Product Vision and Goals

Connect the customer change you seek to the results you measure. Build a vision, an owned metric tree and quarterly goals that guide product decisions.

Why this matters

A vision and a release list leave a gap: the team cannot explain how shipping features advances its purpose. Separate the layers so disappointing results can be traced to vision, strategy or execution.

The chain is vision, business decomposition, North Star and inputs, quarterly objectives and key results (OKRs), then regular goal reviews. It connects the Customer evidence from Chapter 01 to strategy and roadmaps in Chapter 03.

Vision, goals and the layers between

Vision, mission, strategy and goals

Companies use mission and vision differently. Agree on definitions with leadership before drafting. This book uses the following layers.

Roman Pichler’s May 2026 framework separates vision, strategy, outcome roadmap and backlog. Strategy typically spans 12 to 24 months and receives quarterly review. KPIs derive from strategy, business goals and roadmap outcomes. Pichler places OKRs at roadmap level.

Separate the layers so strategy can change while purpose remains stable.

Marty Cagan draws the same line in his 2016 essay on vision versus strategy. The vision is the future the team is trying to create; the strategy is the sequence of products and releases that gets there.

What a good vision does

Pichler defines vision as the positive change that justifies the product. Develop it with the people who use it. Describe customer benefit, keep it broad and concise, and use it to filter ideas. His six quality checks are inspiring, shared, ethical, concise, ambitious and enduring.

Vision horizons vary. Pichler suggests three to five years in some guidance and five to ten elsewhere. Cagan suggests two to five for software, longer for hardware. Choose a useful multiyear horizon.

A solution vision describes technology instead of customer change. Pichler contrasts a children’s game with its purpose: helping children enjoy music and dancing. Apply the test to AI. State the change developers need before choosing agents as the mechanism.

For B2B products, describe the change in the customer’s organization rather than in yours. “Become the leading AIOps vendor” is a company ambition. “On-call teams resolve incidents before customers feel them” is a product vision, and it tells every engineer what a good week looks like.

Three formats: statement, board and narrative

Use three vision formats for different audiences.

The vision statement is one or two sentences: the change, and for whom. It goes at the top of every strategy document and quarterly review, and its job is to be remembered.

The product vision board connects purpose to strategy on one page. Pichler places the vision above four sections: target group, needs, product and business goals. Product covers three to five distinguishing features. Optional extensions add competitors, revenue, costs and channels. Use one board per product. Platform target groups may need separate rows for users, buyers, gatekeepers and partners.

A positioning-style vision, adapted from Geoffrey Moore’s Crossing the Chasm, names the target customer, need, category, benefit, alternative and difference. Place it beneath the purpose vision. Write one per segment when alternatives differ. Manual processes often matter as much as competitors. Chapter 24 develops positioning.

The vision narrative describes the customer’s future in a page or two. Amazon’s Working Backwards practice, described by Colin Bryar and Bill Carr, uses a press release under one page and FAQs of five pages or less. External questions cover customers and press. Internal questions test cost, feasibility, risk and economics.

The press release states what customers notice. The internal FAQ tests delivery constraints. Cagan calls narratives, storyboards and prototypes that make the future concrete visiontypes. In enterprise, cover both users and buyers. Include security, procurement, residency and partner economics. Chapter 34 covers narrative craft.

Breaking the business into parts

A vision describes the whole, but goals have to be owned by parts. Before setting goals, decompose the business into pieces small enough to own and large enough to matter. Four lenses help.

Business model components. Alexander Osterwalder and Yves Pigneur’s Business Model Canvas splits a business into nine building blocks: customer segments, value propositions, channels, customer relationships, revenue streams, key resources, key activities, key partnerships and cost structure. Here the canvas shows which component each goal moves. A pricing change moves revenue streams and cost structure; a partner program moves channels and key partnerships. If a goal moves no component, question whether it’s a business goal.

Value streams. The Scaled Agile Framework separates an operational value stream (the activities that deliver a product or service to a customer, such as a purchase order through to delivery) from a development value stream (the activities that turn a business hypothesis into a working solution). The customer’s operational value stream is the most useful spine for decomposing a product and its metrics, because each stage is a place where value is created or lost.

