Outcome KPI Framework

"Doing stuff isn't the point. Achieving stuff is." -- Jeff Gothelf

Defines measurable outcome KPIs for user stories and features. Loaded during Phase 4 (Requirements Crafting) to produce outcome-kpis.md. Synthesizes three frameworks: customer-centric OKRs, lean metrics, and OKR methodology.

The Outcome KPI Formula

Primary template from Gothelf/Seiden. Every KPI answers five questions:

Component	Question	Example
Who	Which user segment?	Returning customers with 2+ orders
Does What	What observable behavior changes?	Complete checkout without contacting support
By How Much	What is the measurable target?	40% reduction in support tickets
Measured By	How do we collect the data?	Support ticket system + checkout analytics
Timeframe	When do we measure?	30 days post-release, then weekly

Formula: [Who] [Does what] [By how much]

Apply as litmus test: if a KPI cannot answer all five components, it measures an output (feature delivery), not an outcome (behavior change).

Good vs Bad KPIs

Bad (Output)	Good (Outcome)
Launch mobile app v2	Mobile users complete purchases 40% more often
Build recommendation engine	Users purchase from recommendations, increasing from 10% to 25%
Deploy onboarding redesign	New users complete onboarding within 24 hours 30% more often
Ship CSV export	Analysts resolve data questions without engineering support 60% of the time

Leading vs Lagging Indicators

From Gothelf/Seiden: business results are lagging -- teams cannot directly influence them. Target leading indicators instead.

Type	Definition	Examples	Actionable?
Lagging (Impact)	Business results already happened	Revenue, NPS, market share, churn rate	No -- too slow, too many variables
Leading (Outcome)	Behavior changes predicting business results	Purchase completion rate, feature adoption, retention	Yes -- teams can run experiments
Leading (Secondary)	Behaviors predicting primary leading indicators	Page visits, trial starts, onboarding steps completed	Yes -- most granular, fastest signal

Outcome Mapping Chain

Map every KPI through this chain to ensure traceability:

Business KPI (Lagging/Impact)
    Example: "Increase quarterly revenue by 15%"
        |
        v
    Customer Behavior (Leading/Outcome)
        +-- Users complete purchases from recommendations (+25%)
        +-- Users return within 7 days (+20%)
        |
        v
    Secondary Behavior (Leading/Secondary)
        +-- Users browse recommendation pages (+30%)
        +-- Users enable push notifications (+15%)

Each layer decomposes into more granular behavioral metrics. Teams target the highest-leverage behavior.

Actionable vs Vanity Metrics

From Maurya (Running Lean): actionable metrics "tie specific and repeatable actions to observed results."

Dimension	Vanity	Actionable
Measures	Business size (totals)	Individual behavior (rates)
Data type	Gross aggregates	Ratios and unit economics
Cause/effect	No insight into why	Directly signal product-market fit
Examples	Total users, page views, downloads	Activation rate, retention cohort, churn rate
Decision value	Cannot inform action	Drives specific experiments

The OMTM (One Metric That Matters)

Pick ONE metric per product stage. Optimizing one metric reveals the next.

Stage	Focus	Example OMTM
Empathy	Problem validation	Interview pain intensity (qualitative)
Stickiness	Retention	Churn rate, DAU/MAU ratio
Virality	Organic growth	Viral coefficient, referral rate
Revenue	Monetization	Customer Lifetime Value, MRR
Scale	Growth efficiency	CAC/LTV ratio, payback period

Good metric characteristics: rate or ratio (not absolute number) | comparable across time | simple enough to remember | predictive | behavior-changing.

Customer Factory (AARRR) Constraint Mapping

From Maurya: model the business as a production line. Identify the bottleneck, then focus KPIs there.

Stage	Key Question	Example Metric
Acquisition	Are we reaching the right people?	Visitor-to-signup conversion rate
Activation	Do users get the "aha moment"?	% completing core action in first session
Retention	Do users come back?	Week-1 return rate, DAU/MAU
Revenue	Do users pay?	Trial-to-paid conversion rate
Referral	Do users tell others?	Referral rate, viral coefficient

Activation is causal -- it drives retention, revenue, and referral. Prioritize activation KPIs when uncertain.

OKR Integration

From Doerr (Measure What Matters): connect KPIs to strategic objectives.

Writing Key Results

