Foundations of Software Product Management in Startup and SPM Framework

What is a product? (Business perspective)

Every product, whether a pen, a TV, or WhatsApp, shares four business elements:

1. Parties – a supplier (person or legal entity) and a customer/consumer.
2. Value – the offering is useful; that is, it provides some benefit (even if no money changes hands).
3. Defined rights – what the customer may do with the product: own, use, rent, sell (physical product) vs. use under license (software, e.g., Microsoft Office). The transfer of rights is more fundamental than payment.
4. Commercial interests – the supplier’s motivation (money, data, promotion, etc.).

Definition: A product is an offering transferred from supplier to customer, carrying defined rights, in exchange for some commercial interest, and providing value.

---

Physical Products vs Software Products

Exam tip: The marginal cost difference is the most frequently tested distinction. Physical: high marginal cost → careful inventory management. Software: near-zero marginal cost → business models like freemium or volume scaling become viable.

---

Types of Software Products

Not every app is a “software product.” The defining criterion: primary value must come from the software itself.

• Embedded software – software designed specifically to make a physical device work (e.g., iOS for Apple devices, firmware in a washing machine). It runs only under specific hardware conditions.
• Software product – the software itself is the core value; you can use it independently (e.g., WhatsApp, Google Maps).
• Software-intensive product – software is the primary driver, but not the only component of a larger system.
• Non-software product delivered via software – e.g., a banking app. Without a linked bank account, the app has no value. The primary value is the banking service, not the software. Such a product is not a software product in the strict sense.

Key takeaways

• A product always involves parties, value, defined rights, and commercial interests.
• Physical products: tangible, high marginal cost, slow iteration, physical distribution, delayed feedback.
• Software products: intangible, near-zero marginal cost, fast iteration, digital distribution, real-time feedback.
• Software products are defined by software being the primary value; embedded software, software-intensive products, and apps with non-software primary value are related but distinct categories.

---

Product Family

A product family is a set of diverse but connected products united under a single strong brand to enable cross-selling and build trust. The products are held together for marketing reasons – they may share no common technology.

• Each product in the family has distinct functionality.
• They are often shipped together as a suite.
• Brand power drives adoption of the entire family.

Product Platform

A product platform is a foundational set of shared technologies, components, and services that enable the development of multiple related products (or applications) – not a single product.

Two main types (illustrated by Amazon):

1. Innovation platform – a technological foundation that developers use to build their own products. Example: Amazon Web Services (AWS) – startups build applications on AWS infrastructure.
2. Transaction platform – an intermediary or online marketplace that enables buying, selling, or sharing of goods/services. Example: Amazon marketplace – buyers and sellers transact.

• A platform is not a pointed solution; it is a foundation for many solutions.
• Distinguishing feature: the platform enables others to create value.

Product Line

A product line is a set of product variants that all share a common product platform (architecture, code base, or infrastructure) but are adapted for different markets, geographies, or use cases.

• The product line is a manifestation of the platform.
• Relationship: Product platform → (multiple) product lines.

How the three relate:

Key takeaways

• Product family: different products, same brand (marketing-driven).
• Product platform: shared foundational technology/services that enable other products (e.g., AWS, Android).
• Product line: variants of a product built on a common platform (e.g., country-specific Amazon sites).
• These are distinct: a family can exist without a platform; a platform can have multiple lines; a line always depends on a platform.

Software Product Management Definition and Evolution

Software product management (SPM) is the discipline governing a software product — including embedded software, software-intensive products, and associated services — over its entire life cycle. That means managing every phase from concept (understanding customer needs) through design, development, growth, maturity, and eventual retirement. The goal is not just to produce software but to deliver customer value and business value that makes the product viable.

Definition and Scope

• SPM covers the full gamut of business around the product: strategy, pricing, positioning, development, marketing, and lifecycle decisions.
• It applies to pure software products (e.g., WhatsApp), embedded software in physical goods, and software-intensive systems (e.g., a car’s infotainment system).
• The core output is a product that balances customer satisfaction with sustainable profit.

Evolution of Product Management

The role and focus of product management have shifted dramatically over a century, moving from physical goods to intelligent systems.

Key concept – Phygital and cyber-physical systems Phygital products are physical goods enhanced by software to remove friction (e.g., a smart air conditioner controlled via a phone app). Cyber-physical systems go further — software controls safety, regulation, and autonomous decisions (e.g., a self-driving car).

Key takeaways

• SPM manages a product from concept to retirement, balancing customer and business value.
• Product management originated in physical manufacturing (product era), then added marketing, then software, then platforms, and now intelligence.
• Each new era added a new dimension: scale → branding → iterative UX → ecosystems → systems thinking.
• Hardware and software are converging — modern product managers must handle phygital and cyber-physical products.