Team-aligned areas. Matthew Skelton and Manuel Pais, in Team Topologies, describe four team types (stream-aligned, enabling, complicated-subsystem and platform) and three interaction modes (collaboration, X-as-a-service and facilitation). For goals, this means product areas should map to streams so each stream-aligned team can own a metric end to end, and platform teams should state their goals as service to the stream-aligned teams.

Capability, segment and model. Lay your product’s capabilities against its segments and revenue components to see where goals overlap and where nobody owns anything.

Assign one team to each North Star input. Split shared inputs or combine the goals. Resolve unowned inputs before goal-setting.

North Star and metric trees

The North Star metric

Sean Ellis popularized the North Star metric, which he and Morgan Brown describe in Hacking Growth: the single metric that best captures the core value a product delivers to its customers. The emphasis is on one.

Amplitude’s North Star Playbook, co-authored by John Cutler, connects customer, product and business value. Its 2024 guidance gives three tests:

1. It reflects customer value: it rises when customers get more of what they hired the product for.
2. It represents the product strategy: it measures the bet you’re making now.
3. It’s a leading indicator of business success: it moves before revenue does.

Pair the North Star with a stable product vision. Use customer behavior that leads business results. Watch recurring revenue and average revenue per user as financial results.

Amplitude also describes three “games” a product can play:

Most B2B software plays the productivity game, which rules out many tempting metrics. Logins, seats and time in product measure attention, and in a productivity product more time in the tool can mean the product is failing. Pick a metric at the customer’s unit of value: incidents resolved, invoices approved, deployments shipped, contracts executed.

Platforms need one more decision. A platform has at least two sides, such as developers who build on it and the organizations that use what they build. State which side the North Star measures, and give the other side an input in the tree.

The input-metric tree

Break the aggregate North Star into three to five inputs teams can influence. Amplitude suggests four lenses: breadth (customers reached), depth (value per customer), frequency (how often) and efficiency (time or cost).

Arrange the result as a tree. The North Star sits at the root, the inputs beneath it, and beneath each input the drivers a single team can move in a quarter. Each input has one owning team, which is why the decomposition comes first.

Add guardrails: counter-metrics with thresholds that protect against improving one input at another’s expense. Faster diagnosis might hide guessing. Higher adoption might reflect discounting. More automation might increase risk. Cover quality, trust, cost and customer health beside the relevant inputs.

Treat each metric-tree link as a causal hypothesis. Check whether past input changes preceded North Star changes. Investigate links that fail across two quarters. Chapter 05 covers relationships and Chapter 19 covers harness analysis.

Goals that steer the work

Outcomes over output

Josh Seiden defines an outcome as a change in human behavior that drives business results. Drawing on the Kellogg Foundation’s logic model, he separates three levels: output (what the team makes), outcome (the change in customer behavior the output produces) and impact (the business result at the top).

Each end has its own trap. Output goals (“launch diagnosis v2”) are easy to hit and say nothing about whether anyone benefited. Impact goals (“grow ARR 38%”) are what the business needs, but Seiden warns against handing them to small teams: no single team can move them, so the goal produces anxiety instead of direction. Outcomes sit in between, specific enough for a team to influence and close enough to value to matter.

Seiden’s two questions turn any feature into an outcome: what will people be doing differently as a result, and how will you know? Jeff Gothelf and Seiden built a key-result pattern on the same idea in their 2024 book on customer-centric OKRs, whose title states it: Who Does What By How Much? A good key result names an actor, a behavior and a measurable change.

Ship dates still matter. They go in the delivery plan.

OKRs: where they came from and how they work

Objectives and key results developed from Peter Drucker’s management by objectives. Andy Grove adapted them at Intel and described the practice in High Output Management (1983). John Doerr introduced OKRs to Google in 1999 and popularized them in Measure What Matters (2018).

