Governance and Business Reviews

Governance turns metrics, reviews and risk records into timely decisions. Design forums around the choices they make, give each choice an owner, and retire meetings that consume attention without changing action.

Why this matters

Reviews allocate money, people and attention. Yet forums often outlive their purpose, decks accumulate, and hallway decisions acquire conflicting versions. Unowned risks persist until a customer escalation exposes them.

AI makes assembling review packs cheaper. Verification and judgment still require accountable people. This chapter connects the Operate dimension’s weekly, monthly, quarterly and annual forums to decision logs, risk registers and escalation policies. Chapter 28 covers the operations infrastructure.

Core concepts and frameworks

Governance that helps and governance that hurts

Jeff Bezos’s 2016 shareholder letter calls process as proxy the habit of defending a bad outcome by saying the process was followed. Review each process against the customer outcome it serves.

The same letter recommends deciding with roughly 70% of the desired information. His 2015 distinction supplies the qualification: Type 1 decisions are consequential and difficult to reverse, while Type 2 decisions can be changed. Reserve careful consultation for Type 1 and delegate Type 2 to individuals or small groups.

Delegate reversible decisions, log them and specify when to revisit them. Give difficult-to-reverse commitments the heavier review.

A recurring forum earns its place by changing decisions, resource allocations or owner actions. If three consecutive sessions change none of these, merge, shrink or cancel it.

The operating cadence

The forums nest. The weekly review catches exceptions in the inputs; the monthly and quarterly reviews compare progress with the annual plan; annual planning sets that plan; the portfolio review divides the investment envelope. Three standing records run alongside and connect them.

The weekly business review

Amazon’s weekly business review (WBR), described by Colin Bryar and Bill Carr in Working Backwards and Cedric Chin at Commoncog, provides a useful model. Chapter 18 covers its trailing-week and trailing-month metric pack. Three practices define the forum.

Metric owners are accountable business leaders. Bryar and Carr describe owners preparing their metrics in advance. Chin adds daily inspection, department reviews before the company review and Finance facilitation.

Focus on controllable inputs. Show revenue, profit and churn, but discuss actions that can move them. Bezos’s 2009 letter illustrates the emphasis: Amazon’s 2010 plan had 452 goals with owners and dates, including 360 directly affecting customer experience. Revenue appeared eight times and free cash flow four times. Net income and gross margin did not appear.

Explain exceptions. Show every metric, but discuss exceptional variation and missed targets. For each, state an evidenced cause and action or an investigation with an owner and date. Chin draws on Donald Wheeler’s distinction between routine variation and changed conditions. Explaining every fluctuation wastes attention and invites invented causes.

That gives three acceptable forms of variance explanation. Put them in writing for your team:

1. Routine. “Within normal range. Nothing to see here.”
2. Explained. “Exceptional. Cause: [cause, with evidence]. Action: [action, owner, date].”
3. Unexplained. “Exceptional. Cause unknown. Next step: [investigation, owner, date].”

Keep plausible but untested causes labeled as hypotheses. The owner must establish the cause before reporting it as an explanation.

Chin’s account adds two practices. Strategy debates get taken offline, so the WBR stays short. And metrics get added when they reveal a real driver or after something blows up, then demoted to a department review when they stop being useful.

Monthly and quarterly business reviews

The monthly business review (MBR) and quarterly business review (QBR) compare results with the annual plan. Bryar and Carr describe narratives of six pages or fewer, with appendix tables, reviewed 5–10 business days after close. The group leader writes with the team and Finance, then reviews for an hour with their leader, direct reports and selected stakeholders:

1. A table of key output and input metrics against plan and prior year, with prose commentary that puts roughly 80% of the focus on controllable inputs.
2. Three to five key initiatives, each with a red, yellow or green status, the input metric it moves and its headcount.
3. Updates to business assumptions and proposed course changes.
4. Resource status: hiring, and fixed and variable operating cost against budget.
5. An appendix.

For a product organization, use two layers. The monthly product review belongs to the PM: one product, one narrative, reviewed with your leader and cross-functional peers. The internal QBR belongs to the portfolio leader: several products rolled up, with the tradeoffs only visible at that level. Keep it distinct from the customer QBR that account teams run with large customers (Chapter 27).

Give assumption changes and proposed corrections substantial space. State which market, customer or capacity assumptions changed and what you recommend doing about them.

Annual planning: OP1 and OP2

Annual planning sets the investment envelope and the plan every other review is measured against. Bryar and Carr describe Amazon’s version as two passes, OP1 and OP2, and their calendar-year example runs roughly like this:

At OP1, top-down targets meet bottom-up plans and initiatives receive funding, modification or rejection. Each plan specifies metrics, initiatives, resources and organization. Bryar and Carr suggest more than five and fewer than twenty key metrics, typically 8–15, and initiatives with a leader, dates, expected metric impact and resources.

Amazon elevated roughly 15% of reviewed initiatives and metrics to S-Team goals, using about 75% of its review time on them and reporting quarterly. Changes to goals or resources needed senior approval. Additional initiatives within existing resources faced less friction. These rules protected the plan of record.

