Artifact Library

# [Product name] · Product 360

**Owner:** [Name, title]   **Last reviewed:** [YYYY-MM-DD]   **Lifecycle stage:** [Introduce / Grow / Mature / Decline / Retire]

## Scope
[One paragraph: which products, customers, teams and revenue this 360 covers. Name what is explicitly out of scope and who owns it.]

## The 360 at a glance
| Dimension | Key question | Artifact (link) | Owner | Kind | Last reviewed | State |
|---|---|---|---|---|---|---|
| Customer | Who is this for, and what job? | [Personas and problem hypothesis] | | Durable | | Current / Stale / Missing |
| Strategy | Where we play, how we win | [Vision and strategy one-pager] | | Durable | | |
| Strategy | Who we compete with | [Competitive landscape] | | Living (Q) | | |
| Business | How it makes money | [Business model and unit economics] | | Living (Q) | | |
| Build | What's next | [Outcome roadmap] | | Living (M) | | |
| Measure | How we know it works | [North Star, metric tree, dashboard] | | Living (W) | | |
| Measure | What we committed to | [OKRs] | | Living (Q) | | |
| Go-to-market | How it reaches customers | [Positioning and messaging] | | Durable | | |
| Operate | How we run it | [Operating cadence, decision log, risk register] | | Living (W) | | |
| Lifecycle | Where it is in its life | [Lifecycle stage assessment] | | Durable | | |
| Leadership | Who must be aligned | [Stakeholder map and DACI] | | Living (Q) | | |
| AI (if applicable) | Quality, cost, models, risk | [Eval plan, AI cost model, model register, AI risk assessment] | | Living (M) | | |

## Current priorities
1. [The one to three things that matter most this quarter, each linked to its artifact]

## Open decisions
[Link to the decision log, filtered to open items]

## Active events
[Links to in-flight PRDs, launch plans, business cases, sunset plans]

## Key contacts
[Engineering lead, design lead, PMM, product ops, sales lead, support lead, finance partner]

# Artifact inventory · [Product] · [Date]

## Scope statement
[Paste the one-paragraph scope.]

## Inventory
| # | Document | Link | Dimension | Kind (durable/living/event) | Last updated | Owner | State (current/stale/contradicted) | Notes |
|---|---|---|---|---|---|---|---|---|
| 1 | | | | | | | | |

## Gaps by dimension
| Dimension | Spine artifact | Exists? | State | Business risk if missing (H/M/L) | Deadline driver | Priority |
|---|---|---|---|---|---|---|
| Customer | Problem hypothesis and personas | | | | | |
| Strategy | Vision and strategy one-pager | | | | | |
| Strategy | Competitive landscape | | | | | |
| Business | Business model and unit economics | | | | | |
| Build | Outcome roadmap | | | | | |
| Measure | North Star and metric tree | | | | | |
| Measure | OKRs | | | | | |
| Go-to-market | Positioning and messaging | | | | | |
| Operate | Cadence and decision log | | | | | |
| Lifecycle | Lifecycle stage assessment | | | | | |
| Leadership | Stakeholder map and DACI | | | | | |

## Contradictions found
[Each pair of artifacts that disagree, what they disagree on, and who needs to resolve it.]

## Build order
1. [Artifact] because [deadline or risk]

# Operating cadence · [Product] · [Quarter]

| Cadence | Ritual | Day and time | Attendees | Artifacts reviewed | Output | Owner |
|---|---|---|---|---|---|---|
| Weekly | Metrics review | | PM, eng lead, design, analyst | Dashboard, risk register | Adjustments, escalations | |
| Weekly | Team sync | | Product team | Decision log, discovery log | Decisions logged | |
| Biweekly | Sprint review and planning | | Product team | Backlog, release plan | Sprint commitment | |
| Monthly | Product review | | Leadership, PM, eng, design, PMM | Roadmap, OKRs, competitive changes, insight summary | Roadmap changes, asks | |
| Quarterly | Business review | | Leadership, finance, sales, CS | Business model, OKRs, lifecycle stage | Bets, staffing, pricing | |
| Annually | Strategy refresh | | Leadership | All durable artifacts | Strategy for the year | |
| Per event | Launch go/no-go | | Launch team | Launch plan, readiness checklist | Ship or hold | |

## Rules
- Every ritual produces a decision or is cancelled after two meetings without one.
- Decisions are written in the decision log within 24 hours.
- Each artifact shows its owner and last-reviewed date. Anything past its review date is marked stale on the 360 index.

# Product hypothesis · [Product or initiative] · v[n] · [Date]

**Owner:** [PM]   **Status:** Draft / Testing / Confirmed / Revised / Killed

## Customer hypothesis
We believe [specific segment, role and context]...

## Problem hypothesis
...experience [problem] when [situation], which costs them [measurable consequence].

## Solution hypothesis
We believe [solution concept] will solve this.
We will know we are right when [observable signal] reaches [threshold] within [timeframe].

## Growth or buying-process hypothesis
We believe customers will discover and adopt this by [channel or buying process], and that [buying-group gate, such as security or procurement] will approve it because [reason].

## Business outcome
If the hypothesis holds, the business outcome is [metric and target]. The customer outcome is [metric and target].

## Riskiest assumptions (from the assumption map)
1. [Assumption] · Type: desirability / feasibility / viability / adoptability · Test: [smallest test] · Signal: [what would falsify it]
2.
3.

## Evidence log
| Date | Source (interview, data, test) | What we learned | Effect on hypothesis |
|---|---|---|---|
| | | | |

## Decision
[Proceed / pivot / stop], decided by [name] on [date]. Reason: [one paragraph].

# Assumption map · [Product or initiative] · [Date]

| # | Assumption | Type (D/F/V/A) | Importance (H/M/L) | Evidence today (strong/some/none) | Quadrant | Test | Owner | Status |
|---|---|---|---|---|---|---|---|---|
| 1 | | | | | | | | |

Types: D = desirability (do they want it?), F = feasibility (can we build it?), V = viability (should we, financially?), A = adoptability (will the buying group, security and procurement let it through?).

## Test first (important, little evidence)
1.
2.
3.

## Review rhythm
Update after every three or four interviews or tests. Move assumptions between quadrants as evidence arrives, and note why.

# Opportunity assessment · [Opportunity] · [Date]

**Owner:** [PM]   **Decision needed by:** [Date]   **Decision maker:** [Name]

1. **Exactly what problem will this solve?** (value proposition)
2. **For whom do we solve that problem?** (target personas and segments)
3. **How big is the opportunity?** (market size and how it was estimated)
4. **What alternatives are out there?** (competitors, substitutes, build-it-yourself, do nothing)
5. **Why are we best suited to pursue this?** (our differentiator)
6. **Why now?** (market window)
7. **How will we get this product to market?** (go-to-market approach)
8. **How will we measure success and make money?** (metrics and revenue model)
9. **What factors are critical to success?** (solution requirements and riskiest assumptions)
10. **Recommendation:** go, no-go or investigate further, with the next decision point.

Adapted from Marty Cagan's ten opportunity-assessment questions.

# Persona · [Name], [Role]

**Type:** Proto (hypothesis) / Qualitative / Statistical   **Evidence:** [number of interviews, sources]   **Owner:** [PM]   **Last validated:** [Date]   **Retire by:** [Date or condition]

## Role in the deal
End user / Champion / Economic buyer / Technical evaluator / Procurement or legal / Partner

## Context
- Organization type and size:
- Team and reporting line:
- Tools they use today:
- What they're measured on:

## Job story
When [situation], I want to [motivation], so I can [expected outcome].

## Goals
1.
2.