Doerr defines an objective as what is to be achieved: significant, concrete, action-oriented and ideally inspirational. Key results measure progress toward it: specific, time-bound, aggressive yet realistic, and either met or not. A typical set has one objective and three to five key results. His sentence form doubles as a test: “I will [objective] as measured by [key results].” He credits OKRs with five benefits: focus, alignment, commitment, tracking and stretching.

Google’s OKR playbook distinguishes committed goals, expected to score 1.0, from aspirational goals, expected to average 0.7 with high variance. Review missed commitments without punishment. Avoid mixing types, routine-work goals, sandbagging, timid aspirations and incomplete measures of success.

Christina Wodtke, in her 2014 essay “The Art of the OKR” and in Radical Focus, puts the weight on cadence. Objectives are qualitative, time-bound to a month or a quarter, and achievable by the team without depending on others. Key results are quantitative, usually three, set so the team’s confidence of hitting each is about five in ten. Review that confidence weekly, and leave the OKRs alone until the period ends.

In 2020, Cagan stopped recommending OKRs to most companies he encountered because teams lacked empowerment. He distinguishes ambitious misses from missed conservative commitments, which warrant peer review. Give teams problems and decision authority before using OKRs to hold them accountable.

One disagreement is worth knowing. Wodtke’s 2014 essay endorses individual OKRs alongside company and team OKRs. Cagan argues against individual and functional objectives, and many organizations have dropped individual OKRs because they turn into task lists and get tangled with performance reviews. This book sides with team objectives, because the team is the unit that can change customer behavior.

Why OKRs fail

Most OKR failures are predictable, and each has a known cause.

How to apply it

This method takes about four weeks for a product with a validated hypothesis and personas from Chapter 01. For an existing product with a stale vision, run it before the planning cycle so the goals land in time to shape the roadmap.

Week 1: Vision.

1. Gather the inputs: the revised product hypothesis, personas and job stories, the evidence log, current metrics, and the company’s strategy and financial targets.
2. Draft three to five candidate vision statements with the product trio, then test them with a sales leader, a customer success leader and two or three customers. Discard any that names a technology or describes your ambition rather than a customer change. Score the rest against Pichler’s six qualities and pick one.
3. Write the vision narrative: a press release dated two to three years out, plus an FAQ with every hard buying-group question in the internal section. Circulate it. The comments are the real output, because they show where leadership disagrees.
4. Fill in the vision board and write one positioning-style line per buying segment. If two segments name different alternatives, take that to the strategy work in Chapter 03.

Week 2: Decompose.

5. Map the customer’s operational value stream in five to eight stages, from trigger to outcome. Mark where value is created and where it leaks.
6. Lay the product’s capabilities, segments and revenue components against the value stream and the business model components. Note every place two teams own the same thing or nobody owns anything.
7. Map each team to a stage or capability. Platform and enabling teams get goals stated as service to the stream-aligned teams.

Week 3: North Star and tree.

8. Name the game and the customer’s unit of value. Test two or three North Star candidates against Amplitude’s three criteria.
9. Define the North Star precisely enough for a customer or auditor to recount it: what counts, what doesn’t, over what period, from which data. If it might one day become a price meter, write it to that standard now.
10. Find three to five inputs using breadth, depth, frequency and efficiency. Ask the harness how each moved against the North Star over the last four to eight quarters. Drop inputs with no visible relationship, or label them untested bets.
11. Give each input one owning team and a guardrail with a threshold.

Week 4: OKRs.

12. Have each team draft one to three objectives tied to its input, with key results written as who does what by how much. Move every deliverable to the delivery plan.
13. Label each OKR committed or aspirational, record the team’s starting confidence in each key result, and note each baseline’s source.
14. Review the full set with leadership in one sitting. Look for collisions, gaps against the tree, business-as-usual goals and any key result that could be hit by breaking a guardrail.

After launch.

15. Check confidence weekly. Run a monthly goal review of inputs, guardrails and confidence trends. Change plans freely; change OKRs only at the end of the period.
16. Score every OKR at the end of the cycle. Hold a peer review, run like an outage review, for any committed OKR that was badly missed.

