Are We Going Back to Waterfall Project Management?

The backlog doesn't shrink, it becomes infinite

Every company already has more requested changes than it can build. Cost used to hold that appetite in check. Building anything took real time and money, so an idea had to survive scrutiny before it got resources. That friction is mostly gone now. A developer can turn a half-formed description into a convincing prototype in an afternoon, sometimes before the business has even decided which problem it's solving.

So the backlog gets longer, not shorter, and it moves faster than the people prioritizing it. Requests that would've died in a budget conversation five years ago now feel easy enough to just try. Developers clear tasks and immediately want the next decision. Product managers can't keep pace. More software gets made. The company doesn't necessarily get better at deciding which software is worth making.

Code was never the only bottleneck, it just looked that way

AI speeds up development. It doesn't speed up the rest of the organization with it. A product manager still has to understand what's actually broken. Security still has to sign off on data access. Someone still has to weigh whether this matters more than everything else pulling at the team's attention. None of that gets faster because the code does. A coding agent doesn't need a good answer to "why are we building this." It just builds what it's told, and that's where fuzzy direction gets expensive, even when the code itself was nearly free.

Google's 2025 DORA research backs this up. AI adoption correlated with higher throughput, but it also showed a continued negative relationship with delivery stability. Teams are shipping more. Not necessarily shipping more reliably (2025 DORA report). The constraint has moved from "can we build it" to "can we decide and integrate fast enough to keep up."

Product managers aren't falling behind, they're the ones noticing the gap

A developer has a working prototype by end of day while the PM is still scheduling user interviews. Asking for one more conversation before greenlighting can look like a drag on momentum. But they're often flagging the gap between something that demos well and something that actually survives real operations.

Product management doesn't matter less here. It matters more, because engineering capacity stopped being the scarce resource. When building was expensive, companies optimized for managing engineering time. Now that it's cheap, attention is what needs managing: which decisions get made, in what order, by whom.

PMs shouldn't be asked to write requirements at the speed AI writes code. The real job is getting critical calls made sooner and keeping half-baked requests out of the pipeline in the first place.

What waterfall actually got right

Full waterfall would be a mistake to bring back. Nobody wants six-month requirements documents that go stale before development even starts, and real information about what a system needs usually only shows up once people are using it. But waterfall got one thing right: it treated implementation as the beginning of a set of obligations, not the finish line. Someone has to keep access current, keep data clean, keep integrations working. Problems need an owner. AI doesn't remove that. If anything it adds to it, since more tools and automations means more things that eventually need securing, monitoring, replacing.

Waterfall's real lesson was never deciding everything in advance. It was don't skip the essential decisions just because building got faster.

Set the boundaries, not the whole spec

Nobody needs an exhaustive spec for every request. They just need enough shared understanding that fast development doesn't collapse into fast confusion.

Before real work starts, a team should be able to say plainly what problem they're solving, who's affected, what result should improve, and who owns the outcome. They should also know where the hard lines sit: what always needs a human sign-off, what data the system doesn't get to touch. This isn't about eliminating ambiguity. It's giving developers a fence so they aren't quietly inventing business policy while they code.

A faster team needs a shorter list

The instinct when capacity goes up is to start more things. That instinct is usually wrong. A crowded backlog creates the illusion that every idea is just waiting its turn, when a good chunk of it is duplicate requests or someone's pet fix for a problem nobody's actually diagnosed. AI helps a team burn through backlog items faster. It can't tell you which ones deserve to exist.

So discipline has to tighten as speed goes up. Something stays active only if it has a current reason to exist, someone accountable for it, and a way to check afterward whether it worked. If nobody's willing to own a request, it shouldn't be competing for capacity with work that matters. That feels backwards. Why not let a faster team deliver more? Because the point was never to maximize output. It's to make the business better.

Give developers the problem, not just the ticket

