Closed-Loop in Practice

In this module

1. Learning objectives
2. Why one implementation, not "the" implementation
3. The day-in-the-life view — what the loop looks like in practice
4. The three daily flows — VOC triage, Brief refinement, outcome review
5. The weekly + quarterly rhythm
6. What stops happening — the things you stop doing
7. The numbers — what reasonable adoption produces
8. Anti-patterns we've observed across implementations
9. A skeptic's reading guide
10. Discussion prompts

Learning objectives

After this module you should be able to:

• Describe what a closed-loop product workflow looks like at the day-to-day level
• Identify what specifically gets removed from a PM's calendar
• Distinguish reasonable adoption outcomes from vendor-promised outcomes
• Sense-check any specific closed-loop tool (PM33 or otherwise) against the patterns from earlier modules

Why one implementation, not "the" implementation

Modules 1-5 made arguments. Module 6 grounds those arguments in concrete day-to-day practice — using PM33 as one implementation of the closed-loop pattern.

The patterns in this curriculum (Brief as structured spec, continuous flow over fixed sprints, Loop Master role, closed-loop attribution) are not unique to PM33. GitHub's Spec Kit implements a sibling version. Anthropic's harness ecosystem implements another. LangChain, Mastra, CrewAI, and emerging tools from larger vendors are converging on similar shapes.

Treating any one implementation as definitive is risky — it implies the patterns are vendor-specific when they're not. The cleanest test: read modules 1-5, build your own implementation from scratch, and you'd end up with something structurally similar to PM33, Spec Kit, or Anthropic's pattern. The patterns are the durable artifact. Tools come and go.

Concrete is more useful than abstract for learning, so the rest of this module walks through what one specific implementation looks like day-to-day.

The day-in-the-life view

This is what a PM's typical day looks like at a team that's adopted the closed-loop pattern.

A few things to notice:

1. The PM is in fewer meetings than the Agile-era equivalent day. The morning summary replaces standup. The scheduler proposal replaces sprint planning. The outcome review replaces sprint demo + retrospective.
2. The PM spends more time on judgment work than the Agile-era equivalent. Customer call has full attention. Strategy work has its own block. Cross-functional sync is high-signal because it's about novel Briefs, not routine status.
3. The PM does NOT spend time on: Jira hygiene, dependency hunting, status decks, manual Brief grooming sessions, building attribution spreadsheets, "where are we" Slack messages.

The shift in time allocation is roughly:

The category that grows most is customer + strategy work. The category that shrinks most is ceremony + status. This is the shift the curriculum is arguing for.

The three daily flows

A PM using a closed-loop system runs three named flows daily/weekly:

Flow 1 — VOC Triage (5-15 min, morning)

Voice-of-Customer signals (support tickets, sales notes, customer interviews, NPS, social) flow into the system continuously. An overnight triage process:

• Scores each signal against active strategic objectives
• Clusters duplicates and near-duplicates
• Surfaces hot patterns (sudden spike in one complaint area)
• Drafts a Brief (or Idea, if not yet shaped) for the top items

The PM's morning role: read the summary, confirm or correct the top 5-10, ignore the noise. The PM is not reading every VOC item. The triage has already happened.

Flow 2 — Brief Authoring / Refinement (15-30 min, when needed)

When new work needs to be specified, the PM authors a Brief — or refines a Pam-drafted one. The /brief skill walks through structured fields with validation. Anti-patterns get caught at create time.

Time on this flow varies wildly. Some days zero. Some days an hour. The work is bursty.

Flow 3 — Outcome Review (10-20 min, end of week or end of sprint)

A predicted-vs-realized view of recently-shipped Briefs. Three things the PM does:

1. Celebrate the calibrated wins — Briefs that moved the metric within the AR(1) confidence band
2. Investigate the misses — Briefs that shipped but didn't move the predicted metric; diagnose (wrong metric? wrong window? confound? feature flag still off?)
3. Update strategy weights — areas where Briefs reliably move metrics get weighted higher next cycle; areas where they don't get scrutinized

This is the most strategic 20 minutes of the PM's week. It's also the moment that most embodies the closed loop — the system has done its work; the PM does theirs.

The weekly + quarterly rhythm

Compared to Agile, the cadence is similar but the content is different. The cadence isn't broken — the work IN each meeting changes.

What stops happening

The clearest signal that the closed-loop pattern is working: things stop happening that used to take time.

• Status meetings: 80% of status content becomes async summary. Don't replace with another meeting.
• Dependency hunting: the scheduler surfaces dependencies. No more chasing three teams to figure out if PAYMENTS is on track.
• Attribution spreadsheets: built in. Don't build them parallel.
• PRD writing for clearly-scoped features: Briefs replace 80% of PRDs. PRDs are reserved for genuinely novel directions.
• Translating Jira to roadmap: the roadmap IS the strategic-objectives tree. The Brief backlog feeds it.
• Manual Brief grooming sessions: continuous grooming replaces 30-minute weekly grooming. The 5-minute weekly review is what's left.
• Quarter-end attribution scramble: QBR data is already there, automatically attributed.

If after 4 weeks of adoption you find yourself doing any of these, something is misconfigured. The diagnostic question: which of the patterns from Modules 1-5 isn't actually running?

The numbers — what reasonable adoption produces

Be skeptical of vendor-promised numbers. Here's what reasonable expectations look like, drawn from observed implementations:

Vendor-promised numbers that are NOT reasonable:

• "10x productivity" — sub-bullshit indicator
• "Replaces your PM team" — actively misleading
• "Works out of the box for any workspace" — false; AR(1) priors need 30-100 Briefs to converge
• "No change to existing processes required" — false; the patterns interlock

