Product discovery: how to de-risk a software project before development

Why so many builds start from a guess

Most custom software projects begin the same way. Someone senior describes a workflow that frustrates them, and a quote is requested. Product discovery is the step that goes missing in between, and its absence is expensive. CB Insights analysed 483 startup post-mortems and found that 42% cited no market need as a reason for failure, ahead of running out of cash at 29%.

The same pattern shows up in established businesses. McKinsey worked with the University of Oxford across more than 5,400 projects and found that large IT projects run 45 percent over budget while delivering 56 percent less value than predicted. Both numbers are clear indicators that the real problem came from decisions before the actual development.

How product discovery de-risks

Every software project carries four risks, and only one of them is technical. Marty Cagan, who ran product at eBay and now advises product teams through Silicon Valley Product Group, defines the job of discovery as addressing value risk and usability risk. He also includes feasibility risk and business viability risk. A team that only asks "can we build it" has answered one question out of four and paid for the privilege of finding out about the rest later.

The cost of learning late is what makes this worth doing properly. NASA's analysis of error cost escalation found that a requirements error caught during the requirements phase costs one unit to fix, while the same error found at the operations phase ranged from 29 units to more than 1,500. Skipping product discovery defers the planning cost and adds a multiplier.

Then there's the quieter waste. Some features, despite being requested, are not used enough to justify developing them. Here's what usually gets treated as justification when it isn't:

• A stakeholder's confident description of how the team works, which describes how the process is supposed to work rather than how it actually does

• Enthusiastic feedback from people who support you. This is exactly what Rob Fitzpatrick means in The Mom Test when he argues that opinions are worthless: what a feature actually needs to prove itself is facts and commitments rather than compliments

• A competitor's feature set, which tells you what they decided to build and nothing about whether it worked

Product discovery is a shorter, cheaper way of finding out which of your assumptions are wrong while it's still affordable.

Product versus technical discovery

The two get conflated constantly, and it causes real confusion in procurement conversations. Product discovery answers whether you should build anything at all and what that thing needs to do. Technical discovery answers how it can be built and what the existing estate will allow.

You need both, but in that order. A technical discovery run against an unvalidated concept produces a beautifully detailed architecture for something nobody wants. Run the other way round, and you get a validated user need from product discovery with no idea whether your CRM will expose the data required to serve it.

The two connect at specific points, and those connections are where scope quietly doubles:

1. Integration reality. If the workflow depends on data that lives in a supplier's system, API access limits and permission rules decide whether the idea is buildable at the price you had in mind.

2. Legacy constraints. Older systems can't provide the events or real-time data a new interface assumes.

3. Regulatory dependencies. Under Article 25 of the UK GDPR, you must build data protection into the design from the point you determine the means of processing, and a Data Protection Impact Assessment is a legal requirement for high-risk processing. Discovering that after the design is signed off means redesigning.

Bring an engineer into the room during product discovery. The person who knows what the integration will cost needs to hear the user problem first-hand.

Run product discovery

What follows is a sequence where each step produces something the next step depends on. Skipping one shows up two steps later as a disagreement nobody can resolve with evidence.

Product discovery takes weeks. If discovery is running longer, that's a sign the problem hasn't been framed tightly enough, which is where we start.

Frame the problem

Write down who has the problem and what they do today, including what would be different if the problem went away. That's the entire output, and it's harder than it sounds because the proposed solution keeps trying to sneak in. "We need a portal" is a solution request. The problem statement is "Account managers spend two days a month re-keying order data between two systems and errors reach the customer."

Amazon formalised this with its Working Backwards process, where teams write the launch press release before the product exists. Jeff Bezos described it as a huge amount of work that saves even more work later, designed to make sure the team is building the right thing. The discipline is in the constraint. If you can't explain why it matters to the person using it, you don't build it.

Conduct user research

Now go and check. Steve Blank, who teaches customer development at Stanford, has been repeating the same line for two decades: "There are no facts inside the building", so get outside. Internal certainty is a hypothesis wearing a suit.

Good user research at this stage is mostly interviews about past behaviour and observation of the actual workflow. Fitzpatrick warns that "I would definitely buy that" is the world's most deadly fluff, because people are wildly optimistic about their future selves.

You don't need a large sample to learn a lot. Jakob Nielsen's long-standing finding at Nielsen Norman Group is that testing 5 users in a qualitative study finds almost as many problems as testing many more, with roughly 3 to 4 per group when you're serving distinct audiences. Quantitative claims need at least 20. At this stage you're finding out through user research whether the problem is real.

Sit with the existing data too. Support tickets and the spreadsheets people built to work around the current system tell you where the friction actually is. Teresa Torres, who wrote Continuous Discovery Habits, defines the practice as "weekly touchpoints with customers" by the team building the product, rather than a research report arriving six weeks late.

The output of user research is a short list of confirmed needs and beliefs you've disproved. That last category is the valuable one.

Align stakeholders

Get the decision-makers in one room with the evidence from user research. This is where conflicting expectations surface, and surfacing them now is far cheaper than surfacing them during a sprint review. PMI's Pulse of the Profession found that 52 percent of projects experienced scope creep, up from 43 percent five years earlier.

