By Marty Cagan · svpg.com · LinkedIn
Marty Cagan argues that many teams claiming to be Agile or Lean still operate with a Waterfall mindset, merely adopting the rituals and buzzwords. He identifies three telltale signs: risks deferred to the end, sequential handoffs from requirements to design to code, and a focus on shipping output rather than business results. He offers a quick diagnostic: compare how many ideas a team defines versus how many it delivers. Real product discovery should test far more ideas than it builds, so the piece is a useful self-check for teams and leaders.
01Key takeaways
- Look past Agile ceremonies and Lean jargon to see how work actually flows.
- Test the riskiest assumptions (value, usability, feasibility, viability) before engineering builds anything.
- Define products collaboratively with product, design and engineering rather than through sequential handoffs.
- Hold teams accountable for solving business and customer problems, not just shipping roadmap features.
- Measure discovery by comparing ideas tested against ideas built; discovery should outnumber delivery.
02Key sections
- Waterfall in Agile clothing
- Cagan notes that teams often keep Waterfall habits underneath Agile ceremonies and Lean vocabulary. He suggests peeling back these surface practices to see how work really flows.
- Risks saved for the end
- A Waterfall team waits until something is built before checking whether it is desirable, usable, feasible and viable. Good teams tackle these risks early, before committing engineering time and money.
- Sequential handoffs
- When requirements flow from PM to designer to engineer in a chain, the product is defined sequentially. Cagan argues that product, design and engineering should shape the solution together, with technology informing design.
- Focus on output over outcome
- Teams accountable only for shipping roadmap features, without responsibility for the underlying business problem, are still Waterfall. They should iterate or try other approaches until the problem is solved.
- The big tell
- Compare ideas defined with features delivered over a month or quarter. Teams that embrace discovery should test at least twice as many ideas as they build.
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.