The AI lens

Goals for AI-powered products

AI quality varies with inputs and mistakes affect trust. Adoption goals alone can reward use in situations the feature handles poorly. Add quality, trust and cost guardrails.

This book uses four goal families for AI products. The model is the book’s own synthesis of the sources below.

Quality, trust and cost usually act as guardrails while the value goal is pushed. One of them becomes the objective when it’s the binding constraint, such as after a trust incident or when margin falls below plan.

Define quality on a test set. Anthropic recommends specific, measurable, achievable and relevant success criteria. Its examples combine accuracy, non-toxic outputs, severe errors and latency on held-out inputs. Name the set, measure and threshold. Chapter 31 covers evaluations.

Weigh errors by what they cost. Google’s People + AI Guidebook advises weighting false positives and false negatives by their real-world cost, and treating precision against recall as a tradeoff to set with real users. An incident agent that misses a root cause wastes a responder’s time. One that confidently names the wrong one can send the responder to roll back the wrong service. Those errors deserve different thresholds. The guidebook also recommends explicit thresholds that trigger action, such as a rising rejection rate prompting a model review; write those triggers into the goal review.

Decide what to automate before setting autonomy goals. The guidebook distinguishes automation, suited to tedious, hard or risky tasks, from augmentation, suited to tasks people enjoy or feel responsible for. An autonomy goal is legitimate only for tasks customers want automated. Elsewhere, the goal is a better human decision, measured by acceptance and outcome.

Make cost a first-class goal. Inference cost scales with use, so the most successful AI feature can also be the most expensive. Stripe’s 2025 framework for pricing AI products names three kinds of charge metric: consumption (per unit of usage, loosely tied to value), workflow (per completed task) and outcome (only when a defined result happens, closest to value and riskiest for the seller). When the price meter is an outcome, the North Star, the revenue metric and the customer’s value become one number, and cost per outcome decides the margin. Intercom’s Fin charges $0.99 per outcome and publishes what counts as one, for example a customer who asks for no further help after Fin’s last answer. If your North Star may become a price meter, its definition has to be one a customer can audit. Chapter 15 covers pricing.

Make trust evidence reviewable. Customer security teams may ask for wrong-action, override and audit-completeness rates. NIST’s AI Risk Management Framework (January 2023) and Generative AI Profile (July 2024) organize work into govern, map, measure and manage. Trust guardrails support measurement. Chapter 33 covers regulation.

Doing the work with AI

With a harness connected to analytics, CRM, support and planning tools, most of this chapter’s mechanics get faster. The judgment stays with you.

• Vision drafts from evidence. Give the harness the Chapter 01 interview snapshots and ask for candidate vision statements, each traced to supporting evidence, with any that name a technology flagged. Write the final one yourself.
• Narrative drafts, then cuts. A harness produces a plausible PR/FAQ in minutes, and a fluent narrative can hide that nobody has thought through the hard questions. Use the draft to find the questions, and own every claim in the version you circulate.
• Testing the tree. Ask how each candidate input moved against the North Star over past quarters, by segment, and where the relationship is weak or reversed. Teams used to skip this because it needed an analyst. Past co-movement is evidence, not proof of cause.
• OKR critique. Models are good at spotting outputs disguised as outcomes, missing baselines and gameable key results. Have one critique every draft before the leadership review.
• The goal review. The harness assembles inputs, guardrails, confidence trends and what changed. You interpret and decide.

Trace every number to a source the harness read. Mark missing values as placeholders. Use approved tools for customer data, financials and unreleased plans.

The Beacon case: from vision to quarterly goals

The vision. The trio drafts five candidates. Two name agents and go. One describes Northlight’s ambition rather than a customer change. The team settles on:

Every on-call team can resolve incidents before customers feel them, without losing sleep or control.

The vision serves Priya and Dana. Sleep reflects the burnout finding. Control preserves human approval for Sam. The purpose can survive a change in technology.