Before anyone estimates anything, agree on who the target user is and what business goal the work serves. Also settle the hard constraints and who gets to make the call when priorities conflict. Write down the answers. Unwritten decision rights are the reason two directors can both believe they own scope.

Colette Wyatt, CEO of Evolved Ideas, has seen the pattern repeat across delivery engagements: "Distance is rarely the thing that causes delivery problems. Unclear ownership and inconsistent communication do far more damage." The same applies before the build. Ambiguity about who decides is a delivery risk you can eliminate for the price of a workshop.

Test critical assumptions

List what has to be true for this to work, then rank by how much damage a wrong answer would do. Cagan's warning about prototype testing is worth holding onto here: novice teams put a high-fidelity prototype in front of 15 people who say they love it, then think they've validated the product. People say all kinds of things and then go do something different.

So test in ways that cost people something. A pricing page that measures click-through or a signed letter of intent from a prospective customer. Cagan's assumption is that at least half of ideas won't work, and the best teams assume three-quarters won't. Design your tests to find that out in days.

Feasibility gets tested differently. Give an engineer the riskiest technical assumption and a short timebox to prove or break it. If the integration you're depending on turns out to be rate-limited or read-only, you want that finding while the design is still a sketch.

Set commercial guardrails

A business case requires more than a validated user need. Some genuine problems cost more to solve than they return, and this is the section where founders and operations leads skip ahead.

Work through the money. Then set it against build cost and the annual maintenance that rarely appears in the original quote. If the case is efficiency rather than revenue, put a number on the hours saved and the error rate reduced, then convert it.

The useful discipline is to invert the question. Instead of forecasting a return, state what would have to be true for the investment to make sense: the adoption rate you'd need and the volume threshold below which it doesn't pay back. Now you have testable conditions rather than a spreadsheet built on optimism.

Regulatory dependencies belong in this calculation too. If the product handles health data, payments, or children's data, compliance work is a cost line and a timeline factor. The Information Commissioner's Office can issue fines of up to £8.7 million or 2% of global annual turnover for failing to carry out a required DPIA. That's not a detail to leave for the technical lead to discover.

Apply feature prioritisation

By now you have more candidate capabilities than budget. Feature prioritisation is how you decide which ones survive, and it works best when the criteria are agreed before anyone argues about a specific feature.

Rank each capability for feature prioritisation by the user value the evidence supports and what it costs to build. The strength of that evidence and the risk it carries belong in the same ranking. A capability with strong evidence and low effort ships first. A capability everyone loves with no supporting evidence goes into a holding list where it can be tested.

The MoSCoW method, created by Dai Clegg in 1994 at Oracle and later formalised within DSDM, is still the most practical way to communicate this to a mixed group. Must, Should, Could, Won't. The value is in the last category. Explicitly naming what you won't build in this release stops it reappearing as an assumption during development.

Your minimum viable product boundary sits at the smallest set of capabilities that tests the core proposition end to end. Everything a user needs to complete the central task once, and nothing that merely makes the experience nicer. Feature prioritisation done properly gives you a defensible line you can point at when someone asks why their request isn't in scope. It's defensible because it's evidence-based, not because you fought harder for it.

Good feature prioritisation also protects the build team. When a change request arrives mid-sprint, the question becomes which prioritised item it displaces, rather than whether there's room to squeeze it in.

Define success metrics

Pick metrics that tie back to the problem you framed at the start. If the problem was two days of re-keying per account manager per month, the metric is hours spent on that task.

Google's HEART framework, developed by Kerry Rodden, splits experience measurement across five dimensions including happiness and task success. Rodden's own caveat is the important part: "Metrics are not useful unless they are aligned closely with the team's high-level goals." Pick two or three that map to your problem and ignore the rest.

Two things must happen before development starts. Record the baseline, because a metric without a starting number can't demonstrate improvement. And set the decision thresholds now: what result means continue and what result means stop. Agreeing those in advance removes the temptation to reinterpret a disappointing number as encouraging.

Decide what happens next

Product discovery ends in a decision. There are four honest outcomes, and stopping is one of them.

• Go. The problem is confirmed, and the priority scope is clear enough to estimate.

• Revise. The problem is real, but the proposed solution isn't the right response to it.

• Test further. One critical assumption remains unresolved, and a further experiment costs less than building around the uncertainty.

• Stop. The evidence didn't support the case, and you've saved the build budget.

Whichever you choose, the handover pack is the same. Development teams need the validated problem statement and the prioritised scope with the explicit out-of-scope list. They also need the risks still open and the evidence behind each priority call. Give an estimator that and you get a defensible number. Give them a feature list, and you get a guess with a risk premium built in.

Get discovery support

Independent product discovery works because the people running it have no stake in the answer being "yes, build it." Evolved Ideas has spent more than 19 years advising startups and enterprises on exactly this question, and the consultancy process starts with a workshop to collect facts and validate assumptions before any build vs buy recommendation is made.

If you're weighing a custom build or an MVP and want the assumptions tested before you commit budget, it's worth speaking to our team about product discovery first.