Add one section their template doesn’t name: what we will not do. Declined tradeoffs are part of the plan, and writing them down stops the same requests returning every month. Chapter 03 covers the strategy behind the plan.

Portfolio reviews

Portfolio reviews allocate the next investment dollar. BCG traces the growth-share matrix to Alan Zakon and colleagues, popularized by Bruce Henderson’s 1970 “The Product Portfolio.” It sorts by market growth and relative share: stars merit investment, cash cows fund other businesses, question marks warrant investment or exit, and low-growth, low-share businesses may need divestment or repositioning.

This book uses common practice postures: invest, maintain, harvest and divest. These are action labels, rather than BCG’s quadrant names.

Before divesting a platform component, price its dependency cascade: affected products, integrations, partners and workflows, plus migration cost. Low standalone share can conceal substantial portfolio value. Chapters 14 and 30 cover dependencies and sunsets.

For each product or bet, show the current and proposed posture, the evidence, the investment this year and next, the dependencies and the posture trigger: the evidence that would move it to a different posture. Without triggers, the portfolio ossifies around last year’s bets.

Metric reviews

A metric review asks whether you’re still measuring the right things. Run it quarterly, apart from the WBR, so this week’s exceptions don’t crowd it out.

For each metric in the WBR and the plan, ask five questions:

1. Does it still have a named owner who acts on it?
2. Is its definition written down and versioned, and does every report use the same one?
3. Do we know its normal range, so we can tell routine variation from exceptional?
4. For an input metric: when it moved, did the output follow? Which inputs moved without the output following?
5. In the last quarter, did it trigger a discussion or a decision? If not, should it be demoted?

Check whether moving an input also moves its expected output. Divergence calls for investigation into the metric or its definition, rather than automatic celebration of the input. Chapters 02 and 18 cover metric trees and dictionaries.

Decision rights and the decision log

Use DACI, popularized by Atlassian’s Team Playbook, to assign one decision owner and clear participation roles:

• Driver: coordinates the stakeholders, gathers the information, scopes the decision and makes sure it gets made by the agreed date. Usually the PM.
• Approver: makes the decision. Atlassian is emphatic that there is exactly one, writing “The one person (yes: one!) who makes the decision.”
• Contributors: have the subject knowledge and make recommendations. They have a voice but not a vote.
• Informed: are told the outcome. No voice, no vote.

Atlassian’s template adds the record: status, impact and due date, a short background, the decision criteria, at least three options with pros, cons and cost, action items and the outcome.

Bain’s RAPID names Recommend, Agree, Perform, Input and Decide. Its Agree role makes mandatory legal or regulatory approval explicit, while Perform assigns execution. Bain recommends starting with high-value or frequent decisions. Use DACI for ordinary decisions and a bounded Agree role for genuine vetoes.

The decision log records the choice, date, DACI names, options, evidence and outcome. Add door type, reversal trigger and a revisit date. For reversible choices, record what new information would change the decision, then proceed without waiting for every answer.

Risk registers

A risk register gives each potential failure an owner and a response. HM Treasury’s Orange Book covers general practice. NIST’s AI RMF 1.0 (January 2023) uses Govern, Map, Measure and Manage. Its Generative AI Profile followed in July 2024. As of 2026, NIST says AI RMF 1.0 is under revision.

Write each risk as cause, event and consequence: “Because [cause], [event] may happen, causing [consequence].” Add category, AI RMF function where applicable, likelihood, impact, owner, mitigation, early indicator, escalation threshold and review date. Review top risks monthly and the complete register quarterly. Chapter 33 covers AI assessment.

Escalation paths

Escalate genuine misalignment early. Bezos’s 2016 letter warns that unresolved disagreement otherwise gets settled by exhaustion.

Google’s Site Reliability Engineering recommends declaring an incident when another team is needed, customers can see the impact, or focused analysis has not resolved it within an hour. It requires named roles and acknowledged handoffs. Borrow objective triggers for product escalations.

A product escalation policy needs five things:

1. Triggers: customer-visible impact, a second team needed, an issue unresolved after a set time, a proposed change to the plan of record, a budget variance above a threshold, regulatory or security exposure.
2. Levels: who gets it at each level, by role, with a time to respond.
3. A required packet: a one-page narrative with the issue, the options, a recommendation and the specific ask. Nobody escalates with a forwarded email thread.
4. Handoff: an explicit statement of who owns the issue now.
5. Closure: once decided, everyone commits, including those who disagreed, and the decision goes into the log. Bezos calls this disagree and commit, and his letter is clear that it applies to the boss as well.

Narratives instead of slides

Bezos’s 2017 letter describes Amazon’s practice: no slide presentations, but narratively structured six-page memos, read silently at the start of the meeting. He writes that “a great memo probably should take a week or more” to write, rewrite and edit.

