The PM Role Through Three Eras

In this module

1. Learning objectives — what changes about your model of the PM role after this
2. The three eras at a glance — Waterfall → Agile → Adaptive AI
3. What was true in Waterfall — and what made it stop working
4. What Agile changed — the gains, and the costs we tolerated
5. What Adaptive AI changes underneath — the substrate shift
6. What stays the same across all three eras — customer empathy, judgment, strategy
7. The empirical case for taking this seriously — DORA 2024, McKinsey 2025
8. Sidebar: how PM33 implements the Adaptive-AI pattern — one case study
9. Discussion prompts
10. Further reading

Learning objectives

After this module you should be able to:

• Name the three eras and the unit of work, planning cadence, success metric, and coordination role for each
• Explain why we treat Adaptive AI as a distinct era rather than "Agile with AI tools"
• Identify, with evidence, why partial adoption of the Adaptive pattern can reduce delivery performance
• Locate your own team on the three-era spectrum honestly

Key concept

The PM role has been redefined twice in the last 25 years. Most product orgs are still operating with mental models built for Agile while their tooling has moved into the Adaptive AI era. The mismatch produces specific, diagnosable pain: sprint planning that takes longer than the work it plans, AI-augmented teams that ship more but learn less, status meetings that have nothing to status because work flows continuously.

The thesis of this curriculum is that the third era requires a coordinated set of changes — to the unit of work, the planning cadence, the success metric, and the coordination role — and that you can't cherry-pick. DORA's 2024 research is the empirical hammer: AI adoption was accompanied by an estimated 1.5% decrease in delivery throughput and a 7.2% reduction in delivery stability when not paired with disciplined flow practices. Adaptive AI is not optional flavoring on top of Agile. It's a substrate shift.

The three eras at a glance

The columns aren't strict generations — many orgs run all three patterns simultaneously across different teams. The argument is not that everyone moves through the stages on the same schedule. The argument is that the patterns are distinct, and that confusing one for another produces specific kinds of waste.

What was true in Waterfall — and what made it stop working

Waterfall PM was about specifying upfront and staying out of the way. The PM (often called Project Manager or Program Manager, with product responsibilities folded in) wrote a 50-page Product Requirements Document, handed it to engineering, and reappeared at launch.

This pattern worked when:

• Customer needs were stable across the multi-quarter delivery cycle
• The cost of building was high enough that planning had to be near-perfect
• The dominant interface was hardware or shrink-wrap software where shipping was a singular event

It stopped working when:

• The web compressed cycle times — competitors who shipped weekly out-learned competitors who shipped quarterly
• Software became iterable — a wrong feature could be modified, not just lived with
• Customer expectations became continuous — "the app updated again" stopped being a notable event

The PM's pain in Waterfall: by the time delivery happened, the spec was wrong. The PM had two options — defend the wrong spec or rewrite at delivery cost. Neither was good.

What Agile changed — and the cost we tolerated

Agile (and Scrum specifically) responded by shortening the loop. Instead of one specification → build → launch cycle of 18 months, the Agile org runs many cycles of 2 weeks. Each cycle: pick stories, build them, demo, retrospective, adjust.

The wins were real:

• Cycle time compressed by ~10x
• Mid-stream adjustment became normal, not a process violation
• The PM became a continuous participant in delivery, not a hand-off-and-leave specifier
• Marty Cagan's Inspired (2017) and later Transformed (Cagan, 2024) crystallized the "empowered product team" model that became the dominant pattern

But Agile carried specific costs we tolerated:

1. The unit of work became softer. A "story" in Agile is famously underspecified by Waterfall standards. The implicit contract was that engineering would resolve ambiguity through conversation. This worked when the executor was a human who could ask clarifying questions and exercise judgment. It started to break when executors changed (see Adaptive AI section).

2. Sprint planning became expensive. John Cutler's "feature factory" diagnostic (Cutler, ongoing writing at The Beautiful Mess) named the failure mode: orgs that measure output over outcomes become "storypoint machines where the company only cares about how much is being shipped." Sprint planning consumed hours per week per team across estimation, prioritization, and dependency management.

3. Success measurement was disconnected from outcomes. Velocity measured throughput, not impact. Story points measured estimated effort, not realized value. Cagan's Transformed names this as the single biggest gap in current Agile practice: "holding teams accountable for outcomes rather than output… giving teams problems to solve and desired outcomes" (Cagan, 2024).

