The short version
- Discovery is finding out which problems are real, common, and worth solving, before committing effort.
- A request is a situation and a count in one artefact, which makes a standing list the cheapest instrument.
- Discovery as a phase doesn't hold, and this says why.
- Asking about the future produces speculation. Ask about a specific recent moment.
Product discovery is the work of finding out what to build before building it. That's the whole definition and most of the disagreement about it's about ceremony, not substance. Continuous discovery is that same argument with a cadence attached, which is a real distinction and a smaller one than the word suggests.
The substantive question is what discovery produces, and the answer is two things, situations and counts. Almost every activity people call discovery is producing one of those or neither.
What is product discovery?
Finding out, before committing effort, which problems are real, which are common, and which are worth solving.
Three separate questions and they need different instruments. Whether a problem is real comes from talking to somebody who had it. Whether it's common comes from counting. Whether it's worth solving comes from what it costs against what it's worth, which is prioritisation, not discovery.
The reason discovery gets confusing is that teams reach for one instrument and try to answer all three with it.
There's a standing collection running, not a description of one, and the demo is open without an account.
Doing this in a tool rather than a spreadsheet? Twenty one feature request tools and the eight units they bill on. The unit decides the bill, not the headline price.
What discovery produces
| The output | Where it comes from | What it settles |
|---|---|---|
| A situation, in the user's words | Interviews, support tickets, written requests | Whether the problem is real, and what it actually is |
| A count of people with that situation | A standing request list, usage data | Whether it is common |
| A cost | An effort estimate | Nothing on its own, but it is half the prioritisation |
Anything a discovery activity produces that's not in that table is an opinion. Opinions are allowed and useful. The problem is only when they arrive labelled as findings.
Where requests fit in
A request is a situation and a count in one artefact, which is why a standing request list is the cheapest discovery instrument there is.
It's also the most misunderstood, in both directions.
It's not a substitute for talking to people. A request list can only measure agreement with problems somebody thought to write down. The problem nobody has articulated will never appear on it, and finding those is what interviews are for.
It's not just a wish list either. The common dismissal is that customers ask for solutions rather than problems, which is true of the raw text and irrelevant once you rewrite each request as a situation. The rewriting is the work, and after it the list is a set of problems with counts attached.
The sequence that works
- Collect continuously. Requests arrive whenever somebody has one, not when you run a phase.
- Rewrite each as a situation with a cost. "Add filters" becomes "checking one client's requests means reading the whole list".
- Let other people agree with it. This is what turns one message into a count, and it costs nothing but a public page.
- Interview against the top of the list. Five conversations with people who voted for the same thing, about the specific moment.
- Estimate the effort. One rough number per item.
- Then prioritise. Which is a different activity with its own methods.
Steps one to three run all the time. Steps four to six happen when you've room to build something, which is the practical difference between discovery as a habit and discovery as a phase.
Discovery as a phase, and why it does not hold
The phase version puts all of the above into a fixed window before a planning cycle. It fails for a mechanical reason, not a philosophical one. The count in step three needs time to accumulate.
A request posted the week before a planning cycle has had a week to collect agreement. One posted six months ago has had six months. Running the collection continuously and the analysis periodically is the only arrangement where the counts mean the same thing.
What discovery is not
Not validation. Validation is checking a thing you already decided. Discovery is finding out what to decide, and calling the first one the second is the most common way a quarter's plan gets a research shaped justification attached to it afterwards.
Not a workshop. A workshop chooses among options. It doesn't produce them.
Not competitor analysis. That tells you what other products have, which is information about them.
Not a phase with a deliverable. The deliverable framing pushes towards a document, and the useful outputs are a list and some quotes.
The mistakes
Asking about the future. What would you do produces speculation. What did you do last time produces a situation.
Counting internal opinions in the same list as customer requests. Internal people are more available and write better, so they win by default.
Treating a raw vote count as a finding. A count on a board that anybody can vote on measures whoever showed up, unless you know who voted.
Doing the collection in bursts. Then the counts are a function of when the request was posted rather than how many people want it.
How do you do this without a tool?
Interview notes with verbatim quotes in one document, requests in a spreadsheet with a rewritten situation column and who asked, effort estimates added when you get to them.
The step that doesn't work on paper is step three, because agreement requires the other users to be able to see the request. Without it, every count is your own record of who happened to mention something to you.
How does this product do it?
The collection runs continuously on a board. Requests carry the people who wrote them and the people who agreed, so the count is distinct people. Nothing a visitor writes appears publicly until somebody approves it, so an open board doesn't turn into noise.
Each voter carries whatever you know about them, including the revenue on the account, so the count can be read by weight rather than by headcount. Each card carries an effort estimate, which is step five, and the board can be ordered by the priority demand and effort produce, which is step six.
The feedback board page covers the board, and product discovery examples compares the activities.
Roadmap development covers what happens to a discovery finding afterwards.
14 days, a card at signup, then $9 or $39 a month.
