Defining the Real Problem¶
Summary¶
Guides founders from a vague pain point to a validated, prioritized problem statement, distinguishing real problems from perceived ones and root causes from symptoms.
Concepts Covered¶
This chapter covers the following 20 concepts from the learning graph:
| Concept | Concept Impact Score |
|---|---|
| Problem Definition | 3060 |
| Pain Point | 13 |
| Customer Pain | 6 |
| Root Cause | 6 |
| Problem Statement | 6 |
| Problem Severity | 5 |
| Problem Frequency | 5 |
| Problem Prioritization | 5 |
| Real Problem | 4 |
| Perceived Problem | 4 |
| Problem Validation | 4 |
| Problem-Solution Fit | 3 |
| Symptom Vs Root Cause | 3 |
| Unmet Need | 3 |
| Job To Be Done | 2 |
| Problem Framing | 2 |
| Problem Urgency | 2 |
| Willingness To Solve | 1 |
| Essential Bills Priority | 1 |
| Problem Discovery | 1 |
Prerequisites¶
This chapter builds on concepts from:
The Second Block: What Are They Actually Struggling With?¶
Chapter 4 gave you a sharp, specific customer. This chapter answers the question that customer's existence only raises: what, precisely, are they struggling with? A vague answer here — "grooming is inconvenient," "dinner is stressful" — produces a Solution block that's just as vague. This chapter's job is turning a fuzzy sense that "this bothers people" into a Problem block sharp enough to test.
Getting Specific About Pain
"People are busy" is not a problem statement — it's an observation about the entire human species. By the end of this chapter, you'll know how to turn that kind of vague observation into a problem sharp enough to test against real people. Let's find out for real!
What Counts as a Real Problem¶
Problem definition is the practice of stating, in specific and falsifiable terms, the difficulty your target customer experiences that your venture intends to address — specific enough that someone could look at real evidence and say whether the statement is true or false for that customer. This is the second block on the canvas, and it inherits everything Chapter 4 established: a problem is only ever a problem for a specific target customer, not for people in general.
Two smaller terms build up to that definition. Customer pain is the negative experience — frustration, cost, wasted time, embarrassment, risk — a customer feels as a direct result of an unsolved problem. A pain point is one specific, nameable instance of that pain, concrete enough to describe in a single sentence: not "grooming is a hassle" but "I have to take an unpaid afternoon off work to drive forty minutes each way." Jordan's problem definition, refined after several Field Discovery Windows, reads: "Dog owners within 5 miles who don't own a car-friendly crate lose a half-day of income or personal time every time their dog needs grooming, because the nearest groomer requires an in-person drop-off and pickup." That's specific enough to test — and specific enough to be wrong, which is exactly what makes it useful.
Real Problems vs Perceived Problems¶
Not every problem a founder believes in turns out to be real. A real problem is one that customers actually experience and can describe from their own lived frustration when asked directly, confirmed through evidence rather than founder intuition. A perceived problem is one a founder believes customers have, based on logic, outside research, or their own experience, that has not yet been confirmed by talking to the actual target customer. Every problem starts as perceived — the only way a perceived problem becomes a real one is problem validation: the process of testing a perceived problem against real customer conversations and behavior to confirm whether it is genuinely felt, exactly as urgently as assumed.
A Perceived Problem Isn't a Mistake — It's a Starting Point
Notice that "perceived" doesn't mean "wrong." Every real problem this course has ever validated started out perceived. The only mistake is treating a perceived problem as if it were already real — building a Solution block around it before a single customer has confirmed it from their own mouth.
Finding the Root Cause¶
Even a confirmed, real problem can be stated at the wrong depth. A symptom is the surface-level complaint a customer voices first, while a root cause is the underlying condition actually producing that complaint — often several layers beneath the first thing anyone says out loud. Symptom vs. root cause is the discipline of not stopping at the first explanation a customer offers, because a solution built for a symptom often leaves the root cause untouched.
Priya ran into this directly. Her interviewees' first complaint was almost always "I don't have time to cook." That's a symptom. Asking "why don't you have time" repeatedly — a technique sometimes called the Five Whys — led somewhere more specific: not a lack of hours in the day generally, but the unpredictability of rotating shift schedules making any planned dinner routine fall apart. The root cause wasn't time scarcity; it was schedule unpredictability. A meal kit requiring advance planning would have solved the symptom's surface complaint while missing the root cause entirely.
Two more ideas sharpen this same search. An unmet need is a customer requirement that no current option — including doing nothing — adequately satisfies, whether or not the customer has ever put it into words. A job to be done reframes the whole question around function rather than feature: the underlying task or outcome a customer is fundamentally trying to accomplish, independent of any particular product, such as "get a nutritious dinner on the table with zero advance planning" rather than "buy a meal kit."
Before trying the interactive drill-down, notice that the technique is always the same: take the first complaint, ask "why" again, and keep going until the answer stops changing.
Diagram: Symptom vs Root Cause Drill-Down¶
Symptom vs Root Cause Drill-Down
Type: microsim
sim-id: symptom-root-cause-drilldown
Library: p5.js
Status: Specified
Bloom Level: Apply (L3) Bloom Verb: apply
Learning objective: Given a customer's first-stated complaint, learners apply a repeated "why" technique, choosing at each step which underlying cause to pursue, to trace the symptom down to its root cause.
Canvas layout:
- Top: the current complaint text in a card
- Below: 2-3 candidate "why" answers presented as clickable buttons
- A running vertical trail on the left showing each previously selected layer, top (symptom) to bottom (current depth)
Behavior: Start with Priya's complaint: "I don't have time to cook." Present 2 candidate answers to "Why not?": (a) "There aren't enough hours in the day" (a dead-end distractor that loops back to the same complaint if chosen — with feedback: "This restates the symptom rather than explaining it — try the other option"), (b) "My work schedule changes week to week" (correct path, advances). Continue for 2 more rounds along the correct path: "Why does that stop you cooking?" → "I can't commit to a weekly meal plan in advance" (advances) vs. a distractor "I don't like cooking" (feedback: "Priya's interviews didn't support this — stay with what she actually heard"). Final round reveals the root cause: "Rotating shifts make any pre-planned dinner routine unreliable" and labels it "Root Cause Found," contrasting it against the original symptom card still visible at the top.
Interactive controls:
- Click a candidate answer to advance or receive corrective feedback
- "Restart" button resets to the original symptom
- Trail on the left is clickable to jump back to any earlier layer
Default parameters: Starts at the top-level symptom, no layers selected.
Implementation notes: Use p5.js. Store the drill-down as a small tree structure {text, children: [{text, correct, feedback}]}. Must remain fully readable on narrow (mobile) viewports — stack the trail above the current card rather than beside it below 600px width.
Sizing the Problem: Severity, Frequency, and Urgency¶
Not every real, root-cause-confirmed problem deserves to anchor a venture. Three dimensions help size how much a problem actually matters to the customer who has it.
| Dimension | Question It Answers | Priya's Finding |
|---|---|---|
| Problem Severity | How painful is this when it happens? | High — skipped dinners affect the whole family's evening |
| Problem Frequency | How often does it happen? | High — 3 to 5 nights per week on a rotating schedule |
| Problem Urgency | How soon does the customer want it solved? | Moderate — a workaround exists (takeout), but it's expensive and unhealthy |
Problem severity measures how painful or costly the problem is on any single occurrence it happens. Problem frequency measures how often that occurrence recurs for the target customer. Problem urgency measures how soon the customer wants a solution, independent of severity or frequency — a customer can feel a problem intensely and rarely (a flooded basement) or mildly but constantly (a slightly-too-small kitchen), and either combination can still justify a venture.
Multiply Severity by Frequency, Not Either Alone
Here's a shortcut: a mildly annoying problem that happens daily is often a stronger foundation than an intensely painful problem that happens once a year. Ask both questions, and don't let a dramatic severity score distract you from a weak frequency score.
Writing the Problem Statement¶
With severity, frequency, and urgency in hand, problem framing is the choice of how to word a problem — which details to include, which customer language to borrow directly, and which angle to emphasize — since the same underlying problem can be framed narrowly or broadly with very different implications for the Solution block that follows. The finished output of that choice is the problem statement: the specific, written sentence describing the customer's problem that will sit in the canvas's Problem block, typically following a pattern like "[Target customer] struggles with [specific pain], caused by [root cause], which matters because [severity/frequency/urgency]."
When a founder has more than one candidate problem in view — which is common after a full round of interviews — problem prioritization is the deliberate act of ranking those candidate problems and choosing which one to pursue first, using the same severity, frequency, and urgency evidence rather than personal preference.
Will They Actually Solve It?¶
A problem can be real, root-caused, frequent, and severe, and a customer can still never act to solve it. Willingness to solve describes whether a customer is actually motivated to spend money, time, or effort addressing a problem, as distinct from merely being bothered by it — plenty of real problems get quietly tolerated indefinitely. One specific and common reason a customer won't act is essential bills priority: the well-documented tendency for customers to direct limited money first toward non-negotiable obligations — rent, groceries, utilities, debt — before any discretionary spending on a problem that, however real, doesn't threaten their basic stability.
Annoying Is Not the Same as Solvable-For-Money
A common trap here is confirming a problem is real and then assuming willingness to solve automatically follows. It doesn't. Always ask directly: "What have you already tried, or paid for, to fix this?" If the honest answer is nothing, that problem may be competing with essential bills for a customer's limited money — and losing.
From Problem to Solution¶
Two final ideas carry this chapter's work into Chapter 6. Problem-solution fit is the degree to which a proposed solution actually addresses the validated root cause of a problem — as opposed to merely addressing its symptom, which the Five Whys work above exists to prevent. Problem discovery is the ongoing research process of finding and refining problem statements through direct contact with customers — not a one-time task completed in Session 1, but a habit that continues every time new field evidence complicates or sharpens what you thought you knew.
Key Takeaways¶
Before Chapter 6 turns this problem into an offer, hold onto how a problem gets defined:
- Problem definition states, in testable terms, the customer pain behind a specific pain point — and stays a perceived problem until problem validation confirms it as a real problem.
- Symptom vs. root cause thinking, using the Five Whys, distinguishes a surface complaint from the root cause, an unmet need, and the underlying job to be done.
- Problem severity, frequency, and urgency size how much a problem matters; problem framing, the problem statement, and problem prioritization turn that sizing into the canvas's Problem block.
- Willingness to solve — often limited by essential bills priority — determines whether a real problem will actually motivate action, and problem-solution fit is what keeps problem discovery honest as you move forward.
You Just Found the Real Problem
You can now tell a real problem from a perceived one, and a symptom from its root cause — the exact discipline that keeps a venture from solving the wrong thing well. Let's find out for real, starting with the Solution block in Chapter 6.