Most software budgets are not wasted on bad code. They are wasted on good code that builds the wrong thing. A feature nobody uses costs exactly as much as one everybody loves.
Product discovery is the work you do before building to make sure you are building the right thing. It sounds obvious. It is also the step teams skip most often, usually because it feels slower than just starting.
The cost of changing your mind
- 01
Whiteboard
Minutes. Discovery is cheapest here.
- 02
Design file
Hours. Prototypes make assumptions visible.
- 03
Live software
Days or weeks of rework when discovery is skipped.
What discovery actually involves
Discovery is not a long research project. Done well, it is a few focused weeks, sometimes less. The core activities are:
- Talking to real users. Not asking if they like your idea, but asking how they handle the problem today, what it costs them, and what they have already tried.
- Looking at what already exists. Competitors, spreadsheets, WhatsApp groups, paper forms. Whatever people use now is your real competition.
- Listing your assumptions. Every product rests on beliefs like "shop owners will pay monthly" or "drivers have smartphones with data". Write them down and rank them by how badly things go if they are wrong.
- Testing the riskiest ones cheaply. A landing page, a clickable prototype, a few manual trials. Anything that gets real evidence before you write production code.
- Agreeing on scope. Ending with a clear, prioritised list of what to build first and why. A typical discovery plan Phase Key activities What you get
Why it saves money Changing your mind costs almost nothing on a whiteboard. It costs a bit more in a design file. In a live product with real users and real data, it can cost weeks of rework.
Discovery moves the expensive mistakes to the cheap stage. You still make them, because everyone does. You just make them when fixing them takes an afternoon.
It also makes estimates far more reliable. A team that understands the problem can quote with confidence. A team working from a one page idea is guessing, and guesses tend to go up over time, not down. PMI's Pulse of the Profession research found that 47% of unsuccessful projects missed their goals because of inaccurate requirements management, which is exactly the gap discovery closes.
How to ask good discovery questions
The quality of discovery depends on the quality of your questions. Ask about the past, not the future. "Tell me about the last time this happened" gets you facts. "Would you use an app that does this?" gets you polite guesses. Teresa Torres writes well about this habit of regular customer conversations at Product Talk.
Signs you are skipping discovery
- Your feature list came mostly from your own team, not from users.
- You cannot name five real people who have the problem.
- Different people in your company describe the product differently.
- The build has started but the requirements keep changing every week.
If two or more of those sound familiar, a short pause for discovery will probably save you time overall.
Who should run it
You can do discovery in house if you have someone with product experience and the time to do it properly. Many teams find it useful to bring in an outside view, because it is hard to question your own assumptions. Someone without a stake in the original idea will ask the uncomfortable questions sooner. What you should have at the end
A good discovery phase leaves you with a clear problem statement, a defined first user, a prioritised feature list, the main risks and how you will handle them, and a realistic estimate. That is a far stronger starting point than a feature wishlist.
- A one paragraph problem statement your whole team agrees with
- A named first user and their main job to be done
- A ranked list of assumptions, with the riskiest already tested
- A prioritised scope for version one
- A realistic estimate and timeline
How long discovery should take
There is no fixed rule, but discovery should match the size of the bet. A small internal tool might need a few days of conversations and a short scoping workshop. A new product for a new market deserves more time, because the cost of being wrong is higher. The test is simple: keep going until your riskiest assumptions have real evidence behind them, then stop. Discovery that drags on for months has usually turned into a way of avoiding decisions.