The positioning line. For the direct enterprise segment: for IT operations and SRE teams at large enterprises who are drowning in alerts and still diagnosing incidents by hand with runbooks and chat, Beacon is an incident agent platform that correlates alerts, diagnoses root cause with cited evidence and runs approved fixes; unlike AIOps features inside a single observability suite, Beacon works across the customer’s tools through connectors and keeps a human approval gate on every risky action.

The “unlike” clause surfaces Beacon’s strategic tension: cross-tool neutrality or deep integration with Northlight Observe data? One line can’t credibly claim both. The team flags the choice for Chapter 03 and writes a second line for the MSP segment, where Leo’s alternative is a patchwork of tools across 60 customers.

The vision narrative. The Northlight Live press release shows Dana opening a diagnosed incident at 3 a.m., with cited evidence and a rollback awaiting approval. The external FAQ covers Marcus’s MTTR concerns and Leo’s multi-tenant billing. The internal FAQ covers Sam’s controls, residency and AI Act questions, the margin decline from 81% to 72%, and revenue predictability under per-resolved-incident pricing. These become leadership review questions.

Decomposition. The customer’s operational value stream runs detect, correlate, diagnose, decide, act and learn. Beacon’s capabilities line up as Correlate, Diagnose, Act and Learn, with connectors feeding every stage, and the five engineering teams map one each to Connectors, Correlate, Diagnose, Act and Learn. The map exposes a gap: nobody owns “decide,” where a responder chooses whether to accept the diagnosis. Diagnose and Act each assumed the other did. The trio gives it to Diagnose, because acceptance is a diagnosis outcome.

North Star and tree. The North Star is incidents resolved with Beacon’s help per week, a productivity-game metric at the customer’s unit of value. The team writes a definition precise enough to audit, because if per-resolved-incident pricing goes ahead, this definition becomes the price meter. The inputs are environments with full connector coverage (breadth), diagnosis acceptance rate (depth), alert-to-incident compression ratio (efficiency) and autonomous resolution rate on allowlisted actions (autonomy). Weekly active responders stays on the dashboard as a health metric, because it measures attention.

The guardrails are wrong-action rate, inference cost per resolved incident, MTTR (must not rise) and responder trust from a quarterly pulse. The wrong-action guardrail exists because of a real event: a customer rolled back the wrong service after Beacon proposed a hallucinated root cause. Without it, the Diagnose team could raise acceptance by sounding more confident.

When the harness compares past quarters, three inputs move with the North Star. Autonomous resolution has too little history to tell, so it stays on the tree labeled as an untested bet.

The OKR draft that failed. The Agents program’s first draft read: ship Beacon Agents GA by Northlight Live; launch 12 new connectors; publish AI Act documentation. All three are outputs with deadlines, none names a customer behavior, and all three were on the delivery plan already. It’s the pattern Cagan describes: OKRs layered on a roadmap that has already decided what to build.

The OKR set. The rewrite gives the Diagnose team one objective, three key results and a cost guardrail:

• Objective: On-call engineers trust Beacon’s diagnosis enough to act on it.
• KR1 (aspirational): Diagnosis acceptance rate across enterprise customers rises from [baseline] to [target]. Confidence: five in ten.
• KR2 (aspirational): The share of responders who approve a Beacon-proposed action within ten minutes rises from [baseline] to [target].
• KR3 (committed): Wrong-root-cause reports stay below [threshold] per 1,000 diagnoses.
• Guardrail (committed, shared with the Act team): Inference cost per resolved incident stays below [threshold] and falls by [n]% over the quarter.

The Act team takes an aspirational objective on autonomous resolution for allowlisted, low-risk actions, scored against the 0.7 expectation. The quality and cost commitments are labeled committed, so a miss on either triggers a peer review.

The goal review. At the first monthly review, the harness reports that compression ratio rose for the second month running while incidents resolved with Beacon’s help stayed flat in the MSP segment. Leo’s customers had more grouped incidents but no more resolved ones, because few MSP environments had full connector coverage. The team leaves the OKRs alone and changes the plan: the Connectors team prioritizes the two integrations MSPs use most, and the breadth input gets a segment split next quarter.

