Intuition

Phase 2 has a single instruction: stop loving your solution; start interrogating the problem. Uri Levine's Tree puts it visually — Problem is the root, Solution is the trunk, Product is the leaves. Weak root → tree falls. Phase 2 is two halves: (1) Define the problem at Level 3 precision using the 5Ws (with Why as the keystone) and map every stakeholder around it; (2) Prove the problem is worth solving via Magnitude × Frequency × Population — the Painkiller test. Then before you graduate to Phase 3, you talk to real customers with surveys that don't contaminate their answers (past behaviour, quantified pain, no leading questions).

Explanation

Levine's Law (Uri Levine, founder of Waze). *Fall in love with the problem, not the solution.* Founders default to falling in love with the solution because that's the part they built — but a beautiful solution to a fake problem dies; a competent solution to a real problem can iterate its way to PMF.

The Tree diagram. *Product* = leaves and branches (what the world sees). *Solution* = the trunk. *Problem* = the roots. If the root is weak, the tree falls — no amount of pretty leaves saves it. Reproduce this on the exam in two seconds. Roots → trunk → branches → leaves. Bottom to top.

Three levels of problem statements (memorise the ladder). *Level 1 — Vague Observation:* 'People need healthy food.' Says nothing about who, why, how urgent. Untrained founders write at this level. *Level 2 — End-User Perspective:* 'I am a busy professional, I don't have time to grocery shop, this makes me feel upset.' Better — captures emotion in first person — but anecdotal, not generalisable. *Level 3 — 4Ws + When Perspective:* 'Our busy working professional is struggling to eat healthy food during the week as she is consistently working long hours. Our solution needs to deliver a quick and convenient way to purchase healthy food.' Three handles: Who (specific role), Context (when/where), Emotional/Functional Deficit (what they lack). This is the form your professor wants. On the exam, name the level you're writing at and structure the statement against the three handles.

5Ws Framework (Anatomy of a Problem). Five questions, five answers, with Why highlighted as the keystone. (1) Who — who are the stakeholders affected? Not just users; everyone in the orbit. (2) What — current state vs desired state. *The gap is the unmet need.* (Memorise that phrasing.) (3) When — timeframe and frequency. Once-a-year is a different business from once-a-day. (4) Where — location, department, region. Geography shapes the problem (a Tier-1 Indian home is not an American suburb). (5) Why — the Critical Gap. Why is this problem worth solving? What is the magnitude?

Why is the keystone. Why answers the question every investor asks at the end of every conversation: *so what?* If you can't answer Why, the other four Ws don't save you. On the exam, when applying the 5Ws to any scenario, treat Why as the centre of gravity — write the longest answer for Why, support the others around it.

Worked 5Ws walkthrough. Vague version: 'people waste electricity.' Through the 5Ws: Who — Indian middle-class homeowners in Tier-1 cities. What — current state is purifiers cycling 24/7 because they're tuned for worst-case water quality; desired state is purifiers that adapt to actual usage. When — every day, every minute the purifier runs. Where — apartment kitchens where the purifier sits permanently on. Why — ₹2,000–4,000 of avoidable monthly electricity per household, × tens of millions of households = a measurable economic loss the family feels in the bill. That last sentence is the Why-answer that earns marks.

Beyond the End User — the Stakeholder Ecosystem (seven roles). Critical trap your professor disarms: *the end user is not always the buyer; the buyer is not always the decision maker.* This matters disproportionately in B2B and any organisational purchase. The seven orbiting roles: (1) Decision Maker — final authority to approve or kill. (2) Influencer — shapes the decision without authority (advisors, analysts, internal champions). (3) Buyer — owns procurement, signs the contract. (4) Manager — supervises the people who will use it. (5) Operator / End User — actually uses the product day-to-day. (6) Evaluator — assesses fit before purchase (technical reviewer or pilot lead). (7) CFO — owns the budget; gatekeeper for spend.

Salesforce stakeholder example. Rep = User. VP of Sales = Buyer. CFO = Decision Maker. The rep loves the product, the VP signs the contract, the CFO decides whether the company even buys. *If your problem statement names only the rep struggling, you've defined the wrong customer.* The exam-grade synthesis: for each of the seven roles, write a separate version of the problem statement. Different stakeholders feel different versions of the same problem; a complete Phase 2 analysis names all of them.

