That Dog Won’t Hunt

Cagan argues that the common pattern of writing a feature-packed PRD with P1/P2/P3 priorities, then haggling with engineering over schedule and cuts, reliably produces incoherent products that nobody likes. He proposes instead that product managers and designers build a high-fidelity prototype with the minimal functionality needed to meet business goals, involve an engineering architect early to estimate costs, and validate the prototype with real users before committing the full team. Once validated, features should not be cut casually, since the product was already reduced to its essentials; slips in schedule are preferable to breaking the proven whole. The piece matters because it reframes scope management from late-stage trimming to early, collaborative, evidence-based definition.

01Key takeaways

• Build a high-fidelity prototype with the minimum functionality that meets the business objectives.
• Bring an engineering architect into product review early so costs and trade-offs are understood before commitment.
• Validate the prototype with real target users before committing the full product team's resources.
• Treat schedule slips, not feature cuts, as the default response once the minimal product is validated.
• Strip P1/P2/P3 labels from the final spec and present it as a whole product that cannot have legs removed.

02Key sections

The familiar failure pattern

A bloated PRD with prioritized features gets handed to engineering, which produces a schedule months longer than needed. Negotiation over cuts and corners leads to a product that is incoherent and unsatisfying for everyone.

Minimal prototype first

The PM and designer should produce a high-fidelity prototype with only the functionality required to meet business objectives, which both reduces build cost and tends to improve the user experience.

Engineering involved from the start

An architect or lead engineer reviews product ideas as prototypes evolve, flags risky directions, and provides detailed estimates so trade-offs are made collaboratively before commitment.

Validate with real users

Before the full team commits resources, the prototype must be tested with target users, just as code is tested rather than assumed to work.

Hold the line after validation

Once validated, further feature cuts are unjustified; schedule slips are the normal response to overruns, and late requirement additions should be resisted.

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.