Defining the Problem, Quantifying Implications, Bias-Free Validation
Arjun Falls in Love with the Wrong Thing
Two weeks after Lecture 1, Arjun has the retrofit-kit hypothesis from Phase 1 on a whiteboard in his hostel room, and a draft of his architecture diagram: ESP32 microcontroller, current-sense module, ML model on the device, BLE pairing with a phone app. He's spent four nights designing the firmware abstractions. Priya walks in, looks at the whiteboard, and asks:
*"So what's the problem you're solving?"*
He stares at her. He has answers — efficiency, electricity bills, environmental impact — but they slide off the question like water off a leaf. He realises he has spent two weeks loving his solution without ever interrogating the problem.
The next morning, in Lecture 4, Prof. Loganathan opens with the slide that fixes this. It has one sentence on it, attributed to Uri Levine, the founder of Waze:
*Fall in love with the problem, not the solution.*
Under it is a hand-drawn tree. Roots labelled 'Problem.' Trunk labelled 'Solution.' Branches and leaves labelled 'Product.' The prof says quietly: *if the root is weak, the tree falls. No amount of pretty leaves saves it.*
Arjun copies the tree. Then he draws a small arrow from the trunk to the roots and writes: *I went straight to trunk-decoration. I never inspected the roots.*
---
Three Ways to Write the Same Problem
The next slide is *Phrasing the Problem: From Observation to Definition.* A three-level ladder.
Level 1 — The Vague Observation. 'People waste electricity on water purifiers.' Says nothing about who, why, how urgent. *Untrained founders write at this level.*
Level 2 — End-User Perspective. 'I am a middle-class homeowner in Bangalore. My purifier runs all the time even when I'm not using it. This frustrates me when the bill arrives.' Better — captures emotion in first person. But anecdotal, not generalisable.
Level 3 — The 4Ws + When Perspective. *Our Indian middle-class homeowner in a Tier-1 city is paying ₹2,000-4,000/month in avoidable purifier electricity because the appliance is tuned for worst-case water quality and cycles 24/7 regardless of actual usage. Our solution needs to deliver adaptive cycling that learns household patterns without compromising water safety.*
Three handles: Who (specific role), Context (when, where), Deficit (emotional / functional gap). The professor's takeaway: this is the form he wants on the exam. Specific. Quantified. Grounded.
Arjun rewrites his sticky-note problem at Level 3. The version is twice as long and ten times more useful. It mentions ₹2,000-4,000/month, Tier-1 cities, and 24/7 cycling — three numbers that didn't exist in his Level-1 version.
---
The 5Ws — And Why Why is the Keystone
The next slide is the *Anatomy of a Problem: The 5Ws Framework.* Five questions, five answers — one of them highlighted in green. The green one is Why.
| W | Question | Arjun's answer | |---|---|---| | Who | Stakeholders affected? | Indian middle-class Tier-1 homeowners + the appliance industry + utility companies + the grid. | | What | Current state vs desired? | Current: purifiers cycling 24/7 tuned for worst case. Desired: adaptive cycling tuned to actual quality + usage. Gap = unmet need. | | When | Timeframe / frequency? | Every day, every minute the purifier is plugged in. | | Where | Location / region? | Indian Tier-1 apartments. (Globally: 700M purifier-equipped homes — but start Tier-1 India.) | | Why ★ | Why is this worth solving? | ₹2,000-4,000 of avoidable monthly electricity per household × 50M households = ₹1.5 lakh crore/year of avoidable spend. Plus 200 TWh of unnecessary grid load = ~150 million tonnes of avoidable CO₂. |
The professor underlines the Why slide three times. *If you can't answer Why, the other four Ws don't save you. Why is the question every investor asks at the end of every conversation: so what?*
Arjun realises his original sticky note had Who but no Why. Most of the marks on a problem-statement question live in the Why answer. He pencils '₹1.5 lakh crore' into a star next to his Level-3 statement.
---
Beyond the End User — The Trap That Kills B2B Pitches
The next slide disarms a trap Arjun didn't know existed. The professor's title: *Beyond the End User: Mapping the Stakeholder Ecosystem.*
The end user is not always the buyer, and the buyer is not always the decision maker.
Seven roles orbit any organisational purchase:
| Role | Who they are | |---|---| | Decision Maker | Final approve / kill authority | | Influencer | Shapes decision without authority (analysts, internal champions) | | Buyer | Owns procurement, signs the contract | | Manager | Supervises the people who'll use it | | Operator / End User | Actually uses the product | | Evaluator | Assesses fit before purchase (technical / pilot lead) | | CFO | Owns the budget; gatekeeper for spend |
The professor's worked example is Salesforce. 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 struggles,' you've defined the wrong customer.*
Arjun's retrofit-kit product is mostly B2C — Indian families buying directly — so the seven roles compress, but they don't vanish. Even in a household, the Buyer (whoever pays the EMI on appliance purchases — usually one parent) is different from the Decision Maker (the spouse who has veto power on 'is this a fad') and different from the Operator (the family member who maintains it) and different from the Evaluator (the cousin who reviews tech for the family). When he pitches, his marketing has to land four versions of the same value prop:
- *For the Buyer:* '₹3k upfront pays back in 2 months.'
- *For the Decision Maker:* 'Used by 10,000 households. Tested. Not a fad.'
- *For the Operator:* 'Installs in 15 minutes. App is one-tap.'
- *For the Evaluator:* 'Patent filed. Pilot data: 60% verified savings.'
Same product. Four problem statements. The exam-grade move, the professor says, is to write a separate version of the problem statement for each stakeholder role. Arjun does it. Four sticky notes. Each gets pinned to the whiteboard.
---
How Big Is This Actually? — The Implications Triad
*Defining the problem is half the work. The other half is proving the problem is big enough to be a business.*
Three implication questions, each named explicitly in the answer:
1. Magnitude. How big? What happens if you don't solve it — quantified.
Avoidable purifier electricity = ₹2,500/month × 12 = ₹30,000/year/household. Add the CO₂ impact: 4 tonnes/year/household × ₹2,000/tonne carbon price = ₹8,000/year of climate externality. Per-household magnitude: ₹38,000/year.
2. Frequency. How often? Daily / weekly / yearly?
The purifier runs continuously. The problem is 24/7. Maximum possible frequency.
3. Population. How many people face this?
India alone: 50M Tier-1 households with installed RO purifiers (Euromonitor, 2024). Globally: ~700M.
Putting it together:
And the professor underlines the final equation on the slide, which Arjun is going to put on a sticky note above his monitor:
$$
*A Painkiller is something people pay for now to stop pain. A Vitamin is something nice-to-have they might buy when they remember. Investors fund painkillers. Vitamins struggle to extract revenue.*
Arjun runs his idea through the test. Magnitude high. Frequency continuous. Population large. Painkiller — three checks. He breathes for the first time in 12 minutes.
But Priya, on his whiteboard, has already drawn a 2×2 in the corner: Magnitude × Frequency. She points to the *low-low* quadrant ('vitamin'), to the *high-low* quadrant ('transactional — earthquake insurance'), to the *low-high* quadrant ('tolerated nuisance — slow elevator'). Only the top-right is painkiller. *Only one of four quadrants supports a venture-scale recurring-revenue business.*
The professor's line that sticks: *if your problem scores low on either Magnitude or Frequency, you're selling a vitamin — and you must either reframe the problem to find its painkiller dimension or kill the idea.*
---
The Bridge — Validating the Problem Without Contaminating the Data
Arjun has done the work in his head. Every number is still his hypothesis. Before Phase 2 ends, the professor places three slides on how to talk to real customers without poisoning the well.
The Three Rules of Survey Design.
1. Avoid leading questions. Not *'Do you like our idea?'* — that question has the answer baked in. 2. Focus on past behaviour. Not *'Would you use a service like this?'* but *'When was the last time you did X?'* People mispredict the future but accurately report the past. 3. Quantify the pain. Not *'Is this a problem?'* but *'How much time did you lose?'* Numbers force honesty.
The professor circles a line on the slide:
*Bias is the enemy of validation.*
Then the Bias Trap Drill — the canonical contrast:
❌ Bad: *'Would you pay for software that helps store managers?'* (Hypothetical, leading, suggests the answer.) ✅ Good: *'How many hours a week do your store managers currently spend on manual reporting?'* (Factual, quantifiable, no suggestion.)
Arjun looks at the survey he had drafted last night. Question 1 read: *'Would you switch to an energy-efficient purifier if it saved you ₹2,000/month?'* He marks it ❌ — leading + hypothetical + bakes in the value prop. He rewrites it:
✅ *'In the last 12 months, what was the highest your monthly electricity bill went? Roughly what % of that came from the water purifier?'*
Question 2 read: *'Would you install a retrofit kit if it took 15 minutes?'* Marked ❌. Rewrite:
✅ *'When was the last time you had a technician visit for purifier maintenance? How long was the visit?'*
He rewrites all twenty. Half the leading questions die. The new survey is shorter and less flattering — but it's actually going to predict purchase behaviour.
The Validation Workflow — the professor's concluding slide:
Design Survey (with the three rules) → Define Target Audience (your Who from the 5Ws) → Execute (collect ≥ 20 responses) → Synthesise (summarise, update your pitch).
Arjun pencils in his target — 25 Tier-1 households with installed RO purifier, electricity bill ≥ ₹3,500/month. He decides to schedule interviews this weekend. Each one will be 20 minutes by phone.
The slide ends with the line the professor says will recur every Phase 3 lecture:
*Your opinion doesn't matter. Only the customer's data does.*
Arjun underlines it.
---
What Arjun Walks Out With
By end of Lecture 4, Arjun has:
- Levine's Tree pinned to his wall — Problem (root) → Solution (trunk) → Product (leaves). His retrofit-kit work was all trunk-decoration. He's now starting from roots.
- A Level-3 problem statement that names Tier-1 Indian middle-class homeowners, the 24/7 cycling, and the ₹38k/household/year magnitude — instead of his original 'people waste electricity'.
- All five Ws answered. Why is the keystone: ₹1.9 lakh crore/year India TAP, plus a climate co-benefit.
- Seven stakeholder views of the same problem. Four marketing messages for his four household roles.
- A Painkiller verdict that holds up on Magnitude × Frequency × Population, not just on his enthusiasm.
- A rewritten survey — twenty questions, all past-behaviour and quantifiable, none leading.
- A target audience and a sample-size commitment (25 households).
- The Phase 3 mantra ready to internalise: *your opinion doesn't matter; only the customer's data does.*
What he doesn't have: any customer interviews yet. The data is still his hypothesis. Phase 3 is where he goes get out of the building.
Priya looks at the rebuilt whiteboard. She circles the four sticky notes (one per stakeholder), the Painkiller 2×2, the rewritten survey, and the Validation Workflow box. She says:
*"You loved the trunk for two weeks. Now you love the root. That's progress."*
Arjun grins and starts dialling the first household on his list.