Software Product Management for Startups

IIM Bangalore BBA in Digital Business and Entrepreneurship · Term 6 · 2 modules, 102 topics.

Customer Value, Market Segments and Product-Market Fit

Value Pyramid

The value pyramid (developed by Eric Almquist and Bain & Company) decomposes customer value into layers, from basic functional needs to profound social impact. Most products compete only on functional elements — faster, cheaper, better — which leads to commoditization: little differentiation, low pricing power. The pyramid helps a product escape commoditization by adding higher-order value elements that build loyalty and premium.

The framework is analogous to Maslow’s hierarchy of needs: foundational needs must be met first, then emotional, life-changing, and finally social-impact needs.

The Four Layers

Layer	Core Question	Examples of elements	Strategic role
Functional	“Does it save time, effort, or money?”	Saves time, simplifies, reduces effort, organizes transactions, provides information	Table stakes — necessary but not sufficient; easy to replicate. If value stops here, product is commoditised.
Emotional	“How does it make me feel?”	Reduces anxiety, rewards me, wellness, fun/entertainment, badge value	Drives higher Net Promoter Score (NPS) and differentiation.
Life-changing	“Does it change my opportunities or identity?”	Hope, self-actualization, belonging, motivation	Creates infectious loyalty (e.g., iPhone users who upgrade every year).
Social impact	“Does it affect society or equality?”	Self-transcendence, collective belonging, access for underserved groups	Deepens long-term commitment; can make a product culturally essential.

Key Principle: You Don’t Need All 30 Elements

The full pyramid contains about 30 elements. A strong product typically uses 7–8 well-chosen elements — but crucially, at least one or two from the higher layers. The premium and differentiation come from the top, not from piling on functional features.

✅ UPI (Unified Payments Interface) — Successful Value Bundle

Layer	Elements chosen	Why it works
Functional (4)	Saves time, simplifies (scan QR), reduces effort, avoids hassle	Compared to old inter-bank transfers, UPI is instant, one-click.
Emotional (3)	Reduces anxiety (instant confirmation), rewards (cashback), access to digital ecosystem	Users feel secure and rewarded.
Life-changing (3)	Financial inclusion: creates a visible transaction history → farmers/ small vendors can get loans → self-actualisation	Belonging to the formal financial system opens doors.
Social impact (1)	Universal financial inclusion: equal payment capability for all smartphone users (e.g., auto driver can accept UPI)	Reduces inequality; everyone can transact.

Result: About 10–11 elements from 30, but the higher layers turned UPI into a transformative platform with massive loyalty.

❌ Hike (Messaging App) — Failed Value Bundle

Hike (a $1B+ unicorn) was a feature factory — many functional features (chat, emojis, stickers, hidden chats, free SMS) but missing higher-order value.

Layer	Present?	Issue
Functional	Many features	But no clear “saves time” or “simplifies” advantage over WhatsApp.
Emotional	Weak (fun/gamification)	No strong emotional binding — users saw no reason to switch.
Life-changing	Absent	No hope, self-actualisation, or belonging.
Social impact	Absent	No community or social purpose.

Lesson: Churning out functional features without emotional or life-changing elements → no lasting engagement → eventual collapse despite high valuation.

Practical Takeaways for Product Managers

Audit your value bundle against the pyramid. Pick ~7–8 elements, with at least one from emotional or higher.
Differentiate through the top layers, not through functional parity.
Recognise that value is personal — the bundle may differ across user segments (e.g., young user vs. elderly parent). Map value per persona.

Exam tip: The value pyramid is often compared to Maslow’s hierarchy. The key result: functional value is necessary but commoditising; emotional and higher layers drive loyalty and premium pricing. Memorise the UPI and Hike contrasts.

Key takeaways

The value pyramid (Bain) organises customer value into four layers: functional → emotional → life-changing → social impact.
Functional elements are table stakes; if your product stops there, you compete on price only.
Emotional elements (reduced anxiety, rewards, badge) boost NPS and differentiation.
Life-changing and social impact elements create infectious loyalty and long-term commitment.
A strong product uses ~7–8 elements, including at least one higher-order element (UPI succeeded; Hike failed because it had only functional + weak emotional).
Value bundles are not one-size-fits-all; tailor them to different user segments.

Value Proposition Canvas

The Value Proposition Canvas is a framework for ensuring that a product’s features actually address real customer needs. Intuition: too many products are built around features that sound impressive in a spec sheet but fail because they don’t solve what the customer actually cares about. The canvas forces you to separate customer profile (what the customer wants, fears, and hopes for) from the value map (what your product delivers), and then check that the two match.

It was developed by Alex Osterwalder as a companion to the Business Model Canvas.

Customer Profile (the “demand” side)

The right-hand circle describes the customer in three layers:

Jobs to be done (functional, social, emotional)
- Functional: tasks the customer wants to accomplish (e.g., send money, pay bills).
- Social: how the customer wants to be seen by others (e.g., splitting a dinner bill without embarrassment).
- Emotional: the feeling the customer seeks (e.g., convenience, confidence, belonging).
Pains – problems, frustrations, or risks the customer experiences with the current solution (e.g., transaction friction, accessibility limits, high fees).
Gains – outcomes the customer dreams of or would be delighted by, even if not yet achieved (e.g., instant confirmation, one‑app simplicity, financial inclusion for the unbanked).

Note: Pains and gains are always relative to the existing way of doing the job, not the new product.

Value Map (the “supply” side)

The left-hand square contains the product’s offering, also in three layers:

Products & services – the specific features, technologies, and third‑party integrations that make up the offering (including the whole product – everything that surrounds the core to deliver complete value).
Pain relievers – how each pain from the customer profile is addressed.
Gain creators – how each gain is produced.

The central task is to map one side to the other:
Pains → Pain relievers, Gains → Gain creators, Jobs → Products & Services.

flowchart LR
  subgraph Customer Profile
    J[Jobs to be Done]
    P[Pains]
    G[Gains]
  end
  subgraph Value Map
    PS[Products & Services]
    PR[Pain Relievers]
    GC[Gain Creators]
  end
  J --> PS
  P --> PR
  G --> GC

UPI Example (India’s Unified Payments Interface)

Customer Profile (for a digital wallet user)

