Build To Learn FAQ

Marty Cagan answers common follow-up questions to his earlier argument that builders should distinguish between building to learn (product discovery) and building to earn (product delivery). He argues that as delivery costs fall, competitive advantage shifts to discovery, especially solving the problem rather than confirming it exists. He clarifies the PM's role as an individual contributor responsible for value and viability, not a decider, protector, or manager. The piece also covers testing risks (value, usability, feasibility, viability), the role of PRDs as a supplement to discovery, and responsible rollout of changes to customers.

01Key takeaways

• Spend most discovery effort on solving the problem, since identifying and understanding it is usually quicker.
• Test prototypes against value, usability, feasibility, and viability risks with the parties relevant to each risk.
• Don't treat discovery as confirming a problem is real; leadership typically already knows the problem worth solving.
• Act as an individual contributor shaping value and viability, not as the final decider, protector, or manager.
• Use a PRD to supplement discovery and communicate details the prototype can't, not to replace discovery.
• Protect customers from erratic change by limiting rapid experiments to users who have opted in.

02Key sections

Framing build-to-learn work

Work starts from a problem and a desired outcome, with success measured by achieving that outcome. The hardest part is usually solving the problem, not identifying or understanding it.

What discovery is actually testing

Discovery tests whether a prototype solves the problem and produces the business outcome, across value, usability, feasibility, and viability risks. Each risk is tested with the relevant party.

Redefining the PM role

The PM is an individual contributor and a builder who brings knowledge of customers, data, and business to shape value and viability. The PM is not the decider, protector, or manager.

AI, PRDs, and learning in delivery

AI mainly accelerates prototyping and decision support in discovery, while it automates code in delivery. A PRD should supplement discovery, with the prototype serving as the primary spec.

Testing responsibly with customers

Rapid, erratic change can make customers feel like guinea pigs and harm revenue and trust. Experiments should be confined to opted-in groups to protect general users.

03From the post

“In our last article, we argued that especially in the age of AI, we are all builders, but that there is a very meaningful difference between building to learn (known as product discovery) versus building to earn (known as product delivery). Moreover, we argued that as the cost of product delivery continues to drop, the... The post Build To Learn…”

04Frameworks mentioned

Summary and takeaways written by PM Atlas; quotes are short excerpts. © the original author.