Bryar and Carr estimate that slide meetings spend 75% of time presenting and 25% discussing, while narrative meetings reverse that balance. Drawing on Edward Tufte, they recommend at most six pages for an hour or three for thirty minutes, full sentences, useful charts and tables, and required evidence in the main text. Attendees read silently, note questions and discuss them in order. The senior person speaks last.

Use narratives for decisions among roughly 5–20 people. Use slides for broadcasts and external presentations. Narrative formats include operating plans, business reviews, PR/FAQs, correction-of-error reviews and procedures.

If your organization mandates decks, put the decisions and asks on the first page, write the summary in prose and circulate in advance for written comments. Chapters 34 and 35 cover the craft.

How to apply it

Here’s a method for designing (or redesigning) the governance around a product or portfolio over one quarter. If you’re new in a role, it doubles as a way to learn how decisions actually get made.

Weeks 1 and 2: Inventory and prune.

1. List every recurring forum and record that touches your product. For each forum, note the attendees, the monthly hours it consumes (attendees times duration, plus preparation) and what its last three sessions changed.
2. Apply the earn-its-place test. Merge, shrink or cancel any forum whose last three sessions changed no decision, resource or owner action. Write down what you cancelled and why, so it doesn’t quietly return.
3. Sort recurring decisions by door type: pricing, roadmap, model or prompt changes, customer exceptions, deprecations. Delegate two-way doors to the lowest sensible level with a log entry; give one-way doors a named Approver and a written proposal.

Weeks 3 and 4: Decision rights and records.

4. Write a decision-rights map: Driver, Approver, Contributors and Informed for each recurring decision type. Name genuine veto holders (security, legal, compliance) explicitly, borrowing RAPID’s Agree role.
5. Start the decision log and backfill last quarter’s major decisions. The backfill usually exposes decisions that different people remember differently. Resolve them now.
6. Clean up the risk register. Rewrite every risk as cause, event and consequence, with one owner, an early indicator and an escalation threshold. Delete risks nobody will own; nobody was managing them anyway.
7. Write the escalation policy and test it in a 30-minute tabletop exercise with a realistic scenario, so you find the gaps before a real escalation does.

Weeks 5 to 8: The review cadence.

8. Stand up the WBR with the metric pack from Chapter 18. Publish the three forms of variance explanation and have owners label every metric before the meeting. Run four weeks before changing the format.
9. Write the first monthly product review as a narrative of six pages or fewer, reviewed 5 to 10 business days after close. Make the assumption-changes section the longest.
10. Agree the internal QBR format with your portfolio leader: decisions and asks first, then performance against plan, initiatives, risks and commitments.

Weeks 9 to 12: The quarterly and annual layers.

11. Run the first metric review. Apply the five questions to every metric. Retire or demote at least one; if you can’t find one, look harder.
12. Run a portfolio review, or prepare your product’s entry for your leader’s, with posture, evidence and posture trigger.
13. Prepare for annual planning. Learn the calendar: when guidance arrives and when plans are due. Start the narrative early; a plan written the week it’s due reads like one.

Ongoing: Govern the governance. Every six months, repeat steps 1 and 2 and report the hours your forums consumed against the decisions they produced.

The AI lens

Governing AI-powered products

AI products change what governance has to watch in four places.

The WBR needs AI inputs: regression eval pass rates, the rate at which users accept the model’s output, the “I’m not sure” rate, inference cost per unit of value and the share of actions taken autonomously. Give each a named owner, usually the applied AI lead or the PM. Chapter 31 covers definitions.

Model and prompt changes are decisions. A model upgrade, prompt change or new agent tool can change behavior as much as a release, so log them. Most prompt changes are two-way doors. Widening what an agent may do on its own in a customer’s production environment is closer to a one-way door, because trust lost to a bad autonomous action recovers slowly. Give that class of change a named Approver.

The risk register needs AI rows and regulatory dates. Map AI risks to the AI RMF functions so security and compliance reviewers can follow your reasoning, and track regulatory milestones as dated triggers. For products sold into the EU, the European Commission’s AI Act timeline is the clearest example: general applicability began on 2 August 2026, and the Digital Omnibus on AI (Regulation (EU) 2026/1744), in force since 27 July 2026, moved the obligations for high-risk systems listed in Annex III to 2 December 2027. Chapter 33 covers the obligations themselves.

Escalation needs AI triggers. A wrong AI output that a customer acted on is customer-visible and usually needs a second team, which meets two SRE triggers at once. Write AI-specific triggers into the policy before you need them.

Underneath sits a wider shift. Microsoft’s 2025 Work Trend Index, a vendor survey of 31,000 workers in 31 markets, found that 81% of leaders expected agents to be moderately or extensively integrated into their company’s AI strategy within 12 to 18 months, and proposed a “human-agent ratio” as a management metric. Treat it as directional. When agents do work inside your product and your company, your forums have to review what the agents did as well as what people did.

Doing the work with AI: review packs and their verification

