Skill

okr-design

Install
1
Install the plugin
$
npx claudepluginhub yonatangross/orchestkit --plugin ork

Want just this skill?

Add to a custom plugin, then install with one command.

Description

OKR trees, KPI dashboards, North Star Metric, leading/lagging indicators, and experiment design. Use when setting team goals, defining success metrics, building measurement frameworks, or designing A/B experiment guardrails.

Tool Access

This skill is limited to using the following tools:

ReadGlobGrepWebFetchWebSearch
Supporting Assets
View in Repository
references/okr-workshop-guide.md
rules/_sections.md
rules/metrics-experiment-design.md
rules/metrics-instrumentation.md
rules/metrics-kpi-trees.md
rules/metrics-leading-lagging.md
rules/metrics-okr.md
test-cases.json
Skill Content

OKR Design & Metrics Framework

Structure goals, decompose metrics into KPI trees, identify leading indicators, and design rigorous experiments.

OKR Structure

Objectives are qualitative and inspiring. Key Results are quantitative and outcome-focused — never a list of outputs.

Objective: Qualitative, inspiring goal (70% achievable stretch)
+-- Key Result 1: [Verb] [metric] from [baseline] to [target]
+-- Key Result 2: [Verb] [metric] from [baseline] to [target]
+-- Key Result 3: [Verb] [metric] from [baseline] to [target]
## Q1 OKRs

### Objective: Become the go-to platform for enterprise teams

Key Results:
- KR1: Increase enterprise NPS from 32 to 50
- KR2: Reduce time-to-value from 14 days to 3 days
- KR3: Achieve 95% feature adoption in first 30 days of onboarding
- KR4: Win 5 competitive displacements from [Competitor]

OKR Quality Checks

CheckObjectiveKey Result
Has a numberNOYES
Inspiring / energizingYESnot required
Outcome-focused (not "ship X features")YESYES
70% achievable (stretch, not sandbagged)YESYES
Aligned to higher-level goalYESYES

See references/okr-workshop-guide.md for a full facilitation agenda (3-4 hours, dot voting, finalization template). See rules/metrics-okr.md for pitfalls and alignment cascade patterns.


KPI Tree & North Star

Decompose the top-level metric into components with clear cause-effect relationships.

Revenue (Lagging — root)
├── New Revenue = Leads × Conv Rate          (Leading)
├── Expansion   = Users × Upsell Rate        (Leading)
└── Retained    = Existing × (1 - Churn)     (Lagging)

North Star + Input Metrics Template

## Metrics Framework

North Star: [One metric that captures core value — e.g., Weekly Active Teams]

Input Metrics (leading, actionable by teams):
1. New signups — acquisition
2. Onboarding completion rate — activation
3. Features used per user/week — engagement
4. Invite rate — virality
5. Upgrade rate — monetization

Lagging Validation (confirm inputs translate to value):
- Revenue growth
- Net retention rate
- Customer lifetime value

North Star Selection by Business Type

BusinessNorth Star ExampleWhy
SaaSWeekly Active UsersIndicates ongoing value delivery
MarketplaceGross Merchandise ValueCaptures both buyer and seller sides
MediaTime spentEngagement signals content value
E-commercePurchase frequencyRepeat = satisfaction

See rules/metrics-kpi-trees.md for the full revenue and product health KPI tree examples.


Leading vs Lagging Indicators

Every lagging metric you want to improve needs 2-3 leading predictors.

## Metric Pairs

Lagging: Customer Churn Rate
Leading:
  1. Product usage frequency (weekly)
  2. Support ticket severity (daily)
  3. NPS score trend (monthly)

Lagging: Revenue Growth
Leading:
  1. Pipeline value (weekly)
  2. Demo-to-trial conversion (weekly)
  3. Feature adoption rate (weekly)
IndicatorReview CadenceAction Timeline
LeadingDaily / WeeklyImmediate course correction
LaggingMonthly / QuarterlyStrategic adjustments

See rules/metrics-leading-lagging.md for a balanced dashboard template.


Metric Instrumentation

Every metric needs a formal definition before instrumentation.

## Metric: Feature Adoption Rate

Definition: % of active users who used [feature] at least once in their first 30 days.
Formula: (Users who triggered feature_activated in first 30 days) / (Users who signed up)
Data Source: Analytics — feature_activated event
Segments: By plan tier, by signup cohort
Calculation: Daily
Review: Weekly

Events:
  user_signed_up  { user_id, plan_tier, signup_source }
  feature_activated { user_id, feature_name, activation_method }

Event naming: object_action in snake_case — user_signed_up, feature_activated, subscription_upgraded.

See rules/metrics-instrumentation.md for the full metric definition template, alerting thresholds, and dashboard design principles.


Experiment Design

Every experiment must define guardrail metrics before launch. Guardrails prevent shipping a "win" that causes hidden damage.

## Experiment: [Name]

### Hypothesis
If we [change], then [primary metric] will [direction] by [amount]
because [reasoning based on evidence].

### Metrics
- Primary: [The metric you are trying to move]
- Secondary: [Supporting context metrics]
- Guardrails: [Metrics that MUST NOT degrade — define thresholds]

### Design
- Type: A/B test | multivariate | feature flag rollout
- Sample size: [N per variant — calculated for statistical power]
- Duration: [Minimum weeks to reach significance]

### Rollout Plan
1. 10% — 1 week canary, monitor guardrails daily
2. 50% — 2 weeks, confirm statistical significance
3. 100% — full rollout with continued monitoring

### Kill Criteria
Any guardrail degrades > [threshold]% relative to baseline.

Pre-Launch Checklist

  • Hypothesis documented with expected effect size
  • Primary, secondary, and guardrail metrics defined
  • Sample size calculated for minimum detectable effect
  • Dashboard or alerts configured for guardrail metrics
  • Staged rollout plan with kill criteria at each stage
  • Rollback procedure documented

See rules/metrics-experiment-design.md for guardrail thresholds, performance and business guardrail tables, and alert SLAs.


Common Pitfalls

PitfallMitigation
KRs are outputs ("ship 5 features")Rewrite as outcomes ("increase conversion by 20%")
Tracking only lagging indicatorsPair every lagging metric with 2-3 leading predictors
No baseline before setting targetsInstrument and measure for 2 weeks before setting OKRs
Launching experiments without guardrailsDefine guardrails before any code is shipped
Too many OKRs (>5 per team)Limit to 3-5 objectives, 3-5 KRs each
Metrics without ownersEvery metric needs a team owner

Related Skills

  • prioritization — RICE, WSJF, ICE, MoSCoW scoring; OKRs define which KPIs drive RICE impact
  • product-frameworks — Full PM toolkit: value prop, competitive analysis, user research, business case
  • product-analytics — Instrument and query the metrics defined in OKR trees
  • write-prd — Embed success metrics and experiment hypotheses into product requirements
  • market-sizing — TAM/SAM/SOM that anchors North Star Metric targets
  • competitive-analysis — Competitor benchmarks that inform KR targets

Version: 1.0.0

Stats
Stars128
Forks14
Last CommitMar 9, 2026
Actions

Similar Skills