Product Discovery With Live-Data Prototypes

Cagan argues that the core goal of product discovery is finding the smallest valuable, usable, feasible product as fast as possible by failing fast. He describes two techniques: disposable user prototypes tested with real customers, and live-data prototypes tested via A/B splits on a slice of real traffic. Live-data prototypes are costlier and need developer time, but they yield unmatched evidence about how an idea performs in the wild. For established companies, the purpose of discovery is mainly to reduce the risk and cost of innovation, since existing products already fund the business and failed experiments can hurt the brand or cannibalize revenue.

01Key takeaways

• Aim to find the smallest valuable, usable, feasible product as quickly as possible, expecting several iterations.
• Test hypotheses in the fastest, cheapest way first, often with a user prototype tested in days.
• Use live-data prototypes when only real behavior data can show whether an idea works, such as funnels or search relevance.
• Keep live-data prototypes narrow, testing in one market or with one payment flow before investing in full rollout.
• Beware of spending too long building before real users see the idea and the team falls in love with it.
• In established companies, frame discovery as reducing the risk and cost of innovation to the brand and existing revenue.

02Key sections

Failing fast as the goal

Discovery aims to find the smallest viable product quickly by testing ideas on real users and iterating or pivoting. Multiple iterations are expected, so speed of each cycle matters.

User prototypes versus live-data prototypes

User prototypes are disposable simulations tested face-to-face and can be done in days, giving qualitative insight. Live-data prototypes are real code tested with live traffic, giving quantitative evidence but requiring developer time.

Scoping live-data prototypes

A live-data prototype can be deliberately narrow, such as one geography, language, or payment system, with lower polish than the eventual product. Teams can invest in scale only after the idea shows promise.

Discovery in startups versus established companies

Startups face a race against their funding, so discovery is easy to justify. Established companies must justify experiments as risk and cost reduction, because successful existing products make failure costly.

Split testing for discovery

Discovery tests are usually large, structural changes rather than incremental page tweaks, so optimization tools fit poorly. Split testing can also serve as a gentle deployment mechanism.

03From the post

“A partnership dedicated to teaching best practices to product teams and product leaders”

04Frameworks mentioned

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