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.
A repeatable path from insight to a shortlist worth building
Design-thinking ideation gives you the creative rules. A product ideation framework gives you the funnel: how a validated insight becomes a How Might We question, becomes a wide set of ideas, becomes a small set of concepts worth testing.
Ready?
1
The Ideation Funnel
Ideation at product scale is a funnel, and the width of its top determines the quality of what comes out of the bottom.
The modules: a framed problem, a divergence that produces many candidate ideas, a convergence that clusters and shortlists, and finally one or two bets carried into tests.
Nobody auditions a single person and hopes.
The part that is easy to underestimate is what a wide top does to the emotional side of the decision. When three ideas exist, discarding one feels like losing a third of your options, and the discussion becomes about defending ideas. When thirty exist, discarding twenty-six is obviously the process working.
That difference changes decisions more than any framework does. A team with plenty of options can afford to be ruthless; a team with three is negotiating, and the idea that survives is usually the one with the most senior advocate rather than the strongest case.
1
Framed problem
One How Might We question, complete. Everything below inherits its width, so this is the only stage worth being slow about.
2
Diverge
Many candidate ideas, generated without judging. Quantity is the point: thirty options make discarding twenty-six feel like the process working.
3
Converge
Cluster what came out, then shortlist against criteria you named before you could see the options.
4
Bet
One or two carried into a test. Not "the winner" — the ones worth spending a week finding out about.
The widths are the argument. Discarding twenty-six of thirty ideas is obviously the process working; discarding one of three feels like losing a third of your options — so a team that starts narrow ends up negotiating, and the idea that survives is the one with the most senior advocate.
Everyday example
Casting a film: hundreds of auditions, a shortlist of twelve, three screen tests, one actor. Nobody auditions one person and hopes. The funnel is wide at the top precisely so that the narrow end has something to choose from.
Three ideas and a decision
A quarter opened with three candidate features and a vote. The winner shipped and did nothing. The following quarter opened with thirty candidates, converged to four, and tested two — one of which was a small change nobody would have proposed in a room of three. The difference was not creativity; it was the width of the top of the funnel.
Quick check
Where does a validated user insight belong in the ideation funnel?
2
Writing How Might We Questions
A How Might We question turns a problem into an invitation to solve it. Getting its width right is the whole craft.
The reliable tell for a question that is too narrow is that it names a solution. And a question with a solution inside it will produce variations on that solution — which feels like ideation and is really specification.
The tell for one that is too broad is that you cannot picture a specific person in a specific moment. If the question would read identically for a teenager and a procurement manager, it is not yet a question about anybody.
A practical method: take your problem statement and write several How Might We questions at different altitudes, from very broad to very specific. Then choose the one that feels slightly uncomfortable — broad enough that you cannot immediately picture the answer, specific enough that you know who it is for and when it happens.
Too broad
"How might we improve retention?"
Could point anywhere. Loses the specific insight it should be built from.
Well-scoped
"How might we help new sellers price with confidence?"
Grounded in a specific insight, open enough for many possible answers.
Too narrow
"How might we add a price-suggestion tooltip?"
Already names a solution, forecloses other ways to solve the same need.
The two panels fail in opposite directions and both feel productive at the time. The band underneath is the only one of the three you can act on, and the test for it is uncomfortable on purpose: you should not be able to picture the answer, but you should know exactly who it is for and when it happens to them.
Everyday example
"How might we get people to eat vegetables?" is too broad to answer and too narrow to be interesting. "How might we make vegetables the easiest thing in the fridge to grab at 7pm?" gives you somewhere to start and does not tell you the answer.
The question that contained its answer
A workshop ran on "how might we build a better onboarding checklist?" and produced eleven checklists. Reframed to "how might we get an account to its first real result on day one?", the same group proposed a template gallery, a sample dataset and a concierge call — none of which was a checklist, and one of which shipped.
Quick check
Which is the best-scoped HMW question, given the insight "new sellers abandon listing at the pricing step because they don't know competitive prices"?
3
Generating Ideas at Product Scale
The unit of an idea matters as much as the number of ideas, and most backlogs are made of units too small to think with.
An idea stated as a feature has already chosen an approach. It names a mechanism, so every option generated alongside it is a variation on that mechanism — and the approach itself was never discussed. It was decided silently, by whoever phrased the first idea in the room.
An idea stated as a problem at product scale does the opposite. It describes a situation the customer is in and leaves the mechanism open, so several genuinely different approaches can compete to answer it.
The practical consequence shows up when you cluster. Ideas that look distinct at feature scale collapse into a handful of underlying strategies, and teams routinely discover they have been solving the same problem repeatedly in small pieces for years without noticing — because each individual piece looked like a different idea.
So generate at the level of the problem first, then descend. Ask what would have to be true for this difficulty to disappear, and only afterwards what could be built.
Choosing between three strategies is a far better use of a room than ranking ninety features — and it is usually the same material, simply grouped at the level where the real decision lives.
Generate at problem scale
Describe the situation the customer is in and leave the mechanism open, so that several genuinely different approaches can compete to answer it.
Cluster before you judge
Ideas that look distinct at feature scale collapse into a handful of underlying strategies once they are grouped — which is usually where a team finds it has been solving the same problem in small pieces for years.
Only then descend
Ask what would have to be true for the difficulty to disappear, and afterwards what could be built. Three strategies are a better use of a room than ninety features.
The bottom row is four ideas; the middle row is the three arguments those four are actually instances of. A backlog written at the bottom row has already settled the middle one — silently, by whoever phrased the first idea — and a room can compare three strategies far better than it can rank ninety features.
Everyday example
Ideas at product scale are not features. "A dark mode" is a feature. "Make the product usable in a warehouse at night" is a problem at product scale, and dark mode is one of six answers to it.
Scaling the unit of the idea
A backlog of ninety feature-sized ideas was clustered into seven problem-sized ones. Six of the ninety turned out to be different attempts at the same underlying problem, which the team had been solving repeatedly in small pieces for two years without noticing.
Quick check
A team studying restaurant reservation apps for inspiration on their own healthcare booking flow is using which technique?
4
Desirability, Feasibility, Viability
Three tests decide whether an idea survives, and it has to pass all three. They tend to be failed in a predictable order of expense.
Desirability: does anyone actually want this? Feasibility: can we build it with the people, data and systems we have? Viability: does it work for the business — can it be sold, supported and priced, and is it legal?
Viability is the one that gets skipped, and the reason is structural rather than careless — it is the only one with no obvious owner. Desirability belongs to product, feasibility to engineering, and viability sits between finance, legal, support and sales, which in practice means it sits with nobody until something goes wrong late.
The habit that fixes it is unglamorous: screen all three early and cheaply, before the expensive work. A landing page tests desirability in days. An engineer’s afternoon tests feasibility. A short conversation with finance and support tests viability.
The aim is not certainty. It is to fail a bad idea in a week rather than a quarter — and the cheapest available test is almost always the one nobody scheduled.
Desirability
Do users actually want this? Grounded in research, not a hunch.
Feasibility
Can we build it with the technology, skills, and time we have?
Viability
Does it make sense for the business, cost, revenue, strategic fit?
Two of these circles have an owner in the building and the third does not, which is why the usual failure is two tests cleared and the third fatal, found after the design is finished. Each has a cheap version — a landing page, an engineer’s afternoon, one conversation with finance and support — and the expensive one is always the test nobody scheduled.
Everyday example
A restaurant idea has to pass three tests: would anyone come, can we cook it, does it make money at that price. Failing any one of them ends it, and they are usually failed in that order.
Desirable, feasible, and quietly unviable
A feature tested beautifully with customers and was straightforward to build. It also required a per-seat licence from a third party that cost more than the plan it would ship in. Two green lights and one red, discovered after the design was finished, because viability had no reviewer until legal saw it.
Quick check
A brilliant idea scores extremely high on desirability but the team has no way to build it with current technology or skills. What lens is failing?
Drill what you learned
Scenario 1
easy
A team skips writing a How Might We question and jumps straight from "users are confused at checkout" to brainstorming feature ideas.
What's the risk?
Scenario 2
easy
An HMW question reads: "How might we build a loyalty points system?"
What's wrong with it?
Scenario 3
easy
A fintech team studies how airlines handle overbooking and delay compensation while ideating a refund-dispute feature.
What technique is this?
Scenario 4
easy
A team is stuck and someone proposes: "What if we had to ship this with zero engineers, just no-code tools, by Friday?"
What technique is being used?
Scenario 5
easy
An idea scores high on feasibility and viability, but user interviews consistently show nobody wants it.
Which lens is failing?
Scenario 6
medium
A concept completes desirability and feasibility easily, but the cost to build and maintain it exceeds any plausible revenue.
Which lens is failing?
Scenario 7
medium
A PM mines support tickets and finds many customers requesting "please let us export to Excel."
What's the ideation-framework move?
Scenario 8
medium
A team writes an HMW so broad — "how might we make our product better?" — that the brainstorm produces unrelated ideas from everyone.
What's the fix?
Scenario 9
medium
A team has three concepts. One is highly desirable and feasible, but relies on giving the product away free — a model the company can't sustain.
What should happen?
Scenario 10
medium
A team generates fifty ideas from an HMW question but has no way to organize or evaluate them.
What's the next funnel step?
Scenario 11
hard
A team ideating a checkout improvement studies how video-game stores handle one-click, saved-payment purchases.
What kind of ideation source is this?
Scenario 12
hard
A stakeholder says an idea "feels desirable" based on their own personal preference, with no user research behind it.
What's the concern?
Scenario 13
hard
A team's ideation funnel has no insight feeding the top — ideas are generated from a leadership offsite with no research behind them.
What's the risk?
Scenario 14
hard
Two concepts tie on desirability and feasibility. One is a much bigger strategic bet; the other a small, safe improvement.
What should break the tie?
Scenario 15
hard
A team develops a concept fully — mockups, spec, cost estimate — before ever writing a How Might We question or gathering an insight.
What went wrong with their process?
Drilled it. Now apply it to a real situation.
Put it to work
From lesson 1
Gmail came out of the twenty per cent
Google
Google's "20% time" — engineers spending a portion of their week on
self-directed work — is widely credited with producing Gmail, AdSense
and Google News. Paul Buchheit started Gmail as one such project.
What is less often noticed is that the ideas did not go straight to
launch. They entered a funnel: most 20% projects produced nothing, a few
became prototypes, fewer still were resourced, and a handful shipped.
What does treating ideation as a funnel change?
Select all that apply — there are 3 to find.
What actually happened
Google has since wound 20% time down considerably, and the funnel idea
outlived the specific policy. Wide at the top, explicit stages, an
accepted low survival rate — that structure is what the practice was
actually providing.
Ideation is a funnel, not a moment. Wide at the top, narrow at the
bottom, and the ratio between them is what tells you how much
generation you need.
From lesson 2
How Might We, scoped three ways
A pharmacy chain
The insight: elderly customers collecting repeat prescriptions often
cannot remember which of their medicines they have already collected, and
will not ask because they find it embarrassing.
Three How Might We questions are drafted from it.
Order them from the best-scoped to the worst.
Drag the rows, or use the arrows, then check.
"How might we help someone collecting repeat prescriptions know what they already have, without having to ask?"Best. It keeps the insight's specific constraint — without having to ask — which is the part that rules out the obvious answers and forces genuinely new ones.
"How might we make repeat prescription collection less confusing?"Second. The right area, with the constraint dropped. It will generate reasonable ideas and none of them will address the embarrassment that caused the problem.
"How might we improve the pharmacy experience for elderly customers?"Third. So broad that any idea qualifies, which means the session produces volume with nothing to select on.
"How might we build an app that tracks a customer's medicine collection history?"Worst. A solution phrased as a question. It forecloses every non-app answer, including the printed card that turned out to work.
What actually happened
The winning idea from the first framing was a card in the bag listing
what was inside and what was still due — no app, no conversation, no
asking. The fourth framing could not have reached it.
A How Might We should be narrow enough to exclude ideas and wide enough
to admit more than one. Carry the constraint from the insight into the
question.
From lesson 3
Generating at the right altitude
A car insurance app
The brief: how might we help drivers feel confident they are on the right
cover? An hour of generation produces 34 ideas. Sorting them afterwards,
the team notices they sit at very different levels.
A sample of what was generated
Idea
Level
Change the tooltip copy on 'excess'
Detail
A cover-comparison view against similar drivers
Feature
Annual cover review as a service, with a human
Product
Move from selling policies to selling ongoing protection
Business model
Bigger font on the summary page
Detail
What should the team do with a set of ideas spread across levels like this?
Select all that apply — there are 3 to find.
What actually happened
Sorted into three piles, the quarter took two detail fixes and one
feature. The business-model idea went to the strategy review, where it
became a serious proposal a year later — and would have been thrown away
the same afternoon under a single-ranking process.
Ideas come out at different altitudes. Sort by level before ranking, or
the cheapest idea wins every comparison it should not have been in.
From lesson 4
Desirable, feasible, viable — pick the one that kills it
A grocery subscription
The shortlisted idea: a "never run out" service that predicts when
staples will run low and ships them automatically. Three lenses, three
different verdicts.
Work the three lenses in the order that saves the most money.
Step 1 of 3
Which lens should be applied first?
Here viability is the cheapest: a spreadsheet, an afternoon.
Step 2 of 3
The model shows automatic shipments would average £11 of goods against £4.20 of picking and delivery cost. What does that tell you?
The constraint reshapes the concept: predict a whole week's staples and ship once, not each item as it runs low.
Step 3 of 3
Reshaped, an average basket of £34 against £4.20 works. What is the next lens, and what would it need to show?
Twenty households, run by hand for a month. Nine loved it, six cancelled after one delivery containing something they did not want.
What actually happened
The concierge test produced the feature that decided the product: a
24-hour window to edit the basket before it ships. Desirability was not
binary — it was conditional on control, which no amount of prediction
accuracy would have supplied.
Apply the three lenses in order of cheapest evidence against most likely
to be fatal. Each one that fails should reshape the idea before the next
is applied, rather than ending it.