本文へ移動
cccskills
無料GitHub で公開

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

インストール方法を見る

含まれるファイル(4)

  • SKILL.md7.5 KB
  • assets/kpi.md4.0 KB
  • references/benchmarks.md3.9 KB
  • references/examples.md5.0 KB

SKILL.md(原文)

インストールする前に、エージェントに与えられる指示の中身を確認できます。

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:

TierMetric TypesWhy It Matters
Tier 1Revenue (MRR, first dollar, ACV), Churn (logo, NRR), LTV:CACRevenue validates market fit. "First dollar IS the proof."
Tier 2Conversion rates (trial→paid, lead→customer), Time to Value, ActivationLeading indicators that predict Tier 1 outcomes
Tier 3Engagement (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 TypePrimary MetricsAnti-Metrics (Avoid)
CloneFeature parity score, Price delta vs. leader, TTFV vs. leaderGeneric engagement (doesn't prove you beat leader)
UndercutPrice per [unit] vs. leader, Niche conversion rate, CAC in target segmentBroad market share (you're niche by design)
UnbundleCategory NPS vs. platform, Vertical retention, Feature depth usagePlatform-level metrics (irrelevant to your slice)
SliceMarketplace ranking, Install→activate rate, Platform retention liftTAM metrics (platform owns the market)
WrapperTime saved per workflow, API reliability, Integration adoptionStandalone usage (value is in connection)
InnovationEducation→activation conversion, Behavioral change rate, Reference customersUser 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 this — e.g., "v0.5 Red Team kill criteria"]
Measurement: [How/when measured — e.g., "Weekly via Mixpanel"]

Example KPI- entry:

KPI-001: Time to First Revenue
Type: Tier 1
Category: Lagging
Definition: Days from market signal identification to first paying customer
Target: ≤14 days (GearHeart standard: Signal → $1: 14 days)
Evidence: BR-001 (GearHeart methodology)
Downstream Gate: v0.5 Red Team — if not hit by Day 21, evaluate pivot
Measurement: Manual tracking in PRD changelog

Anti-Patterns to Avoid

  1. Vanity metrics as primary: "50K users" means nothing if only 500 pay
  2. Traffic without quality: High volume + low engagement = quality problem
  3. Arbitrary targets: "10% improvement" without baseline or benchmark
  4. All lagging, no leading: Can't course-correct if you only see outcomes monthly
  5. Ignoring product type: Clone metrics ≠ Innovation metrics
  6. Unmeasurable outcomes: "Better experience" — how do you know?

Downstream Connections

KPI- entries feed into:

ConsumerWhat It UsesExample
v0.5 Red TeamKill thresholds"If KPI-001 not hit by Day 21, pivot"
v0.7 Build ExecutionEPIC acceptance criteria"EPIC complete when KPI-002 validated"
v0.9 GTMLaunch dashboardTrack KPI-001, KPI-003 post-launch
BR- Business RulesDerived constraints"BR-XXX: No launch if LTV:CAC <3:1"

Detailed References

  • Good/bad examples: See references/examples.md
  • Benchmark sources: See references/benchmarks.md
  • KPI template worksheet: See assets/kpi.md

レビュー

まだレビューはありません。使ってみた感想をお寄せください。

同じリポジトリのスキル

概要と使いどころ

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 `/ghm-gate-check`.

日本語の概要は準備中です。原文の説明を表示しています。

mattgierhart/PRD-driven-context-engineering1812026年8月31日 更新

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.

日本語の概要は準備中です。原文の説明を表示しています。

mattgierhart/PRD-driven-context-engineering1812026年8月31日 更新

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.

日本語の概要は準備中です。原文の説明を表示しています。

mattgierhart/PRD-driven-context-engineering1812026年8月31日 更新

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 product content. Triggers on "install the methodology", "adopt this into my repo", "self-install", "set up PRD lifecycle here", "onboard existing project". Outputs an installed framework + a verification report.

日本語の概要は準備中です。原文の説明を表示しています。

mattgierhart/PRD-driven-context-engineering1812026年8月31日 更新

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 properly structured SoT.*.md file with ID prefix, frontmatter, and update protocol.

日本語の概要は準備中です。原文の説明を表示しています。

mattgierhart/PRD-driven-context-engineering1812026年8月31日 更新

Synchronizes README.md Command Center with current project state. Triggers on gate changes, EPIC status changes, or explicit `/ghm-status-sync` invocation. Outputs updated README.md dashboard with current lifecycle stage, blockers, and metrics.

日本語の概要は準備中です。原文の説明を表示しています。

mattgierhart/PRD-driven-context-engineering1812026年8月31日 更新

mattgierhart のスキルをすべて見る

このスキルの問題を報告する