This is part 1 of a three-part series on how AI is reshaping product management. Part 2 covers the urgency gap, and Part 3 covers what teams will look like on the other side.
The Manifesto Was Right
Go back and read the Agile Manifesto. It’s four sentences:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
That’s it. Twelve principles back it up, and they’re all about speed, trust, and staying close to the customer. Ship frequently. Build around motivated people. Give them the environment and support they need, then get out of the way. The best architectures and designs emerge from self-organizing teams.
Read those principles and then walk into a SAFe PI Planning session. Tell me those are the same religion.
What Happened to Agile
Agile won. And then it got enterprise-ified.
The original manifesto was written by seventeen developers who were frustrated with bureaucratic software processes. It was a rebellion against heavyweight methodology. The irony is that “agile” became its own heavyweight methodology within about a decade.
Here’s the drift, as I’ve seen it play out across multiple organizations:
Ceremony replaced conversation. Standups became status reports. Retros became complaint sessions that produce action items nobody follows up on. Sprint planning became a negotiation between what the business wants and what engineering says is possible, mediated by story points that everyone knows are fiction but nobody will admit it.
Measurement replaced trust. Velocity charts. Burndown charts. Cycle time dashboards. Sprint commitment percentages. We built an entire measurement apparatus around “are the teams productive” instead of asking the simpler question: “are we building the right things?” The manifesto says “working software is the primary measure of progress.” We replaced that with “story points completed per sprint.”
Roles created walls. Product managers write tickets. Engineers build tickets. QA tests tickets. Scrum masters facilitate ceremonies. Everyone has a lane, and the lanes created exactly the kind of siloed, over-the-wall handoff culture that agile was supposed to eliminate. The manifesto says “business people and developers must work together daily.” What we got instead was a game of telephone through Jira.
Sprints became mini-waterfalls. A two-week sprint, in practice, often looks like this: three days of planning and grooming, four days of building, two days of testing, one day of demo prep, and one day of retro and next sprint planning. Sound familiar? It’s waterfall compressed into fourteen days. We just renamed the phases.
I’m not saying agile is useless. It was a massive improvement over what came before. But the implementation has calcified into exactly the kind of rigid, process-heavy methodology the manifesto was rebelling against. We kept the vocabulary and lost the philosophy.
The Real Bottleneck Shifted
Here’s the thing that agile frameworks were designed around: building software was expensive and slow. A feature took weeks. A pivot took months. Mistakes were costly because rework was costly. So the entire methodology was optimized for managing a scarce, expensive resource: engineering time.
Story points exist because engineering capacity was the constraint. Sprint planning exists because you needed to carefully allocate that capacity. The PM-to-engineer ratio exists because you needed one person to keep several engineers pointed in the right direction.
AI is changing that equation. Not theoretically. Right now.
When a feature that used to take a sprint can be built in a session, the bottleneck isn’t “can we build it.” The bottleneck is “should we build it.” The scarce resource isn’t engineering hours. It’s product judgment.
And here’s the uncomfortable part: most of our agile processes are designed to manage a bottleneck that’s disappearing. Story points measure engineering effort. Velocity tracks engineering throughput. Sprint capacity is about engineering bandwidth. If engineering speed increases by 5x or 10x, what are we even measuring? What are we even planning for?
Back to the Manifesto
This is where it gets interesting. AI doesn’t push us further from the Manifesto. It actually gives us a chance to get closer to it.
“Working software over comprehensive documentation.” When you can go from idea to working prototype in hours instead of weeks, you don’t need a 30-page spec. You can build the thing and react to it. Show, don’t spec.
“Responding to change over following a plan.” When the cost of changing direction drops dramatically, you can actually respond to change instead of managing change requests through a backlog grooming process. The manifesto imagined a world where pivoting was cheap. AI is making that world real.
“Individuals and interactions over processes and tools.” When one person with AI can do the work that used to require a cross-functional squad, you need fewer coordination processes. Fewer handoffs, fewer ceremonies, fewer meetings about meetings. You can get back to small, empowered teams that talk to each other instead of updating Jira.
“Customer collaboration over contract negotiation.” When you can build fast enough to test ideas with real users instead of debating them in planning sessions, you can actually collaborate with customers. Build the thing. Ship it. See what happens. Iterate. That’s what agile was supposed to be.
What Comes Next
I don’t have a tidy framework with a catchy name. But I think the next era of product development has some clear characteristics:
Outcomes over output. Stop measuring how many story points the team completed. Start measuring whether the thing you shipped moved the number you care about. AI makes building cheap enough that you can take more swings, which means the PM’s job is picking the right swings, not managing the capacity to swing.
Continuous flow over sprints. Artificial two-week boundaries made sense when a feature took two weeks to build and you needed to plan capacity. When features can ship in a day, the sprint boundary just creates waiting. Ship when it’s ready. Review what happened. Decide what’s next.
Smaller teams, bigger scope. A PM with AI tools can cover ground that used to require a PM, a tech lead, and a scrum master. An engineer with AI can build what used to take a squad. Teams get smaller, but each person’s impact gets larger. That means fewer coordination costs, fewer meetings, fewer processes designed to keep large groups aligned.
Product thinking as the core skill. When building is cheap, the most valuable thing a PM does is understand the customer deeply enough to know what to build. Not write tickets. Not manage sprints. Not negotiate capacity. Think about the problem. Talk to users. Make bets. AI handles the execution speed. The human handles the judgment.
Faster feedback loops. Build, ship, measure, learn. Not in two-week cycles. In days or hours. The manifesto’s principle was “deliver working software frequently, from a couple of weeks to a couple of months.” AI makes “a couple of days” realistic. Use that speed to learn faster, not just build faster.
The Uncomfortable Conversation
Here’s the part that makes people nervous, and it should.
A lot of agile roles exist because the process demands them, not because the work demands them. If you remove the ceremony, if you collapse the build cycle, if you let small teams operate with autonomy and speed, some of those roles look different. Not gone. Different.
Scrum masters become less necessary when you don’t have sprints to facilitate. Project managers become less necessary when the gap between “decide to build” and “ship it” shrinks from months to days. Even the traditional PM role changes when you’re no longer spending half your time writing tickets and grooming backlogs.
That’s not a threat. It’s an evolution. But it requires the people in those roles to evolve with it. The PMs who thrive in the next era won’t be the ones who are best at managing a sprint board. They’ll be the ones who are closest to the customer, who can make product bets with conviction, and who can move at the speed that AI enables instead of the speed that process allows.
The Point
The Agile Manifesto is a good document. It described a way of working that was fast, human, collaborative, and customer-focused. Then we spent two decades building processes that made it slow, bureaucratic, siloed, and internally focused.
AI gives us a second chance. Not to bolt new tools onto old processes, but to actually build the way the manifesto envisioned. Small teams. Fast iteration. Working software as the measure of progress. Responding to change instead of managing it.
The question isn’t whether agile needs to evolve. It does. The question is whether we’ll use AI to get back to first principles or just add it as another column in the sprint board.
I know which one I’m betting on.
Next up: Part 2 looks at why most teams are heads-down building while the ground is shifting under them.