Product Operations

Product operations supplies trusted metrics, customer evidence and an operating rhythm. It helps PMs decide with less reporting work and gives leaders clear decision rights, planning dates and controls for shared AI tools.

Why this matters

As teams multiply, metric definitions diverge, feedback fragments and planning becomes deck production. These failures weaken strategy: leaders debate numbers, loud customers dominate and delayed decisions become engineering commitments by default.

Melissa Perri described product operations in 2019 as removing obstacles to evidence-based decisions. Use that test for the function: does it make good decisions faster and safer? This chapter covers the Operate dimension’s function, calendars, decision rights and tool access. Chapter 29 covers the governance forums they support.

The product operations model

Three pillars (Perri and Tilles)

Melissa Perri and Denise Tilles organize Product Operations (2023) around three inputs that product teams need at scale:

1. Data and insights. One trusted source for business and product metrics, connecting financial outcomes (revenue, retention, cost) to what the teams ship. Chapter 00 of this book calls this pillar business and data insights, because in B2B the business numbers are the point: ARR, net revenue retention and gross margin by product are what earn product ops its credibility with Finance.
2. Customer and market insights. A standing flow of research, feedback, win-loss notes and market intelligence, routed to the teams that need it instead of hoarded by whoever heard it first.
3. Process and governance. The product operating model: the planning calendar, the rituals, the templates, the decision rights and the tools that make them run.

Their examples include Stripe, Uber, athenahealth and Fidelity, alongside guidance on introducing the function into an existing organization.

The force multiplier, and its guardrails (Cagan)

Marty Cagan’s December 2021 SVPG article uses three related labels: quantitative insights, qualitative insights, and tools and best-practices evangelism. Crediting Perri’s earlier work, he describes product ops as a force multiplier for PMs, designers and sometimes product marketers. His guardrails preserve their accountability:

Cagan warns that “process becomes the thing” when scope expands unchecked. Require every template, ritual and approval step to identify the decision it improves.

What product ops owns

This book combines the models into six responsibilities:

1. The operating cadence. The weekly, monthly, quarterly and annual rituals. Product ops schedules, preps and records them; product leaders run them.
2. The planning calendar. The year view that aligns product planning with the fiscal calendar, the board cycle, budget submissions and the annual customer event.
3. Data and the metric glossary. One definition per metric, one system of record per data type, self-serve access and, in 2026, the monthly AI quality and cost report.
4. The feedback system. One repository for customer signals from every channel, tagged so a PM can ask one question across all of it.
5. Templates and decision rights. Standard formats for recurring work (PRD, DACI, launch tier, QBR), increasingly packaged as shared skills in the AI harness, and the register of who decides what.
6. PM enablement. Onboarding, training and tool access, so a new PM contributes in weeks rather than a quarter.

PMs and leaders retain roadmap content, priorities, customer commitments and pricing decisions.

When to create the function

Research establishes no headcount threshold for product ops. Pendo’s vendor heuristic suggests five to ten PMs or post-Series B, when administration, scattered data and inconsistent processes grow. Perri’s warning signs include unreliable metrics, stale research, weak feedback loops, unclear authority and status meetings without decisions.

This book’s heuristic is to watch for three signals instead of counting PMs:

• Shared calendar. Three or more product teams depend on one planning calendar, so a slip in one team’s plan becomes everyone’s problem.
• Unstable numbers. Leaders can’t ask for the same metric twice and get the same answer.
• Deck season. PMs spend planning season building slides, and decisions wait for the slides.

When two signals are present, this book recommends one senior person focused on the most painful pillar. In B2B, a shared metric glossary often comes first. A credible portfolio-wide lead, as at Northlight, can change senior PMs’ practices without creating a coordination bureaucracy.

The operating cadence in depth

Chapter 00 sets two cadence rules: each ritual produces a decision or is cancelled, and each decision is recorded. Product ops adds ownership, preparation and harness-supported pre-work.

Three established rhythms inform the cadence. Working Backwards, by Colin Bryar and Bill Carr, describes Amazon’s weekly business review and annual OP1/OP2 plans. Google’s re:Work OKR guide uses annual and quarterly goals, check-ins and 0.0–1.0 grading, with 0.6–0.7 as its suggested range. Ryan Singer’s Shape Up offers six-week work cycles, two-week cool-downs and a small senior betting table choosing the next uninterrupted cycle. Choose the rhythm that fits your organization.

Weekly: the metric walk and the team sync

In the weekly metrics review, metric owners walk a fixed set of metrics, explain any variance from the expected trend, and say what they’ll do about it. Keep the set fixed: if the dashboard changes every week, nobody learns what normal looks like.

Product ops checks dashboard definitions against the glossary before the review. The PM owns the team sync. Product ops keeps its decision log and risk register accessible.