AI-assisted development makes it easy to take a request too literally. A ticket might ask for a new field without explaining why, or whether that field is even the right fix. In the slower model, missing context tended to surface anyway, since a developer would hit a wall and ask around. An AI agent can finish the ticket before any of that happens.

Developers now need more upfront context, not less. How the work actually happens today. Where it breaks down. How success gets judged. Anthropic's own research into coding-agent use found the tool doesn't replace subject-matter expertise. It amplifies whatever direction it's given (Anthropic's research on Claude Code use). A team with sharp priorities moves faster with AI. A team with vague requirements just generates confusion faster.

Plan the decisions, not the whole project

Waterfall tried to map the entire route from requirements to release before anyone started building. A better approach plans the decision points instead: agreeing the problem is real, deciding who the first users are, figuring out who gets to say "this is ready." None of that needs settling before code gets written. It needs to happen once there's enough information to decide well, and a prototype can be exactly what surfaces what users actually need. A limited release can expose problems no planning session would ever catch. The plan becomes scaffolding for learning, not an attempt to predict the unpredictable.

Faster code doesn't mean the org can absorb it faster

Engineers and coding agents can juggle several tasks at once. The rest of the company usually can't keep up at that pace. So when output rises, the backlog doesn't vanish, it relocates: code waits for review, prototypes wait for a decision, features wait for training. None of that is a failure by the engineers. It's just what happens when one part of the system speeds up and the rest doesn't.

The fix isn't skipping review. It's capping how much work is in flight at once and treating testing and training as part of the build, not an afterthought tacked on once the "real work" is done. Keeping everyone constantly busy was never the same thing as creating value.

A good demo is not a finished product

AI has made prototypes cheap, and that's genuinely useful for finding out fast whether an integration is even feasible. The trouble starts when a polished demo gets mistaken for a nearly finished product. Security, error handling, and actual employee adoption stay invisible, even though they often take more effort than the demo itself did.

Every prototype should start with a specific question it's meant to answer. Once that question's answered, someone needs to make a call: kill it, revise it, or fund it to production grade. Cheap experimentation is good. It shouldn't come with cheaper standards for what actually ships.

Product management is becoming an editing job

In a world of near-unlimited ideas and fast-generated software, the most valuable thing a product leader does is say no. Cut the weak requests. Merge the overlapping ones. Push back on a "solution" that doesn't actually touch the root problem.

That only works if decisions move fast too. A PM can't keep pace with AI-assisted engineering when every judgment call sits in a queue for a committee meeting three weeks out. Senior leaders need to spend less time rubber-stamping small features and more time setting boundaries and risk tolerance. Skip that shift, and faster engineering just produces a bigger pile of software waiting for someone to decide what to do with it.

So, waterfall again?

Not really. What's coming back is a habit of deliberate planning, and that's different from trying to eliminate uncertainty before anything gets built.

Nail down the problem, the outcome, who owns it, and the boundaries, early but lightly. Then build in small pieces, show people quickly, and let what you learn shape the next decision. Waterfall put almost all its thinking before the building started. Careless AI-assisted development risks putting too little thinking anywhere at all. The better version keeps the two close together, always feeding back into each other.

The real question isn't how to keep developers busy now that AI makes them fast. It's how to make the decisions around them faster and better.

Where to actually start

Look at what's entering the pipeline right now. For anything non-trivial, ask what problem it solves, who owns the outcome, and what would count as evidence it worked. You don't need a new template for this. Just have the conversation. Anything that can't be answered yet should stay an idea, not a commitment.

Then look at where work is actually stuck: a product decision, a security review, a testing window. Those stalls show exactly where decision-making hasn't kept up with the tools. Some reviews can be delegated. Others need to stay slow, because the cost of getting it wrong is real.

And cut how much is running at once. Pick a handful of problems that actually matter, put engineers in front of the people who understand them, and let working software carry the conversation.

AI means a company can build more than it ever could before. The ones who win won't be the ones who build the most. They'll be the ones disciplined enough not to build the wrong things faster.