Anthropic introduced the Model Context Protocol (MCP) in November 2024 as an open standard for connecting AI assistants to the systems where data lives. With connectors, a harness can pull metrics, tickets, CRM notes and docs into a draft WBR or monthly review in minutes. Agent Skills, introduced in October 2025, let a team package the recipe (sources, metric definitions, format, verification checklist) as a folder of instructions, so every week’s pack is built the same way. Grounded citations, as Anthropic’s platform documentation describes them, return the exact passages supporting each claim.

Source-grounded drafting still needs verification. Fortune reported in 2025 that Deloitte would partly refund the Australian government after a 237-page July report contained nonexistent citations and a fabricated judicial quote. The revision disclosed generative AI use, while Deloitte said the findings were unchanged. Vectara’s document-summarization leaderboard still showed nonzero unsupported-content rates for every listed model in October 2026.

Check that the cited passage supports the claim, is current and justifies any causal inference. A real citation alone establishes none of these.

This book’s verification protocol for any AI-assembled review pack has six rules:

1. Every number cites its source system and a timestamp. No citation, no number.
2. The owner reconciles headline numbers against the system of record before the pack circulates. Headline means anything in the summary, any output metric and any number tied to a decision.
3. Causal claims are labeled hypotheses unless the metric owner confirms them. “Acceptance fell because of the model change” stays a hypothesis until someone checks.
4. Spot-check a fixed sample of citations every week, chosen by the reviewer, not the author. Read the source and confirm the claim.
5. Disclose AI drafting and name the accountable human. Microsoft’s 2025 Work Trend Index report did exactly this, stating that AI helped produce it and that people reviewed and revised all AI-generated content. Copy the practice.
6. The owner writes the last sentence of every variance explanation. The model can propose; the owner states the cause, or states that it’s unknown.

The Beacon case: building Beacon’s operating system

The escalation that tested the system. The incident from Chapter 31, where a responder at a retail customer accepted the agent’s root cause, rolled back the wrong service and took checkout down for eleven minutes during a sale, met two triggers before anyone had written them down: it was customer-visible, and it needed a second team. The customer’s VP of IT Operations called Northlight’s CEO, so the escalation reached the top without passing anyone who could act on it. Afterward you write the policy you wish you’d had. Any AI-caused customer-visible incident reaches you and the applied AI lead within an hour and the VP of Product the same business day, with a one-page packet: what happened, what’s already changed, the options and the ask. An enterprise customer threatening churn alongside a security finding reaches the VP within 24 hours.

The decision log, rebuilt. You move the log out of the chat channel and backfill it. Two entries from the incident set the pattern. Pausing the agent’s rollback proposals is a two-way door: you’re the Approver, and the reversal trigger is the eval suite reaching its targets. Widening customer-allowlisted autonomous actions in future releases is treated as a one-way door for trust: the VP of Product approves, Sam’s security requirements sit in an explicit Agree role and the revisit date is tied to the next eval report.

The risk register, rewritten. “AI hallucination” was the only AI row. You rewrite it: because the agent can over-weight recent deploys and miss events outside the affected region, it may propose a wrong root cause with high confidence, which could lead a responder to take a harmful action in production. The early indicator is the eval suite’s rate of diagnoses with mismatched timelines; the escalation threshold is any customer-visible action taken on a wrong diagnosis. You map it to the AI RMF’s Measure and Manage functions, the first thing Sam asks about. A second row covers EU AI Act documentation, with regulatory dates and customer requests as triggers.

The weekly review, with an AI-built pack. Your product ops lead packages the WBR recipe as a team skill: connectors to the metrics store, incident tracker and CRM, the metric dictionary and the six-rule checklist. In the second week the checklist catches something the draft didn’t flag: inference cost per resolved incident cites a finance dashboard that hadn’t refreshed in three weeks. The finance partner corrects the figure before circulation. Nothing in the draft looked wrong; only the timestamp rule caught it.

The pricing decision. Moving Beacon Agents to a per-resolved-incident price is a Type 1 decision: it changes contracts, partner margins and revenue recognition, and is hard to undo once customers sign. You’re the Driver; the VP of Product for the Operations portfolio is the Approver; finance, product marketing and sales are Contributors; partners, including MSPs like Leo’s, are Informed before any announcement. The record lists three options (keep per-environment pricing, a hybrid, or a full move), each with pros, cons and cost. Chapter 15 covers the pricing itself; here the point is one Approver, a date and a record anyone can find.

The portfolio review. Your VP’s quarterly portfolio review asks for a posture for each part of Beacon. You propose invest for Beacon Agents, maintain for correlation and harvest, then divest for the legacy Beacon Classic engine through a migration, with the share of Classic customers migrated as the posture trigger. The review pushes back, rightly: several Classic customers call its correlation APIs from their own integrations, so a divest date set without pricing that cascade would break workflows Beacon doesn’t own. The date moves to the lifecycle plan in Chapter 30, gated on a migration path for API users.