Monthly: product review, voice of the customer, and AI quality and cost

The monthly product review combines roadmap progress, OKRs, competition and customer insights into leadership decisions. Product ops prepares a consistent pack for comparing teams.

Add a voice-of-the-customer readout with themes by segment, representative quotes and accounts. Teams shipping AI also need an AI quality and cost review covering evals, new failures, cost per successful outcome and margin.

Quarterly: business review and planning

The quarterly business review (QBR) looks backward: business results, OKR grades, lifecycle changes and what was learned. Quarterly planning looks forward: next quarter’s bets, staffing and dependencies. Keep them separate. When a single meeting does both, the retrospective gets squeezed into the last ten minutes and the lessons never reach the plan.

Product ops runs the quarterly machinery: it publishes the planning calendar, collects the insight pack, schedules the betting table or portfolio review, chases the capacity check with engineering and publishes the roadmap internally and to the field. Product leaders own the choices.

Annual: strategy refresh and planning

The annual cycle refreshes vision, strategy, personas and positioning, then produces the plan and budget. Product ops aligns these with Finance’s deadlines, the fiscal year, board meetings and customer events.

Calibrating process weight: one-way and two-way doors

Jeff Bezos’s 2015 shareholder letter distinguishes Type 1 decisions, consequential and difficult to reverse, from Type 2 decisions, which are reversible. He recommends quick Type 2 decisions by small groups and warns against applying heavyweight processes to them.

Assign process weight by reversibility. Roadmap sequencing usually stays with the team. Pricing models, deprecations, contracts and autonomous production actions warrant written evidence, named roles and leadership review.

The planning calendar

The operating cadence is the repeating rhythm. The planning calendar is the specific set of dated milestones that turns one quarter into the next, and the year into the next year. Product ops publishes it, and every milestone has an owner and a required input.

The offsets below are this book’s synthesis, not a published standard; adjust them to your company’s size and fiscal year.

Overlay strategy refresh, Finance’s budget deadline, annual pricing review, event code freeze and enablement dates on the quarterly calendar. One view exposes collisions across teams.

Decision rights: DACI, RACI and RAPID

Decision rights identify who decides and prevent meetings from ending with unresolved ownership.

DACI

DACI, popularized by Atlassian through its Team Playbook, names four roles for a single decision:

• Driver: gathers the stakeholders and information, sets the scope and gets a decision by the agreed date. Usually the PM.
• Approver: makes the decision. Atlassian is emphatic that this is one person.
• Contributors: have expertise and a voice, but no vote.
• Informed: are told the outcome. No voice, no vote.

Atlassian’s DACI document records the question, status, impact, people, deadline, background, evidence, decision factors, options, costs, actions and outcome. Its play suggests fifteen minutes of preparation and an hour with three to six people. This book uses DACI for most one-off product decisions.

RACI and RAPID

RACI (Responsible, Accountable, Consulted, Informed) assigns roles to tasks and deliverables, where DACI assigns them to a decision. Responsible people do the work; one Accountable person signs off; Consulted people are in two-way conversation; Informed people get one-way updates. It fits recurring operational work such as the release process or launch tiers, where the same roles apply every time.

RAPID, from Bain & Company, adds a role that DACI lacks: Agree, a sparing veto for people who must sign off on feasibility or mandatory requirements, such as Legal or Security. The other roles are Recommend (leads, gathers input, proposes), Perform (executes), Input (consulted, doesn’t decide) and Decide (ideally one person, who commits the organization and resolves any deadlock between Recommend and Agree). Bain suggests applying it first to high-value or high-frequency decisions.

The decision-rights register

Pre-assign recurring decisions in a decision-rights register. For pricing, deprecation, autonomous actions, committed roadmap changes, model swaps and launch tiers, record the door type, framework, roles and forum. Chapter 29 covers decision logging and review.

The PM tool stack in 2026

Product ops maintains one system of record per data type, removes overlapping tools and sets access rules. Cagan and Pendo include tooling in the function’s remit. Add explicit controls for harness and in-tool agent access.

Anthropic introduced Model Context Protocol (MCP) in November 2024 to connect AI assistants with data and tools. It donated MCP to the Linux Foundation’s Agentic AI Foundation in December 2025, reporting more than 10,000 active public servers. Vendor examples include Amplitude analysis, Linear issue access with a read-only scope, Atlassian Rovo search and workflow agents, and Productboard Spark for product and feedback work. Treat capabilities as dated examples.

That leaves product ops with a new design question for each category: what is the system of record, and what can the harness and the in-tool agents read or write?

Vendor names are examples and capabilities change quickly; the categories and the access rules are what product ops should standardize. Read-only should be the default for every connector, with write access granted per use case and logged.

Anthropic introduced Agent Skills in October 2025 as folders of relevant instructions, scripts and resources, adding organization-wide management in December. Product ops can package PRD, DACI and QBR formats as shared skills so harness drafts use the organization’s current template.