## Pains (in their words)
- "[Quote]" (interview #, date)
- "[Quote]"

## Four forces
- Push (what's wrong today):
- Pull (the better future they imagine):
- Anxiety (what worries them about switching):
- Habit (what keeps them where they are):

## AI posture (AI products only)
Enthusiast / Pragmatist / Skeptic, with evidence:

## What they need from us to say yes
[Proof points, artifacts, controls, references]

## Buying jobs they own
Problem identification / Solution exploration / Requirements building / Supplier selection / Validation / Consensus creation

# Jobs · [Product] · [Date]

## Job stories (one per persona and situation)
| Persona | When (situation) | I want to (motivation) | So I can (outcome) | Evidence |
|---|---|---|---|---|
| | | | | |

## Job map (for one core job)
| Step | What the customer is doing | Desired outcomes (direction + metric + object + context) |
|---|---|---|
| Define | | |
| Locate | | |
| Prepare | | |
| Confirm | | |
| Execute | | |
| Monitor | | |
| Modify | | |
| Conclude | | |

## Opportunity scoring (if surveyed)
| Desired outcome | Importance (0 to 10) | Satisfaction (0 to 10) | Opportunity = I + max(I − S, 0) |
|---|---|---|---|
| | | | |

# Journey map · [Persona] · [Scenario] · [Date]

**Journey type:** Buying journey / Usage journey   **Evidence:** [sources]

## Lens
- Actor:
- Scenario:
- Expectations:

## Experience
| Phase | [Phase 1] | [Phase 2] | [Phase 3] | [Phase 4] | [Phase 5] |
|---|---|---|---|---|---|
| Actions | | | | | |
| Thoughts | | | | | |
| Emotion (−2 to +2) | | | | | |
| Touchpoints | | | | | |
| Backstage (who at our company is involved) | | | | | |
| Pain points | | | | | |

## First value
The moment the customer first gets the outcome they bought: [describe]. Median time to reach it today: [time].

## Opportunities
| Opportunity | Phase | Owner | Metric | Priority |
|---|---|---|---|---|
| | | | | |

# Discovery interview guide · [Topic] · [Date]

**Hypothesis under test:** customer / problem (not solution)   **Persona:** [persona]   **Length:** 45 minutes

## Before the call
- Learning goals (max three):
  1.
  2.
  3.
- What would change our mind:

## Opening (5 min)
- Thank them, explain we're learning, not selling. Ask permission to record.
- "Tell me about your role and what a typical week looks like."

## The story (25 min)
- "Tell me about the last time [the situation] happened."
- "What happened first? Then what?"
- "Who else was involved?"
- "What did you use to deal with it? Why that?"
- "What did it cost you: time, money, stress, reputation?"
- "What have you tried to fix it? What happened?"
- "If it happened again tomorrow, what would you do?"

## Switching (if they recently changed tools) (10 min)
- "When did you first think something had to change?"
- "What made you start looking? What did you look at?"
- "What almost stopped you?"
- "What would make you switch away?"

## Close (5 min)
- "Is there anything I should have asked?"
- "Who else should I talk to?"
- Ask for a commitment: a follow-up, an intro, a pilot.

## Rules
Ask about past specifics, not future hypotheticals. Don't pitch. Dig behind feature requests to the problem. Silence is a tool.

# Interview snapshot · [Participant] · [Date]

**Persona:** [persona]   **Interviewers:** [trio]   **Recording:** [link]

## Quick facts
[Context that matters: company, team size, tools, role]

## Memorable quote
"[Quote]"

## The story in five moments
1.
2.
3.
4.
5.

## Opportunities heard (needs, pains, desires)
-
-

## Insights (notable, not yet actionable)
-

## Evidence for or against the hypothesis
| Assumption | For / Against / Neutral | Evidence |
|---|---|---|
| | | |

## Commitment offered
[None / follow-up / intro / pilot / other]

# Product vision · [Product] · v[n] · [Date]

**Owner:** [PM]   **Agreed with:** [names]   **Horizon:** [years]   **Next review:** [date]

## Vision statement
[One or two sentences: the positive change the product brings about, and for whom. No technology, feature or company ambition.]

## Quality check (pass / fail, with a note)
| Quality | Pass? | Note |
|---|---|---|
| Inspiring: people want to work toward it | | |
| Shared: built with and agreed by the team and key stakeholders | | |
| Ethical: benefits customers and does no harm | | |
| Concise: easy to remember and repeat | | |
| Ambitious: broad enough to guide several years | | |
| Enduring: survives a change of strategy | | |
| Names no technology, feature or mechanism | | |
| Describes a change for the customer, not for us | | |

## Vision board
| Target group | Needs | Product | Business goals |
|---|---|---|---|
| Users: | Problem solved: | What it is: | Revenue: |
| Economic buyer: | Benefit delivered: | 3 to 5 standout features: | Retention or expansion: |
| Gatekeepers: | | | Margin or cost: |
| Partners: | | | Strategic: |

## Extended board (optional)
| Competitors and alternatives | Revenue sources | Cost factors | Channels |
|---|---|---|---|
| | | | |

## Positioning line (one per buying segment)
For [target customer] who [need, or dissatisfaction with the current alternative], [product] is a [category] that [key benefit]. Unlike [main alternative, including manual processes], [product] [primary differentiation].

## Ideas this vision rules out
1.
2.

# Vision narrative · [Product] · [Date of the imagined announcement]

**Owner:** [PM]   **Status:** Draft / In review / Agreed   **Reviewers:** [names]

## Press release (under one page)
**Headline:** [The customer outcome, in a customer's words]
**Subheading:** [Who the customer is and the benefit they get]
**Summary:** [What is launching and why it matters, in two or three sentences]
**The problem:** [What the customer's day looks like today, and what it costs them]
**The solution:** [What changes for the daily user]
**What the economic buyer sees:** [The business result for the person who pays]
**Quote from our leader:** [Why we built it]
**Quote from a customer:** [Illustrative; mark as imagined]
**How to get started:** [The first step for a new customer]

## External FAQ (customers, partners, press)
1. Q: A:
2. Q: A:

## Internal FAQ (leadership, engineering, finance, legal)
1. What will it cost to build and to run per unit of value?
2. What are the hardest technical problems, and how confident are we?
3. What will security, procurement and legal reviewers ask, and what are our answers?
4. What does this do to revenue, margin and pricing?
5. What must be true about customers that we have not yet proven?
6. What are we choosing not to do?

## Open questions after review
| Question | Owner | Due |
|---|---|---|
| | | |

Rule: no claim in the narrative may rest on a number we have not sourced. Mark every imagined quote and every target as such.

# Business decomposition · [Product] · [Date]

## Customer's operational value stream
| Stage | [Stage 1] | [Stage 2] | [Stage 3] | [Stage 4] | [Stage 5] | [Stage 6] |
|---|---|---|---|---|---|---|
| What the customer does | | | | | | |
| Where value leaks today | | | | | | |
| Our capability that serves it | | | | | | |
| Owning team | | | | | | |
| Metric that shows progress | | | | | | |

## Capability × segment
| Capability | [Segment A] | [Segment B] | [Segment C] |
|---|---|---|---|
| | Owner / metric | | |

## Business model components each goal moves
| Component | Current state | Goals that move it | Owner |
|---|---|---|---|
| Customer segments | | | |
| Value propositions | | | |
| Channels | | | |
| Customer relationships | | | |
| Revenue streams | | | |
| Key resources | | | |
| Key activities | | | |
| Key partnerships | | | |
| Cost structure | | | |

## Team types
| Team | Type (stream-aligned / platform / enabling / complicated-subsystem) | Stream or service | Main interaction mode |
|---|---|---|---|
| | | | |

## Gaps and overlaps
- Stages or components nobody owns:
- Stages or components two teams both claim:
- Decision and owner for each:

# North Star and metric tree · [Product] · [Date]

## Vision (one line)
[Vision statement]

## North Star
**Metric:** [name]
**Game:** Attention / Transaction / Productivity
**Definition:** what counts: [ ] · what does not count: [ ] · period: [ ] · data source: [ ]
**Could it become a price meter?** Yes / No. If yes, can a customer audit the count? [how]
**Checks:** reflects customer value [ ] · represents the current strategy [ ] · leads revenue [ ] · not a vanity or lagging financial metric [ ]
**Side measured (platforms):** [which side; how the other side appears below]

## Inputs (three to five)
| Input | Lens (breadth / depth / frequency / efficiency) | Definition | Baseline and source | Owning team | Evidence it drives the North Star |
|---|---|---|---|---|---|
| | | | | | Tested / Weak / Untested bet |

## Team drivers under each input
| Input | Driver | Team | Target this quarter |
|---|---|---|---|
| | | | |

## Guardrails
| Guardrail | Family (quality / trust / cost / health) | Threshold | Inputs it protects | Who watches it |
|---|---|---|---|---|
| | | | | |

## Health metrics (watched, not goals)
-

## Review
Last tested against history: [date]. Inputs to replace or re-test: [list].

# OKRs · [Team] · [Quarter]

**Input on the metric tree this team owns:** [input]   **Guardrails this team could break:** [list]

## Objective 1: [Qualitative, inspiring, achievable by this team]
**Type:** Committed (expected 1.0) / Aspirational (expected about 0.7)

| # | Key result (who does what by how much) | Baseline and source | Target | Confidence at start (0 to 10) | Type |
|---|---|---|---|---|---|
| KR1 | | | | | |
| KR2 | | | | | |
| KR3 | | | | | |

**Guardrail for this objective:** [metric, threshold]
**Problem the team is solving (not a feature list):** [one paragraph]

## Objective 2 (optional)
...

## Tests before submitting
- [ ] Each KR names an actor and a behavior change, not a deliverable.
- [ ] Each KR has a baseline with a named source.
- [ ] Each OKR is labeled committed or aspirational.
- [ ] No KR can be hit by breaking a guardrail.
- [ ] Deliverables and dates are in the delivery plan, not here.
- [ ] The team can move every KR without waiting on another team.

## Moved to the delivery plan
- [Output] · [date]

# AI goal set · [Feature] · [Quarter]

**Task automated or augmented:** [describe]   **Automate or augment?** [choice and reason]

| Family | Measure | Definition and test set | Baseline | Threshold or target | Role (objective / guardrail) | Action if breached |
|---|---|---|---|---|---|---|
| Value | | | | | | |
| Quality | | Held-out set: [name, size, last refreshed] | | | | |
| Quality: severe errors | | | | | | |
| Trust | Acceptance rate | | | | | |
| Trust | Override or rejection rate | | | | | |
| Trust | Wrong-action rate | | | | | |
| Cost | Inference cost per unit of value | | | | | |
| Cost | Gross margin contribution | | | | | |

## Error costs
| Error | Example | Cost to the customer | Weighting |
|---|---|---|---|
| False positive | | | |
| False negative | | | |

## Triggers
- If [measure] crosses [threshold] for [period], then [model review / rollback / pause autonomy / escalate].

## Evidence for reviewers
Where the security reviewer, auditor or regulator can find each trust measure: [location]

# Goal review · [Product] · [Month]

**Prepared by:** [PM]   **Data pulled from:** [sources and date]   **Attendees:** [names]

## North Star
| Metric | Last month | This month | Trend (3 months) | Comment |
|---|---|---|---|---|
| | | | | |

## Inputs
| Input | Owner | This month | Trend | Moved with the North Star? |
|---|---|---|---|---|
| | | | | Yes / No / Unclear |

## Guardrails
| Guardrail | Threshold | This month | Status (OK / Watch / Breached) | Action |
|---|---|---|---|---|
| | | | | |

## OKR confidence
| Team | KR | Confidence last month | Confidence now | Why it changed |
|---|---|---|---|---|
| | | | | |

## Broken links
Inputs that moved without moving the North Star, and our explanation:

## Decisions
| Decision | Owner | By when |
|---|---|---|
| | | |

## End of cycle only: committed OKRs missed
| OKR | Score | Peer review date | What we learned |
|---|---|---|---|
| | | | |

Rule: change plans freely; change OKRs only at the end of the period.

# Strategy kernel · [Product] · v[n] · [Date]

**Owner:** [PM]   **Approver:** [Name]   **Review date:** [Date]

## Diagnosis
The critical challenge is [challenge] because [cause].
Evidence: [win/loss, churn, usage, competitive or economic data, with sources]

## Guiding policy
We will [overall approach].
Therefore we will not:
1. [Refusal]
2. [Refusal]
3. [Refusal]

## Coherent actions (3 to 5)
| # | Action | Owner | Resource commitment | How it reinforces the others |
|---|---|---|---|---|
| 1 | | | | |

## Proximate objective
By [date] we will have [measurable, achievable result].

## Bad-strategy check
- [ ] No fluff: every sentence commits to something.
- [ ] The challenge is named and faced.
- [ ] Goals are not standing in for strategy.
- [ ] Not a laundry list; actions are coherent.
- [ ] A stranger could predict three requests we'll refuse.

# Product strategy · [Product] · Horizon: [12 to 24 months]

**Owner:** [PM]   **Last reviewed:** [Date]   **Nests inside:** [business unit or portfolio strategy]

1. **Diagnosis:** the one critical challenge, with evidence.
2. **Winning aspiration:** what winning looks like for customers and for us.
3. **Where we play / where we don't:** segments, buyers, channels, ecosystem position.
4. **How we win (DHM):**
   - Delight (per persona): [end user] / [champion] / [economic buyer] / [gatekeeper]
   - Hard to copy:
   - Margin-enhancing:
5. **Guiding policy:** the approach, plus the three things we'll say no to.
6. **Coherent actions as SMTs:**

| Strategy (hypothesis) | Proxy metric (current → target) | Tactics (projects, experiments) | D / H / M |
|---|---|---|---|
| | | | |

7. **Capabilities and systems we must build:**
8. **What would have to be true:**

| Condition | Confidence (H/M/L) | Test | Owner | Due |
|---|---|---|---|---|
| | | | | |

9. **Outcome metrics:** North Star [metric]; inputs [2 to 3]; guardrails [margin, trust, quality].

**Changes since last review:** [what changed and the evidence that changed it]

# Prioritization scorecard · [Product] · [Period]

**Lens chosen:** [WSJF / RICE with reach in accounts / MoSCoW / Kano / other]
**Why this lens:** [how the guiding policy makes this lens the right one]
**Reach unit:** [accounts / ARR touched / users]

## Strategy filter (before scoring)
Only items linked to a coherent action are scored. Items removed at the filter:
| Item | Reason removed | Status told to requester |
|---|---|---|
| | | |

## Scored items
| Item (opportunity or bet) | Strategy link | Accounts / ARR affected | Customer value (1 to 3) | Cost of delay per month | Risk reduction / enablement | Effort (team-weeks) | Evidence level | Score | Decision (commit / bet / explore / no) |
|---|---|---|---|---|---|---|---|---|---|
| | | | | | | | | | |

Evidence levels (Confidence Meter): opinion · anecdote or market data · customer evidence · MVP or launch data.

## Departures from score order
| Item | Moved from → to | Reason | Decided by |
|---|---|---|---|
| | | | |

# Roadmap · [Product] · v[n] · [Date]

**Strategy:** [link to one-pager]   **Owner:** [PM]   **Next review:** [Date]

| | Now (in delivery) | Next (discovery under way) | Later (problems to solve) |
|---|---|---|---|
| Theme / outcome | | | |
| Target metric | | | |
| Type | Commitment / Bet / Exploration | | |
| Confidence (H/M/L) | | | |
| Date (commitments only) | | Not dated | Not dated |

## Commitments register
| Commitment | Who depends on it | Date | Discovery done? | Engineering estimate | Owner |
|---|---|---|---|---|---|
| | | | | | |

## Capability watchlist (AI products)
| Later item | Capability threshold to move to Next | Eval used | Last model tested | Result |
|---|---|---|---|---|
| | | | | |

## Capacity split
New value [x]% · Platform and enablers [x]% · Quality, evals and model migration [x]% · Commitments [x]%

## Changelog
| Date | What moved | From → to | Why |
|---|---|---|---|
| | | | |

# Roadmap communication pack · [Product] · [Date]

**Source roadmap:** [link]   **Disclaimer approved by:** [legal contact, date]

## 1. Executive view (one page)
- Outcomes we're driving and current metric values:
- Strategic bets and what would make us stop:
- Investment mix (capacity split):
- Top risks:
- Decisions needed from you:

## 2. Field view (sales, solutions, customer success)
- Talk track (three sentences):
- Commitments you can quote, with dates:
- Themes for Next and Later (no dates):
- Won't list (do not promise):
- How to log a customer request, and what status they'll get back:
- Forward-looking disclaimer:

## 3. Customer view
- Problems we're solving for you and our direction:
- Commitments (contractual only):
- Design-partner invitations:
- NDA required: yes / no

## 4. Partner and developer view
- API changes and versions:
- Deprecations, with notice periods:
- Platform contracts and dependencies:

## 5. Changelog since last version
| What moved | Why | Who was told |
|---|---|---|
| | | |

# Backlog policy · [Product or team] · [Date]

**Accountable:** [PM]   **Reviewed:** quarterly

## Three stores
1. **Request inbox:** every raw ask, linked to account and ARR. Never ordered, never promised. Searchable by the field.
2. **Opportunity backlog:** requests clustered into customer problems, sized by accounts and ARR, linked to a coherent action.
3. **Delivery backlog:** ordered and refined; covers the next [one to two] cycles of Now only. Maximum size: [n] items.

## Entry criteria for the delivery backlog
- [ ] Linked opportunity and outcome
- [ ] Evidence level stated
- [ ] Owner named
- [ ] Rough size
- [ ] Acceptance criteria
- [ ] AI features: eval or quality bar defined

## Ageing rule
Items untouched for [two quarters] are archived with a reason. The requester's status updates automatically.

## Capacity split
| Category | Share | Notes |
|---|---|---|
| New value | | |
| Platform and enablers | | |
| Quality, debt, evals and model migration | | |
| Customer commitments | | |

## Cadence
- Weekly: refine the top of the delivery backlog.
- Monthly: opportunity review; cluster new requests.
- Quarterly: strategy and roadmap check; reset capacity split.
- Any reorder of a commitment is communicated within [n] business days.

## Request statuses a seller can quote
Logged · Mapped to theme [x] · In discovery · Planned (Now) · Not planned this half · Won't do (with reason)

# Prototype test plan · [Initiative] · Round [n] · [Date]

**Owner:** [PM]   **Trio:** [PM, designer, engineer, applied AI engineer if AI]   **Decision owner:** [Name]   **Readout date:** [Date]

## Decision this test informs
[The specific decision, e.g. "Proceed to PRD with design A, iterate, or stop."]

## Risk question
We are testing whether [persona] will [observable behavior] when [situation], using [prototype].
Risk type: Value / Usability / Feasibility / Viability (adoptability)
Assumption(s) from the assumption map: [#, #]

## Prototype
- Type: Feasibility / Low-fidelity user / High-fidelity user / Live-data / Hybrid / Wizard of Oz / Concierge
- Fidelity: Interactivity [L/M/H] · Visuals [L/M/H] · Content [L/M/H]
- Built by: [Name, tool category]
- Throwaway or reusable: [ ]
- Deliberately ignores: [permissions, scale, audit, multi-tenancy, ...]
- Data: synthetic (reviewed by [domain expert]) / real (engineering-owned, with [controls])
- Piloted with: [Colleague] on [Date]

## Participants
| Role (persona) | Count this round | Screener criteria | Recruiting source |
|---|---|---|---|
| | | | |

## Tasks (three to five, no interface labels)
1.
2.
3.

## Signals (agreed before testing)
- Proceed if:
- Iterate if:
- Kill or pivot if:

## Logistics
Format: moderated remote / in person / unmoderated   Session length: [min]   Recording consent: [method]
Observers: [names]   Debrief: same day, [time]
Wizard of Oz or deception used: Yes / No   If yes, debrief script: [link]
Customer data handling: [approved tools only; what's recorded and where it's stored]

# Usability test script · [Prototype] · [Persona] · [Date]

**Facilitator:** [Name]   **Note-taker:** [Name]   **Length:** [45 to 60] minutes

## 1. Welcome and consent (5 min)
- Thank them. Explain the session: "We're testing a design, not you. You can't do anything wrong here."
- "Some of what you see won't work yet. That's expected."
- Ask permission to record. Name who is observing.

## 2. Thinking aloud (3 min)
- "As you work, please say what you're thinking: what you're looking at, what you expect, what surprises you."
- Warm-up: ask them to think aloud while doing a simple task on a familiar site or tool.

## 3. Background (5 min)
- "Tell me about your role and how [the situation] usually comes up for you."
- "Tell me about the last time it happened. What did you do?"

## 4. Tasks (25 to 35 min)
Read one task at a time. Hand it over in writing as well.

| # | Scenario (realistic, actionable, no clues) | What we're watching for | Post-task question |
|---|---|---|---|
| 1 | | | "How confident are you in what you just decided, from 1 to 7? Why?" |
| 2 | | | |
| 3 | | | |

Facilitator rules: stay quiet. Prompt only on silence ("What are you thinking now?"). Don't answer questions about the interface; turn them back ("What would you expect?"). Note every intervention.

## 5. Wrap-up (5 min)
- "What was most confusing? What was most useful?"
- "If you could change one thing, what would it be?"
- If Wizard of Oz was used: explain that a person produced some responses, why, and offer to answer questions.
- Thank them and confirm any incentive.

## Note-taking grid
| Time | Task | What they did | What they said (verbatim) | Intervention? |
|---|---|---|---|---|
| | | | | |

# Test readout · [Initiative] · Round [n] · [Date]

**Decision requested:** [proceed / iterate and retest / pivot / stop]   **Decision owner:** [Name]   **Recordings:** [link, access-controlled]

## Summary (three sentences)
What we tested, with whom, and what we recommend.

## Against the pre-registered signals
| Signal | Threshold | Result | Met? |
|---|---|---|---|
| Proceed | | | |
| Kill | | | |

## Findings, ranked by severity
Severity: 0 not a problem · 1 cosmetic · 2 minor · 3 major · 4 catastrophe (must fix before release)

| # | Severity | Finding | Count (n of N, by role) | Evidence (clip or quote, timestamp) | Decision (fix / retest / accept / kill) |
|---|---|---|---|---|---|
| 1 | | | | | |

## What we'll change before the next round
Smallest change that fixes each severity 3 and 4 finding:
1.
2.

## What worked (keep)
-

## What we still don't know
-

## Effect on the hypothesis and PRD
Assumptions confirmed, revised or killed: [#, #]   PRD sections to update: [ ]

## Verification
Every count and quote checked against recordings by [Name] on [Date].

# Team staffing plan · [Initiative] · [Date]

**Owner:** [PM]   **Approver:** [Leader]   **Review date:** [Date]

## Outcome and appetite
- Outcome the team owns: [metric and target]
- Appetite: [weeks or quarters] for [scope boundary]

## Team type
Stream-aligned / Platform / Enabling / Complicated subsystem. Why:

## Roles
| Role | Named person | Allocation (%) | Responsibilities | Backfill or gap |
|---|---|---|---|---|
| Product manager | | | | |
| Product designer | | | | |
| Tech lead | | | | |
| Engineers | | | | |
| Applied AI engineer (AI features) | | | | |
| Forward-deployed engineer (if used) | | | | |
| Product marketing | | | | |
| Other (data, security, docs) | | | | |

## Interaction modes with neighboring teams
| Team | Mode now (collaboration / X-as-a-Service / facilitating) | Until | Target mode | Interface or agreement |
|---|---|---|---|---|
| | | | | |

## Capacity
| | Engineer-weeks per quarter |
|---|---|
| Gross (people × weeks × allocation) | |
| Less on-call | |
| Less maintenance and support | |
| Less migrations and other keep-the-lights-on work | |
| **Net capacity for this initiative** | |

Net capacity versus appetite: [fits / doesn't fit, by how much]

## Binding constraint
[The one role or team that limits throughput, and the decision needed: add, borrow, sequence or cut.]

## Dependencies and risks
-

## Asks
-

# PRD · [Feature or product] · v[n] · [Date]

**Owner:** [PM]   **Status:** Draft / In review / Approved / In delivery / Shipped   **Reviewers:** [engineering, design, security, legal, partner, PMM]
**Links:** Hypothesis · PR/FAQ · Prototype (behavior spec) · Test readouts · Staffing plan · AI addendum (Chapter 31)

## 1. Problem and evidence
What's wrong, for whom, how often, what it costs. Cite interviews, test readouts and data.

## 2. Customers and personas
| Persona | Role in the deal | What they need from this release |
|---|---|---|
| | | |

## 3. Goals and success metrics
| Metric | Baseline | Target | Measured how | By when |
|---|---|---|---|---|
| | | | | |

## 4. Non-goals
What this version deliberately doesn't do, and why.

## 5. Scope and user journeys
Journey 1: [persona] [situation] → [steps] → [outcome]. Prototype link: [ ]
Journey 2:

## 6. Requirements and acceptance criteria
| # | Requirement (the what) | Journey | Acceptance criteria (testable by a person or an agent) | Priority |
|---|---|---|---|---|
| | | | | |

## 7. Non-functional requirements
- Security and permissions:
- Audit and logging:
- Performance and reliability:
- Data residency and privacy:
- Accessibility and localization:
- Integrations and APIs (contracts, versioning):

## 8. Dependencies and staffing
Teams, interaction modes and capacity, from the staffing plan.

## 9. Risks and open questions
| Risk or question | Impact | Owner | How we'll resolve it | By when |
|---|---|---|---|---|
| | | | | |

## 10. Rollout, pricing and packaging
Rollout stages, eligibility, migration, enablement, pricing and packaging impact.

## 11. AI features only
Attach the AI PRD addendum (Chapter 31): evals and pass-rate targets, failure taxonomy, latency and cost per task, trust and failure UX, staged autonomy and kill switch, margin floor, regulatory classification.

## 12. Decision log
| Date | Decision | Options considered | Decided by | Rationale |
|---|---|---|---|---|
| | | | | |

# One-page PRD · [Bet] · [Date]

**Owner:** [PM]   **Decision needed:** [what, from whom, by when]

**Problem.** [Two or three sentences, with the strongest piece of evidence.]

**Who.** [Primary persona, and the buying-group member who could block it.]

**Why now.** [What changed: customer demand, technology, competition, strategy.]

**Appetite.** [Time the business is willing to spend, and the team that would spend it.]

**Solution sketch.** [Core elements in a few bullets. Prototype link: ]

**Success metric.** [One metric, baseline, target, timeframe.]

**Non-goals and no-gos.**
-
-

**Rabbit holes.** [Known pitfalls and how we'll avoid them.]

**Top risks.** [Value / usability / feasibility / viability, one line each.]

**Open questions.**
-

**Next step.** [Test, build or stop, and when this page becomes a full PRD.]

# Tracking plan · [Product or feature] · v[n] · [Date]

**Owner:** [PM]   **Engineering owner:** [Name]   **Data reviewer:** [Name]   **Status:** Draft / Implemented / Validated

## Questions this plan must answer
1. [Question] → Metric: [metric name]
2.
3.

## Conventions
- Event names: Object + past-tense Action, Proper Case (for example, "Report Exported").
- Property names: snake_case.
- Variable detail goes in properties, never in event names.
- Every event carries: account_id, user_id, actor_type (human / agent / automation), [workspace_id or partner_id if relevant].
- Trust- or revenue-critical events fire server-side.

## Events
| Event name | Fires when (exact moment) | Question it answers | Metric(s) it feeds | Event properties (name: type) | Source (server/client) | Owner | Status | Privacy note |
|---|---|---|---|---|---|---|---|---|
| | | | | | | | Proposed / Implemented / Validated | |

## User and account properties
| Property | Level (user/account/workspace/partner) | Type | Allowed values | Source |
|---|---|---|---|---|
| | | | | |

## AI events (AI features only)
Each AI output event also carries: model_version, prompt_or_agent_version, sources_retrieved, tool_calls, latency_ms, cost, and the human decision (accepted / edited / rejected / reverted).

## Privacy and security
- Customer content (logs, tickets, prompts, documents) is never sent as a property unless approved by [reviewer] on [date].
- Personal data in properties: [none / list with approval].

## Validation
- [ ] Every critical path run in test and checked against this plan
- [ ] Every event has account_id
- [ ] No duplicate or near-duplicate events against the existing taxonomy
- [ ] Changes logged below

## Change log
| Date | Change | Reason | By |
|---|---|---|---|

# HEART grid · [Product or feature] · [Date]

**Owner:** [PM]   **Unit of analysis:** user / account / unit of work ([which])

| Category | Goal (what we want for the user) | Signal (behavior or attitude that shows success or failure) | Metric (normalized, with window) | Source (logs / survey) | Logged today? | Target | Owner |
|---|---|---|---|---|---|---|---|
| Happiness | | | | | | | |
| Engagement | | | | | | | |
| Adoption | | | | | | | |
| Retention | | | | | | | |
| Task success | | | | | | | |

## Rows left blank on purpose
| Category | Why we are not measuring it |
|---|---|
| | |

## Failure signals
List the signals that would show the feature failing (abandonment, undo, rejection, reversion, escalation):
-
-

## Notes
- Engagement is reported per user or per account, never as a total.
- Plan to read Happiness over several weeks after a change, to see past change aversion.

# Metrics dashboard spec · [Product] · v[n] · [Date]

**Purpose:** [the decision or review this dashboard serves]   **Audience:** [who looks at it, how often]   **Owner:** [PM]   **Data freshness:** [daily / hourly]

## Layout
1. North Star: [metric] (Chapter 02)
2. Input metrics (3 to 5)
3. Guardrails
4. Lagging indicators

## Metric definitions
| Metric | Tier (North Star / input / guardrail / lagging) | Numerator | Denominator | Window | Unit (user / account / work item) | Segments available | Target or threshold | Action this metric triggers |
|---|---|---|---|---|---|---|---|---|
| | | | | | | | | |

## Guardrails
| Guardrail | Threshold | Who is alerted | What happens on breach |
|---|---|---|---|
| | | | |

## Standard segments
[Persona or role, plan tier, region, account size, partner, cohort month, model_version]

## Charts we decided not to include
| Chart | Why it was cut |
|---|---|
| | |

## Review rhythm
Reviewed in [weekly team review / monthly metric review]. Definitions changed only through [owner], with a dated note.

# Experiment design · [Name] · [Date]

**Owner:** [PM]   **Analyst:** [Name]   **Decision maker:** [Name]   **Status:** Draft / Approved / Running / Read out

## 1. Decision this informs
[What we will do differently depending on the result.]

## 2. Hypothesis
We believe [change] for [segment] will [move OEC by at least X] because [reason]. We will know when [metric and threshold].

## 3. Unit of randomization
User / account / tenant / other: [choice]. Why: [interference risk, how the experience is shared].

## 4. Metrics
- OEC: [one metric or weighted combination, with definition]
- Secondary metrics: [list]
- Guardrails: [metric: must not degrade by more than X]

## 5. Power and duration
- Baseline and variance of the OEC: [values and source]
- Minimum detectable effect: [value]
- Sample size per arm: [n]
- Duration: [whole weeks]
- Variance reduction: [pre-period adjustment used? yes / no]
- Stopping rule: fixed duration / sequential method [name]. No early stopping on the OEC.

## 6. Population and ramp
Included: [who]. Excluded: [who and why]. Ramp: [percent by date].

## 7. Validity checks
- [ ] Sample ratio check before readout
- [ ] Pre-period or A/A comparison of arms
- [ ] Novelty or primacy watch: read results by week
- [ ] Data quality: event volumes by arm

## 8. Decision rule (written before launch)
| Result | Decision |
|---|---|
| OEC up, guardrails pass | |
| OEC up, a guardrail fails | |
| No detectable change | |
| OEC down | |

## 9. Risks and communication
Privacy review: [status]. Customer notice required by contract? [yes / no]. Safety: [any action that must not be randomized].

## If we cannot run a controlled experiment
Method chosen: [staged rollout with holdout / matched comparison / time series / offline replay / design partners]. Assumption we are making: [state it]. What else could explain a change: [list].

# Experiment readout · [Name] · [Date]

**Decision:** [Ship / iterate / kill], recommended by [PM], decided by [Name] on [date].

## Validity
- Sample ratio: configured [x/y], observed [x/y], check [pass / fail]
- Duration served: [dates, whole weeks]
- Data quality issues: [none / list]
- Deviations from the design doc: [none / list]

If any validity check failed, stop here: the result is not interpretable. State the cause and the rerun plan.

## Primary result
OEC: control [value], treatment [value], difference [value] with [95%] interval [low to high].

## Guardrails
| Guardrail | Threshold | Result | Pass / fail |
|---|---|---|---|
| | | | |

## Secondary metrics
| Metric | Difference | Interval | Notes |
|---|---|---|---|

## Segments
| Segment | Pre-registered or exploratory | Result |
|---|---|---|

## What we learned
[What moved, and the qualitative evidence for why. Include what surprised us.]

## Next step
[Action, owner, date]

# Post-launch review · [Feature or product] · [Review point: 30 / 60 / 90 days] · [Date]

**Owner:** [PM]   **Attendees:** [trio, data, stakeholders]

## The hypothesis as written before launch
[Paste it verbatim, with its date.]

## Success criteria set before launch
| Criterion | Target | Date set |
|---|---|---|

## What happened
| Area | Metric | Result | Against target |
|---|---|---|---|
| Activation | | | |
| Task success or quality | | | |
| Retention | | | |
| Guardrails | | | |
| Revenue or business signal | | | |

## What customers said
[Themes from conversations, tickets and, for AI features, trace review. Link the evidence.]

## Verdict by assumption
| Assumption | Validated / invalidated / unclear | Evidence |
|---|---|---|

## Decisions
1.
2.

## What we would instrument differently
[Events or properties we missed, definitions that caused confusion.]

# Iteration plan · [Product or feature] · [Period] · [Date]

**Owner:** [PM]   **Linked review:** [post-launch review or readout]

## Open assumptions and next tests
| Assumption | Current status | Next test or measurement | Evidence that would change the plan | Dashboard metric | Owner | Due | Stop condition |
|---|---|---|---|---|---|---|---|
| | | | | | | | |

## Pivot-or-persevere checkpoint
- Baseline: [metric and value, date]
- Tuning work: [what we will change]
- Decision date: [date]
- Persevere if: [result]
- Pivot or stop if: [result]

## Not doing this iteration
[Items considered and deliberately deferred, with the reason.]

# Story · [Verb phrase title] · [Tracker ID]

**Epic:** [Epic or outcome]   **Persona:** [Persona]   **Owner:** [PM]   **Status:** Draft / Ready / In progress / Done

## Story
As a [role in context], I want [capability], so that [outcome].

## Context and evidence
- Customer evidence: [quotes, ticket IDs, interview snapshots]
- Metric this should move: [metric and expected direction]
- Why now: [link to Sprint Goal or quarterly outcome]

## Acceptance criteria (Given-When-Then, three to five steps each)
Scenario: [Happy path]
  Given [known state]
  When [event]
  Then [observable outcome]

Scenario: [Permission boundary: role without rights]
  Given [user lacks role or scope]
  When [event]
  Then [what they see instead]

Scenario: [Error or missing input]
  Given [failure state]
  When [event]
  Then [safe, observable outcome]

Scenario: [Tenancy: data from another tenant or customer]
  Given [...]
  When [...]
  Then [...]

## Rules in EARS form (optional, for agent specs)
- When [trigger], the [system] shall [response].
- If [unwanted condition], then the [system] shall [response].

## Non-functional
Latency: [ ]   Audit log entry: [ ]   Data residency: [ ]   Accessibility: [ ]   API versioning: [ ]

## AI behavior (AI features only)
Eval set: [name]   Pass threshold: [ ]   Cost per task ceiling: [ ]   Risk class: [ ]

## Out of scope
- [Explicit exclusions]

## Telemetry
Event that proves use: [ ]   Event that proves value: [ ]

## Open questions
| Question | Owner | Due |
|---|---|---|
| | | |

## INVEST check
Independent [ ]  Negotiable [ ]  Valuable [ ]  Estimable [ ]  Small [ ]  Testable [ ]

# Story map · [Outcome or capability] · [Date]

**Outcome:** [What changes for the customer when this is done]   **Personas on this map:** [User, approver, admin, buyer]

## Backbone (activities, left to right in narrative order; not ranked)
| [Activity 1] | [Activity 2] | [Activity 3] | [Activity 4] | [Activity 5] |
|---|---|---|---|---|

## User tasks (under each activity)
| [Task] | [Task] | [Task] | [Task] | [Task] |
|---|---|---|---|---|
| [Persona] | [Persona] | [Persona] | [Persona] | [Persona] |

## Release 1: walking skeleton (thinnest end-to-end slice)
| [Story] | [Story] | [Story] | [Story] | [Story] |
|---|---|---|---|---|

Release goal: [ ]   Target window: [range]   Exit criteria: [ ]

## Release 2
| [Story] | [Story] | [Story] | [Story] | [Story] |
|---|---|---|---|---|

Release goal: [ ]

## Later
| [Story] | [Story] | [Story] | [Story] | [Story] |
|---|---|---|---|---|

## Hand-offs between personas (where enterprise gaps hide)
| From | To | What passes between them | Covered by story |
|---|---|---|---|
| | | | |

## Gaps found while mapping
- [ ]

# Definition of Ready and Done · [Team] · v[n] · [Date]

**Agreed by:** [PM, engineering lead, designer, QA]   **Review after:** any escaped defect, or quarterly

## Definition of Ready (keep it short; drop any line that never catches anything)
- [ ] Problem and customer evidence linked
- [ ] Acceptance criteria written as Given-When-Then, including error cases
- [ ] Permission, role and tenancy cases listed
- [ ] Dependencies named, each with an owner
- [ ] Design attached, or marked "no UI"
- [ ] Telemetry events defined
- [ ] Fits in one sprint (passes INVEST "Small")
- [ ] Security, privacy or compliance review need flagged
- [ ] AI features: risk class assigned and eval cases added

## Definition of Done
- [ ] Code reviewed by a person, including every agent-written change
- [ ] Automated tests pass, including the acceptance scenarios
- [ ] Behind a flag if not released to all customers; flag has a removal task and expiry date
- [ ] Docs and release notes drafted
- [ ] Telemetry live and checked in production
- [ ] Security checks pass
- [ ] Deployed to production (dark if needed)
- [ ] No new P0 or P1 bugs open against it
- [ ] AI features: evals pass at threshold; cost per task within budget; compliance documentation updated
- [ ] Actions that change customer systems: audit entry verified; kill switch tested

# Bug triage policy · [Product] · v[n] · [Date]

**Owner:** [PM]   **Engineering owner:** [Lead]   **Applies to:** [Products, services]

## Severity (technical impact; set by engineering or QA)
| Level | Definition | Example from this product |
|---|---|---|
| S1 | Outage, data loss, security exposure or unsafe action; no workaround | |
| S2 | Major function broken; painful workaround | |
| S3 | Minor function broken; reasonable workaround | |
| S4 | Cosmetic or polish | |

## Priority (business urgency; set by the PM)
Priority = severity, adjusted for customers affected, contractual exposure, workaround and strategic accounts.
| Priority | Meaning | Internal fix SLA | Contractual SLA it protects |
|---|---|---|---|
| P0 | Drop everything | [hours] | [ ] |
| P1 | Next in line, this sprint | [days] | [ ] |
| P2 | Default; planned | [weeks] | |
| P3 | When able | None | |
| P4 | Polish; eventually | None | |

Rule: every internal SLA is shorter than the contractual SLA it supports.

## Triage cadence
When: [day, time, frequency]   Attendees: PM, engineering lead, QA, support lead   Prep: harness drafts agenda from tracker and support connectors

## Bug bar by release phase
| Phase | Meets the bar |
|---|---|
| Early build | All S1 to S3; S4 if cheap |
| Stabilization | S1, S2; any customer-reported bug |
| Release candidate | S1; data loss; security; [product-specific always-fix conditions] |

Always meets the bar: [for example, any defect that can cause an unapproved or wrongly targeted action]

## Escalations from named accounts
Path: [support → account team → PM → engineering lead]   Who can override priority: [role]

## Regressions
Definition: [a defect in behavior that previously passed]   Treatment: [one priority level higher by default]

## Reporting (monthly)
Open P0 and P1 count and age; escaped defects; reopen rate; SLA misses; top root-cause clusters

# Release plan · [Release name] · [Date]

**Outcome:** [What changes for customers]   **PM:** [ ]   **Engineering lead:** [ ]   **Date range:** [earliest to latest] at [confidence]

## Scope
In: [ ]   Out: [ ]   Scope lever if the date is at risk: [ ]

## Flags
| Flag | Type (release / experiment / ops / permissioning) | Owner | Removal task | Expiry |
|---|---|---|---|---|
| | | | | |

## Rollout stages
| Stage | Who sees it | Entry criteria | Exit criteria | Earliest date |
|---|---|---|---|---|
| Internal | [ ] | | | |
| Design partners | [ ] | | | |
| Opt-in beta | [ ] | | | |
| Cohort or percentage | [ ] | | | |
| General availability | [ ] | | | |
| Regions held back | [ ] and why | | | |

## Exit criteria metrics
Error rate: [ ]   Latency: [ ]   Acceptance or adoption metric: [ ]   Support tickets: [ ]   Change fail rate: [ ]

## Kill switch and rollback
Kill-switch owner: [name, role]   Rollback plan: [ ]   Rehearsed on: [date]

## Customer communications
Release notes: [ ]   Admin notices: [ ]   Deprecation notices: [ ]   Status page: [ ]

## Enablement
Support: [ ]   Sales: [ ]   Partners: [ ]   Customer success: [ ]

## Compliance artifacts
[Security documentation, AI documentation, data processing terms, as applicable]

## Decision log
| Date | Decision | Made by | Reason |
|---|---|---|---|
| | | | |

# Technical debt register · [Product] · [Date]

**Owner:** [PM and engineering lead]   **Review:** quarterly, and before each roadmap cycle

| ID | Area or service | Description | Quadrant (deliberate or inadvertent; prudent or reckless) | Interest being paid (evidence) | Change frequency of the area | Principal (effort range) | Risk if left (security, compliance, scale) | Proposed fix and first slice | Owner | Decision (pay now / schedule / accept / retire) | Review date |
|---|---|---|---|---|---|---|---|---|---|---|---|
| TD-1 | | | | | | | | | | | |

## Ranking rule
Rank by interest paid times change frequency. Pay down where the code changes most. Leave stable, rarely touched code alone.

## Evidence of interest (use the business's terms)
- Slower lead time on roadmap items: [ ]
- Incidents traced to this area: [ ]
- Escalations or SLA misses: [ ]
- Roadmap items blocked: [ ]
- Onboarding drag for new engineers: [ ]

## Capacity reserved for debt this quarter
[Share or person-days, set from history], agreed by [ ]

# Sprint plan · [Team] · Sprint [n] · [Dates]

## Sprint Goal (an outcome, not a ticket list)
[One sentence]   Links to quarterly outcome: [ ]   Product Goal: [ ]

## Capacity
| Person | Days available | Less leave | Less on-call or support duty | Net days |
|---|---|---|---|---|
| | | | | |

Total net capacity: [ ]
Reserve for unplanned work (bugs, escalations): [set from the last few sprints]
Reserve for debt: [from the register]
Reserve for review of agent-written changes: [ ]
Capacity for planned stories: [ ]

## Selected items
| Item | Persona | Ready? | Size or count | Notes |
|---|---|---|---|---|
| | | | | |

## Forecast (if asked for dates)
Throughput over recent sprints: [ ]   Date range: [ ] at [confidence]   Scope lever: [ ]

## Risks and dependencies
| Risk or dependency | Owner | Mitigation |
|---|---|---|
| | | |

# Technical design review · [Design doc title] · [Date]

**Reviewer:** [PM]   **Doc owner:** [Tech lead]   **Linked PRD:** [link]   **Decision needed by:** [Date]

## 1. Problem and outcome
- [ ] The doc's context and goals match the PRD's problem and outcome metric.
- [ ] Notes:

## 2. Non-goals
- [ ] Every non-goal is acceptable to customers, sales, support and partners.
- [ ] Non-goals that need to be communicated externally: [list]

## 3. Who calls this
- [ ] Callers are named: human users / developers / internal teams / AI agents / partners.
- [ ] For each caller, what changes for them: [notes]

## 4. Alternatives considered
- [ ] At least one cheaper, simpler or more reversible option was weighed.
- [ ] The reason for rejecting each alternative is stated.

## 5. Data
- [ ] What is stored, where (region), for how long, under which tenant: [answer]
- [ ] Residency and retention match customer commitments.

## 6. Reliability
- [ ] Proposed SLIs and SLOs: [list]
- [ ] Error budget and what happens when it's spent.
- [ ] Failure behavior: what each user sees when a dependency is down.

## 7. Compatibility
- [ ] Observable behaviors that change for existing callers (ordering, timing, defaults, error text): [list]
- [ ] Versioning and migration plan for breaking changes.

## 8. Security and privacy
- [ ] Least-privilege access and scopes.
- [ ] Audit logging, including actions taken by agents and who approved them.
- [ ] Revocation path (kill switch, token revocation).

## 9. Cost
- [ ] Unit cost per request and per customer outcome, at expected and peak usage: [numbers]
- [ ] Margin impact: [estimate]

## 10. Observability and rollback
- [ ] How we'll know it works in production: [signals]
- [ ] How we undo it, including undoing a failed rollback.

## 11. Reversibility
- [ ] Decisions that are hard to reverse (public interface, data model, pricing unit) are flagged: [list]

## 12. Decisions to record
| Decision | ADR number | Status |
|---|---|---|
| | | |

## The regret question
What would make us regret this design in a year? [answer]

## Outcome
Approve / Approve with changes / Revise and re-review. Changes requested: [list]

# API and platform product brief · [Interface or service name] · v[n] · [Date]

**Owner:** [PM]   **Tech lead:** [name]   **Status:** Draft / In review / Published

## Customers
| Customer type | Who specifically | Their job to be done | Volume expected |
|---|---|---|---|
| External developers | | | |
| Partners | | | |
| Internal teams | | | |
| AI agents (via API or MCP server) | | | |

## The interface promise
- Resources and operations offered: [list]
- Events or webhooks emitted: [list]
- What we promise never to change without a new version: [list]
- Observable behaviors we know callers depend on (Hyrum's Law check): [list]

## Versioning and deprecation
- Versioning scheme: [date-based / numbered / other]
- What counts as a breaking change: [definition]
- Deprecation notice period and migration support: [policy]

## Reliability
- SLIs and SLO targets: [list]
- SLA, if any, and its consequences: [terms]
- Error budget policy: [what happens when it's spent]

## Limits and access
- Rate limits and quotas, by customer tier: [table]
- Authentication method and scopes: [list]
- Least-privilege defaults: [description]

## Agent readiness
- Operations agents may call: [list]
- Operations that require a human approval: [list]
- Agent rate limits and attribution (which human each agent acts for): [policy]
- MCP server: yes / no / planned. Tool descriptions owned by: [name]

## Commercials
- Pricing or internal chargeback unit: [unit]
- Cost to serve per unit: [estimate]

## Adoption and success
- Adoption metric: [active integrations, time to first successful call, share of target teams using it]
- Health metrics: [error rate, breakage reports, support tickets per integration]

## Documentation and onboarding
- Reference docs, samples and quickstart: [links]
- Time to first successful call target: [time]

## Open questions
1.
2.

# Failure pre-mortem · [Initiative] · [Date]

**Facilitator:** [name]   **Participants:** [product trio, security, support, sales or partner lead, others]

## The premise
It is [date, 6 to 12 months out]. [Initiative] has failed. Write down every plausible reason why, on your own, before anyone speaks.

## Prompts (use after silent writing, to find gaps)
- Market and product fit: did customers need it badly enough? Was the timing wrong?
- Unit economics: did cost to serve or pricing make it unsustainable?
- Process (Cagan's root causes): were ideas dictated by stakeholders? Did engineering or design arrive too late? Did all the risk sit at the end?
- Feature factory signs (Cutler): no measurement, deal-driven features, no tweaking after launch, hand-offs, invisible debt?
- Technical: compatibility breaks, reliability, security review, data residency, cost at scale?

## Raw reasons
| # | Reason | Raised by |
|---|---|---|
| 1 | | |

## Ranked risks
| Rank | Failure story | Likelihood (H/M/L) | Damage (H/M/L) | Early-warning signal | Mitigation | Owner | Review date |
|---|---|---|---|---|---|---|---|
| 1 | | | | | | | |
| 2 | | | | | | | |
| 3 | | | | | | | |

## Changes to the plan
1.
2.

## Revisit
At each milestone: which early-warning signals have moved?

# Experiment analysis request · [Experiment name] · [Date]

Use this brief as the prompt to an AI harness or the request to an analyst. If it includes customer data, use an approved tool.

## The decision
- Decision this informs: [ship / iterate / stop / roll back]
- Decision maker: [name]

## The plan, as written before launch
- Hypothesis: [text, copied from the plan]
- Unit of randomization: [user / account / team / tenant]
- Expected split: [for example, 50/50]
- Primary metric (OEC) and definition: [metric]
- Guardrail metrics and definitions: [list]
- Minimum effect worth detecting: [value]
- Stopping rule and planned sample size: [rule]
- Pre-registered segments: [list, or "none"]

## Data
- Sources (connector or system names): [list]
- Date range: [start to end]
- Known data issues: [list]
- Exclusions (internal, test and sandbox accounts, bots): [list]
- Outlier rule (cap, median or none): [rule]

## Required outputs, in this order
0. Data preparation: each exclusion applied, with unit counts by group before and after; counts of missing and duplicated events by group.
1. Sample ratio mismatch check: observed versus expected split, and whether it fails. If it fails, stop and report likely causes; do not report effects.
2. Primary metric: effect size, confidence interval and significance, as planned.
3. Guardrails: status of each, with intervals.
4. Pre-registered segments only.
5. Plain-language summary in under 150 words.
6. Assumptions made about data and method.
7. Data-quality caveats.
8. What result would change the conclusion.

## Not allowed
- Changing the primary metric or its definition.
- Reporting new segments unless labeled "exploratory."
- Declaring a winner if the SRM check fails or the stopping rule wasn't met.

## Verification (completed by the requester)
- [ ] Group counts match the experiment platform.
- [ ] Primary metric and segments are the pre-registered ones.
- [ ] Harness critiqued its own analysis; issues raised: [list]
- [ ] For major decisions, a second pass reproduced the headline numbers.

# Technical fluency self-assessment · [Name] · [Quarter]

Rate each area 1 to 4. 1 = I need someone to explain it to me. 2 = I can follow the discussion. 3 = I can ask the questions that expose tradeoffs, without help. 4 = I can teach it and spot a weak answer.

| Area | Behavioral anchor for a 3 | Rating (1 to 4) | Evidence |
|---|---|---|---|
| Architecture | I can draw our system-context diagram and explain which calls are synchronous | | |
| APIs | I can say which proposed changes are breaking and why | | |
| Data models | I can explain our main entities, tenancy and residency | | |
| Reliability | I can propose SLOs and explain the error budget tradeoff | | |
| Security and privacy | I can explain our access model, scopes and audit trail | | |
| Cost | I know our unit cost per request and per customer outcome | | |
| Experimentation | I can frame a test and spot SRM, peeking and segment fishing | | |
| AI systems | I can explain our evals, retrieval and agent permissions | | |
| Design docs | I can review a design doc and find the hard-to-reverse decisions | | |

## Two areas to grow this quarter
1. Area: [ ]   Plan: [who will teach me, what I'll read in our own docs, what I'll practice]   Evidence of progress: [ ]
2. Area: [ ]   Plan:   Evidence of progress:

## Review
Re-rate at the end of the quarter with your tech lead's input.

# Feature factory check · [Team] · [Quarter]

Score each sign 0 (not true), 1 (sometimes true) or 2 (true). Signs paraphrased from John Cutler.

| Sign | Score (0 to 2) | Evidence |
|---|---|---|
| We don't measure the impact of what we ship | | |
| People move between projects without a stable mission | | |
| Launches are celebrated; outcomes aren't checked | | |
| We rarely kill or scrap work | | |
| Work isn't connected to core metrics | | |
| We don't review past product decisions | | |
| We prioritize hard but never check whether priorities paid off | | |
| We don't iterate after launch | | |
| Hand-offs keep the team away from research and from customers after release | | |
| We ship in large batches | | |
| Deal-driven features ignore complexity cost | | |
| Technical debt and refactoring are invisible | | |

**Total:** [ ] of 24

## AI acceleration check
Has AI-assisted building increased our output without improving outcomes? [evidence]

## Two changes for next quarter
1.
2.

# Growth metrics scorecard · [Product] · [Period] · v[n]

**Owner:** [PM]   **Definitions agreed with:** [marketing ops, sales ops, finance]   **Last refreshed:** [Date]

## Definitions (one line each, with source system)
- CAC: [blended or paid only; fully loaded or not; includes partner margin?] · Source: [system]
- Gross margin used: [%, by product line] · Source: [finance]
- LTV: [formula; lifetime cap in years; expansion treatment] · Source:
- Payback: CAC / (new monthly revenue per customer x gross margin) · Source:
- Activation: [event that counts] · PQL / PQA: [threshold] · Source:

## Scorecard by motion and segment
| Motion / segment | New logos | First-year ACV | CAC (fully loaded) | Gross margin | Payback (months) | LTV:CAC | NRR | Activation rate | PQL or PQA rate | Win rate | Median cycle (days) |
|---|---|---|---|---|---|---|---|---|---|---|---|
| Direct enterprise | | | | | | | | | | | |
| Partner / MSP | | | | | | | | | | | |
| Self-serve | | | | | | | | | | | |
| Cross-sell | | | | | | | | | | | |
| **Blended** | | | | | | | | | | | |

## Reference points
LTV:CAC above 3 and payback under 12 months (Skok); up to about 20 months for enterprise land-and-expand. Note any motion far outside these and why.

## What changed since last period
| Metric | Motion | Change | Cause (evidence) | Action |
|---|---|---|---|---|
| | | | | |

## Known gaps
[Missing data, definition disputes, motions too small to read]

# Journey funnel model · [Product] · [Segment] · [Date]

**Owner:** [PM]   **Built with:** [marketing, sales, customer success]   **Unit:** account / user

| Stage | Buyer question | Persona | Touchpoints (owned, paid, earned, partner, product, AI answer) | Entry definition | Leading metric | Conversion to next | Median days in stage | Observable? (yes / partly / no) | Owner | Data source and blind spots |
|---|---|---|---|---|---|---|---|---|---|---|
| Problem framing | | | | | | | | | | |
| Exploration | | | | | | | | | | |
| Trial / proof of value | | | | | | | | | | |
| Activation | | | | | | | | | | |
| Validation (security, ROI) | | | | | | | | | | |
| Purchase | | | | | | | | | | |
| Expansion and advocacy | | | | | | | | | | |

## How we estimate the unobservable stages
- Self-reported attribution question: [wording, where asked]
- Win-loss interviews: [cadence]
- AI answer audit: [cadence, question set]

## Binding constraint
Stage: [ ]   Evidence: [conversion, wait time]   Product hypothesis to fix it: [ ]   Metric to watch: [ ]

# Attribution assessment · [Report or dashboard] · [Date]

**Owner:** [PM]   **Report owner:** [name, team]   **Model in use:** first touch / last touch / linear / time decay / position-based / data-driven / other

## The decision this report supports
[Budget allocation, campaign tuning, channel reviews, comp plans]

## Bias review
| Question | Answer |
|---|---|
| What does this model over-credit? | |
| What does it under-credit? | |
| Which touches can't it see? (peers, community, AI answers, events, partner) | |
| Is the unit right? (person versus account) | |
| Does any platform self-attribute here? Double counting risk? | |
| Is targeting creating selection bias? | |

## Cross-checks
| Method | Available? | What it says | Agrees with the report? |
|---|---|---|---|
| Experiment or holdout | | | |
| MMM (calibrated?) | | | |
| Self-reported attribution | | | |
| Win-loss interviews | | | |

## Verdict
Fit for: [ ]   Not fit for: [ ]   Change needed: [ ]   Review date: [ ]

# Channel experiment plan · [Channel or program] · [Date]

**Owner:** [PM or marketing lead]   **Analyst:** [name]   **Decision maker:** [name]

## Hypothesis
We believe [program] causes [outcome] in [segment], and we'll know we're right if [metric] is at least [x] higher in the treatment group than in the holdout.

## Design
- Unit of randomization: user / account / geo
- Population: [list, size]
- Treatment: [what they get]   Holdout: [share, what they don't get]
- Randomization method and who runs it:
- Duration: [weeks or quarters, with the reason]

## Metrics
- Primary (pre-registered): [ ]
- Guardrails: [ ]
- Minimum detectable effect at this sample size: [ ]

## Decision rule (written before launch)
- If lift ≥ [x]: [scale / keep]
- If no detectable lift: [cut / redesign / combine with other evidence]
- If inconclusive: [what we'll do, and what extra evidence we'll use]

## Threats and mitigations
[Contamination between groups, small sample, seasonality, sales outreach to holdout accounts]

## Readout
Date: [ ]   Result with interval: [ ]   Decision: [ ]   Logged in: [decision log]

# AI answer engine audit · [Product] · [Month]

**Owner:** [PM or product marketing]   **Assistants checked:** [list]   **Run by:** [harness, date]

## Fixed buyer question set
| # | Buyer question (as a buyer would ask it) | Persona | Journey stage |
|---|---|---|---|
| 1 | | | |

## Results
| # | Assistant | Product mentioned? | Position in answer | Accurate? | Errors or risky claims | Sources the answer drew on |
|---|---|---|---|---|---|---|
| | | | | | | |

## Share of answer
[Mentions / questions asked, by assistant, against last month]

## Corrections
| Error | Likely source | Fix (docs, reviews, public content) | Owner | Recheck date |
|---|---|---|---|---|
| | | | | |

# [Decision] · Data-driven strategy memo · [Date]

**Author:** [PM]   **Decision maker:** [name]   **Decision needed by:** [Date]

## The decision we're asking for
[One or two sentences.]

## Context and numbers
[The three to five figures that matter, each with definition and source. Link to the scorecard and funnel model.]

## Options
| Option | Expected incremental impact (range) | Cost | Payback effect | Main risk |
|---|---|---|---|---|
| A | | | | |
| B | | | | |
| Do nothing | | | | |

## Recommendation
[Option, and why the evidence supports it.]

## What the data can't see
[Unobservable stages, attribution limits, small samples, open definitions.]

## What would change our mind
[The experiment result or metric movement that reverses this call, and by when we'll know.]

## Review date
[Date, forum]

# Retention and churn report spec · [Product] · v[n] · [Date]

**Owner:** [PM]   **Agreed with:** [Finance lead], [Customer success lead]   **Cadence:** Quarterly   **Next review:** [Date]

## Decisions this report supports
1. [For example: where to invest retention effort next quarter]
2. [For example: whether the onboarding change worked]

## Definitions (fixed; change only with a version bump)
| Term | Definition | Source system |
|---|---|---|
| Customer | [Contracting entity / account] | [CRM] |
| Cohort start | [Contract signature / go-live] | |
| Contract churn | [Non-renewal / termination] | |
| Usage churn | [No active users for N days / usage below X% of baseline] | [Telemetry] |
| Active | [Definition] | |
| Revenue base | [Contracted ARR / billed / consumed] | [Billing] |
| NRR | Revenue now from customers active 12 months ago ÷ their revenue 12 months ago | |
| GRR | As NRR, excluding expansion, cross-sell and price increases (max 100%) | |

## Segments
[Three to six: ACV band, channel, industry, region, onboarding path, migration status]
Minimum cohort size for reporting a rate: [N accounts]

## Sections
1. **Headline**: NRR, GRR and logo retention, overall and by segment, with counts.
2. **NRR bridge** by segment: starting revenue, + expansion, − contraction, − churn.
3. **Contract survival curves** by segment, current customers treated as censored.
4. **Usage survival curves** by segment, with the gap to contract survival.
5. **Hazard view**: where in the lifecycle risk concentrates.
6. **Cohort triangles**: logo, user and revenue retention.
7. **Churn reasons**: coded from exit interviews and notes, linked to revenue lost.
8. **What changed since last quarter** and why.
9. **Implications**: decisions proposed, with size of prize and confidence.

## Checks before publishing
- [ ] Totals reconcile to finance ARR within [x]%
- [ ] Definitions echoed back by the analysis and match this spec
- [ ] Five sample accounts spot-checked in source systems
- [ ] No rate shown without its count
- [ ] Sensitivity to the inactivity threshold tested

## Change log
| Version | Date | Change | Approved by |
|---|---|---|---|
| | | | |

# Customer lifetime value model brief · [Product] · [Date]

**Owner:** [PM]   **Finance partner:** [Name]   **Decision it informs:** [For example: channel investment, acquisition spend limits, CS coverage]

## Question
[One sentence. For example: "Is a mid-market customer acquired through partners worth more or less than a direct one, after cost to serve?"]

## Scope
- Segments or channels compared:
- Population and time window:
- Exclusions:

## Model type
Simple (constant retention, margin multiple) / Survival-weighted by segment / Predictive per account
Why this level is enough for the decision:

## Inputs and assumptions
| Input | Value or range | Source | Confidence |
|---|---|---|---|
| Revenue per customer per year | | | |
| Gross margin after inference and hosting | | | |
| Cost to serve (CS, support, onboarding) | | | |
| Partner margin (if any) | | | |
| Retention by year (from survival curve) | | | |
| Expansion assumption (capped or decaying) | | | |
| Discount rate | | Finance | |
| Acquisition cost | | | |
| Horizon | [years] | | |

## Outputs
| Segment | CLV low | CLV base | CLV high | CLV ÷ acquisition cost | Payback period |
|---|---|---|---|---|---|
| | | | | | |

## Sensitivity
The two assumptions that move the answer most:
1.
2.

## What this model doesn't capture
[For example: strategic value of logos, partner-level churn, referral value]

## Recommendation and confidence
[Decision supported, confidence level, what would change it]

# Customer health score definition · [Product] · v[n] · [Date]

**Owner:** [PM or CS lead]   **Purpose (decision it drives):** [For example: which accounts get proactive CS outreach]   **Review date:** [Date]

## Population
[Which accounts; segment variants if the model differs by segment]

## Components
| Component | Signal | Source system | Weight | Green | Yellow | Red | Available how early before renewal? |
|---|---|---|---|---|---|---|---|
| Deployment | [Entitled vs activated] | | | | | | |
| Engagement | [Stakeholder coverage: champion, buyer, gatekeeper] | | | | | | |
| Adoption | [Breadth and depth of use] | | | | | | |
| ROI | [Agreed outcome milestones met] | | | | | | |
| Trust (AI products) | [Rejected or reversed AI actions] | | | | | | |
| Sentiment | [Survey, ticket themes] | | | | | | |

## Overall bands
Green: [rule]   Yellow: [rule]   Red: [rule]
Refresh cadence: [daily / weekly]

## Exclusions (leakage check)
Signals deliberately left out because they appear only after a decision to leave:
-

## Playbook per band
| Band | Owner | Action | Response time |
|---|---|---|---|
| Green | | | |
| Yellow | | | |
| Red | | | |

## Validation
- Back-test window: last [4 to 8] quarters of renewals
- Share of churned accounts that were red 90 days before renewal: [x]%
- Share of churned accounts that were green 90 days before renewal: [x]%
- Share of red accounts that renewed: [x]%
- Retention pilot (randomized) planned or run: [link]

## Governance
Who can change weights: [name]   Manual overrides allowed: Yes / No, logged by [name]

# Retention pilot plan · [Intervention] · [Date]

**Owner:** [PM]   **CS partner:** [Name]   **Decision it informs:** whom to target with [intervention] at scale

## Hypothesis
Offering [intervention] to [risk band or segment] will improve [usage measure / renewal] compared with normal coverage.

## Design
- Eligible population: [accounts, risk band, segment]
- Assignment: random, [n] treatment and [n] control
- Intervention: [what exactly happens, who delivers it]
- Control: normal coverage
- Duration: [weeks]
- Primary measure: [for example weekly active users, renewal intent, GRR]
- Secondary measures:

## What we want to learn
Which kinds of accounts respond (for example: champion present, deployment incomplete, segment)

## Guardrails
- No account is denied help it requests
- Stop rule: [condition]

## Result
| Group | Accounts | Primary measure before | After | Change |
|---|---|---|---|---|
| Treatment | | | | |
| Control | | | | |

Accounts that responded most: [characteristics]
Targeting rule going forward: [rule]

# Voice-of-customer report · [Product] · [Period]

**Owner:** [PM]   **Sources:** [surveys, tickets, calls, community, CSM notes, churn interviews]   **Items analyzed:** [n]   **Codebook version:** [v]

## Headline
[Two or three sentences: the themes that matter most and what they cost or could earn]

## Themes
| Theme | Share of items | Trend vs last period | Accounts raising it | ARR of those accounts | GRR of those accounts | Owner |
|---|---|---|---|---|---|---|
| | | | | | | |

## For each top theme
**[Theme name]**
- What customers say (three verbatims with source references):
  1. "[Quote]" ([source, date])
  2.
  3.
- Who raises it: [segments, roles]
- Link to retention or revenue: [evidence]
- Root cause (if known):
- Action and owner:

## New themes proposed this period (pending approval)
| Proposed theme | Example items | Approve / merge / reject |
|---|---|---|
| | | |

## Sentiment scores (context only)
| Measure | This period | Last period | Responses | By role |
|---|---|---|---|---|
| NPS | | | | |
| CSAT | | | | |
| Effort score | | | | |

## Closing the loop
- Individual follow-ups completed: [n of n]
- Root-cause fixes shipped since last report:

## Method and quality
- Human-labeled validation sample: [n] items; agreement: [measure]
- Theme shares, human vs machine: [comparison]
- Known weaknesses: [for example negation, sarcasm, a theme undercounted]
- Personal data removed before analysis: Yes / No; approved tool used: [tool]

# Sentiment analysis request · [Topic] · [Date]

**Requester:** [PM]   **Decision it informs:** [Decision]   **Due:** [Date]

## Question
[For example: "What are the main sources of frustration among mid-market customers in the last two quarters, and are they linked to lower retention?"]

## Sources and window
| Source | Connector or export | Time window | Approx. volume | Data restrictions |
|---|---|---|---|---|
| | | | | |

## Data handling
- Personal data to remove:
- Customer contract or residency limits checked by: [name]
- Approved tool:

## Codebook
Use codebook v[n] (attached). New themes may be proposed separately, not added.
Sentiment: positive / negative / mixed / neutral, per theme mentioned (aspect level), not only per item.

## Known hard cases to test
- Negation ("would be great if it stopped...")
- Sarcasm
- Positive question framing with negative answers
- Domain terms: [list]

## Validation
- Human-labeled sample: [n] random items, labeled by [names] before seeing machine output
- Report agreement, disagreements and theme shares (human vs machine)

## Outputs
- Theme table with counts, shares and trends
- Three verbatims per theme with source references
- Link to account retention and revenue where the source allows
- Confidence statement and known weaknesses

# Retention strategy decision · [Product] · [Date]

**Owner:** [PM]   **Decision maker:** [Name]   **Decision needed by:** [Date]

## Finding
[One paragraph: what the analysis showed, with the key numbers and their counts]

## Evidence
| Analysis | Result | Confidence | Link |
|---|---|---|---|
| Survival / hazard | | | |
| NRR and GRR decomposition | | | |
| CLV comparison | | | |
| Health score and pilot | | | |
| VoC themes | | | |

## Options
| Option | Type (retention / expansion / pricing / segment exit / channel) | Expected effect | Cost | Risk |
|---|---|---|---|---|
| 1. | | | | |
| 2. | | | | |
| 3. Do nothing | | | | |

## Recommendation
[Option], because [reason].

## Success measure and review
- Leading indicator: [for example usage survival in segment X]
- Lagging indicator: [for example GRR in segment X]
- Review date:
- What would make us reverse this:

# Insight statement · INS-[xx] · [Product] · [Date]

**Owner:** [PM]   **Status:** Draft / Briefed / Decided / Retired   **Linked decision:** [decision log entry]

## The insight in one sentence
[User] needs [need] because [explanation of the behavior].

## Structure
- **Who:** [role, context, position in the buying group]
- **Observed:** [the behavior, stated as observation, not interpretation]
- **Evidence:** [n interviews, usage report, tickets, reviews, with source IDs]
- **Because:** [motivation or constraint that explains the behavior]
- **Tension:** [what they want] versus [what stops them]
- **So we believe:** [implication for the product]
- **Confidence:** High / Medium / Low
- **What would change our mind:** [specific evidence]

## Quality test
| Test | Pass / Fail | Note |
|---|---|---|
| Non-obvious: the team was not already acting as if this were true | | |
| Explains behavior: says why, not only what | | |
| Grounded: traces to at least two independent sources | | |
| Implies action: a reader knows what to do differently | | |

## Contrary evidence
- [What doesn't fit, with source IDs]

## Forward trace
| Decision (build / defer / reject) | Requirement IDs | Date | Result when measured |
|---|---|---|---|
| | | | |

# Buying-group insight map · [Product or deal type] · [Date]

**Decision being studied:** [purchase, renewal, expansion, adoption of a capability]
**Evidence:** [win/loss interviews, call recordings, security reviews, CRM notes]

| Role | Person or persona | Job in the purchase | Fear | Proof they need | Veto power (none / soft / hard) | Evidence |
|---|---|---|---|---|---|---|
| End user | | | | | | |
| Champion | | | | | | |
| Economic buyer | | | | | | |
| Technical evaluator | | | | | | |
| Procurement or legal | | | | | | |
| Partner (if any) | | | | | | |

## Where consensus stalls
[Which role, at which step, and why]

## Risk-reduction features this implies
| Fear addressed | Feature or artifact (pilot, audit log, exit clause, security pack) | Owner |
|---|---|---|
| | | |

## How AI assistants describe us
[What a buyer's AI assistant says about our product for this role's key question, and where it is wrong or vague]

# Insight brief · [Headline in one sentence] · [Date]

**To:** [decision owner]   **From:** [PM]   **Decision needed by:** [date]

## The insight
[One sentence. Lead with it.]

## Why it matters for this decision
[The so-what: what the decision is, and how this insight changes it]

## Evidence
| Source | Sample | What it shows | Strength (strong / some / weak) |
|---|---|---|---|
| | | | |

**Observation:** [what we saw]
**Interpretation:** [what we think it means]
**Contrary evidence:** [what doesn't fit]

## Who is affected
[Roles, segments, number of customers, revenue at stake]

## Options
| Option | What it means | Cost | Risk |
|---|---|---|---|
| A | | | |
| B | | | |
| Do nothing | | | |

## Recommendation
[Option and reason, in two or three sentences]

## Confidence
High / Medium / Low. This would change if [specific evidence].

## The ask
[Decision required], owner [name], by [date].

# Behavioral design review · [Feature or flow] · [Date]

**Reviewers:** [PM, designer, engineer, legal or compliance where billing, consent or data is involved]
**Spec:** [link]   **Markets:** [US / EU / other]

## 1. Choice architecture inventory
| Element | Type (default, framing, ordering, prominence, choice set, prompt, AI suggestion) | Current design | Intended effect on behavior | Rationale |
|---|---|---|---|---|
| | | | | |

## 2. Persuasion or manipulation: four tests (per element)
| Element | Serves user's own goal? | Survives disclosure? | Symmetric (out as easy as in)? | True information? | Verdict |
|---|---|---|---|---|---|
| | | | | | Keep / Change / Escalate |

## 3. Dark-pattern check
Mark any that apply and name the screen and element.
- [ ] Sneaking (items, renewals or changes added without clear notice)
- [ ] Hard to cancel or downgrade (exit harder than entry)
- [ ] Preselection that favors us over the user
- [ ] Obstruction (data export, account closure or opt-out made laborious)
- [ ] Hidden costs or hidden subscription terms
- [ ] Trick wording or confirmshaming
- [ ] Visual interference (the option we prefer is dominant, the other hidden)
- [ ] Nagging (asking again for a choice already made)
- [ ] Fake urgency, scarcity or social proof
- [ ] Comparison prevention (plans or prices hard to compare)
- [ ] Privacy choices obscured or subverted
- [ ] AI-specific: agent that flatters, pressures or exploits the user's situation

Regulatory lenses to note (confirm applicability with counsel): FTC Act Section 5 and ROSCA (US); DSA Article 25 for online platforms, UCPD and GDPR (EU); AI Act Article 5 for AI systems (EU).

## 4. AI trust check (AI features only)
- Is evidence shown where the decision is made?
- Is confidence shown honestly, including uncertainty?
- Can the user adjust the output, not only accept or reject?
- Are acceptance and wrong acceptance both measured?
- Does the design guard against automation bias at approval points?

## 5. Defaults register
| Default | Value | Owner | Rationale | Share of customers who change it | Review date |
|---|---|---|---|---|---|
| | | | | | |

## Outcome
Approved / Approved with changes / Escalated to [name]. Changes required: [list]. Signed off by [names] on [date].

# Product specification · [Feature] · v[n] · [Date]

**Owner:** [PM]   **Design:** [name]   **Engineering:** [name]   **Status:** Draft / In review / Approved

## 1. Context and linked insights
| Insight ID | Insight (one sentence) | Confidence |
|---|---|---|
| | | |

Other drivers (strategic, compliance, technical): [list, named as drivers]

## 2. Users and buying-group roles affected
[End users, champion, economic buyer, technical evaluator, procurement, partner]

## 3. Goals, non-goals and success metrics
- Goals:
- Non-goals:
- Success metrics with baselines and review date:

## 4. Functional requirements
| Req ID | Requirement | Traces to | Acceptance criterion (Given, When, Then) | Priority |
|---|---|---|---|---|
| REQ-[xx] | | INS-[xx] | Given [context], when [event], then [observable outcome] | |

## 5. Behavioral design decisions
| Decision (default, framing, choice set, prompt) | Choice made | Rationale | Four-test result |
|---|---|---|---|
| | | | |

## 6. AI behavior (AI features only)
- Expected outputs and format:
- When to decline, ask or escalate:
- How evidence and confidence are shown:
- Evals that gate release, with thresholds:
- Human approval points and what the approver sees:

## 7. Non-functional requirements
Security and access, audit logging, latency, availability, data residency, accessibility, cost per action.

## 8. Risks and review results
- Behavioral design review outcome: [link and verdict]
- Open questions:
- Risks and mitigations:

## 9. Traceability
| Insight ID | Opportunity or job | Req ID | Acceptance criterion | Success metric | Verification (test or eval) | Status |
|---|---|---|---|---|---|---|
| | | | | | | |

Requirements with no upstream insight or named driver: [list or "none"]
High-confidence insights with no decision: [list or "none"]

# Relaunch plan · [Product] · [Launch moment] · [Date]

**Owner:** [PM]   **Marketing lead:** [name]   **Decision maker:** [name]

## 1. Trigger and evidence
Trigger: Unexpected competitors in deals / Value resonates with a different segment / New segment entry / Capability outgrew the category / Trust reset
Evidence: [win/loss, pipeline, interviews, with sources]
Why this is perception, not product quality or onboarding: [reasoning]

## 2. Positioning delta
| Component | Today | After relaunch | Evidence |
|---|---|---|---|
| Competitive alternatives | | | |
| Differentiated capabilities | | | |
| Value | | | |
| Target customers | | | |
| Market category | | | |

## 3. Segments and buying-group messages
| Segment | Role | Message | Proof |
|---|---|---|---|
| | | | |

## 4. Product changes shipping with the relaunch
[List, with spec links]

## 5. Existing customers
- What changes for them, and when:
- How they are told (channel, notice period):
- Migration: opt-in or scheduled, with a published timeline; no silent migration
- Data export and exit: [how easy, confirmed by the behavioral design review]
- Contract or pricing changes and how they are disclosed:

## 6. Channels and enablement
Sales, partners, customer success, documentation, and the content AI assistants will summarize.

## 7. Metrics and baselines (set before launch)
| Metric | Type (leading / lagging) | Baseline | Target | Cohort | Review date |
|---|---|---|---|---|---|
| Qualified pipeline in new category | Leading | | | | |
| Win rate vs. new competitor set | Leading | | | | |
| Sales-cycle length | Leading | | | | |
| Message recall in win/loss | Leading | | | | |
| New capability activation | Leading | | | | |
| NRR, expansion, churn in migrated cohort | Lagging | | | | |

## 8. Risks and rollback
| Risk | Signal | Response | Owner |
|---|---|---|---|
| | | | |

# Methodology selection guide · [Product] · [Team] · [Date]

**Owner:** [PM]   **Agreed with:** [tech lead, designer, team]   **Review by:** [Date]

## 1. The work (last two quarters, from the tracker)
- Share of work planned vs unplanned: [x]% / [y]%
- Share of work ordered (known solution) vs complex (learning required): [x]% / [y]%
- Typical item size: [hours / days / weeks]
- Examples of each category: [three links]

## 2. The main risk (Chapter 00's four risks)
Value / Usability / Feasibility / Viability, with evidence:

## 3. External commitments
| Commitment | Type (date, scope, service level) | Truly fixed? | Owner | Date |
|---|---|---|---|---|
| | | | | |

## 4. Coordination
- Teams sharing this codebase or backlog:
- Dependencies that could be removed by an API, contract or platform capability:

## 5. Verification strength
- Automated tests: strong / partial / weak
- Evals for AI behavior: strong / partial / weak / not applicable
- Share of changes written mainly by coding agents:

## 6. Default method
| Situation | Default |
|---|---|
| Ordered, fixed external date and scope | Plan-driven, iterative build inside gates |
| Complex, value risk high | Scrum with dual-track discovery |
| Interrupt-driven, service commitments | Kanban with WIP limits and an SLE |
| Fixed date, flexible scope | Appetite-bounded cycles (Shape Up style) or Scrum with appetites |
| Five or more teams, real dependencies | Remove dependencies first; then LeSS, or SAFe for portfolio governance |
| Agent-heavy, strong CI and evals | Continuous flow with a fixed review, retro and planning cadence |

**Chosen method:** [method]
**Why (one paragraph):**
**What would make us change it:** [specific trigger, e.g. unplanned work above an agreed share for two months]

# Team working agreement · [Team] · v[n] · [Date]

**Method:** [Scrum / Kanban / cycles / hybrid]   **Signed off by:** [team members]   **Review date:** [Date]

## Cadence
- Planning or betting: [when, how long]
- Daily coordination: [when, 15 minutes]
- Review with customers or customer-facing staff: [when, who is invited]
- Retrospective: [when]

## Workflow and WIP limits
| State | Entry policy | WIP limit |
|---|---|---|
| Ready | | |
| In progress | | |
| In review | | |
| Evals and security | | |
| Ready to release | | |

## Definition of Done
- [ ] Tests pass, including tests not written solely by an agent
- [ ] Evals updated and passing (AI features)
- [ ] Cost per task within budget (features that call models)
- [ ] Security review complete where required
- [ ] Documentation and release note written
- [ ] Customer-facing teams told what changed

## Coding agents
- Agents may change: [code areas]
- Agents may not change: [eval suites, test configuration, approval gates, security controls]
- Human review required: [one reviewer by default; two for these areas]
- Size guideline for agent-generated changes: [e.g. reviewable in one sitting]
- An agent disabling or deleting a test is treated as a defect.

## Interrupt work
- How escalations enter: [channel, triage owner]
- Classes of service: Expedite (may exceed WIP; criteria) / Standard / Fixed date
- Service level expectation: [x]% of [item type] finish within [n] days

## Decision rights
| Decision | Decides | Consulted |
|---|---|---|
| What problem to solve next | PM | Team, design, tech lead |
| How to solve it | Team | PM, design |
| Scope cuts inside an appetite | Team with PM | Stakeholders informed |
| Release readiness | Tech lead | PM, security |

## Meeting norms
[Start and end times, async defaults, recording, decisions written down]

# RICE scoring sheet · [Product] · [Quarter] · [Date]

**Goal metric all items are scored against:** [one metric]
**Reach unit:** accounts / ARR / users / events per [quarter]   (use one unit for the whole sheet)
**Calibration items:** [two or three reference items with agreed scores]

| ID | Initiative | Reach (unit, period, source) | Impact (3 / 2 / 1 / 0.5 / 0.25, rationale) | Confidence (100 / 80 / 50%, evidence label) | Effort (person-months to production and adoption) | RICE | Cost-of-delay note | Override? (dependency, table stakes, commitment) | Decision |
|---|---|---|---|---|---|---|---|---|---|
| | | | | | | | | | |

Score = (Reach × Impact × Confidence) ÷ Effort.

## Evidence labels and confidence caps
| Evidence | Maximum confidence |
|---|---|
| Opinion or conviction | 50% |
| Anecdotes, a few customer requests | 50% |
| Interviews across personas, or usage data | 80% |
| Test result, pilot or incident evidence | 100% |

## Effort includes
Build, review, evals, security review, migration, documentation, enablement, support readiness.

## Review questions
1. Which three rows have the weakest evidence?
2. Which items have a deadline or rising cost that RICE ignores?
3. Which items differ by less than the noise? Treat them as ties.
4. Is every item at the same grain (initiatives, not tickets)?

# Shaped bet · [Name] · [Date]

**Shaped by:** [names]   **Cycle:** [dates]   **Team:** [team]

## Problem
[The specific customer problem, with evidence: incidents, interviews, data]

## Appetite
[Small batch: 1 to 2 weeks / Big batch: 6 weeks / other]. This is a budget, not an estimate.

## Solution (rough, solved, bounded)
[The main elements and how they fit, at the level of a sketch]

## Rabbit holes
[Known technical or design traps, and how we avoid them]

## No-gos
[What is explicitly out of scope]

## Circuit breaker
If not shippable by [date], we [ship this reduced scope / stop and re-pitch]. We do not extend by default.

## Outcome signal
[The metric and threshold that tells us this worked, and when we'll check]

# Review · [Team] · [Sprint or cycle n] · [Date]

**Attendees:** [team, PM, customer success, design partner]

## Goal
Sprint Goal or bet: [text]
Met / Partly met / Not met, with one line why:

## What shipped
| Item | Linked to goal? | Released to | Evidence it works |
|---|---|---|---|
| | | | |

## Outcome metric
[Metric]: [value before] → [value now]. Too early to tell? Say when we'll know.

## Customer evidence
[Demo feedback, design-partner reactions, support signals, quotes with source]

## What we learned in discovery
- Ideas tested:
- Killed:
- Moving to delivery:

## Flow
- Throughput: [items finished]
- Cycle time, 85th percentile: [days]
- Oldest unfinished item and its state: [item, age]
- Age in review and verification: [days]

## Risks and decisions needed
| Decision | Owner | By when |
|---|---|---|
| | | |

## Next goal
[Draft Sprint Goal or next bet]

# Process health check · [Team] · [Quarter] · [Date]

Score each from 1 (poor) to 5 (strong) with evidence. Pick at most two to improve next quarter.

| # | Dimension | Score | Evidence |
|---|---|---|---|
| 1 | Goals are outcomes, not output | | |
| 2 | WIP stays within limits | | |
| 3 | Cycle time trend is stable or improving | | |
| 4 | Few items age past the SLE | | |
| 5 | Changes are small (batch size) | | |
| 6 | Review and verification wait time is short | | |
| 7 | Escaped defects and incidents are low | | |
| 8 | Discovery kills or reshapes ideas before build | | |
| 9 | PM and team have regular direct customer contact | | |
| 10 | Agent-generated changes have a low revert rate | | |
| 11 | The team reports a sustainable pace | | |
| 12 | Every ceremony produces a decision or a change | | |

## Two changes for next quarter
1. [Change], owner, how we'll know it worked:
2.

## Method still fits?
Has the work changed (share unplanned, complexity, commitments, team count)? Yes / No. If yes, rerun the selection guide.

# Value proposition canvas · [Product] · [Role] · v[n] · [Date]

**Segment:** [segment]   **Role in the deal:** End user / Champion / Economic buyer / Technical evaluator / Procurement / Partner
**Owner:** [PM]   **Evidence:** [number of interviews, pilots, data sources]   **Status:** Hypothesis / Partly confirmed / Confirmed

## Customer profile
### Jobs (ranked)
| Rank | Job | Type (functional / social / emotional) | Evidence |
|---|---|---|---|
| 1 | | | |

### Pains (ranked, measurable)
| Rank | Pain | Measurable form (how much, how often) | Evidence |
|---|---|---|---|
| P1 | | | |

### Gains (ranked, measurable)
| Rank | Gain | Measurable form | Required / expected / desired / unexpected | Evidence |
|---|---|---|---|---|
| G1 | | | | |

## Value map
### Products and services
-

### Pain relievers
| Pain reliever | Addresses (pain ID) | Proof available today |
|---|---|---|
| | | |

### Gain creators
| Gain creator | Addresses (gain ID) | Proof available today |
|---|---|---|
| | | |

## Fit
- Top pains and gains with no reliever or creator:
- Relievers or creators that address nothing ranked:
- Gains that feed the economic value model (economic buyer canvas only):

## Untested assumptions
1. [Assumption] · Test: [how] · Signal: [what would falsify it]

# EVC model · [Product] · [Segment] · [Customer or composite] · [Date]

**Owner:** [PM]   **Built with:** [customer names and roles, or "composite of n customers"]   **Time horizon:** [e.g. 12 months]   **Units:** [per year / per seat / per incident]

## 1. Benefit (not feature)
What changes for the customer, in one sentence:

## 2. Next best alternative
- What the customer would do without us:
- Its real price after discounts, in our units and horizon: $[ ]   Source:
- **Reference value:** $[ ]

## 3. Differentiation drivers
| Driver | + / − | Calculation in words | Inputs (owner) | Annual value | Evidence and source | Confidence (H/M/L) | Risk haircut % | Risk-adjusted value |
|---|---|---|---|---|---|---|---|---|
| | + | | | | | | | |
| | − | | | | | | | |
| **Total differentiation value** | | | | | | | | |

## 4. EVC
- EVC (unadjusted) = reference value + differentiation value: $[ ]
- EVC (risk-adjusted): $[ ]

## 5. Price corridor
- Floor: fully loaded cost to serve, including inference: $[ ]   Source: finance
- Ceiling: risk-adjusted EVC: $[ ]
- Proposed price: $[ ]   Share of risk-adjusted EVC captured: [ ]%
- Why this share (lifecycle stage, buyer uncertainty, strategy):

## 6. Assumption log
| # | Assumption | Value used | Source | Date checked | Owner |
|---|---|---|---|---|---|
| 1 | | | | | |

## 7. Review
Next review date, and the product data that will confirm or correct each driver:

# Customer ROI calculator spec · [Product] · v[n] · [Date]

**Owner:** [PM]   **Partners:** product marketing, sales engineering, customer success, finance
**Audience:** [economic buyer role] and [champion role]
**Disclosure line (shown on every output):** Built by [company]. Results are modeled from the inputs shown, not measured at your organization. [If any inputs come from a commissioned study, say so.]

## Value drivers
| Driver | Calculation in words | Input the customer owns | Default value | Source of default | Editable? |
|---|---|---|---|---|---|
| | | | | | Yes |

## Cost side (full TCO)
| Cost | Calculation in words | Default | Source |
|---|---|---|---|
| Subscription or platform fee | | | |
| Usage, outcome or overage charges | | | |
| Implementation and integration | | | |
| Internal admin and oversight time | | | |
| Training and change management | | | |
| (AI products) Review and approval time, data preparation | | | |

## Time to value
- Ramp assumption by month or quarter:
- Month in which full value is assumed:

## Risk adjustment
| Driver | Default haircut % | Why | Customer can change? |
|---|---|---|---|
| | | | |

## Outputs
- Net benefit (year 1 and three-year)
- ROI
- Payback in months
- NPV at the customer's own discount rate (customer enters the rate)
- A sensitivity view: the two inputs that move the result most

## Rules
- No default without a cited source. Missing evidence shows as "Customer to supply."
- Every calculation is visible in plain words, not hidden.
- The customer can export inputs and assumptions.

## After the sale
| Driver | How it is measured in product | Report | Cadence | Owner |
|---|---|---|---|---|
| | | Quarterly business review | Quarterly | Customer success |

# Investment case · [Initiative] · [Date]

**Owner:** [PM]   **Finance partner:** [name]   **Decision maker:** [name]   **Decision needed by:** [date]

## Decision asked
[One sentence: approve $[ ] for [scope] through [first gate].]

## Options
| Option | Description | Baseline assumption |
|---|---|---|
| Do nothing | | [Realistic baseline, including erosion if competitors move] |
| Option A | | |
| Option B (staged) | | |

## Key assumptions
| Driver | Value | Evidence | Confidence (H/M/L) |
|---|---|---|---|
| Adoption (customers, ramp) | | | |
| Price and value metric | | | |
| Gross margin (including inference) | | | |
| Cost to build | | | |
| Cost to run | | | |
| Time to first revenue | | | |

## Cash flow summary (by year, versus do-nothing baseline)
| | Year 0 | Year 1 | Year 2 | Year 3 | Year 4 |
|---|---|---|---|---|---|
| Incremental revenue | | | | | |
| Incremental gross profit | | | | | |
| Investment | | | | | |
| Erosion avoided versus baseline | | | | | |
| Net cash flow | | | | | |

## Results
- Discount rate (from finance): [ ]%
- NPV: $[ ]   Payback: [ ] months   IRR (if finance uses it): [ ]%
- NPV against a flat baseline, for comparison: $[ ]

## Sensitivity (top three drivers)
| Driver | Value at which NPV reaches zero | How far that is from the base case |
|---|---|---|
| | | |

## Scenarios
| Scenario | Key differences | NPV |
|---|---|---|
| Downside | | |
| Base | | |
| Upside | | |

## Stage gates and kill criteria
| Gate | Date | Evidence required to continue | Kill or pivot if |
|---|---|---|---|
| | | | |

## Value not in the numbers
- Strategic options this creates (flexibility):
- Risks not modeled:

# Lifecycle pricing plan · [Product or portfolio] · [Date]

**Owner:** [PM]   **Partners:** pricing or monetization, finance, sales, customer success

| Product or capability | Stage (intro / growth / maturity / decline) | Evidence for stage | Pricing objective | Price relative to EVC | Packaging and value metric | Discount guardrails | Trigger for next stage | Customer communication | Risks |
|---|---|---|---|---|---|---|---|---|---|
| | | | | | | | | | |

## Launch choice (introduction stage only)
- Skimming / penetration / market-based, and why:
- How buyer uncertainty is reduced (pilot, guarantee, minimum, credits):

## Decline and sunset (decline stage only)
- Price for the remaining base:
- Migration offer toward the successor:
- End-of-life date and notice period:
- Contract commitments to honor:

## Review
Review at each quarterly business review, and whenever a stage trigger fires.

# Pricing ethics review · [Pricing page, proposal or order form] · [Date]

**Reviewer:** [PM]   **Second reviewer:** [legal or product marketing]

| Check | Pass / Fail | Notes |
|---|---|---|
| Every option shown is real and purchasable (no decoy that cannot be bought) | | |
| Any reference or "was" price is a price we actually charged | | |
| Any deadline or scarcity claim is true and will be honored | | |
| The full price, including usage, overage and minimums, is shown before commitment | | |
| AI consumption charges are explained in plain words with an example bill | | |
| Spend visibility, alerts or caps exist for usage-based charges | | |
| Cancellation or downgrade terms are as easy to find as the purchase path | | |
| A customer who learned how this was designed would not feel tricked | | |

## Decision
Ship / Fix and re-review. Fixes required:

# Market sizing worksheet · [Product or opportunity] · v[n] · [Date]

**Owner:** [PM]   **Reviewed with:** [FP&A, sales ops]   **Period for SOM:** [e.g., 3 years]

## Value unit
Annual value per account = [units of value per year, e.g., resolved incidents, documents, seats] × [price per unit]
Basis for price: [current price list / pricing research / comparable products]
Expected price trend: [flat / falling by about x% a year because ...]

## Segments (mutually exclusive)
| Segment | Definition (trigger, job, firmographic filters) | Buying motion | Account count | Source and date | Confidence (H/M/L) | Annual value per account | Basis for value | Segment value | In SAM? (Y/N and why) | Reachable in period |
|---|---|---|---|---|---|---|---|---|---|---|
| | | | | | | | | | | |

Rule that keeps segments from overlapping: [describe]

## Totals
| Layer | Value | Boundary rule | What would have to be true |
|---|---|---|---|
| TAM | | Every buyer with the job | |
| SAM | | [integrations, regions, compliance, channel] | |
| SOM | | From the capacity model below | |

## SOM capacity model
| Driver | Value | Source | Owner |
|---|---|---|---|
| Quota-carrying reps (by year) | | | |
| Ramp time | | | |
| Partner-sourced pipeline | | | |
| Win rate by segment | | | |
| Average first-year contract value | | | |
| Net revenue retention | | | |

## Cross-checks
- Top-down check: [industry total, source, category definition, filters] → [value]
- Value-based check: [cost of the job today, including people time] → [value]
- Do the methods agree within an order of magnitude? [Yes / No: the broken assumption is ...]

## Excluded on purpose
[Segments, regions or revenue types left out, and why]

# Competitive landscape · [Product] · [Segment] · [Quarter]

**Owner:** [PM or PMM]   **Last verified:** [Date]   **Next refresh:** [Date]

## The question customers are answering
"What would we do if [product] didn't exist?" Most common answer in win/loss: [answer]

## Alternatives by layer
| Layer | Alternative | Who chooses it | Why they choose it | Our win rate against it | Evidence |
|---|---|---|---|---|---|
| Direct | | | | | |
| Indirect | | | | | |
| Substitute (including build in-house) | | | | | |
| Do-nothing | Status quo / delay | | | | |

## Map axes
- X axis: [buying criterion] · Source: [win/loss, RFPs, requirement lists]
- Y axis: [buying criterion] · Source:
- Bubble size (only if sourced): [measure and source]

## Five Forces summary
| Force | Strength (H/M/L) | Evidence | Effect on our margin or pricing power |
|---|---|---|---|
| Rivalry | | | |
| New entrants | | | |
| Buyer power | | | |
| Supplier power (including model providers) | | | |
| Substitutes (including DIY AI harness) | | | |

Strongest two forces and what we do about them:
1.
2.

## What changed since the last version
-

# Competitor profile · [Alternative] · [Date]

**Owner:** [PM or PMM]   **Last verified:** [Date]   **Confidence:** H / M / L

## Snapshot
| Field | Detail | Source and date |
|---|---|---|
| Who they are | | |
| Size (revenue, funding or segment revenue) | | |
| Target customers and segments | | |
| Go-to-market and partners | | |

## Product and roadmap signals
| Date | Signal (release, pricing change, hiring, partnership) | Source | What it suggests |
|---|---|---|---|
| | | | |

## Pricing and packaging
[Model, tiers, published prices, discount patterns. Mark anything from deal hearsay as unverified.]

## Strengths and weaknesses (from buyers' point of view)
| Strengths | Evidence | Weaknesses | Evidence |
|---|---|---|---|
| | | | |

## Head to head
- Where they win against us (segments, situations):
- Where we win against them:
- Our win rate against them, last four quarters:

## AI claims check
| Claim they make | Verified? (Y/N/partly) | How verified |
|---|---|---|
| | | |

## Likely next move
[Prediction, with reasoning and confidence]

## Sources
[List with URLs and access dates]

# Battlecard · [Us] vs [Alternative] · [Segment]

**Owner:** [PMM]   **Last updated:** [Date]   **Review cadence:** monthly

## When you'll meet them
[Deal signals that this alternative is in play]

## Why we win (three points, each with proof)
1. [Point] · Proof: [customer, metric or demo]
2.
3.

## Their pitch, in their words
[Summary of how they position, from their own materials]

## Landmines to set (questions that expose real gaps)
- "[Question for the buyer]"
-

## Objection handling
| Objection | Response | Proof |
|---|---|---|
| | | |

## Quick dismisses
- [Misconception] → [one-line correction with source]

## Pricing guidance
[How they price, typical discounting, how to position our price]

## Customer proof
[References and logos cleared for use]

## Do not say
- [Claims we can't prove, including unverified AI or performance claims]
- Never disparage the competitor.

## Sources
[Each claim's source and verification date]

# Battlecard · [Us] vs doing nothing · [Segment]

**Owner:** [PMM]   **Last updated:** [Date]

## How the status quo shows up
[Signals: "not this quarter," endless evaluation, more stakeholders added late]

## Cost of doing nothing (buyer's numbers, not ours)
[What the job costs today in time, risk and money, with the buyer's own figures where possible]

## Judge the indecision
Questions to find out whether the buyer is stuck on fear of a wrong choice:
-

## Offer a recommendation
[The single starting configuration we recommend for this segment, and why]

## Limit the exploration
[What we will not ask them to evaluate now]

## Take risk off the table
[Pilot terms, reversibility, controls, approval gates, references]

## Proof
[Customers who moved from the same status quo, with outcomes they'll confirm]

# Win/loss analysis · [Product] · [Period]

**Sponsor:** [Executive]   **Interviewer:** [Neutral third party / internal non-sales]   **Owner:** [PM]

## Sample
| Segment | Wins | Losses to competitor | No decision | Churned | Interviews completed | Deals in period |
|---|---|---|---|---|---|---|
| | | | | | | |

Sample matches pipeline mix? [Yes / No: gaps are ...]

## Win rate trend
[By quarter and segment, from CRM]

## Reason taxonomy (stable codes)
Product gap · Price · Trust or risk · Timing · Relationship · Competitor strength · Status quo · Other

## Top reasons won
| Code | Count | Short buyer quote or paraphrase | Evidence beyond the interview |
|---|---|---|---|
| | | | |

## Top reasons lost (including no decision)
| Code | Count | Short buyer quote or paraphrase | Stated reason vs evidence |
|---|---|---|---|
| | | | |

## Competitor-specific patterns
-

## No-decision patterns
-

## Implications and actions
| Theme | Product | Positioning | Sales | Owner | Due |
|---|---|---|---|---|---|
| | | | | | |

## Coding quality
AI-assisted coding? [Y/N] · Sample checked by a person: [n of N] · Corrections made:

# Business case · [Initiative] · v[n] · [Date]

**Owner:** [PM]   **Finance partner:** [FP&A]   **Decision maker:** [Name]   **Decision needed by:** [Date]

## 1. Decision requested
[One sentence: what, how much, by when]

## 2. Problem and opportunity
[The customer problem, the evidence and the market size (link the sizing worksheet)]

## 3. Options considered
| Option | Cost | Expected benefit | Why not chosen |
|---|---|---|---|
| Do nothing | | | |
| Smaller option | | | |
| Recommended option | | | |

## 4. Assumptions register
| ID | Assumption | Value | Source or evidence | Confidence (H/M/L) | Owner | How we'll test it | Date |
|---|---|---|---|---|---|---|---|
| A1 | | | | | | | |

## 5. Financial summary (base case)
| Item | Year 1 | Year 2 | Year 3 |
|---|---|---|---|
| Revenue | | | |
| Cost of goods sold (including inference) | | | |
| Gross margin | | | |
| Investment (people, vendors, go-to-market) | | | |
| Net cash flow | | | |

NPV at finance's hurdle rate of [x%]: [value]   Payback: [months]   IRR (if finance uses it): [value]

## 6. Scenarios
| | Downside | Base | Upside |
|---|---|---|---|
| Story in one line | | | |
| Key assumption values | | | |
| NPV | | | |
| Payback | | | |

Outside view: reference class used [past launches], their actual-against-plan record [summary], and how the base case was adjusted.

## 7. Sensitivity (ranked)
| Rank | Assumption | Range tested | NPV swing |
|---|---|---|---|
| 1 | | | |
| 2 | | | |
| 3 | | | |

## 8. Risks and mitigations (from the premortem)
| Risk | Likelihood | Impact | Mitigation | Early signal |
|---|---|---|---|---|
| | | | | |

## 9. Milestones and kill criteria
| Milestone | Date | Metric and threshold | If missed |
|---|---|---|---|
| | | | |

## 10. Agreements with FP&A
Driver tree · Discount rate and horizon · Cost allocation · Revenue recognition

## 11. Ask
[People, money, time, and the first review date for actuals against this case]

# Platform map · [Product] · v[n] · [Date]

**Owner:** [PM]   **Reviewed with:** [partnerships lead, architect]   **Next review:** [Date]

## Ecosystem roles
| Role | Who (named parties or segments) | What they create or do | What they get today | Evidence |
|---|---|---|---|---|
| Owner | [us] | Architecture, access, rules | | |
| Providers | [resellers, MSPs, marketplaces] | Deliver access to customers | | |
| Producers | [partners, connector authors, customers who share content] | Create value units | | |
| Consumers | [users and teams] | Act on value units | | |

## Core interaction
On our platform, [producer] creates [value unit]; [filter] matches it to [consumer], who [acts on it].

- Value unit:
- Filter (how the right value unit reaches the right consumer):
- What a failed interaction looks like:

## Adjacent interactions (later)
1.
2.

## The four platform decisions, as they stand
| Decision | Today (deliberate or accidental?) | Proposed |
|---|---|---|
| Number of sides | | |
| Design (what we provide vs what participants provide) | | |
| Pricing structure (who pays, who is subsidized) | | |
| Governance rules | | |

## Platforms we depend on (we are a complement)
| Host platform | What it gives us | What it takes | What can change without our consent | Exit or multi-homing plan |
|---|---|---|---|---|
| | | | | |

## Platforms that could envelop us
| Platform | Shared customer relationship | Bundle they could offer | Early warning signal | Our defense (see moats, Chapter 16) |
|---|---|---|---|---|
| | | | | |

# Network effects assessment · [Product] · [Date]

**Owner:** [PM]   **Evidence sources:** [analytics, CRM, partner portal, marketplace data]

## Claimed effects
| # | Claimed effect (as stated in our materials) | NFX type | Sides involved | Mechanism: who gets more value when whom joins? | Evidence today (metric, value, source) | Density and clustering | Limits (asymptote, multi-homing, disintermediation) | Verdict |
|---|---|---|---|---|---|---|---|---|
| 1 | | | | | | | | |

Verdict options: real network effect / data-enabled learning / scale effect / switching cost / aspiration (no evidence yet).

## Data moat test (for any data claim)
| Question | Answer | Evidence |
|---|---|---|
| How much value does customer data add compared with the product without it? | | |
| Does the marginal value of more data stay high, or plateau? Where? | | |
| How fast does the data lose relevance? | | |
| Is the data proprietary, or available to competitors? | | |
| Are the improvements hard to imitate? | | |
| Does one customer's data improve the product for other customers? Are we allowed to use it that way? | | |

## Cold start position
- Stage (Cold Start Problem / Tipping Point / Escape Velocity / Hitting the Ceiling / The Moat):
- Atomic network (smallest stable network that grows on its own):
- Hard side (participants who create disproportionate value and are hardest to attract):
- Hard problem we solve for the hard side:

## Platform health
| Metric | Definition for our platform | Current value | Trend |
|---|---|---|---|
| Interaction failure | | | |
| Engagement | | | |
| Match quality | | | |
| Negative network effects (congestion, spam, misbehavior) | | | |

## What changes in our strategy and board story
[One paragraph: which effects we will build on, which we will stop claiming, what we will measure.]

# Ecosystem and partner strategy · [Product] · [Date]

**Owner:** [PM]   **Partner organization lead:** [Name]   **Decision maker:** [Name]

## Stance by platform
| Platform | Our role (host / complement / both) | Why | Commitment level (explore / invest / core) |
|---|---|---|---|
| Our own platform | Host | | |
| [Marketplace] | Complement | | |
| [AI assistant or agent runtime] | Complement | | |

## Partner segments and value exchange
| Segment | Examples | What they give us | What they get | Terms (rev share, co-sell, listing, certification) | Owner |
|---|---|---|---|---|---|
| Technology integrations | | | | | |
| Marketplaces and distributors | | | | | |
| Channel (resellers, MSPs) | | | | | |
| Systems integrators | | | | | |
| Agent and connector builders | | | | | |

## Openness plan
- Architecture (what outsiders can access now, and next):
- Governance (what say and share of value outsiders get now, and next):
- Sequence (what opens when, and the trigger for each step):

## Dependency and exit plan
| Host | Revenue or pipeline share through it | Biggest rule-change risk | Multi-homing or direct alternative |
|---|---|---|---|
| | | | |

## Metrics (three to five)
| Metric | Target | Review cadence |
|---|---|---|
| | | |

## Decisions and open questions
-

# Developer platform brief · [Product] · v[n] · [Date]

**Owner:** [PM]   **Engineering lead:** [Name]   **Developer relations:** [Name]

## Target builder (the hard side)
- Who they are (partner type, role, skill level):
- The hard problem we solve for them:
- What they use today instead:

## Job story
When [situation], I want to [motivation], so I can [expected outcome].

## Surfaces
| Surface | Purpose | Status | Audience |
|---|---|---|---|
| Public API | | | |
| SDKs | | | |
| MCP server (agent to tool) | | | |
| A2A agent and Agent Card (agent to agent) | | | |
| Sandbox and test data | | | |

## Access tiers
| Tier | Who qualifies | What they can do | Review required? |
|---|---|---|---|
| Open | | | |
| Certified partner | | | |
| Strategic | | | |

## Reward model
How builders share in the value they create: [listing, revenue share, co-sell, lead sharing, certification badge, marketplace placement].

## Versioning and deprecation
- Versioning scheme:
- Minimum deprecation notice: [period]
- How breaking changes are announced:
- Support window for old versions:

## Registry and marketplace listings
Where builders' work, and our own servers and agents, will be discoverable: [public registries, private enterprise registries, marketplaces].

## Success metrics
| Metric | Definition | Target |
|---|---|---|
| Time to first working integration | | |
| Active builders (shipped in last 90 days) | | |
| Third-party integrations used weekly | | |
| Share of customer value from third-party integrations | | |

## Risks and open questions
-

# Platform governance policy · [Platform] · v[n] · Effective [Date]

**Policy owner:** [Name]   **Approved by:** [product, security, legal]   **Next review:** [Date]

## Purpose and principles
[Two or three sentences: what the platform is for, and the balance it strikes between users' safety and builders' opportunity.]

## Scope
Who this applies to: [connector authors, agent builders, marketplace sellers, resellers].

## 1. Safety and security
- Least-privilege access: [scopes allowed by default; scopes needing review]
- Actions on customer systems: [which require human approval; which may run autonomously and under what customer allowlist]
- Audit logging: [what must be logged and retained]
- Data handling: [residency, retention, training use]
- Responsibility for third-party code and models inside a submission:

## 2. Performance and quality
- Certification criteria: [functional tests, accuracy thresholds, uptime]
- Quality filters: [how listings are ranked and matched]
- What happens when a submission stops working:

## 3. Business terms
- Fees and revenue share:
- Pricing and billing rules (including metering for usage-based pricing):
- Rules on steering customers off the platform:

## 4. Design and experience
- Required disclosures to users (what the integration does, what it can access):
- Branding rules:

## 5. Legal and compliance
- Regulatory obligations passed to participants (for AI features, see Chapter 33):
- Contract terms and liability:

## Review process
| Stage | Who reviews | Target time |
|---|---|---|
| Submission | | |
| Security review | | |
| Certification | | |

## Enforcement ladder
| Level | Trigger | Action | Notice given |
|---|---|---|---|
| 1. Warning | | | |
| 2. Suspension | | | |
| 3. Delisting | | | |
| 4. Removal from program | | | |

## Appeals
How a participant appeals, who decides and how fast.

## Changes to this policy
Minimum notice before a change takes effect: [period]. Where changes are announced: [channel]. Change log below.

| Version | Date | Change | Reason |
|---|---|---|---|
| | | | |

# Pricing and packaging proposal · [Product] · v[n] · [Date]

**Owner:** [PM]   **Finance partner:** [Name]   **Sales or deal desk partner:** [Name]   **Decision maker:** [Name]   **Decision needed by:** [Date]

## 1. Objective
What this pricing optimizes for: acquisition / revenue / margin; new logos / expansion. One paragraph on why now.

## 2. Diagnosis of current pricing
- Current model and value metric:
- Pocket price band by segment (from the discount report):
- Share of deals lost on price (last two quarters):
- Gross margin per unit of current value metric, and the trend:
- Monetizing Innovation failure we're closest to: feature shock / minivation / hidden gem / undead. Evidence:

## 3. Segments
| Segment | Needs | Willingness to pay (evidence) | Budget line that pays | Preferred way to pay |
|---|---|---|---|---|
| | | | | |

## 4. Value metric
Chosen metric: [unit]. Runner-up: [unit]. See the value metric assessment.

## 5. Model
Seat / usage / credits / outcome / hybrid. Structure: [platform fee, included allowance, metered layer, commit, minimum].

## 6. Packages
| | [Tier 1] | [Tier 2] | [Tier 3] |
|---|---|---|---|
| Designed for (segment) | | | |
| Leaders (why they buy this tier) | | | |
| Fillers | | | |
| Included allowance | | | |
| List price | | | |

Add-ons (narrow, intense demand): [name, price, who buys it]
Removed or moved (killers): [feature, reason]
Included in every tier on principle (for example, safety or compliance controls): [list]

## 7. Price points and evidence
| Price point | Research method | Sample | Result | Confidence |
|---|---|---|---|---|
| | | | | |

## 8. Unit economics
Cost per unit of value metric: [amount, date]. Gross margin at list: [%]. At typical discount: [%]. Margin floor: [%].

## 9. Outcome definition (if any)
Link to the outcome definition artifact.

## 10. Metering and spend controls
What's logged, what customers see, alerts, caps, overage policy, rollover.

## 11. Migration of existing customers
Accounts modeled: [n]. Bills up more than [x]%: [n]. Bills down more than [x]%: [n]. Grandfathering, notice and migration offers:

## 12. Discount policy and impact plan
Links to both. Kill or revise criteria in one line.

## 13. Decision
Approved / revise / rejected, by [name] on [date].

# Value metric assessment · [Product] · [Date]

Score each candidate High / Medium / Low on each test, with one line of evidence per score.

| Test | [Metric A] | [Metric B] | [Metric C] | [Metric D] |
|---|---|---|---|---|
| 1. Correlates with the value different customers get | | | | |
| 2. Shares in customer success; doesn't discourage adoption | | | | |
| 3. Lets customers start small and grow | | | | |
| 4. Grows over time for the average customer | | | | |
| 5. Feasible to monitor and meter accurately | | | | |
| 6. Predictable enough for procurement to budget | | | | |
| 7. Hard to dispute or game | | | | |
| Tracks our cost to serve | | | | |
| Fits the North Star metric | | | | |

Tests 1 to 5 follow Kyle Poyar's value metric criteria. Tests 6 and 7 are B2B additions.

## Behavior check
For each finalist: what will customers do to keep the bill down, and is that behavior good or bad for them and for us?

## Recommendation
Primary metric: [ ]. Predictability layer (if hybrid): [ ]. Why:

## What the product must build to meter it
[Events logged, data retained, customer-visible reporting]

# Willingness-to-pay interview guide · [Product or concept] · [Date]

**Interviewee:** [role; economic buyer preferred]   **Segment:** [ ]   **Length:** 45 minutes   **Interviewers:** [PM plus one]

## Rules
Don't name a price first. Don't pitch before you ask. Ask about current costs in their numbers. Never ask "what would you pay?" cold.

## 1. Context (10 min)
- "Walk me through the last time [problem] happened. What did it cost: hours, people, tools, penalties?"
- "What do you use or pay for today to deal with it?"

## 2. Value (10 min)
- Show the capability list. "If you could keep only three, which?" "Which could you live without?"

## 3. Metric (5 min)
- "How would you expect to pay for something like this: per user, per environment, per [unit of work], per outcome?"
- "What would make a bill for this feel unfair?"

## 4. Range (5 min, after showing the concept)
- "At what price would this seem so cheap you'd doubt it works?"
- "At what price would it feel like a bargain?"
- "At what price would it start to feel expensive, but still worth considering?"
- "At what price would it be too expensive to consider?"

## 5. Point check (5 min)
- "At [price] per [unit or year], would you buy?" Move up or down depending on the answer.

## 6. Budget and buying (5 min)
- "Which budget would this come from: software, services or headcount?"
- "Who approves it? At what amount does procurement get involved?"

## 7. Predictability (5 min)
- "Would you rather have a fixed commitment, a cap, or pay as you go? Why?"

## After the call
| Field | Answer |
|---|---|
| Current cost of the problem (their numbers) | |
| Top three capabilities | |
| Preferred metric; unfair-bill triggers | |
| Range: too cheap / bargain / expensive / too expensive | |
| Point check result | |
| Budget line and approver | |
| Commit, cap or pay-as-you-go | |
| Memorable quote (verbatim) | |

# Outcome definition · [Product] · v[n] · [Date]

**Owner:** [PM]   **Reviewed by:** finance, legal, customer success, [customer advisory board]

1. **Unit.** One [conversation / incident / workflow / document] counts once, however many steps it takes.
2. **Eligibility.** The conditions under which a unit can be billed: [what the product must have done; what the customer must have confirmed or not contested].
3. **Exclusions.** Never billed: [escalated to a human; reopened within [window]; actions rolled back; test and sandbox; duplicates; other].
4. **Verification.** How we decide: [evidence record, automated review, human confirmation]. What the customer can see of it:
5. **Evaluation window.** The outcome is final [time] after [event].
6. **Audit trail.** Every billed unit appears in [dashboard or export] with its evidence, within [time].
7. **Disputes and credits.** Customers can dispute within [days]. Upheld disputes are credited on the next invoice. Target dispute rate: under [n] per 1,000 billed units.
8. **Harm clause.** If our product causes or worsens the outcome it's paid for: [not billable; follow-on not billable; service credit of [amount]].
9. **Macro-outcomes we deliberately don't price,** because we don't control them: [list].

## Worked examples
| Scenario | Billable? | Why |
|---|---|---|
| | | |

# Price change impact plan · [Change] · [Date]

**Owner:** [PM]   **Analyst or harness owner:** [Name]   **Finance partner:** [Name]

## Hypothesis
We expect [change] to move [metric] by [amount] in [segment] within [time], because [reason].

## Break-even
- Contribution margin today: [%]
- For a cut: volume increase needed = cut ÷ (margin − cut) = [%]
- For a rise: volume loss we can absorb = rise ÷ (margin + rise) = [%]
- Is that volume change plausible? Evidence:

## Scope and rollout
New logos / renewals / expansions. Segments, regions and channels. Phased rollout or holdout: [design, and why it's fair and legal].

## Baseline
Period: [dates]. Known seasonality and quarter-end effects:

## Indicators
| Type | Metric | Baseline | Expected | Guardrail |
|---|---|---|---|---|
| Leading | Quote-to-close conversion | | | |
| Leading | Win rate | | | |
| Leading | Discount depth | | | |
| Leading | Sales cycle length | | | |
| Leading | Deals lost on price (share) | | | |
| Leading | Bill-shock tickets or disputes | | | |
| Lagging | ARR and gross margin | | | |
| Lagging | Net and gross revenue retention | | | |
| Lagging | Downgrades and churn reasons | | | |

## Confounders to check
[New competitor, sales compensation change, product release, large deals, macro events]

## Existing customers
Grandfathering rule: [ ]. Notice period: [ ]. Price protection: [ ]. Accounts needing a personal conversation: [list].

## Kill or revise criteria
We revise if [condition]. We roll back if [condition]. Decided by [name].

## Reviews
30 days: [date]. 90 days: [date]. 180 days: [date].

# Discount policy · [Product] · [Effective date]

**Owner:** [Deal desk lead]   **Product owner:** [PM]   **Finance owner:** [Name]

## Price book
| Item | List price | Floor | Notes |
|---|---|---|---|
| [Tier] | | | |
| [Value metric unit rate] | | | Discounted only with a volume commitment |

## Approval matrix
| Discount depth or term | Rep | Manager | Deal desk | Finance or CRO |
|---|---|---|---|---|
| Up to [x]% | ✓ | | | |
| [x] to [y]% | | ✓ | | |
| [y] to [z]% | | | ✓ | |
| Above [z]%, or any non-standard term | | | | ✓ |

## Give-get list (every discount buys something)
Multi-year term · prepayment · larger commitment · case study or publicity rights · auto-renewal · automatic annual increase · reference calls

## Rules
1. Discount the package or commitment, not the unit rate, unless volume is committed.
2. Introductory discounts expire at first renewal. Renewal uplift: [%].
3. Free pilot credits are capped at [amount] and expire after [days]. They count as discounts in the pocket price report.
4. Partner margin comes from a wholesale rate, not ad hoc discounts.
5. Quarter-end: deals above [x]% discount in the last [n] days of the quarter need [approver].

## Reporting
Monthly pocket price band by segment, tier and rep. Quarterly review with product, sales and finance. A tier discounted more than [x]% in most deals triggers a packaging review.

# AI pricing model comparison · [Product or AI capability] · [Date]

## Inputs
- What the buyer values, and whether it can be measured and attributed:
- Our cost per unit of work today, and its variability:
- How predictable the bill must be (procurement's view):
- Which budget pays: software / services / headcount:
- Our confidence in consistent performance (eval results):
- Can the customer audit the count?

## Comparison
| Criterion | Seat | Usage | Credits | Outcome | Hybrid |
|---|---|---|---|---|---|
| Unit | | | | | |
| Alignment with customer value | | | | | |
| Tracks our cost | | | | | |
| Bill predictability for the buyer | | | | | |
| Revenue as agents replace work | | | | | |
| Who carries performance risk | | | | | |
| Who carries model-cost risk | | | | | |
| Dispute risk | | | | | |
| Metering we'd need to build | | | | | |
| Gross margin at expected volume | | | | | |
| Competitor and market norm | | | | | |

## Spend controls required for the chosen model
Included allowance · alerts at [thresholds] · caps by [user, team, project] · overage policy (stop or finish and bill) · fallback behavior · rollover or expiry · burn-rate dashboard · plain-language unit names

## Recommendation
Model: [ ]. Why: [ ]. What would make us change it: [ ]. Review date: [ ].

# 7 Powers assessment · [Product] · [Date]

**Owner:** [PM]   **Reviewed with:** [names]   **Next review:** [date, one year out]

Rule: a Power counts only if both the benefit and the barrier cells are filled with evidence. Expect one or two to survive.

| Power | Status (present / emerging / absent) | Benefit in cash-flow terms (price, cost, capital) | Barrier: what stops a capable rival, and why won't they copy? | Evidence (with source) | Action |
|---|---|---|---|---|---|
| Scale economies | | | | | |
| Network economies | | | | | |
| Counter-positioning | | | | | |
| Switching costs | | | | | |
| Branding (including trust) | | | | | |
| Cornered resource | | | | | |
| Process power | | | | | |

## Claims that did not survive
| Claimed advantage | Why it fails (no benefit / no barrier / no evidence) | What it really is (feature, strength, scale effect) |
|---|---|---|
| | | |

## Timing
- Stage of the business (early, rapid growth, mature):
- Powers still available to build at this stage:
- Window closing on (for example, switching costs during rapid growth):

## The one or two Powers we will deepen
1. [Power] · Barrier-building roadmap items: [items] · Metric that shows the barrier widening: [metric]
2.

## Decision
Agreed by [name] on [date]. Logged in [decision log].

# Moat scorecard · [Product] · [Year]

Scoring: 0 = none, 1 = claimed but unproven, 2 = real with evidence, 3 = real, evidenced and hard to copy. Any score above 1 needs a source.

| Moat source | Score (0 to 3) | Evidence (source) | This year: widened / stable / narrowed | What would erase it | Leading indicator to watch |
|---|---|---|---|---|---|
| Proprietary data (exclusive, refreshed by use, in the hard tail) | | | | | |
| Proprietary context (what the agent can know that rivals can't) | | | | | |
| Outcome labels (which action actually worked) | | | | | |
| Workflow depth / system of record or action | | | | | |
| Switching costs (configuration, approvals, compliance evidence) | | | | | |
| Distribution and channel (who owns the user relationship) | | | | | |
| Trust and brand | | | | | |
| Ecosystem (partners, connectors, complements) | | | | | |
| Scale economics (including inference cost per outcome) | | | | | |
| Counter-positioning (business model rivals won't copy) | | | | | |
| Process power (eval and learning loop speed) | | | | | |
| Model access | 0 | Rivals can buy the same models | | | Price and quality of alternative models |

## Annual test
- Widened this year:
- Narrowed this year:
- Biggest surprise:

## Implications
- Stop defending:
- Start building:
- Pricing and margin effect:

# Disruption test · [Threat] · [Date]

**Threat:** [competitor, product or category]   **Source of signal:** [where we saw it]

| Question | Yes / No | Evidence |
|---|---|---|
| 1. Is it worse on the measures our customers use to judge us today? | | |
| 2. Is it cheaper or simpler, or does it serve people who don't buy from anyone today? | | |
| 3. Is it improving fast on the measures our mainstream customers care about? | | |
| 4. Is it attached to a business model we'd find unattractive to copy? | | |

## Classification
Sustaining / Low-end disruption / New-market disruption / Counter-positioning / Aggregator (taking the user relationship)

## Which of our customers are exposed first
[Segment, channel or persona]

## Response
- If sustaining: product, sales and pricing response:
- If disruptive: separate offer, unit or business model considered? [yes/no, why]
- Owner:
- Review date:

# Commoditization response plan · [Feature] · [Date]

**Owner:** [PM]   **Decision maker:** [name]   **Decide by:** [date]

## 1. The feature and the force
- Feature:
- Commoditizing force (model provider / platform bundle / open source / AI assistant / new entrant):
- Evidence that "good enough" alternatives exist (source):
- Share of revenue, usage or deals that depend on it today:

## 2. Product or complement?
Is this feature what customers pay us for, or something that makes the thing they pay for more valuable?
[Product / Complement], because:

## 3. Disruption check
Result of the disruption test (attach): [sustaining / disruptive / aggregator]

## 4. Options
| Option | What we'd do | Revenue effect | Cost effect | Risk | Fit with our Powers |
|---|---|---|---|---|---|
| Move up the stack (sell the outcome) | | | | | |
| Bundle into a system with fit | | | | | |
| Reprice (include it, or price on outcomes) | | | | | |
| Commoditize it ourselves (open it, make it standard) | | | | | |
| Harvest and exit | | | | | |

## 5. Decision
- Chosen response:
- What we stop doing:
- Customer and sales communication needed:
- Metrics to watch (three at most):
- Review date:

# Competitive threat monitor · [Product] · [Month]

**Drafted by:** AI harness from [connected sources]   **Validated by:** [PM]   **Reviewed with:** [product marketing, sales leader]

Rule: nothing enters the monitor without a cited source and a human check.

| Threat | Type (sustaining / low-end / new-market / counter-positioning / aggregator) | Signal observed | Source (link or record) | Moat row it attacks | Severity (H/M/L) | Trigger for action | Owner | Status |
|---|---|---|---|---|---|---|---|---|
| | | | | | | | | |

## Changes since last month
- New threats:
- Threats that grew:
- Threats that faded:

## Triggers hit this month
| Trigger | What happened | Action taken or proposed | Decision maker |
|---|---|---|---|
| | | | |

## Sources scanned
Win/loss notes · CRM opportunity notes · support tickets · call summaries · competitor release notes and pricing pages · partner feedback · analyst notes

# Decision question bank · [Product] · v[n] · [Date]

**Owner:** [PM]   **Reviewed with:** [analytics lead, product ops]   **Next review:** [Date]

One row per standing question. Keep the questions you ask every quarter here, with the evidence that answers them, so nobody reinvents them.

| # | Stage (Discover / Invest / Build / Launch / Grow / Price / Retire) | Decision | Question (with population, window, metric, comparison) | Quantitative evidence | Qualitative evidence | Report type | Answer that would change the decision | Owner | Verified question? (Y/N) |
|---|---|---|---|---|---|---|---|---|---|
| 1 | | | | | | | | | |
| 2 | | | | | | | | | |
| 3 | | | | | | | | | |

## Retired questions
| Question | Why retired (failed value test, vanity, decision no longer live) | Date |
|---|---|---|
| | | |

Rules: every question names a decision. Totals that only rise are rewritten as rates, per-account measures or cohort comparisons. A question marked "verified" has a reviewed definition and a known-good answer the harness can be checked against.

# Question brief · [Short name] · [Date]

**Owner:** [Name]   **Reviewer:** [Name]   **Answer needed by:** [Date]

## The decision
- Decision: [what we are choosing]
- Options: 1. [ ] 2. [ ] 3. [do nothing / keep current approach]
- Decision maker or forum: [ ]
- Decision date: [ ]
- Type: one-way door (Type 1) / two-way door (Type 2). Why: [ ]

## The question
[One sentence.]

## Why it matters
- What answer would change our decision: [ ]
- What we'll do if the answer is [A]: [ ]  If [B]: [ ]
- Confidence needed to act: [for example, "a clear direction across most comparison accounts"; roughly 70% of the information we'd like is enough for Type 2]

## Framing (PTMC)
- **Population:** [who or what counts; exclusions such as internal, trial or test tenants]
- **Time window:** [dates, time zone, partial periods in or out]
- **Metric definition:** [governed definition name, or numerator / denominator / unit / filters; link the metric definition card]
- **Comparison:** [prior period / control / matched accounts / segment / target]

## Evidence plan
| Evidence | Type (quant / qual) | Source or connector | Report type | Status |
|---|---|---|---|---|
| | | | | |

## Output requested
Format: [table, chart, one paragraph]. Show the definitions, filters, time window and record counts used. List assumptions and anything that would change the answer.

## Answer
- Result: [ ]
- Reconciled against: [known number or second method]
- Accounts behind the result we spoke to: [ ]
- Confidence: low / medium / high, because [ ]
- Effect on the decision: [ ]

# Metric definition card · [Metric name]

**Owner:** [Name]   **Last reviewed:** [Date]   **Status:** Draft / Agreed / Governed (in semantic layer)

## Meaning
- In plain language: [one sentence a new hire would understand]
- Decision it serves: [ ]
- Good direction: up / down   **Target or threshold:** [ ]

## Formula
- Numerator: [ ]
- Denominator: [ ]
- Unit: [percent, count per account per week, currency]

## Scope
- Population: [ ]
- Exclusions: [internal, test, trial tenants; other]
- Time grain and time zone: [ ]
- Unit of analysis: [user / account / environment / incident]

## Source of truth
- Governed definition: [name in the semantic layer or metrics catalog, or "none yet"]
- Underlying sources: [systems, not tables]
- Verified question and known-good answer: [a question with an answer the team has checked, for testing harness answers]

## Integrity
- Paired guardrail metric: [the harm this target could cause, measured]
- Gaming risks: [how people or systems could move the number without moving the outcome]
- Known caveats: [seasonality, data gaps, definition changes and their dates]

## Change log
| Date | Change | Approved by |
|---|---|---|
| | | |

# Decision memo · [Decision] · [Date]

**Author:** [PM]   **Decision maker:** [Name or forum]   **Type:** one-way door / two-way door   **Review date:** [ ]

## Recommendation
[Two or three sentences: what we should do, and the single strongest reason.]

## Frame
- The problem we are solving: [ ]
- In scope: [ ]   Out of scope: [ ]
- What happens if we do nothing: [ ]

## Options considered
| Option | What it means | Main upside | Main risk |
|---|---|---|---|
| 1. | | | |
| 2. | | | |
| 3. Do nothing / keep current approach | | | |

## Evidence
- What we know (with question briefs linked): [ ]
- How confident we are and why: [ ]
- What we don't know, and why we're deciding anyway: [ ]

## Values and trade-offs
[The criteria we weighed and which mattered most.]

## Reasoning
[Why this option beats the others, in prose.]

## Pre-mortem and bias check
- It's a year from now and this failed. The most likely reasons: [ ]
- Have we fallen in love with this option? Were dissenting views and credible alternatives explored? Where did the key numbers come from? Is the worst case bad enough? [answers]

## Reversibility and kill criteria
- How we could reverse or limit it: [toggle, staged rollout, contract terms]
- Kill or pause criteria, set now: [ ]

## Commitment
- Owner and resources: [ ]
- Who disagreed and committed, and on what: [ ]

## Post-decision review (complete on the review date)
- What happened: [ ]
- Was the process sound given what we knew then? [ ]
- What did we learn about the world? [ ]
- Changes to our question bank or metric cards: [ ]

# Vanity question rewrite · [Team or review] · [Date]

Run every question in a review, dashboard or deck through these five tests. Rewrite any that fail.

| # | Original question | Only goes up? | Could change a decision? | Has a comparison? | Traceable to accounts? | Gameable without a guardrail? | Rewritten question | Decision it informs |
|---|---|---|---|---|---|---|---|---|
| 1 | | Y/N | Y/N | Y/N | Y/N | Y/N | | |
| 2 | | | | | | | | |
| 3 | | | | | | | | |

A question passes when it can change a decision, includes a comparison, traces to named accounts and has a guardrail if it will become a target. Totals that only rise become rates, per-account measures or cohort comparisons.

# Decision review · [Period] · [Date]

**Facilitator:** [Name]   **Decisions reviewed:** [number]

For each decision whose review date has passed, judge the process and the outcome separately.

| Decision | Date made | Type (1 / 2) | Expected outcome and confidence | Actual outcome | Process quality (frame, alternatives, information, trade-offs, reasoning, commitment: weakest link) | Decision or dice? | Lesson | Change to question bank |
|---|---|---|---|---|---|---|---|---|
| | | | | | | | | |

## Patterns
- Two-way doors that waited too long: [ ]
- One-way doors decided too lightly: [ ]
- Questions that kept failing the value test: [ ]

# Data source inventory · [Product] · v[n] · [Date]

**Owner:** [PM]   **Reviewed with:** [data, RevOps, finance, support, applied AI owners]   **Next review:** [Date, at least quarterly]

## Sources
| Source | System of record | Owner (named person and team) | Grain (event, account, opportunity, invoice, ticket, trace) | Freshness | Account identifier | Can tell you | Can't tell you | Known traps | Harness access (governed or raw; connector or MCP) | Contract or SLA? |
|---|---|---|---|---|---|---|---|---|---|---|
| Product telemetry | | | | | | | | | | |
| CRM | | | | | | | | | | |
| Billing and subscription | | | | | | | | | | |
| Support tickets | | | | | | | | | | |
| Surveys and NPS | | | | | | | | | | |
| Sales and customer calls | | | | | | | | | | |
| Product reviews and communities | | | | | | | | | | |
| Market and competitive data | | | | | | | | | | |
| Finance and FP&A | | | | | | | | | | |
| AI traces and evals | | | | | | | | | | |

## Account mapping
| Source | Identifier used | Maps to the master account by | Known breaks (partners, subsidiaries, test tenants, merges) | Who fixes it |
|---|---|---|---|---|
| | | | | |

## Sensitive data
| Source | Contains customer content or personal data? | Access policy | Retention | Approved tools for AI use |
|---|---|---|---|---|
| | | | | |

## Open requests to source owners
| Request (freshness, field, definition, join key) | Owner | Needed for which report | Due |
|---|---|---|---|
| | | | |

# Report catalog · [Product or portfolio] · [Date]

**Owner:** [Product leader]   **Rule:** every recurring report appears here, or it gets archived.

| # | Report | Questions it must answer | Decision it feeds | Cadence | Audience | Owner | Primary sources | Key metrics (dictionary IDs) | Status (live / rebuild / planned / deferred) |
|---|---|---|---|---|---|---|---|---|---|
| 1 | Weekly metrics review | What changed? Is it exceptional? Why? What are we doing? | Weekly priorities and escalations | Weekly | | | | | |
| 2 | Product health | Is the product working for customers? | Reliability investment, release holds | Daily view, weekly review | | | | | |
| 3 | Funnel and activation | Where do new accounts stall before first value? | Onboarding investment | Weekly, monthly deep dive | | | | | |
| 4 | Retention and NRR | Which cohorts expand, contract or churn, and why? | Retention bets, packaging | Monthly, quarterly | | | | | |
| 5 | Feature adoption | What's used, by whom, how broadly and deeply? What should we retire? | Invest, fix or retire | Monthly; 30, 60, 90 days after launch | | | | | |
| 6 | Customer health | Which accounts are at risk or ready to expand? | Account plans, escalations | Weekly list, monthly trend | | | | | |
| 7 | Pipeline influence | Which capabilities show up in won and lost deals? Which gaps block deals? | Roadmap, competitive response | Monthly, quarterly | | | | | |
| 8 | Pricing and discount | What do customers actually pay? Where does price leak? | Pricing and packaging changes | Monthly, quarterly | | | | | |
| 9 | Support trends | Top themes by volume and ARR affected; what's new? | Defect priorities, docs, deflection | Weekly digest, monthly | | | | | |
| 10 | AI quality and cost | Is the AI getting better or worse? What does a successful outcome cost? | Release gates, model choice, pricing | Weekly; every model or prompt change | | | | | |
| 11 | QBR pack (internal and customer) | Are bets on track? What value did this customer get? | Quarterly priorities; renewals | Quarterly | | | | | |
| 12 | Portfolio review | Where is investment against return across the portfolio? | Grow, sustain, harvest, retire | Quarterly or twice a year | | | | | |

## Archived reports
| Report | Replaced by | Archived on | Pointer left? |
|---|---|---|---|
| | | | |

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

**Facilitator:** [name]   **Data as of:** [timestamp]   **Definitions:** metric dictionary v[n]   **Trust check:** passed / failed on [source]

## Rules
- Every metric is shown. Owners speak only to exceptional variation or a missed target.
- "Nothing to see here" is a complete answer for a normal week.
- "I don't know yet" is allowed. The follow-up gets logged with an owner and a date.
- No improvised causes.

## 1. Controllable inputs
| Metric (dictionary ID) | Owner | This week | Trailing 4 weeks | Same week last year | Target | Exception? | Comment |
|---|---|---|---|---|---|---|---|
| | | | | | | Y / N | |

## 2. Outputs
| Metric (dictionary ID) | Owner | This week | Trailing 4 weeks | Trailing 12 months | Target | Exception? | Comment |
|---|---|---|---|---|---|---|---|
| North Star: | | | | | | | |
| | | | | | | | |

## 3. Financials
| Metric | Owner | Latest | Plan | Variance | Exception? | Comment |
|---|---|---|---|---|---|---|
| | | | | | | |

## Accounts behind the moves
For each exception, list the accounts that drove it, with ARR and segment.

## Customer reality check
Two or three verbatims (tickets, calls, traces) that show what the numbers stand for this week.

## Follow-ups
| # | Question | Owner | Due | Answered? |
|---|---|---|---|---|
| | | | | |

## Metric set changes proposed
Add / drop / redefine, with reason. (Change only after four weeks of evidence.)

# QBR metrics pack · [Product] · Q[n] [Year]

**Version:** Internal (executive product review) / Customer ([Account name])   **Definitions:** metric dictionary v[n]   **Data as of:** [Date]

## A. Internal product QBR
### Summary
Three sentences: where we are against goals, the biggest change this quarter, the decision we need.

### Goals and bets
| Goal or bet | Target | Result | Status (on track / at risk / missed / killed) | Evidence |
|---|---|---|---|---|
| | | | | |

### Output metrics (quarter and trailing four quarters)
| Metric | Q-3 | Q-2 | Q-1 | This Q | Target | Comment |
|---|---|---|---|---|---|---|
| North Star | | | | | | |
| NRR (state window and price treatment) | | | | | | |
| GRR | | | | | | |
| ARR | | | | | | |
| Gross margin | | | | | | |
| AI cost per successful outcome (AI products) | | | | | | |

### What we learned
Top findings from adoption, support, pipeline and pricing reports.

### Decisions requested
1.
2.

## B. Customer QBR
### Executive summary
### The outcomes you bought us for
| Original buying reason | Metric | Baseline | This quarter | Trend |
|---|---|---|---|---|
| | | | | |

### Adoption and time to value
### ROI (method stated; customer's own numbers where possible)
### Progress against last quarter's goals
### Benchmark (only if the comparison group is defined)
### Health and risks
### Actions
| Action | Owner (ours / theirs) | Date |
|---|---|---|
| | | |

### Next QBR: [Date]

# Metric: [Name] · ID [metric-id] · v[n]

**Owner (accountable):** [name]   **Steward (maintains logic):** [name]   **Status:** Draft / Approved / Deprecated

## Definition
One sentence a customer could read.

## Formula in words
- Numerator:
- Denominator:
- Filters and exclusions (test tenants, internal accounts, trials):
- Deduplication rule:

## Grain and time
- Grain (event, user, account):
- Time window (weekly, trailing 12 months, snapshot date):
- Fiscal or calendar:

## Allowed segments
[Tier, region, channel, cohort, product line]

## Source
- Source of record:
- Semantic layer name:
- Freshness:

## Type
Input / Output · North Star / Health / Guardrail / Financial · Billing unit? Y / N (if Y, finance co-owns)

## Targets and thresholds
- Target:
- Exceptional variation means:

## Caveats
What this metric can't tell you, and how it could be gamed.

## Decisions it informs
[Reports and decisions]

## Change log
| Version | Date | What changed | Why | Approved by | Charts that need a marker |
|---|---|---|---|---|---|
| | | | | | |

# Data trust check · [Report or analysis] · [Date]

Run before any number drives a decision. Record failures before the answer, not after.

| Check | Question | Result | Action if failed |
|---|---|---|---|
| Freshness | When was each source last updated? Is that later than the decision needs? | | |
| Quality | Are null, duplicate or out-of-range rates unusual? | | |
| Volume | Did event or row counts move outside the normal range? | | |
| Schema | Did any field, event name or definition change in the last 30 days? | | |
| Lineage | Which upstream sources feed this number? Did any have a problem? | | |
| Definition | Which dictionary entry and version was used? | | |
| Denominator | What's the base, and how many accounts does it contain? | | |
| Hand check | Does one named account reconcile across sources? | | |

**Verdict:** Trust / Trust with caveats (list) / Don't use yet

# Source and connector inventory · [Product area] · [Date]

**Owner:** [PM]   **Reviewed with:** [data owner, security reviewer]   **Next review:** [Date]

| Source system | Category (analytics / warehouse / metrics layer / CRM / ticketing and docs / chat / files) | Access route (approved connector / export / none) | On approved list or registry? | Read-only tools available? | Write or send tools to switch off | Highest data tier (public / internal / confidential / restricted) | Region | Data owner | Freshness |
|---|---|---|---|---|---|---|---|---|---|
| | | | | | | | | | |

## Gaps
- Sources we need but can't reach through an approved route:
- Metrics that exist in dashboards but not in the metrics layer:

## Trifecta check
Sources holding attacker-writable text (tickets, chat, email, web): [list]. These are never combined in one session with tools that can send data out.

# Data access request · [Product area] · [Date]

**Requester:** [name, role]   **Approvers:** [data owner] · [security or compliance reviewer]

## Purpose
The decision or recurring review this access supports, in one or two sentences:

## Harness and workspace
- Harness and plan (company-approved enterprise workspace only):
- Project or workspace where the data will be used:

## Sources and scopes
| Source | Connector or export | Read-only scope requested (named, no wildcards) | Write or send tools disabled? |
|---|---|---|---|
| | | | Yes |

## Fields and minimization
| Field | Data tier | Why it's needed | Aggregation level (account / segment / tier) | Masked or pseudonymized? |
|---|---|---|---|---|
| | | | | |

Fields explicitly excluded (personal data, free text, contract terms, credentials):

## Controls
- Audit logging confirmed: Yes / No
- Data residency requirement (for example EU data stays in EU region):
- Retention and deletion of any exports: [period, location, who deletes]
- Step-up rule: any write or broader scope needs a new request.

## Duration
Access starts [date] and expires [date]. Review on [date].

## Approval
| Approver | Decision | Conditions | Date |
|---|---|---|---|
| | | | |

# Context pack · [Product area] · v[n] · [Date]

**Owner:** [PM]   **Loaded into:** [project or workspace name]   **Last reconciled:** [Date]

## 1. Purpose
The decisions and recurring reviews this pack supports:

## 2. Product 360 summary (one page)
Vision, target personas, North Star, input metrics, current strategy and bets, what's out of scope.

## 3. Metric dictionary
| Metric | Plain-language definition | Grain (per incident, per account, per user) | Owner | Source (connector, metrics layer name) | Time zone and period convention | Known caveats | Canonical value, last complete period |
|---|---|---|---|---|---|---|---|
| | | | | | | | |

## 4. Segment definitions
| Segment | Rule | Count today | Notes |
|---|---|---|---|
| | | | |

## 5. Source map
| Question type | Best source | Freshness | Use live or frozen? |
|---|---|---|---|
| | | | |

## 6. Data rules
- Highest data tier allowed in this project:
- Never pull: [personal data, free text, contract terms]
- Default aggregation level:
- Session rule: read-only tools only; write, send and web tools off.

## 7. Known data incidents and gaps
| Date | What changed (tracking change, migration, outage, definition change) | Effect on metrics |
|---|---|---|
| | | |

## 8. House style for reports
Answer first. Every number carries source, window and timestamp. Charts: one message each, units and window labeled, events annotated, bars start at zero. No causal language without causal evidence.

## 9. Glossary
| Term | Meaning here |
|---|---|
| | |

# Analysis request brief · [Short title] · [Date]

**Owner:** [PM]   **Decision maker:** [name]   **Decision needed by:** [date]

## Question (one sentence)

## Decision it informs
What will we do differently depending on the answer? What answer would change the decision?

## Audience
Who will read the result, and what they already believe:

## Question type
Describe / Diagnose / Compare / Forecast / Segment / Synthesize

## Scope
- Metrics (link to metric dictionary entries):
- Time window: [start date] to [end date], [time zone], complete periods only
- Segments:
- Sources allowed:
- Sources excluded:

## Known caveats
Tracking changes, migrations, incidents in the window:

## Output
Table / chart / one-page report / decision memo. Format notes:

## Verification depth
- Exploratory: reconcile, method, time window.
- Decision-grade: full checklist.
- Board, pricing or forecast: full checklist plus sign-off from [data owner or analyst].

# Verification checklist · [Analysis title] · [Date]

**Depth required:** Exploratory / Decision-grade / Board or pricing   **Verified by:** [name]   **Sign-off (if required):** [name, date]

| # | Check | How | Result (pass / fail / n.a.) | Notes |
|---|---|---|---|---|
| 1 | Reconcile to source | A headline number matches the system of record or the canonical value in the context pack | | |
| 2 | Method shown | Query, filters, joins and window explained in plain language; steps match the question | | |
| 3 | Spot-check | Three records traced from source to final number | | |
| 4 | Sanity bounds | Rates within 0 to 100%; segments sum to total; change from last published value explained | | |
| 5 | Time window | Exact start and end; time zone; complete periods; fiscal or calendar; late-arriving data | | |
| 6 | Definitions | Metric names, grain and deduplication match the dictionary | | |
| 7 | Denominator and mix | No averages of averages; segment split checked for reversal; churned or migrated accounts included | | |
| 8 | Run twice | Fresh session, same brief, same numbers within tolerance | | |
| 9 | Provenance | Every reported number carries source, window and timestamp | | |
| 10 | Stakes sign-off | Required sign-off obtained | | |

Exploratory depth requires checks 1, 2 and 5. Decision-grade requires 1 to 9. Board, pricing or forecast requires all ten.

## Failures found and fixes
| Check | What was wrong | Fix (prompt change, context pack update) |
|---|---|---|
| | | |

## Saved evidence
Method: [link]   Frozen dataset or export: [link]   Timestamp:

# Report review · [Report title] · [Date]

**Reviewer:** [name]   **Audience:** [who]   **Analysis verified on:** [date, checklist link]

| # | Question | Yes / No | Fix |
|---|---|---|---|
| 1 | Does the headline answer the question in the brief, in one sentence? | | |
| 2 | Is every number traceable to the verified analysis, with source, window and timestamp? | | |
| 3 | Has any number, quote or claim appeared that isn't in the analysis? | | |
| 4 | Are causal words ("drove", "caused", "because") supported by causal evidence? | | |
| 5 | Are caveats proportional: neither buried nor overwhelming? | | |
| 6 | Is each chart honest: right type for the comparison, one message, bars from zero, units and window labeled, events annotated? | | |
| 7 | Is the decision request explicit, with options and an owner? | | |
| 8 | Have personal data and customer names been removed or approved for this audience? | | |
| 9 | Would the reader reach the same conclusion from the evidence alone? | | |

## Decision record
- Decision:
- Confidence (high / medium / low) and why:
- Threshold that would change it:
- Owner and review date:
- Logged at: [decision log link]

# Innovation placemat · [Bet name] · v[n] · [Date]

**Owner:** [PM]   **Executive champion:** [Name, title]   **Status:** Draft / Signed / In gate review / Scaled / Stopped
**Portfolio band:** Core / Adjacent / Transformational   **Horizon:** 1 / 2 / 3

## 1. Strategic intent
- Corporate goal served (quoted from [strategy document, date]): "[goal]"
- Innovation thesis: Because the company is pursuing [corporate goal], we will innovate in [band and types] for [customers], measured by [outcome], funded at [target mix or amount].

## 2. Where we will play
- Ambition matrix cell: [where to play] × [how to win]
- Innovation types used (Ten Types): [e.g. profit model, network, product performance]
- Sustaining or disruptive? [and for which customers]

## 3. Customer and job
- Who: [personas and segment]
- Job and problem: [job story]
- Evidence we already hold: [interviews, data, pilots, with links]

## 4. Bets and hypotheses (ranked by risk)
1. [Assumption] · Type: desirability / viability / feasibility / adoption / organizational / regulatory / ecosystem · Evidence today: strong / some / none
2.
3.

## 5. Goals
| Element | Statement | Baseline | Target | Date | Source |
|---|---|---|---|---|---|
| Outcome goal | | | | | |
| Leading indicator | | | | | |
| Guardrail | | | must not fall below | | |
| Learning goal (this stage) | [assumption] confirmed or refuted with [evidence] | | | | |

## 6. Resources and horizon
- People: [roles and FTE]
- Money: [amount this tranche]
- Time box: [start to end]
- Funded from: [band and budget owner]

## 7. Executive champion
- Name and title:
- Why it matters to them: [their goal or metric]
- Decision rights: [what they decide alone]
- Cadence: [monthly check-in, quarterly gate]

## 8. Top risks and mitigations (from the risk register)
| # | Risk | Mitigation | Owner | Kill or pivot trigger |
|---|---|---|---|---|
| 1 | | | | |
| 2 | | | | |
| 3 | | | | |
| 4 | | | | |
| 5 | | | | |

## 9. Milestones and stage gates
| Gate | Date | Evidence required | Funding released | Decision options |
|---|---|---|---|---|
| Gate 1 | | | | Continue / Pivot / Stop |
| Gate 2 | | | | Scale / Pivot / Stop |

## Signatures
Team: [PM] [date]   Champion: [name] [date]

## AI disclosure
Sections drafted with AI: [list]. Every number verified against source by [name] on [date].

# Innovation ambition matrix · [Product line or portfolio] · [Quarter]

**Owner:** [PM or portfolio lead]   **Target mix agreed with:** [champion] on [date]

## Grid (list each bet in its cell)
| How to win ↓ / Where to play → | Existing customers and markets | Adjacent customers and markets | New customers and markets |
|---|---|---|---|
| New products and assets | Adjacent: | Transformational: | Transformational: |
| Incremental products and assets | Core: | Adjacent: | Transformational: |
| Existing products and assets | Core: | Core: | Adjacent: |

Band boundaries vary by company; agree them with your champion and keep them stable between quarters.

## Bet list
| Bet | Cell | Band | Horizon (1/2/3) | Ten Types used | People (FTE) | Spend | Placemat link |
|---|---|---|---|---|---|---|---|
| | | | | | | | |

## Mix
| Band | Current share of effort | Target share | Gap | Action to close the gap |
|---|---|---|---|---|
| Core | | | | |
| Adjacent | | | | |
| Transformational | | | | |

## Notes
- What drives the current mix (e.g. a migration, an escalation, a commitment):
- Why the target mix fits our industry and position (not copied from 70-20-10):
- Bets moved between bands since last quarter, and why:

# Executive champion brief · [Bet name] · [Date]

**To:** [Executive name, title]   **From:** [PM]   **Decision needed by:** [date]

## The ask (one paragraph)
We are asking you to champion [bet]. Specifically: [decision], [money], [people], [air cover on a named conflict], by [date].

## Why it matters to you
This bet moves [the executive's goal or metric] by [expected effect, with confidence level]. If it works, [what changes for their organization].

## What we have learned so far
- [Evidence 1, with source]
- [Evidence 2, with source]
- What we do not yet know: [riskiest assumption]

## What we need you to do
1. [Visible behavior, e.g. open the quarterly gate review]
2. [Blocker to remove, e.g. agree a pilot exception with sales operations]
3. [Coalition move, e.g. bring [peer executive] on as co-sponsor]

## What we are not asking for
- No solution design or scope changes without a trade-off discussion.
- [Anything else out of scope]

## Decision rights and escalation
- You decide: [gate outcomes, budget release, kill]
- The team decides: [scope, sequencing, experiments]
- Escalation path for conflicts with the core business: [name, forum]

## Cadence
Monthly 30-minute check-in; quarterly gate review; ad hoc escalations within [time].

## Kill and exit criteria (agreed now)
We will stop or pivot if [trigger 1], [trigger 2] or [trigger 3]. The decision is yours; the evidence will come from [source].

## Attachments
Innovation placemat v[n]; innovation risk register; ambition matrix for [portfolio].

# Innovation risk register · [Bet name] · [Date]

**Owner:** [PM]   **Reviewed with:** [champion, security, finance]   **Review cadence:** monthly and at each stage gate

Categories: DES = desirability, VIA = viability, FEA = feasibility, ADO = adoption and change, ORG = organizational, REG = regulatory and trust, ECO = ecosystem and dependency.
Score = likelihood (1 to 5) × impact (1 to 5).

| ID | Risk statement (If [cause], then [effect] on [goal]) | Category | Likelihood | Impact | Score | Leading signal to watch | Mitigation | Owner | Kill or pivot trigger | Status | Last reviewed |
|---|---|---|---|---|---|---|---|---|---|---|---|
| R1 | | | | | | | | | | Open | |
| R2 | | | | | | | | | | | |
| R3 | | | | | | | | | | | |

## AI rows (map to NIST AI RMF functions)
| ID | Risk | Govern (policy, accountability) | Map (context, impact) | Measure (evals, monitoring) | Manage (response, controls) |
|---|---|---|---|---|---|
| | | | | | |

## Link to the placemat
The top five risks by score appear in box 8 of the placemat. Riskiest assumptions in box 4 that are not in this register: [list, or "none"].

## Changes since last review
| Date | Risk | Change | Evidence |
|---|---|---|---|
| | | | |

# Ten types scan · [Product or bet] · [Date]

**Purpose:** widen the option set beyond product performance before choosing a bet.

| Category | Type | What we do today | Candidate move 1 | Candidate move 2 | Right to win? (Y/N, why) |
|---|---|---|---|---|---|
| Configuration | Profit model | | | | |
| Configuration | Network | | | | |
| Configuration | Structure | | | | |
| Configuration | Process | | | | |
| Offering | Product performance | | | | |
| Offering | Product system | | | | |
| Experience | Service | | | | |
| Experience | Channel | | | | |
| Experience | Brand | | | | |
| Experience | Customer engagement | | | | |

## Disruption lens
- Customers we overserve:
- Cheaper or simpler alternatives that could serve them (low-end):
- Non-customers who could now be served (new-market):
- Our response: defend / serve with a lighter offer / let go, and why

## Combinations worth testing
| Combination of types | Why they reinforce each other | Day's screen: Real? Win? Worth it? |
|---|---|---|
| | | |

# Innovation goal set · [Bet name] · Stage: [discovery / pilot / scale]

## Outcome goal (SMART)
By [date], [segment] will [behavior or outcome] from [baseline] to [target], measured by [source]. Owner: [name].

## Leading indicator
[Metric that moves before the outcome], reviewed [weekly / monthly]. Expected direction: [up / down].

## Guardrails
- [Metric] must not fall below [threshold].
- [Metric] must not rise above [threshold].

## Learning goal for this stage
[Assumption] will be confirmed or refuted by [date], using [experiment or evidence]. Confirmed means [result]. Refuted means [result].

## Gaming check
If the team optimized only the outcome goal, what could go wrong? [answer]. Which guardrail prevents it? [answer].

## Stage logic
Early stage: the learning goal leads. Pilot: learning goal and leading indicator lead. Scale: the outcome goal leads. Guardrails apply at every stage.

# Experiment card · [Experiment name] · [ID] · [Date]

**Owner:** [PM]   **Decider:** [Name]   **Linked bet or opportunity:** [Link]   **Status:** Designed / Running / Done

## Riskiest assumption
[One assumption from the assumption map]
Type: desirability / feasibility / viability / adoptability (buying group, security, procurement)

## Test card (complete before the test starts)
- We believe that: [assumption]
- To verify that, we will: [experiment type, audience, number of customers, duration]
- And measure: [metric or observable behavior]
- We are right if: [threshold, written before any data arrives]

## Cost and evidence
- Cost (people, money, customer time):
- Time to result:
- Evidence strength expected: weak / medium / strong, and why
- What decision this evidence will inform:

## AI disclosure
- Generated by the AI harness: [prototype / analysis / draft materials]
- From real customers: [sessions, behavior, signatures]
- Synthetic output used as evidence: none (synthetic output may only prepare the test)

## Learning card (complete after the test)
- We believed that:
- We observed: [result against the threshold, with links to evidence]
- From that we learned:
- Therefore we will: persevere / pivot (type) / run next test / stop
- Assumption status: right / wrong / still unclear

# MVP plan · [Product or bet] · [Date]

**Owner:** [PM]   **Decider:** [Name]   **Time box:** [Start] to [End]

## What we need to learn
- Hypothesis under test:
- Leap-of-faith assumptions: value hypothesis: [ ]; growth or buying-process hypothesis: [ ]
- The decision this MVP informs:

## MVP type and why
Smoke test or fake door / Explainer video / Concierge / Wizard of Oz / Single-feature / Piecemeal / Presale or letter of intent
Why this is the cheapest route to evidence strong enough for the decision:

## Who sees it
| Segment or persona | Number | How recruited | Consent and contract owner informed |
|---|---|---|---|
| | | | |

## Data and security
- Customer data used: none / synthetic only / real (security review reference: [ ])
- What is faked or manual, and who knows:

## Thresholds (set before launch)
- Success: [metric and threshold]
- Kill: [metric and threshold]
- Ambiguous result: [what we'll do]

## What we will deliberately not build
-
-

## After the decision
Destroy / harden and fold into the roadmap / hand to another team. Owner of the clean-up:

# Innovation accounting dashboard · [Bet] · Week of [Date]

**Owner:** [PM]   **Next pivot-or-persevere review:** [Date]

## Milestone status
- [ ] Baseline established (date and source)
- [ ] Tuning the engine (experiments since baseline: [n])
- [ ] Pivot-or-persevere decision due: [date]

## Leading indicators (by cohort, weekly)
| Indicator | Why it's actionable | Cohort | Baseline | Current | Target | Trend |
|---|---|---|---|---|---|---|
| | | | | | | |

## Learning velocity
| Measure | This cycle | Last cycle |
|---|---|---|
| Experiments completed | | |
| Assumptions validated | | |
| Assumptions invalidated | | |
| Still unclear | | |
| Median days from hypothesis to decision | | |
| Cost per validated learning (people-weeks) | | |

## Viability
- Cost per successful outcome (include inference cost for AI products):
- Evidence of willingness to pay (letters of intent, paid pilots):

## Vanity metrics deliberately excluded
- [Metric]: excluded because [it rises regardless of what we change]
-

## What changed our mind this week
[One paragraph, with links to learning cards]

# Design sprint plan · [Challenge] · [Dates]

**Decider:** [Name]   **Facilitator:** [Name]   **Team (seven or fewer):** [Names and roles]

## Monday: Map
- Long-term goal:
- Sprint questions (what could make us fail?):
  1.
  2.
  3.
- Experts to interview and their slots:
- Target customer and moment on the map:

## Tuesday: Sketch
- Existing ideas to remix (competitors, other teams, other industries):
- Recruiting started: [personas, numbers, screener]

## Wednesday: Decide
- Decision method:
- Storyboard owner:

## Thursday: Prototype
- Fidelity and tool (AI-built allowed):
- What is faked (label on screen):
- Data used: fabricated only, no production data
- Interview script owner:

## Friday: Test
| Persona | Sessions (five per persona) | Interviewer | Observers |
|---|---|---|---|
| | | | |

## Scorecard
| Sprint question | Session 1 | 2 | 3 | 4 | 5 | Pattern |
|---|---|---|---|---|---|---|
| | | | | | | |

## Decision and next experiment
[What the Decider decided, and the experiment card it produced]

# Pivot-or-persevere review · [Bet] · [Date]

**Cadence:** every [6 to 8] weeks or once per cycle   **Decider:** [Name]
**Attendees:** product trio, Decider, finance partner, [others]

## Evidence summary
- Dashboard link and milestone status:
- Experiments since last review, with learning cards:
- What moved, and why we think so:
- What didn't move:

## Warning signs
- Are we solving an important problem? Evidence:
- Are early adopters actually adopting? Evidence:
- Does the product deliver what it promises? Evidence:
- Is the team chronically frustrated, with only modest gains from tuning?

## Options
| Option | Pivot type (if any) | What we keep | What changes | Cost | Evidence for |
|---|---|---|---|---|---|
| Persevere | n/a | | | | |
| Pivot | zoom-in / zoom-out / customer segment / customer need / platform / business architecture / value capture / engine of growth / channel / technology | | | | |
| Stop | n/a | | | | |

## Decision
- Decision:
- Rationale (one paragraph):
- What we keep from the past (validated learning carried forward):
- New or revised hypothesis:
- Next milestone and review date:
- Who will be told, and how:

# Double Diamond brief · [Challenge] · [Date]

**Owner:** [PM]   **Designer:** [Name]   **Current phase:** Discover / Define / Develop / Deliver

## The request as received
[What the customer or stakeholder asked for, in their words. Treat it as a clue, not a brief.]

## Discover (diverge on the problem)
- People to spend time with (by persona, including the buying group):
- Methods: observation, interviews, data review
- What surprised us:

## Define (converge on the problem)
- Point of view or job story: When [situation], [persona] wants to [motivation], so they can [outcome].
- Problem statement we will design for:
- What we're explicitly not solving:

## Develop (diverge on solutions)
- Options generated (at least five, including "do nothing"):
- Co-design sessions held, and with whom:

## Deliver (converge on a solution)
- Small-scale test and its experiment card:
- What failed and was rejected:
- What will be improved and carried forward:

## Loop-backs
| Date | From phase | Back to phase | Why |
|---|---|---|---|
| | | | |

# Innovation mechanism selector · [Bet name] · [Date]

**Owner:** [PM]   **Decision maker:** [Name]   **Answer needed by:** [Date]

## The bet as a question
[One question the roadmap can't answer yet. No solution language.]

## Placement (from the innovation portfolio, Chapter 20)
- Ambition: Core / Adjacent / Transformational
- Horizon: 1 / 2 / 3
- Why: [one or two sentences]

## Blocking uncertainty (pick the main one)
- [ ] Feasibility: can it be built?
- [ ] Desirability and adoption: will customers use it, and will their security teams approve it?
- [ ] Availability: does someone already have it?
- [ ] Capability: do we have the skills and people?
- [ ] Business model: can we make money from it?

## Candidate mechanisms
| Mechanism | Answers the question? | Cost (L/M/H) | Time to answer | Control | Customer impact | Reversible? |
|---|---|---|---|---|---|---|
| [e.g. hackathon] | | | | | | |
| [e.g. venture client pilot] | | | | | | |
| [e.g. design partners] | | | | | | |

## Build, partner or buy check
1. Internal resources relevant? [Yes / Partly / No, with evidence]
2. Resource tradable by contract? [Yes / No]
3. Bounded collaboration enough? [Yes / No]
4. Deep integration needed and feasible? [Yes / No]
- Model-provider dependency: [none / describe]
- Need the team, or only the technology? [team / technology / both]

## Choice
**Mechanism:** [name]   **Why this one:** [the cheapest mechanism that answers the question in time, and why]
**Rejected and why:** [one line each]

## Landing plan
- Receiving owner (PM and engineering lead): [names, signed]
- Follow-on capacity reserved: [sprint, quarter slot or budget]
- Gatekeepers involved from the start: [security, legal, procurement]
- Decision date: [date]   **Evidence that decides:** [thresholds set now]
- Possible outcomes: Absorb / Continue with new question / Hand to another mechanism / Stop

# Hackathon plan · [Event name] · [Dates]

**Sponsor:** [Exec]   **Owner:** [PM]   **Planning started:** [date, about four months ahead]

## 1. Goal
[What the roadmap needs answered. Measurable: e.g. "three prototypes that pass eval X".]

## 2. Theme
[One theme tied to a named bet.]

## 3. Competition or cooperation
[Choice and why. Shared assets teams can reuse.]

## 4. Stakeholder involvement
- Customer or partner participants and judges: [names]
- Security pre-approval of data and system access: [name, date]

## 5. Participant recruitment
[Who, how many, which skills. Include domain experts, not only engineers.]

## 6. Specialized preparation
- Sandbox environment and connectors: [list]
- Data set (anonymized, approved): [description]
- Eval set and scoring method: [description]
- Templates, starter code, model access: [list]

## 7. Duration and breaks
[Length, hours, rest. No overnight heroics unless chosen.]

## 8. Ideation
[Before or during the event; problem list seeded from customer evidence.]

## 9. Team formation
[How people find teams; maximum team size.]

## 10. Agenda
| Time | Activity |
|---|---|
| | Kickoff: goal, rules, judging |
| | Build |
| | Mentor check-ins |
| | Evaluation run on the shared eval set |
| | Presentations and judging |

## 11. Mentoring
[Who mentors on product, security, AI, domain.]

## 12. Continuity (agreed before the event)
- Each winning project gets: [named PM owner, follow-on slot, budget]
- Other outcomes we'll keep: [reusable components, connectors, eval cases, people to recruit into the bet]
- Decision review date: [date]

## Judging rules
- Measured results on the shared eval set: [weight]
- Customer value against the bet's question: [weight]
- Safety and security: [pass/fail gate]
- Demo polish: not scored

## Tensions we're managing
[Organizational vs personal goals; concept vs useful output; challenge vs achievable; speed vs quality.]

# Design partner program plan · [Product or capability] · [Dates]

**Owner:** [PM]   **Executive sponsor:** [Name]   **Program length:** [one to three quarters]

## Learning goals
1. [What we must learn about workflow]
2. [What we must learn about adoption and approval]
3. [What we must learn about pricing or packaging]

## Selection criteria
- Matches target segment: [criteria]
- Willing to share data: [what, under which agreement]
- Executive sponsor on their side: [required]
- Mix: [include at least one partner unlike the most enthusiastic one]
- Number of partners: [typically five to eight]

## Commitments
| Partner commits to | We commit to |
|---|---|
| Feedback sessions every [n] weeks | Early access to builds |
| Usage and outcome data shared | Named PM contact |
| [Reference or case study if successful] | [Pricing protection for first term] |
| [Security review in parallel] | [Roadmap visibility under NDA] |

## Rules for what ships
- A partner-requested feature ships only if [at least n] partners need it.
- Single-partner requests go to a separate log, reviewed at program end.
- No custom branches or one-off integrations.

## Cadence and evidence
- Weekly: synthesis of feedback, every theme traced to partners
- Monthly: progress against learning goals
- Thresholds that end the program early (positive or negative): [list]

## Exit
- End date: [date]
- Conversion terms to standard commercial contract: [summary]
- What happens to partners who don't convert: [plan]
- Data handling at exit: [return or delete]

# Build, partner or buy analysis · [Capability] · [Date]

**Owner:** [PM]   **Reviewers:** [engineering, finance, corporate development, security]

## Capability needed and why
[What the strategy requires, by when, and the cost of not having it.]

## The four questions
| Question | Answer | Evidence |
|---|---|---|
| 1. Are internal resources relevant (knowledge, skills, organizational fit)? | | |
| 2. Is the resource tradable (can a contract define and protect it)? | | |
| 3. Is a bounded collaboration enough (limited joint work, aligned goals)? | | |
| 4. Is deep integration needed, and is it feasible? | | |

## Options compared
| | Build | Partner (contract or alliance) | Buy (company, team or technology) |
|---|---|---|---|
| Time to capability | | | |
| Cost (one-time and ongoing) | | | |
| Control | | | |
| Effect on gross margin | | | |
| Switching cost later | | | |
| Effect on customers | | | |
| Talent risk | | | |
| Regulatory exposure | | | |

## AI-era checks
- Model-provider dependency: [which provider, terms, switching cost, what they can see]
- Exclusivity or limits on other partners: [terms]
- Portability: [abstraction layer, model-agnostic evals]
- Team or technology only? [answer]

## Our default path and the trap
[Which path this company usually takes, and whether this analysis is just repeating it.]

## Recommendation
[Path, scope, and the conditions that would trigger the next path.]
**Review date:** [date]

# Acquisition opportunity brief · [Target] · [Date] · Confidential

**Author:** [PM]   **Corporate development lead:** [Name]   **Distribution:** [named list only]

## The target in one paragraph
[What they build, for whom, stage, team, and why it came up.]

## Strategic fit
- Roadmap bet it answers: [bet]
- Capability gained: [technology, team, customers, data]
- Time saved against building: [estimate with reasoning]

## Leverage or reinvent?
- Value proposition: [same / different]
- Customers and buyers: [same / different]
- Sales motion and pricing: [compatible / different]
- Verdict: Leverages our model (integrate) / Reinvents it (keep separate)

## Options, in order of commitment
| Option | What we get | Cost | Effect on the target's customers | Reversible? |
|---|---|---|---|---|
| Venture client pilot | Evidence of fit | | Served as normal | Yes |
| Minority investment | Option and relationship | | Unchanged | Partly |
| License-and-hire | Team and technology | | Risk of stranding | No |
| Full acquisition | Everything, plus contracts | | Inherited | No |

## Integration risks
[Talent retention, product overlap, technology stack, culture, security posture.]

## Diligence questions
[Technical, eval quality, data rights, security, customer contracts, open-source licenses.]

## Regulatory and approval considerations
[Merger review, data transfer, sector rules. Confirm with legal.]

## Trigger conditions to proceed
[Measured results, by date, that would justify the next level of commitment.]

## Recommendation
[Next step only. Not the whole deal.]

# Venture client pilot charter · [Startup] · [Dates]

**Owner:** [PM]   **Startup contact:** [Name]   **Procurement:** [Name]   **Security:** [Name]

## Problem we're buying a solution to
[One paragraph, in customer terms.]

## Why buy rather than build
[Short answer from the build, partner or buy check.]

## Scope
- Workflow and environment: [where it runs]
- Data shared: [what, under which agreement]
- Duration: [weeks]
- Paid pilot value: [amount]

## Success criteria (set before the pilot)
| Measure | Threshold | Source |
|---|---|---|
| | | |

## Gates
- Security review completed by: [date]
- Purchase order issued by: [date]
- Mid-pilot check: [date]
- Decision: [date]

## Outcomes
- Pass: [contract path, owner, budget line]
- Partial: [what changes and one more cycle]
- Fail: [how we exit and what we keep]

# Innovation stakeholder map · [Bet name] · [Date]

**Owner:** [PM]   **Champion:** [Executive]   **Confidential:** contains views about colleagues; share only with the core team.

| Name and role | Power (H/M/L) | Interest (H/M/L) | Grid group | Current stance | Gains if it works | Loses if it works | Evidence that would move them | Owner and next touch |
|---|---|---|---|---|---|---|---|---|
| | | | Manage closely / Keep satisfied / Keep informed / Monitor | Champion / Supporter / Neutral / Skeptic / Blocker | | Budget, headcount, metric, risk, roadmap share | | |

## Borrowed assets
| Asset borrowed from the core | Governed by | Terms of access | What the core gets back |
|---|---|---|---|
| Customers | | | |
| Data | | | |
| Sales channel | | | |
| Certifications and compliance | | | |
| Platform services | | | |

## Coalition gap (one line)
[Which high-power stakeholder is neutral, skeptical or blocking, and what would move them.]

## Changes since last version
| Date | Stakeholder | Stance before → after | What changed it |
|---|---|---|---|

# Innovation campaign plan · [Bet name] · [Quarter]

**Objective:** [The decision or behavior this campaign must produce, and by when]
**Decision needed:** [Forum, date, decision maker]
**Urgency in their words:** [The corporate goal or threat, quoted from the strategy memo, with source]

## Guiding coalition
| Member | Function | Role in the campaign | Commitment asked |
|---|---|---|---|
| [Executive champion] | | Sponsor; opens doors | Attend gates; recruit one peer |
| | | | |

## Audiences and messages (from the stakeholder map)
| Audience segment | Their problem | The evidence for them | The ask | Messenger |
|---|---|---|---|---|
| | | | | |

## Volunteer army
[Who inside or outside the company wants this to win, and what each will do: run a demo, staff a pilot, tell a story.]

## Short-term wins (dated, each a piece of evidence)
| Date | Win | Evidence it produces | Before which decision |
|---|---|---|---|
| | | | |

## Channels and moments
| Moment | Date | Audience | What we show |
|---|---|---|---|
| Executive staff meeting | | | |
| QBR or business review | | | |
| All-hands demo | | | |
| Customer advisory board | | | |

## Barriers and policy exceptions requested
| Barrier | Policy behind it | Exception proposed (who, how long, guardrail, end condition) | Owner | Status |
|---|---|---|---|---|

## Objections log
| Date | Objection | From | Response: evidence or plan change | Resolved? |
|---|---|---|---|---|

## Measures of support
[Stance changes on the stakeholder map; exceptions granted; pilots staffed by volunteers; decision outcome.]

# Dedicated team charter · [Bet name] · [Date]

**Single-threaded leader:** [Name, and the scope they gave up]
**Executive champion:** [Name]   **Form:** Structural (separate team) / Contextual (protected time inside a team)
**Why this form:** [Distance from the core: buyer, price, channel, risk profile]

## Explore and exploit alignment
| Element | Core (performance engine) | This bet (dedicated team) |
|---|---|---|
| Strategic intent | | |
| Critical tasks | | |
| People and skills | | |
| Structure and decision rights | | |
| Metrics and rewards | | |
| Culture and norms | | |
| Funding | Annual plan | Tranches at evidence milestones |

## Split of work
| Task (build to scale) | Fits core routine? | Owner: dedicated team or shared staff | Named person | Conflict to manage |
|---|---|---|---|---|
| Build | | | | |
| Evals and quality | | | | |
| Pricing and billing | | | | |
| Selling | | | | |
| Support and escalation | | | | |
| Security and risk review | | | | |
| Operations and on-call | | | | |
| Release and deployment | | | | |

## Supporting policies
| Policy area | Current rule | Exception or new rule | Approved by | Ends when |
|---|---|---|---|---|

## Reviews
Learning review: [cadence, forum, separate from performance reviews]
Disputes with the core are settled by: [champion or senior team]

# Innovation portfolio review · [Portfolio] · [Quarter]

**Forum:** [Name]   **Decision makers:** [Names]   **Prepared by:** [PM]   **Sources:** [Reports used, with dates]

## Portfolio summary
| Measure | This quarter | Last quarter | Target |
|---|---|---|---|
| Spend mix: core / adjacent / transformational | | | [Agreed mix] |
| Bets by stage (gate 1 / 2 / 3 / 4) | | | |
| Assumptions retired this quarter (learning velocity) | | | |
| Bets killed or pivoted this quarter | | | Some, every year |
| Bets transferred to the core this quarter | | | |

## Bets
| Bet | Horizon or zone | Stage | Riskiest assumption | Evidence since last review | Leading indicator vs plan | Spend to date | Next tranche asked | Kill line (state and date) | Kill line status | Door type of the decision | Recommended decision |
|---|---|---|---|---|---|---|---|---|---|---|---|
| | H1 / H2 / H3 | | | | | | | | Met / Not met / Not yet due | Two-way / One-way | Continue / Pivot / Scale / Kill / Hold |

## Kill lines crossed or missed
[Every bet whose kill line date passed this quarter, with the state reached and the decision.]

## Decisions
| Bet | Decision | Resources released | Next gate date | Decided by |
|---|---|---|---|---|

## Recognition
[Teams that killed or pivoted a bet on evidence this quarter.]

# Scale-up readiness checklist · [Bet name] · [Date]

**Gate:** Pilot to scale (gate 4)   **Receiving owner:** [Name]   **Transfer path:** Absorb into core unit / Grow standalone / Sell or spin out

Every item needs an evidence link. An item with a claim and no evidence is a fail.

| # | Item | Pass / Fail | Evidence link | Owner | Fix by |
|---|---|---|---|---|---|
| 1 | Results hold outside the pilot: customers representative of the target segments, not only the friendliest | | | | |
| 2 | Results hold without pilot-level attention from the team | | | | |
| 3 | Unit economics at scale volumes, including inference cost as a dated curve | | | | |
| 4 | For AI: autonomy matches the job; a simpler workflow was considered and rejected on evidence | | | | |
| 5 | Evals cover the actions and outputs customers will rely on, and will keep running after transfer | | | | |
| 6 | Operational readiness: support runbooks, escalation path, on-call, documentation | | | | |
| 7 | Go-to-market readiness: price, SKU, billing, sales compensation, partner enablement | | | | |
| 8 | Compliance and risk: security review, audit logs, data residency, AI risk documentation | | | | |
| 9 | Receiving owner has the bet in their plan, budget and roadmap | | | | |
| 10 | Integration and technical debt listed, each with an owner | | | | |
| 11 | Pilot exceptions listed, with what replaces each at scale | | | | |
| 12 | Metrics and dashboards continue in the receiving unit's business review for two or three quarters | | | | |
| 13 | Sunset or migration plan for anything the bet replaces | | | | |
| 14 | Exit report written: what was learned, open assumptions, what the receiving unit must keep doing | | | | |

## Decision
[Scale / Scale with conditions / Not yet], decided by [forum] on [date]. Conditions: [list].

# Innovation pitch · [Bet name] · [Decision forum] · [Date]

Format: two pages plus appendix, read silently at the start of the meeting.

## 1. Headline
[One sentence: the customer, the outcome and the decision we're asking for.]

## 2. Problem and why now
[The customer problem in their words; the corporate goal it serves, quoted; what changed that makes now the time.]

## 3. What we learned since the last gate
| Assumption | Evidence | Result | Source |
|---|---|---|---|

## 4. The bet and the business model
[What we will build or scale, how it makes money, unit economics with dated assumptions.]

## 5. The ask
| Item | Amount or scope | Door type (two-way / one-way) | Released against |
|---|---|---|---|
| Money | | | |
| People | | | |
| Policy exceptions | | | |
| Transfer decision | | | |

## 6. Milestones and tranches
| Milestone | Date | Evidence required | Tranche released |
|---|---|---|---|

## 7. Kill criteria
We stop [bet] if by [date] we have not shown [state, measured as], unless [named exception]. Decided by [forum].

## 8. Scale path
[Transfer path, receiving owner and the date they take it into their plan.]

## 9. Top risks
[Top three from the risk register, each with owner and trigger.]

## Appendix: internal FAQ
Market size and evidence · Competition and alternatives · Unit economics · Upfront investment · Cannibalization of current revenue · Dependencies on other teams and third parties · Regulation and AI risk · Assumptions that must hold · Top reasons this could fail

## AI disclosure
[Which parts were drafted or analyzed with AI, and confirmation that every number was checked against its source.]

# Positioning canvas · [Product or offer] · v[n] · [Date]

**Owner:** [PM] and [PMM]   **Decision maker:** [Name]   **Status:** Thesis / Validated / Under review
**Scope:** Single product / Suite or platform / Company / Combination: [which]
**Champion persona:** [role, from the buying group]   **Review date:** [date or after N qualified deals]
**Evidence used:** [win/loss for which period, number of discovery interviews, pilots, usage data, evals]

## 1. Competitive alternatives (what customers would do if we didn't exist)
| Alternative | How often it appears in deals (source) | Where it falls short for best-fit customers |
|---|---|---|
| [Status quo or manual process] | | |
| [Competitor or category] | | |
| [Do nothing] | | |

## 2. Differentiated capabilities (what we have that the alternatives lack)
| Capability | Which alternatives lack it | How we know (evidence) |
|---|---|---|
| | | |

## 3. Value themes ("so what?" for each capability, grouped into two to four themes)
| Value theme | Capabilities that deliver it | Proof we have today | Proof still needed |
|---|---|---|---|
| | | | |

## 4. Best-fit customers
- Characteristics that make a customer care a lot about this value: [size, situation, tech stack, trigger events]
- Characteristics that predict a poor fit: [ ]
- Example best-fit customers (from won deals): [ ]

## 5. Market category
- Style chosen: Head to head / Big fish in a small pond / New category
- Category or subsegment: [name]
- Why this frame makes our value obvious: [ ]
- Budget line and shortlist test: [does the buyer already budget and shortlist for this?]
- Styles rejected and why: [ ]

## Optional: relevant trend
- Trend: [ ]   How it links to present value: [ ]   Risk of sounding like hype: [ ]

## Decision
- Decided on [date] by [names]. Logged in decision log as [ID].

# Positioning statement · [Product or offer] · v[n] · [Date]

**Source canvas:** [link]   **Owner:** [PM and PMM]   **Status:** Draft / Approved

**For** [best-fit customers, from canvas section 4]
**who** [need or problem, in their words],
**[Product] is a** [category or subsegment, from canvas section 5]
**that** [primary value theme, as a benefit].
**Unlike** [the primary competitive alternative, usually the one that appears most in deals],
**[Product]** [primary differentiation, from canvas section 2].

## Persona check
| Persona | Does the statement speak to them? | What they would add or object to |
|---|---|---|
| Champion | | |
| Economic buyer | | |
| Technical evaluator or security | | |

## Repeat-back test
| Tester (sales rep or customer) | Their version in their own words | Accurate? |
|---|---|---|
| | | |

## Claims in this statement
- [List each objective claim and its claims-log row ID]

# Messaging framework · [Product or offer] · v[n] · [Date]

**Positioning source:** [canvas and statement links]   **Owner:** [PMM]   **Accuracy reviewer:** [PM]

## Message house
**Roof (umbrella message, one sentence, customer language):** [ ]

| | Pillar 1 | Pillar 2 | Pillar 3 |
|---|---|---|---|
| Value theme (from canvas) | | | |
| Supporting message | | | |
| Proof points (claims-log IDs) | | | |
| Main persona | | | |

**Foundation (credibility, trust and objection handling):** [security, compliance, data use terms, support, integrations, company facts, AI governance facts]

## Persona variants ([Product] messaging for [persona])
| Persona | Role in deal | Pain in their words | Lead pillar | Core message | Proof they trust | Objections to handle |
|---|---|---|---|---|---|---|
| Champion | | | | | | |
| Economic buyer | | | | | | |
| End user | | | | | | |
| Technical evaluator or security | | | Foundation | | | |
| Partner | | | | | | |

## Availability labels
| Capability mentioned | Label (GA / Preview / Roadmap) | Matches offer definition? |
|---|---|---|
| | | |

## Words we use and words we avoid
- Use: [ ]
- Avoid: [for example, "replaces your [professional]", "fully autonomous", unqualified "available now"]

# Offer definition · [Offer name] · v[n] · [Date]

**Owner:** [PM]   **Packaging and pricing source:** [Chapter 15 decision, link]   **Status:** Draft / In readiness / Approved / Live

## What is sold
| SKU | Name | Edition or add-on | Unit of charge | List price | Owner |
|---|---|---|---|---|---|
| | | | | | |

## Editions and entitlements
| Capability or entitlement | Edition A | Edition B | Edition C | Add-on |
|---|---|---|---|---|
| | | | | |

Limits and quotas: [ ]   Support level: [ ]   Data retention: [ ]   Service levels: [ ]

## Unit definition (required for usage or outcome pricing)
- Exact definition of one unit: [ ]
- Who measures it and from which data: [ ]
- Exclusions: [ ]
- Dispute window and process: [ ]
- Credits when the product makes things worse: [ ]

## Bundles
- Sold only together: [ ]   Sold separately: [ ]   Both ways: [ ]

## Terms
- Contract length: [ ]   Minimum commitment: [ ]   Overage and true-up: [ ]
- Renewal and price protection: [ ]   Discount guardrails: [ ]

## Eligibility
- Who may buy each edition (prerequisites): [ ]
- Regions: [ ]   Channels: Direct / Reseller / MSP / Marketplace
- Partner-specific terms (for example, per-customer billing): [ ]

## Availability
| Capability | GA / Preview / Roadmap | Date | Shown in messaging as |
|---|---|---|---|
| | | | |

## AI-specific terms (AI products)
- Customer data used for training: [never / with consent / terms]
- What the product does autonomously, with approval, or only suggests: [ ]
- Customer controls (allowlists, kill switch): [ ]
- Third-party models or services relied on: [ ]

# Offer readiness check · [Offer name] · [Date]

**Launch date:** [ ]   **Owner:** [PM]   **Go / no-go decision maker:** [Name]

| Stage | Question | Owner | Status (Ready / Gap / N/A) | Gap and fix date |
|---|---|---|---|---|
| Offer configuration | Is every SKU, edition and add-on configured, with rules for valid combinations? | Sales operations | | |
| Pricing | Are list prices, discount guardrails and approval levels set? | Pricing or finance | | |
| Quoting | Can a rep produce a correct quote for each edition, region and channel without help? | Sales operations | | |
| Contract management | Are the terms, unit definitions, AI terms and data processing terms approved? | Legal | | |
| Orders | Can orders be booked and provisioned, including entitlements and limits? | Operations | | |
| Billing | Can billing measure and charge every unit of charge, with the data needed for disputes? | Billing and engineering | | |
| Payment and collections | Are payment terms and collections processes ready, including for partners? | Finance | | |
| Revenue recognition | Has revenue accounting identified the separate promises and any variable consideration? | Revenue accounting | | |
| Renewal | Is the renewal, upgrade and migration path defined? | Customer success | | |
| Partners | Can partners quote, order and bill this offer, or is it labeled direct-only for now? | Partner team | | |
| Claims | Is every external claim in the claims log and approved? | PMM and legal | | |

**Decision:** Go / Go with scope reduced (what is labeled "coming" and when) / No-go

# Claims substantiation log · [Product or launch] · [Date]

**Owner:** [PM] (evidence)   **Wording owner:** [PMM]   **Approver:** [Legal]   **Investor relations review (public companies):** [Name]

| ID | Claim text (exact wording) | Where used | Type: express or implied; quantified, comparative or availability | Evidence (link) | Population and period the evidence covers | Matches the audience of the claim? | Evidence owner | Status (Draft / Approved / Rewrite / Cut) | Review date |
|---|---|---|---|---|---|---|---|---|---|
| C-01 | | | | | | | | | |

## Rules
- No objective claim appears externally without an Approved row.
- A claim that states its own level of support ("tested," "proven," "in pilots") needs at least that level of support.
- Evidence must exist when the claim is made, be retained and cover the same population the claim addresses.
- AI accuracy and autonomy numbers trace to a named eval set or production metric, with date and scope, and state the denominator.
- Claims that the product replaces a professional, or that it acts without human involvement, get extra scrutiny.
- Availability claims match the offer definition's GA, preview and roadmap labels.
- Re-review every row when the model, eval set or product version behind it changes.

# Launch tier matrix · [Product or portfolio] · v[n] · [Date]

**Owner:** [Launch council chair or product ops lead]   **Review:** every half year

## Tier criteria (a launch meets a tier when it meets any two of its criteria)
| | Tier 1 | Tier 2 | Tier 3 |
|---|---|---|---|
| New product, SKU or price | | | |
| Changes how buyers evaluate us | | | |
| Revenue or pipeline target attached | | | |
| Regulatory or trust exposure (AI autonomy, new data use) | | | |
| New capability for existing customers | | | |
| Changes an admin or user workflow | | | |
| Improvement, fix or minor change | | | |

AI rule: an AI feature that acts on the customer's behalf moves up one tier.

## What each tier gets
| | Tier 1 | Tier 2 | Tier 3 |
|---|---|---|---|
| Announcement artifacts | Press release, blog post, customer FAQ, internal FAQ, release notes, transparency note (AI) | Blog post, customer FAQ, internal FAQ, release notes | Release notes |
| Readiness | All nine functions | Affected functions | Docs and support |
| Rollout | Design partners, early access, LA, GA | Opt-in or percentage | Flag to GA |
| Enablement | Certification | Brief | None |
| Go/no-go decider | [VP or GM] | [PM lead] | [Engineering lead] |
| Post-launch review | 30 and 90 days | 30 days | On trigger |

## Stage definitions we use
| Stage | Access | Support | SLA | Production use | Price |
|---|---|---|---|---|---|
| Design partners (private preview) | Named accounts under NDA | Direct with product team | None | [Agreed in writing / no] | [Free / discounted] |
| Early access (preview) | Admin opt-in | Best effort | None | [No / at own risk] | [ ] |
| Limited availability | [Platforms, regions or scale limit] | Full | [None stated / ] | Yes, within scope | [ ] |
| General availability | All eligible customers | Full | [SLA] | Yes | List |

## Tier decisions this quarter
| Launch | Proposed tier | Criteria met | Confirmed by | Date |
|---|---|---|---|---|
| | | | | |

# Launch plan · [Launch name] · Tier [1/2/3] · [Date]

**Owner:** [PM]   **Go/no-go decider:** [Name]   **Launch date or range:** [ ]   **Go/no-go review date:** [ ]
**Links:** PR/FAQ · PRD · release plan (Chapter 06) · positioning (Chapter 24) · readiness checklist

## Goal
What changes for which customers, and the business outcome we expect: [one paragraph].

## Audience
Target segments and personas: [ ]. Who is excluded at this stage and why: [ ].

## Stage plan
| Stage | Entry criteria | Who | Autonomy ceiling (AI) | Exit criteria | Target date |
|---|---|---|---|---|---|
| Design partners | | | | | |
| Early access | | | | | |
| Limited availability | | | | | |
| General availability | | | | | |

Flags: release toggle [name], permissioning toggle [name], kill switch (ops toggle) [name], owner [name].

## Success metrics (set before launch)
| Type | Metric | Baseline | Target | When read | Source report |
|---|---|---|---|---|---|
| Leading | | | | | |
| Lagging | | | | | |
| Guardrail | | | | | |
| Reach (reported only) | | | | | |

## Communications timeline
| When | Audience | Artifact or channel | Owner | Status |
|---|---|---|---|---|
| T minus [n] weeks | Internal: sales, support | | | |
| T minus [n] weeks | Analysts, press (embargo) | | | |
| T | Customers, public | | | |
| T plus 1 week | Customers | FAQ and docs updates | | |

## AI-specific (AI features only)
- Model and version at launch: [ ]. Upstream retirement date if known: [ ].
- Production quality evals running after launch: [ ].
- Behavior reviewer for the go/no-go: [name].
- AI disclosure: what is labeled AI-generated, where: [ ].

## Post-launch review triggers
[Every tier 1 at 30 and 90 days; any conditional go; any rollback; any trigger metric crossing [threshold].]

## Risks and open questions
| Risk | Likelihood | Impact | Mitigation | Owner |
|---|---|---|---|---|
| | | | | |

# Launch readiness checklist · [Launch name] · Stage: [ ] · [Date]

Status: Green = ready · Amber = at risk, with a plan and date · Red = not ready
Definitions of ready are agreed by [date], before work is graded against them.

| Function | Owner | Ready means | Evidence link | Status | Note |
|---|---|---|---|---|---|
| Product | | Scope frozen for this stage; metrics and baselines set; customer FAQ approved | | | |
| Engineering | | Rollout plan, flags and kill switch; capacity tested against the marketing plan; rollback rehearsed | | | |
| Documentation | | Docs for every supported platform at this stage; release notes drafted; limitations stated | | | |
| Support | | Runbooks and macros; staff trained; launch ticket tag live; escalation path | | | |
| Sales | | Enablement complete; talk track states the stage; quoting works | | | |
| Legal | | Terms match the stage label; claims substantiated; AI disclosure reviewed | | | |
| Billing | | SKUs and meters live; test invoice correct; dispute path defined | | | |
| Security | | Review passed; audit logging and access controls verified; security docs ready | | | |
| Marketing | | Artifacts approved; channels and timeline set; spokespeople and references confirmed | | | |
| Behavior review (AI) | | Named reviewer has used the feature on real tasks and signs off on behavior | | | |

## Capacity inputs from marketing
Announcement channels and expected traffic: [ ]. Event demo load: [ ]. Confirmed with engineering on [date].

# Go/no-go review · [Launch name] · [Date] · T minus [n] days

**Decider:** [Name]   **Attendees:** [one owner per function]   **Readiness checklist:** [link]

## Status poll (each owner states their own)
| Function | Owner | Status | Open items |
|---|---|---|---|
| | | | |

## Reds and ambers
| Item | Risk if we launch anyway | Options | Owner |
|---|---|---|---|
| | | | |

## Decision
[ ] Go   [ ] Go with conditions   [ ] No-go

**Conditions (if any):**
1. [Condition] · Owner: [ ] · Due: [ ] · What happens if it is missed: [ ]

**Risk acceptances (any red launched over):**
- [Risk] accepted by [decider], owned by [name], resolved by [date].

**If no-go:** new date [ ], evidence needed to reach go [ ].

## Communicated
Field and support told on [date] by [name]. Decision log entry: [link].

# Early access program plan · [Feature] · [Date]

**Owner:** [PM]   **Stage:** Design partners (private preview) / Early access (preview)   **Runs:** [start] to [end]

## What we need to learn
1. [Learning goal, written as a question with a measurable answer]
2.
3.

## Who gets in
- Number of accounts: [n] (no more than we can talk to every two weeks)
- Entry criteria: [fit, environment, willingness to give feedback, named contact]
- Who opts in: [customer admin role]. What the admin controls: [features, agents, actions, users]
- Exclusions: [regions, regulated segments, platforms not yet supported]

## Terms (confirmed by legal)
- Production use: [allowed / not allowed / allowed with conditions]
- SLA and support: [ ]
- Confidentiality: [ ]
- Data handling, including any AI monitoring or retention: [ ]
- Price during the program and at graduation: [ ]
- What happens to the customer's work and configuration at the next stage: [ ]

## Cadence
Feedback sessions: [every two weeks]. Usage review: [weekly]. Program channel: [ ].

## Exit criteria to the next stage
| Criterion | Threshold | Current | Met? |
|---|---|---|---|
| | | | |

## Graduation communication
What each account is told, by whom and when, at graduation or at the end of the program: [ ].

# Announcement pack · [Launch name] · [Date]

## Press release (under one page)
**Heading:** [Product name]: [one-line descriptor]
**Subheading:** [Customer segment] can now [benefit].
**Summary:** [City], [date]. [What is available today, at which stage, and what comes later, with dates or ranges.]
**Problem:** [The customer's problem in their terms.]
**Solution:** [How it solves the problem and why it beats current alternatives, including doing nothing.]
**Spokesperson quote:** [ ]
**Customer quote:** [Real, approved, from a named design partner or early access customer.]
**Getting started:** [How to join, what it costs, where to learn more.]

## Launch blog post
- Title: [the customer outcome]
- Opening: a specific situation the reader recognizes
- What's new, at what stage, for whom
- A worked example with a real (approved) or clearly illustrative scenario
- What's next, without dates the plan doesn't support
- How to get access

## Release notes entry
### [Version or date]
- **Added:**
- **Changed:**
- **Deprecated:**
- **Removed:**
- **Fixed:**
- **Security:**
- **Model and behavior changes (AI):** model and version; eval results that moved; known regressions

## PR/FAQ gap analysis
| Inception PR/FAQ said | Launch release says | Why it changed | Who must know |
|---|---|---|---|
| | | | |

## Claims register
| Claim | Evidence | Reviewed by legal |
|---|---|---|
| | | |

# FAQs · [Launch name] · [Date]

## Customer FAQ (customers, admins, security reviewers)
1. What is available today, and at what stage?
2. What does it cost now, and what changes at [next stage]?
3. Who can turn it on, and how do I turn it off?
4. What data does it read, where is it processed and is it used for training?
5. What does it do without a person's approval, and who decides? (AI)
6. What happens if it gets something wrong? (AI)
7. What is labeled as AI-generated, and where? (AI)
8. What changes when the model changes, and how will we be told? (AI)
9. What support and SLA apply at this stage?
10. Where are the security documentation and transparency note?

## Internal FAQ (sales, support, leadership)
1. What changed between the inception PR/FAQ and launch, and why?
2. What can we say, and what must we not promise? (List.)
3. How does this compare with current alternatives and competitors?
4. What are the unit economics, including cost to serve and margin effect?
5. Which third parties does it depend on, including model providers and their retirement dates?
6. What regulatory or legal issues apply, and what has legal approved?
7. What are the top reasons this launch could fail, and what are we watching?
8. How do I get a customer into early access, and who approves it?
9. Who do I escalate to for a wrong action, a pricing dispute or a security question?

# Post-launch review · [Launch name] · [30 / 90] days · [Date]

**Owner:** [PM]   **Reviewed by:** [senior reviewer]   **Blameless:** we review systems and decisions, not people.

## Prediction against actual
| Metric | Type | Baseline | Predicted | Actual | Read |
|---|---|---|---|---|---|
| | Leading | | | | Above / on / below |
| | Lagging | | | | |
| | Guardrail | | | | |
| | Reach | | | | Reported only |

## What happened
Timeline of the launch and any incidents, rollbacks or stage changes: [ ].

## Why it differed
[Causes, with evidence. Include customer and support signals, not only dashboards.]

## Was the go/no-go right?
Conditions set: [ ]. Were they met on time? Was any risk acceptance justified?

## AI behavior (AI features only)
Production quality eval trend; behavior complaints from support and community; any model or infrastructure change since launch.

## Changes
| Change | In the product or the launch process? | Owner | Due |
|---|---|---|---|
| | | | |

## Stage decision
[Promote / hold / roll back], decided by [name] on [date]. Shared with [ ] and stored in [ ].

# Event plan · [Event name] · [Product] · v[n] · [Date]

**Event owner (marketing):** [Name]   **Product owner:** [PM]   **Claims sign-off:** [Product, legal, communications]
**Event date:** [Date]   **Location / format:** In person / virtual / hybrid

## Launches at this event
| Launch | Tier (Chapter 25) | Readiness label | Channel at event |
|---|---|---|---|
| | 1 / 2 / 3 | GA / Public preview / Private preview / Roadmap | Keynote / breakout / lab / blog / release notes |

## Readiness table (signed)
| Capability | Label | Evidence for the label | Signed by | Date |
|---|---|---|---|---|
| | | | | |

## Sessions
| Session | Format | Persona served | Presenter(s) | Demo? (live / recorded / hybrid) | Owner |
|---|---|---|---|---|---|
| Keynote segment | | | | | |
| Breakout | | | | | |
| Hands-on lab | | | | | |
| Partner session | | | | | |
| Analyst session | | | | | |
| Security or compliance deep-dive | | | | | |

## Audiences and what each must leave with
| Audience | What they need to see or hear | Where they get it |
|---|---|---|
| Users | | |
| Buyers | | |
| Security and compliance | | |
| Partners | | |
| Analysts | | |
| Press | | |

## Customer proof
| Customer | Claim it proves | Number(s) shown | Customer approval | Legal approval |
|---|---|---|---|---|
| | | | Pending / Approved | Pending / Approved |

## Key dates
- Readiness table signed: [Date]
- Keynote outline locked: [Date]
- Demo environment ready: [Date]
- Dress rehearsal: [Date]
- Final claims review: [Date]

## Success measures (set before the event)
See the event impact report.

# Announcement sequencing plan · [Announcement] · [Event] · [Date]

**Owner:** [PM with product marketing and communications]   **Embargo lift:** [Date, time, time zone]

| When | Audience | What they learn | Format | Under | Owner | Ready? |
|---|---|---|---|---|---|---|
| T−[n] weeks | Sales, support, partners | Full detail, readiness labels, FAQ, hard questions | Enablement session, FAQ | Internal confidentiality | | |
| T−[n] weeks | Analysts | Strategy, specifics, roadmap boundaries | Pre-brief | NDA | | |
| T−[n] days | Press | Release, briefing book, spokesperson access | Pre-brief | Embargo | | |
| T zero | Public | The announcement | Press release at embargo lift | | | |
| T zero | Event audience | The story and the demo | Keynote | | | |
| T zero to T+[n] days | Practitioners | Detail and hands-on | Breakouts, labs, webinar | | | |
| T+[n] weeks | Customers and partners | Fit for their accounts | Advisory boards, account reviews | | | |
| GA | Everyone | Availability | Release notes, blog, pricing page | | | |

## Embargo terms
- Embargo lifts at: [date, time, time zone]
- What is under embargo: [release, briefing book, demo video]
- What is never for publication: [internal numbers, unannounced pricing]
- What happens if it breaks: [communications owner's plan]

## Readiness gate for GA
GA is confirmed when: [criteria, such as eval thresholds, support readiness, security sign-off]. Not before.

## Leak plan
If the news leaks before lift: [who decides, what we say, which audiences we contact first]

# Keynote outline · [Event] · [Segment] · [Length] · v[n]

**Presenters:** [Names and roles]   **Tier 1 launch:** [Name]   **Readiness labels shown:** [List]

| # | Beat | Minutes | What is said (in one sentence) | What is shown | Demo? | Label on screen | Audience served (users / buyers / analysts and press) |
|---|---|---|---|---|---|---|---|
| 1 | What is | | | | | | |
| 2 | Call to adventure | | | | | | |
| 3 | Contrast cycle 1 | | | | | | |
| 4 | Contrast cycle 2 | | | | | | |
| 5 | Contrast cycle 3 | | | | | | |
| 6 | S.T.A.R. moment | | | | | | |
| 7 | Customer proof | | | | | | |
| 8 | Call to action | | | | | | |
| 9 | New bliss | | | | | | |

## Checks
- [ ] The audience, not the product, is the hero of the opening.
- [ ] Each of the three audiences has at least one beat aimed at them.
- [ ] Every capability shown matches its readiness label.
- [ ] The call to action is something the audience can do this week.
- [ ] The S.T.A.R. moment is true, rehearsed and has a fallback.
- [ ] Every number on screen has a source and an approval.

# Demo script · [Event] · [Segment] · v[n] · [Date]

**Presenter(s):** [Names]   **Demo engineer:** [Name]   **Booth switcher:** [Name]
**Environment:** [Name, isolated / shared]   **Data:** synthetic / seeded / other: [describe]
**Pinned:** product build [x], model version [x], generation settings [x], retrieval index snapshot [x], connector versions [x]
**Reset procedure:** [link or steps by name]   **Rehearsal eval:** [n] runs, pass threshold [x of n], last result [x of n] on [date]

## Situation summary (what is, 30 seconds)
[The customer's problem, in their words]

## Beats
| # | Words (what the presenter says) | Action | Expected screen | Time | Live / recorded | Abandon trigger | Fallback and line to say |
|---|---|---|---|---|---|---|---|
| 1 | | | | | | | |
| 2 | | | | | | | |
| 3 | | | | | | | |

## Honesty lines (said aloud or on screen)
- What is seeded or synthetic:
- What is recorded, edited or sped up:
- Where a human approves or assists:
- Readiness label for each capability shown:

## Words we never say
[Claims beyond the label, such as "fully autonomous" for a private preview capability]

## Go / no-go for live
Decided by [name] on [date], based on rehearsal eval [x of n] and dress rehearsal result [pass / fail].

# Demo risk plan · [Event] · [Segment] · [Date]

**Pre-mortem held:** [Date, attendees]
**Prompt used:** "It's the morning after the event and the demo failed. What happened?"

| # | Risk | Likelihood (H/M/L) | Impact (H/M/L) | Mitigation before the show | Trigger on stage | Fallback | Owner |
|---|---|---|---|---|---|---|---|
| 1 | Venue network fails or slows | | | | | | |
| 2 | Audience devices load the network or service | | | | | | |
| 3 | Third-party connector or API times out | | | | | | |
| 4 | AI output differs from rehearsal | | | | | | |
| 5 | Notification or device step delayed | | | | | | |
| 6 | State left over from rehearsal or a previous beat | | | | | | |
| 7 | Presenter improvises a claim beyond the label | | | | | | |
| 8 | [Other] | | | | | | |

## Rehearsal record
| Date | Conditions (venue, network, load) | Runs | Pass | Issues found | Fixed? |
|---|---|---|---|---|---|
| | | | | | |

## Disclosure check
- [ ] Edited, sped-up, staged or human-assisted segments are labeled on screen.
- [ ] Anyone interacting with an AI during the demo is told so.
- [ ] Synthetic voices, faces or footage are labeled.
- [ ] Legal has reviewed the demo for markets with disclosure rules.

# Briefing book · [Announcement] · [Event] · [Date]

**Confidential until:** [embargo lift, date, time, time zone]   **Spokespeople:** [Names]   **Owner:** [PM with communications and analyst relations]

## 1. Fact sheet (one page)
- What we're announcing:
- Who it's for:
- What problem it solves:
- Availability:

## 2. Readiness table
| Capability | Label | Available from | Notes |
|---|---|---|---|
| | | | |

## 3. How it works
[Architecture view: components, connectors, data flow, where AI is used]

## 4. Guardrails and risk (AI products)
- Human approval points:
- Audit and logging:
- Data handling and residency:
- Evaluation approach:
- Regulatory documentation available:

## 5. Customer references
| Customer | Use case | Result | Approved to name? | Approved to quote numbers? | Contact |
|---|---|---|---|---|---|
| | | | | | |

## 6. Pricing position
[What we say about pricing; what we don't say yet]

## 7. Competitive framing
| Alternative | How we compare | What we don't claim |
|---|---|---|
| | | |

## 8. Hard questions and approved answers
| Question | Approved answer | Approved by |
|---|---|---|
| | | |

## 9. Internal only (never in the book that leaves the building)
[Numbers and facts spokespeople must know but must not share, with the approved deflection for each]

## 10. Embargo terms
[What is embargoed, until when, and the contact for questions]

# Event impact report · [Event] · [Product] · [30-day / 90-day] · [Date]

**Owner:** [PM]   **Sources:** [CRM, product analytics, support, survey, analyst and press coverage]   **Measures set before the event on:** [Date]

## Summary
[Three sentences: what we announced, what changed, how confident we are]

## Results by level
| Level | Measure | Target | Result | Evidence |
|---|---|---|---|---|
| 1. Reaction and planned action | Session ratings; intent to adopt | | | |
| 2. Learning | Lab completions; certifications | | | |
| 3. Application | Preview or feature activations within 30 days by attending accounts | | | |
| 4. Business impact | Pipeline created and accelerated, attendees vs matched non-attendees; product outcome metrics among adopters | | | |
| 5. ROI | Attributable margin vs the product's share of event cost | | | |
| Intangibles | Analyst note tone; press accuracy on readiness labels; share of voice | | | |

## Isolating the event's effect
- Comparison group and how it was matched:
- Other things that changed in the same period:
- Confidence in the difference (high / medium / low) and why:

## Claim drift
| Source (ticket, call, review) | What the customer expected | Actual readiness | Action taken |
|---|---|---|---|
| | | | |

## What we'd change next time
1.
2.
3.

# Sales enablement kit · [Product or release] · v[n] · [Date]

**PM owner:** [name]   **PMM owner:** [name]   **Enablement owner:** [name]   **Launch tier:** 1 / 2 / 3   **Next review:** [date]

## 1. One-page positioning (PMM with PM)
- For: [segment and persona]
- Problem: [in the customer's words]
- What they use today: [main alternative, including "do nothing"]
- Why we win: [two or three differentiators, each with proof]
- Proof: [reference customers, data, analyst or certification evidence]

## 2. Pitch narrative (PMM)
Problem → what changed in the world → what we do → proof → next step. Link: [deck]

## 3. Discovery guide (PM with sales)
| Persona | Situation | Problem | Implication | Need-payoff |
|---|---|---|---|---|
| | | | | |

## 4. Objection handling guide
Link: [objection guide]

## 5. Competitive battlecards
| Competitor or alternative | Card | Owner | Last updated |
|---|---|---|---|
| | | | |

## 6. Demo
- Environment: [link, data set, reset procedure]
- Script: [link] (reverse chronology: outcome first)
- Failure-mode moment (AI products): [what we show when the product is wrong]

## 7. Pricing and packaging guidance (PM with pricing)
| Item | List | Discount band | Approver |
|---|---|---|---|
| | | | |
Never promise: [custom roadmap dates, uncapped usage, unreleased features, other]

## 8. ROI or business value tool (PM)
- Buyer inputs: [list]
- Assumptions, each with source: [list]
- Default posture: conservative

## 9. Roadmap guidance (PM)
| Item | Can say publicly | Can say under NDA | Do not discuss |
|---|---|---|---|
| | | | |
Every roadmap statement carries the line: "This is not a commitment."

## 10. Known limits and "do not sell into"
| Limit or poor-fit customer | Why | What to do instead |
|---|---|---|
| | | |

## 11. FAQ and escalation
- FAQ: [link]
- Escalation to PM: [channel], response within [one business day]

## Enablement plan
| Audience | Format | Certification | Date | Owner |
|---|---|---|---|---|
| Sellers | | | | |
| Sales engineers | | | | |
| Customer success | | | | |
| Partners | | | | |

## Health of the kit
Usage by asset, field feedback, and the date each asset was last checked by the PM for accuracy.

# Objection handling guide · [Product] · [Date]

**Owner:** [PM]   **Reviewed by:** [PMM, legal for regulatory items]   **Sources:** [call recordings, win-loss, lost-deal notes, date range]

## Objection classes
Price or value · Trust and risk (security, AI safety, data use) · Integration · "We can build it" · Timing · Incumbent is good enough · Regulatory

## Entries (one per objection)

### [Objection, verbatim as buyers say it]
- **Class:**
- **Who says it:** [persona]
- **How often heard:** [count and period, with source]
- **What it usually means:** [the underlying concern]
- **Clarifying question:** [ask before answering]
- **Response:** [two to four sentences]
- **Proof:** [customer evidence, demo moment, document]
- **When to escalate to the PM:** [condition]
- **When the objection is valid:** [condition, and what the seller should do instead, including walking away]
- **Last updated:** [date]

## Retired objections
| Objection | Retired on | Why (product change, market change) |
|---|---|---|
| | | |

# Battlecard · [Us] vs [competitor or alternative] · [Date]

**Owner:** [PMM]   **PM reviewer:** [name]   **Refresh trigger:** competitor release, win-loss pattern, or every [n] weeks

## The competitor in one line
[Who they are and who they sell to]

## When we meet them
[Segments, deal stages, personas involved]

## Where they win
- [Be honest. Sellers trust cards that admit this.]

## Where we win (framed from the buyer's need)
- [Need] → [how we meet it] → [proof]

## Landmines to set (discovery questions that expose their gap)
1.
2.

## Traps they set, and responses
| What their sellers say about us | Response | Proof |
|---|---|---|
| | | |

## Pricing posture
[How they price, how we respond, what we never do]

## Win-loss evidence
[Recent wins and losses against them, with decision drivers]

# Partner enablement plan · [Product] · [Period]

**PM owner:** [name]   **Partner team owner:** [name]

## Partner segments
| Segment | Their business model | Their job with our product | Target number of partners |
|---|---|---|---|
| Reseller | | | |
| Managed service provider | | | |
| Services partner | | | |
| Technology partner | | | |

## What each segment must be able to do
| Segment | Know | Sell | Deploy | Support |
|---|---|---|---|---|
| | | | | |

## Product requirements for partners
[Multi-tenant views, per-customer billing, bulk configuration, APIs, partner pricing, deal registration. Link each gap to a problem record.]

## Content and training
| Segment | Assets | Format | Certification level | Owner |
|---|---|---|---|---|
| | | | | |

## Demo and trial environments
[Sandbox tenants, data, reset rules]

## Commercial summary
[Margin or discount structure, deal registration, co-sell rules. Link to the contract owner.]

## Feedback channel
Partners log problems through [channel] into the same weekly triage as the direct field. Response standard: [days].

## Metrics
| Metric | Baseline | Target | Review cadence |
|---|---|---|---|
| Certified partners by segment | | | |
| Partner-sourced pipeline | | | |
| Time to first partner deal | | | |
| Health of partner-managed customers | | | |

# Onboarding plan · [Customer] · [Start date]

**CSM:** [name]   **Customer lead:** [name]   **Executive sponsor (customer):** [name]   **Product contact:** [PM or SE]

## Desired Outcome
- Goal: [objective] under [conditions] by [time frame]
- Appropriate experience for this segment: [touch model, communication, self-serve vs guided]

## First value
- First-value moment: [the event that proves value]
- Target date: [date]

## Handoff from sales
- Goals agreed in the deal:
- Promises made (check against roadmap guidance):
- Buying-group members and their concerns:
- Risks flagged by sales:

## Prerequisites
| Item | Owner | Due | Status |
|---|---|---|---|
| Security review | | | |
| Connectors and permissions | | | |
| Data access | | | |
| Admin and user provisioning | | | |

## Plan
| Week | Milestone | Customer owner | Our owner | Status |
|---|---|---|---|---|
| 1 | Kickoff, joint plan agreed | | | |
| 2 | | | | |
| 3 | | | | |
| 4 | | | | |

## Checkpoints
| Day | What we review | Signals | Decision |
|---|---|---|---|
| 30 | | | |
| 60 | | | |
| 90 | Formal onboarding review | | Handoff to steady state? |

## Exit criteria
[The conditions that move the customer from onboarding to steady state]

## Risks and mitigations
| Risk | Likelihood | Mitigation | Owner |
|---|---|---|---|
| | | | |

# Feature request intake and triage policy · [Product or portfolio] · v[n]

**Owner:** [PM]   **Operated by:** [product ops]   **Effective:** [date]

## Principle
We record problems, not solutions. Every request becomes evidence on a problem record.

## Intake channels
CRM field · CS platform · Support escalations · Partner portal · Customer advisory board · Win-loss findings · AI call and ticket summaries (with links to the source)

## Required fields
| Field | Notes |
|---|---|
| Customer and segment | |
| Revenue band | |
| Requested by (role and persona) | |
| The problem, in the customer's words | Not the proposed feature |
| Current workaround | |
| Impact | Time, money, risk, blocked deal or renewal |
| Evidence link | Call, ticket, email |
| Account team contact | Who receives the answer |

## Dedupe rule
Search existing problem records first. If the problem exists, attach the new customer as evidence. If not, create a problem record with status "needs discovery."

## Linking
Every problem record links to an opportunity on the product's opportunity solution tree, or is marked "outside current outcomes."

## Statuses
New · Needs discovery · Linked to opportunity · Planned · Not planned (with reason) · Shipped

## Cadence
- Weekly triage, 30 minutes: PM and product ops
- Monthly field update: top problems, decisions and what shipped

## Service levels
- Acknowledge to requester: within [5] business days
- Decision or "needs discovery" status: within [n] weeks
- Close the loop at decision and at ship, to the requester and account team

## Rules
- Revenue-weighted counts are an input, never the sole prioritizer.
- No roadmap commitments in deals without PM sign-off, recorded on the problem record.
- "Not planned" answers include the reason and what the customer can do instead.

## Health metrics
Share of requests linked to a problem · Median time to acknowledge · Share of requesters who received a decision · Share of shipped items announced back to requesters

# Customer advisory board charter · [Product or company] · [Year]

**Executive sponsor:** [name, ideally the CEO or GM]   **Program owner:** [name]   **PM lead:** [name]

## Purpose
[The strategic questions this board exists to advise on]

## Goals for this year
1.
2.
3.

## Membership
- Size: [number]
- Selection criteria: senior decision makers from strategic accounts who can advise beyond their own account; a diverse mix of segments, regions and use cases; [partner seat, if applicable]
- Not eligible: prospects, outside thought leaders
- Term: [length], with a graceful exit for members who no longer fit

## Member value
[What members get: influence on direction, peer exchange, early insight]

## Recruitment and onboarding
[Who nominates (sales and CS), who approves, how members are briefed]

## Rules of engagement
Pitch-free · Confidential · Open dialogue · Compliant with legal and ethical rules · Sales nominates but does not attend

## Meetings
- In person: [1 to 2] times a year, [1 to 1.5] days
- Virtual: [frequency], 60 to 90 minutes
- Agenda principle: strategic questions first; no roadmap walkthrough without a question attached

## Member expectations
[Attendance, preparation, candor]

## Reporting back
After each meeting: a read-out to members within [n] weeks, documented insights, actions with owners and due dates, and candid updates on what we did not do and why.

## Annual review
Revisit charter, content, format and membership every year.

# 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.]

# 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.

# Lifecycle stage assessment · [Offering, module, API version or dependency] · [Date]

**Owner:** [PM]   **Evidence window:** [e.g., last four quarters]   **Next review:** [Date]

## Signals
| Signal | Value | Trend | Source |
|---|---|---|---|
| ARR or usage growth against the market | | | |
| Share of new bookings | | | |
| Net revenue retention and gross churn (customers whose main use is this offering) | | | |
| Active customers and usage trend | | | |
| Gross margin and cost to serve | | | |
| Support tickets per customer; on-call load | | | |
| Engineering share against revenue share | | | |
| Competitive parity (competitor bundles, general-purpose AI tools) | | | |
| Dependency risk (models, platforms, protocols with published end dates) | | | |
| Strategic fit (feeds or competes with the strategy) | | | |

## Assessment
- **Stage:** Introduction / Growth / Maturity / Decline
- **Confidence:** Low / Medium / High
- **The one signal that would change this call:**
- **Self-fulfilling risk:** what we'd stop doing if we call it this stage, and whether that would cause the decline

## Investment posture
Invest / Sustain / Harvest / Retire. Reason in two sentences:

## Portfolio view (one row per offering)
| Offering | Stage | Posture | Revenue share | Engineering share | Gap to resolve |
|---|---|---|---|---|---|
| | | | | | |

## Decision
Agreed by [name] on [date]. Next review: [date]. If the posture is Retire, open a sunset decision memo.

# Stage-gate criteria · [Gate name] · [Product or portfolio]

**Gate type:** New segment / General availability / Price change / R1 Consider retirement / R2 Announce end-of-sale / R3 End support / R4 Decommission
**Gatekeepers:** [names and roles]   **Decision owner:** [name]

## Deliverables the team brings
1.
2.
3.

## Must-meet criteria (any "No" stops the gate)
| Criterion | Yes / No | Evidence |
|---|---|---|
| Strategic fit with the agreed strategy | | |
| Legal and contract review complete | | |
| Security and privacy review complete | | |
| No unmitigated customer harm (data loss, broken integrations, compliance gaps) | | |
| Funded owner for the next stage | | |

## Should-meet criteria (score 1 to 5)
| Criterion | Weight | Score | Evidence |
|---|---|---|---|
| Customer evidence | | | |
| Market attractiveness | | | |
| Competitive advantage | | | |
| Feasibility or migration readiness | | | |
| Financial return or savings | | | |
| Risk (lower risk scores higher) | | | |
| **Weighted total** | | | |

## Decision rules (agreed before the gate)
- Go if all must-meet criteria pass and the weighted total is at least [threshold].
- Recycle if [condition]. Hold if [condition]. Kill if [condition].

## Outcome
Decision: Go / Kill / Hold / Recycle. Approved plan and resources: [summary]. Next gate date: [date]. Recorded in the decision log on [date].

# Sunset decision memo · [Offering] · [Date]

**From:** [PM]   **To:** [Decision owner]   **Approvers:** [Engineering, finance, legal, sales, customer success]

## Recommendation
[One sentence: retire X, with end-of-sale on [date] and last date of support on [date], migrating customers to Y.]

## Why now
- Usage and revenue trend:
- Cost to serve and engineering share:
- Security or dependency risk:
- Strategic fit:
- Successor readiness:

## Who is affected
| Segment | Accounts | ARR | Top accounts | Partners involved |
|---|---|---|---|---|
| | | | | |

## Options considered
| Option | What it costs | What it frees | Customer impact | Verdict |
|---|---|---|---|---|
| Do nothing (keep as is) | | | | |
| Keep investing | | | | |
| Maintenance only | | | | |
| Sell, spin off or open-source | | | | |
| Migrate and retire | | | | |

## Financial impact (planning assumptions, to be confirmed by finance)
- ARR at risk (worst case):
- Expected migration rate and expected churn:
- Savings (engineering, infrastructure, support):
- One-time costs (credits, migration services, tooling):
- Questions for finance (revenue recognition, credits, deferred revenue):

## Contract and legal review
- Notice periods in customer and partner agreements:
- Committed terms that run past the proposed dates:
- Service-level commitments affected:
- Data return, retention and deletion obligations:
- Regulatory obligations:

## Migration path and incentives
[Successor, parity summary, tooling, credits or price protection]

## Communication summary
[Who hears first, public announcement date, channels]

## Milestones and gates
| Gate or milestone | Date | Owner |
|---|---|---|
| R1 Consider retirement | | |
| R2 Announce end-of-sale | | |
| R3 End support | | |
| R4 Decommission | | |

## Reversal criteria (written before announcement)
If [condition, e.g., less than x% of affected ARR has migrated by end of maintenance], we will [action, e.g., offer paid extended support to named accounts for up to n months].

## Decision
[Approved / Not approved / Revise], by [name] on [date].

# End-of-life plan · [Offering] · v[n] · [Date]

**Program owner:** [PM]   **Successor:** [Offering]   **Status:** Planning / Announced / In migration / Closed

## Milestones
| Milestone | Date | What stops | What continues | Owner |
|---|---|---|---|---|
| End-of-life announcement | | | | |
| End-of-sale (last order date) | | New orders | Renewals [yes/no] | |
| Last new subscription term or last ship date | | | | |
| End of software maintenance | | Features and bug fixes | Security fixes, support | |
| End of security fixes | | Vulnerability patches | Support | |
| Last date of support | | Support contracts | Documentation, data export | |
| Decommission and data deletion | | Service and stored data | Deletion evidence on request | |

## Workstreams
| Workstream | Owner | Key deliverables | Due |
|---|---|---|---|
| Migration tooling and parallel run | | | |
| Customer communication | | | |
| Partner program | | | |
| Contracts and legal | | | |
| Pricing, credits and extended support | | | |
| Support staffing | | | |
| Data return and deletion | | | |
| Internal enablement (sales, customer success, support) | | | |
| Price list, documentation and website removal | | | |

## Extended support (if offered)
Price: [ ]   Maximum duration: [ ]   Scope: [security fixes only / other]   Eligibility: [named accounts]

## Metrics (reviewed weekly)
- Share of affected ARR migrated; share of accounts migrated
- Accounts blocked, with reason
- Calls to deprecated APIs by customer
- Support tickets about the end-of-life
- Usage and satisfaction in recently migrated accounts

## Reversal criteria
[Copied from the sunset decision memo]

# End-of-sale and end-of-life notice · [Offering] · [Announcement date]

## Summary
On [date], [company] will stop selling [offering and editions or SKUs]. Support continues until [last date of support]. We recommend moving to [successor], which [one-sentence benefit]. This notice lists every date and what changes at each.

## Affected products
| Product or SKU | Replacement |
|---|---|
| | |

## Milestones
| Milestone | Date | What this means for you |
|---|---|---|
| End-of-sale | | No new orders. Existing subscriptions [can / cannot] renew until [date]. |
| End of software maintenance | | No new features or bug fixes. Security fixes continue. |
| End of security fixes | | No further vulnerability patches. |
| Last date of support | | Support ends. Data export remains available until [date]. |
| Service shutdown and data deletion | | The service stops and remaining data is deleted. |

## What you need to do, and by when
1. [Action] by [date]
2. [Action] by [date]

## Migration support
- Tooling: [import, parallel run]
- Help: [migration services, office hours, documentation]
- Commercial terms: [credits, price protection, extended support terms if any]

## Your data
[How to export it, how long it stays available, when and how it is deleted, how to request deletion evidence]

## For developers
Deprecated APIs and webhooks: [list]. Responses include Deprecation and Sunset headers from [date]. Migration guide: [location].

## Contacts and FAQ
Account team: [contact]   Support: [contact]   FAQ: [location]

# Migration plan · [From offering] to [successor] · [Date]

**Owner:** [PM]   **Engineering lead:** [name]   **Customer success lead:** [name]

## Segments
| Segment | Accounts | ARR | Migration complexity (L/M/H) | Approach (self-serve / assisted / white-glove) | Wave |
|---|---|---|---|---|---|
| | | | | | |

## Feature parity map
| Old capability | New equivalent | Gap | Workaround or plan | Accounts relying on it |
|---|---|---|---|---|
| | | | | |

## Tooling
- Configuration or rule import:
- Data migration and export:
- Parallel run: [how long, what customers compare, how to revert]

## Success criteria per account
[e.g., parallel run complete, key metric within x% of old system, customer sign-off]

## Incentives
[Credits, price lock, free services, and their deadlines]

## Support staffing curve
| Period | Expected migrations | Support and services capacity needed |
|---|---|---|
| | | |

## Tracking
| Account | ARR | Wave | Status (not started / parallel run / migrated / blocked) | Blocker | Owner | Next step |
|---|---|---|---|---|---|---|
| | | | | | | |

## After migration
Check-ins at [30 and 60] days. Watch: [usage, satisfaction, key outcome metric].

## Escalation path
Blocker owner → [PM] → [decision owner], with a response time of [n] business days.

# Deprecation communication plan · [Offering, feature or API] · [Date]

**Owner:** [PM or PMM]   **Canonical page:** [location of the deprecation registry or lifecycle page]

## Audiences and channels
| Audience | What they need to know | Channel | Sender | First contact |
|---|---|---|---|---|
| Economic buyers | Dates, business impact, commercial terms | Account team call, email | Account executive | Pre-brief |
| Admins and champions | Dates, migration steps, tooling | Email, in-product banner, webinar | Product | Announcement |
| Developers | Deprecated endpoints, replacements, dates | Changelog, docs, Deprecation and Sunset headers, SDK warnings | Engineering | Announcement |
| Partners (resellers, MSPs) | All of the above, earlier, plus tenant tooling | Partner briefing, partner portal | Partner team | Pre-brief, before public notice |
| Internal (sales, customer success, support) | Talk track, FAQ, escalation path | Enablement session, internal page | PM and PMM | Before pre-briefs |

## Sequence
| When | Message | Audience |
|---|---|---|
| T minus [n] weeks | Internal enablement | Internal |
| T minus [n] weeks | Pre-brief | Top accounts and partners |
| T (announcement) | Public notice with every date and the successor | All |
| Fixed intervals (e.g., quarterly, then monthly) | Reminder with migration progress and next date | Accounts not yet migrated |
| [n] days before each milestone | Milestone warning | Affected accounts |
| Final warning | Last call with consequences | Accounts not yet migrated |
| After retirement | Confirmation and data deletion notice | All affected |

## Programmatic signals
- [ ] Deprecation and Sunset headers on deprecated endpoints
- [ ] Deprecated tags in schemas and SDKs, with runtime warnings
- [ ] Status field in the API or console
- [ ] Entry in the deprecation registry with earliest removal date

## Key messages (approved by legal)
1.
2.
3.

## Feedback loop
Customer replies and tickets summarized weekly by theme; owner: [name].

# Model deprecation runbook · [Product]

**Owner:** [PM]   **Applied AI lead:** [name]   **Last reviewed:** [Date]

## Standing preparation (before any notice)
- [ ] Model register: every model dependency by feature, provider, channel, region, version or alias, and customer tier
- [ ] Each provider's published lifecycle states, notice periods and "not sooner than" dates recorded
- [ ] Subscriptions to provider notices; status fields checked on a schedule
- [ ] Eval suite per feature, including regression sets from past incidents
- [ ] Model abstraction so a swap is a configuration change plus evals
- [ ] Decision per feature: pinned version or alias, and why

## When a notice arrives
| Step | Action | Owner | Done |
|---|---|---|---|
| 1 | Log the notice: model, channel, region, retirement date | | |
| 2 | Set the internal deadline at least [30] days before retirement | | |
| 3 | List affected features, customers and contracts (including AI risk documentation commitments) | | |
| 4 | Shortlist candidate replacements | | |
| 5 | Run the eval suite on representative data; compare quality, latency and cost together | | |
| 6 | Adjust prompts, tools and parameters for the chosen candidate | | |
| 7 | Shadow or canary with a limited set of accounts | | |
| 8 | Notify customers if behavior, data handling, region or price changes; update AI documentation | | |
| 9 | Cut over with a tested rollback path | | |
| 10 | Record results; update the model register and documentation | | |

## Candidate comparison
| Candidate | Quality (eval pass rate) | Regression set result | Latency | Cost per task | Data handling or region change | Decision |
|---|---|---|---|---|---|---|
| | | | | | | |

## Escalation
If no candidate meets the quality bar before the internal deadline: [options, e.g., degrade the feature gracefully, restrict it to supervised mode, request a provider extension where offered, notify customers].

# AI PRD addendum · [Feature] · v[n] · [Date]

Attach to the standard PRD. Every section is required for AI-powered features.

## 1. Why AI
- The user problem (link to PRD):
- Why a rule-based solution isn't enough:
- Cost-of-error table:

| Error type | Example | Cost to user | Cost to business | Detectable by user? |
|---|---|---|---|---|
| False positive | | | | |
| False negative | | | | |
| Harmful or inappropriate output | | | | |
| Wrong action (agents) | | | | |

## 2. Pattern and autonomy
- Pattern: augmented model / chain / routing / parallel / orchestrator / evaluator-optimizer / agent
- Why the simpler patterns weren't enough:
- Autonomy per action class:

| Action class | Reversibility (cheap / costly / irreversible) | Autonomy (L1 to L5) | Approval and confirmation design |
|---|---|---|---|
| | | | |

- Stopping conditions and budgets: max steps [n], max tokens [n], max time [n], max spend per task [$]
- Escalation path when a limit is hit:

## 3. Quality (link to eval plan)
- Failure taxonomy (top modes):
- Capability eval targets:
- Regression eval threshold (target near 100%):
- Consistency target (pass^k):
- Accountable domain expert:

## 4. Models and data
- Models and providers (link to model register):
- Fallback when the provider is unavailable or degraded:
- Grounding sources and how they're permissioned:
- Personal and customer data handled, retention, residency:
- Training and feedback use permitted by contracts: yes / no / with consent
- Feedback signals captured and where they're stored:

## 5. Cost and latency (link to AI cost model)
- Cost per task at expected volume:
- Gross-margin floor:
- Latency budget: time to first token [ms], end to end [s]
- Cost levers in use: routing / caching / workflow caching / budgets

## 6. Trust and failure UX
- How capability and limits are communicated:
- Sources and confidence display:
- "I don't know" state:
- Correction, undo and regenerate:
- AI disclosure:
- Graceful degradation:
- Anti-rubber-stamping design (for approvals):

## 7. Risk and regulation (link to AI risk assessment)
- Our role: provider / deployer
- Likely risk tier and jurisdictions:
- Transparency and documentation duties:
- Security threats considered: prompt injection, data exfiltration, credential misuse

## 8. Rollout
| Stage | Entry criteria (evals and production evidence) | Who sees it | Exit criteria |
|---|---|---|---|
| Shadow | | | |
| Assisted | | | |
| Supervised | | | |
| Autonomous (allowlisted actions) | | | |

- Kill switch: who can pull it, and how fast it takes effect:

# Eval plan · [Feature] · [Date]

**Owner:** [PM or domain expert]   **Engineering owner:** [Name]   **Last run:** [Date]   **Gates releases:** yes / no

## Error analysis
- Traces reviewed: [n] on [dates], from [source]
- Reviewers:
- Failure taxonomy:

| # | Failure mode | Description | Example trace | Frequency in sample | Severity (H/M/L) |
|---|---|---|---|---|---|
| 1 | | | | | |

## Eval suite
| Suite | Type | # tasks | Grader (code / model judge / human) | Target | Current |
|---|---|---|---|---|---|
| [Failure mode 1] | Capability | | | | |
| [Existing behaviors] | Regression | | | ≥ 98% | |
| Should refuse or say "I'm not sure" | Capability | | | | |
| Consistency | pass^[k] | | | | |

## Judge validation (for each model judge)
| Judge | Failure mode | Human labels | True positive rate | True negative rate | Last validated |
|---|---|---|---|---|---|
| | | | | | |

## Run policy
- Runs on: every prompt change / model change / provider change / release
- Regression failure policy: block release / require approval from [name]
- Production sampling: [n] traces per [week], reviewed by [name]
- New failures from production become eval cases within [n] days

## History
| Date | Change | Capability score | Regression score | Notes |
|---|---|---|---|---|
| | | | | |

# AI cost model · [Feature] · [Date]

**Owner:** [PM]   **Finance partner:** [Name]   **Prices as of:** [Date]

## Per-task cost
| Step | Model | Calls per task | Input tokens | Output tokens | Cached share | Cost per call | Cost per task |
|---|---|---|---|---|---|---|---|
| | | | | | | | |
| **Total** | | | | | | | **$** |

Include retrieval, tool and infrastructure costs per task.

## Volume and margin
| Scenario | Tasks per month | Inference cost | Other COGS | Revenue | Gross margin |
|---|---|---|---|---|---|
| Low | | | | | |
| Expected | | | | | |
| High | | | | | |

- Gross-margin floor: [%]
- Cost per task at which the floor is breached: [$]

## Levers
| Lever | Expected saving | Quality risk | Status |
|---|---|---|---|
| Route [step] to a smaller model | | | |
| Cache [stable context] | | | |
| Convert [recurring path] to deterministic code | | | |
| Lower step or token budget | | | |

## Sensitivities
- If tokens per task rise 50%:
- If the provider raises prices 20%:
- If usage doubles in a quarter:

# Model and vendor register · [Product] · [Date]

| Feature | Model and version | Provider | Hosting region | Data sent | Training on our data? | Contract and DPA | Fallback model | Deprecation date | Last eval run | Owner |
|---|---|---|---|---|---|---|---|---|---|---|
| | | | | | | | | | | |

## Change policy
- Any model, version or provider change requires a regression eval run and sign-off from [name].
- Deprecation notices are reviewed [monthly]; migrations are planned at least [n] months before the date.
- Customers are notified of material model changes per [contract terms].

# AI risk assessment · [Feature] · [Date]

**Owner:** [PM]   **Reviewers:** [security, legal, privacy, responsible AI]   **Next review:** [Date]

## System description
- What it does, for whom, and what decisions or actions it influences:
- Our role: provider / deployer
- Jurisdictions and likely risk classification (confirm with counsel):

## Risks
| # | Risk | Category (accuracy, bias, privacy, security, safety, IP, transparency, over-reliance) | Likelihood | Impact | Mitigations | Residual risk | Owner |
|---|---|---|---|---|---|---|---|
| 1 | | | | | | | |

## Controls
- Human oversight design:
- Logging and audit (what is retained, for how long, who can access it):
- Transparency to users:
- Security: prompt injection, data exfiltration, credential scope:
- Monitoring and incident response (link):

## Documentation customers may request
- [ ] System description and intended use
- [ ] Data handling and residency
- [ ] Evaluation results and known limitations
- [ ] Human oversight and controls
- [ ] Incident response process
- [ ] Relevant certifications or framework alignment (for example ISO/IEC 42001, NIST AI RMF)

## Sign-off
| Role | Name | Date | Decision |
|---|---|---|---|
| | | | |

# AI workflow map · [PM name] · [Product] · [Date]

**Review cadence:** monthly   **Approved harness:** [tool and account tier]

## Map
| PM activity | Frequency | Time today | AI role (draft / synthesize / critique / monitor / prototype / none) | Frontier position (inside / edge / outside) | Context needed (context pack sections) | Connector or source | Verification check (pass or fail) | Human-only step | Ladder rung (1 to 6) | Target rung |
|---|---|---|---|---|---|---|---|---|---|---|
| Discovery synthesis (calls, interviews) | | | | | | | | | | |
| Support ticket and win/loss mining | | | | | | | | | | |
| PRD and narrative writing | | | | | | | | | | |
| Prototyping | | | | | | | | | | |
| Metrics review and analysis | | | | | | | | | | |
| Competitive monitoring | | | | | | | | | | |
| Roadmap and prioritization | | | | | | | | | | |
| Stakeholder updates | | | | | | | | | | |
| Meeting prep and follow-up | | | | | | | | | | |
| Review prep (QBR, exec, launch readiness) | | | | | | | | | | |
| Release notes and enablement | | | | | | | | | | |
| Post-launch and post-incident reviews | | | | | | | | | | |

Ladder rungs: 1 one-off prompt · 2 saved prompt in the library · 3 shared project with context pack · 4 skill (procedure plus checks) · 5 scheduled task with connectors · 6 agent with write access behind an approval gate.

## First three to change
1. Upstream activity:
2. Recurring report:
3. Drafting task:

## Never delegated
Decisions and trade-offs · commitments · prioritization calls · relationship moments · final sign-off on anything with my name on it.

## Monthly review
| Activity | Check catch rate | Editing effort (low / medium / high) | Outcome effect | Change next month |
|---|---|---|---|---|
| | | | | |

# Prompt · [Name]

**Owner:** [Name]   **Version:** [v1.0]   **Last reviewed:** [Date]   **Status:** Draft / Tested / In use / Promoted to skill / Retired

## Task
What this prompt does and when to use it:

## Inputs required
- Files or pasted material:
- Connectors (and scope):

## Context to attach
Context pack sections: [brief / personas / metrics / strategy / glossary / house style / other]

## Data classification allowed
Public / Internal / Confidential / Restricted (never)
Approved tools only. Remove personal identifiers where the task doesn't need them.

## Prompt
[Prompt text with [placeholders]]

## Output format
[Structure, length, headings, table columns]

## What good looks like
[Two or three success criteria, written so a colleague could judge them]

## Verification checks (pass or fail)
- [ ] Every number traces to a named source and date
- [ ] Every quote has a source ID and appears verbatim
- [ ] No commitments, dates or scope I didn't provide
- [ ] [Task-specific check]

## Known failure modes
- [What the model tends to get wrong here, and how the checks catch it]

## Test inputs
1. [Real past input, with the output you'd accept]
2.
3.

## Usage log
| Date | User | Check failures | Editing effort | Notes |
|---|---|---|---|---|
| | | | | |

## Promote to skill?
Yes when two or more PMs use it weekly and its checks have been stable for a month.

# Context pack · [Product] · [Date]

**Owner:** [PM]   **Review:** monthly   **Location:** [shared project in approved harness]

## Part 1: Always-loaded brief (one to two pages)

**One-liner:** [What the product does, for whom, and why it wins]

**Customers and personas**
| Persona | Role in the deal | Job story (short) | Main anxiety |
|---|---|---|---|
| | | | |

**Metrics** (every value dated)
| Metric | Definition | Current value | As of | Source |
|---|---|---|---|---|
| North Star | | | | |
| Input metric | | | | |

**Strategy:** pillars [1 to 3] · non-goals [what we will not do]
**This quarter's outcomes:** [1 to 3, with targets]
**Pricing and packaging:** [one paragraph]
**Competitive frame:** [main alternatives, including do nothing]
**Decision rights:** [who decides what]
**Glossary:** [terms the model must use exactly]
**House style:** [tone, format rules, banned words, how we write numbers]
**Standing instructions:** cite sources for every number and quote; say "unknown" rather than guess; never invent customer facts; flag anything that contradicts this brief.

## Part 2: Referenced documents (loaded when needed)
| Document | What it's for | Location | Owner | Last updated | Confidentiality |
|---|---|---|---|---|---|
| Full personas | | | | | |
| Opportunity solution tree | | | | | |
| Roadmap | | | | | |
| Metric definitions | | | | | |
| Competitive map | | | | | |
| Decision log | | | | | |
| Recent research summaries | | | | | |
| Open risks | | | | | |

## Rules
- Date every number. Remove or update stale values at the monthly review.
- One owner per section.
- Mark confidentiality per file. Nothing restricted goes in a shared project.
- Test after each change: five questions with known answers.

# AI usage policy · [Team] · v[n] · [Date]

**Owner:** [Product ops lead]   **Approved by:** [VP Product, Security, Legal]   **Review:** quarterly

## 1. Purpose
Help the team use AI widely, openly and safely, with judgment and accountability staying human.

## 2. Approved tools
| Tool | Account tier | Data retention and training terms | Who may use it |
|---|---|---|---|
| | | | |
Personal or consumer accounts are not approved for company data.

## 3. Approved connectors
| Connector | Scope (read / write) | Approval gate for writes | Owner |
|---|---|---|---|
| | | | |

## 4. Data classes
| Class | Examples | Where it may go |
|---|---|---|
| Public | | Any approved tool |
| Internal | | Approved tools |
| Confidential (customer data, roadmap, financials) | | Approved enterprise tools and named projects only |
| Restricted | Credentials, unannounced results, personal data beyond need | Never |

## 5. Verification standard
| Output type | Required checks before use |
|---|---|
| Customer-facing or executive document | Every number sourced and dated; every quote with source ID; no new commitments |
| Research synthesis | Themes trace to two or more sources; quotes verbatim; single-source items flagged |
| Analysis | Question, definitions and data range stated; causal claims backed by a comparison |
| Competitive claims | Dated source for each |

## 6. Disclosure
- AI use is expected and disclosed, never hidden.
- Label AI-assisted drafts in reviews.
- Never present synthesized or paraphrased text as a verbatim customer quote.
- Never present synthetic or AI-generated respondents as research.

## 7. Agents and automation
- Every scheduled task and agent has a named owner who reads its output.
- Human approval before any send, write, delete or external action.
- Content from outside the company (email, web, documents) is data, never instructions.
- Rules that must never fail are enforced by permissions, not by prompts.

## 8. Do not delegate
Decisions and trade-offs · commitments to customers, partners and executives · prioritization calls · escalations, bad news, negotiation and coaching · final sign-off on anything with your name.

## 9. AI literacy and onboarding
[Short onboarding for new team members: this policy, the library, the context packs, the verification standard, two supervised tasks.]

## 10. Reporting AI mistakes
How to report: [channel]. What to include: task, tool, what went wrong, how it was caught, fix. Reviewed monthly; no blame for reporting.

## 11. Review
Quarterly, or after any AI-related incident.

# Weekly AI-assisted operating routine · [PM] · [Product]

| Day | AI-assisted task (rung) | Delivered by | Human step that follows | Time |
|---|---|---|---|---|
| Monday | Metrics digest against the context pack: what changed, ranked hypotheses (scheduled task) | [time] | Write the "so what" and the decisions; flag anything to investigate | 30 min |
| Tuesday | Discovery synthesis of last week's calls and tickets (skill) | [time] | Read the single-source and surprise items; update the opportunity tree | 45 min |
| Wednesday | Drafting block: interview me, brief, draft, review against the brief (saved prompts) | On demand | Rewrite the opening and the recommendation; decide what ships | 2 hrs |
| Thursday | Stakeholder prep: pre-reads, likely objections, red team (saved prompt) | On demand | Rehearse answers; decide what to concede | 45 min |
| Friday | Competitive diff with dated sources (scheduled task) | [time] | Decide what, if anything, changes in positioning or roadmap | 30 min |
| Friday | Library upkeep: retire, refine, promote; review what AI got wrong this week | Manual | Log failures; update checks | 15 min |
| Daily | Meeting prep and follow-ups drafted from notes (saved prompt) | After each meeting | Read and send yourself; correct owners and dates | 10 min each |

## This week's AI misses
| Task | What went wrong | Caught by | Fix to prompt, check or context |
|---|---|---|---|
| | | | |

## Outcome check (monthly)
Discovery touchpoints per week: [n] · Hours spent on report assembly: [n] · Decisions logged: [n] · Errors caught before release: [n]

# Skill spec · [Name]

**Owner:** [Name]   **Promoted from:** [prompt library entry and version]   **Date:** [Date]

## When the harness should use it
[One or two sentences the model reads to decide whether this skill applies]

## Procedure
1. [Step]
2. [Step]
3. [Step]

## Inputs and connectors
- [Source] · scope: read / write

## Output format and example
[Structure, plus one canonical example of good output]

## Built-in checks (pass or fail)
- [ ]
- [ ]

## Who can start it
Anyone / Only a person (required for skills that send, write or publish)

## Test cases
| Input | Expected result | Last run | Pass / Fail |
|---|---|---|---|
| | | | |

## Change log
| Date | Change | Reason |
|---|---|---|
| | | |

# AI use-case risk triage · [Product] · [Use case] · [Date]

**Owner:** [PM]   **Reviewed by:** [legal / privacy / security]   **Next review:** [Date or trigger]

## The use case
- What it does, in one sentence:
- Who uses it, and who is affected by its output:
- Model(s) and provider(s):
- Data it reads (including any personal data):
- What it can change (none / suggests only / acts with approval / acts autonomously):

## Role
- Our EU AI Act role: provider / deployer / both
- Could a customer or partner become a provider (own branding, substantial modification, new high-risk purpose)? [yes/no, how]

## Screens
| Screen | Answer | Reasoning |
|---|---|---|
| Any prohibited practice (Art. 5)? | | |
| In an Annex III area? Which one? | | |
| Profiles people? (if yes and Annex III: high-risk) | | |
| Article 6(3) conditions claimed, if any | | |
| Annex I regulated product? | | |
| Interacts with people or generates content (Art. 50)? | | |
| Personal data: DPIA trigger likely? | | |
| Other jurisdictions in scope (US states, Korea, China, others) | | |

## Internal tier
Low / Medium / High, because [reason]. Review track: light / standard / full board.

## Open questions for counsel
1.

## Decision
[Proceed / proceed with conditions / stop], decided by [name] on [date].

# AI impact assessment · [Product] · [Use case] · v[n] · [Date]

**Owner:** [PM]   **Contributors:** [applied AI, security, privacy, legal, UX]   **Linked:** triage, DPIA [link or n/a], FRIA support [link or n/a]

## 1. Purpose and boundaries
- Intended purpose:
- Intended users and settings:
- Prohibited and out-of-scope uses (as they will appear in terms and docs):

## 2. Affected people
| Group | How they are affected | Can they see or contest the output? |
|---|---|---|
| | | |

## 3. Harms
| # | Harm | Principle or NIST GAI risk | Who is harmed | Likelihood | Severity | Current evidence |
|---|---|---|---|---|---|---|
| 1 | | | | | | |

## 4. Mitigations as requirements
| Harm # | Requirement | Acceptance test (eval, gate, log field, UX) | Backlog item | Owner |
|---|---|---|---|---|
| | | | | |

## 5. Human oversight
- Who reviews or approves, at which step, with what information:
- How a user overrides or stops the system:

## 6. Data
- Personal data involved, retention, residency, sub-processors:
- Training on customer data: yes / no; if yes, basis and opt-out:

## 7. Fairness and performance
- Slices evaluated (segment, language, region, other):
- Results and gaps:

## 8. Residual risks
| Risk | Why accepted | Accepted by | Revisit by |
|---|---|---|---|
| | | | |

## 9. Change triggers
Re-assess on: new model or version, new tool permission, new data source, new market, new autonomy level, or a severity 1 or 2 incident.

# System card · [Product or feature] · v[n] · [Date]

Audience: customer security, compliance and admins. Every claim must be confirmed by its engineering owner.

## Overview
- What the system does and for whom:
- Intended purpose and prohibited uses:
- Our role and the customer's role (EU AI Act):

## Models
| Use | Model and version | Provider | Hosting region | Provider documentation |
|---|---|---|---|---|
| | | | | |

## Data flows
- Data the system reads, from where (connectors, MCP servers):
- What is stored, where, for how long:
- Training on customer data: [default and options]
- Sub-processors:

## Tools, permissions and autonomy
| Action class | Permission scope | Autonomy level (suggest / approve / autonomous) | Who can change it |
|---|---|---|---|
| | | | |

## Evaluation
- What we test, how often, and on what data:
- Current results (headline metrics and slices):
- Red-team scope and date of last exercise:

## Known limitations
-

## Human oversight and controls
- Approval gates, overrides, kill switch:
- Audit logs: fields, retention, customer access and export:

## Transparency to end users
- How users know content or actions are AI-generated:
- Content marking (if the system generates media or published text):

## Monitoring and incidents
- What we monitor in production:
- How customers report a problem; how we notify them:

## Change log
| Date | Change | Re-reviewed? |
|---|---|---|
| | | |

# AI red-team plan · [Product] · [System version] · [Dates]

**Owner:** [PM or applied AI lead]   **Security partner:** [name]   **Retest date:** [Date]

## Objective
What decision this exercise informs (for example, beta go or no-go):

## Scope
- System version, environment (never production customer data unless approved):
- In scope: [features, tools, connectors]
- Out of scope:

## Harm and attack categories
| Category | Source (impact assessment, NIST GAI risk, OWASP LLM or Agentic item) | Priority |
|---|---|---|
| | | |

## Red-team types and people
- Expert: [who]
- General users or domain practitioners: [who]
- AI-generated attacks: [approach and volume]

## Scenarios
| # | Scenario | Seed or example | Expected safe behavior | Failure definition |
|---|---|---|---|---|
| 1 | | | | |

## Severity scale
- S1: could cause harm in production or expose customer data
- S2: unsafe or wrong behavior with a plausible path to harm
- S3: policy or quality violation without direct harm
- S4: cosmetic

## Rules of engagement and data handling
-

## Findings
| # | Scenario | Severity | Reproduction | Fix | New eval case | Status |
|---|---|---|---|---|---|---|
| | | | | | | |

## Decision
[Proceed / proceed with conditions / hold], decided by [name] on [date].

# AI incident response plan · [Product] · v[n] · [Date]

Extends the company security incident process. Link: [process]

## AI-specific triggers
- Confident wrong output affecting many users or a high-impact decision
- Unsafe or unintended agent action
- Prompt injection or tool misuse that changed system behavior
- Personal or confidential data exposed through outputs
- Fairness or bias finding
- Unannounced behavior change after a model or provider update

## Severity
| Level | Definition for this product | Example | Response time |
|---|---|---|---|
| 1 | | | |
| 2 | | | |
| 3 | | | |

## Controls available
| Use case | Kill switch or degrade option | Who can trigger | Time to effect |
|---|---|---|---|
| | | | |

## Roles
- Incident lead: [name]
- PM (customer impact, comms, eval follow-up): [name]
- Applied AI (diagnosis, model or prompt rollback): [name]
- Security, privacy, legal: [names]

## Clocks to check (confirm with counsel)
- Contractual notification commitments: [summary]
- GDPR personal data breach notification, if personal data is involved
- EU AI Act Article 73 serious incident reporting, for high-risk systems once applicable
- Other: [jurisdiction or customer specific]

## Customer communication
- First notice within [time], containing: what happened, what we changed, what customers should do, when we will update next.

## After the incident
- [ ] Root cause (data, retrieval, prompt, model, tool, UX, process)
- [ ] New eval cases added and passing
- [ ] System card and impact assessment updated
- [ ] Decision log entry
- [ ] Tabletop scheduled for the next quarter

# AI security questionnaire answer bank · [Product] · [Date]

Structure follows the domains your customers use most (for example, the AI-CAIQ). One canonical answer per question. A named owner approves every answer before it goes to a customer.

| ID | Domain | Question (canonical form) | Answer | Evidence (doc, report, control) | Frameworks satisfied (ISO/IEC 42001, NIST AI RMF, EU AI Act, other) | Owner | Last reviewed | Confidential? |
|---|---|---|---|---|---|---|---|---|
| G-01 | Governance | Do you have an AI policy and a review process? | | | | | | |
| M-01 | Models and suppliers | Which models and providers do you use, and where are they hosted? | | | | | | |
| D-01 | Data use | Do you train on customer data? | | | | | | |
| P-01 | Privacy | Can you support our DPIA? | | | | | | |
| S-01 | Security | How do you defend against prompt injection and tool misuse? | | | | | | |
| E-01 | Evals and testing | How do you test quality, safety and fairness? When was your last red team? | | | | | | |
| H-01 | Oversight | What can the system do without human approval, and how is it stopped? | | | | | | |
| T-01 | Transparency | How do users know they are interacting with AI? | | | | | | |
| I-01 | Incidents | How will you notify us of an AI incident? | | | | | | |
| R-01 | Regulation | What is your EU AI Act role and risk classification? | | | | | | |

## Rules
- Answers cite evidence; if there is no evidence, the answer says what exists and what is planned, with a date.
- New questions not in the bank are answered by hand, then added.
- Review every answer at least every [six] months and after any material change.

# Responsible AI review · [Product] · [Use case] · Gate: [PRD / pre-beta / pre-GA / material change] · [Date]

**Presenter:** [PM]   **Approver (can block):** [name]   **Attendees:** [applied AI, security, privacy, legal, UX]

## Evidence presented
- [ ] Triage with role, tier and transparency duties; counsel's view recorded
- [ ] Impact assessment, current version
- [ ] DPIA status (needed / done / not needed, with reason)
- [ ] Eval results, including slices and regression suite
- [ ] Red-team findings and their status (pre-beta and later)
- [ ] System card and instructions for use (pre-GA and later)
- [ ] Incident plan with kill switches tested (pre-GA and later)
- [ ] Disclosure and content marking in the UX
- [ ] Logging that meets deployer retention needs
- [ ] Questionnaire answer bank updated

## Questions the approver asks
1. What is the worst thing this system can do, and what stops it?
2. Who could be treated worse, and how would we know?
3. What changed since the last review?
4. Which residual risks are we accepting, and who owns them?

## Decision
- [ ] Approved   - [ ] Approved with conditions: [conditions, owners, dates]   - [ ] Not approved: [what is needed]

Recorded in the decision log by [name] on [date].

# Audience analysis · [Document or proposal] · [Date]

**Narrowed objective (one sentence):** [Action] by [decider] by [date], scope: [included / excluded]
**Decision type:** One-way door / Two-way door / Split (explain)
**Document type:** Email / One-page proposal / Decision memo / Six-page narrative / PR/FAQ

## Readers
| Reader | Role in decision (decide / veto / advise / execute / informed) | What they know | What they believe now | What they care about and are measured on | What they fear | How they will read it | Lead appeal (ethos / pathos / logos) |
|---|---|---|---|---|---|---|---|
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |

## The objection most likely to sink this
[Who holds it, in their words, and how the document answers it]

## Curse-of-knowledge check
Terms, acronyms and references a reader outside the work won't know:
- [Term]: define / remove

## Pre-wiring plan
| Reader | Share draft by | Channel | Their feedback | How the document changed |
|---|---|---|---|---|
| | | | | |

# [Title that states the recommendation, e.g. "Hold the autonomous tier one quarter"]

**Decision needed from:** [Name]   **By:** [Date and why that date]   **Author:** [PM]   **Decision type:** One-way / Two-way door

## The ask
[One or two sentences the decider could approve by replying "yes."]

## Why now
[Situation: what the reader already accepts.] [Complication: what changed, with a number.] [Question: what this raises.] [Answer: the ask, restated.]

## Recommendation and reasons
1. **[Reason 1]**: [strongest evidence, with source]
2. **[Reason 2]**: [strongest evidence, with source]
3. **[Reason 3]**: [strongest evidence, with source]

## Options considered
| Option | What it costs | Why not |
|---|---|---|
| Do nothing | | |
| [Option B] | | |
| **Recommended** | | |

## Risks and what would change my mind
- Risk: [risk] · Mitigation: [mitigation]
- I would change my recommendation if [specific, observable condition].

## Cost and next steps
| Step | Owner | Date |
|---|---|---|
| | | |

---
*How this was made: [e.g. "Drafted with an AI assistant from (sources); every number checked against source systems by (name)."]*

# PR/FAQ · [Product or feature] · Draft v[n] · [Date]

**Author:** [PM]   **Reviewers:** [names]   **Status:** Draft / In review / Approved / Shelved

## Press release (under one page)

### [Heading: the product named so the target customer understands it, one sentence]
#### [Subheading: who the customer is and the benefit they get, one sentence]

**[City] · [Outlet] · [Planned launch date]**: [Summary paragraph: what the product is and its main benefit.]

**The problem.** [The customer's problem, from the customer's point of view, in their words.]

**The solution.** [How the product solves it, how it differs from today's alternatives (including doing nothing), and how to get started.]

"[Quote from a company spokesperson: why we built it.]" said [name, title].

"[Quote from a hypothetical customer: the outcome in their words.]" said [persona, role, company type].

**Getting started.** [How easy it is to start, and where to go.]

## External FAQ (customers and press)
1. How much does it cost?
2. How does it work?
3. How do I get help?
4. Where and how do I buy it?
5. [What does it access, and how is my data handled?]

## Internal FAQ (stakeholders; five pages or fewer for the whole FAQ)
1. Who has this problem, how many of them are there and how many will pay?
2. How does this beat the alternatives on quality, cost or speed? Who are the competitors?
3. How big is the market we can actually serve?
4. What edge cases matter, and how do we handle them?
5. What are the hardest technical, operational, legal and design problems? What new capabilities do we need?
6. What do we depend on (partners, platforms, other teams)?
7. What regulatory or compliance questions apply?
8. What are the unit economics, the upfront investment and the time to payback?
9. For AI products: what is the autonomy level, how do users notice when it's wrong and what is the blast radius?
10. What must be true for this to succeed, and what are the top three reasons it could fail?

# [Title stating the proposal] · Narrative · [Date]

**Author:** [PM]   **Meeting:** [date]; silent reading in the first minutes   **Decision needed:** [one sentence]

This outline is a recommended shape, not an official format. Write in full paragraphs; tables and charts are fine where they carry data. Six pages is a ceiling.

## 1. Context and question (half a page)
The situation, the complication and the question this document answers. End with the answer in one sentence.

## 2. Tenets (a few lines)
The principles we're using to decide, stated so a reader can disagree with them.

## 3. Where we are today (one page)
The current state, with data and sources. What customers say, in their words. What we've tried.

## 4. The proposal (one and a half pages)
What we'll do, for whom and why. How it serves the tenets. What success looks like, in metrics.

## 5. Alternatives considered (half a page)
Each serious alternative, including doing nothing, and why we didn't choose it.

## 6. Risks and mitigations (half a page)
What could go wrong, how we'd know early and what we'd do. What would change our mind.

## 7. Plan and ask (half a page)
Milestones, owners, cost and the specific decisions needed from this meeting.

## 8. Open questions
What we don't know yet, and how we'll find out.

## Appendix (not counted in the six pages)
Supporting data, detailed models, customer evidence, glossary.

---
*How this was made: [AI use and verification line]*

# Decision: [the decision, stated as a sentence] · [Date]

**Decider:** [Name]   **Author:** [PM]   **Status:** Proposed / Decided / Revisited
**Decision type:** One-way door / Two-way door / Split: [which part is which]
**Information confidence:** [roughly how much of what we'd want to know we have, and what's missing]

## Context
[Two or three sentences: the situation and complication.]

## Options
| Option | Benefits | Costs and risks | Reversible? |
|---|---|---|---|
| | | | |

## Decision
[What was decided, by whom, and the main reasons.]

## Dissent and commitment
| Person | Concern | Committed? |
|---|---|---|
| | | Yes / No |

## Conditions and review
- We will revisit if: [observable trigger]
- Review date: [date]   Forum: [governance forum or business review]

## Consequences
[What changes now: roadmap, owners, messages to customers or teams.]

Subject: [Decision needed / FYI / Approval needed] by [date]: [the ask in under ten words]

[Name],

[The ask in one sentence that can be answered with one word.] [The date and why.]

- [Reason 1, one line]
- [Reason 2, one line]
- [Reason 3, one line]

[Cost of saying no, one sentence.] [What you'll do if you hear nothing, and when.]

Full proposal: [link]

[Your name]

---
Checks before sending:
- Under about 150 words.
- The first line works alone in a preview pane or an AI summary.
- First line tailored to this reader's main concern.
- Every number checked against its source.

# Presentation plan · [Meeting] · [Date]

**Presenter:** [PM]   **Slot:** [minutes]   **Format:** In person / Virtual / Hybrid / Recorded

## The decision
- Decision this meeting exists to make:
- Decision maker:
- People who can block it:
- Cost of not deciding (or of deciding late):

## Audience analysis
| Person | Role in the decision | What they know | What they believe today | What they fear | What they need to leave with |
|---|---|---|---|---|---|
| | | | | | |

## Objective
- They will **know**:
- They will **feel**:
- They will **do**:

## Big Idea (one sentence)
[Audience] should [act or believe] because [our point of view], and if they don't, [what's at stake].

## The hero
Who changes as a result of this presentation, and what stands in their way:

## Mode
Pre-read plus discussion / Talk with visuals / Written update only / Async video. Why this mode:

## The 3-minute story
[Big Idea plus the two or three most important supporting points, written as you'd say them]

## The 5-minute cut
What survives if the slot shrinks:

## Evidence needed
| Claim | Evidence | Source | Owner | Ready? |
|---|---|---|---|---|
| | | | | |

## The ask (exact words)
"[...]"

## Success signal
How we'll know afterward that the objective was met:

# Executive briefing · [Topic] · [Date]

**Presenter:** [PM]   **Decision maker:** [Name]   **Pre-read sent:** [Date]

## 1. The ask and recommendation (first 60 seconds)
- We are asking you to: [decision]
- We recommend: [option], because [one sentence].
- If we don't decide by [date]: [consequence].
- Format note to say aloud: "Summary first, then discussion. Detail is in the appendix."

## 2. Context (Situation, Complication, Question)
- Situation (what we all agree on):
- Complication (what changed):
- Question (what we must decide):

## 3. Supporting arguments (one action title and one chart each)
1. [Action title] · Evidence: [chart or data] · Source:
2. [Action title] · Evidence: · Source:
3. [Action title] · Evidence: · Source:

## 4. Options and trade-offs
| Option | What we get | What it costs | Main risk | Our view |
|---|---|---|---|---|
| Recommended | | | | |
| Alternative | | | | |
| Do nothing | | | | |

## 5. Risks and what would change our mind
- Risk · Mitigation · Owner
- We'd change our recommendation if: [evidence]

## 6. Next steps if approved
| Step | Owner | Date |
|---|---|---|
| | | |

## Appendix index
| Slide | Covers | Likely question it answers |
|---|---|---|
| A1 | | |

# Data story · [Topic] · [Audience] · [Date]

## Big Idea
[One sentence: point of view plus what's at stake]

## What the audience expects to see
[Their current belief, named before the new finding]

## The chart that proves it
- Action title (full-sentence takeaway):
- Chart type and why:
- What to highlight (color or emphasis):
- What to gray out or remove:
- Annotations (events, launches, changes):
- Source and date range:

## Context chart (optional, at most one)
- Action title:
- Why the main chart needs it:

## Uncertainty
- Range or confidence interval:
- Sample size (n) and time period:
- Method in one line:
- Estimative words used, with their numeric meaning:
- What this data can't tell us:

## Findings (what the data shows)
1.
2.

## Recommendation (what we propose to do; kept separate from findings)
-

## If the audience accepts the data but rejects the recommendation
Options to offer:

# Q&A prep · [Meeting] · [Date]

| # | Question (in the asker's words) | Likely asker | One-sentence answer | Evidence | Appendix slide | If I don't know: who follows up, by when |
|---|---|---|---|---|---|---|
| 1 | | | | | | |
| 2 | | | | | | |
| 3 | | | | | | |
| 4 | | | | | | |
| 5 | | | | | | |
| 6 | | | | | | |
| 7 | | | | | | |
| 8 | | | | | | |
| 9 | | | | | | |
| 10 | | | | | | |

## The question I most hope nobody asks
- Question:
- Honest answer:

## Pushback pattern
Acknowledge (restate the concern) · Answer (one sentence) · Anchor (one piece of evidence) · Advance (back to the ask, or what would change my view)

## Questions I won't answer in this room, and why
[For example, unannounced roadmap in a mixed audience. Prepared redirect:]

# [Product or feature]: how well it works · [Date]

## What it's for
[Intended use, in one sentence]

## What it isn't for
[Uses we don't support or recommend]

## How we tested it
- Eval set: [description, size n, how built]
- Production data: [period, number of cases]
- Offline eval and production results are labeled separately below.

## How it performs
| Measure | Result | 95% interval | n | Offline or production |
|---|---|---|---|---|
| | | | | |

## By segment
| Segment | Result | Interval | n |
|---|---|---|---|
| | | | |

## Known failure modes
| Failure | How often (with range) | What the product does when it happens | Fix status |
|---|---|---|---|
| | | | |

## Representative examples
Two successes and two failures, chosen to be typical rather than best.

## Wording rules on this slide
No single number without its range and n. No improvement claimed that is smaller than the interval. No "understands," "knows" or "thinks."

# Rehearsal checklist · [Meeting] · [Date]

## Content
- [ ] Full run, timed: [minutes] against a slot of [minutes]
- [ ] 5-minute cut run, timed
- [ ] 3-minute story said aloud without slides
- [ ] First 60 seconds and last 60 seconds said without notes
- [ ] Titles-only read: the action titles alone tell the story
- [ ] Someone outside the team says back the ask correctly

## Numbers
- [ ] Every number checked against its source; source in speaker notes
- [ ] Every chart's scale and axis checked
- [ ] Every estimative word ("likely," "most") has a number or range
- [ ] AI results show range and sample size

## Delivery
- [ ] Recorded run reviewed (or AI rehearsal report) for pace, filler words and reading slides
- [ ] Pause planned after the ask
- [ ] Numbers slowed down: number, unit, comparison

## Q&A
- [ ] Q&A prep sheet complete, ten questions
- [ ] Murder board run with the hardest personas (human or AI)
- [ ] Appendix slides findable in under ten seconds

## Setup
- [ ] Virtual: camera, audio, screen share, captions tested; self-view hidden
- [ ] Ask written in the chat or on screen for virtual audiences
- [ ] Demo: recorded fallback ready; scripted or prepared data labeled
- [ ] Pre-read sent [date]; follow-up template ready
- [ ] Deck built only in tools approved for this data

# Stakeholder map · [Product or initiative] · [Date]

**Owner:** [PM]   **Scope:** Internal / External   **Next review:** [Date, at least quarterly]

| Name and role | Team | Power (H/M/L, with reason) | Interest (H/M/L) | Quadrant | Current stance | Desired stance, by when | What they're measured on (their currency) | What they fear | Relationship owner | Last touch | Next action |
|---|---|---|---|---|---|---|---|---|---|---|---|
| | | | | | | | | | | | |

Quadrants: Manage closely (high power, high interest) / Keep satisfied (high power, low interest) / Keep informed (low power, high interest) / Monitor (low power, low interest).

Stance: Champion / Supporter / Neutral / Skeptic / Blocker.

## Sleeping gatekeepers
High-power stakeholders who could block late (security, legal, finance, procurement) and the date each moves to "manage closely":
1.
2.

## Evidence for stance
For each stance rating, link what the person actually said or did, with dates. Refresh from evidence, not memory.

# Stakeholder engagement plan · [Product or initiative] · [Quarter]

**Owner:** [PM]   **Linked map:** [link]

| Stakeholder or group | Quadrant | Objective (inform / consult / involve / decide) | Message or ask | Channel (1:1, written update, review forum, demo) | Cadence | Owner | Signal they're engaged | Risk if neglected |
|---|---|---|---|---|---|---|---|---|
| | | | | | | | | |

## Pre-wiring before key decisions
| Decision | Date | Stakeholders to pre-wire | Likely objection | Evidence that answers it | Done |
|---|---|---|---|---|---|
| | | | | | |

## Upward rhythm
- Weekly written update to [manager]: outcomes moved, decisions needed, risks, asks.
- No-surprises items (always escalate within 24 hours): [list]

## Request intake
Requests from [functions] arrive through [channel] with: problem, affected customers or accounts, revenue at stake, deadline, other customers with the same need.

# DACI: [Question we're trying to answer]?

**Status:** Not started / In progress / Decided   **Impact:** High / Medium / Low   **Due date:** [Date]

## People
| Role | Name |
|---|---|
| Driver (runs the process, gets a decision by the date) | |
| Approver (one person only) | |
| Must agree (veto for must-meet requirements, such as legal or security; use sparingly) | |
| Contributors (voice, no vote) | |
| Informed (told the outcome afterward) | |

## Background
[One or two sentences: why this decision, why now.]

## Relevant data
[Metrics, eval results, customer evidence, incident reviews, cost. Link sources.]

## Decision factors
1. [Factor, and how it will be weighed]
2.
3.

## Options considered
| Option | Description | Pros | Cons | Resources and cost | Must-agree requirements met? |
|---|---|---|---|---|---|
| A | | | | | |
| B | | | | | |
| C | | | | | |

## Pre-wiring log
| Contributor | Date | Position | Concern raised | How the options changed |
|---|---|---|---|---|
| | | | | |

## Outcome
[Decision, decided by (Approver) on (date). Reason in one paragraph. Options rejected and why.]

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

## Disagreements recorded
[Who disagreed, on what, and their confirmation that they commit to the decision.]

Format after Atlassian's DACI play, with a "Must agree" role borrowed from Bain's RAPID.

# Team charter · [Team name] · v[n] · [Date]

**Review date:** [3 to 6 months out]   **Charter owner:** [PM or lead]

## Mission
[One sentence: why this team exists.]

## Customers and problems we own
-
-

## Outcomes and metrics
| Outcome | Metric | Baseline today | Target | By when |
|---|---|---|---|---|
| | | | | |

Hard constraints (must never be violated): [for example, zero unapproved actions]

## Out of scope
[What this team does not own, and who does.]

## Members and roles
| Name | Role (PM, design, tech lead, engineering, applied AI, PMM) | Accountable for | Top 3 to 5 responsibilities |
|---|---|---|---|
| | | | |

Overlapping responsibilities and their named primary owner:

## Decision rights
| Decision type | Who decides | Must agree | Consulted |
|---|---|---|---|
| Roadmap priorities within our area | | | |
| Shipping to general availability | | | |
| Customer-specific requests | | | |
| [Other recurring decision] | | | |

## Key stakeholders and engagement
| Stakeholder | What they need from us | Cadence and channel |
|---|---|---|
| | | |

## Working agreements
- Core hours and time zones:
- Channels (urgent, async, decisions):
- Meetings (purpose, cadence, sync or async):
- How we give and receive feedback:
- How we raise bad news (eval regressions, incidents, slipped dates):

## Escalation path
When we can't agree: [step 1], then [step 2], decided by [role] within [time]. Decisions shared via [channel] and logged in [location].

## Interfaces and dependencies
| Team or system | What we depend on, or what depends on us | Contact |
|---|---|---|
| | | |

# PM competency self-assessment · [Name] · [Level] · [Period]

**Manager or coach:** [Name]   **Check-in date:** [Date]

Rate 1 to 5 against the expectation for your level (1 = well below, 3 = meets, 5 = well above). Every rating needs evidence from the last two quarters.

| Competency | Expectation at my level | Self-rating | Evidence (links to artifacts, decisions, outcomes) | Manager rating | Gap | One development action |
|---|---|---|---|---|---|---|
| Problem discovery | | | | | | |
| Customer insight | | | | | | |
| Data fluency (questions, evidence, reports) | | | | | | |
| Product definition for humans and agents | | | | | | |
| Delivery | | | | | | |
| AI product judgment (evals, cost, risk) | | | | | | |
| Strategy and roadmap | | | | | | |
| Business outcome ownership | | | | | | |
| Stakeholder influence | | | | | | |
| Communication (writing and presenting) | | | | | | |
| Managing up | | | | | | |
| Team leadership and coaching | | | | | | |

## Focus for next quarter (one or two competencies)
| Competency | Real work that will exercise it | What good looks like by [date] | Support needed |
|---|---|---|---|
| | | | |

## Strengths to use more
-

# 1:1 · [Name] and [Manager or coach] · [Date]

The 1:1 belongs to [Name]. Their agenda comes first.

## Their agenda
1.
2.

## Wins since last time
-

## One challenge, coached with GROW
- **Goal:** what do you want from this conversation, and from this problem?
- **Reality:** what is true now? What evidence do you have? What have you tried?
- **Options:** what could you do? What else? What would you advise someone else to do?
- **Will:** what will you do, by when? How will I know?

## Feedback, both ways
- From me (specific, with an example; care personally and challenge directly):
- From you to me:

## Competency focus this quarter
[From the self-assessment.] Progress since last time:

## Commitments
| Who | What | By when |
|---|---|---|
| [Name] | | |
| [Manager] | | |

## What I owe you
[Introductions, decisions, air cover, resources.]

## For a first 1:1, also ask
- What frustrates you at work, and how will I be able to tell?
- How do you like to get feedback and recognition: in public or in private?
- What would make our 1:1s useful to you?
- What are your short- and long-term goals? What do you need from me, the team and your peers?
- Do you have enough challenge, time to reflect and timely feedback right now?

# 30/60/90 plan · [Product surface area] · Start date [date]

**PM:** [name]   **Manager:** [name]   **Reviewers:** [peers, engineering lead, design lead]
**Last updated:** [date]   **Status:** Draft / Agreed with manager / In progress / Closed

## Scope paragraph
[One paragraph: products, customers, teams, revenue. Note any boundary disputes and their decision log IDs.]

## Expectations agreed with my manager
- What success looks like at day 90:
- Decisions my manager expects me to bring:
- How and how often we'll review progress:

## Days 1 to 30: learn and anchor
**Goals:**
-
**Artifacts to deliver:** Product 360 index (spine 1), stakeholder map and DACI draft (spine 12), decision log opened, gap list, urgent event artifacts: [list]
**Grilling sessions:** facts only. [Dimensions and dates]
**File-mode questionnaires sent to:** [owner: dimension]
**Listening tour:** [names and roles, including at least five customers across the buying group]
**Early decision to land:** [decision, decider, date]
**Exit criteria:** gap list approved; index published; stakeholder map reviewed by manager; one decision logged
**Risks:**

## Days 31 to 60: decide and build the spine
**Goals:**
-
**Grilling sessions (dependency order):**
| Dimension | Mode (live / file) | Date | Participants | Log ID |
|---|---|---|---|---|
| Customer | | | | |
| Strategy | | | | |
| Business | | | | |
| Measure | | | | |
| Build | | | | |
| Go-to-market | | | | |
| AI (if AI-powered) | | | | |

**Artifacts to deliver:** spine 2 to 9; AI four if applicable: [list]
**Stakeholder reviews:** [artifact: reviewer]
**Consistency audit date:** [day 60]
**Exit criteria:** spine 2 to 9 drafted from approved logs; audit run; every contradiction fixed or logged
**Risks:**

## Days 61 to 90: operate and prove
**Goals:**
-
**Cadence started:** weekly exception brief from [date]; monthly roadmap refresh on [date]; QBR on [date]
**Artifacts to deliver:** operating cadence (spine 10), lifecycle stage assessment (spine 11), event artifacts: [list with dates]
**Health review date:** [date]
**Exit criteria:** four weekly cycles run; QBR held from the 360; health review scored against Appendix C; next quarter's focus dimension chosen
**Risks:**

## What I will not do in the first 90 days
-
-

## Day-90 close
**Premortem for next quarter:**
**Weakest dimension and next quarter's focus:**
**Open grilling items carried forward:** [count and IDs]

# Product 360 build tracker · [Product] · Updated [date]

**Owner:** [PM]   **Index:** [link]
Status values: Not started / Grilling / Drafted / Audited / Published / Re-grill due

## Spine
| # | Artifact | Dimension | Kind | Template | Source materials | Grilling log ID | Owner | Status | Last reviewed | Next review | Open items |
|---|---|---|---|---|---|---|---|---|---|---|---|
| 1 | Product 360 index | All | Living | product-360-index | | | | | | | |
| 2 | Problem hypothesis and personas | Customer | Durable | product-hypothesis, b2b-persona | | | | | | | |
| 3 | Vision and strategy one-pager | Strategy | Durable | 03-strategy-one-pager | | | | | | | |
| 4 | Competitive landscape | Strategy | Living, quarterly | 13-competitive-landscape | | | | | | | |
| 5 | Business model and unit economics | Business | Living, quarterly | 13-business-case | | | | | | | |
| 6 | Outcome roadmap | Build | Living, monthly | 03-now-next-later-roadmap | | | | | | | |
| 7 | North Star and metric tree, dashboard | Measure | Living, weekly | 02-north-star-tree | | | | | | | |
| 8 | OKRs | Measure | Living, quarterly | 02-okr-set | | | | | | | |
| 9 | Positioning and messaging | Go-to-market | Durable | 24-positioning-statement, 24-messaging-framework | | | | | | | |
| 10 | Operating cadence and decision log | Operate | Living, weekly | operating-cadence, 29-decision-log | | | | | | | |
| 11 | Lifecycle stage assessment | Lifecycle | Durable, yearly | 30-lifecycle-stage-assessment | | | | | | | |
| 12 | Stakeholder map and DACI | Leadership | Living, quarterly | 36-stakeholder-map, 36-daci-decision | | | | | | | |

## AI artifacts (AI-powered products)
| Artifact | Dimension | Template | Grilling log ID | Owner | Status | Last reviewed | Next review | Open items |
|---|---|---|---|---|---|---|---|---|
| Eval plan | Measure | eval-plan | | | | | | |
| AI cost model | Business | ai-cost-model | | | | | | |
| Model and vendor register | Lifecycle | model-register | | | | | | |
| AI risk assessment | Operate | ai-risk-assessment | | | | | | |

## Active event artifacts
| Artifact | Event and date | Template | Spine artifacts it draws on | Owner | Status | Archive date |
|---|---|---|---|---|---|---|
| | | | | | | |

## Summary
- Spine artifacts published: [n] of 12
- Open grilling items: [n]   Contradictions open from last audit: [n]
- Overdue reviews: [list]

# Grilling session log · [Product] · [Dimension] · [Session ID] · [Date]

**Mode:** Live / File   **Participants:** [PM, stakeholders]   **Harness:** [tool, approved for this data: Y/N]
**Reference materials loaded:**
| Source | Owner | Date of source | How loaded (connector / export / pasted) |
|---|---|---|---|
| | | | |

**Prior logs read:** [session IDs]

## Questions
| Q-ID | Question | Kind (fact / decision) | Harness recommendation and reason | Answer | Evidence (source or "assumption") | Challenge raised (test) | Status | Owner | Feeds artifact |
|---|---|---|---|---|---|---|---|---|---|
| [DIM]-01 | | | | | | | Agreed / Overridden / Open / Needs owner | | |
| [DIM]-02 | | | | | | | | | |

Status rules: Agreed means the answer passed all seven tests. Overridden means the PM kept an answer that failed a test, with the reason recorded below. Open means no answer yet. Needs owner means someone else holds the answer.

## Overrides
| Q-ID | Test failed | PM's reason for keeping the answer |
|---|---|---|
| | | |

## Premortem
"It's 90 days from now and this dimension's artifact misled a decision. What happened?"
- Answer:
- Changes made because of it:

## Readback
[Five to ten lines: what was decided in this session.]
**Readback confirmed by PM:** Y / N   **Date:**

## Next
- Follow-ups and owners:
- Next session:

# Product 360 health review · [Product] · [Quarter] · [Date]

**Reviewer:** [PM]   **Attendees:** [manager, peers, product ops]
**Maturity scale:** Appendix C   **Previous review:** [link]

## By dimension
| Dimension | Artifacts | Owner | Last reviewed | Freshness (current / stale / contradicted) | Used in a ritual? (which) | Maturity (Appendix C) | Open grilling items | Audit contradictions open | Decision needed |
|---|---|---|---|---|---|---|---|---|---|
| Customer | | | | | | | | | |
| Strategy | | | | | | | | | |
| Business | | | | | | | | | |
| Build | | | | | | | | | |
| Measure | | | | | | | | | |
| Go-to-market | | | | | | | | | |
| Operate | | | | | | | | | |
| Lifecycle | | | | | | | | | |
| Leadership | | | | | | | | | |

## AI artifacts (AI-powered products)
- Eval scores: current, trend, last release gated by evals:
- Cost per task or outcome: current, trend:
- Model deprecations due in the next two quarters:
- AI risk assessment: last reviewed, new regulatory duties:

## Cadence health
| Ritual | Held as planned (n of n) | Decisions produced | Keep / change / cancel |
|---|---|---|---|
| Weekly metrics review | | | |
| Monthly roadmap refresh | | | |
| Quarterly business review | | | |

## Summary
- Weakest dimension:
- Top three fixes (owner, date):
  1.
  2.
  3.
- Re-grills scheduled: [dimension, date]
- What changed since the last review:

# Product 360 workspace brief · [Product]

Standing instructions for the AI harness. Keep this short and current; it loads with every session.

## Scope
[The scope paragraph, with the date it was last confirmed.]

## Where the 360 lives
- Index: [location]
- Grilling logs: [location]
- Decision log: [location]
- Approved connectors: [list, with what each may be used for]
- Not approved for this workspace: [systems or data types]

## Rules
1. Never invent facts, numbers, quotes or decisions. If a source doesn't support it, say "no source" and add it to the gap list.
2. Fetch facts from connected sources and cite them (source, owner, date). Ask the PM only for decisions.
3. Ask one question at a time, with a recommended answer and the reason.
4. Test every answer against the seven challenge tests: specific, evidenced, falsifiable, trade-off named, consistent, owned, decision-relevant. Push once on a failure, then log it as open or overridden.
5. Don't agree to be agreeable. If the evidence points elsewhere, say so.
6. Write every session to a grilling log before ending it.
7. The decision log names a person as the decider, never the harness.

## Vocabulary
- Nine dimensions: Customer, Strategy, Business, Build, Measure, Go-to-market, Operate, Lifecycle, Leadership.
- Artifact kinds: durable, living, event.
- Product terms and metric definitions: [link to metric dictionary]

## Current state
- Phase: [days 1 to 30 / 31 to 60 / 61 to 90 / maintaining]
- Open grilling items: [n, link]
- Next review due: [artifact, date]

# Product 360 self-assessment · [Product] · [Quarter] · [Date]

**Scored by:** [PM]   **Challenged by:** [peer PM, manager or product ops]
**Scope:** [link to the scope paragraph on the Product 360 index]
**Evidence sources:** [Product 360 index, decision log, calendar, artifact links]
**Previous assessment:** [link, or "first assessment"]

## Scoring rules
- A level counts only if every criterion for it and every level below is met, with evidence.
- Mixed evidence takes the lower level.
- Level 5 requires level 4 held for two consecutive quarters.
- Score the weakest part of the scope.

## Scores by dimension
| Dimension | Level (1 to 5) | Evidence (artifact, ritual or log entry, with link and date) | Lowest unmet criterion for the next level | Previous level | Confidence (high / medium / low) |
|---|---|---|---|---|---|
| Customer | | | | | |
| Strategy | | | | | |
| Business | | | | | |
| Build | | | | | |
| Measure | | | | | |
| Go-to-market | | | | | |
| Operate | | | | | |
| Lifecycle | | | | | |
| Leadership | | | | | |

## AI overlay (AI-powered products)
| AI element | Host dimension | Level (1 to 5) | Evidence | Lower than host? |
|---|---|---|---|---|
| Evals | Measure | | | |
| Cost | Business | | | |
| Model register | Lifecycle | | | |
| AI risk | Operate | | | |

## The two weakest
1. [Dimension, level] because [evidence]
2. [Dimension, level] because [evidence; if tied, the business risk or fixed date that broke the tie]

## Action plan (one level up per weak dimension)
| Dimension | From level | To level | Unmet criterion | Action | Template or chapter | Ritual that will use it | Owner | Due | Evidence it's done |
|---|---|---|---|---|---|---|---|---|---|
| | | | | | | | | | |
| | | | | | | | | | |

## Not doing this quarter
[Dimensions and actions deliberately deferred, and why.]

## Challenges raised and how they were resolved
| Dimension | Challenge | Resolution (score kept or changed, and why) |
|---|---|---|
| | | |

# Quarterly maturity review · [Product] · [Quarter] · [Date]

**Attendees:** [PM, manager, product ops, key partners]
**This quarter's self-assessment:** [link]   **Last quarter's:** [link]

## Movement
| Dimension | Last quarter | This quarter | Change | Why it moved (or didn't) |
|---|---|---|---|---|
| Customer | | | | |
| Strategy | | | | |
| Business | | | | |
| Build | | | | |
| Measure | | | | |
| Go-to-market | | | | |
| Operate | | | | |
| Lifecycle | | | | |
| Leadership | | | | |
| AI overlay (evals, cost, register, risk) | | | | |

## Last quarter's action plan
| Action | Owner | Done? | Evidence | Did the level move? |
|---|---|---|---|---|
| | | | | |

## Slips
[Every dimension that dropped a level: the cause (owner left, ritual stopped, event made an artifact false) and the fix.]

## Ritual health
| Ritual | Held as planned (n of n) | Decisions logged | Keep / change / cut |
|---|---|---|---|
| | | | |

## Decisions
- Focus dimensions for next quarter: [two, with reasons]
- Actions approved: [link to the new self-assessment's action plan]
- Anything escalated: [what, to whom]
- Next review: [date]