The monthly narrative. You replace the status deck with a five-page monthly product review. The metrics table shows the outputs: ARR of about $48M growing 38% year over year, NRR of 118% and gross margin of 72%, down from 81% before the agentic features launched. The commentary concentrates on inputs: diagnosis acceptance, autonomous resolution and inference cost per resolved incident. The assumption-changes section is the longest. The plan assumed trust would grow with accuracy; the rollback showed that trust also depends on how the agent expresses uncertainty. The proposed course change is to ship calibrated confidence before widening autonomous actions. The VP reads in silence, writes eleven margin comments and speaks last.

The OP1 narrative. Next year’s plan is a narrative, not the deck template. Its thesis is that Beacon earns the right to act autonomously by proving it can diagnose reliably. It names three initiatives: launching Beacon Agents with supervised remediation at Northlight Live; recovering gross margin from 72% through inference cost work, toward a target the finance partner sets; and completing the AI Act documentation EU customers have asked for, owned with Sam. Its “what we will not do” section carries over the refusals from the strategy in Chapter 03, including no Beacon metrics store, which settles a request that had come up in three consecutive monthly reviews.

Product 360 artifacts

# Weekly business review · [Product] · Week of [Date]

**Pack owner:** [Name]   **Facilitator:** [Name]   **Length:** [30 to 60] minutes
**Data freshness:** [timestamp of the latest source refresh]   **Sources:** [systems of record]
**AI drafting:** [Yes/No]. Drafted by [harness or skill name]; verified by [Name] on [date].

## 1. What customers experienced last week
- Top customer events, incidents and escalations (max three), with links:
  1.
  2.
  3.

## 2. Output metrics (shown, not debated)
| Metric | This week | vs plan | vs prior year | Trailing 6 weeks | Owner |
|---|---|---|---|---|---|
| | | | | | |

## 3. Controllable input metrics (the discussion)
| Metric | Owner | This week | vs plan | Routine / Exceptional | Owner note |
|---|---|---|---|---|---|
| | | | | | |

Owner notes use one of three forms only:
- Routine: "Within normal range. Nothing to see here."
- Explained: "Exceptional. Cause: [cause, evidence link]. Action: [action, owner, date]."
- Unexplained: "Exceptional. Cause unknown. Next step: [investigation, owner, date]."

## 4. Actions from last week
| Action | Owner | Due | Status (done / on track / late) |
|---|---|---|---|
| | | | |

## 5. Taken offline
| Topic | Owner | Forum it goes to | Date |
|---|---|---|---|
| | | | |

## 6. Verification checklist (before circulation)
- [ ] Every number cites a source system and timestamp
- [ ] Headline numbers reconciled against the system of record by their owners
- [ ] Causal claims labeled "hypothesis" unless the owner confirmed them
- [ ] Citation spot-check done by the reviewer: [n] checked, [n] corrected
- [ ] Every variance explanation's final sentence written by its owner

# Monthly product review · [Product] · [Month, Year]

**Author:** [PM]   **With:** [finance partner, engineering lead, design lead]
**Review date:** [5 to 10 business days after month close]   **Length:** six pages or fewer, plus appendix
**Reviewers:** [leader, peers, invited stakeholders]   **AI drafting disclosed:** [Yes/No; verified by Name]

## 1. Summary (half a page, prose)
What happened, whether we're on track against the annual plan, and the one or two decisions or asks for this review.

## 2. Metrics against plan and prior year
| Metric | Type (input/output) | Actual | Plan | Prior year | Commentary |
|---|---|---|---|---|---|
| | | | | | |
Commentary: most of it on controllable inputs. For each exceptional move: cause, or "unknown" and next step.

## 3. Key initiatives (three to five)
| Initiative | Owner | Status (R/Y/G) | Input metric it moves | Headcount | Next milestone |
|---|---|---|---|---|---|
| | | | | | |
For anything yellow or red: what changed, what we're doing, what we need.

## 4. Assumptions that changed, and proposed course corrections
| Plan assumption | What we now believe | Evidence | Proposed change | Decision needed from |
|---|---|---|---|---|
| | | | | |

## 5. Top risks (from the risk register)
| Risk | Owner | Early indicator status | Change since last month |
|---|---|---|---|
| | | | |

## 6. Resources
Hiring against plan; fixed and variable operating cost against budget; inference or other usage-driven cost against budget.

## 7. Asks and decisions
1. [Decision or ask] · Approver: [Name] · Needed by: [Date]

## Appendix (never required reading)
6-12 charts, detailed tables, decision log entries made this month.

# Internal quarterly business review · [Portfolio or product] · Q[n] [Year]

**Owner:** [Portfolio leader]   **Contributors:** [PMs, finance, engineering, GTM leads]
**Format:** narrative preferred. If a deck is mandated, keep this order and write page 1 in prose.

