In short
- 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?
Product discovery is 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 prioritization, 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 prioritization |
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.
What product discovery techniques are worth running?
Four, and each answers a different one of the three questions above.
Interviews are for whether a problem is real. A structured conversation about a specific recent moment, not a general opinion about the product.
Support ticket mining is for the same question at volume, reading through a stretch of tickets and sorting the situations that repeat from the ones that were a single person's bad day.
A standing request board is for whether a problem is common, because it turns the same situation arriving from different people into one entry with a count.
Usage data is the only technique here that doesn't rely on somebody telling you anything. It answers whether a problem is real by showing where people get stuck or give up, and it's the one to trust when what people say and what they do disagree.
Surveys sit between interviews and a standing board: faster to run than an interview, blunter, and good for a rough read across a group too large to talk to one at a time.
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.
What is the product discovery process?
The product discovery process is six steps, and the split between them is the part most descriptions miss.
- 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 prioritize. 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.
What are the product discovery activities in a normal week?
There are three product discovery activities in a normal week, and none of them takes a whole day.
Read what arrived. New requests, new comments on old ones, support tickets tagged as a request rather than a fault. Twenty minutes if the intake is tidy.
Talk to one customer. One a week is fifty a year, which is more customer conversations than most product teams manage, and it fits in an hour.
Write one decision down where the person who asked can see it. One request refused with a reason, or one accepted and put on the roadmap. This is the activity that gets skipped, and skipping it is why the same request arrives again in three months.
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 VoteFirst 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.