Jobs to be done	Pains (current system)	Gains (desired)
Send money to friends<br>Pay local vendors<br>Pay utility bills<br>Split dinner bills (social)<br>Avoid carrying cash (convenience)	High transaction friction – entering bank details, 30‑min wait for payee to be added<br>Limited digital acceptance (e.g., auto‑rickshaw)<br>High merchant discount rates (MDR) on credit cards	Instant credit and confirmation<br>All‑in‑one app<br>Financial inclusion for low‑balance users

Value Map (UPI solution)

Products & services	Pain relievers	Gain creators
UPI protocol (mobile‑first, interoperable)<br>Virtual Payment Address (e.g., name@bank)<br>QR codes (open source, whole product)	Scan‑and‑pay (no typing details)<br>Interoperability – any UPI app works with any bank<br>Zero‑fee architecture (subsidised by volume)	24×7 availability (no bank hours)<br>Real‑time feedback (e.g., sound box in shops)<br>Integrated account systems (bill pay, investment, credit lines)

Each pain is explicitly tackled by one or more pain relievers, and each gain creator maps to a customer gain. The canvas reveals value gaps – features with no corresponding job, pain, or gain – and prompts teams to fill them or cut the feature.

Exam tip: Examiners often ask you to distinguish between a feature (e.g., “QR code”) and a pain reliever (“eliminates need to type bank details”). Always link every element of the value map back to a specific job, pain, or gain.

Key takeaways

The Value Proposition Canvas decouples what the customer experiences (jobs, pains, gains) from what the product provides (products & services, pain relievers, gain creators).
Start with the customer profile first, then design the value map to match.
A value gap exists when features are offered that do not address any real pain or gain.
The canvas is especially useful for early‑stage startups: it prevents feature bloat and ensures product‑market fit.
Apply the canvas to your own product by listing all jobs, pains, and gains – then check whether each is covered.

Markets and Customer Segments

A market is a group of customers with shared needs and willingness to pay (where “pay” includes time, attention, or subscription – not just cash). It is not an industry; a single product (e.g. WhatsApp) serves consumers, small businesses, and housewives across many industries. Markets consist of actual and potential buyers with specific needs (Philip Kotler).

Why does this matter? Products fail not because of bad technology but because of weak market readiness – e.g. Google Glass was technologically advanced but had no ready market; WhatsApp used simple tech and achieved mass adoption.

Software product markets are special

Dynamic – a product useful for one group can suddenly address a larger market (e.g. Peloton’s fitness content expanded from hardware to a Spotify-tied subscription, opening Indian users).
Network-driven – word-of-mouth, viral effects, and behavioural consumption patterns spread faster.
Winner-takes-all (or most) – software can rapidly capture huge market share.

Customer Segments – dividing the market

Customer segmentation is the process of dividing a broader market into smaller groups with similar characteristics. Segments are more granular than markets: e.g. the fitness market contains segments like “North American athletes”, “Asian senior citizens”, “weight-loss beginners”.

Types of segmentation (for software)

Type	Basis	Example (fitness wearables)
Demographic	Age, income, profession	Athlete vs. senior citizen
Behavioural	Usage patterns, engagement	Athlete records performance data; senior monitors vitals (pulse, oxygen, ECG)
Psychographic	Lifestyle, motivations, values	Urban banker in Gurugram (long commute, less family time) vs. tier-2 banker (goes home for lunch) – different usage needs
Jobs to be done	Common tasks/pains irrespective of other attributes	“Manage investments” – any age, lifestyle, or income who wants simple wealth building

Segmentation optimises product differentiation and competitive advantage. A generic product is unclear; a segment-specific product (e.g. “Ultra 2 for athletes”) controls costs and delivers precisely to that group.

Market structures in software

Structure	Description	Example
Mass market	Broad horizontal appeal, network effects	Instagram, Facebook
Vertical niche	Specialised, deep expertise, narrow	Zerodha (futures & options traders)
Multi-sided platform	Two+ interdependent segments	Amazon (buyers ↔ sellers ↔ AWS), Uber (riders ↔ drivers)
Emerging market	Product space itself is new and rapidly evolving	OpenAI, Perplexity (AI – student, researcher, journalist use cases)

These structures are not static – they evolve with technology and customer learning.

Segmentation in practice – examples

Netflix: DVD rentals → streaming → AI-created micro-segments based on consumption patterns, demographics, and geography.
Uber/Amazon: multi-layered segmentation – each sub-segment (e.g. Amazon consumers vs. sellers) has distinct needs met by the same platform.
Zerodha: disruption via a focused segment (retail, cost-conscious, DIY investors) that challenged traditional brokerages.

Personas – bringing segments to life

A persona is a fictional representation of a key segment, giving it a name, demographics, goals, pains, and gains. It bridges the gap between abstract segmentation and product design.

Example: Investment platform persona (e.g. for Groww, CRED)

Amit / Radha – “Aspirational professional”

Age 26–35, first or second job
Urban living (Mumbai, Bangalore, Gurugram)
Income ₹8–25 lakhs p.a.

Goals

Help me manage money better and grow wealth (efficient, weekly 10-min check-in)
Make smart investments without complexity (access to equities, mutual funds – not real estate)

Pains

Medium financial literacy (first-gen saver)
Too many fragmented apps
Fear of losing money

Gain expectations

Simplicity, automation (e.g. monthly portfolio view)
Trustworthy market insights
Ease of learning and building wealth

This segment is defined by jobs to be done – common pains and gains – not just age or income.

Common segmentation mistakes (for builders)

Assuming segments without validation – e.g. “all 20–30 year olds go to the gym”. Not true.
Over-relying on demographics – age/city/income alone miss motivational and behavioural differences.
Ignoring early adopters – some individuals break the segment pattern (e.g. a senior citizen with high risk appetite). Early adopters are critical for product launch.
Targeting too broad a market – “all students in India” is too vague. Slice by K12, university, post-grad, med school, etc.

Exam tip: The difference between a market and a segment is a frequent test point. A market is a broad group with shared needs and willingness to pay; a segment is a narrower slice defined by a combination of demographic, behavioural, psychographic, or jobs-to-be-done criteria. Always give concrete examples (Peloton, Zerodha).

Key takeaways – Markets

A market is customers with shared needs + willingness to pay (not an industry).
Software markets are dynamic, network-driven, and winner-takes-most.
Segmentation divides a market into smaller groups with similar characteristics.