Every Key Result uses the outcome formula. Quality criteria:

1. Measurable: "It's not a Key Result unless it has a number" (Marissa Mayer)
2. Outcome-focused: "Increase email subscribers by 20%" not "Launch newsletter"
3. Time-bound: deadline (typically end of quarter)
4. Verifiable: no ambiguity about whether met
5. Aggressive yet realistic: stretch without demoralizing

Committed vs Aspirational

Type	Expected Score	Resource Allocation	Failure Response
Committed	1.0 (must deliver)	Consume most available resources	Requires explanation, replanning
Aspirational	0.7 (stretch goal)	Overcommit slightly beyond capacity	Expected -- carry forward

Sweet spot: blended aggregate of 0.6-0.7. Consistently hitting 1.0 = not ambitious enough.

OKR Anti-Patterns

Anti-Pattern	Signal	Fix
Output-based KRs	"Launch X", "Build Y", "Ship Z"	Rewrite as behavior: "Users [do what] [by how much]"
Too many KRs	>5 KRs per Objective	Cut to 2-4 per Objective, max 3-5 Objectives
Vague KRs	No numeric target	Add baseline + target + deadline
Sandbagging	Consistently scoring 1.0	Increase ambition level
Backlog retrofitting	OKRs match existing backlog 1:1	OKRs filter backlog, not justify it

Mapping: Objective to User Stories

Objective (qualitative, inspirational, timeboxed)
    |
    Key Results (2-4 per Objective, [Who][Does what][By how much])
    |
    Epics (weeks of work, aligned to Key Results)
    |
    User Stories (days of work, with measurable acceptance criteria)

Every story traces back to a Key Result. Orphan stories (no KR link) are potential waste.

KPI Template

Use this exact structure in outcome-kpis.md:

## Feature: {feature-name}

### Objective
{What success looks like in one sentence -- qualitative, inspirational, timeboxed}

### Outcome KPIs

| # | Who | Does What | By How Much | Baseline | Measured By | Type |
|---|-----|-----------|-------------|----------|-------------|------|
| 1 | {segment} | {behavior} | {target} | {current} | {method} | Leading/Lagging |

### Metric Hierarchy
- **North Star**: {the ONE metric that matters most for this feature}
- **Leading Indicators**: {behaviors that predict the north star}
- **Guardrail Metrics**: {metrics that must NOT degrade}

### Measurement Plan
| KPI | Data Source | Collection Method | Frequency | Owner |
|-----|------------|-------------------|-----------|-------|

### Hypothesis
We believe that {proposed solution} for {user segment} will achieve {key result}.
We will know this is true when {who} {does what} {by how much}.

KPI Granularity

• Per Epic: Define 2-3 north-star KPIs that all contributing stories aim to move
• Per Story: Add story-level success criteria tied to the epic-level KPIs
• Guardrails: Define at epic level, apply consistently across all stories
• Rule of thumb: If the feature has 1-3 stories, one KPI table suffices. If 4+, group by epic.

Smell Tests

Before finalizing KPIs, verify each one passes:

Check	Question	If No
Measurable today?	Can you measure it with current instrumentation?	Add instrumentation to requirements
Rate not total?	Is it a ratio/rate, not a gross count?	Convert to rate (vanity -> actionable)
Outcome not output?	Does it describe user behavior, not feature delivery?	Rewrite as "[Who] [Does what] [By how much]"
Has baseline?	Do you know the current value?	Establish baseline before setting target
Team can influence?	Can the team directly affect this metric?	Decompose into more granular leading indicator
Has guardrails?	Are there metrics that must not degrade?	Add guardrail metrics (e.g., error rate, load time)

Handoff to DEVOPS

The platform-architect needs these from outcome-kpis.md to plan instrumentation:

1. Data collection requirements: what events/behaviors to instrument, what data points to capture
2. Dashboard/monitoring needs: which metrics need real-time dashboards vs. weekly reports
3. Alerting thresholds: guardrail metric boundaries that trigger alerts when breached
4. Baseline measurement: any metrics needing baseline collection before feature release

References

For deeper reading on source frameworks:

• Running Lean (Maurya): docs/research/running-lean-research.md
• Measure What Matters (Doerr): docs/research/measure-what-matters-research.md
• Who Does What By How Much (Gothelf/Seiden): docs/research/who-does-what-research.md