Measuring product ops

Measure decision speed and quality, using your own baselines. This book’s measures below have no verified benchmark. Template volume alone says little about the function’s value.

Pendo’s vendor guidance lists similar measures, such as PM time on strategic work and time from insight to decision. Its numeric targets come without sources, so set your own.

How to apply it

This method sets up product operations for a portfolio, or repairs a function that has drifted. It assumes one senior product ops person working with a sponsoring product leader and two or three PMs as pilot customers. Plan on a quarter.

Weeks 1 and 2: Diagnose.

1. Interview every PM and two or three field leaders (sales, customer success, support) for thirty minutes each. Ask where they lose time, which numbers they don’t trust, where customer evidence goes to die, and which decisions stall. Have the harness cluster the notes and count how often each pain appears.
2. Audit the last two QBRs and the last planning cycle. Mark every metric that appeared with two definitions, every decision that slipped past its date and every meeting that ended without a decision.
3. Score the three pillars red, amber or green, and pick one to fix first. Usually it’s the metric glossary, because every ritual depends on it.

Weeks 3 and 4: Charter.

4. Write the product ops charter: mission, customers, scope by pillar with Cagan’s “we do / we do not” lines, services with response times, owned artifacts, and the measures you’ll report. Get the product leader to sign it, and share it with every PM.
5. Agree the measures and take a baseline. At minimum, measure insight latency, metric disputes and ritual decision yield.

Weeks 5 to 8: Install the foundation.

6. Publish the metric glossary for the ten to fifteen metrics leaders actually use, with one owner and one system of record each. Retire the duplicates.
7. Draw the tool stack map. Name the system of record for each data type, set read-only as the default harness access, and list overlapping tools to cut at renewal.
8. Build the detailed operating cadence calendar. Start from the meetings that already exist, absorb rituals into them where you can, and cancel any ritual with no decision output.
9. Publish the planning calendar for the next two quarters with the annual overlay. Send it to Finance and the field, not just product.
10. Write the decision-rights register for the five to eight recurring decision types that cause the most friction.

Weeks 9 to 12: Run it and enable PMs.

11. Run one full monthly cycle and one quarterly planning cycle on the new calendar. Product ops preps and records; product leaders run the rituals.
12. Package the core templates (PRD, DACI, QBR pack, launch tier) as shared skills in the team’s harness, so the formats are applied the same way every time.
13. Assemble the PM onboarding kit and test it on the next new PM. Ask them where they got stuck in week one.
14. Report the measures against the baseline at the QBR. Keep what moved, cut what didn’t, and review the charter.

Then put the charter on an annual review. Product ops should shrink its own process as often as it adds to it.

The AI lens

Product ops for AI-powered products

AI features add two things to the business and data insights pillar that most product ops functions weren’t built for: quality that has to be measured continuously, and cost that varies with every request.

Eval reporting. Anthropic’s January 2026 engineering guidance on evaluating AI agents gives product ops a vocabulary it can standardize across teams. An eval runs a task over several trials, a grader scores each one, and the transcript (the full trace) shows what the agent did. Graders come in three kinds: code-based (fast, cheap, brittle), model-based (flexible, but needs calibration against human judgment) and human (best, slow). Report two pass rates separately:

• Capability evals measure what the agent is learning to do. They should start low and climb.
• Regression evals protect what already works. They should sit near 100%; a drop is an incident.

Promote reliably passing capability tasks into regression tests. Separate pass@k (one or more successes in k trials) from pass^k (every trial succeeds). Autonomous actions need consistency: at 75% success per independent trial, three consecutive successes occur about 42% of the time. Start with 20–50 tasks from real failures, inspect traces and investigate persistent 0% results for broken tasks or graders.

Cost reporting. The FinOps Foundation’s FinOps for AI group (October 2026 overview) names Product as a core cost-management role. Product and engineering set quality and value requirements, FinOps supplies cost data, and Finance participates early. Track cost per inference, blended token cost, cache hit rate and model fit. For decisions, prioritize cost per successful outcome: total run cost divided by successful runs, including failed-run costs in the numerator. Report distributions by use case because long runs can dominate bills. Include system prompts, history and retrieval in token accounting.

Model providers publish usage and cost reports; Anthropic’s, for example, breaks token use down by model, workspace and API key, reports daily cost in US dollars, and has data available within about five minutes. Product ops pulls these through a connector, joins them to outcome data and publishes the monthly view.

Doing product ops with AI

The harness changes the work of product ops more than it changes the shape of the function.