Key takeaways – Customer Segments

Four common segmentation bases: demographic, behavioural, psychographic, jobs-to-be-done.
Four market structures for software: mass market, vertical niche, multi-sided platform, emerging market.
Personas (fictional representatives) make segments actionable for product design.
Common mistakes: assuming without validation, over-relying on demographics, ignoring early adopters, targeting too broadly.

Market Sizing: TAM, SAM, and SOM

Before building any product, you must answer two questions: How big is the opportunity? and Who will be my first customers? TAM, SAM, and SOM provide a top-down framework to size the market from broadest to most actionable.

Definitions and Intuition

Term	Meaning	Analogy (Zerodha – an investment platform)
Total Addressable Market (TAM)	The entire revenue opportunity if you captured 100% of a market. It answers: "How big could this be?"	All retail investors worldwide who trade in exchange-traded securities and mutual funds.
Serviceable Available Market (SAM)	The portion of TAM you can realistically reach given your business model, geography, regulation, and distribution.	Online retail investors in India (cross-border regulation restricts global reach).
Serviceable Obtainable Market (SOM)	The slice of SAM you can actually capture in the near term with your current resources, marketing, and sales.	Cost‑conscious, frugal, self‑driven retail investors who want low brokerage and no dedicated relationship manager.

Intuition: TAM is the total pie; SAM is the pie you can touch; SOM is the slice you can eat now. Every startup must define all three. A huge TAM is useless if your SOM is tiny and unserviceable.

Why This Matters

TAM convinces investors of the ceiling.
SAM focuses your go‑to‑market on a reachable segment.
SOM grounds your short‑term business plan – you can only serve what your team, budget, and capacity allow.

Exam tip: Be precise: SOM is not just “people who might buy”; it’s the specific sub‑segment you have the operational ability to serve today.

Key Takeaways – TAM/SAM/SOM

TAM = total market for the problem your product solves (global).
SAM = market you can serve within constraints (e.g., regulation, geography).
SOM = market you can obtain with current resources (your realistic first target).
Always think top‑down (“think big”) but execute bottom‑up (“start small” with SOM).

Early Evangelists

Early evangelists are the first customers who urgently need your solution – not necessarily your brand, but the value you deliver. They will adopt an incomplete product, provide feedback, pay, and advocate.

How to Spot an Early Evangelist

Use the five‑point test – a candidate must:

Have a clear problem that your product addresses (e.g., athletes need to track hydration – they don't just want a bottle, they want data).
Be actively searching for a solution (already using workarounds like spreadsheets or apps).
Be dissatisfied with current alternatives (manual tracking is tedious).
Have budget or authority to pay (willing to spend ₹1000 vs. ₹100 for a normal bottle).
Will promote if the product works (share on social media, within communities).

Connecting TAM/SAM/SOM with Evangelists

Top‑down (TAM→SAM→SOM): sizes the opportunity.
Bottom‑up (evangelists): identifies the first customers within your SOM.

flowchart LR
    A[Think Big: TAM] --> B[Reachable: SAM]
    B --> C[Actionable: SOM]
    C --> D[Find Early Evangelists within SOM]
    D --> E[Validate product-market fit]
    E --> F[Expand SAM → TAM]

Start with SOM, then zoom in on the evangelists inside it. The product is built for the planet, but you begin with 100 people who fit the evangelist profile.

Why Early Evangelists Matter

Validate product‑market fit – if they adopt, the core need is real.
Refine product quickly – their feedback guides incremental improvements (e.g., adding pH measurement to a water bottle).
Generate initial traction – they pay (not just test for free) and become vocal advocates.

Exam tip: Early evangelists are not personas or demographic groups. They are named, specific individuals you can list (e.g., “Ram, a marathon runner from Bangalore”). The exercise requires naming them.

Key Takeaways – Early Evangelists

Early evangelists have a clear problem, actively search, are dissatisfied, have budget, and will promote.
They accept an imperfect product because the core value outweighs limitations.
Use them inside your SOM – do not start with the whole TAM.
They are the foundation for validated learning and product‑market fit.

Learning Loops

A learning loop is the Build‑Measure‑Learn cycle that turns assumptions into validated knowledge. It reduces market risk, accelerates product‑market fit, and saves time/money.

The Cycle

flowchart TD
    A[Build MVP] --> B[Measure behavioral data]
    B --> C[Learn: validate hypotheses]
    C --> D{Pivot or Persevere}
    D -->|Persevere| A[Iterate with next MVP]
    D -->|Pivot| E[Change product, customer, or value]
    E --> A

Build a Minimum Viable Product (MVP) – a version that meets the needs of a tiny segment, delivering maximum learning per unit of effort. It is not just a prototype; it must be usable enough to generate real feedback.
Measure behavioral data (engagement, retention, usage patterns), not opinions (“Do you like it?”). Focus on what users do, not what they say.
Learn – compare outcomes against the original hypotheses (assumptions about the problem, solution, and customer). Decide to persevere (continue on the same path) or pivot (change course).

Pivot Types

Pivot Type	What Changes
Product pivot	Feature set or technology shifts based on feedback.
Customer pivot	Target a different segment that finds the product more valuable.
Value pivot	Change the core value proposition (e.g., from hydration tracking to wellness coaching).

Role of Early Evangelists in Learning Loops

Early evangelists are the ideal participants in the loop because they:

Give honest, constructive feedback even when the product is rough.
Are willing to pay and use the product repeatedly, providing real behavioral data.
Help refine the MVP faster than general users.

Exam tip: The three questions that every learning loop answers: (1) Do users use the feature? (2) Do they return? (3) Does the data confirm or reject our hypothesis? Avoid vanity metrics.

Key Takeaways – Learning Loops

Build‑Measure‑Learn is the core cycle for validated learning.
MVP must be a real, usable product for a tiny segment, not a demo.
Measure behavior (engagement, retention) – never rely solely on stated preferences.
Learning leads to either persevere or pivot; pivots can be product, customer, or value.
Early evangelists are the best partners for the loop – they provide honest data and advocacy.

MVP Strategies for Learning Loops

A learning loop is a cycle of three activities—Build, Measure, Learn—used to validate assumptions about a product idea quickly and cheaply. Instead of building a full product, you run small experiments to generate validated learning about what customers actually need.

A learning loop is not about shipping features; it is about extracting knowledge from minimum effort, cost, and time.

Hypotheses before building

Before starting any loop, state three core hypotheses (informed assumptions):

Hypothesis	What it asks	Example (Smart Water Bottle)
Problem	Do we understand the problem?	People do not drink enough water; current alternatives (manual reminders, bottles) are inadequate.
Customer	Who has this problem?	Busy professionals, fitness enthusiasts, high‑performance athletes.
Value	What value will the product bring?	Smart tracking improves hydration habits by delivering data‑driven insights (behavioural change, not just measurement).

Three MVP strategies (sequential learning loops)

The goal of an MVP (Minimum Viable Product) is maximum learning with minimum effort, cost, and time. For the smart water bottle, the team runs three loops, each testing a different risk:

flowchart LR
  subgraph Loop1[Loop 1: Reminder effectiveness]
    A1[Build: WhatsApp reminder bot] --> B1[Measure: % user response, frequency]
    B1 --> C1[Learn: Do reminders work?]
  end
  subgraph Loop2[Loop 2: Personalization]
    A2[Build: App with wearable-data triggers] --> B2[Measure: retention, engagement]
    B2 --> C2[Learn: Does personalisation increase value?]
  end
  subgraph Loop3[Loop 3: Hardware viability]
    A3[Build: Hardware prototype & pilot] --> B3[Measure: willingness to pay, daily usage]
    B3 --> C3[Learn: Is the full product viable?]
  end
  Loop1 -->|Success| Loop2
  Loop1 -->|Fail| Pivot1[Pivot or stop]
  Loop2 -->|Success| Loop3
  Loop2 -->|Fail| Pivot2[Pivot segment or value]
  Loop3 -->|Success| Go[Proceed to full build]
  Loop3 -->|Fail| Pivot3[Pivot model or kill]

Loop 1 – Reminder effectiveness
Build a simple WhatsApp bot that sends periodic hydration reminders. Measure activation (how many sign up) and retention (how many keep using it). Learn whether reminders alone are valuable enough to pursue the idea.

Loop 2 – Personalization
If reminders work, create an app that reads data from a wearable (e.g., step count from Fitbit) to send activity‑triggered reminders. Measure engagement (how regularly users interact with the app and update data). Learn whether personalisation increases perceived value.

Loop 3 – Hardware viability
Only after verifying software value, build a hardware prototype (the smart bottle). Measure conversion – willingness to pay and actual daily usage. Learn the economic feasibility and price sensitivity.

Key metrics across all loops are:

Activation – % of users who start using the solution.
Retention – % who return after first use.
Engagement – frequency and depth of interaction.
Conversion – % who pay or intend to pay.

Pivot decisions & common traps

Based on the learnings, teams make pivot decisions:

Pivot type	Decision point	Example
Product pivot	Can the solution be app‑only?	Skip hardware entirely.
Segment pivot	Which customer segment is the sweet spot?	Focus on athletes instead of general users.
Value pivot	Does the core value shift?	Move from hydration tracking to a wellness platform.

Common traps to avoid:

Building hardware too early – start with software (WhatsApp, app) to test assumptions cheaply.
Ignoring early customer feedback – data from the first few users is the most valuable.
Measuring vanity metrics – focus on behaviours that indicate value, not just output.
Iterating too slowly – each loop should be rapid (days, not months).

Exam tip: The MVP is not a product – it is a learning vehicle. State the hypothesis, run the loop, measure the right metrics, and pivot or proceed. This is the most tested concept in the section.

Key takeaways

The learning loop is Build → Measure → Learn; the cycle repeats to reduce uncertainty.
Start with clear hypotheses: problem, customer, value.
Run sequential MVPs that test the riskiest assumption first (software before hardware).
Measure activation, retention, engagement, and conversion – not downloads or notifications sent.
Pivot on product, segment, or value based on what the data reveals.

Metrics for the Learning Loop

The “Measure” step in a learning loop is only useful if you pick the right metrics. Two categories exist:

Vanity metrics – numbers that look good but do not inform decisions.
Actionable metrics – data that shows a clear cause–effect relationship and guides the next action.

Three qualities of a good metric

Causal – there is a direct relationship between what you build and the user behaviour you observe.
Example: A personalised reminder (build) leads to the user hydrating sooner (behaviour).
Actionable – the metric tells you what to do next.
Example: Low engagement → expand the sample or tweak the reminder interval.
Predictive – the metric from the MVP can forecast future success in a larger market.
Example: 60% daily retention among 100 users suggests a similar rate at scale.

Vanity vs. Actionable: digital water bottle example

Metric	Type	Reason
App downloads	Vanity	Downloads ≠ usage; no insight into value.
Active users (daily / weekly)	Actionable	Shows real engagement – users find value.
Notifications sent	Vanity	Sending 5000 notifications is an output, not an outcome.
Reminder response rate	Actionable	Links your reminder to the user’s hydration action – causal.
Units sold	Vanity	Paying customers who never use the product predict churn.
Daily hydration tracked (e.g., % of target users logging water)	Actionable	Core value metric – validation that the product changes behaviour.

Using metrics to drive pivots

After measuring, the “Learn” step answers “Should we continue, pivot, or stop?” Actionable data provides the evidence. Vanity metrics leave you guessing.

Exam tip: Be ready to classify metrics as vanity vs. actionable. A common trick: ask “Does this number tell me what to do next?” If not, it is vanity.

Key takeaways

Every metric must be causal, actionable, and predictive to be useful.
Vanity metrics (downloads, notifications sent, units sold alone) inflate optimism without guiding decisions.
Actionable metrics (active users, response rate, daily tracked usage) link directly to value and enable pivots.
The learning loop’s power depends on the quality of the measured data – measure outcomes, not outputs.

Defining a Market

A market is a group of customers or potential customers who share a common problem, have a similar purchasing power, and are willing to adopt a solution. It combines:

Shared needs – the core problem.
Context – geographic, demographic, or lifestyle similarities.
Behaviour – common usage patterns and decision-making.
Ability to pay – economic capacity and willingness to spend.
Alternatives – existing solutions customers compare against.

Market Expansion

Moving from one customer segment to another requires understanding differences in context, needs, behaviour, and ability to pay. Expansion can be:

Niche → mainstream (e.g., growing from a few hundred users to millions).
Local → global (e.g., a product built for one country taken to 100).

Example: UPI (India)
Started with tech‑savvy urban smartphone users. Expanded to small merchants, then rural consumers (as smartphones spread), then street vendors (via QR codes), and finally a mass retail ecosystem – becoming a national payment infrastructure.

Example: Airbnb
Started with budget travellers attending conferences (the MVP). Grew to families on vacation, luxury travellers, and business travellers seeking long‑term stays.

Technology Adoption Lifecycle (Geoffrey Moore)

Intuition: Different customer groups adopt technology for different reasons. A product built for early adopters will not automatically appeal to later groups. Moore’s model (based on Everett Rogers’ Diffusion of Innovations) segments customers into five categories, separated by a critical chasm between the early market and the mainstream market.

Segment	Also Known As	Motivation	Tolerance for Imperfection	Buying Criteria
Innovators	Technology Enthusiasts	Love novelty and experimentation	High – tolerate bugs and instability	Cutting‑edge technology
Early Adopters	Visionaries	Seek competitive advantage, want to shape the market	Moderate – accept risk for strategic gain	Vision, influence, transformation
(CHASM)
Early Majority	Pragmatists	Want proven, reliable solutions	Low – demand proof and low risk	Productivity, ROI, peer ratings
Late Majority	Conservatives	Adopt when market standardises	Very low – require mature ecosystem	Price, ease of use, conformity
Laggards	Skeptics	Resist change; adopt only when unavoidable	None – must work as well as the old method	Necessity, ecosystem pressure

Key distinctions:

Innovators vs. Early Adopters: Innovators just love the new technology; early adopters buy into a vision and see strategic advantage.
Early Adopters vs. Early Majority: Early adopters accept bugs and incomplete ecosystems; early majority demand reliability, proof (e.g., customer reviews, crash statistics), and utility (e.g., “Kitna deta hai?” – fuel efficiency).
Late Majority: Wait until the product becomes the de facto standard (e.g., switching to a smartphone only when WhatsApp stops working on a feature phone). Price‑sensitive and want simplicity.
Laggards: Only move when old methods are no longer supported (e.g., obsolete car models with no spare parts).

The Chasm

The chasm is the gap between early adopters and the early majority. Crossing it is the most difficult transition for a startup. The early market product (built for visionaries) does not automatically serve pragmatists, who need a complete solution, proven reliability, and minimal risk.

Exam tip: Most startup failures occur at the chasm – they assume the early market product will attract the mainstream. Successful crossing requires tailoring the offer, positioning, and distribution to the pragmatic buyer’s needs.

Key Takeaways

A market = customers with a shared problem, similar purchasing power, and willingness to adopt.
Market expansion means moving to new customer segments with different contexts, behaviours, and ability to pay.
Moore’s Technology Adoption Lifecycle segments into innovators, early adopters, early majority, late majority, and laggards.
The chasm separates early adopters (visionaries) from the early majority (pragmatists).
Early majority demands reliability, proof, and low risk; late majority wants standardization and low price; laggards adopt only under compulsion.
Crossing the chasm requires a shift from selling a vision to selling a reliable, complete solution.

Crossing the Chasm

Crossing the Chasm (Geoffrey Moore) describes the difficult transition a high‑tech product must make from early adopters (visionaries who buy into the vision) to the mainstream market (pragmatists who want reliable, complete solutions). Early‑market success with an MVP does not guarantee mainstream adoption — a chasm of skepticism, risk aversion and missing infrastructure must be bridged.

The ten strategies

Strategy	Core idea	Example in transcript
Narrow beachhead market	Dominate one small segment before expanding; avoid “spray and pray”.	WhatsApp launched only on iOS in North America (2009) before expanding globally.
Simplify product for mainstream users	Remove complexity; add intuitive UX, onboarding, configuration.	ChatGPT created a chat interface so non‑programmers could use GPT.
Build trust & reliability	Mainstream users avoid risk — invest in uptime, security, compliance, support, social proof.	Aadhaar started small, built robust infrastructure, then scaled to 1 billion users.
Build ecosystems & integrations	Fit into existing workflows; don’t force users to change habits.	UPI used existing mobile phones and bank accounts — no new cards or devices.
Create social proof & network effects	Word‑of‑mouth, ratings, testimonials, creator ecosystems drive adoption.	Airbnb built strong referral and rating systems, partnering with Facebook.
Reduce adoption friction	Lower learning cost, migration effort, pricing risk, commitment barriers.	Jio offered free talk time, number portability, bundled data — minimal switching cost.
Whole product	Deliver a complete solution, not just a core technology.	Zoho provides SaaS (no hardware), Zerodha includes tutorials, API, compliance reports.
Localize for new markets	Adapt to local language, low bandwidth, identity systems, pricing.	WhatsApp added low‑bandwidth optimisation, phone‑number identity, multilingual support for India.
Shift from technology to outcome orientation	Mainstream customers want value — low cost, simplicity, time savings — not tech specs.	Zerodha won adoption not because it was online, but because it was low‑cost and frictionless.
Distribution advantage	Use partners, bundles, existing ecosystems to reach customers faster.	JioCinema leveraged Jio telecom bundles, mobile data, and IPL streaming to compete with Netflix.

How the strategies connect

flowchart LR
    A[Early Adopters] --> B{Chasm}
    B --> C[Beachhead]
    C --> D[Simplify & Trust]
    D --> E[Ecosystem & Whole Product]
    E --> F[Reduce Friction & Social Proof]
    F --> G[Localize & Distribute]
    G --> H[Mainstream Market]
    H --> I[Outcome Focus]

Exam tip: Crossing the chasm is not a single‑action event. Startups typically combine several strategies (e.g., Jio used friction reduction + distribution + bundling). The beachhead comes first; the others are applied as the product scales.

Key takeaways

The chasm is between early adopters (visionaries) and mainstream (pragmatists).
Start by dominating a narrow beachhead market.
Mainstream users need reliability, simplicity, integration, and social proof.
Reduce every barrier to adoption — cost, effort, learning.
A “whole product” (hardware + software + support + training) is often necessary.
Localise for new geographies; use distribution partners to scale.
Shift messaging from “what the technology does” to “what outcomes it delivers”.

1. Problem-Solution Fit (PSF)

Definition:
Problem-solution fit confirms that (1) a real problem exists for a specific customer segment and (2) an early solution (typically an MVP) provides recognisable value to at least a few users. It answers: Are we solving a painful, real problem?

Signals of PSF:

Strong interviews – customers articulate the problem and confirm its urgency.
Early prototype value recognition – users see the solution as helpful.
Repeated engagement – the same users return to use the product.
Manual alternative exists – the pain is already being addressed (even with a workaround), proving demand.

Example – Airbnb: The founders placed three air mattresses in their apartment, invited conference attendees, and charged $80. Guests paid and used the service → problem (expensive/bad accommodation) was real. This validated learning from a tiny segment.

Stage in the startup evolution:
PSF belongs to the Validation phase (after Discovery). The MVP is built with minimal cost/effort to test desirability and feasibility with early users.

2. Product-Market Fit (PMF)

Definition:
Product-market fit is achieved when the product satisfies strong market demand repeatedly and at scale. The solution now serves a larger market beyond the early adopters. It answers: Can this product scale sustainably across a broad market?

Signals of PMF:

Retention – users keep coming back.
Organic referrals – word-of-mouth drives new users.
Revenue traction – customers are willing to pay (and keep paying) for the product.
First adoption – a demand pool emerges naturally, reducing customer acquisition friction.

Core idea (Marc Andreessen):
“Being in a good market with a product that can satisfy the market” – the market is the dominant force. PMF is felt when customers buy as fast as you can produce, or usage grows as fast as you can add servers.

3. Comparing PSF and PMF

Dimension	Problem-Solution Fit	Product-Market Fit
Focus	Is the problem real and solvable?	Is the market large enough to scale?
Stage	MVP / Validation	Growth / Scaling
User base	Early adopters (curiosity-driven)	Mainstream market (pull-driven)
Proof	Qualitative (interviews, usage observations)	Quantitative (retention, revenue, organic growth)
Goal	Establish usefulness	Establish scalable demand
Key question	Will customer pay?	Is cost of customer acquisition smaller than price?

4. Key Frameworks

Value Hypothesis vs. Growth Hypothesis (Andy Rachleff – original coiner)

Value hypothesis (X-axis): The key assumption that a customer will find the product valuable.
Growth hypothesis (Y-axis): How to scale the number of customers attracted to the product.
Both must be satisfied to achieve PMF.

Crossing the Chasm (Geoffrey Moore)

flowchart LR
    A[Early Adopters] --> B{Chasm}
    B --> C[Mainstream Market]
    C --> D[Product-Market Fit]

The MVP serves early adopters, but PMF requires crossing the chasm to address the mainstream segment. The product and market must be fine-tuned together: adding features (“bells and whistles”) and finding the right customer segments.

Continuous Relevance

PMF is not a one-time arrival. Markets shift, competitors emerge, and customer needs evolve. The rule of relevance demands constant questioning:

Who is this product relevant for?
Degree of criticality?
How long will it be relevant?
What are alternatives and price points?
What could make it irrelevant?

Example – Peloton: Surged during COVID as home workouts became relevant, but lost momentum when gyms reopened and the market shifted.

Zoom evolved from a simple connectivity tool to a productivity platform by integrating AI features (note-taking, scheduling) – staying relevant.

5. The Continuous Journey: A 3D View

Think of PMF as a spiral over time:

X-axis: Customers / market segments
Y-axis: Value delivered to each segment
Z-axis: Time

Start with one small segment, deliver value, then expand to new segments with adjusted value propositions (channels, pricing, deployment models). Each iteration adds more market segments and more value. PMF is a repeated, dynamic process, not a finish line.

Key Takeaways

Problem-solution fit validates that a real problem exists and a minimal solution works for a few users.
Product-market fit validates that the solution scales to a large, sustainable market.
PSF relies on qualitative signals (interviews, repeated use); PMF requires quantitative traction (retention, revenue, organic growth).
PMF is not a permanent milestone – market shifts demand continuous relevance.
Crossing the chasm between early adopters and the mainstream market is critical for PMF.
Use the value hypothesis and growth hypothesis to frame both fits.

Services vs. Product Business Models

A professional services company and a product company operate under fundamentally different business models. Understanding this distinction is critical for startups transitioning from services to products.

Dimension	Service Company	Product Company
Core activity	Hire engineers, execute customer projects	Develop a standard product for many customers
Primary metric	Utilization rate (percentage of engineer time billed to clients)	Not applicable; developers work on the standard product, not custom projects
Revenue driver	Daily rate × utilization	Product sales (licenses, subscriptions)
Trap	Using utilization rate to manage a product business kills it – developers must focus on the product, not custom work

Exam tip: The single biggest mistake a services firm makes when launching a product is continuing to use utilization rate as a key metric. It forces developers onto customer projects instead of building the product.

Key takeaways

Services: simple two-parameter business (utilization rate, daily rate).
Products: require a different mindset – invest in a standard solution, not project-by-project.
Startups with a services heritage must consciously shift metrics and culture.

ISPMA Framework: Startups vs. Mature Companies

The ISPMA (International Software Product Management Association) framework applies to both mature and startup companies, but the focus differs sharply in early stages.

Mature companies:

Running business is stable.
Emphasis on maintaining existing products, incremental improvements.
Occasional new product launches.

Startups – the three-stage validation process:

Desirability – What is the customer problem?
- Identify the core problem to solve.
Problem-Solution Fit – Is it feasible?
- Can your solution actually address the problem?
- Validate technically and with users.
Product-Market Fit – Is it viable?
- Business viability: can this become a sustainable business?

flowchart LR
    A[Customer Problem] --> B[Problem-Solution Fit]
    B --> C[Product-Market Fit]
    C --> D[Scalable Business]

Startup is an experiment to validate the business model – iterative learning loops are essential.

Key takeaways

Early-stage startups must focus on desirability, then feasibility, then viability – in that order.
Mature companies focus on sustaining existing revenue; startups focus on discovering a repeatable business model.
Problem-Solution Fit must be achieved before pursuing Product-Market Fit.

Product Strategy Challenges

Product strategy is often neglected or done poorly in both startups and mature companies.

Common reasons:

Mature companies: Product managers are positioned as execution-focused (planning, development interface) – no time or authority for strategy.
Startups: Founders want to own strategy but are overwhelmed with finance, management, sales, etc. They neither delegate nor fully focus.

Exam tip: In startups, the “action imperative” (jump to prototyping and selling) often overrides strategic thinking. Strategy must be given dedicated attention – or delegated.

Key takeaways

Product strategy requires dedicated time and clear ownership.
In startups, founders must either carve out time or appoint a strategy-focused role.

Competitive Advantage and Moats for Startups

Startups compete against “600-pound gorillas” but have one powerful edge: innovation.

Large corporations excel at protecting existing business but struggle with disruptive innovation (predictable revenue focus conflicts with radical ideas).
Startups can innovate faster and more freely.
The challenge is building moats – durable competitive advantages that can be defended.

How big tech responds:

Acquire innovative startups (paying founders well) – but integration often fails.
Long-term independence is rare because acquisition temptation is strong.

Key takeaways

Innovation is the startup's primary weapon; big companies are structurally weak at it.
Moats (patents, network effects, data, brand) must be built quickly.
Acquisition is a likely exit path – plan accordingly, but be aware of integration risks.

Pricing Pitfalls

Many startups underprice their products, creating long-term problems.

Common mistake:

Enter a market with a low price to compensate for product deficiencies.
Once a low price is set, raising it later is extremely difficult – customers protest.

Real example: AI companies

Started with fixed-price models.
Realized costs (computing) were much higher than expected.
Tried switching to token-based (cost-based) models → heavy users saw huge price increases → backlash.
Lesson: Starting too low creates a trap.

The North Star: Clarity on the value to the customer should drive pricing, not fear of competition.

Key takeaways

Never price based on your deficiencies – price based on value delivered.
It's easier to lower a high price than to raise a low one.
Understand your cost structure before setting prices, especially with AI products.

AI and Software Product Management

AI changes product management in two dimensions: tools for product managers and managing AI-based products.

1. AI tools for PM productivity

Can increase efficiency in many tasks (analytics, content generation).
But: AI hallucinates – outputs are not reliable.
Product managers remain accountable; they must apply human judgment.
Education should focus more on developing judgment skills, not just tool usage.

2. Managing AI-based products

Traditional functional specs / requirements documents are insufficient.
Products rely on a learning process based on data.
New challenges:
- Ensuring data availability for the learning loop.
- Compliance with privacy and legal requirements.
- Collaborating with data scientists to prepare data for AI engines.
The product manager's role shifts from specifying features to curating data and overseeing an iterative learning process.

Key takeaways

AI boosts productivity but requires human oversight – judgment is the critical skill.
For AI products, data governance and privacy become core PM responsibilities.
The learning loop in AI products mirrors startup iteration – continuous adaptation.

Final Message: The Primacy of Human Judgment

Fear of job loss due to AI is overblown – the industry is overreacting.
Three key points for students:
1. Master AI technology – be able to work with it.
2. Develop judgment – the ability to evaluate AI outputs critically.
3. Be above the algorithm, not below – manage the technology, don't let it manage you.
As Paul Choudary (ISPMA fellow) says: "You are either below or above the algorithm."

Key takeaways

Human judgment remains indispensable; AI is a tool, not a replacement.
Education must emphasize critical thinking and accountability.
Positioning yourself as the decision-maker who validates AI outputs guarantees your career value.

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:

Parties – a supplier (person or legal entity) and a customer/consumer.
Value – the offering is useful; that is, it provides some benefit (even if no money changes hands).
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.
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

Attribute	Physical Product	Software Product
Tangibility	Tangible (you can touch it)	Intangible (can't touch the software itself)
Marginal cost	High – each unit requires raw material, manufacturing, labour, logistics	Near zero – serving one more user costs almost nothing (just a download)
Iteration speed	Slow – retooling the assembly line needed for any change	Fast – upgrades can be shipped overnight
Distribution	Requires warehouse, shipping, physical retail	No logistics or shelf life – delivered via app stores or cloud
Feedback loop	Slow – manufacturers rely on surveys, complaints, or warranty claims	Near real-time (especially cloud) – usage data available instantly
Risk of irreversibility	High – committed cost cannot be recovered easily	Low – can fix, upgrade, or revise after release

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. (The lecture does not give a concrete example but implies products where software is central yet still part 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.

Example	Products in the family
Google	Search, Maps, Photos, Cloud, Meet, Drive
Microsoft Office 365	Word, Excel, PowerPoint, Outlook

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):

Innovation platform – a technological foundation that developers use to build their own products.
Example: Amazon Web Services (AWS) – startups build applications on AWS infrastructure.
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.

Example	Platform	Product Lines
Amazon	Single code base (underlying platform)	amazon.in, amazon.de, amazon.fr – same look and feel but different features per country
Android	Open-source Android OS	Variants by different phone brands (Samsung One UI, Xiaomi MIUI)
Automobiles	Same engine, braking, chassis	Sedan, hatchback, estate

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

How the three relate:

graph TD
    A[Product Family] -->|shared brand & marketing| B[Google, Microsoft Office]
    C[Product Platform] -->|shared technology / components| D[AWS, Android]
    D -->|produces variants| E[Product Lines]
    E --> F[Amazon country sites, Android phone variants]

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.

timeline
    title Evolution of Product Management
    1900s : Product era (Ford) : Engineering excellence, scale, standardization
    1930s : Marketing era (P&G) : Customer segmentation, branding, 4Ps
    1960s–1990s : Software era (IBM, Microsoft) : Features, UX, iterative delivery
    2000s : Platform era (Amazon, Uber) : Ecosystems, network effects, product–market fit
    Today : Intelligent era (Tesla, da Vinci 5) : AI, phygital, cyber-physical systems

Era	Key Focus	Representative Company	Core Concepts
Product era (early 1900s)	Manufacturing at scale, efficiency, standardization	Ford (“any color as long as it’s black”)	Production, engineering, quality
Marketing era (1930–31)	Brand management, customer segmentation, positioning	Procter & Gamble	4Ps (product, price, place, promotion); product manager as mini-CEO
Software era (late 1960s–1990s)	Develop features, deliver user experience, iterate rapidly	IBM, Microsoft (MS-DOS, Windows)	SDLC, agile, lean startup; shrink-wrapped software
Platform era (2000s–2010s)	Multi-sided ecosystems, network effects, scale	Amazon, Uber	Product–market fit, ecosystem partners, business value at scale
Intelligent era (present)	AI, digital-physical integration, systems thinking	Tesla, da Vinci 5	Phygital products, cyber-physical systems, autonomous decision-making

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.

Pillar	Question	Skill Required
Desirability	Do customers actually need or want this product?	Design / empathy
Feasibility	Can we build it with current technology and capabilities?	Engineering
Viability	Can we make a profit — are the unit economics sustainable?	Business

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

Attribute	Description
Extreme uncertainty	Unclear markets, customers, funding, team availability, and technology viability
Temporary structure	Not meant to last as-is; success leads to transformation into a mature company
Experimentation	Decisions are hypotheses to be tested; failure is data, not final
Resource constraints	Limited money, people, and time (especially in bootstrapped phases)
High dependency on ecosystem	Must rely on partners for storage, compute, market access, etc.

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

Dimension	Bootstrapped	Funded	Corporate Venture
Source of funds	Founders	External investors	Parent corporation
Resource availability	Low	High	High
Time pressure	Low (self-paced)	High (investor exit timeline)	Moderate (parent’s strategic cycle)
Flexibility	Maximum	Limited (investor control)	Limited (parent alignment)
Example	Zoho	Flipkart, Paytm	Jio

Experimentation in Action: Instagram’s Pivot

The lecture uses Instagram 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

flowchart TD
  A[Startup] --> B[Extreme Uncertainty]
  A --> C[Temporary Organization]
  A --> D[Experimentation]
  B --> E[Need to validate business model quickly]
  D --> F[Iterate or Pivot]
  C --> G[Types of startup chosen]
  G --> H[Bootstrapped]
  G --> I[Funded]
  G --> J[Corporate Venture]
  H --> K[Frugal innovation, high flexibility]
  I --> L[Rapid scale, time pressure]
  J --> M[Market access, parent alignment]

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.

flowchart LR
    A[Spot the customer problem] --> B[Observe / survey large sample]
    B --> C[Identify patterns]
    C --> D[Study the alternatives]
    D --> E[Conclude: Is the problem real & unsolved?]

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):

What is the pressing unmet need?
Who has this problem, and how does it manifest across segments?
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.

Key principle	Why it matters
Minimise time, cost, effort	Speed and learning, not perfection
Choose pilot customers who really need the product	Friends/family may say “yes” but never use it — pick those with a felt need
Build just enough to test	A working experiment, not an automated, scalable system

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:

A clear, unambiguous target customer — you know their attributes, problem, patterns, and alternatives.
Clarity of the problem — exactly what are you solving?
An MVP that works for those customers.
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.

flowchart LR
    A[Discovery<br>(Desirability focus)] --> B[Build Core Product<br>Step 4]
    B --> C[Validate Core Product<br>Step 5]
    C --> D[Sharpen Core Product<br>Step 6]
    D --> E[Problem-Solution Fit]

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:

Dimension	Core Question	What It Means	Real-World Example
Value	Does it solve a real problem in a simple, relatable way?	Customer–centric: solves pain, drives adoption & retention. Benefit must be clear at first use.	WhatsApp replaced complex sign‑ups (Skype) with a phone‑number‑only model, delivering instant value.
Scalability	Can it serve millions/billions without breakdown?	Robust architecture, performance, ecosystem integration. Growth of adoption without failure.	UPI scaled from a few banks to handling billions of transactions/month across payment gateways, devices, and banking systems.
Sustainability	Can it endure environmentally, socially, and economically?	Environmental (e.g., energy use), social (across demographics), and economic (value for business and ecosystem partners).	Microsoft Office sustains by improving user productivity, co‑existing across OS, and enabling collaboration (Teams) with reasonable energy consumption.
Responsibility	Is it ethical, trustworthy, safe, and privacy‑respecting?	No dark patterns, data privacy, transparency, non‑addictive design, informed defaults. Trust is a strategic asset.	Aadhaar (India’s digital identity) is simple yet profoundly responsible — it has no dark patterns, is trustworthy, and protects privacy.
Profitability / Impact	Can it generate revenue (commercial) or social value (societal platform)?	Sustained value per user and collectively. Without profitability/impact, the product vanishes.	WhatsApp is commercial; Aadhaar is a societal platform. Both must demonstrate sustained value to survive.

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

Environmental — minimize negative impact (e.g., avoid fossil fuels).
Social — work across demographics and sustain social cohesion.
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

flowchart LR
    A[Value] --> B[Scalability]
    B --> C[Sustainability]
    C --> D[Responsibility]
    D --> E[Profitability / Impact]
    E -.-> A

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:

Job Type	Description	Example (UPI payment)
Functional	The practical task to be done	Transfer ₹46 to an auto driver
Emotional	How the user wants to feel	Relieved, not anxious about non‑payment
Social	How the user wants to be perceived	Not embarrassed by inability to pay after dinner

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

The transcript outlines a step‑by‑step interview approach using a recent payment scenario (e.g., a small UPI‑like payment). Below is the logic flow:

flowchart TD
  A[Identify a recent, specific event] --> B[Probe the trigger & context]
  B --> C[Alternatives considered & why chosen]
  C --> D[Frustrations & trade‑offs]
  D --> E[Satisfaction with outcome?]
  E --> F[Summarize the JTBD statement]

Sample interview questions (from the UPI example):

Trigger event: “Tell me about the last time you paid a small amount (₹46 for a rickshaw).”
Context: “What caused that payment? Did the driver lack change?”
Options considered: “Did you think of cash, card, cheque? Which ones and why?”
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.
What nearly stopped you? “Did any of these issues almost make you avoid the transaction?”
Trade‑offs made: “What did you sacrifice? (e.g., small change, privacy, time)”
Satisfaction: “Were you relieved when the payment went through? How?”
Importance: “How important is it to have a certain, easy payment method?”
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

Alternative	Cost (time, effort, risk)	Benefit	Gap (unsatisfied job)
Cash	Finding change; carrying exact amount	Universal acceptance	Effort of finding change; risk of not having enough
Card	Remember PIN; swipe machine needed; data risk	Secure for large amounts	Not always accepted on street; anxiety about PIN failure
Cheque	Slow; not accepted for small amounts	Record‑keeping	High effort; not used in daily small payments
UPI (ideal)	Almost zero friction	No change; no details shared; always works	–

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.