Waterfall

Waterfall is a linear, sequential approach to software development where progress flows steadily downward through distinct phases: requirements gathering, system design, implementation, testing, deployment, and maintenance. Each phase must be fully completed and documented before the next begins. Once a phase is finished, the project doesn't return to it - like water flowing over a cliff, there's no going back up.

Why it matters

Understanding Waterfall matters because it shaped how entire generations thought about building software, and its influence persists in many organizations today. Even teams that consider themselves fully Agile often work with stakeholders, contracts, or compliance requirements that assume Waterfall-style planning. Knowing when Waterfall makes sense - and when it doesn't - helps product managers choose the right approach for each situation.

Waterfall also serves as an important point of contrast. Much of modern product thinking emerged as a reaction to Waterfall's limitations. Understanding those limitations helps explain why practices like iterative development, continuous delivery, and customer feedback loops became so central to contemporary product management.

The waterfall phases

A classic Waterfall project moves through these stages:

Each phase produces documentation that becomes the input for the next phase. Progress is measured by phase completion rather than working software.

When waterfall works

Waterfall isn't inherently bad - it's poorly suited to certain contexts but well-suited to others. Waterfall can be effective when:

Requirements are truly stable. Some projects have fixed, well-understood requirements that won't change. Regulatory compliance systems, accounting software implementing specific standards, or systems replicating existing paper processes may have requirements stable enough for upfront specification.

The domain is well-understood. When building the fifth version of a familiar system type, teams may have enough experience to accurately specify requirements and designs upfront.

External constraints demand it. Government contracts, highly regulated industries, and some enterprise procurement processes require detailed upfront documentation. Fighting the system may be harder than working within it.

Hardware is involved. Physical product development often has long lead times and irreversible decisions that make iterative approaches impractical.

The core problems

Waterfall's limitations become apparent in most modern software contexts:

Late feedback. Users don't see working software until near the end. By then, the cost of changing direction is enormous. Requirements that seemed clear often prove wrong once users interact with actual software.

Assumption of predictability. Waterfall assumes you can know enough at the start to plan everything. In practice, building software reveals information that changes what you should build. Learning comes from doing, not from planning.

Change resistance. The structure actively discourages responding to new information. Change requests become bureaucratic processes rather than natural responses to learning.

Integration risk. When components are built separately and integrated late, integration problems surface when they're most expensive to fix.

Measuring progress by documentation. Completed requirements documents and design specs feel like progress, but they're not working software. Teams can be "on schedule" while building the wrong thing.

Waterfall vs. agile

The contrast between Waterfall and Agile reflects fundamentally different beliefs about software development:

Agile emerged specifically to address Waterfall's limitations in contexts with uncertain requirements and fast-changing markets. But the choice isn't always binary - many teams use hybrid approaches that combine upfront planning with iterative execution.

Hybrid approaches

Pure Waterfall is increasingly rare, but Waterfall thinking often blends with Agile practices:

Water-Scrum-Fall. Requirements and design happen in Waterfall style, implementation uses Scrum, and testing/deployment return to sequential phases. This compromise often emerges when organizations adopt Agile partially.

Phase-gated Agile. Agile methods within phases, but formal gates between phases. Common in enterprises that need approval checkpoints for budget or compliance reasons.

Spiral Model. Combines Waterfall's phases with iterative risk analysis. Each cycle through the spiral includes planning, risk analysis, development, and evaluation.

Making the choice

The right methodology depends on context. Consider Waterfall-style approaches when:

Consider Agile approaches when:

Most modern product development favors Agile approaches because most software contexts involve uncertainty, learning, and changing requirements. But product managers should choose methods based on context rather than ideology.

The legacy

Waterfall's influence extends beyond projects that explicitly use it. Contract structures, stakeholder expectations, and organizational processes often assume Waterfall-style planning even in "Agile" organizations. Product managers frequently find themselves translating between Agile realities and Waterfall-shaped expectations - explaining why detailed year-long roadmaps aren't realistic, or why scope may change even though budget won't.

Understanding Waterfall helps product managers navigate these conversations and advocate effectively for approaches that match the realities of modern software development. Tools like Klero support this by connecting ongoing customer feedback to product decisions, making it easier to demonstrate why iterative, feedback-driven approaches deliver better outcomes than upfront specification.