Published:
Get personalized guidance to refine your product strategy and achieve market success.
Building software is expensive in the obvious way: salaries, infrastructure, tools. It's also expensive in quieter ways. Every feature that ships has to be supported, maintained, and tested again with each release. Every month spent on the wrong thing is a month the right thing didn't get built. And a launch that goes nowhere takes something out of the team that doesn't show up in any budget.
Two data points show how common the problem is, and both come with limits worth knowing:
Discovery doesn't guarantee you'll choose well. What it does is move the moment you find out you're wrong. A prototype that tests badly costs days. A feature that tests badly after release costs the months it took to build, plus everything it kept you from building instead.
Discovery is most valuable when uncertainty is highest. In practice that means three moments:
Teams that do this well often keep a lighter version going permanently, with regular conversations with users running alongside the build instead of stopping when development starts. That's usually called continuous discovery.
One honest caveat: not every change needs a full discovery effort. Changing a button label doesn't need an interview round. The effort should scale with the risk of being wrong, and a good team learns to tell the difference.
Every team runs the product discovery process a little differently, depending on its stage, budget, and how much is still unknown. Even so, most teams follow a similar path from problem to decision. The table below shows the seven product discovery steps most teams work through, what happens in each one, and what it produces.
The discovery phase of product development isn't a straight line. Step 6 often sends a team back to step 4, and sometimes all the way back to step 2, when a test shows the problem was framed wrong. That isn't failure. It's the process doing its job.
A product management framework doesn't do the discovery for you. What it gives a team is a shared structure and shared vocabulary, so people stop talking past each other. Four are widely used.
Created by the UK's Design Council in 2005, the Double Diamond describes design work as two diamonds. In the first, you explore the problem widely (Discover) and then narrow to a clear definition (Define). In the second, you explore possible solutions (Develop) and then narrow to one you can ship (Deliver). Its main value is separating two questions teams tend to blur: are we solving the right problem, and are we solving it well?
Popularized by Clayton Christensen, Jobs to Be Done starts from the idea that people "hire" a product to make progress in a particular situation. The focus moves from who the customer is (age, role, industry) to what they're trying to get done and what they currently use instead. That last part is often the useful surprise: the real competitor may be a spreadsheet, a workaround, or doing nothing at all.
Teresa Torres introduced the Opportunity Solution Tree and explains it in detail in her book Continuous Discovery Habits. It's a visual map: a desired outcome at the top, customer opportunities (needs and pain points) beneath it, possible solutions beneath those, and assumption tests at the bottom. The tree makes it harder to fall in love with a single solution, because every idea has to connect to an opportunity and every opportunity to the outcome. It suits teams that run discovery continuously.
Developed by Jake Knapp at Google and refined at GV, a design sprint compresses discovery into about five days: map the problem, sketch solutions, decide, build a prototype, and test it with users. It works well when you have one big question and can get the right people in a room for a week. It's a poor fit as a replacement for ongoing discovery, because it answers one question at a time.
Most teams don't pick one and stay loyal to it. They borrow: Jobs to Be Done to understand the customer, an Opportunity Solution Tree to organize what they learn, a sprint when a question needs a fast answer.
Talk to people who actually have the problem, including those who left or never bought. The most common mistake is asking about the future ("Would you use this?"). People are polite and poor at predicting their own behavior. Ask about the past instead: "Tell me about the last time you had to do this. What did you do? What was annoying?" What people did is far more reliable than what they say they'd do.
Functional prototyping techniques exist on a spectrum, and the skill is matching the effort to the question:
For AI-driven products, this matters more than usual. Whether the model's output is good enough is often the riskiest assumption, and a static mockup can't test it. A prototype that uses real model output can. The principle is the same everywhere: don't write working code to answer a question a sketch could answer.
Every idea rests on assumptions: that users have this problem, that they'd pay to fix it, that you can build it, that it fits your legal and business constraints. List them, then rank each by how critical it is and how uncertain it is. Test the riskiest first, with the smallest experiment that could prove you wrong.
Marty Cagan groups these risks into four: value (will people want it), usability (can they figure it out), feasibility (can we build it), and business viability (does it work for the business). Agree what a pass looks like before you run the test, for example "most of the users we test can finish the task unaided." Without that, it's easy to read ambiguous results the way you were hoping to.
A good discovery phase ends with a decision, not just a document. Typical outputs include:
These outputs are the raw material for building a product strategy. Our product strategy guide explains how vision, positioning, and roadmap fit together once discovery has told you what is worth building.
Discovery decides what to build. Delivery builds it. The two are often described as separate tracks, and the differences are real:
In practice the two overlap. The best teams run discovery alongside delivery, so the next thing to build has already been tested while the current one is being shipped. And engineers belong in discovery from the start: feasibility is one of the four risks, and the people who'd build it are often the first to spot a problem.
Plenty of teams run good discovery on their own. Outside help makes sense when one or more of these is true:
A neutral outside team brings experience, extra hands, and the willingness to say an idea isn't working, which is hard to do about your own idea.
If several of those sound familiar, our product strategy team can run discovery as part of a wider roadmapping engagement: researching users and the market, testing the riskiest assumptions before engineering time is committed, and turning the results into a roadmap your team can execute. If you'd like a shorter, more focused starting point, a product discovery workshop brings stakeholders together to define project goals, target audience, and success metrics, and ends with a plan and clear next steps.
CodeFulcrum runs product discovery as the first stage of its product strategy work. Our team interviews users, maps the riskiest assumptions, and tests them with functional prototypes, so clients get evidence and a prioritized roadmap before committing engineering budget. Founded in 2019, CodeFulcrum has 60+ engineers across the US, UAE and Pakistan and a 4.8 rating on Clutch.
A product strategy is the plan that connects what your company wants to become to the specific product decisions that get you there.
If you're deciding what to build next and want evidence behind the decision, talk to our team. We'll help you work out whether discovery, a workshop, or a full strategy engagement fits where you are.
Market research studies the market as a whole: its size, competitors, and trends. Product discovery tests specific solutions with specific users to see whether they actually solve the problem. Market research is a useful input to product discovery, but it cannot show whether a particular design will work for a particular user.
Product discovery usually takes between 1 and 6 weeks. A design sprint answers one focused question in about 5 days, while the discovery phase for a new product often takes 2 to 6 weeks. Continuous discovery never fully stops, because it runs alongside development. A good rule is to stop when more research is unlikely to change the decision.
Product discovery costs depend on the scope, team size, and duration. A focused discovery workshop costs far less than a multi-week discovery phase with user research and prototypes. At CodeFulcrum, discovery typically ranges from USD 1000 - USD 2000. In most cases it costs a small fraction of building the wrong product.
A product manager usually leads product discovery, but it works best as a shared effort between product, design, and engineering. Engineers should join from the start, because technical feasibility is one of the four key risks discovery tests, and engineers often spot technical problems before anyone else.
Yes. Deciding what belongs in an MVP is a product discovery question, and an MVP built without discovery is a small version of a guess. The effort can be lightweight: a well-understood problem needs a few days of validation, while a new market needs several weeks of user research and testing.
Continuous product discovery is the practice of talking to users and testing ideas every week, alongside development, instead of in a single phase before building. Teresa Torres popularized the approach in her book Continuous Discovery Habits. It keeps the roadmap based on current user evidence rather than research that is months old.
A product discovery workshop is a structured session, or short series of sessions, that aligns stakeholders on goals, users, and success metrics. The product discovery process is the full cycle of research, prototyping, and testing that follows. A discovery workshop is a strong starting point, but it does not replace talking to real users.
Why Does Product Discovery Matter?
When Should You Do Product Discovery?
What Are the Steps in the Product Discovery Process?
Common Product Discovery Frameworks
Outputs and Deliverables of a Discovery Phase
Product Discovery vs Product Delivery
Common Product Discovery Mistakes to Avoid
When to Bring in Outside Help for Product Discovery
