Flavors of Prototypes

Marty Cagan argues that prototyping is not one thing: teams often narrow the term to whichever prototype type they first encountered, and then misuse it. He lays out four main flavors: feasibility prototypes that answer technical risk, low-fidelity user prototypes that show information and workflow, high-fidelity user prototypes that look real but are simulated, and live-data prototypes that prove whether an idea works with real data and real traffic. Hybrids mix these. The point matters because choosing the wrong flavor leads teams to draw false conclusions, such as declaring victory after praise from a handful of users.

01Key takeaways

• Match the prototype type to the risk you need to test: technical, usability, or market behavior.
• Do not treat praise from a small group of users as proof that a product will succeed.
• Use high-fidelity prototypes to learn why users reject an idea, combining feedback across testers like puzzle pieces.
• Live-data prototypes can prove value in days or weeks by limiting scope to critical use cases and skipping productization.
• Live-data prototypes still need to be productized before a business can run on them if tests succeed.
• Keep discovery focused on the fastest, cheapest way to test ideas, and build skill across all prototype types.

02Key sections

Why the term is misunderstood

People tend to define prototypes by the first kind they saw, such as feasibility or usability, which narrows how they test ideas. Cagan argues the category is broader than any single example.

Feasibility prototypes

Engineers write just enough code to answer technical questions like new technology, algorithms, or performance before deciding whether to build.

Low- and high-fidelity user prototypes

Low-fidelity versions are interactive wireframes useful for thinking through workflow, while high-fidelity versions look real and suit usability and stakeholder communication but cannot prove a product will sell.

Live-data prototypes

These connect to real data sources and receive real traffic, often via A/B tests, to prove whether an approach performs better. They are built by developers, take days to weeks, and are not a shippable product.

Hybrids and the discovery principle

Hybrids combine elements, such as live data without live traffic for learning about relevance. The guiding rule is to choose the fastest, cheapest test that fits the idea.

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.