/prd-v03-outcome-definition
Define measurable success metrics (KPIs) tied to product type during PRD v0.3 Commercial Model. Triggers on requests to define success metrics, set KPI targets, determine what to measure, establish go/no-go thresholds, or when user asks "how do we measure success?", "what
$ npx -y skills add mattgierhart/PRD-driven-context-engineering --skill prd-v03-outcome-definition --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
- Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.Auto-invocation is when the right skill fires by itself at the right moment, driven by a FLOW.md router and a hook, instead of you invoking it by name. It is the difference between a skill being installed and a skill actually getting used.Read the full definition →
- You can call itInvoke it directly when you want it.
- Slash command
/prd-v03-outcome-definition
Context preview
The summary Claude sees to decide when to auto-load this skill.
Define measurable success metrics (KPIs) tied to product type during PRD v0.3 Commercial Model. Triggers on requests to define success metrics, set KPI targets, determine what to measure, establish go/no-go thresholds, or when user asks "how do we measure success?", "what
SKILL.md
prd-v03-outcome-definition.SKILL.mdname: prd-v03-outcome-definition
description: Define measurable success metrics (KPIs) tied to product type during PRD v0.3 Commercial Model. Triggers on requests to define success metrics, set KPI targets, determine what to measure, establish go/no-go thresholds, or when user asks "how do we measure success?", "what metrics matter?", "what's our target?", "how do we know if this works?", "define KPIs", "success criteria". Consumes Product Type Classification (BR-) from v0.2. Outputs KPI- entries with thresholds, evidence sources, and downstream gate linkages.
context: fork
allowed-tools:
- Read
- Write
- Edit
- Glob
- Grep
- WebSearch
- WebFetch
Outcome Definition
Position in HORIZON workflow: v0.2 Product Type Classification → **v0.3 Outcome Definition** → v0.3 Pricing Model Selection
Consumes
This skill requires prior work from v0.2:
- **BR-\* product type entry** (from Product Type Classification) — Classification determines which metrics are relevant
- **CFD-\* entries** (from Problem Framing and Competitive Landscape) — Customer evidence about desired outcomes
- **Market benchmarks and competitor metrics** — Reference data for Tier 1/2 targets
This skill assumes v0.2 classification is complete.
Produces
This skill creates/updates:
- **KPI-\* entries** (outcome definitions) — Measurable success metrics tied to product type
- **BR-\* outcome rules** (optional) — Constraints derived from KPI thresholds (e.g., "Launch blocked if LTV:CAC < 3:1")
- **Success criteria artifact** — Dashboard of leading + lagging indicators that define product-market fit
All KPI entries should include:
- `confidence: 2-3/5` (based on benchmark evidence, not just assumptions)
- Evidence source (competitor benchmarks, CFD validation, industry reports)
- Forward target: "Would move to 4/5 if we observe real customer data"
Example KPI entry with confidence:
KPI-001: Time to First Revenue
Type: Tier 1 (Revenue)
Category: Lagging
Definition: Days from market signal identification to first paying customer
Target: ≤14 days
Confidence: 2/5 (source: GearHeart-methodology + 0-customer-validation)
Evidence: BR-001 (GearHeart standard); No pre-customer validation yet
Next Target: "Would move to 4/5 if actual customer reaches paying status in ≤14 days"
Downstream Gate: v0.5 Red Team — if not hit by Day 21, evaluate pivot
---
KPI-002: Conversion Rate (Trial → Paid)
Type: Tier 2 (Leading Indicator)
Category: Leading
Definition: (Paid customers / Trial signups) × 100, measured over 60-day trial period
Target: ≥15% (benchmark: SaaS median 10-15%)
Confidence: 3/5 (source: SaaS-benchmarks + 1-SMB-validation-conversation)
Evidence: CFD-042 (competitive landscape shows SMB conversion patterns)
Next Target: "Would move to 4/5 if we see actual cohort conversion in our product"
Downstream Gate: v0.7 Build Execution — EPIC complete when KPI-002 validated
Metric Quality Hierarchy
Not all metrics are equal. Use this tier system:
| Tier | Metric Types | Why It Matters | |------|--------------|----------------| | **Tier 1** | Revenue (MRR, first dollar, ACV), Churn (logo, NRR), LTV:CAC | Revenue validates market fit. "First dollar IS the proof." | | **Tier 2** | Conversion rates (trial→paid, lead→customer), Time to Value, Activation | Leading indicators that predict Tier 1 outcomes | | **Tier 3** | Engagement (DAU, sessions), Feature adoption, NPS | "Nice to know" — only track if tied to Tier 1/2 |
**Rule**: Every product needs at least one Tier 1 metric. Tier 3 metrics without Tier 1/2 correlation are vanity metrics.
Product Type × Metric Selection
Metrics must align with product type from v0.2 classification:
| Product Type | Primary Metrics | Anti-Metrics (Avoid) | |--------------|-----------------|----------------------| | **Clone** | Feature parity score, Price delta vs. leader, TTFV vs. leader | Generic engagement (doesn't prove you beat leader) | | **Undercut** | Price per [unit] vs. leader, Niche conversion rate, CAC in target segment | Broad market share (you're niche by design) | | **Unbundle** | Category NPS vs. platform, Vertical retention, Feature depth usage | Platform-level metrics (irrelevant to your slice) | | **Slice** | Marketplace ranking, Install→activate rate, Platform retention lift | TAM metrics (platform owns the market) | | **Wrapper** | Time saved per workflow, API reliability, Integration adoption | Standalone usage (value is in connection) | | **Innovation** | Education→activation conversion, Behavioral change rate, Reference customers | User counts without activation (people try, don't convert) |
Leading vs. Lagging Framework
Every product needs BOTH:
**Leading Indicators** (actionable now, predict outcomes):
- Sequences sent, open rates, trial starts
- Time to first value, activation rate
- Feature adoption in first 7 days
**Lagging Indicators** (confirm strategy worked):
- MRR, churn rate, LTV:CAC
- Net Revenue Retention (NRR)
- Customer count, logo churn
**Pattern**: Track leading weekly, lagging monthly. If leading indicators fail, you can pivot before lagging indicators confirm disaster.
Target-Setting Rules
Targets must be evidence-based, never arbitrary:
**Good targets** (use these approaches):
- Competitor benchmark × safety margin: "SMB churn benchmark 3-5% → use 5%"
- Revenue gates: "First dollar by Day 14" (Signal → $1: 14 days)
- Ratio thresholds: "LTV:CAC ≥ 3:1"
- Time bounds: "TTFV < 5 minutes for self-serve"
**Bad targets** (anti-patterns):
- Round numbers without evidence: "10% improvement"
- Engagement without revenue tie: "1000 DAU"
- Aspirational without baseline: "Best in class retention"
Output Template
Create KPI- entries in this format:
KPI-XXX: [Metric Name]
Type: [Tier 1 | Tier 2 | Tier 3]
Category: [Leading | Lagging]
Definition: [Exact calculation formula]
Target: [Specific threshold with evidence source]
Evidence: [CFD-XXX or benchmark source]
Downstream Gate: [Which decision uses t
Read more
name: prd-v03-outcome-definition description: Define measurable success metrics (KPIs) tied to product type during PRD v0.3 Commercial Model. Triggers on requests to define success metrics, set KPI targets, determine what to measure, establish go/no-go thresholds, or when user asks "how do we measure success?", "what metrics matter?", "what's our target?", "how do we know if this works?", "define KPIs", "success criteria". Consumes Product Type Classification (BR-) from v0.2. Outputs KPI- entries with thresholds, evidence sources, and downstream gate linkages. context: fork allowed-tools: - Read - Write - Edit - Glob - Grep - WebSearch - WebFetch
Outcome Definition
Position in HORIZON workflow: v0.2 Product Type Classification → **v0.3 Outcome Definition** → v0.3 Pricing Model Selection
Consumes
This skill requires prior work from v0.2:
- **BR-\* product type entry** (from Product Type Classification) — Classification determines which metrics are relevant
- **CFD-\* entries** (from Problem Framing and Competitive Landscape) — Customer evidence about desired outcomes
- **Market benchmarks and competitor metrics** — Reference data for Tier 1/2 targets
This skill assumes v0.2 classification is complete.
Produces
This skill creates/updates:
- **KPI-\* entries** (outcome definitions) — Measurable success metrics tied to product type
- **BR-\* outcome rules** (optional) — Constraints derived from KPI thresholds (e.g., "Launch blocked if LTV:CAC < 3:1")
- **Success criteria artifact** — Dashboard of leading + lagging indicators that define product-market fit
All KPI entries should include:
- `confidence: 2-3/5` (based on benchmark evidence, not just assumptions)
- Evidence source (competitor benchmarks, CFD validation, industry reports)
- Forward target: "Would move to 4/5 if we observe real customer data"
Example KPI entry with confidence:
KPI-001: Time to First Revenue Type: Tier 1 (Revenue) Category: Lagging Definition: Days from market signal identification to first paying customer Target: ≤14 days Confidence: 2/5 (source: GearHeart-methodology + 0-customer-validation) Evidence: BR-001 (GearHeart standard); No pre-customer validation yet Next Target: "Would move to 4/5 if actual customer reaches paying status in ≤14 days" Downstream Gate: v0.5 Red Team — if not hit by Day 21, evaluate pivot --- KPI-002: Conversion Rate (Trial → Paid) Type: Tier 2 (Leading Indicator) Category: Leading Definition: (Paid customers / Trial signups) × 100, measured over 60-day trial period Target: ≥15% (benchmark: SaaS median 10-15%) Confidence: 3/5 (source: SaaS-benchmarks + 1-SMB-validation-conversation) Evidence: CFD-042 (competitive landscape shows SMB conversion patterns) Next Target: "Would move to 4/5 if we see actual cohort conversion in our product" Downstream Gate: v0.7 Build Execution — EPIC complete when KPI-002 validated
Metric Quality Hierarchy
Not all metrics are equal. Use this tier system:
| Tier | Metric Types | Why It Matters | |------|--------------|----------------| | **Tier 1** | Revenue (MRR, first dollar, ACV), Churn (logo, NRR), LTV:CAC | Revenue validates market fit. "First dollar IS the proof." | | **Tier 2** | Conversion rates (trial→paid, lead→customer), Time to Value, Activation | Leading indicators that predict Tier 1 outcomes | | **Tier 3** | Engagement (DAU, sessions), Feature adoption, NPS | "Nice to know" — only track if tied to Tier 1/2 |
**Rule**: Every product needs at least one Tier 1 metric. Tier 3 metrics without Tier 1/2 correlation are vanity metrics.
Product Type × Metric Selection
Metrics must align with product type from v0.2 classification:
| Product Type | Primary Metrics | Anti-Metrics (Avoid) | |--------------|-----------------|----------------------| | **Clone** | Feature parity score, Price delta vs. leader, TTFV vs. leader | Generic engagement (doesn't prove you beat leader) | | **Undercut** | Price per [unit] vs. leader, Niche conversion rate, CAC in target segment | Broad market share (you're niche by design) | | **Unbundle** | Category NPS vs. platform, Vertical retention, Feature depth usage | Platform-level metrics (irrelevant to your slice) | | **Slice** | Marketplace ranking, Install→activate rate, Platform retention lift | TAM metrics (platform owns the market) | | **Wrapper** | Time saved per workflow, API reliability, Integration adoption | Standalone usage (value is in connection) | | **Innovation** | Education→activation conversion, Behavioral change rate, Reference customers | User counts without activation (people try, don't convert) |
Leading vs. Lagging Framework
Every product needs BOTH:
**Leading Indicators** (actionable now, predict outcomes):
- Sequences sent, open rates, trial starts
- Time to first value, activation rate
- Feature adoption in first 7 days
**Lagging Indicators** (confirm strategy worked):
- MRR, churn rate, LTV:CAC
- Net Revenue Retention (NRR)
- Customer count, logo churn
**Pattern**: Track leading weekly, lagging monthly. If leading indicators fail, you can pivot before lagging indicators confirm disaster.
Target-Setting Rules
Targets must be evidence-based, never arbitrary:
**Good targets** (use these approaches):
- Competitor benchmark × safety margin: "SMB churn benchmark 3-5% → use 5%"
- Revenue gates: "First dollar by Day 14" (Signal → $1: 14 days)
- Ratio thresholds: "LTV:CAC ≥ 3:1"
- Time bounds: "TTFV < 5 minutes for self-serve"
**Bad targets** (anti-patterns):
- Round numbers without evidence: "10% improvement"
- Engagement without revenue tie: "1000 DAU"
- Aspirational without baseline: "Best in class retention"
Output Template
Create KPI- entries in this format:
KPI-XXX: [Metric Name] Type: [Tier 1 | Tier 2 | Tier 3] Category: [Leading | Lagging] Definition: [Exact calculation formula] Target: [Specific threshold with evidence source] Evidence: [CFD-XXX or benchmark source] Downstream Gate: [Which decision uses t
PRD-driven Context Engineering: A systematic approach to building AI-powered products using progressive documentation and context-aware development workflows
Repo: mattgierhart/PRD-driven-context-engineering
Other skills on prd-driven-context-engineering.
- /SKILL_TEMPLATE
[1-2 sentence description of what this skill does]. Triggers on [specific phrases/contexts that should activate this skill]. Outputs [what the skill produces].
Open skill - /ghm-gate-check
Validates gate criteria before PRD lifecycle advancement by delegating to the readiness scoring pipeline (scripts/readiness.py). Returns a graduated PASS / WARN / BLOCK verdict with top blockers and their causal chain. Triggers before advancing from v0.X to v0.Y or explicit
Open skill - /ghm-harvest
Extracts durable insights from temp/ files to SoT during EPIC Phase E. Triggers at EPIC completion or explicit `/ghm-harvest` invocation. Outputs new SoT entries and archive manifest.
Open skill - /ghm-id-register
Validates and registers new SoT IDs with cross-reference integrity. Triggers when creating BR-XXX, UJ-XXX, API-XXX, or CFD-XXX entries. Outputs formatted SoT entry with validated cross-references.
Open skill - /ghm-self-install
Install the PRD-Driven Context Engineering methodology into a fresh OR existing repository — the subscription-native alternative to forking the whole repo. Runs an interactive wizard that seeds the framework (.claude/ hooks, skills, agents, rules, scripts) without clobbering
Open skill - /ghm-sot-builder
Creates new Source of Truth (SoT) files when existing templates don't fit your needs. Triggers on requests to create a new SoT file, add a new artifact type, or when user says "I need to track [X] but there's no SoT for it", "create SoT", "new source of truth". Outputs a
Open skill