1. **Summary and decisions needed** (one page, prose): the quarter in three sentences; the decisions and asks for this review, each with an Approver.
2. **Outputs against the operating plan**: revenue, retention, margin and the North Star against plan and prior year.
3. **Inputs and what moved them**: the controllable inputs that explain the outputs, with evidence. Label unconfirmed causes as hypotheses.
4. **Initiatives**: status (R/Y/G) for each plan initiative, the input metric it moves and the change since last quarter.
5. **Changed assumptions**: which plan assumptions no longer hold and what we propose instead.
6. **Cross-product tradeoffs**: shared resources, dependencies and conflicts only visible at portfolio level.
7. **Top five risks**: from the risk register, with owners, indicators and escalations this quarter.
8. **Next-quarter commitments**: what we will deliver, the metric each moves and what we will not do.
9. **Appendix**: per-product monthly reviews, 6-12 charts, decision log extract, headcount and budget detail.

Rule: decisions and asks come first. Nothing in the appendix is required reading.

# [Year] operating plan · [Product or portfolio] · OP1 draft v[n] / OP2

**Author:** [Name]   **Finance partner:** [Name]   **Due:** [Date]   **Top-down guidance received:** [Date, link]

## 1. Introduction and thesis (one paragraph)
What this product will achieve next year, and the single bet the plan rests on.

## 2. Last year in review
| Goal | Target | Actual | Hit / missed | What we learned |
|---|---|---|---|---|
| | | | | |

## 3. Key metrics (more than 5, fewer than 20)
| Metric | Type (input/output) | Owner | Q1 | Q2 | Q3 | Q4 | Year-end target |
|---|---|---|---|---|---|---|---|
| | | | | | | | |

## 4. Key initiatives
| Initiative | Leader | Start / finish | Metric it moves, and by how much | Resources | Elevated goal? (Y/N) |
|---|---|---|---|---|---|
| | | | | | |

## 5. Resources and organization
Headcount by team, hiring plan, operating cost, usage-driven cost (inference, cloud) and any org changes.

## 6. What we will not do
| Request or option declined | Who asked | Why not this year |
|---|---|---|
| | | |

## 7. Risks and dependencies
Top risks from the register; dependencies on other teams, with named counterparts and agreed dates.

## 8. FAQ
Questions a skeptical reviewer will ask, answered in advance.

## 9. Appendix
P&L, initiative detail, headcount table, roadmap.

## Change control
After OP2, changing a goal or adding resources requires approval from [role]. Adding an initiative within existing resources requires [role].

## OP2 revision (January)
Variance against Q4 actuals: [summary]. Changes from OP1: [list, with reasons].

# Portfolio review · [Portfolio] · [Quarter or half, Year]

**Owner:** [Portfolio leader]   **Approver for posture changes:** [Name]   **Investment envelope:** [amount or headcount]

## Portfolio summary
| Product or bet | Current posture | Proposed posture | Market growth | Our position | Gross margin (after usage costs) | Investment this year | Investment next year | Decision needed |
|---|---|---|---|---|---|---|---|---|
| | | | | | | | | |

Postures: Invest (grow; fund ahead of revenue) · Maintain (hold; fund sustainably) · Harvest (minimize new investment; maximize cash and retention) · Divest (exit through sunset, sale or migration).

## Per product or bet
### [Name]
- Posture now and proposed:
- Evidence for the proposal (input and output metrics, customer evidence):
- Strategic fit:
- **Posture trigger** (the evidence that would move this to a different posture):
- Dependencies (other products, partners, customer integrations that rely on it):
- Cost of the cascade if divested:
- Decision needed and Approver:

## Decisions made
Recorded in the decision log: [links]

# Decision log · [Product or portfolio]

**Log owner:** [Name]   **Location:** [single shared location]   **Review:** monthly for revisit dates

| ID | Date | Decision (one sentence) | Door type (one-way / two-way) | Driver | Approver | Contributors | Informed | Options considered | Evidence (links) | Outcome / status | Reversal trigger | Revisit date |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| D-001 | | | | | | | | | | | | |

## Full record (for one-way doors)
### D-[ID] · [Decision title]
- **Status:** Not started / In progress / Decided   **Impact:** High / Medium / Low   **Due:** [Date]
- **Background (one or two sentences):**
- **Relevant data:** [links, with timestamps]
- **Decision factors (criteria):** [e.g. cost, time to market, reversibility, customer trust]
- **Options (at least three):**

| Option | Description | Pros | Cons | Cost (money and people) |
|---|---|---|---|---|
| A | | | | |
| B | | | | |
| C | | | | |