• Ritual pre-work. Before the metrics review, the harness pulls the dashboard through the analytics connector, compares each metric to its expected range and drafts variance notes for the owners to correct. Before the product review, it assembles team updates into the standard pack. Product ops checks the pack; it no longer builds it.
• Feedback synthesis. With read access to tickets, call notes and the feedback repository, the harness clusters a month’s signals into themes with linked quotes and accounts. Keep the evidence attached, as Chapter 01 insists: a theme that can’t be traced to at least two real customers is the model’s opinion.
• Templates as skills. A new PM gets the same PRD, DACI and QBR structure as a veteran, and a template change reaches everyone at once.
• Decision hygiene. After each ritual, the harness drafts the decision log entry from the notes, with roles from the register filled in, for the Driver to confirm.
• Onboarding. A new PM can ask the harness to summarize last quarter’s decisions, list open risks and explain the glossary from the team’s own documents.

Apply three controls: read-only connector defaults, approved tools for each customer-data class, and metric-owner sign-off before numbers reach leadership. Grant write access per logged use case and review it at renewal.

The Beacon case: a charter for the Operations portfolio

Diagnosis. You and the ops lead interview the three Beacon PMs, the Observe and Desk group PMs and leads from sales, customer success and support. The harness clusters the notes. Three pains dominate: nobody trusts MTTR, nobody can answer “which customers had autonomous actions rolled back?” without a manual hunt, and planning for Northlight Live runs on a slide rather than a calendar. You score business and data insights red, and the other two pillars amber.

The charter. You write it for the whole Operations portfolio, with Beacon as the pilot, and the VP signs it. The “we do not” column does most of the work: the shared ops lead doesn’t do PMs’ analysis, run their research or decide what goes on any roadmap. The lead owns the metric glossary, the feedback tagging, the two calendars, the decision-rights register, the tool stack map and the onboarding kit. The charter makes no headcount request. Whether the portfolio needs a second ops person is a question for the next annual plan, and the charter’s measures will inform it.

One MTTR. The glossary entry takes two meetings. Observe measures MTTR from first alert; Beacon measured from incident creation; the CS deck used customer-reported times. The VP decides, using the DACI the ops lead drafted: MTTR runs from first correlated alert to resolution, from Beacon’s telemetry, with Observe data as the cross-check. The decision goes in the log, and the other two numbers come off every dashboard.

The cadence. You add a monthly AI quality and cost review for Beacon. It tracks diagnosis acceptance rate, autonomous resolution rate, regression pass rate, pass^k for the allowlisted autonomous actions, the distribution of cost per resolved incident, and gross margin. The first session surfaces what the averages had hidden: a small share of very long diagnosis runs accounts for a large share of inference cost. That becomes a bet for the next quarter: cap run length, route simple incidents to a smaller model, and watch whether diagnosis acceptance holds.

The planning calendar. The ops lead works back from Northlight Live. Code freeze for Beacon Agents, the enablement milestone for sales and partners, the security documentation pack for reviewers like Sam and the press briefing all go on one page, alongside the quarterly planning weeks and Finance’s budget deadline. Two collisions appear immediately: the enablement milestone fell in the same week as week −3 planning, and the security pack was due after code freeze. Both move.

Decision rights. The register pre-assigns the decisions that kept stalling.

The rollback decision gets the heavy process: a full DACI document, pass^k eval results on the allowlisted actions, and a security review. The backlog reorder gets none.

The stack. The tool stack map names one system of record per data type and sets harness access: read-only for work tracking, analytics, eval results and provider cost reports; read with customer identifiers masked for the feedback repository; read-write only in the team’s docs space. The rollback question that took two weeks now takes an afternoon, because the harness can join rollback events from analytics to the tagged tickets in the feedback repository.

Measures. The charter commits to three by the next QBR: one MTTR definition used everywhere, same-day answers to the rollback question, and a shorter time to first logged decision for the next PM who joins. That PM arrives a month later to cover Leo’s MSP persona and gets the onboarding kit on day one, including a schedule for shadowing calls with two MSP partners and a set of first-week prompts. They log a first decision (the multi-tenant view’s default sort, a two-way door) in week three.

Product 360 artifacts

# Product operations charter · [Portfolio or organization] · v[n] · [Date]

**Sponsor:** [Product leader]   **Product ops lead:** [Name]   **Review date:** [Date, at least annually]

## Mission
One sentence: Product operations makes it faster and safer for [product teams] to make evidence-based decisions by [how].

## Customers of product ops
| Customer | What they need from us | How we'll know it works |
|---|---|---|
| PMs and designers | | |
| Product leaders | | |
| Field (sales, CS, support, partners) | | |
| Finance | | |

## Scope by pillar
| Pillar | We do | We do not |
|---|---|---|
| Business and data insights | Own the metric glossary and one source of truth; provide self-serve dashboards; publish the monthly AI quality and cost report | Do teams' analysis for them |
| Customer and market insights | Run the feedback repository and its tagging; maintain the research panel; publish the monthly voice-of-the-customer readout | Run teams' discovery or interviews for them |
| Process and governance | Publish the cadence and planning calendars; prep and record rituals; maintain the decision-rights register, templates and skills; onboard PMs | Make product decisions; own the roadmap; add process that no decision needs |