Product 360 artifacts

# 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.

Prompts

Goal: Get candidate vision statements grounded in what customers said, not in what the company wants to be.
Paste in: interview snapshots or the evidence log, the personas and job stories, and the current vision if one exists. Use a tool approved for customer data.

You are helping me write the product vision for [product]. Using only the evidence provided:

1. Summarize, in five bullets, the change customers most want in their work, each with the snapshot IDs that support it.
2. Draft five candidate vision statements of one or two sentences. Each must describe a positive change for the customer's organization. Keep each statement focused on customer change. Reserve technology and market-position choices for the strategy.
3. Score each candidate against six qualities: inspiring, shared, ethical, concise, ambitious, enduring. Say which quality each one is weakest on.
4. For the strongest two, list three feature ideas each would rule out.
5. If the current vision names a technology or describes our ambition instead of a customer change, say so plainly.

[evidence]

Check the output: confirm each supporting snapshot ID actually says what the summary claims. Reject any candidate that would need rewriting if the strategy changed.

Goal: Produce a press release and FAQ that expose the hard questions behind the vision.
Paste in: the vision statement, personas (including the economic buyer and security reviewer), the product hypothesis and any known cost, pricing and risk facts. Confidential financials go only into an approved tool.

Write a vision narrative for [product] in the Working Backwards style, dated [date of the imagined announcement].

Part 1: a press release under one page, with a headline about the daily user's outcome, a subheading, the problem, the solution, what the economic buyer gets, how to get started and two quotes clearly marked as imagined.
Part 2: an external FAQ of five to eight questions customers, partners and press would ask.
Part 3: an internal FAQ of at least eight questions covering cost to build and run, technical risk, security and procurement objections, regulatory obligations, pricing and margin, and what we are choosing not to do. Answer only from the facts provided. Where a fact is missing, write "Unknown: [what we need to find out]."

Then list the three questions in the internal FAQ most likely to stop this vision from shipping.

[inputs]

Check the output: delete any number the model introduced that is not in your inputs. Read the internal FAQ first; if it is shorter or easier than the press release, it has not done its job.

Goal: Break the product and business into parts so every goal has one owner.
Paste in: a list of capabilities, segments, revenue components, teams and what each team works on today.

For [product], build a decomposition in four parts:

1. The customer's operational value stream from trigger to outcome, in five to eight stages. For each stage: what the customer does, where value leaks today and which of our capabilities serves it.
2. A capability by segment grid showing which team owns each cell.
3. The nine business model components (customer segments, value propositions, channels, customer relationships, revenue streams, key resources, key activities, key partnerships, cost structure), with the current goals that move each one.
4. Each team classified as stream-aligned, platform, enabling or complicated-subsystem, with its main interaction mode.

Then list every stage or component that nobody owns, every one two teams both claim, and a recommended owner for each with the reason.

[inputs]

Check the output: walk the value stream yourself with one real customer's recent experience. If a stage the customer went through is missing, add it before trusting the gaps list.

Goal: Pick a North Star at the customer's unit of value and check whether the proposed inputs actually drive it.
Paste in (or connect the harness to): the vision, the decomposition, metric definitions and at least four quarters of history for the candidate North Star and inputs, by segment.

For [product]:

1. Name the game we play (attention, transaction or productivity) and the customer's unit of value.
2. Propose two or three North Star candidates. Test each against three criteria: reflects customer value, represents the current strategy, leads revenue. Reject vanity metrics and lagging financial metrics.
3. For the recommended North Star, write a definition precise enough for a customer to audit: what counts, what does not, period and data source.
4. Propose three to five inputs using breadth, depth, frequency and efficiency.
5. Using the history provided, show for each input how it moved relative to the North Star, overall and by segment. Classify each as "moves with the North Star," "weak or reversed" or "too little history." Label co-movement as association and state what evidence would test causation.
6. Propose one guardrail per input that would catch someone gaming it.

[definitions and data]