- **Veto holders, if any (RAPID's Agree role):**
- **What information would change this decision:**
- **Outcome:** [decision, Approver, date]
- **Dissent recorded, and commitment confirmed:**
- **Action items:** [action, owner, date]

# Risk register · [Product or portfolio]

**Register owner:** [Name]   **Top risks reviewed:** monthly   **Full review:** quarterly   **Last full review:** [Date]

| ID | Risk statement (Because [cause], [event] may happen, which would [consequence]) | Category | AI RMF function (Govern / Map / Measure / Manage), if AI | Likelihood (H/M/L) | Impact (H/M/L) | Owner | Mitigations in place | Mitigations planned | Early indicator | Escalation threshold, and to whom | Status | Last reviewed |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| R-001 | | | | | | | | | | | | |

Categories: customer, security, AI behavior, regulatory, commercial, delivery, dependency, people.

## Dated triggers (regulatory and contractual)
| Date | Obligation or event | Affected risk IDs | Owner | Readiness |
|---|---|---|---|---|
| | | | | |

## Closed risks
| ID | Closed on | Why (mitigated / occurred / no longer relevant) | Lesson |
|---|---|---|---|
| | | | |

# Escalation policy · [Product or portfolio] · v[n] · [Date]

**Policy owner:** [Name]   **Approved by:** [Name]   **Last tested (tabletop):** [Date]

## When to escalate (any one trigger is enough)
- Customer-visible impact, including any customer action taken on a wrong AI output
- A second team is needed to resolve it
- Unresolved after [time] of concentrated work
- A proposed change to the plan of record (goal, date or resources)
- Budget or usage-cost variance above [threshold]
- Security, privacy or regulatory exposure
- An enterprise customer threatening churn
- A disagreement between owners unresolved after [time]

Escalating early is expected. Nobody is judged for escalating against a trigger.

## Levels
| Level | Who (role and name) | Response time | Can decide |
|---|---|---|---|
| 1 | [PM and engineering lead] | [time] | [scope] |
| 2 | [Group PM or director] | [time] | [scope] |
| 3 | [VP of Product, with peer VPs as needed] | [time] | [scope] |

## The escalation packet (one page, required)
1. What happened, and the impact, with evidence
2. What has already been done
3. Options (at least two), with tradeoffs
4. Recommendation
5. The specific ask, and by when

## Handoff
State explicitly who owns the issue now, and confirm acknowledgment in writing.

## Closure
- The Approver decides; everyone commits, including those who disagreed.
- The decision goes into the decision log; the risk register is updated.
- For customer-visible incidents, a correction-of-error narrative goes to the next monthly product review.

Prompts

Goal: Get a first draft of the WBR pack in minutes, with every number traceable.
Paste in (or connect the harness to): the WBR metric list with definitions, owners and targets; read access to the metrics store, incident tracker and CRM; last week's pack and action list. Use an approved tool if the data includes customer names or contract values.

Build this week's weekly business review pack for [product], week of [date], using the attached template.

Rules:
1. Every number must cite its source system, the exact report or query it came from and the source's last refresh timestamp. If you can't find a source or the refresh is older than [n] days, write "UNVERIFIED" instead of the number.
2. For each input metric, compare this week with its normal range over the last [20] weeks. Label it "routine" or "exceptional" and say why in one line. Don't explain routine moves.
3. For exceptional moves, list up to three candidate causes with the evidence for each, labeled "hypothesis for owner." Don't pick one.
4. Summarize what customers experienced: the top three incidents, escalations or notable tickets, with links.
5. Carry forward last week's actions with their current status from the tracker.
6. End with a list of every claim you couldn't verify.

Check the output: open the three oldest timestamps and two random citations yourself. Make sure no owner note has been written for the owner; the "hypothesis for owner" lines are prompts for them, not explanations.

Goal: Catch stale numbers, broken citations and invented causes before a leader reads them.
Paste in: the draft pack, the metric dictionary and exports or links from the systems of record for the headline numbers.

Act as the reviewer of this [weekly / monthly / quarterly] review pack for [product]. Check it against the attached sources and report, in a table:

1. Every headline number (anything in the summary, any output metric, any number tied to a decision): matches the source / doesn't match / can't check. Give the source value and timestamp.
2. Every citation in a random sample of [10]: does the cited passage exist, and does it support the claim as written?
3. Every causal claim ("X drove Y", "because", "due to"): is it labeled as a hypothesis or confirmed by a named owner? List any that aren't.
4. Any metric whose definition in the pack differs from the metric dictionary.
5. Any source older than [n] days.

Return findings for human review, ranked by their potential to mislead a decision. Preserve the supplied pack.

Check the output: re-check two of the items the model marked "matches" yourself. A reviewer that never finds anything isn't reviewing.

Goal: Turn a month of weekly reviews into a first-draft narrative of six pages or fewer.
Paste in: the month's WBR packs and action logs, the annual plan (metrics, initiatives, assumptions), the top of the risk register, the month's decision log entries and the budget report.

Draft a monthly product review narrative for [product] for [month], using the attached template. Write in full sentences, not bullets, except for the tables.

1. Summary: half a page. State whether we're on track against the annual plan and the one or two decisions this review needs.
2. Metrics against plan and prior year: put most of the commentary on controllable inputs.
3. Initiatives: status and the input metric each moves.
4. Assumptions that changed: compare each plan assumption with this month's evidence and list those that no longer hold. This is the most important section; don't leave it empty without saying why.
5. Risks, resources and asks.

Label every causal claim as a hypothesis unless the action logs show an owner confirmed it. Keep it to [n] pages; move detail to an appendix that nobody has to read.

Check the output: rewrite the summary and the assumptions section yourself. They carry your judgment, and the model can only propose them. Confirm every number against the verified WBR packs.

Goal: Find the weaknesses a senior reviewer will find, before the OP1 review.
Paste in: your plan narrative draft, the top-down guidance and last year's plan with actuals.

Act as a demanding executive reviewing this annual operating plan for [product]. Read it through five lenses, one at a time:
1. Facts and truth: which claims lack evidence or contradict last year's actuals?
2. Strategic vision: does the plan follow from a clear thesis, or is it a list?
3. Metrics and initiatives: does every initiative name the metric it moves and by how much? Are there more than 5 and fewer than 20 key metrics?
4. Achievability: which commitments look unrealistic given the resources and last year's delivery record?
5. Resource allocation: where is investment misaligned with the stated priorities?

Then write the ten questions you'd ask in the review, and list anything that should be in a "what we will not do" section but isn't.

Check the output: answer each of the ten questions in the plan's FAQ, or change the plan. Ignore any critique that relies on facts not in the materials.

Goal: Turn a stuck discussion into a decision with one Approver and a date.
Paste in: the thread, notes or documents where the decision has been debated, and the names and roles of the people involved.

From this material, draft a DACI decision record for: [decision].

1. Propose a Driver, one Approver, Contributors and Informed, with a one-line reason for each. If more than one person seems to think they're the Approver, say so explicitly.
2. Write the background in one or two sentences.
3. List the decision factors (criteria) that people have actually argued about.
4. Lay out at least three options, including any that were mentioned and dropped, each with pros, cons and estimated cost.
5. Classify the decision as a one-way or two-way door, and explain why.
6. List what information would change the decision, and whether waiting for it is worth the delay.
7. Flag anyone who appears to hold a veto (security, legal, compliance).

Don't recommend an option. Don't invent costs or facts not in the material; write "unknown" instead.

Check the output: confirm the Approver with that person before circulating. Check that each option is described fairly enough that its advocate would agree with the summary.

Goal: Find the forums that cost more than they return.
Paste in (or connect): your calendar for the last [8] weeks, the list of recurring forums with attendees, and the decision log and action logs. Use an approved tool for calendar data.

For each recurring forum I attend or own:
1. Estimate the hours it consumes per month: attendees multiplied by duration, plus a preparation estimate I'll confirm.
2. From the decision and action logs, list what it changed in its last three sessions: decisions made, resources moved, owner actions created.
3. Flag forums with no changes in their last three sessions, forums that overlap more than half their attendees and agenda with another, and forums making two-way-door decisions with a one-way-door process.
4. Recommend for each: keep, merge (with which), shrink or cancel.

Check the output: talk to the owner of each forum flagged for cancellation before acting. Logs undercount the decisions made in a room; ask what would break if it stopped.

Goal: Turn incidents, customer requests and regulatory deadlines into risks someone owns.
Paste in: recent incident reviews, security questionnaire findings, customer escalations, the current register and any regulatory dates that apply. Use an approved tool for customer and security data.

Review this material for [product] and propose risk register entries.

For each risk:
1. Write it as: "Because [cause], [event] may happen, which would [consequence]."
2. Assign a category and, for AI risks, the NIST AI RMF function (Govern, Map, Measure or Manage) it falls under, with a one-line reason.
3. Propose likelihood and impact (H/M/L), citing the evidence.
4. Propose an early indicator we can actually observe and an escalation threshold.
5. Mark whether it duplicates or should be merged with an existing register entry.

List dated obligations separately, with their source. Don't assign owners; leave that field blank for me.

Check the output: confirm every regulatory date against the official source before adding it. Assign one owner per risk yourself, and delete any risk nobody will own.

Anti-patterns

Checklist

• Every recurring forum has a stated purpose, an owner and evidence that it changed a decision, resource or action in its last three sessions.
• Recurring decision types are sorted into one-way and two-way doors, and two-way doors are delegated with a log entry.
• A decision-rights map names the Driver, one Approver, Contributors and Informed for each recurring decision type, with veto holders named explicitly.
• The decision log is in one shared location and records door type, options, evidence, reversal trigger and revisit date.
• The WBR runs on controllable inputs with named owners, and every variance explanation uses one of the three forms.
• The monthly product review is a narrative of six pages or fewer, held 5 to 10 business days after close, with a substantive assumption-changes section.
• The internal QBR puts decisions and asks first and keeps required reading out of the appendix.
• The annual plan narrative has more than 5 and fewer than 20 key metrics, initiatives with owners and metric impact, and a “what we will not do” section.
• The portfolio review states a posture, the evidence and a posture trigger for each product or bet, and prices dependencies before any divest decision.
• A quarterly metric review has retired or changed at least one metric.
• Every risk in the register has one owner, an early indicator and an escalation threshold; AI risks are mapped to the AI RMF functions and regulatory dates are tracked.
• The escalation policy has objective triggers, levels with response times, a one-page packet, an explicit handoff and a closure rule, and has been tested in a tabletop exercise.
• AI-drafted review packs follow the six verification rules, disclose AI drafting and name the accountable human.
• The governance calendar is audited every six months for hours spent against decisions produced.