By Marty Cagan · svpg.com · LinkedIn
Marty Cagan examines the Waterfall product development process, which he notes remains the most common way software products are built despite being decades old and widely criticized. He explains its phased structure of requirements, design, coding, testing and deployment with formal reviews between phases, and acknowledges why managers and stakeholders still favor it: apparent predictability and reassuring deliverables. The core problem for product managers is that working software arrives too late, so validation of usefulness and feasibility happens after most investment is spent, and changes are expensive and slow to ship. The essay argues that PMs should validate the product spec with real users and engineering before implementation begins, since this is the most effective way to avoid costly rework.
01Key takeaways
- Validate the product with real target users before handing a spec to engineering for implementation.
- Resolve major technical feasibility risks before architectural design and implementation begin.
- Treat documentation and polished specs as weak evidence; they do not prove a product will work.
- Account for the cost of a follow-on release when deciding whether to defer a change or fix it now.
- Expect Waterfall-style processes to be disguised under other names, and watch for the same risks.
02Key sections
- What the Waterfall process is
- Waterfall moves software through sequential phases from requirements to deployment, with a review and sign-off at the end of each. It appears in formal standards and in informal handoffs between marketing and engineering alike.
- Why it persists
- Management values the perceived predictability of schedules, and stakeholders are reassured by thorough documents and diagrams. Cagan notes these comforts can be misleading because documents cannot be tested like software.
- Late validation
- Because no working software exists until near the end, usefulness is only learned after most of the investment. Prototyping and testing with target users and resolving technical risks should happen before design and build.
- Costly change
- Changes from earlier phases destabilize the process and trigger rework, and deferring a fix often costs more than correcting it early. The PM must keep representing the customer's voice while weighing these costs.
- Slow response to the market
- Heavy documentation and phase overhead make even small changes slow, which pushes PMs to get the spec right upfront and to coordinate fast course corrections after release.
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.