---

Desirability–Feasibility–Viability Framework

This framework (adapted from IDEO’s design thinking) identifies three essential pillars for any product’s success. A product that succeeds must sit at the intersection of all three.

Intersections and failure modes

A product can fail if any one pillar is missing:

• Desirability + Feasibility, no viability → Unsustainable. Customers want it and you can build it, but the economics don’t work (e.g., early Dunzo, Zepto had unit economics problems).
• Desirability + Viability, no feasibility → Pipe dream. Demand and money exist, but technology isn’t ready (e.g., telemedicine in pre-COVID India where remote areas lacked data connectivity).
• Feasibility + Viability, no desirability → Useless innovation. You can build it profitably, but nobody wants it. ~40% of startups fail here (per Crunchbase insights; e.g., early VR EdTech tools that customers didn’t adopt at the price point).

Exam tip – the biggest killer The most common cause of startup failure (≈40%) is lack of desirability — building something feasible and viable that nobody actually needs. Always validate desirability first.

Success example: UPI and digital wallets

• Desirability: Massive demand for simple digital payments.
• Feasibility: Core banking and financial backend technologies existed.
• Viability: Billions of transactions enabled the business to scale profitably.

Key takeaways

• A product must be desirable, feasible, and viable simultaneously.
• Missing any one dimension leads to a specific failure pattern: unsustainable, pipe dream, or useless innovation.
• Validate desirability early — it is the most common missing pillar.
• The framework is a practical lens for evaluating any new product idea (e.g., a hypothetical “smart hydration bottle”).

Startup Attributes and Types of Startups

A startup is not a small version of a mature company. Intuitively, think of a caterpillar and a butterfly — the caterpillar is not a “small butterfly”; it is a fundamentally different stage of life. Similarly, a startup operates under conditions that make it a distinct organizational form.

Defining a Startup: The Experiment Lens

Serial entrepreneur Steve Blank defined a startup as “an experiment in search of a business model.” A business model is a hypothesis about how the organization will create, deliver, and capture value. Until validated, the venture is temporary.

Key implications:

• The product is not final — the team does not yet know who the real customers are, how they will use the product, or whether it will meet their needs.
• The approach is iterative experimentation: build, measure, learn, pivot or persevere.
• A startup is a temporary organization designed to discover a repeatable, scalable business model.

Core Attributes of a Startup

Exam tip: The “caterpillar vs. butterfly” analogy is a classic exam question — remember that a startup is structurally different, not just smaller.

Types of Startups (in Product Management Context)

Three major types exist, each with distinct trade-offs for product managers.

1. Bootstrapped Startup

• Funding: Founders self-fund; no external investment.
• Focus: Frugal innovation — lean, low-cost, iterative development.
• Advantages: Full flexibility — choose markets, technology, and release timings independently.
• Disadvantages: Severe resource constraints; heavy reliance on ecosystem partners (e.g., cloud storage, compute vendors); dependency can delay or derail.
• Example: Zoho — famously refused funding to retain control.

2. Funded Startup

• Funding: External investors (angel, VC) provide capital in exchange for equity.
• Focus: Rapid scale and monetization — investors expect high returns within 3–7 years.
• Advantages: Ample resources; ability to hire aggressively, spend on marketing, and develop faster.
• Disadvantages: Time constraint is the sword — not patient capital; pressure to ship and monetize quickly; limited freedom to pivot because investors control strategic direction.
• Examples: Flipkart, Paytm — began small, received funding, grew into platforms.

3. Corporate Venture

• Funding: A single corporate parent provides capital.
• Focus: Strategic alignment — the venture operates within (or adjacent to) the parent’s business.
• Advantages: Access to both capital and the parent’s market, distribution, and expertise (“riding on giant shoulders”).
• Disadvantages: Constraints of alignment — priorities and timelines are dictated by the parent; the venture cannot explore “white spaces” that conflict with the parent’s roadmap.
• Example: Jio (Reliance) — massive initial investment in infrastructure and distribution, made possible by the parent corporation.

Comparison Table

Experimentation in Action: Instagram’s Pivot

Instagram is used as a case study:

• Original idea: a location‑sharing app that let users share photos from places (restaurants, parks) and monetize via sponsors.
• After launch, only the photo‑sharing feature gained traction.
• The team removed all other features — streamlined the app — and relaunched as a pure photo‑sharing platform.
• Business model shifted from location sponsors to the creator economy (ads, influencer marketing).