## Services and response times
| Service | Request route | Response time |
|---|---|---|
| New metric or definition change | | [e.g. decision within 2 weeks] |
| Access to a tool or connector | | |
| Ad hoc data question | | [self-serve first; escalation within N days] |
| New template or skill | | |

## Owned artifacts
- Metric glossary
- Operating cadence calendar
- Planning calendar with annual overlay
- Decision-rights register
- Tool stack map
- Template and skill library
- PM onboarding kit

## Decision rights of product ops itself
Product ops decides: [tool selection within budget, template formats, calendar dates, connector access defaults].
Product ops recommends, a product leader decides: [new rituals, new required steps, tool purchases above threshold].
Product ops never decides: roadmap content, priorities, pricing, customer commitments.

## Measures (baseline and target)
| Measure | Baseline | Target | Date |
|---|---|---|---|
| Insight latency | | | |
| Metric disputes per quarter | | | |
| Ritual decision yield | | | |
| New PM time to first logged decision | | | |

## Process budget
Every new ritual, template or required step names the decision it improves. Each review, we retire at least one thing that no longer does.

# Operating cadence calendar · [Product or portfolio] · [Quarter]

**Owner:** [Product ops lead]   **Sponsor:** [Product leader]   **Last reviewed:** [Date]

| Ritual | Frequency and slot | Runs it | Product ops prep | Attendees | Inputs | Decision output | Recorded in | Harness pre-work |
|---|---|---|---|---|---|---|---|---|
| Metrics review | Weekly, [day, time], 30 min | Product leader or PM | Glossary check on every number; dashboard refreshed | PMs, eng leads, analyst | Dashboard, risk register | Variances explained; actions; escalations | Decision log | Draft variance notes against expected ranges |
| Team sync | Weekly, [slot] | PM | Decision log and risk register linked | Product team | Decision log, discovery log | Decisions logged | Decision log | Summarize open decisions and new evidence |
| Sprint review and planning | Biweekly, [slot] | Eng lead and PM | None | Product team | Backlog, release plan | Sprint commitment | Tracker | Draft release notes from closed work |
| Product review | Monthly, [slot], 60 min | Product leader | Standard update pack per team | Leadership, PMs, eng, design, PMM | Roadmap, OKRs, competitive changes, insight summary | Roadmap changes; asks for help | Decision log | Assemble team updates into the standard pack |
| Voice-of-the-customer readout | Monthly, [slot], 45 min | Product ops | Themes by segment from the repository | PMs, CS, support, sales | Feedback repository, win-loss | Themes assigned to owners | Feedback repository | Cluster the month's signals with linked quotes and accounts |
| AI quality and cost review | Monthly, [slot], 60 min | Product leader | Eval scorecard; cost distribution; margin view | PMs, applied AI, eng, finance partner | Eval results, usage and cost reports | Quality and cost actions; model or routing changes | Decision log | Draft scorecard and flag regressions and cost outliers |
| Quarterly business review | Quarterly, week 13 | Product leader | Results pack; OKR grades | Leadership, finance, sales, CS | Business model, OKRs, lifecycle stage | Lessons; staffing and pricing asks | QBR record | Draft the results narrative from the quarter's data |
| Planning or betting table | Quarterly, week −3 | Product leader | Insight pack; ranked bets; capacity | Product and eng leadership | Draft bets, capacity estimate | Next quarter's bets | Roadmap | Summarize each bet against OKRs and evidence |
| Roadmap publication | Quarterly, week −1 | Product ops with PMM | Field-safe roadmap version | Field, partners | Approved bets | Published roadmap | Roadmap | Draft the field version and FAQ |
| Strategy refresh | Annually, [month] | Product leader | Durable artifacts audited for staleness | Leadership | Vision, strategy, personas, positioning | Strategy for the year | Strategy one-pager | Flag contradictions between durable artifacts |
| Annual planning | Annually, aligned to fiscal year | Product leader with Finance | Budget template; planning calendar | Leadership, finance | Strategy, business case | Plan of record; budget | Annual plan | Draft the plan narrative from the strategy and results |

## Rules
1. Every ritual produces a decision or is cancelled.
2. Every decision is recorded where the table says.
3. Two-way-door decisions are made in the team rituals. One-way-door decisions follow the decision-rights register.

# Planning calendar · [Organization] · FY[year]

**Owner:** [Product ops lead]   **Fiscal year starts:** [Date]   **Annual customer event:** [Date]

