Product discovery
that starts from the problem, not the feature list.
Product discovery sets out the problem, the people who have it and what the product proposes to do about it, before anything is built. It matters when the feature list arrived first and nobody can say whose problem it solves.
The real question
Whether anyone has the problem badly enough to change what they do today.
Step 01 of 06 · Product & Venture Building
The path
From idea
to launch.
Six steps, each feeding the next. This page is one of them.
- Product discovery (this page)
- MVPs
- UX
- Implementation
- Brand
- Launch support
01Questions
The questions
it answers.
Whose problem is it?
The audience is named as people in a specific situation, narrow enough that you know where to find them and who is left out.
What do they do about it today?
The current workaround is written down and treated as the competitor: the product has to beat what people already do.
What would count as better?
The proposition says in one sentence what changes for that audience, in terms that evidence could show to be wrong.
What has to be true for the idea to work?
Each thing that must be true is written down and marked as evidence or guess, so a guess cannot pass as a finding once the build starts.
02Pitfalls
Where it
usually breaks.
A solution with the problem written to fit
The feature list comes first and the problem statement is drafted to justify it. Nothing in the statement can rule a feature out, so the scope only grows.
An audience of everyone
The product is for anyone who might benefit. Every request then looks in scope, and there is no specific person to put an early version in front of.
Agreement counted as evidence
People are asked whether they like the idea, not what they did the last time the problem came up. Demand is then first tested at launch, when being wrong costs most.
The workaround left out of the comparison
The idea is compared with rival products, not with what people do today. The real alternative, a spreadsheet or nothing at all, goes unexamined, and switching looks easy.
03Approach
How I work
on it.
Start from what people do today
I begin with who has the problem and what they do about it now, working from behaviour and existing evidence, not opinions of the idea.
Write statements that can be wrong
With your team I write the problem, the audience and the proposition as plain sentences, each specific enough for evidence to contradict.
Write down what must be true
I list what must be true, about demand and about what can be built, mark each line as evidenced or still a guess, and record what was ruled out and why.
What you leave with
- A written problem statement: who has the problem, what they do about it today and what would count as better.
- A named audience, narrow enough to find and ask, with a note of who the product is not for.
- A product proposition in one sentence, set against the alternatives it has to beat.
- Assumptions marked as evidence or guess, what was ruled out and why, and a recommendation: build, test first or stop.
04Measures
What I
would measure.
Signals to read, not targets to hit: what counts as good enough is your team’s decision.
Share of assumptions backed by evidence
Count only what was observed or tested, not stated interest. A flat share means the build starts from the original guesses.
Requests the problem statement turns down
If none is ever turned down, the statement is probably too broad to decide anything, and scope is still settled one request at a time.
The team’s answers on who the product is for
Answers that converge show the statement is in use; answers that drift apart predict scope arguments during the build.
05Evidence
The topic,
in practice.
From my own ventures: the ideation stage of each timeline, with each venture labelled by its actual stage. They show problem framing; none records audience research at that stage.
Ventures of my own
YoMaxi
In development, not released: I wrote the brief and framed the problem, choosing life areas over one list. The audience is broad; no launch segment is validated yet.
Deal Wizard
Live as a free public beta: it began with a problem I knew as an investor and became a proposition for investors, deal sourcers and property professionals.
City Dreams
A trading business with a live site: its two customers, guests and owners handing over a flat, need opposite things, and I learned the model commercially.
Building or launching
something similar?
Tell me about the product, where it is today and what you need next.