Exam tip: The Instagram story illustrates that experimentation is not only about adding features; removing features and simplifying can be the winning move. It also shows how the business model itself can pivot.

How Ideas Connect

Key Takeaways

• A startup is not a small version of a mature business; it is a temporary, experimentation‑driven organization searching for a repeatable business model.
• Core attributes: extreme uncertainty, experimentation, temporary structure, resource constraints, and ecosystem dependency.
• Three types: bootstrapped (frugal, flexible), funded (resource‑rich but time‑pressed, investor‑controlled), and corporate venture (strategic alignment, parent‑dependent).
• Product managers must adapt their approach based on the type: e.g., pivot cautiously in funded startups, embrace partnership dependency in bootstrapped ventures.
• Real‑world pivots (e.g., Instagram) show that experimentation often means removing features, not just adding them.

Discovery Phase

The Discovery Phase is the first stage of a startup’s product evolution. Its purpose is to answer a single high-stakes question: Does this product need to exist? Founders who skip this phase risk building something nobody wants — ~40% of startup products are never needed (Crunchbase Insights). The phase systematically uncovers a real customer problem, validates that enough people face it, and checks whether existing solutions are inadequate.

Step 1: Spot the Customer Problem

A customer problem is not a business problem; it is a difficulty or inefficiency a person experiences when completing a task. It is uncovered by keen observation of current practices — analysing the time, effort, cost, and risk involved in the way people do things now.

Airbnb example: The founders couldn’t pay rent and rented out air mattresses to conference attendees. They observed that short-term travellers struggled to find affordable, convenient accommodation — a problem of temporary demand-supply mismatch.

Step 2: Observe / Survey a Large Sample

Once a potential problem is spotted, the startup must gather customer insights from a large sample (not just the first few users). The goal is to identify a pattern: does the problem repeat across a significant population? Who faces it? Under what conditions?

Airbnb example: They talked to hundreds of travellers attending conferences and events in San Francisco. The pattern emerged: during conferences, peak vacation times, and events, there was a consistent lack of affordable, nearby accommodation.

Step 3: Study the Alternatives

Before building a solution, the startup must understand what customers currently do to cope with the problem. This step determines whether the problem truly needs a new solution or could be solved with a simple tweak (e.g., better information). The analysis should examine cost, convenience, risk, time, and effort of each existing alternative.

Airbnb example:

• Hotels: expensive, often unavailable at short notice
• Staying far away: inconvenient and unsafe
• Friends/family: not everyone has them nearby

Conclusion: no scalable alternative existed; the problem was not about awareness but a genuine supply-demand mismatch.

Why This Matters for Pricing

Studying alternatives directly informs pricing. The value of the solution is bounded by what customers currently pay in time, money, and hassle. Airbnb’s $80 per night price was not arbitrary — it reflected the cost and inconvenience of hotel rooms and distant rentals.

Practical Application

Apply the same three questions to any startup (e.g., Niramai, Zoho, or your own idea):

1. What is the pressing unmet need?
2. Who has this problem, and how does it manifest across segments?
3. What current alternatives exist, and at what cost, convenience, risk, time, and effort?

Exam tip: The 40% failure rate statistic (Crunchbase) is a high-yield reminder: the Discovery Phase is not optional. Questions often ask why startups fail — lack of problem validation is a top cause.

Key takeaways

• The Discovery Phase confirms that a real customer problem exists before any solution is built.
• Step 1: Spot the problem via observation of time, effort, cost, and risk.
• Step 2: Validate the pattern by surveying a large sample (100s–1,000+).
• Step 3: Study alternatives to see if the problem is truly unsolved or just poorly matched.
• Alternative analysis directly feeds into pricing strategy.
• Skipping discovery leads to a ~40% chance of building something no one needs.

From Discovery to Validation: Shifting Focus

The discovery phase (Steps 1–3) established whether a real customer problem exists — it emphasised desirability (“do they need it?”). The validation phase (Steps 4–6) checks whether your solution actually works for real users. Now feasibility (“can we build it?”) becomes equally important.

The DFV framework (desirability, feasibility, viability) visualises this shift:

• Discovery: desirability circle is largest — the focus is on understanding the problem, customer segments, and alternatives.
• Validation: both desirability and feasibility circles are large — the solution must continue addressing a real problem and be buildable within constraints.

The goal of validation: build something that some people actually use and find valuable — not just express approval.

---

Step 4: Build the Core Product

What to build and what not to build is critical. Create a minimum version of the product that addresses the needs of a carefully selected set of early adopters — not all potential customers.