The Implications Triad — proving the problem is worth solving. Defining is half the work; proving it's big enough to be a business is the other half. Three questions, name each explicitly on the exam.

Implication 1 — Magnitude (How big?). Consequences question. What happens if you don't solve it? Death, financial loss, lost time, lost productivity, lost happiness — quantified. Slides example: PM 2.5 air pollution in China → premature mortalities + 20,035 gigagrams of lost crop production = 267 billion Yuan total economic impact. The exam-grade move: not 'people are annoyed' but '₹X crore of lost output.' Numbers, not adjectives.

Implication 2 — Frequency (How often?). Recurrence question. Daily problem = recurring revenue opportunity. Once-a-year = transactional at best. Slides example: nine recurring retail operations (daily store opening checklist, daily store closing checklist, weekly visual merchandising audit, customer feedback, mystery shopper audit, store operations audit, store visit report, temperature log, restaurant operations audit) — each is a chance to embed software into routine work. High frequency = high stickiness = recurring revenue.

Implication 3 — Population (How many?). Scale question. Magnitude per person matters less if only fifty people face it. Slides example for heart disease: 1 million people will have a heart attack this year (Magnitude); 103 million adults have high BP (Frequency / Prevalence); 38% rise in high BP deaths (Trend).

The Painkiller equation (memorise verbatim). $\boxed{\text{High Frequency}+\text{High Magnitude}=\text{Urgent Problem (Painkiller)}}$. A Painkiller is something people pay for now to stop pain. A Vitamin is something nice-to-have that they might buy when they remember. Investors fund painkillers. Vitamins struggle to extract revenue. If your problem scores low on either Magnitude or Frequency, you're selling a vitamin — and you must either reframe to find its painkiller dimension or kill the idea.

The Phase 2 → Phase 3 bridge — validating the problem with real customers. Every number you've written is *your hypothesis*. Before you graduate to Phase 3, three discipline-setting slides handle survey design without contaminating the data.

Survey design — three rules. (1) Avoid leading questions. Not 'Do you like our idea?' — that question bakes in the answer. (2) Focus on past behaviour. Not 'Would you use a service like this?' but 'When was the last time you did X?' People mispredict future behaviour but accurately report past behaviour. (3) Quantify the pain. Not 'Is this a problem?' but 'How much time did you lose?' Numbers force honesty. Slide-summary line to quote: Bias is the enemy of validation.

The Bias Trap (canonical contrast). ❌ Bad: 'Would you pay for software that helps store managers?' (Hypothetical, leading.) ✅ Good: 'How many hours a week do your store managers currently spend on manual reporting?' (Factual, quantifiable.) Every survey question can be critiqued through this binary. On the exam, when asked to evaluate a survey item, name the bias trap, name the past-behaviour fix, quote the rule.

Validate Your Problem — assignment workflow. Design a Survey (with the three rules) → Define Target Audience (your Who from the 5Ws) → Execute (collect ≥ 20 responses) → Synthesize (summarise results, update your pitch). Closing principle of the slide: Your opinion doesn't matter. Only the customer's data does.

Phase 2 pipeline. Define problem (Phrasing Levels → 5Ws → Stakeholder Ecosystem with all 7 roles) → Quantify implications (Magnitude × Frequency × Population = Painkiller test) → Validate with customers (bias-free survey using past-behaviour + quantified-pain questions) → exit with a validated problem statement + implications.

What the exam tests on Unit 2. (a) Levine's Tree — draw and explain. (b) Rewrite a Level-1 problem statement at Level 3 using the 4Ws+When structure. (c) Apply the 5Ws to a scenario and identify Why as the keystone. (d) For a B2B scenario, name all 7 stakeholder roles and identify which is Decision Maker vs Buyer vs User. (e) Apply Magnitude × Frequency × Population and judge Painkiller vs Vitamin. (f) Critique a leading / hypothetical survey question and rewrite it past-behaviour and quantifiable. (g) Design a complete validation workflow (survey + target + sample size + synthesis).

Definitions

