Product Fail

Marty Cagan argues that the common company process of taking executive or stakeholder ideas, building business cases, prioritizing feature roadmaps, and handing requirements down a line from product to design to engineering is the root cause of most product failures. He walks through this 'project model' step by step, then lists ten problems with it, including unknowable business case inputs, the assumption that most ideas will succeed, and validation happening too late. The core point is that this model produces output rather than outcomes, wastes time and money, and is far from how the best teams work. He closes by pointing toward continuous discovery and delivery and outcome-based problem framing as the alternative.

01Key takeaways

• Recognize that revenue and cost estimates for unproven ideas are guesses, and avoid treating them as reliable inputs for prioritization.
• Assume at least half, and ideally three quarters, of product ideas will not perform as hoped and plan validation accordingly.
• Frame roadmaps around business outcomes and problems to solve rather than lists of features or stakeholder requests.
• Bring engineering, design, and product together early in discovery instead of handing off requirements sequentially.
• Validate ideas with customers before full build, since building and deploying unvalidated features is one of the most expensive ways to learn.
• Watch for projects that ship on time but fail to meet objectives, a sign the organization is funding output instead of outcomes.

02Key sections

The project model's typical process

Ideas flow from executives and stakeholders into quarterly roadmaps based on business cases, then pass sequentially through requirements, design, engineering sprints, QA, and deployment.

Flawed business cases and roadmaps

Revenue and cost cannot be known before a solution exists, yet companies demand them to prioritize, and roadmaps become lists of features rather than problems.

Roles reduced to delivery

Product management becomes requirements gathering, design arrives too late to be more than cosmetic, and engineers and Agile are brought in only at the end.

Risk concentrated at the end

Because validation with customers happens after full build and deployment, waste is maximized, and project-centric funding leads to orphaned projects that miss objectives.

The better alternative

Continuous discovery and delivery run in parallel with cross-functional collaboration, replacing feature output with business problems and aiming for product/market fit.

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.