## Quarterly milestones (repeat for each quarter)
| Week (relative to quarter start) | Milestone | Owner | Required input | Q1 date | Q2 date | Q3 date | Q4 date |
|---|---|---|---|---|---|---|---|
| −6 | Insight pack published | Product ops | Metrics vs OKRs, customer themes, competitive changes, AI eval and cost trends | | | | |
| −4 | Draft bets due | PMs | One-page bets linked to OKRs | | | | |
| −3 | Betting table or portfolio review | Product leader | Ranked bets, capacity estimate | | | | |
| −2 | Capacity and dependency check | Eng leads | Staffing plan, dependencies | | | | |
| −1 | Roadmap published (internal and field) | Product ops with PMM | Approved bets | | | | |
| 1 | Quarter starts; OKRs set | Product leader | Final OKRs | | | | |
| 6 | Mid-quarter check | Product ops | OKR progress, risks | | | | |
| 13 | QBR | Product leader | Results, grades, lessons | | | | |

## Annual overlay
| Milestone | Date | Owner | Depends on |
|---|---|---|---|
| Strategy refresh | | | |
| Budget submission to Finance | | | |
| Board meeting(s) | | | |
| Annual pricing review | | | |
| Customer event: code freeze | | | |
| Customer event: enablement complete | | | |
| Customer event: security and compliance pack ready | | | |
| Customer event | | | |

## Collisions found
| Week | Collision | Resolution | Decided by |
|---|---|---|---|
| | | | |

# DACI: [The question we're deciding]?

**Status:** Not started / In progress / Decided   **Impact:** High / Medium / Low   **Door type:** One-way / Two-way
**Due date:** [Date]   **Forum:** [Ritual where it will be decided]

