Product Discovery: How to Validate Before You Build

The most expensive software is software nobody wanted. More precisely: software that solves a problem in a way that users don't want to use, built for a market that isn't as large as assumed, at a price point that doesn't match willingness to pay.

These mistakes are not caught in development. They're caught — expensively — at launch. Product discovery is the set of activities that catches them earlier, when the cost of changing direction is low.

Product discovery is the work you do before and during development to answer the question: are we building the right thing?

It's distinct from product delivery, which is the work of building what you've decided to build. Discovery is about reducing uncertainty. Delivery is about executing on decisions made with sufficient confidence.

The two are not sequential — you don't complete discovery and then begin delivery. In well-functioning product teams, discovery and delivery happen in parallel: you're always validating future decisions while executing on current ones. But for teams preparing to build their first product, or a significant new feature, front-loading some discovery work before committing to a build is usually the right sequence.

The teams that skip product discovery typically justify it one of two ways: they believe they already know enough, or they believe they'll learn faster by building than by researching.

The first belief is usually overconfident. Founders are not representative users. What seems obviously valuable to the people who conceived the product often looks different in the hands of people who didn't. The assumptions built into a product spec — about user behaviour, about willingness to switch from existing solutions, about the frequency of the problem being solved — are exactly the assumptions discovery is designed to test.

The second belief is sometimes correct. In some contexts, building a rough prototype and watching people use it does generate faster learning than a round of research interviews. But this is most true for usability questions — how people interact with a specific flow — and least true for strategic questions: whether the problem is worth solving, whether this market is the right one, whether the pricing model is viable.

Building to learn is expensive when what you're learning is that you've been solving the wrong problem.

Problem interviews. Conversations with people who are potential users of your product — before you show them anything you're building. The goal is to understand how they currently experience the problem you're solving: how often it occurs, how painful it is, what they've tried, why existing solutions fall short. Problem interviews are not about validating your solution. They're about understanding the problem from the user's perspective, which is often meaningfully different from your own.

The most important skill in a problem interview is listening without steering. Founders who've been thinking about their solution for months naturally try to guide conversations toward validating the solution they already have in mind. The discipline of a problem interview is to hear what's actually there.

Jobs-to-be-done mapping. Behind most product problems is a job the user is trying to get done — a goal they're trying to achieve, a progress they're trying to make in some aspect of their life or work. Understanding the job clarifies the product in ways that feature lists don't. Airbnb's job is not "find accommodation" — it's "feel at home in an unfamiliar place." That framing leads to entirely different product decisions than optimising for search and booking.

Mapping the job your product is hired to do — and the circumstances under which users hire it — reveals which features are essential and which are peripheral.

Prototype testing. A prototype can be a Figma mock-up, a paper wireframe, or a minimal working demo. The point is to create something concrete enough that users can react to it, without investing the engineering time of a real build. Prototype tests answer usability and comprehension questions: do users understand what this is, can they figure out how to use it, do they feel confident in what happens when they take an action.

Competitive analysis. What alternatives do your target users currently use? Why do they use them? What are those alternatives bad at? The competitive landscape tells you what users have already tried and why those solutions were insufficient — which shapes both your positioning and your feature priorities.

Pricing and willingness-to-pay research. Many products fail not because nobody wants them but because the economics don't work. Willingness-to-pay research — asking potential users directly about what they'd pay, or using techniques like the Van Westendorp pricing model — generates early signal about whether the business model is viable before you've built anything.

Enough to meaningfully reduce your biggest uncertainties. Not so long that you're using research as a way to delay the discomfort of building.

For most early-stage products, three to six weeks of focused discovery work — 10 to 20 user conversations, a round of prototype testing, and competitive analysis — is sufficient to validate or invalidate the core assumptions. If you're finding that discovery keeps surfacing new uncertainty rather than resolving existing uncertainty, that's often signal that the problem is not as well-defined as it needs to be before development makes sense.

Discovery doesn't end uncertainty. The goal is to reduce it to a level where building is a reasonable risk to take — not to eliminate it entirely, because that's not achievable before launch.

The markers that typically indicate sufficient discovery:

You can describe the specific user you're building for and articulate why this problem matters to them. You've spoken to at least 10 to 15 people who match that description and heard consistent patterns. You have at least one piece of evidence that users would pay for a solution (a pre-order, a letter of intent, a paid pilot commitment). You've identified the riskiest assumption in your product plan and either validated it or accepted the residual risk.

The teams that discover these markers don't exist after three weeks of research are usually better served by refining their problem definition than by starting to build.

One of the most valuable reframes is to stop thinking of discovery as a phase before development and start treating it as an ongoing practice. The product questions that matter change as the product matures. At early stage, the question is whether the problem is real. At growth stage, it becomes why retention is lower than expected, or which of three proposed features will drive the most activation. The discipline of discovery — testing assumptions before committing to them — applies throughout.

If you're preparing to build and want to stress-test your assumptions before committing to a development programme, our consulting team works with early-stage founders on exactly this kind of structured validation. When you're ready to build, our product development team can take it from validated concept to working product. Get in touch.