• Levine's Law — Fall in love with the problem, not the solution. The discipline of Phase 2.
• Levine's Tree — Problem (roots) → Solution (trunk) → Product (leaves). Weak roots mean the tree falls.
• Problem Statement Levels — L1 vague observation → L2 end-user perspective → L3 = Who + Context + Deficit (4Ws + When). L3 is the form the professor wants.
• 5Ws Framework — Who, What, When, Where, Why. Why is the keystone.
• Critical Gap (Why) — The magnitude-of-consequence answer. What happens if the problem isn't solved? Quantified, not adjectival.
• Stakeholder Ecosystem — The seven roles orbiting any organisational purchase. End user ≠ buyer ≠ decision maker.
• Decision Maker — Final authority to approve or kill the purchase.
• Influencer — Shapes the decision without holding authority. Advisors, analysts, internal champions.
• Buyer — Owns procurement and signs the contract. Not necessarily the user or decision maker.
• Operator / End User — Person actually using the product day-to-day.
• Evaluator — Assesses fit before purchase — technical reviewer, pilot lead, security/compliance gatekeeper.
• CFO (in stakeholder mapping) — Owns the budget; gatekeeper for spend. Final-step approver of any committed cost.
• Implications Triad — Magnitude × Frequency × Population. Three dimensions for proving a problem is worth solving.
• Magnitude — Consequence per occurrence — quantified financial / health / time cost. 'How big is this problem?'
• Frequency — Occurrences per period (per person). 'How often is this problem faced?' High frequency → recurring revenue.
• Population — Number of people facing the problem. 'How many are facing this problem?' Drives TAM upper bound.
• Painkiller — High Magnitude × High Frequency. Investors fund painkillers. Customers pay *now*.
• Vitamin — Low Magnitude or Low Frequency. Nice-to-have. Investors don't fund them; revenue extraction is hard.
• Total Addressable Pain (TAP) — Magnitude × Frequency × Population aggregated. The economic case for the problem.
• Bias-Trap — The canonical leading/hypothetical-vs-factual/quantifiable contrast in survey design. Bias is the enemy of validation.
• Past-Behaviour Question — Asks 'when did you last…?' rather than 'would you…?'. Retrieves from memory, predicts conversion. Replaces hypothetical-future questions.
• Validation Workflow — Survey → Define Target (= Who from 5Ws) → Execute (≥ 20 responses) → Synthesise (update pitch). Closing principle: customer data, not founder opinion.

Formulas

• $$\text{Painkiller}=\text{High Magnitude}\times \text{High Frequency}$$
• $$\text{Vitamin}=\text{Low Magnitude}\text{ OR }\text{Low Frequency}$$
• $$\text{Problem Statement (Level 3)}=\text{Who}+\text{Context (When/Where)}+\text{Emotional/Functional Deficit}$$
• $$\text{Total problem value}=\text{Magnitude per person}\times \text{Frequency per year}\times \text{Population}$$
• $$\text{Survey integrity}=\text{Past Behaviour}+\text{Quantified Pain}-\text{Leading Questions}$$

Derivations

Why Why is the keystone among the 5Ws. Who/What/When/Where are descriptive — they fill out the *shape* of the problem. Why is normative — it answers *should anyone care?* An investor reading a problem statement asks 'so what?' at the end. If Why is weak (vague or unquantified), the other four Ws don't compensate, because no amount of crisp Who/What/When/Where rescues 'and nothing important happens if this isn't solved.' Conversely, a crisp Why ('267 billion Yuan/year lost') makes a thin Who/What/When/Where forgivable because the magnitude alone justifies investigation. Hence Why carries asymmetric weight — it is the keystone that holds the arch.

Why Painkiller = High Magnitude × High Frequency (and not just one or the other). Consider four cases on a 2×2 of Magnitude × Frequency. (a) High M, Low F: rare catastrophic event (earthquake insurance for a building) — people pay, but transactional revenue and slow growth. (b) Low M, High F: tiny daily irritation (slow elevator) — high frequency, but the individual cost is too low to justify dedicated spend; people tolerate rather than buy. (c) Low M, Low F: vitamin territory. (d) High M, High F: painkiller — people pay *now*, *recurrently*, because the cost of not solving compounds daily. Only case (d) supports a venture-scale recurring-revenue business. Hence the product structure: investors fund (d), not (a/b/c).

Why past-behaviour beats hypothetical-future questions. Humans systematically mispredict future behaviour — the *intention-action gap*. People who say 'I would definitely use this service' adopt it at 10-30% of the rate they predicted. People asked 'when did you last do X?' answer accurately because retrieval is from memory, not simulation. Survey designers who ask hypothetical questions get false positives that look like validation but vanish on launch. Surveys that ask past behaviour get a smaller but predictive signal. Hence the rule: bias is the enemy of validation.