McKinsey's 5.5% number (from Module 1) is the right honesty calibration. Most orgs that adopt AI tools see modest gains; the ~5.5% that achieve significant value are the ones that rewired the operating model around closed-loop attribution. Aim for that quintile; expect first-year results to be modest while the team learns.

Anti-patterns we've observed across implementations

These show up regardless of which specific tool you're using:

1. Adopting Briefs but keeping sprints

Module 3's failure mode. The Briefs get filed; the sprint planning meeting still happens but has nothing to plan. Attendees lose attention; the meeting becomes ritual. Fix: shorten or eliminate sprint planning; route the energy to outcome review.

2. Adopting Briefs but writing them as Stories

The Brief schema gets filled with prose AC ("works correctly for common cases"). The AutoDoneVerificationService can never confirm done. Briefs sit in in_review because no one trusts the verification. Fix: enforce schema at create time (the /brief skill does this); train PMs on machine-verifiable AC; pair with engineering on the first 10.

3. Outcome attribution without recalibration

Metrics get measured; predictions get logged; nobody looks at the gap. The AR(1) prior never updates. The dashboard is a graveyard. Fix: weekly outcome review with named owner; ban "we'll get to it later."

4. No Loop Master ownership

The harness drifts. CLAUDE.md stops being maintained. Skills get out of date. Lifecycle events fail silently. The PM doesn't notice because the PM is focused on customer + strategy work. Fix: name a Loop Master, even if part-time. The role can be 25% of someone's job; it can't be 0%.

5. Treating Pam (or any conversational AI) as oracle

The PM defers to AI suggestions without iteration. First-answer acceptance. Quality drops because the AI's first answer is usually a draft. Fix: ban first-answer acceptance for strategic questions; require at least one iteration on Pam-drafted Briefs.

6. Velocity reporting persisting in leadership communication

The PM team reports outcome attribution; the engineering team reports velocity. Skip-level managers get conflicting pictures. Political friction builds. Fix: agree at the leadership level on a single success metric for the team — outcome attribution rate, not velocity.

A skeptic's reading guide

If you're skeptical of this entire curriculum — good. The strongest test of an argument is whether it survives someone trying to break it. Here's what to push on:

1. "You're describing patterns that haven't been validated at scale." Partly true. The DORA 2024 data and McKinsey 2025 framework are the most rigorous evidence available; specific implementations (PM33 included) are still building the case studies. Honest answer: the patterns are emerging, the evidence is accumulating, and the strongest argument is structural (the substrate is shifting) rather than empirical (here's the longitudinal data).

2. "This is just Agile with new vocabulary." Push hard on this. The honest answer: some elements (learning cadence, continuous improvement, customer-outcome focus) are continuous with Agile. The structural shifts (machine-verifiable specs, continuous flow over fixed sprints, AI specialists as executors, closed-loop attribution as the success metric) are not. The test: if you could lift the patterns wholesale into a pure-human team, they'd work poorly. They're shaped by AI execution.

3. "Closed-loop attribution is statistical hand-waving." Partly true. Attribution is a statistical estimate, not a hard causal claim. The engineer-track Module 4 covers the math honestly. The argument isn't "attribution is perfect" — it's "attribution by spreadsheet + memory at quarter-end is worse than attribution by AR(1) priors with explicit confidence intervals."

4. "My team will resist this hard." Probably true. The Scrum Master who's identified with ceremony facilitation will resist becoming a Loop Master. The PM who's identified with the role of being-the-decider will resist delegating triage. The engineer who's identified with spec-interpretation will resist machine-verifiable AC. Honest answer: yes, the change is hard. The case for making it is the McKinsey 5.5% number and the DORA Vacuum Hypothesis — not changing has a measurable cost too.

5. "Show me the data, not the patterns." Fair request. The data you should ask for: predicted-vs-realized attribution rates over 3-6 months; recalibration history showing the AR(1) priors converging; capacity-aware scheduling outputs that PMs accept ~70% of the time. If a vendor can't show you these, the loop isn't running.

Discussion prompts

1. Walk your own team through the day-in-the-life view. Which time blocks are different from yours today? Which are the same?
2. Pick the two anti-patterns most likely to bite at your org. What structural defense would prevent them?
3. The McKinsey 5.5% number: which side of the line is your org on today? What would have to be true to be on the other side in 12 months?
4. The skeptic's reading guide — pick the objection you'd lead with. How does the curriculum address it (or fail to)?

Further reading

• For deeper PM33 specifics: Builder-track Module 4 (outcome attribution math), Builder-track Module 5 (governance and audit)
• For the executive case: Executive track Module 2 (Reading the Outcome Attribution Report)
• For the security/compliance angle: Security & Compliance track Modules 1-4

What to do after this module

Three paths, depending on your role:

• PM evaluating adoption: pilot one strategic objective end-to-end. Author 5-10 Briefs against it. Measure outcome attribution. Decide based on data, not the curriculum's argument.
• Engineering leader: read engineer-track Modules 2-5 for the technical depth. Decide whether the harness pattern fits your stack.
• Executive sponsoring AI adoption: read Executive track Module 3 (Sponsoring AI Adoption the Right Way). The Loop Master role question is yours to fund.
• Loop Master candidate (if the role resonates): bookmark Module 4. The skills profile is real. The role exists, even if it's not yet named in your org chart.

The curriculum's last word: the loop is the product. Build the loop, defend the loop, close the loop. Everything else exists to keep it running.