Product discovery: deciding what to build before development

An application request often arrives as a feature list: sign-in, dashboard, notifications, payments, administration. That list describes screens and functions. It does not yet explain why they should be built or which ones belong in the first release.

Product discovery helps make those decisions. Its outcome should give the people funding, designing and developing the product a shared scope. Here is a practical structure for that work.

1. Describe a situation before designing a solution

Start with a concrete sentence: “When this person encounters this situation, they need to complete this action.” Add what happens today, the difficulty involved and its effect on the business.

“We need a customer portal” leaves many possibilities open. “Customers call to check their request because they hear nothing between submission and resolution” gives you options to examine: better notifications, a tracking page or a change to the internal process.

This follows a principle in the UK Government Service Manual: understand the problem, users and constraints before committing to build a service. Source: the discovery phase, GOV.UK.

Gather the evidence you already have: support requests, sales conversations, observation of actual work and limitations of existing tools. Record separately what you observed, what someone reported and what remains an assumption.

2. Choose a complete priority journey

Consider a hypothetical equipment-hire company planning a booking application. This is an illustrative example, not a Black Tide client case.

Its first journey might involve finding suitable equipment, checking availability, submitting a booking request and receiving confirmation. That journey also raises questions about unavailability, rejection and cancellation. Someone inside the company may need to approve requests.

Describe the beginning, steps, outcome and main exceptions. A first release can support a limited set of situations while still letting users finish a task. Counting screens does not define that scope.

3. Put uncertainty first

Open questions have different consequences. Reliable access to availability data could determine the entire booking flow. Choosing an animation for confirmation can wait.

Use a short decision table:

Give each question an owner and a next action. This creates an investigation plan that product, design and engineering can work from together.

4. Decide what the prototype should help you learn

A prototype can help examine the order of steps, the meaning of a label or whether people can find information. A booking mockup cannot establish that production availability data will be accurate.

Prepare a realistic task, observe the route people take and record points of hesitation. For integration uncertainty, use a focused technical experiment instead. Select the method around the question; the Service Manual also uses this principle when planning user research. Source: planning research, GOV.UK.

Document the learning, its limits and the resulting decision. A preference expressed in an interview is insufficient to establish that a feature will be used regularly.

5. Define the first release and its boundaries

The equipment team might begin with manually approved requests before automating allocation. Whether that is appropriate depends on volume, operating arrangements and an acceptable response time.

For each part of the first release, specify:

• the action a user will be able to complete;
• the rules and main failure scenarios;
• the data, access and integrations required;
• the criteria for accepting the delivery;
• what is explicitly deferred.

A useful acceptance criterion might be: “When a request is rejected, the customer sees its new status and receives the agreed notification; the equipment remains available.” This gives design, development and acceptance testing a shared reference.

6. Prepare an estimate with explicit assumptions

An estimate should state its coverage: interface, backend, data migration, integrations, testing, release and operational preparation as applicable. Required accounts, access to decision-makers and external dependencies also belong in the discussion.

Keep unknowns visible. If access to a third-party system is unconfirmed, state the assumption and explain how a different outcome would change the scope. Agree who decides when a new request competes with the first release.

Discovery supports a commitment that everyone can understand. Unexpected work and decisions that need revisiting after real use can still occur.

What you should have at the end

The document can be short: the situation to address, intended users, priority journey, evidence gathered, agreed scope, exclusions, dependencies, acceptance criteria and remaining questions. Each item should help someone make a decision or deliver the work.

Technical choices can then be assessed in context. Our Flutter or native iOS/Android article explores the criteria for mobile applications.

Planning a new product or a substantial change? Explore our product design and development service, or let’s discuss the scope.