Airbnb example: Founders listed their own apartment with three air mattresses on a simple blog/website — no automation, just contact info and pictures. Target: attendees of a specific conference. That was their minimum viable product (MVP) — a crude but testable offering.

---

Step 5: Validate the Core Product

The MVP is now tested with real users. Validation addresses desirability + feasibility and focuses on durability and repeatable use — not mass adoption.

• Durability: Do users find the solution valuable enough to return?
• Repeatability: Do they come back and use it again?
• Comparison with alternatives: Can users compare the new offering with existing options and give meaningful feedback?

Airbnb validation:

• Would strangers stay in someone else’s home? (Behavioural change for guests)
• Would hosts list their spaces? (Behavioural change for hosts)
• Real people booked, stayed, and paid. Hosts rented space. This proved the concept — not just verbal enthusiasm.
• Validation insight: Usage and feedback are the proof-point, not just payment.

Exam tip: Validation is not when users say “great idea”. Validation is when they change their behaviour because of your product.

---

Step 6: Sharpen the Core Product (Validated Learning)

Validated learning is data-driven, not just qualitative. Use metrics to fine-tune the product within available means (time, cost, effort). Ask: what works? What doesn’t? Improve the former, remove the latter.

Airbnb sharpening:

• Improved listing quality — added photos of interiors, utilities, features.
• Collected reviews to build trust.
• Made booking simpler.
• Result: the core value proposition gets stronger for existing users (both hosts and guests), even if not yet ready for mass scale.

The output of these three steps is a problem-solution fit.

---

Problem-Solution Fit

Validation culminates in problem-solution fit — the point where you have:

1. A clear, unambiguous target customer — you know their attributes, problem, patterns, and alternatives.
2. Clarity of the problem — exactly what are you solving?
3. An MVP that works for those customers.
4. Users who find it valuable — demonstrated by usage, repeat behaviour, feedback, and (ideally) payment.

Airbnb example: Simple website, few listings, real bookings. The MVP proved demand exists beyond hotels/friends/family. Both hosts and guests showed behavioural change — hosts opened their homes, guests chose to stay with strangers.

Key difference from product-market fit: Problem-solution fit is about validating the solution for a small set of early users; product-market fit (covered later) is about scaling to the mass market.

---

Key takeaways

• Validation shifts focus from desirability alone to desirability + feasibility.
• Build a minimal product (MVP) for a carefully selected set of real users — aim for speed and learning.
• True validation = behavioural change, repeat usage, and measurable feedback, not just praise.
• Sharpening uses data-driven learning to improve what works and remove what doesn’t.
• Validation ends with problem-solution fit: a clear target customer, a clear problem, a working MVP, and evidence of value.

Product Thinking

Product thinking is a customer-first, value-centric, continuous approach to building products that are scalable, sustainable, responsible, and profitable or impactful. It contrasts with project thinking, which is limited by budget, time, and defined goals. A product is a long-term, evolving solution that solves real-world problems for a population scale — not just a single transaction.

Product thinking = value + iteration + impact + profitability — all with a long-term lens.

The Five Dimensions of Product Thinking

Every global product must be evaluated along these five interrelated pillars:

Value: The Core Driver

• Solve a real problem — identify what customers currently use (alternatives), at what cost/convenience/risk.
• Drive adoption & retention — the first use must deliver benefit immediately. WhatsApp’s phone‑number‑only sign‑up made first‑use value instant, leading to high retention.

Scalability: Thinking Beyond the First User

• Architecture must handle rapid growth without performance loss.
• Ecosystem thinking — the product must interface seamlessly with other systems (payment gateways, banking, devices). UPI succeeded because NPCI built a simple, robust, interoperable system.

Sustainability: Three Layers

1. Environmental — minimize negative impact (e.g., avoid fossil fuels).
2. Social — work across demographics and sustain social cohesion.
3. Economic — create value for both the business and its ecosystem partners (suppliers, developers, etc.).

Responsibility: The Modern Imperative

Modern digital products are deeply embedded in life; responsibility covers:

• Ethical design — no dark patterns (manipulative defaults, addictive loops).
• Data privacy & trust — transparent processing, secure handling, informed consent.
• Safety — protect users and non‑users (e.g., content moderation).

Exam tip: Trust and sustainability are strategic advantages — even if regulators don’t ban an irresponsible product, users will eventually abandon it.

Profitability / Impact: The Survival Condition

• Commercial platforms must generate revenue (profits) to survive.
• Societal platforms must deliver measurable social impact (e.g., Aadhaar’s inclusion).
• Without either, the product will disappear (e.g., many short‑lived apps that were not profitable).

Trade-Offs and Interconnections

