Your largest customer emails on a Friday. They want a custom approvals workflow, and the message hints that renewal depends on it. Sales forwards it with “urgent” in the subject line, engineering estimates six weeks, and by Monday the feature is on the roadmap. Nobody has asked whether your other customers need approvals, or whether approvals are even the problem this customer is trying to solve.
Product discovery is the work that happens before that commitment. It is a short, structured period of learning that tests whether an idea is worth building, using evidence that costs far less than the build itself. Done well, it gives you one of three answers: build it, reshape it, or drop it. Each of those answers saves money compared with finding out after launch.
This guide covers what discovery should answer, a step-by-step process for a single decision, how much discovery a decision deserves, and how to judge whether your evidence is strong enough to fund development.
What Product Discovery Should Answer Before You Commit
A useful way to frame discovery is around risk. Product leader Marty Cagan groups product risk into four types, and each one needs different evidence. Value asks whether customers will choose to use or pay for this. Usability asks whether people can work out how to use it without help. Feasibility asks whether your team can build it with the time, skills and systems you have. Viability asks whether it works for the business, including sales, support, legal and margins.
Most teams test usability first because it feels concrete. You can watch someone click through a prototype and see them struggle. Value is harder to test, so it gets assumed, and an untested value assumption is the usual reason a feature ships and then sits unused. A beautifully usable approvals screen is wasted if customers route approvals through email and have no wish to change.
Requests are guesses at solutions
When a customer asks for a feature, they are proposing a solution to a problem you have not seen yet. “We need approvals” might mean the customer’s finance team was burned by an unauthorized purchase, or that an auditor asked for a paper trail, or that a new manager wants visibility of what their team spends. Each of those problems points to a different build, and one of them might be solved by a report you already have.
Before anything else, write the problem in the customer’s words without naming a feature. If you cannot describe the problem without describing your solution, you are still looking at the request, and discovery has not started.
A Five-Step Discovery Process for One Decision
Discovery works best when it is attached to a specific decision with a deadline. “Learn more about our users” never ends. “Decide by the 30th whether approvals go into Q3” does.
1. Name the decision and the outcome
Write down the decision you need to make, the date you need to make it, and the outcome metric that would show the problem is solved. For approvals, the outcome might be fewer support tickets about unauthorized spend, or a higher renewal rate among accounts with more than fifty users. A clear outcome stops the team from chasing every interesting thing they hear.
2. Gather evidence of what people do today
Start with behavior. In interviews, ask about the last time the problem happened: who was involved, what they did, what it cost them. “Walk me through the last time a purchase went through without sign-off” produces facts. “Would you use an approvals feature?” produces polite guesses.
Pair interviews with what you already have. Product analytics show where people stall. Support tickets and sales call notes show how often the problem comes up and in which accounts. Talking to six or eight customers from the right segment usually tells you more than a survey of hundreds, as long as you recruit carefully. Our guide on how to recruit users for user research covers screening so you are not just hearing from your friendliest accounts.
3. List the assumptions and rank them
Every idea rests on things that must be true for it to work. List them plainly: “Customers with more than fifty users have approval problems.” “Managers will check a queue at least daily.” “We can add approval states without rebuilding the order model.”
Then rank each assumption on two questions. How bad is it if this is wrong? How much evidence do we have? The assumptions that are both critical and unsupported go to the top of the list. That is where your first test belongs.
4. Pick the cheapest test that could prove you wrong
Match the test to the type of risk. A good test is small, quick and able to fail. The table below gives common options.
| Risk you are testing | Low-cost tests | What a pass looks like |
| Value | Fake-door button, landing page, concierge service run by hand, pre-sale or letter of intent | People take an action that costs them time, data or money |
| Usability | Clickable prototype with five or six target users | Most participants finish the core task without help |
| Feasibility | Technical spike or proof of concept | Engineers confirm the approach and a realistic estimate |
| Viability | Review with sales, support, legal and finance | No blocker on pricing, support load or compliance |
Test two or three alternative solutions where you can. People react more honestly when they have options to compare, and you avoid falling for the first idea that sounded good. The principles of rapid prototyping in software development apply here: build only what you need to answer the question in front of you.
5. Set pass criteria before you run anything
Decide what result would count as a pass before you see the data. “At least five of eight target admins complete the approval task unaided” or “Three of our ten largest accounts agree to pilot a manual version” are criteria you can act on. Without them, every result gets read as encouraging.
When discovery says build, the next risk is building too much. M7’s MVP development team works in a build, measure, learn cycle, so the first release is scoped to the evidence you have and designed to answer the next open question with real usage data.
How Much Product Discovery Does a Decision Deserve?
The right amount of discovery depends on what it costs to be wrong. Three factors set the size of the timebox.
Reversibility. A copy change or a new filter can be rolled back in a day. A new pricing tier, a data model change or a public API is hard to undo. The harder a decision is to reverse, the more evidence it deserves.
Access. Some users are easy to reach. Others, such as enterprise buyers, clinicians or finance controllers, take weeks to schedule. Plan around that, or the timebox fills up with waiting.
Complexity. A feature that touches several roles, systems and rules has more assumptions hiding in it, so it needs more tests.
As a working rule, a small reversible change might need a day or two of checking, a new feature set a few weeks, and a new product line longer. When the timebox ends, make the call with what you have. A useful stopping test: if another two weeks of research would not change the decision, stop researching and decide.
Reading the Evidence: Build, Reshape or Drop
You will never reach certainty. You need enough confidence that the remaining risk is cheaper to learn through a careful build than through more research.
Weigh evidence by what it cost the person giving it. Strong evidence includes people paying, signing a pilot agreement, entering real data, or using a manual version of the service more than once. Weak evidence includes compliments, “I would definitely use that”, survey intent and requests from a single loud account. Weak evidence is a reason to keep testing, never a reason to commit a quarter of engineering time.
Then make one of three calls. Build when value and usability tests pass and engineering has confirmed feasibility. Reshape when customers want the outcome but your proposed solution misses, which is common and usually points to a simpler build. Drop when the problem matters less than you assumed. Dropping an idea is a good result, because it frees budget for something with stronger evidence.
Back to the approvals request. Suppose interviews show that most large accounts want visibility of spending, and very few want a blocking approval step. The reshaped answer might be a weekly spend summary for managers, built in two weeks, with a manual approval option offered to the one customer who needs it. That is a better outcome for everyone, including the customer who asked.
Keeping Discovery Running Alongside Delivery
Discovery works best as a habit, not a phase that ends when design begins. Many teams use a product trio of a product manager, a designer and an engineer who share responsibility for learning. Each sees different risks: the product manager watches value and viability, the designer watches usability, and the engineer spots feasibility problems early, often before the team falls in love with an idea that cannot be built on the current stack.
Keep the cadence light. One or two customer conversations a week, a shared log of assumptions and test results, and a short review at sprint planning will keep a team grounded. Running discovery and delivery side by side, with the same people involved in both, avoids the handoff where a research report lands on a build team that never met a customer. For SaaS teams planning this in practice, this guide to aligning your product roadmap with UX discovery and engineering shows how to plan both tracks against one roadmap.
Product Discovery Mistakes That Waste Budget
Validating a decision that has already been made. If the feature is promised to a customer and sold internally, research becomes theater. Run discovery before commitments are made, or be honest that the goal is to shape the build, not to decide whether it happens.
Asking people to predict their own behavior. “Would you use this?” and “How much would you pay?” produce answers people believe at the time and rarely act on. Ask about past behavior and test with actions instead.
Testing only with your happiest customers. Your most engaged accounts are easy to reach and generous with praise. They are also the least like the customers you are trying to win or keep. Recruit from the segment the decision affects.
Letting results sit in a slide deck. Evidence that does not change the backlog changes nothing. Every test should end with an update to the roadmap, the scope or the list of assumptions.
Make the Next Roadmap Decision on Evidence
Pick one item on your current roadmap and list the assumptions it depends on. Mark which have evidence behind them. If the most important one has none, schedule a test this sprint, before any more design or engineering time goes in.
M7’s strategists, UX designers and engineers work through discovery, design and build as one team, so what you learn in research carries straight into the product. If you want a partner to test your next big idea before you fund it, see how M7 runs product strategy, design and development.
Frequently Asked Questions
What is the difference between product discovery and user research?
User research is one input to product discovery. Discovery also covers feasibility checks, business viability, prioritization and the decision itself. Research tells you what is true for users; discovery turns that into a choice about what to build.
Who should own product discovery?
The product manager usually owns the decision and the timebox, but discovery works best as a shared responsibility with design and engineering. When all three take part, fewer insights get lost and feasibility problems surface early. Stakeholders should review the evidence, not just the conclusion.
Can you do product discovery for an existing product?
Yes, and existing products have an advantage: live usage data. You can test new ideas against real behavior, run fake-door tests inside the product and interview active users within days. Most discovery work in established companies happens on products that are already live.
What should a product discovery phase deliver?
At minimum, a clear decision with the evidence behind it, a ranked list of the assumptions that remain, and a scope for the first build if the answer is to go ahead. Prototypes and test notes are useful supporting material, but the decision is the main output.
