All 29 modules are open from the start — nothing here is
locked, and nothing costs anything. Sign in so your progress, titles and
credentials stay with you, on every device you use.
Free forever, with your Google account. No password, no payment.
Solve the right problem before you solve a problem right
Teams love jumping straight to solutions. But build the sharpest feature to answer a fuzzy or wrong problem, and you've still shipped nothing worth using. This guide covers how to frame a problem so the rest of the process has something solid to stand on.
Ready?
1
Solving the Wrong Problem Well
A tenant complains that the flat is cold. You buy them a heater. It works — the flat is warmer, the complaint stops, everyone is satisfied.
Product teams do this constantly, and not through carelessness. It happens because problems usually arrive already dressed as solutions. A customer says “I need bulk export”. A stakeholder says “we should add notifications”. Both are answers to a question nobody has stated, and accepting them means inheriting someone else’s diagnosis.
One team had “add bulk export” on the roadmap for three quarters. Written out properly, the problem turned out to be that finance needed one specific figure each month and was exporting everything to calculate it by hand. The fix was a single line on an existing screen. Bulk export was never built and nobody missed it.
The most valuable few hours in a project are usually spent before anyone agrees what to build — and they are almost always the first hours cut, because defining a problem produces no visible output and looks like delay.
Every line in the left panel is a real result: it is warmer, the complaint did stop. That is what makes this the harder mistake to catch — nothing in the work went wrong, and the only difference between the two panels is which problem got written down before anyone started.
Everyday example
A tenant complains the flat is cold. You can buy them a heater, and it will work. If the actual problem is a window that no longer closes, you have just agreed to pay their heating bill forever — a good solution, executed well, to the wrong problem.
The support-ticket trap
A team notices users abandon checkout and complain "your checkout is confusing." They
redesign the checkout flow end to end. Abandonment barely moves, because the real
problem was a shipping-cost surprise on the last step, not the layout. They solved a
problem. Just not the one that mattered.
A sharp solution to a fuzzy or wrong problem still fails. Framing comes first.
Quick check
A stakeholder says "users want a dark mode, build it." What's the problem-framing move before writing any code?
2
Writing a Sharp Problem Statement
A problem statement is worth writing down properly because it is the thing every later decision gets checked against. Four parts, and each one does specific work.
Who — a specific group, not “users”. Trying to — the goal they already have, which exists whether or not your product does. But — the obstacle, stated without naming a solution. We know because — the evidence that this is real rather than assumed.
The but clause is where solutions smuggle themselves in, and it is worth policing. If your obstacle contains a feature name, you have already decided.
The we know because clause is the one that gets skipped and the one that saves the most time. It forces you to say whether this came from research, from analytics, or from a meeting where someone said it confidently. All three are legitimate inputs and they carry very different weight — and a problem statement that cannot cite anything is a hypothesis about a hypothesis.
1
Who
The specific group, not “users”. “New sellers in their first week” tells you who to go and talk to; “users” tells you nothing.
2
Trying to
The goal they already have, which exists whether or not your product does — price a listing so that it sells.
3
But
The obstacle, with no solution in it. If the sentence contains a feature name, the decision has already been taken.
4
We know because
Where this came from: analytics, research, or somebody saying it confidently in a meeting. All three are legitimate inputs and they carry very different weight.
Too vague
"Users struggle with pricing"
No segment, no number, no source, impossible to know when it's fixed.
Sharp
"New sellers abandon the pricing step (38%, last 90 days)"
Specific enough to investigate, specific enough to know if a fix works.
Four parts, none optional, which is why none of them is picked out. The two middle rows are where a solution gets in — a goal the person already had, and an obstacle named without naming a fix. Put a feature into either and the bottom row is being asked to justify a decision that was already taken.
Everyday example
Compare "users need a dashboard" with "account admins cannot tell which of their seats are unused before a renewal, so they over-buy". The first names a solution and closes the conversation. The second names a person, a moment and an obstacle, and leaves five solutions open.
The statement that killed the feature
A team had "add bulk export" on the roadmap for three quarters. Written out properly, the problem turned out to be that finance needed one specific figure each month and was exporting everything to compute it by hand. The fix was a single line on an existing screen. Bulk export was never built, and nobody missed it.
Quick check
Which of these is the sharpest problem statement?
3
Digging to the Root Cause
A well-written problem statement can still be pointed at a symptom. “Users abandon checkout” is specific, evidenced and true, and it may still be three layers above anything you can usefully fix.
Getting deeper is mostly the discipline of asking why one more time than feels necessary. A team notices abandonment and complaints that checkout is confusing. They redesign it end to end. Abandonment barely moves — because the real problem was a shipping cost that appeared for the first time on the final screen, and no amount of visual clarity fixes a surprise.
The chain runs: they abandon → because a cost appears late → because shipping is calculated after address entry → because the estimator was never built. Each level is a different fix with a different lifespan.
Two things make this work in practice. Stop when you reach something you can actually change — a cause you have no control over is interesting and useless. And check the chain backwards before acting: if we fixed this bottom cause, would the symptom genuinely disappear? If the honest answer is “partly”, you have a multi-cause problem and one more why will not resolve it.
The point is not to reach the deepest possible cause. It is to reach the deepest one you can afford to fix, and to know what you are leaving above it.
The highlighted layer is the bottom one, and that is the whole claim. The three above it are all true, and all fixable too — you can redesign the page, you can reorder the steps — they just buy less time each, and the arrow stops where your team’s control runs out rather than where the causes do.
Everyday example
A puddle on the kitchen floor. Mop it and it comes back. The pipe behind the dishwasher is the reason; the puddle is the notification. Most roadmaps are full of mops.
The 5 Whys, in action
Problem: Checkout crashes on Mondays.
Why? Traffic spikes then. Why? Our Monday email blast lands right at 9am. Why does the spike crash it? Servers are scaled for average load, not peak. Why? No autoscaling is configured. Why wasn't it configured? No one owns capacity planning.
The root cause isn't "add more servers", it's an ownership gap. Fix that, and every
future spike stops being a fire drill.
Five whys, and the one that mattered
A checkout crashed on Mondays. The chain ran: traffic spikes, a query gets slow, an index is missing, the migration that added it was skipped, and nobody checks migrations after a rollback. Four of those are fixable in an afternoon and one of them stops it recurring across every future feature.
Quick check
Using the 5 Whys, you land on "nobody owns capacity planning" after five whys. What should you do with that?
4
Common Problem-Framing Traps
Four traps catch problem framing, and each one produces work that looks productive for months before anybody notices.
The solution in disguise. A statement like “users need faster search” sounds like a problem and is an answer. It names the fix, so every option that follows is a variation on that fix, and the genuinely different approaches are never generated.
The symptom mistaken for the cause. Real, measurable, and three layers above anything you can usefully change — so the fix works briefly and the problem returns.
The problem framed around the answer you already like. This is much harder to notice from the inside than it sounds, because it feels exactly like having a hypothesis. The give-away is that the framing quietly rules out every option except the one you arrived with.
The problem nobody actually has. Stated plausibly, agreed by everyone present, supported by no evidence from outside the room.
One defence covers most of them. Hand your problem statement to a colleague who was not in the discussion and ask them to propose three solutions. If all three are the thing you were already planning to build, you have not written a problem — you have written a specification with a story attached.
Trap 1
Solution-shaped problem
"We need push notifications" names a feature, not a pain. Ask what it's meant to fix.
Trap 2
Too broad to act on
"Users are unhappy" can't be tested or solved. Narrow to a segment and a moment.
Trap 3
Cherry-picked evidence
Hunting only for data that confirms the fix you already wanted defeats the point of framing.
The right-hand column is four different routes to the same confident meeting. None of them looks like a mistake from inside the room — each has a plausible sentence, a team that agrees, and often some data behind it — which is why the only reliable check comes from someone who was not there.
Everyday example
A detective who announces the suspect in the first five minutes will spend the rest of the case gathering evidence about that person. The evidence may even be good. It is the search that has been narrowed, and narrowing the search is much harder to notice than reaching a wrong conclusion.
Framed around the solution
A brief opened "users want faster search". Research found that people were not waiting on search at all — they were searching repeatedly because the results did not show which document was the current version. Speed was measurable, visible and irrelevant, and it had been in the problem statement from the first day.
Quick check
A PM writes: "Problem: we lack a referral program." What's wrong with this framing?
Drill what you learned
Scenario 1
easy
A support lead says: "Problem: we need a live chat widget."
What's your first move?
Scenario 2
easy
Two teammates argue hotly about button color while debating a signup problem nobody has actually defined yet.
What should happen?
Scenario 3
easy
A churn analysis concludes: "users leave because the product is bad."
How do you improve this problem statement?
Scenario 4
easy
A PM's 5 Whys chain stops after one why — "Signups dropped. Why? The homepage changed." — and ships a full revert.
What's the risk?
Scenario 5
easy
Leadership demands: "Problem: we don't have a mobile app."
How do you reframe it?
Scenario 6
medium
A problem statement reads: "New users abandon onboarding (61%, last 30 days, from funnel analytics)."
Why is this a strong statement?
Scenario 7
medium
During a root-cause dig, someone says "let's stop, we all agree it's an API bug" after only two whys — while data shows three teams changed things that week.
What's the caution?
Scenario 8
medium
A researcher notices they're only pulling user quotes that support the "redesign the nav" idea already scoped.
What's happening?
Scenario 9
medium
A problem statement names a segment ("enterprise admins") but no evidence — just "I think they're frustrated."
What's missing and why does it matter?
Scenario 10
medium
A team debates for an hour whether to build feature X or Y, with no written problem statement for either.
What should happen first?
Scenario 11
hard
Analytics shows a spike in a "problem" only three days old, and no one has checked whether it's a one-off event (a marketing blast) or a persistent pattern.
What's the framing risk?
Scenario 12
hard
A doc lists fifteen different "problems," ranging from onboarding to pricing to support tone, with no ranking.
What's the issue with this?
Scenario 13
hard
A junior PM says "the problem is complete, let's move to ideation" after a single Slack message from one user.
Is that enough to move forward?
Scenario 14
hard
A problem statement says: "We're losing to Competitor X, so we need their feature set."
What's the framing flaw?
Scenario 15
hard
After a sharp, evidence-backed problem statement is written, a stakeholder still says: "Just build what I asked for originally."
What's the best response?
Drilled it. Now apply it to a real situation.
Put it to work
From lesson 1
Burbn had eleven features and one that mattered
Instagram
Burbn was a check-in app with photos, plans, points and more besides.
Usage was thin. Rather than build harder, Systrom and Krieger looked at
what the few active users actually did — and found they almost entirely
ignored check-ins and used it to post photos.
They stripped everything else out, added filters and fast sharing, and
relaunched as Instagram.
What was the problem they had been solving well, and wrongly?
What actually happened
Instagram passed a million users within a couple of months of launch. The
engineering work that produced Burbn was not wasted — the reframing was
what changed, and the reframing came from watching behaviour rather than
from a better feature list.
Solving the wrong problem well is the most expensive failure in product,
because every internal signal — velocity, delivery, quality — says you are
doing fine.
From lesson 2
Four attempts at the same problem statement
A hotel booking site
Cancellations within 24 hours of booking are up. Four people write the
problem statement. Only one of them is usable.
Order these from sharpest to weakest.
Drag the rows, or use the arrows, then check.
"31% of same-day cancellations come from bookings where the total at checkout was more than 15% higher than the price shown in search — up from 12% in March, when we began showing fees later in the flow."Sharpest. Specific population, measured size, a timeframe, and a candidate mechanism tied to a known change. It is falsifiable and it points somewhere.
"Same-day cancellations rose from 4% to 9% of bookings after March."Second. Real, measured, bounded in time. It says what is happening without any hypothesis about why, which is honest but leaves the team with nowhere to start.
"Users are cancelling because they find the pricing misleading."Third. It has a mechanism but no evidence and no size. Stated this confidently it will be treated as established, and the team will build against an assumption.
"We need to improve trust in the booking flow."Weakest. A solution direction disguised as a problem. There is no number, no population, nothing that could turn out to be false, and it silently rules in a whole class of work.
What actually happened
The team went with the first. Because it named a specific population it
could be checked — and checking it showed the effect was concentrated
almost entirely in one market where local tax display rules differed. The
fix was regional, took a week, and would never have been found from
"improve trust in the booking flow".
From lesson 3
Five whys on a checkout drop
An electronics retailer
Checkout completion fell four points overnight. The obvious answer is that
checkout broke. It did not — error rates are flat and the page loads fine.
Work down the chain.
Step 1 of 3
Completion is down and checkout is technically healthy. What is the next question?
Mobile only. Desktop is unchanged.
Step 2 of 3
Why would mobile completion drop with no errors?
So: banner added → pay button below the fold on small screens → fewer people reach it.
Step 3 of 3
Why did that ship? Keep going past the immediate cause.
The root is a missing check, not a missing person. That is the level where a fix stops the class of problem rather than the instance.
What actually happened
The banner was fixed in an hour. The mobile viewport check added to the
release process caught two more layout regressions in the following
quarter, either of which would have cost a similar four points.
Stop at the proximate cause and you fix today. Go to the root and you fix
the category.
From lesson 4
A problem statement with the answer already in it
A recruitment platform
The statement circulated before the quarterly planning session:
"Recruiters are not posting enough jobs because we lack an AI job-description
generator. We need to build one to stay competitive."
Which traps is this statement falling into?
Select all that apply — there are 3 to find.
What actually happened
Reframed as "recruiters who post fewer than three jobs a month cite time as
the barrier; we do not know which part of posting takes the time", the team
spent two days watching people post. Writing the description turned out to
be about a fifth of the effort. Most of it went on approval chasing and
re-entering details the system already held.
If your problem statement contains the word "because we lack", you have
written a solution and given it a problem's name.