4. The Scrum Master role concentrated on ceremony. What started as systemic-impediment removal hardened into standup facilitation and Jira hygiene. AgileGenesis names this directly in their 2026 piece: "Ceremony facilitation is rarely the lead requirement anymore" (AgileGenesis, 2026).

These weren't bugs in Agile. They were the price of compressed cycles. The bet was that the wins outweighed the costs. For 15+ years, they did.

What Adaptive AI changes underneath

The Adaptive AI era didn't replace Agile by improving it. It changed the substrate underneath in three structural ways:

1. Cycle time compressed by another order of magnitude

"If an agent can deliver a feature in an hour or two, why wait to schedule it into the next sprint?" — Alexander König (DevOps Lead, doubleSlash), February 2026

When AI agents can execute well-specified work in hours, the 2-week sprint becomes a coordination ritual without a delivery purpose. You're not "planning a sprint" — you're imposing a time-box on continuous flow. Module 3 covers this collapse in depth.

But — and this is Giles Lindsay's productive complication (Lindsay, 2026) — the sprint also served as a learning cadence. Faster execution doesn't eliminate the need for learning cycles; it intensifies the need. What dies is the sprint as a delivery throttle. What persists, and intensifies, is the loop as a learning structure.

2. The unit of work needs to be machine-verifiable

A "story" written for a human team carries implicit contracts: the engineer will ask if something is ambiguous, will check with design about edge cases, will surface compliance concerns at code review. An AI agent doesn't do any of those things by default.

Anthropic Engineering's harness blog (November 2025) is explicit:

"Each subagent needs an objective, an output format, guidance on the tools and sources to use, and clear task boundaries... Without detailed task descriptions, agents duplicate work, leave gaps, or fail to find necessary information." — Anthropic Engineering, "How we built our multi-agent research system" (June 2025)

GitHub's productized response is the Spec Kit (September 2025). The pattern: Spec → Plan → Tasks → Implement, with explicit verification at each gate. The "spec" — what this curriculum calls a Brief — has structured fields (function signature, input contract, output contract, acceptance criteria) that machines can verify.

"A vague prompt like 'add photo sharing to my app' forces the model to guess at potentially thousands of unstated requirements." — Den Delimarsky (Principal PM, GitHub), September 2025

The story doesn't disappear — it evolves into a more structured artifact. Module 3 covers the migration.

3. The Scrum Master role evolves toward loop stewardship

When some of the team's work is executed by AI agents, the coordination role's content changes. The Scrum Master's responsibilities (impediment removal, ceremony facilitation, team coaching) split:

• Ceremony facilitation atrophies — fewer humans need to be in fewer rooms because the work flow has fewer human handoffs per unit shipped
• Impediment removal expands — now it includes harness health, agent dispatch quality, lifecycle event hygiene, prompt-discipline coaching
• Team coaching persists — humans still need to be coached, but the coaching surface includes "how to delegate to AI" alongside "how to collaborate with humans"

Scrum.org itself acknowledges this in their 2025 piece "AI Augmented Scrum Framework: When Half Your Team Is Autonomous Agents". The fact that Scrum.org — not a disruptor blog — is publishing this is the strongest signal that the role evolution is real and accepted.

Module 4 makes the case for the Loop Master as the natural name for this evolved role, including the prior-art comparison against candidates like Flow Master, Cycle Master, and Loop Steward.

What stays the same across all three eras

To be explicit about what we are NOT arguing:

• Customer outcomes are the point. They were in 1985 with Waterfall. They were in 2010 with Agile. They are now.
• Judgment and taste are the PM's job. AI can summarize a customer call; it can't sit in one.
• Strategy — "should we pivot?", "should we sunset X?", "is this market still attractive?" — is not delegatable. The Loop Master does not replace the strategist.
• Cross-functional brokerage — when eng, design, and PM disagree, a human resolves it. AI doesn't navigate office politics.
• Hypothesis → experiment → learn as the core scientific structure of product work. Adaptive AI changes the loop's cycle time, not its shape.

If anything, the Adaptive era makes these eternal skills more important relative to the time spent on ceremony and coordination. The PM who used to spend 15 hours per week on standups, Jira grooming, and dependency hunting gets that time back. The question is whether they spend it on customer empathy and strategy — or get pulled into low-value work the AI didn't quite finish.

