Product Discovery: Deciding What to Build Before You Deliver

Product discovery is the work done before development that establishes whether an initiative is useful to customers, usable, technically feasible and viable for the business. It tests these four risks with small experiments before a team invests weeks or months in building. Delivery makes sure things are built right, and discovery makes sure the right things are built.

Many organisations have improved their ability to deliver in recent years, only to find that features shipped on time still go unused. The cause lies before delivery, in a requirement that was never tested. This article describes how discovery is structured, which experiment fits which risk, and how an executive team can tell that an initiative is ready for implementation.

What is product discovery and how does it differ from delivery?

Product discovery is the part of product work in which a team finds out which solution to which problem is worth building, while delivery brings that solution into operation reliably. The product manager Marty Cagan popularised the distinction in his 2017 book “Inspired”. He describes how most ideas do not work as hoped, so a team must gather evidence before it commits development capacity.

The difference shows in the output. Delivery produces software, processes or services that match the plan. Discovery produces a reasoned decision: build, change or discard. Both ways of working run in parallel, which practitioners call dual-track. A team builds what has already been tested and tests what comes next. The article on the definition of done covers how finished work is defined. Discovery adds the question of whether the finished work is needed at all.

The four risks that discovery tests

Discovery tests four risks: value to customers, usability, technical feasibility and business viability. Cagan introduced these four risks as a grid for any product idea. The grid helps because it moves the discussion from opinion to evidence, since each risk calls for its own experiment.

Testing value alone overlooks the most common source of late surprises. A solution that customers want can fail on an interface nobody examined, or on a sales team that does not want to sell it. For this reason engineers and business units belong in discovery from the start, long before the handover.

Which methods exist, and how do you choose?

The method follows the largest risk and the time the decision is worth. Three approaches have become established. The design sprint by Jake Knapp, described in the 2016 book “Sprint”, takes a team from a problem to a tested prototype in five days. It suits a new offering that needs clarifying when the key decision-makers can be available for a week. Continuous discovery by Teresa Torres, set out in “Continuous Discovery Habits” from 2021, relies on weekly customer conversations and an opportunity tree linking outcome, opportunities, solutions and experiments. It suits teams that keep developing an existing product. The lean startup approach by Eric Ries from 2011 calls for a minimum viable product that tests one assumption, and it suits initiatives with high uncertainty about demand.

The principle transfers to companies beyond the software sector. A new service is first delivered by hand to two pilot customers, and a new internal process is tried at a single site. The yardstick stays the same: the more expensive the implementation, the more evidence the decision demands. How early customer feedback enters ties in with shortening lead time, as the article on time to market describes.

Who is responsible for discovery in the company?

Discovery is the responsibility of a small, permanent team of a product owner, a specialist in design or processes and an engineer. The product owner owns the decision on what is built and gathers the evidence. In mid-sized companies the role is often overloaded, because it collects requirements while it defends priorities and coordinates development. The article on the product owner in mid-sized companies shows which decision rights the role needs to fulfil this task.

The executive team influences the quality of discovery more than any single team does. It decides whether a team may discard ideas without being judged to have failed, and whether budget is tied to evidence or to the ranking of sponsors. Where budgets for the whole year are fixed on features in advance, discovery has no room. The article on agile fixed-price projects describes one way to separate scope and budget.

Checklist: is the initiative ready for implementation?

An initiative is ready for implementation when all six of the following statements can be answered with yes.

• The problem has been discussed with at least five customers or users, and their statements are on record.
• At least one experiment has shown that customers act, for example by ordering, booking or supplying data.
• A prototype has been used by users without instruction.
• Engineers have reviewed scope and interfaces and judge the largest technical risk to be manageable.
• The business case rests on assumptions the business unit has confirmed.
• There is a metric, its baseline and the threshold below which the initiative is ended.

If two or more answers are missing, the initiative stays in discovery. That costs a few weeks and prevents a team from spending months on a feature nobody later uses. The article on release planning explains how an approved solution becomes a reliable date.

Discovery with Niehues Consulting

Niehues Consulting is a consultancy for AI management and organisation design, seen from the delivery perspective, based in Düsseldorf. Founder Marin Niehues builds organisations that deliver, in projects ranging from VC-funded scale-ups to DAX 40 corporations and in more than 20 countries on six continents. In the service area of delivery management he works as delivery manager, project manager and product owner and runs the phase before implementation so that decisions rest on evidence.

The approach follows the Niehues Delivery Model. For discovery, three of its test questions matter most: which business result should change measurably? What is the baseline, and how do we measure success? Does the prototype prove the benefit in the real process with real data? The starting point is a free initial consultation of 30 minutes, which you can arrange via the contact page. Scope and terms of an engagement are discussed there.