Check the output: pick one input and ask for the underlying quarter-by-quarter numbers and their source. If the harness cannot point to the source, treat the classification as unverified.

Goal: Turn a release list into OKRs that name behavior changes.
Paste in: the draft OKRs or goal list, the metric tree and the team's owned input.

Act as a demanding OKR coach reviewing these goals for [team].

1. Classify each objective and key result as output (something we ship), outcome (a change in what a named customer does) or impact (a business result).
2. Rewrite every output and impact key result as "who does what by how much," tied to the team's input on the metric tree. Leave the baseline and target as [placeholders] unless I supplied them.
3. Move every deliverable to a "delivery plan" list with its date.
4. Label each OKR committed or aspirational, and explain the choice.
5. For each key result, name the guardrail it could break and how a team might hit the number while making the product worse.
6. Flag any key result the team cannot move without another team's work.

[draft goals]
[metric tree]

Check the output: make sure no baseline or target appeared that you did not provide. Read each rewritten KR aloud with "as measured by" in front of it; if it sounds like a task, rewrite it again.

Goal: Define the guardrails that keep an AI feature's value goal honest.
Paste in: the feature description, the task it automates or augments, the value goal, current eval results, known failure cases and cost per unit of value. Use an approved tool for any customer incidents.

For the AI feature [feature], draft a goal set in four families: value, quality, trust and cost.

1. Say whether the task suits automation or augmentation, and why.
2. For quality: name the held-out test set needed, the measures (task fidelity, severe-error share and any others that fit) and a threshold for each. Mark thresholds as proposals.
3. For errors: describe a false positive and a false negative in this feature, their real cost to the customer, and which should be weighted more heavily.
4. For trust: propose acceptance, override and wrong-action measures, and how each will be logged so a customer's security reviewer can inspect it.
5. For cost: propose inference cost per unit of value as a guardrail, and say what happens to margin if usage doubles.
6. Write three triggers in the form "if [measure] crosses [threshold] for [period], then [action]."

[inputs]

Check the output: every threshold should be labeled as a proposal until the team has a baseline. Confirm the severe-error definition with someone who has handled a real customer incident.

Goal: Produce the goal review in minutes so the meeting is spent on decisions.
Paste in (or connect the harness to): the metric tree, OKR set, guardrail thresholds, this month's and the last three months' values, and the teams' confidence ratings.

Prepare this month's goal review for [product]:

1. North Star: this month, last month and the three-month trend, with a one-line explanation from the data.
2. Inputs: each input's trend and whether it moved with the North Star this month.
3. Guardrails: status against threshold (OK, watch or breached), with the action already agreed for a breach.
4. OKR confidence: each key result's confidence now against last month, with the teams' stated reasons.
5. Broken links: any input that rose for two or more months while the North Star stayed flat or fell, overall or in any segment.
6. Three decisions the group should make, each with the evidence behind it.

Cite the source for every number. Mark missing values as "Missing" and list the source needed.

[tree, OKRs, data, confidence]

Check the output: spot-check two numbers against the source system. Make sure the proposed decisions change plans, not the OKRs themselves, unless the cycle has ended.

Anti-patterns

Checklist

• The vision statement describes a change for the customer, names no technology, and passes the six quality checks.
• A vision narrative exists, and its internal FAQ covers security, procurement, cost, pricing and regulatory questions.
• Each buying segment has a positioning-style line that names its real alternative.
• The customer’s operational value stream is mapped, and every stage has one owning team.
• The North Star is at the customer’s unit of value, passes the three criteria and has an auditable definition.
• Three to five inputs sit under the North Star, each with one owning team and evidence of how it moved with the North Star.
• Every input has a guardrail with a threshold.
• Every key result names who does what by how much, with a sourced baseline.
• Every OKR is labeled committed or aspirational, with a starting confidence.
• Deliverables and dates live in the delivery plan, not in the OKRs.
• For AI features, quality, trust and cost goals exist, with a named test set and triggers for action.
• A weekly confidence check and a monthly goal review are on the calendar, and missed committed OKRs get a peer review.