Examples

• Levine's Tree applied. Product = Waze app. Solution = community-sourced real-time traffic routing. Problem = drivers stuck in unpredictable traffic without knowing alternative routes. Without the strong problem-root, Waze is just another map. With it, the entire community-routing mechanism makes sense.
• Level 1 → Level 3 rewrite. Level 1: 'People waste food.' Level 3: 'Indian Tier-1 urban households with two working parents discard 25-30% of their weekly grocery purchases because they over-buy on weekends and lack time to plan meals during the week. The solution must provide quick weekday meal-planning and adaptive grocery suggestions to cut household food waste.' Who + context (Indian Tier-1, two working parents, weekly cycle) + deficit (over-buy, no time, food waste).
• 5Ws applied to e-waste. Who: urban Indian middle-class households + small electronics retailers. What: current state — devices end up in landfills or grey-market dismantling; desired state — safe disposal with recoverable-material credit. When: every 2-3 years per device (smartphone) + continuous for retailers. Where: Tier-1/2 Indian cities. Why (keystone): 1.7 million tonnes of Indian e-waste annually; 95% processed informally with health and environmental damage; ₹15,000 cr of recoverable materials lost per year.
• Stakeholder Ecosystem for B2B SaaS (HR analytics tool). End User = HR analyst. Manager = Director of HR. Evaluator = IT compliance / security review team. Buyer = procurement. Decision Maker = CHRO or VP People. Influencer = peer CHROs / Gartner analysts. CFO = approves the budget line. The problem statement is different for each: the HR analyst struggles with hours of manual reporting; the CHRO struggles with delayed insights affecting board reporting; the CFO struggles with bloated tooling spend. A complete Phase 2 analysis writes seven statements, not one.
• Painkiller test on three scenarios. (a) Last-mile cold-chain visibility for vaccine distributors — High M (vaccine spoilage = lives + crores), High F (every shipment) → Painkiller. (b) Curated-recipe weekly newsletter — Low M (recipe boredom isn't painful), Low F (interest is occasional) → Vitamin. (c) Earthquake-resistant retrofit for buildings — High M (lives), Low F (rare earthquakes) → transactional, not recurring revenue (case a in the derivation 2×2).
• Magnitude calculation worked. Avoidable purifier electricity per household: ₹2,500/month average. Annual: ₹30,000. Population (Tier-1 Indian households with purifiers): ~50M. Total magnitude: 50M × ₹30,000 = ₹1.5 lakh crore/year of avoidable household electricity spend. Total Addressable Pain (TAP). A founder citing this number does more work than five paragraphs of qualitative argument.
• Survey question Bias-Trap critique. Question: 'Would you switch to an energy-efficient purifier if it saved you ₹2,000/month?' → ❌ Leading (suggests the answer), hypothetical (future behaviour), implicit framing of the value prop. Rewrite: 'In the last 12 months, what is the highest amount your household electricity bill reached? Roughly what % of that was driven by the water purifier?' → ✅ Past behaviour, quantifiable, no suggestion.
• Validation workflow concrete. Survey 25 Tier-1 households via 20-min phone interviews. Target audience: families with installed RO purifier ≥ 2 years old, monthly electricity bill ≥ ₹3,500. Questions: (1) When was the last time you checked your monthly electricity bill itemisation? (2) What's the highest your bill has gone in the last year? (3) How many hours/day does your purifier run? (4) Have you ever taken steps to reduce purifier electricity? Synthesise: how many independently flagged purifier cost as top-3 monthly concern? That count is the validation signal.

Diagrams

• Levine's Tree: vertical tree drawing. Roots at the bottom labelled Problem. Trunk labelled Solution. Leaves at the top labelled Product. Weak roots → cracked trunk → falling leaves (alternate label: 'tree falls').
• 5Ws spoke: central hub labelled 'Problem' with five spokes radiating outward: Who, What, When, Where, Why. Why is drawn in a different colour and longer to mark its keystone status.
• Stakeholder Ecosystem orbit: organisation in the centre; seven labelled satellites around it (Decision Maker, Influencer, Buyer, Manager, Operator/User, Evaluator, CFO). Lines connecting roles that typically interact (Buyer ↔ CFO, Operator ↔ Manager).
• Implications Triad funnel: top — Magnitude (consequence per occurrence), middle — Frequency (occurrences per period), bottom — Population (people affected). Multiplied together = Total Addressable Pain (TAP).
• Painkiller vs Vitamin 2×2: Magnitude (axis) × Frequency (axis). Top-right quadrant (high M × high F) is Painkiller — investor sweet spot. Other three quadrants labelled — Vitamin / Transactional / Tolerated.
• Bias-Trap binary contrast: two boxes side by side. ❌ left = leading + hypothetical. ✅ right = past-behaviour + quantifiable. Arrow between them with the rule 'Bias is the enemy of validation.'

Edge cases

• Beautiful Level-3 statement, weak Why. Possible to write a precise Who/What/When/Where while still having a thin Why. The exam catches this — strong Why is non-negotiable.
• Single-stakeholder problem statement in B2B. A common student error — writing only the operator's pain. B2B sales fail because the Buyer / CFO / Decision Maker felt no pain. Map all 7 roles.
• High frequency, low magnitude. Daily small irritation isn't a painkiller — people tolerate it. Many app ideas fail here.
• High magnitude, low frequency. Rare catastrophic event = transactional product, not recurring-revenue startup. Insurance is the classic example — viable as a business, but with a fundamentally different economics from SaaS.
• Survey responses ≠ purchase behaviour. Even with past-behaviour questions, declared interest is 2-3× higher than actual conversion. Discount the survey signal by 50-70% in your projections.
• Population × Magnitude × Frequency triple-counting. Don't multiply across overlapping populations or double-count (e.g., per-incident magnitude for a population that experiences multiple incidents/year — multiply by frequency, not population alone).
• Stakeholders with veto-only power. Some stakeholders can't approve but can block (Security, Legal, Compliance). Treat them as Influencers with veto authority — addressing their concerns matters even if they never sign the contract.

Common mistakes

• Writing problem statements at Level 1 ('people need X') and stopping. Always push to Level 3.
• Forgetting Why is the keystone — distributing equal effort across all 5Ws.
• Naming only the End User in the stakeholder analysis (mistake especially in B2B).
• Qualitative argument instead of quantitative magnitude. 'Big problem' loses marks; '₹1.5 lakh crore/year' earns them.
• Confusing Frequency with Population. Frequency = how often per person. Population = how many people.
• Calling a vitamin a painkiller because the founder *wants* it to be one. Honesty about Magnitude × Frequency is the test.
• Asking leading or hypothetical questions in validation surveys, then citing the responses as proof.
• Treating Phase 2 as a quick step before 'real' work. Phase 2 is where 35% of startups die — it deserves the most rigour.
• Pitching the *solution* in customer interviews. Phase 2 is detective work on the *problem*; the solution comes in Phase 3 customer development.

Shortcuts

• Levine's Tree: Problem (root) → Solution (trunk) → Product (leaves). Weak root = falling tree.
• Problem-statement levels: L1 vague → L2 end-user → L3 = 4Ws + When.
• 5Ws: Who, What, When, Where, Why (keystone).
• Seven stakeholders: Decision Maker, Influencer, Buyer, Manager, Operator, Evaluator, CFO.
• Painkiller equation: High Magnitude × High Frequency.
• Total Addressable Pain: Magnitude per person × Frequency per period × Population.
• Survey design: Past Behaviour + Quantified Pain − Leading Questions.
• Validation workflow: Survey → Target → Execute (≥ 20 responses) → Synthesise.
• Closing principle: Your opinion doesn't matter. Only the customer's data does.

Proofs / Algorithms

Three-handle decomposition of Level 3 problem statements. Any Level-3 statement S can be parsed into three orthogonal handles: $H_1$ = Who (the specific role), $H_2$ = Context (the When/Where conjunction that grounds the problem in space and time), $H_3$ = Deficit (the emotional or functional gap). Removing any one yields a non-Level-3 statement: drop $H_1$ → vague observation (Level 1); drop $H_2$ → universal claim without grounding (effectively Level 2); drop $H_3$ → description without pain (no actionable solution). All three are jointly necessary. The 5Ws framework is the operationalisation of $H_1$ ↔ Who, $H_2$ ↔ When + Where, $H_3$ ↔ What + Why. QED.