• Trade-offs are inevitable — e.g., maximizing profit might tempt dark patterns, undermining responsibility.
• Trust and sustainability make the product a long‑term strategic advantage; short‑term gains at their expense lead to eventual failure.

Key takeaways

• Product thinking is multidimensional: value, scalability, sustainability, responsibility, profitability/impact.
• Customer value drives adoption/retention; first‑use benefit is critical.
• Scalability requires robust architecture and ecosystem integration.
• Sustainability spans environmental, social, and economic dimensions.
• Responsibility (ethics, privacy, trust) is a modern strategic necessity.
• Profitability or societal impact is required for survival; all five dimensions must be balanced.

Job-To-Be-Done (JTBD) Framework

Jobs to Be Done (JTBD) is a framework for understanding why customers “hire” a product. The core insight: people do not simply buy products; they hire them to make progress in a specific context. The progress includes functional, emotional, and social dimensions — not just the stated need.

Need vs. Value

Customer need = a problem, pain, or job the user wants done. Value = the perceived benefit minus the total cost (money, time, effort, risk). A product may solve the need but still fail if it does not deliver enough relative value compared to alternatives.

$\text{Value} = \text{Benefits} - \text{Costs} \quad (\text{where costs include money, time, effort, risk})$

Many products fail not because they don't solve the need, but because they don't deliver enough value.

Example – Doctor’s Certificate A doctor wants to hang her MD certificate.

• Functional need: Display the certificate (regulatory / practical).
• Emotional need: Pride, sense of achievement after a decade of study.
• Social need: Build trust and confidence in new patients (social credibility).

A simple drilling machine solves the functional need (hang the photo). But a framing service or a digital display that enhances the emotional and social value would deliver more value.

Example – Uber vs. Traditional Taxi Both solve the need “get from A to B.” But Uber added:

• Convenience – app-based booking, tracking, expected arrival time.
• Reliability – real-time data, driver rating before the ride.
• Safety – perceived security through tracking.

Uber did not invent a new need; it delivered higher value by addressing emotional and social jobs (reliability, safety, convenience) on top of the functional job.

The JTBD Framework (Clayton Christensen)

When customers “hire” a product, they look for progress across three types of jobs:

The framework forces teams to look beyond the stated need and uncover the full set of jobs. This enables designing a value proposition that outperforms current alternatives.

Conducting JTBD Interviews – Process

A step-by-step interview approach uses a recent payment scenario (e.g., a small UPI-like payment). The logic flow is:

Sample interview questions (from the UPI example):

1. Trigger event: “Tell me about the last time you paid a small amount (₹46 for a rickshaw).”
2. Context: “What caused that payment? Did the driver lack change?”
3. Options considered: “Did you think of cash, card, cheque? Which ones and why?”
4. Frustrations: “What frustrated you most about each option?”
   • Cash: needing exact change, not having small notes.
   • Card: remembering PIN, terminal not available, risk of sharing details.
5. What nearly stopped you? “Did any of these issues almost make you avoid the transaction?”
6. Trade‑offs made: “What did you sacrifice? (e.g., small change, privacy, time)”
7. Satisfaction: “Were you relieved when the payment went through? How?”
8. Importance: “How important is it to have a certain, easy payment method?”
9. Perfect solution: “What would a perfect solution look like? (e.g., no details, no change, always works)”

After interviewing several people, look for patterns – common frustrations, recurring contexts, and unsatisfied emotional/social jobs.

Synthesised JTBD statement (payment example):

“When I need to pay, I want to pay simply and easily and in a certain way so I can feel relieved that I'm not at risk of non‑payment.” Functional job: pay without losing extra money / change. Emotional job: avoid anxiety about being unable to pay. Social job: avoid embarrassment.

Worked Example – UPI Payment Alternatives

Exam tip: The JTBD interview process is a direct application of the customer discovery phase. The goal is to validate the importance of the job and identify where current alternatives fall short. This feeds the value proposition canvas (covered later).

Key Takeaways

• Need ≠ Value. Value = benefits – costs; a product can solve a need but still fail if it doesn't deliver enough value compared to alternatives.
• Jobs to Be Done includes functional, emotional, and social dimensions. Always probe beyond the stated need.
• Interview method: start with a recent, specific event; ask about triggers, alternatives, frustrations, trade-offs, and the perfect solution.
• Pattern recognition across multiple interviews reveals the true JTBD statement.
• Value proposition is built by making progress on jobs better than the alternatives in all three dimensions.
• Practice on any product (WhatsApp, Instagram, Perplexity) by mapping the functional, emotional, and social jobs.