The waterfall model: When I’d use it and when I wouldn’t
Our reviewers evaluate writing services independently. Learn how we stay transparent, our methodology, and tell us about anything we missed.
What I mean by waterfall
I use “waterfall” for a sequential approach in which work moves through defined phases, with substantial planning and documentation before later phases begin. The key assumption is that decisions can be made early enough, and with enough confidence, that late change should be limited.
Why teams choose it
Sequential work can create clarity when requirements, interfaces, approvals, or physical constraints are well understood. It can also support governance, documentation, formal testing, and coordination across fixed dependencies. Some safety, regulatory, contractual, or hardware work needs deliberate checkpoints.
Risks I watch
The biggest risk is learning too late. If users and technical teams do not see a usable result until the end, an incorrect assumption can travel through every phase. A complete plan can create confidence without creating evidence. I also watch for change-control theater that defends the original plan instead of improving the outcome.
How I choose
I ask how stable the requirements are, how expensive late change would be, whether a meaningful slice can be tested early, and what governance requires formal sequence. Often I use a hybrid: define safety or architecture boundaries upfront while iterating on workflows and user experience.
A milestone should be a decision opportunity, not only a date. I choose the feedback loop that matches the uncertainty rather than treating waterfall and agile as moral categories.
A practical check
I also ask whether the team has a real way to revisit a phase decision. If the answer is no, I treat the plan as a risk rather than a certainty. Even in sequential work, prototypes, simulations, reviews, and early stakeholder feedback can reduce expensive surprises.
My bottom line
I use this framework to make the work explicit, not to create ceremony for its own sake. Start with the decision, show the evidence, make ownership visible, and revisit the approach when the product or context changes.
If you are building the fundamentals behind this kind of work, the Product HQ product management certification is a useful next step. I also share practical lessons in the Product HQ newsletter.