The empirical case for taking this seriously

Two pieces of recent research make the strongest case for treating Adaptive AI as a distinct era requiring coordinated change.

McKinsey QuantumBlack — outcome attribution as the differentiator

From McKinsey QuantumBlack, 2025:

"Only about 5.5% of nearly 2,000 surveyed organizations reported greater than 5% of EBIT attributable to AI."

McKinsey calls the rest "AI theater" — orgs that are "going through the motions of AI adoption without rewiring the operating model to capture real value." The differentiator between the 5.5% and the 94.5% is the ability to attribute outcomes to specific shipped work, not the volume of AI adoption. Most orgs have adopted AI tools. Few have rewired their operating model around closed-loop attribution.

This is the strategic case for the Loop Master role: someone owns the attribution layer.

DORA 2024 — the Vacuum Hypothesis

The strongest empirical argument is in DORA's 2024 State of DevOps Report:

"AI adoption was accompanied by an estimated decrease in delivery throughput by 1.5%, and an estimated reduction in delivery stability by 7.2%."

The mechanism — what DORA calls the "Vacuum Hypothesis" — is that reclaimed time from AI productivity gains gets absorbed by "other lower-value tasks" rather than redirected to high-leverage work. Partial adoption (use AI to write code faster, keep everything else the same) demonstrably makes delivery worse.

This is the empirical argument for why the curriculum is sequenced as a single argument across 6 modules. You cannot pick one element of the Adaptive pattern (faster execution, structured Briefs, continuous flow, closed-loop attribution, Loop Master role) and ship the rest. The elements interlock. Partial adoption is worse than no adoption.

Sidebar — how PM33 implements the Adaptive-AI pattern

This is the first of the "case study" sidebars. PM33 is one implementation of the patterns this module describes. It is not the only one. The patterns stand independent of PM33.

Where the patterns surface in PM33:

You can read this curriculum without using PM33. You can build the patterns into Linear, Jira, Notion, or a custom stack. We made PM33 because building it forced us to confront the patterns in code; we share the curriculum because the patterns deserve to outlive any one implementation.

Discussion prompts

Use these to ground the module in attendees' real experience:

1. Pick your own team. Where is each of the four dimensions (unit of work, planning cadence, success metric, coordination role) currently sitting on the three-era spectrum? Are they aligned with each other?
2. Where in your current week do you spend time that doesn't fit any of the three eras — i.e., it's neither classic specification, nor sprint coordination, nor loop stewardship? What is it, and why is it taking time?
3. The McKinsey 5.5% number: what would have to be true at your org to land in the 5.5%? What's missing today?
4. The DORA Vacuum Hypothesis: where in your team has reclaimed AI productivity been absorbed by low-value work?

Further reading

• Cagan, Marty. Transformed: Moving to the Product Operating Model (SVPG, 2024) — the defining text on outcome-orientation as operating model
• DORA 2024 State of DevOps Report — the empirical foundation
• McKinsey QuantumBlack — "From promise to impact" — the attribution-as-differentiator framework
• AgileGenesis — "The Scrum Master Role Is Dying" — the role evolution piece (Module 4 builds on this)
• Anthropic Engineering — "Effective harnesses for long-running agents" — first-party source on Brief structure
• Next module: PM Module 2 — The PM's Actual Problems

A note on intellectual honesty

This curriculum makes a strong argument. We've tried to surface counter-evidence where it exists:

• Lindsay (2026) argues the sprint isn't dead — its delivery-throttle role is dead, but its learning-cadence role persists and intensifies. We agree, and Module 3 builds on this.
• Cutler ("Beyond Outcomes Over Outputs") argues the outcomes/outputs binary is over-simplified. Some mission types legitimately optimize for output velocity. We agree, and Module 2 holds space for this.
• DORA 2024 itself notes that fundamentals (small batch sizes, robust testing) remain crucial. AI doesn't change Lean's underlying mechanics — it changes the cycle-time constants.

The strongest version of our argument isn't "Waterfall and Agile are wrong and Adaptive is right." It's "the substrate is shifting, and the orgs that match their operating model to the new substrate will out-learn the orgs that don't." If you disagree with the framing, the disagreement is welcome — bring it to the workshop. The argument is better when challenged.