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.
Find problems worth solving before writing a line of code
The most common product mistake is falling in love with a feature idea instead of the
user problem behind it. This guide teaches you to spot real opportunities, size them,
and prioritize them with simple, repeatable frameworks.
Ready?
1
Opportunities vs. Solutions
This is the distinction between an opportunity and a solution, and it is the one that decides whether a roadmap is a set of bets or a queue of requests.
An opportunity is a customer need, pain or desire — a difficulty that exists whether or not you do anything about it. A solution is something you might build to address it. Customers hand you solutions, because solutions are what they can see and name; opportunities have to be recovered from underneath.
A patient walking in and demanding a specific medication is doing exactly this. A good doctor does not refuse, and does not simply comply — they establish the symptom first, because the requested prescription may work, or something cheaper may work better, and only one of those conversations is possible before the diagnosis.
The habit is to ask “what would this let you do?” until you reach something that is true regardless of what gets built. That answer is the opportunity, and it is the thing worth putting on a roadmap — because several solutions compete to serve it, and you get to choose.
Only the third panel survives a change of plan: the request names a thing you might not build, the opportunity names a difficulty that is there either way. That is the test for whether you have gone far enough — and it is the third panel, not the first, that belongs on a roadmap.
Everyday example, "a faster horse"
There's a famous line attributed to Henry Ford: "If I'd asked people what they wanted,
they'd have said a faster horse." A faster horse is a solution. The real
opportunity underneath it was "I need to get places quicker and more
comfortably", and the car served that far better than any horse could. When users ask
for a specific feature, they're handing you their guessed solution. Your job is to dig
out the opportunity beneath it, because a better solution than the one they named often
exists.
The doctor analogy
A patient walks in with severe muscle cramps and demands a specific pill they saw
in an advertisement, that's the solution.
A good doctor doesn't just hand it over. They ask questions, run tests, and discover
the patient is severely dehydrated, that's the opportunity. Treating dehydration
fixes the problem for good; the pill alone would fix nothing.
Rule: never prescribe a feature without diagnosing the opportunity first.
The patient who prescribed for themselves
A customer asked for a specific integration by name, repeatedly and with a deadline. The underlying difficulty was that their data arrived as a weekly CSV nobody had time to clean. The integration would have solved it; so would a scheduled import, at a fraction of the cost, and the customer had no way of knowing that.
Quick check
You work on a fitness app. Which of these is an opportunity, not a solution?
2
The Opportunity Solution Tree
An opportunity solution tree is a structure that keeps solutions attached to the reasons they exist. A desired outcome sits at the top. Opportunities hang beneath it. Solutions hang beneath the opportunities. Experiments hang beneath the solutions.
The single rule that makes it work: a solution may never attach directly to the outcome. It must hang from an opportunity.
The tree also makes your options visible. Under a single opportunity you should be able to list three or four candidate solutions, and seeing them side by side is what stops the first idea from winning by default.
And it shows the shape of your thinking at a glance. A tree with many opportunities and one solution each is a wish list. A tree with one opportunity and eight solutions is a team that has stopped exploring the problem. A solution with no opportunity above it is a feature somebody wanted to build, and the tree makes that visible rather than arguable.
Six solutions, and none of them touches the outcome directly — each has to come up through an opportunity to reach it. Read the shape rather than the boxes: three siblings under one opportunity means you had a choice to make, and one lonely box under another means you stopped at the first idea.
Everyday example, planning to save money
Imagine a tree for "save $200 a month" (the outcome, at the top). Branch
into the reasons you're not: "eating out too much," "forgotten subscriptions," "impulse
shopping" (the opportunities). Under each, list ideas: for eating out, "meal-prep Sundays," "a lunch budget app" (the solutions). Then try one
for two weeks and see if it sticks (the experiment). The tree keeps you
from jumping straight to a random idea ("download a budgeting app!") before you even know
which problem is costing you the most.
1
Desired outcome
A measurable business target. "Increase food-delivery retention by 10%."
2
Opportunities
Unmet user needs blocking that outcome. "Food arrives cold."
3
Solutions
Feature ideas that might resolve each opportunity. "Text directions, 3D maps."
4
Experiments
Cheap tests, A/B tests, interviews, to find which solution actually works.
The solution with no opportunity above it
A tree had "AI assistant" attached directly to the outcome, with no opportunity between them. Asked which customer difficulty it addressed, the room produced four different answers. The idea survived, but it moved down under one specific opportunity — and in that position it was clearly the third-best option available.
Quick check
Your tree's outcome is "Boost user retention by 12%." Where does the task
"Run an A/B test comparing two checkout layouts" sit?
3
Sizing Up Opportunities
Once you have a tree with several opportunities on it, you have to decide which to pursue — and the intuitive answer is usually wrong.
The common approach is importance versus satisfaction. Ask customers how important a need is, then how satisfied they are with how it is met today. The opportunity worth pursuing is the one that is high importance and low satisfaction: it matters, and nothing currently does it well.
Two other filters matter. How many customers share it? An intense need affecting 2% of your base is a different proposition from a moderate one affecting 60%. And does it fit your strategy? A real, large, unmet opportunity outside the segment you chose to serve is still a distraction, and it will be an unusually persuasive one.
The sizing is not a formula that outputs an answer. It is a way of making two opportunities comparable so the debate is about evidence rather than about who is more enthusiastic.
The top-left is the trap. One survey found the most important need was also the best-served — it looked like the leading opportunity and was the worst. The genuine one ranked fourth on importance and last on satisfaction.
Everyday example, which pothole to fix
A city can't fix every pothole at once, so it picks wisely. A deep crater on a busy main
road that wrecks tires (many people hit it, and it hurts a lot) gets fixed first. A small
crack on a quiet dead-end street waits. The opportunity score does the
same math for user problems: a pain that's important to many users and
badly served today is your main-road crater, the sweet spot. A pain
that's minor, or that competitors already solve well, is the quiet-street crack. Fix the
craters first.
How many?
User demand
What share of your users hit this problem, 70% or 5%?
How bad?
Pain severity
Is it a workflow-breaking blocker causing uninstalls, or a minor annoyance?
Who else?
Market gap
Can users solve it elsewhere easily, or would fixing it set you apart?
The opportunity score
The sweet spot is a need with high importance but
low satisfaction with today's alternatives:
A survey found the most important need in the product was also the one customers were most satisfied with. It looked like the top opportunity and was in fact the worst — there was nothing left to win. The genuine opportunity ranked fourth on importance and last on satisfaction.
Quick check
A problem is very important to users (importance = 9/10), but competitors already solve it
brilliantly (satisfaction = 9/10). What's its opportunity score?
4
Prioritizing with RICE
Once you are choosing between solutions rather than opportunities, a scoring model helps — not because the number is authoritative, but because it forces the inputs into the open.
RICE is the common one: (Reach × Impact × Confidence) ÷ Effort. Reach is how many people this affects in a period. Impact is how much it moves things for each of them, usually on a coarse scale. Confidence is how sure you are, as a percentage, and it is the honest one. Effort is person-months.
The danger is treating the output as a verdict. Every input is an estimate, and small changes in effort — the number people are worst at — swing the result substantially. A score of 42 against 39 is a tie.
The right use is as a conversation-forcing device. When two people disagree about a score, they are disagreeing about reach, or impact, or confidence, and now they know which — which is a far more productive argument than the one about whether a feature feels important.
Two items looked equal until they were scored: one reached 5% with high confidence, the other 60% with low, and multiplying flipped the ranking. Four slots, four separate arguments — the value is not the number that falls out of the bottom but knowing which of the four rows two people are actually disagreeing about.
Everyday example, picking a home project
Deciding between home improvements, you weigh four things.
Reach: how many rooms does it affect? (Rewiring the whole house vs. one
closet.) Impact: how much nicer will life be? Confidence:
how sure are you it'll actually work out? Effort: a weekend or three
months? A project that helps every room, a lot, reliably, in a weekend beats one that
helps one closet, slightly, maybe, over months. RICE literally divides the payoff (reach
× impact × confidence) by the effort, so quick wins with wide, confident
benefit rise to the top, and expensive gut-feel bets sink.
Reach, how many users it touches in a given period.
Impact, how much each user gains (scored 0.25 to 3).
Confidence, how solid your evidence is (100% = strong data, 50% = educated guess).
Effort, the cost to build, in person-months.
Where RICE changed the order
Two items looked equal until scored: one reached 5% of users with high confidence, the other 60% with low. Multiplying reach by confidence flipped the ranking, and the item everyone had assumed was second shipped first — the arithmetic disagreed with the room and turned out to be right.
Quick check
A riddle: "I am the truth-teller of the RICE formula. When a stakeholder overhypes a
feature's reach and impact on pure gut feeling, scoring me honestly, based on verified
research only, drags the final score back down to reality. Who am I?"
Drill what you learned
Scenario 1
easy
A high-value enterprise customer threatens to churn unless you build a custom 'PDF Export' feature that isn't on your roadmap.
What is your first step?
Scenario 2
easy
Food-delivery users complain their food arrives cold because drivers get lost inside large apartment complexes. You start an Opportunity Solution Tree with the outcome 'raise delivery satisfaction to 95%'.
Where does 'drivers lose time in the final 100 meters' belong on the tree?
Scenario 3
easy
A stakeholder proposes a Bluetooth smart-water-bottle integration to boost activity logging in your fitness app.
What does a RICE evaluation most likely reveal?
Scenario 4
easy
You must choose between two opportunities. Opportunity A: importance 8, satisfaction 7. Opportunity B: importance 7, satisfaction 2.
Which scores higher, and why?
Scenario 5
easy
Two features have similar Reach, Impact, and Effort. But one is backed by solid usage data and interviews; the other is a hunch from a single loud meeting.
How does RICE separate them?
Scenario 6
medium
A PM writes this "opportunity" on the tree: "Build an AI recommendation engine."
What's wrong with it as an opportunity?
Scenario 7
medium
Your team found a real, painful problem that only affects about 0.5% of users — but for those few it's a total blocker.
How should you weigh it?
Scenario 8
medium
A stakeholder games the RICE scores: they quietly inflate Reach and Impact and lowball Effort for their pet feature so it tops the list.
What's the right way to protect the process?
Scenario 9
medium
During research you uncover 15 distinct user pains for one outcome. Leadership wants you to tackle all 15 this quarter.
What does the Opportunity Solution Tree encourage instead?
Scenario 10
medium
You have a promising opportunity and three candidate solutions. A teammate wants to fully build the most exciting one right away.
What does the tree's 'experiments' layer suggest?
Scenario 11
hard
Sales relays that "customers keep asking for a dark mode." You investigate and find the underlying complaint is eye strain during long night shifts.
Why does distinguishing these matter?
Scenario 12
hard
An opportunity scores high on importance and low on satisfaction — a jackpot. But when you size the effort, any real solution would take 18 months and a new team.
How should this affect your decision?
Scenario 13
hard
A leader says: "RICE scores are just made-up numbers — they give false precision. Let's not bother."
Your opportunity tree has an outcome ("increase retention 10%") but a teammate keeps adding opportunities like "users on Android" and "enterprise customers."
What's the confusion, and how do you fix the tree?
Drilled it. Now apply it to a real situation.
Put it to work
From lesson 1
A backlog of solutions with no problems attached
A veterinary booking platform
Six items at the top of the backlog: a chatbot, a mobile app, SMS
reminders, a loyalty scheme, a redesigned homepage, and calendar sync.
Each has a champion. Asked what customer problem each solves, the room
produces answers for two of them.
What is wrong with a backlog shaped like this?
Select all that apply — there are 3 to find.
What actually happened
Rewritten as opportunities, four of the six collapsed into one: "I forget
my appointment and only realise when the practice calls." SMS reminders,
the chatbot and calendar sync were three solutions to that single
problem, and could finally be compared against each other rather than
stacked in a list.
An opportunity is a customer problem or unmet need. A solution is one way
of addressing it. Backlogs made of solutions cannot be prioritised
honestly, because the thing being compared is never stated.
From lesson 2
Building the tree from twenty interviews
A freelance accounting tool
Desired outcome: raise the share of users who file their quarterly return
through the product from 31% to 50%. Twenty interviews are done. The
team now has to turn them into a tree.
Order these four from the top of the opportunity solution tree downward.
Drag the rows, or use the arrows, then check.
"Raise self-filed quarterly returns from 31% to 50%"The outcome at the root. One measurable business result the whole tree exists to move — not a list of goals, and not a solution.
"I don't trust that I've categorised my expenses correctly"An opportunity: a customer problem in their own words, drawn from the interviews. It sits under the outcome because solving it plausibly moves that number.
"Show a confidence score on each categorised expense"A solution — one of several ways to address that specific opportunity. It belongs under its opportunity, never directly under the outcome.
"Run a week-long test showing scores to 5% of users and measure filing completion"An experiment. It sits under the solution and tests whether that solution actually addresses the opportunity, which is the only honest way to find out.
What actually happened
Drawn out, the tree had three opportunities under the outcome and eleven
solutions across them — but nine of the eleven sat under a single
opportunity. That imbalance was the finding: the team had been generating
solutions for the problem they found easiest to think about, not the one
the interviews weighted most heavily.
Outcome, opportunity, solution, experiment. The structure's value is that
it makes the imbalance visible.
From lesson 3
Sizing what you cannot measure directly
A recruitment platform
Three opportunities, all real, all drawn from research. The team has to
size them without any of them yet having a metric of its own.
What is known about each
Opportunity
How often it occurs
How badly it hurts
Evidence
"I can't tell if a candidate is actually available"
Every shortlist
Wastes a whole interview slot
17 of 20 interviews
"I lose track of which agency sent whom"
Weekly, larger firms only
Embarrassing, occasionally a double fee
4 of 20, all enterprise
"I can't compare two candidates side by side"
Every hire
Mild — people use a spreadsheet
11 of 20
Which readings are sound?
Select all that apply — there are 3 to find.
What actually happened
They took availability. The agency problem went to the enterprise
roadmap, where its denominator was right, and the comparison problem was
parked with an explicit note: revisit if anyone stops using a
spreadsheet.
Size on frequency, severity and confidence — and check which population
the frequency is a fraction of before comparing.
From lesson 4
RICE, and the number that was doing all the work
A restaurant reservation product
Four solutions scored with RICE. The top-scoring item is about to be
committed for the quarter.
The scores as presented
Solution
Reach
Impact
Confidence
Effort
Score
Waitlist auto-fill
8,000
3
50%
4
3,000
Table-plan editor
1,200
2
100%
3
800
Deposit collection
3,500
2
80%
5
1,120
SMS confirmations
9,000
1
100%
2
4,500
Work through the scoring before committing.
Step 1 of 3
SMS confirmations scores highest. What should you check first?
It turns out 9,000 is everyone who books, and the "impact" is a marginally clearer confirmation. Real, and close to zero per person.
Step 2 of 3
Waitlist auto-fill has half the score but 50% confidence. What does that low number represent?
A two-week test on one city raised confidence to 85%, taking the score to 5,100 — above SMS confirmations.
Step 3 of 3
What is the general lesson about RICE?
The quarter went to waitlist auto-fill, on the strength of a test that cost two weeks.
What actually happened
SMS confirmations shipped anyway, later, as a two-day job. The RICE score
had been right that it was cheap and wrong that it was valuable — a
distinction the single number could not carry, and the conversation about
the inputs could.
RICE is a way of writing down four assumptions so they can be argued
with. The moment it becomes a sort order, it has stopped working.