## People
- **Driver:** [Name] (gathers input, sets scope, gets a decision by the due date)
- **Approver:** [One name]
- **Contributors:** [Names and what expertise each brings]
- **Informed:** [Groups to tell once decided]
- **Agree (only if a function holds a veto, RAPID style):** [Function and the condition they're checking]

## Background
[One or two sentences.]

## Relevant data
[Links to the evidence, with dates. Eval results and cost data for AI decisions.]

## Decision factors
[Cost, time, scalability, customer risk, reversibility, security, margin]

## Options considered
| Option | Pros | Cons | Estimated resources and cost |
|---|---|---|---|
| A | | | |
| B | | | |
| Do nothing | | | |

## Outcome
[Decision, date, approver, one-paragraph rationale]

## Action items
| Action | Owner | Due |
|---|---|---|
| | | |

---

# Decision-rights register · [Portfolio] · [Date]

| Recurring decision type | Door type | Framework | Driver or Recommend | Approver or Decide | Contributors or Input | Agree (veto) | Informed | Forum |
|---|---|---|---|---|---|---|---|---|
| Pricing model change | One-way | DACI | | | | | | |
| Deprecation or sunset | One-way | RAPID | | | | Legal | | |
| New autonomous action in production | One-way | DACI | | | | | | |
| AI model swap for a shipped feature | Depends on eval results | DACI | | | | | | |
| Roadmap change after commit | Two-way | DACI (light) | | | | | | |
| Launch tier | Two-way | RACI | | | | | | |

# Tool stack map · [Organization] · [Date]

**Owner:** [Product ops lead]   **Approved data classes per model and connector:** [Link]

| Category | System of record | Other tools in use (overlap) | Owner | Harness access (none / read / read-write) | Agents inside the tool, and what they can write | Data it feeds | Ritual that consumes it | Renewal date | Annual cost |
|---|---|---|---|---|---|---|---|---|---|
| Work tracking and roadmapping | | | | | | | | | |
| Product analytics and experimentation | | | | | | | | | |
| Feedback and research repository | | | | | | | | | |
| Docs and knowledge | | | | | | | | | |
| AI harness and agents | | | | n/a | | | | | |
| AI quality and cost observability | | | | | | | | | |

## Access rules
1. Read-only is the default for every connector.
2. Write access is granted per use case, logged, and reviewed at renewal.
3. Customer data goes only to approved tools and models.
4. One system of record per data type. Overlaps are listed above and resolved at renewal.

## Shared skills
| Skill | Encodes template | Owner | Last updated |
|---|---|---|---|
| | | | |

## Cuts and changes at next renewal
| Tool | Action | Saving | Date |
|---|---|---|---|
| | | | |

# AI quality and cost report · [Product] · [Month]

**Prepared by:** [Product ops]   **Reviewed in:** [Ritual, date]   **Sources:** [eval harness run IDs, usage and cost report period]

## Eval scorecard
| Capability | Eval type (capability / regression) | Tasks | Pass rate | pass@k or pass^k (k = ) | Change vs last month | Grader type |
|---|---|---|---|---|---|---|
| | | | | | | |

## New failures added to the suite
| Failure | Source (incident, ticket, transcript) | Added as task ID |
|---|---|---|
| | | |

## Outcome and cost
| Use case | Successful outcomes | Cost per successful outcome (p50 / p90) | Cache hit rate | Model fit notes | Trend |
|---|---|---|---|---|---|
| | | | | | |

## Margin
Gross margin impact this month: [value and change]. Main driver: [one sentence].

## Transcripts read
[Number read, and the one pattern worth discussing.]

## Decisions requested
1.
2.

# PM onboarding kit · [Product or portfolio] · [New PM] · Start date [Date]

**Buddy:** [PM]   **Manager:** [Name]   **Product ops contact:** [Name]

## Before day one
- [ ] Access requests filed for every system on the tool stack map
- [ ] Harness set up with team skills and read-only connectors
- [ ] Added to the rituals marked below

## Read in week one
- Product 360 index and its twelve spine artifacts
- Metric glossary and North Star tree
- Last two QBR packs and the decision log for the last two quarters
- Decision-rights register
- Charter of the product ops function

## Rituals to attend
| Ritual | Attend / observe / skip for now | Starting week |
|---|---|---|
| | | |

## Customer exposure
| Week | Customer call to shadow | Persona | Notes |
|---|---|---|---|
| | | | |

## First-week harness prompts
1. "Summarize the decisions in the decision log from the last two quarters, grouped by theme, with the approver and date for each."
2. "List the open risks in the risk register and which ritual last discussed each."
3. "Explain the five metrics in the glossary I'm most likely to be asked about, with their definitions and current values."
4. "From the feedback repository, summarize the top themes for [persona] this quarter with linked quotes."

## 30 / 60 / 90
| By day | Outcome | Evidence |
|---|---|---|
| 30 | Can explain the strategy, metrics and top risks; first two-way decision logged | |
| 60 | Owns a ritual; first DACI driven | |
| 90 | Product 360 artifacts for the area refreshed; first bet through planning | |

## Feedback on this kit
Where did you get stuck in week one? [Answer goes to product ops.]

Prompts

Goal: Find which product ops pillar to fix first, from evidence rather than complaints.
Paste in: notes from PM and field-leader interviews, the last two QBR packs, and the last planning cycle's calendar and decision log. Remove names if your harness isn't approved for HR-sensitive material.

You are helping me diagnose the product operations needs of [organization]. Product ops has three pillars: business and data insights, customer and market insights, and process and governance.

1. From the interview notes, list every distinct pain, how many people raised it and which pillar it belongs to. Quote the notes.
2. From the QBR packs, list every metric that appears with more than one value or definition, with the slide references.
3. From the planning calendar and decision log, list decisions that slipped past their dates and meetings that ended with no logged decision.
4. Score each pillar red, amber or green, with the evidence for each score.
5. Recommend the one pillar to fix first and the first three actions.

Use only the material provided. If something isn't supported by it, say "no evidence."

Check the output: confirm two of the metric conflicts yourself against the slides. If the recommendation is "fix everything," push back and ask for one pillar.

Goal: Get a first-draft charter that scopes product ops as a force multiplier, not a PMO.
Paste in: the diagnosis, the team structure, the sponsoring leader's goals, and any existing product ops job description.

Draft a product operations charter for [organization] with these sections: mission (one sentence), customers of product ops, scope by pillar in a "we do / we do not" table, services with response times, owned artifacts, decision rights of product ops itself, measures with baselines to collect, and a process budget rule.

Rules:
- Product ops enables and does not decide. It never owns roadmap content, priorities, pricing or customer commitments.
- It provides self-serve data, not analysis on demand; research infrastructure, not research.
- Every service and artifact must name the decision it makes faster or better. Cut any that can't.
- Flag anything in my inputs that would turn the function into a project management office or split the PM role.

Check the output: read the "we do not" column aloud to two PMs. If either says "but we need that," decide explicitly whether it belongs to product ops or to them.

Goal: Turn existing meetings into a cadence where every ritual produces a decision.
Paste in: the list of recurring meetings with attendees and agendas, the fiscal calendar, the annual customer event date, and the metric glossary.

Design a detailed operating cadence calendar for [product or portfolio]. For each ritual give: frequency and slot, who runs it, what product ops prepares, attendees, inputs, the decision it produces, where the decision is recorded, and what the AI harness can draft beforehand.

Reuse existing meetings wherever possible. Include a weekly metrics review, a monthly product review, a monthly voice-of-the-customer readout, a monthly AI quality and cost review if we ship AI features, a quarterly business review kept separate from quarterly planning, and an annual strategy refresh aligned to the fiscal year.

Then list every existing meeting you recommend cancelling or merging, and why. Finish with the weekly hours the cadence costs a PM.

Check the output: any ritual whose "decision output" is "discussion" or "alignment" has no decision. Cut it or give it one.

Goal: Get a decision document with clear roles and the right process weight.
Paste in: the decision question, background, the evidence you have, the options, and the people involved with their roles.

Draft a DACI document for this decision: [question]. Use this structure: title phrased as the question; status, impact, door type and due date; Driver, one Approver, Contributors and Informed; one- or two-sentence background; relevant data with sources; decision factors; an options table with pros, cons and estimated resources and cost, including "do nothing"; action items.

Then:
1. Say whether this is a one-way or two-way door, and why. If it's a two-way door, recommend a lighter process.
2. Say whether any function holds a real veto (Security, Legal, regulatory). If so, add an Agree role, RAPID style, and state the condition they're checking.
3. Propose a row for our decision-rights register so this type of decision is pre-assigned next time.

Use the supplied evidence. Mark cost and risk estimates as unknown when the inputs cannot support them.

Check the output: there must be exactly one Approver. If the draft names two, or a committee, fix it before sharing.

Goal: One system of record per data type, and safe defaults for what the harness can reach.
Paste in: the list of tools in use with owners, costs and renewal dates; the connectors your harness has; and your data classification policy.

Build a tool stack map for [organization] using these categories: work tracking and roadmapping; product analytics and experimentation; feedback and research repository; docs and knowledge; AI harness and agents; AI quality and cost observability.

For each category give: the system of record, overlapping tools, owner, recommended harness access (none, read or read-write) with a reason, any agents inside the tool and what they can write, which ritual consumes the data, renewal date and cost.

Default every connector to read-only. Recommend write access only where a named use case needs it, and say how it should be logged. List overlaps to resolve at renewal with the likely saving.

Check the output: confirm against your data policy that no connector with customer data is routed to an unapproved model. Ask the tool owners to confirm the access levels before you publish the map.

Goal: A one-page view of whether the AI features are getting better, staying safe and paying for themselves.
Paste in (or connect the harness to): this month's eval results with task counts and grader types, the list of new failures, the provider usage and cost report for the period, outcome counts from product analytics, and last month's report. Use only approved tools for production transcripts.

Prepare the monthly AI quality and cost report for [product].

1. Eval scorecard by capability: capability and regression pass rates reported separately, and pass^k for any capability where the agent acts without a human. Flag any regression rate below [threshold] and any capability rate stuck at 0% (a likely broken task or grader).
2. New failures since last month, and whether each has been added to the suite.
3. Cost per successful outcome for each use case: total cost divided by runs that met the quality bar. Show the median and the 90th percentile, and the trend.
4. The top three cost drivers, including any long-tail runs, and the gross margin impact.
5. Three decisions the review should make, each with the evidence.

Show the distribution. Label improvement only when the change exceeds run-to-run noise relative to last month.

Check the output: open three transcripts behind the biggest change and confirm the story matches. Reconcile total cost with the provider's report before the meeting.

Goal: Give a new PM a week-one kit built from the team's real artifacts.
Paste in (or connect the harness to): the Product 360 index, metric glossary, decision log, risk register, cadence calendar, decision-rights register, tool stack map and the last two QBR packs.

Build an onboarding kit for a new PM joining [team] to own [area or persona]. Include: before-day-one access steps; a reading list in priority order with one line on why each matters; which rituals to attend, observe or skip for now; a customer-call shadowing plan for the first four weeks; five first-week prompts the PM can run against our documents; and a 30/60/90 plan with evidence for each milestone.

Write the kit for someone experienced in product management but new to our product, customers and jargon. Define every acronym from the glossary the first time it appears.

Check the output: give the kit to the most recent joiner and ask what was missing in their first week. Add it.

Anti-patterns

Checklist

• The organization has checked the three signals (shared calendar, unstable numbers, deck season) and chosen one pillar to fix first.
• A signed product ops charter states its customers, services, owned artifacts and what product ops does not do.
• The metric glossary gives each leadership metric one definition, one owner and one system of record.
• Customer signals from every channel land in one feedback repository with consistent tags.
• The detailed cadence calendar names, for every ritual, who runs it, what product ops preps, the decision it produces and where it’s recorded.
• The QBR and quarterly planning are separate rituals.
• The planning calendar shows quarterly milestones with owners and inputs, plus the annual overlay (fiscal year, budget, board, customer event).
• A decision-rights register pre-assigns door type, framework and roles for recurring decisions, with exactly one approver each.
• The tool stack map names one system of record per category, with read-only harness access as the default.
• Core templates are packaged as shared skills in the team’s harness.
• Teams shipping AI features hold a monthly AI quality and cost review with separate capability and regression rates, pass^k for autonomous actions and cost per successful outcome as a distribution.
• A PM onboarding kit exists and was tested on the most recent joiner.
• Product ops reports its measures against a baseline at least quarterly, and retires at least one process each review.