Product Discovery

Product discovery investigates user problems and possible responses so a team can decide what investment is justified. In his 2007 essay, Marty Cagan describes finding a real need and a useful, usable, feasible solution. Delivery builds, operates, and supports a chosen response. The activities overlap: experiments may require implementation, and feedback after release can change the team’s understanding of the same capability.

Cagan argues that discovery cannot be scheduled like construction because its outcome is not predictable, and warns that a fixed delivery schedule can force a team to proceed despite unfavorable evidence. DORA identifies building a platform without user research or validation as a pitfall. In a fictional case, a team builds preview environments at a sponsor’s request without investigating review workflows. Four of sixty teams use them after launch. That count alone cannot diagnose discovery quality or product failure: the team must establish how many teams need the capability and what it does for them. The missing research is a separate fact of this scenario.

The risks it investigates

Cagan’s four-risk framework asks whether a response provides value, is usable, can be built within constraints, and works for the business. Product management leads value and viability investigation, design leads usability work, and engineering leads feasibility work. They combine their evidence because a useful interface can still be unaffordable or impractical to support. Reducing uncertainty enough for the next decision does not remove every risk.

For an internal platform, examine task outcomes and organizational requirements as well as voluntary use. Usability includes successful completion, effort, errors, and accessibility; no support ticket is not proof of success. Test build and operating feasibility against expected load, failure scenarios, and available capacity. Compare costs with budget and check the relevant policies and contracts. Support records, usage observations, and discovery research provide different evidence. A prototype with one or two teams can expose problems in their workflows, but it cannot establish suitability for all teams or years of operation. Record who participated, what was tested, and which assumptions remain.

What it produces

A useful learning record describes the problem and affected users, evidence about candidate responses, and the next decision with its rationale. A trial user saying they would use a solution is an initial signal, not a universal completion threshold. Match evidence to the investment’s cost and risk: task tests with relevant user groups, observed use, cost analysis, and operational experiments may be needed. The next step can be a limited release, another experiment, a process change, a documented pause, or stopping. For a pause, name the missing evidence, responsible person, and reconsideration condition. A quarter without a feature is not itself failure; indefinite investigation without a decision process is a different problem.

Discovery research concentrates on understanding current work and needs and can inform product discovery. Product discovery also examines candidate responses and the evidence needed for investment decisions. Neither activity is defined solely by whether it ends in a build decision. Learning continues during delivery and operation, including revisiting a released capability. The platform product manager coordinates these decisions within an agreed mandate; Four of Sixty Teams Used It shows how they affect an internal platform.

References

• Marty Cagan, Product Discovery, Silicon Valley Product Group.
• Marty Cagan, The Four Big Risks, Silicon Valley Product Group, 4 December 2017.
• DORA, Capabilities: Platform engineering (Creative Commons Attribution 4.0).