diff --git a/.claude/agents/metro/MEMORY.md b/.claude/agents/metro/MEMORY.md index 6792aa8..be2bdb3 100644 --- a/.claude/agents/metro/MEMORY.md +++ b/.claude/agents/metro/MEMORY.md @@ -12,5 +12,14 @@ ## Decisions (choices made with rationale) +**v0.9 GTM is now a chained framework workflow, not a monolithic skill.** Run order: `prd-v09-positioning-dunford` (Dunford 5-step) → `prd-v09-offer-construction-hormozi` ($100M Offers value equation) → `prd-v09-launch-channels-orb` (Owned/Rented/Borrowed). `prd-v09-gtm-strategy` is now the orchestrator that runs these three and reconciles outputs (best-fit alignment, promise consistency, guarantee viability, category-channel fit, KPI rollup). **Why:** monolithic skill was too broad and produced incoherent output across positioning/offer/channels. **Alternatives rejected:** keep monolithic with deeper sub-sections (still too long; no framework grounding); fully delete old skill (breaks backwards compat with existing GTM- entries). + +**v1.0 is anchored on Moore's Crossing the Chasm with new ADO- ID prefix.** Stage assessment (ADO-STAGE-), beachhead segment (ADO-BEACHHEAD-), whole-product gaps (ADO-WHOLE-), reference accounts (ADO-REF-) all live in `SoT/SoT.ADOPTION.md`. **Why:** v1.0 was previously a stub; Moore's lifecycle is the canonical framework for post-launch adoption strategy and pragmatist-buyer behavior. **Alternatives rejected:** keep v1.0 as a PRD.md inline section without first-class SoT (no queryable adoption data; weak traceability for chasm-crossing risks). + +**Tactical playbooks attach to channels from the ORB matrix, not to GTM-strategy directly.** AEO audit, alternatives pages, cold outreach tiered, HN/Reddit launch all run after Launch Channels (ORB) has produced its channel-mix matrix. Each playbook explicitly disqualifies itself when positioning best-fit doesn't match the channel (e.g., HN/Reddit skips for enterprise procurement products). **Why:** running tactical playbooks before strategic channel selection produces channel work that doesn't reach the right segment. + +**Mode tiering (quick/standard/deep) applies to all v0.8/v0.9/v1.0 skills.** Default is standard; quick is appropriate (not degraded). See `.claude/rules/08-skill-execution-modes.md` for full doctrine. **Why:** same operation often needs 15-min founder pass OR 90-min deep audit; previously the only mode was implicitly "standard" which forced over-work on simple cases. + + ## Handoff Notes (friction points between agents) diff --git a/.claude/domain-profile.yaml b/.claude/domain-profile.yaml index c707296..65523a8 100644 --- a/.claude/domain-profile.yaml +++ b/.claude/domain-profile.yaml @@ -37,11 +37,12 @@ id_prefixes: ARC: { file: "SoT/SoT.TECHNICAL_DECISIONS.md", description: "Architecture decisions" } INT: { file: "SoT/SoT.INTEGRATIONS.md", description: "Integrations" } LL: { file: "SoT/SoT.LESSONS_LEARNED.md", description: "Lessons learned (cross-session feedback)" } + ADO: { file: "SoT/SoT.ADOPTION.md", description: "Adoption-stage data (Moore Chasm — stage, beachhead, whole-product, references)" } # PRD/README-owned IDs FEA: { file: "PRD.md", description: "Features (PRD-owned, v0.3)" } RISK: { file: "PRD.md", description: "Risks (PRD-owned, v0.5)" } - GTM: { file: "PRD.md", description: "Go-to-market (PRD-owned, v0.9)" } + GTM: { file: "PRD.md", description: "Go-to-market (PRD-owned, v0.9 — Type sub-codes: Positioning, Offer, Guarantee, Channel, Sequence, Index, AEO, OUT, CHG, MOPS, CASE, TST)" } KPI: { file: "README.md", description: "KPI metrics (README-owned)" } # Execution IDs @@ -81,9 +82,24 @@ skills: - prd-v08-monitoring-setup - prd-v08-release-planning - prd-v08-runbook-creation + - prd-v08-changelog-as-marketing + - prd-v08-drift-baseline-compare + - prd-v08-marketing-ops-handoff - prd-v09-feedback-loop-setup - prd-v09-gtm-strategy - prd-v09-launch-metrics + - prd-v09-positioning-dunford + - prd-v09-offer-construction-hormozi + - prd-v09-launch-channels-orb + - prd-v09-aeo-audit + - prd-v09-alternatives-pages + - prd-v09-cold-outreach-tiered + - prd-v09-hn-reddit-launch + - prd-v10-chasm-adoption-moore + - prd-v10-continuous-discovery-torres + - prd-v10-mom-test-interview + - prd-v10-case-study-builder + - prd-v10-testimonial-collector # --- Agent Registry --- # Product-lifecycle agents. Non-product repos may drop these entirely. diff --git a/.claude/rules/08-skill-execution-modes.md b/.claude/rules/08-skill-execution-modes.md new file mode 100644 index 0000000..f034e46 --- /dev/null +++ b/.claude/rules/08-skill-execution-modes.md @@ -0,0 +1,73 @@ +# Skill Execution Modes (quick / standard / deep) + +PRD-lifecycle skills run in one of three depth modes. The mode shapes time budget, output depth, and which optional steps run — it does not change whether the skill is correct or which Source-of-Truth IDs it owns. + +| Mode | Time | When to pick it | Output shape | +|------|------|-----------------|--------------| +| **quick** | < 15 min | Solo founder gut-check, "before I commit", rough first pass | 3–5 SoT IDs, no validation rounds, confidence may be 1/5 | +| **standard** (default) | 30–45 min | Normal session, first real attempt at the stage | Full skill execution, every `Consumes` input checked, confidence ≥ 2/5 | +| **deep** | 60–90 min | Critical decision, team-facing, pre-investor, audit | Full + research loops + assumptions log + cross-skill validation, confidence ≥ 3/5 where evidence exists | + +## Picking a mode + +Default is **standard**. Use the user's framing to infer otherwise. + +| Signal in user request | Mode | +|------------------------|------| +| "rough idea", "quick pass", "gut-check", "before I commit" | quick | +| "define", "set up", "plan", "let's do" | standard | +| "audit", "deep dive", "thorough", "investor-ready", "team review", "stress-test" | deep | + +Quick is **appropriate, not degraded**. Don't refuse it because "the proper way is more thorough" — the user picked the trade. Honor the time budget by cutting optional steps (`[standard+]`, `[deep only]`), not by speed-running every step. + +Only ask the user when framing is genuinely ambiguous. + +## Tagging skill phases (for skill authors) + +In `SKILL.md` execution steps, annotate optional phases: + +- *(no tag)* — runs in all modes +- `[standard+]` — runs in standard and deep only +- `[deep only]` — runs in deep only + +Each skill's frontmatter declares supported modes: + +```yaml +execution_modes: + default: standard + supports: [quick, standard, deep] +``` + +If a skill genuinely only supports one mode (e.g., a `TEST-` generator that must be exhaustive), declare `supports: [standard]` and explain why in the SKILL.md preamble. + +## How depth shows up in outputs + +| Output dimension | quick | standard | deep | +|------------------|-------|----------|------| +| SoT IDs created | 3–5 | full | full + assumption log | +| Confidence floor ([P4](../skills/PRINCIPLES.md)) | 1/5 OK | 2/5 minimum | 3/5 minimum where evidence exists | +| Consumes / Produces sections | always emitted | always emitted | always emitted | +| Consumes detail | only obviously-linked IDs | full chain | full chain + downstream impact analysis | +| Anti-pattern check | skipped | done | done with concrete examples called out | +| Cross-skill validation | none | one pass | iterative until clean | + +`Consumes` and `Produces` sections are emitted in **every** mode — the mode affects depth of *content*, not whether the section exists. + +## Anti-patterns + +| Pattern | Fix | +|---------|-----| +| Always running deep regardless of question | Pick the mode that fits the decision | +| Calling output "quick" but doing standard work | Honor the budget; cut optional phases | +| Skipping confidence floors in deep mode | Deep raises the evidence bar, doesn't lower it | +| Adding `[deep only]` to mandatory phases | If a phase is required for correctness, it runs in all modes | +| Quick mode without acknowledging the trade | Say which optional phases you skipped and why | + +## Relationship to P3 and P4 + +Modes are a **time/scope dial**, not a research bypass: + +- **quick mode** acknowledges confidence will be 1/5–2/5 and tags outputs accordingly. It does not pretend evidence is stronger than it is. +- **deep mode** raises the confidence floor — if you can't reach 3/5 with available evidence, the skill output should explicitly say *"blocked on research"* and surface the missing inputs. + +See [`PRINCIPLES.md`](../skills/PRINCIPLES.md) P3 (Research Drives Scope) and P4 (SoT is Living Evidence) for the underlying discipline. diff --git a/.claude/skills/README.md b/.claude/skills/README.md index 1c53a06..3a67d8c 100644 --- a/.claude/skills/README.md +++ b/.claude/skills/README.md @@ -52,9 +52,24 @@ skills/ ├── prd-v08-release-planning/ # v0.8 Release ├── prd-v08-runbook-creation/ # v0.8 Release ├── prd-v08-monitoring-setup/ # v0.8 Release -├── prd-v09-gtm-strategy/ # v0.9 Launch +├── prd-v08-changelog-as-marketing/ # v0.8 Release (bridge to GTM) +├── prd-v08-drift-baseline-compare/ # v0.8 Release (drift monitoring) +├── prd-v08-marketing-ops-handoff/ # v0.8 Release (lead lifecycle) +├── prd-v09-gtm-strategy/ # v0.9 Launch (orchestrator) +├── prd-v09-positioning-dunford/ # v0.9 Launch (Dunford 5-step) +├── prd-v09-offer-construction-hormozi/ # v0.9 Launch (Hormozi $100M Offers) +├── prd-v09-launch-channels-orb/ # v0.9 Launch (ORB framework) +├── prd-v09-aeo-audit/ # v0.9 Launch (AI search visibility) +├── prd-v09-alternatives-pages/ # v0.9 Launch (X-vs-Y SEO pages) +├── prd-v09-cold-outreach-tiered/ # v0.9 Launch (Tier 1/2/3 outreach) +├── prd-v09-hn-reddit-launch/ # v0.9 Launch (HN + Reddit playbook) ├── prd-v09-launch-metrics/ # v0.9 Launch ├── prd-v09-feedback-loop-setup/ # v0.9 Launch +├── prd-v10-chasm-adoption-moore/ # v1.0 Adoption (Moore — the spine) +├── prd-v10-continuous-discovery-torres/ # v1.0 Adoption (Torres) +├── prd-v10-mom-test-interview/ # v1.0 Adoption (Fitzpatrick) +├── prd-v10-case-study-builder/ # v1.0 Adoption (social proof) +├── prd-v10-testimonial-collector/ # v1.0 Adoption (social proof) ├── ghm-gate-check/ # Methodology ├── ghm-id-register/ # Methodology ├── ghm-status-sync/ # Methodology @@ -62,7 +77,7 @@ skills/ └── ghm-sot-builder/ # Methodology ``` -**29 skills total** covering the complete PRD lifecycle v0.1→v1.0. +**44 skills total** covering the complete PRD lifecycle v0.1→v1.0, including framework-grounded v0.9 (Dunford / Hormozi / ORB) and v1.0 (Moore Chasm / Torres / Mom Test) skills. --- @@ -77,8 +92,9 @@ skills/ | **v0.5 Red Team** | Risk Discovery Interview, Technical Stack Selection | 2 | | **v0.6 Arch** | Architecture Design, Technical Specification | 2 | | **v0.7 Build** | Epic Scoping, Test Planning, Implementation Loop | 3 | -| **v0.8 Release** | Release Planning, Runbook Creation, Monitoring Setup | 3 | -| **v0.9 Launch** | GTM Strategy, Launch Metrics, Feedback Loop Setup | 3 | +| **v0.8 Release** | Release Planning, Runbook Creation, Monitoring Setup, Changelog-as-Marketing, Drift Baseline/Compare, Marketing-Ops Handoff | 6 | +| **v0.9 Launch** | GTM Strategy (orchestrator), Positioning (Dunford), Offer Construction (Hormozi), Launch Channels (ORB), AEO Audit, Alternatives Pages, Cold Outreach Tiered, HN/Reddit Launch, Launch Metrics, Feedback Loop Setup | 10 | +| **v1.0 Adoption** | Crossing the Chasm (Moore), Continuous Discovery (Torres), Mom Test Interview (Fitzpatrick), Case Study Builder, Testimonial Collector | 5 | | **Methodology** | Gate Check, ID Register, Status Sync, Harvest, SoT Builder | 5 | See [`skills-inventory.md`](skills-inventory.md) for full specifications. diff --git a/.claude/skills/prd-v08-changelog-as-marketing/SKILL.md b/.claude/skills/prd-v08-changelog-as-marketing/SKILL.md new file mode 100644 index 0000000..219c74e --- /dev/null +++ b/.claude/skills/prd-v08-changelog-as-marketing/SKILL.md @@ -0,0 +1,209 @@ +--- +name: prd-v08-changelog-as-marketing +description: > + Design the changelog as a distribution surface bridging engineering releases (DEP-/FEA-) to + marketing channels (GTM-) during PRD v0.8 Deployment & Ops. Triggers on requests to set up a + changelog system, publish releases, or when user asks "how should we publish releases?", + "changelog as marketing", "release notes", "Stripe-style changelog", "what to do with our + release notes", "ship and tell". Outputs MON-CHG-* changelog entries and per-channel formats. +context: fork +allowed-tools: + - Read + - Write + - Edit + - Glob + - Grep + +execution_modes: + default: standard + supports: [quick, standard, deep] +--- + +# Changelog as Marketing + +Position in workflow: v0.8 Release Planning → **v0.8 Changelog as Marketing** → v0.9 Launch Channels (ORB) + +## Execution Mode + +Default is **standard**. See [`.claude/rules/08-skill-execution-modes.md`](../../rules/08-skill-execution-modes.md) for selection logic. + +| Mode | What this skill produces | +|------|--------------------------| +| **quick** | One release format (markdown for site); one channel mapping; minimum-viable changelog page | +| **standard** | Release categorization + 2–3 channel mappings; per-channel format templates; publish cadence; attribution plan | +| **deep** | Full categorization taxonomy; format templates for all relevant channels (email, blog, Twitter, LinkedIn, RSS, Slack); cadence + voice guide; KPI- attribution per channel | + +## What This Does + +Treats the changelog as a **distribution surface**, not an engineering record. Each shipped release becomes a content artifact that lands across Owned and Rented channels with minimal extra effort. This is the bridge between v0.8 (what shipped) and v0.9 (where it gets told). + +Done well, this is one of the highest-leverage Owned-channel investments — Stripe, Linear, Vercel, and Sentry have shown that an opinionated changelog drives ongoing inbound that compounds over years. Done badly, it's a dumping ground for "fixed bug X" that nobody reads. + +## How It Works + +1. **Define the changelog audience(s)** — Engineering changelogs (for users running self-hosted or integrating an API), customer-facing changelogs (for end-users), and internal changelogs (for the team) have different shapes. Anchor to the Positioning best-fit segment. +2. **Categorize release content** — Each shipped item gets a category: + - **New feature** (publish loudly) + - **Improvement** (publish, briefly) + - **Breaking change** (publish, prominently, with migration path) + - **Deprecation** (publish, with timeline) + - **Fix** (publish only if user-visible) + - **Internal** (don't publish externally) +3. **Map categories to channels** — Each category gets a channel destination from the ORB mix: + - New feature → Blog post + email + Twitter + LinkedIn + - Breaking change → Email (high-priority) + RSS + blog + - Improvement → Blog (digest) + Twitter (digest) + - Fix → Changelog page only +4. **Build per-channel format templates** — Each channel has a length/tone constraint: + - Email: subject line + 2-paragraph body + CTA + - Blog: full writeup, screenshots, code samples + - Twitter/X: 280 chars, one image + - LinkedIn: 1,000-1,500 chars, professional voice + - Slack/Discord: short with link to blog + - RSS: full content for engineering audiences +5. **Set publish cadence** — Per-release (every shipped release publishes immediately) vs. digest (weekly/monthly roll-up). Most teams need both: per-release for big things, digest for the rest. +6. **Plan attribution** — Every channel-published release gets a UTM. Track changelog → signup conversion to identify which categories convert. + +## Example + +A developer-tools product ships: + +| Item | Category | Channels | +|------|----------|----------| +| New `/api/v2/webhooks` endpoint | New feature | Blog (full), email, Twitter, LinkedIn, RSS | +| `/api/v1/webhooks` deprecation (sunset in 6mo) | Deprecation | Email (high-priority), blog, RSS | +| 30% faster response time on heavy queries | Improvement | Twitter, weekly digest | +| Fixed: webhook signing edge case | Fix | Changelog page only | +| Internal: refactored auth middleware | Internal | (none) | + +Tuesday publish: +- Blog post: "Webhooks v2 is live — here's what changed and how to migrate" +- Email to API customers (segment-targeted, not full list): "Action needed: webhook v1 sunset" +- Twitter: "Webhooks v2 ships today. v1 is sunset in 6 months. Migration guide: [link]" +- Changelog page: all five items (including the fix and internal note marked appropriately) + +## What You Get Back + +- **MON-CHG-\* changelog entries** (one per shipped release) — Master record with category, audience, channel mapping, links to per-channel publications +- **GTM-CHG-\* per-channel formats** (one per channel) — Templates and example content +- **Publish cadence schedule** — Per-release vs. digest decisions +- **KPI attribution plan** — UTMs and conversion tracking + +## When to Use It + +| Trigger | Mode | +|---------|------| +| First release post-launch (no changelog system yet) | quick | +| Standard launch cadence stabilizing | standard | +| Pre-investor / pre-Series A — changelog as proof of velocity | deep | +| API or developer-tool product | deep (changelog is a primary surface) | +| One-time announcements (acquisition, big feature) | standard | + +## Consumes + +- **DEP-\* release entries** (from v0.8 Release Planning) — What's being released, when +- **FEA-\* features** (from v0.3) — What new features exist; categorization input +- **GTM-\* channel mix** (from v0.9 Launch Channels ORB, when available) — Where to publish +- **GTM-\* positioning** (from v0.9 Positioning, when available) — Voice and tone constraints +- **PER-\* best-fit characteristics** — Audience tone calibration +- **KPI-\* baselines** — Attribution targets + +> When this skill runs before v0.9 has executed, channel mapping uses placeholder channels and is reconciled when v0.9 channels are finalized. + +## Produces + +- **MON-CHG-\* entries** in `SoT/SoT.DEPLOYMENT.md` (or a dedicated `SoT/SoT.CHANGELOG.md` if release volume warrants) +- **GTM-CHG-\* entries** with `Type=Channel-Changelog` (per-channel format templates) +- **CFD-\* gaps surfaced** — If a release category lacks an obvious channel mapping, log as research gap + +## Output Template + +``` +MON-CHG-XXX: Release — [Release name / version] +Type: Changelog +Date: YYYY-MM-DD +Owner: [Person / role] +Status: [Drafted | Reviewed | Published] + +Released items: + - [Item 1] — Category: [New feature | Improvement | Breaking change | Deprecation | Fix | Internal] + - [Item 2] — Category: ... + +Audience: [API customers | All users | Internal team | Mixed] + +Channel publications: + - Blog: [URL or "scheduled YYYY-MM-DD"] + - Email: [Segment + scheduled date] + - Twitter: [Scheduled date] + - LinkedIn: [Scheduled date] + - Changelog page: [Updated YYYY-MM-DD] + +Attribution: utm_campaign=changelog- + +Linked IDs: DEP-AAA (release), FEA-BBB (features shipped), GTM-CHG-CCC (channel formats), KPI-DDD (attribution) +``` + +``` +GTM-CHG-XXX: Channel Format — [Channel name] +Type: Channel-Changelog +Channel: [Blog | Email | Twitter | LinkedIn | RSS | Slack] +Owner: [Person / role] + +Format constraints: + Length: [chars / words / sections] + Tone: [Conversational | Technical | Formal — anchored in Positioning voice] + Visuals: [Required / optional] + CTA: [Specific action expected] + +Template: + [Reusable template for this channel, with variable placeholders] + +Example (most recent use): + [Concrete example from MON-CHG-XXX] + +Publish trigger: [Per-release | Weekly digest | Monthly digest] + +Linked IDs: MON-CHG-AAA (latest use), GTM-YYY (positioning voice) +``` + +## Anti-Patterns + +| Pattern | Signal | Fix | +|---------|--------|-----| +| **Dumping internal commits** | Changelog reads like `git log` | Categorize; publish only what users care about | +| **Same content everywhere** | Same blog post copy-pasted to Twitter and LinkedIn | Each channel has its own format constraints; honor them | +| **Vague feature claims** | "Various improvements" | Name the specific change; "30% faster heavy queries" beats "performance improvements" | +| **Engineering-only voice** | Customer changelog uses internal jargon | Tone-shift per audience; engineer changelog ≠ end-user changelog | +| **No attribution** | Changelog publishes but no idea what converts | UTM every link; track per-channel conversion | +| **Sporadic cadence** | Publish heavily for 2 months, then quiet for 6 | Pick per-release or digest cadence; commit to it | +| **Breaking change buried** | Hidden in a sea of small items | Breaking changes get a dedicated, prominent slot | + +## Quality Gates + +Before publishing the first release: + +- [ ] Audience(s) defined (engineering, customer-facing, internal — separately if needed) +- [ ] Categorization scheme exists (at minimum: new / improvement / breaking / fix) +- [ ] Channel mapping table exists (categories → channels) +- [ ] Per-channel format templates exist +- [ ] Publish cadence committed +- [ ] Attribution plan (UTM convention) defined +- [ ] Voice/tone honors GTM- positioning (if v0.9 is done) + +## Downstream Connections + +| Consumer | What it uses | Example | +|----------|--------------|---------| +| **Launch Channels (ORB)** | Changelog is an Owned channel; rolls into mix matrix | Blog-changelog = Owned-content | +| **Launch Metrics** | Per-channel changelog conversion targets | KPI-changelog-blog-signups | +| **Feedback Loop Setup** | Changelog reader comments become CFD- | Blog comment threads → CFD- pattern | +| **AEO Audit** | High-traffic changelog posts become AI citation sources | Changelog entries cited by AI search | +| **v1.0 Case Study Builder** | Shipped features in changelog feed case study material | "How we use [feature] at [customer]" | + +## Detailed References + +- Stripe changelog: [stripe.com/changelog](https://stripe.com/changelog) — the canonical example +- Linear changelog: [linear.app/changelog](https://linear.app/changelog) — opinionated voice +- Vercel changelog: [vercel.com/changelog](https://vercel.com/changelog) — visual-heavy +- jonathimer's `changelog-updates` skill (devmarketing-skills) +- (No bundled `references/` — read the source examples for current best practice) diff --git a/.claude/skills/prd-v08-drift-baseline-compare/SKILL.md b/.claude/skills/prd-v08-drift-baseline-compare/SKILL.md new file mode 100644 index 0000000..64bd4ed --- /dev/null +++ b/.claude/skills/prd-v08-drift-baseline-compare/SKILL.md @@ -0,0 +1,213 @@ +--- +name: prd-v08-drift-baseline-compare +description: > + Establish baseline → snapshot → compare → history monitoring for any KPI, config, or + metric that can drift during PRD v0.8 Deployment & Ops. Triggers on requests to monitor + drift, baseline a value for later comparison, or when user asks "how do we track if X + changes?", "baseline this", "config drift", "performance regression", "metric drift", + "compare to last week", "is this getting worse?". Outputs MON-DRIFT-* entries with + baseline + comparison rules. +context: fork +allowed-tools: + - Read + - Write + - Edit + - Glob + - Grep + - Bash + +execution_modes: + default: standard + supports: [quick, standard, deep] +--- + +# Drift: Baseline / Compare / History + +Position in workflow: v0.8 Monitoring Setup → **v0.8 Drift: Baseline / Compare / History** → v0.8 Runbook Creation + +## Execution Mode + +Default is **standard**. See [`.claude/rules/08-skill-execution-modes.md`](../../rules/08-skill-execution-modes.md) for selection logic. + +| Mode | What this skill produces | +|------|--------------------------| +| **quick** | One metric / config / dataset baselined; weekly compare schedule; simple threshold alert | +| **standard** | 3–5 things monitored; baseline + tiered thresholds (warn / critical); compare cadence; history retention | +| **deep** | Full portfolio; multi-dimensional comparison (per segment, per environment); regression-cause matrix; auto-baselining after intentional change | + +## What This Does + +Generalizes a pattern AgriciDaniel's `claude-seo` skill encodes for SEO drift — **baseline → snapshot → compare → history** — into a reusable monitoring shape that works for any metric, config, or dataset that can change over time and needs to be watched. + +This is **drift monitoring**, distinct from alerting on absolute thresholds. Alerting answers "is X over the line right now?" Drift monitoring answers "is X different from last week's normal?" — which catches slow regressions that absolute thresholds miss. + +Examples of things worth drift-monitoring: +- **KPI**: activation rate week-over-week +- **AI search position**: ChatGPT/Perplexity ranking for target queries +- **Config**: feature-flag rollout percentages +- **Performance**: p95 latency by endpoint +- **Cost**: per-user infra cost +- **Marketing**: per-channel CAC trend +- **Content**: changelog post engagement +- **Third-party**: vendor pricing pages (price hikes), competitor feature pages (parity loss) + +## How It Works + +1. **Pick what to monitor** — One thing per MON-DRIFT- entry. Must be: + - Quantifiable (number, percentage, list, configuration value) + - Snapshotable (captureable at a point in time, ideally automatically) + - Causally interpretable (when it changes, you know enough to investigate) +2. **Capture the baseline** — Take a snapshot. Date it. Store in version control or a known location (`status/baselines/`, `monitoring/snapshots/`, etc.). +3. **Define drift thresholds**: + - **Warn**: meaningful change (e.g., 10% drift in a KPI; any change in a config value) + - **Critical**: serious change (e.g., 25% KPI drop; breaking config change) + - **Recalibrate**: intentional change that should refresh the baseline (e.g., after a feature rollout, the baseline is wrong; refresh it) +4. **Set compare cadence** — How often does this get re-snapshotted? + - Hot (hourly/daily): production KPIs, AI search positions during a launch + - Warm (weekly): standard product KPIs, content engagement + - Cool (monthly): vendor pricing, competitor feature parity, infra cost +5. **Build the compare procedure** — A script or runbook that: + - Takes a new snapshot + - Diffs against baseline + - Computes drift % per dimension + - Emits warn/critical signals at thresholds + - Appends to history log +6. **Plan auto-baselining after intentional change** [standard+] — When the team makes a deliberate change (ships a feature that should improve activation), the old baseline becomes wrong. Define what triggers a baseline refresh and who approves it. + +## Example + +Monitoring AI search position for the target query "best CRO tool for SaaS founders" across 3 surfaces. (Generalized from AEO Audit re-test cadence.) + +**Baseline** (2026-04-01): +``` +ChatGPT: not mentioned (rank: --) +Perplexity: rank 4 of 5, miscategorized as "analytics" +AI Overviews: not mentioned +Sources cited: [competitor1.com, competitor2.com, reddit.com/r/SaaS] +``` + +**Thresholds**: +- Warn: rank changes by ≥1, sources list changes, miscategorization persists +- Critical: dropped from any surface where previously mentioned + +**Compare cadence**: weekly during launch month, monthly after. + +**Re-snapshot** (2026-04-15): +``` +ChatGPT: rank 3 of 5 (NEW) ← improved +Perplexity: rank 3 of 5, category corrected (NEW) ← improved +AI Overviews: rank 5 of 7 (NEW) ← improved +Sources cited: [+ ourdomain.com (NEW), ...] +``` + +**Compare output**: 3 surfaces improved. Likely cause: alternatives-pages campaign + new CRO-anchored blog post indexed. + +**History append**: 2026-04-01 → 2026-04-15 row added to history log. + +**Action**: No alert; positive drift. Baseline can stay (next compare in 2 weeks). If the trend reverses, the baseline catches it. + +## What You Get Back + +- **MON-DRIFT-\* entries** (one per monitored thing) — Baseline snapshot, thresholds, cadence, compare procedure, history pointer +- **History logs** in `status/drift-history/.jsonl` (or similar) — Append-only record of compare results +- **Compare scripts** (`scripts/drift/.sh` or equivalent) when automatable + +## When to Use It + +| Trigger | Mode | +|---------|------| +| Post-launch — need ongoing watch on KPIs | standard | +| AEO Audit results to maintain | standard | +| Competitor feature parity tracking | standard | +| Vendor / third-party pricing watch | quick | +| Performance regression hunting | deep | +| Infrastructure cost trend | quick | + +Do not use for things that are already covered by **threshold-based alerting** (RED/USE metrics, MON-* alerts). Drift is for trends; alerting is for absolutes. + +## Consumes + +- **MON-\* monitoring infrastructure** (from v0.8 Monitoring Setup) — Data sources for KPI/performance drift; existing dashboards +- **KPI-\* metric definitions** (from v0.3 + v0.9) — What's worth watching +- **CFD-\* competitor research** (from v0.2 + ongoing) — For competitor-parity drift +- **GTM-AEO-\* Coverage Matrix** (from v0.9 AEO Audit) — For AI search position drift +- **BR-PRICING-\*** (from v0.3 + v0.9 Offer) — For pricing drift on our side; vendor-pricing drift watches their side +- **DEP-\* release entries** — Intentional changes that may trigger baseline refresh + +## Produces + +- **MON-DRIFT-\* entries** with `Type=Drift-Baseline` — One per monitored thing +- **History logs** in `status/drift-history/` — Append-only diff history +- **Compare scripts** in `scripts/drift/` (when automatable) +- **Baseline-refresh approvals** — Recorded when an intentional change resets a baseline + +## Output Template + +``` +MON-DRIFT-XXX: Baseline — [What is being monitored] +Type: Drift-Baseline +Category: [KPI | AI-Search | Config | Performance | Cost | Vendor | Competitor] +Owner: [Person / role] +Status: Active + +Subject: [Specific thing — e.g., "ChatGPT rank for query 'best CRO tool for SaaS'"] + +Baseline (YYYY-MM-DD): + [Snapshot — values, list, config dump, etc.] + +Thresholds: + Warn: [Condition — e.g., "rank change ≥1 OR sources list changes"] + Critical: [Condition — e.g., "dropped from any surface previously mentioned"] + Recalibrate-trigger: [What intentional change resets the baseline] + +Compare cadence: [Hourly | Daily | Weekly | Monthly | Triggered] +Compare procedure: [Script path OR manual runbook reference] + +History: status/drift-history/.jsonl + +Re-snapshot history: + - YYYY-MM-DD: [summary of last compare result] + - YYYY-MM-DD: ... + +Linked IDs: MON-XXX (data source), KPI-YYY or CFD-ZZZ or GTM-AEO-AAA (subject) +``` + +## Anti-Patterns + +| Pattern | Signal | Fix | +|---------|--------|-----| +| **Stale baseline** | Comparing today's value against a 12-month-old baseline that no longer reflects "normal" | Add recalibrate-trigger conditions; refresh after intentional changes | +| **Drift alerting on noise** | Critical alert fires every week for 2% movement | Threshold is too tight; widen warn, tighten critical | +| **No history log** | Snapshot, compare, alert, forget | Append-only history is the whole point; without it, you can't see trends | +| **Monitoring everything** | 50 MON-DRIFT-* entries, nobody reads any | Pick the 3–5 things that matter; archive the rest | +| **No causal interpretation** | "Drift detected" with no investigation path | Each drift signal should map to candidate causes (recent release, competitor move, AI surface change) | +| **Drift instead of alerting** | Using drift for things that need absolute thresholds | Drift = trends; absolutes (latency > 500ms) = alerting | + +## Quality Gates + +Before activating drift monitoring: + +- [ ] Subject is quantifiable and snapshotable +- [ ] Baseline captured with explicit date +- [ ] Warn and critical thresholds defined +- [ ] Compare cadence committed +- [ ] Compare procedure (script or runbook) exists +- [ ] History log path defined and writable +- [ ] Recalibrate-trigger documented (when does baseline get refreshed?) +- [ ] Owner assigned + +## Downstream Connections + +| Consumer | What it uses | Example | +|----------|--------------|---------| +| **Runbook Creation (RUN-)** | Drift criticals trigger investigation runbooks | MON-DRIFT-AEO critical → RUN-investigate-aeo-loss | +| **Launch Metrics** | Drift on launch KPIs informs go/no-go decisions | KPI-activation drift ≥10% → re-look at GTM | +| **Feedback Loop Setup** | Drift in customer-facing metrics drives CFD- investigation | Activation drift down → CFD- interview cohort | +| **v0.9 AEO Audit (re-run)** | Drift in AI search positions triggers re-audit | AEO drift → re-run aeo-audit | +| **v1.0 Continuous Discovery** | Drift patterns inform discovery questions | "Why is X drifting?" → Teresa Torres discovery | + +## Detailed References + +- AgriciDaniel's `seo-drift` skill — original baseline/compare/history pattern for SEO +- Site Reliability Engineering (Google) — SLO-burn-rate alerting (related but different) +- (No bundled `references/` — pattern is reusable; the *content* lives in each MON-DRIFT- entry) diff --git a/.claude/skills/prd-v08-marketing-ops-handoff/SKILL.md b/.claude/skills/prd-v08-marketing-ops-handoff/SKILL.md new file mode 100644 index 0000000..7697f3a --- /dev/null +++ b/.claude/skills/prd-v08-marketing-ops-handoff/SKILL.md @@ -0,0 +1,219 @@ +--- +name: prd-v08-marketing-ops-handoff +description: > + Define lifecycle stages and marketing → sales / CSM handoff rules for leads captured by GTM + channels during PRD v0.8 Deployment & Ops. Triggers on requests to set up lead lifecycle, + define MQL/SQL criteria, build handoff process, or when user asks "what's an MQL?", + "marketing to sales handoff", "lead lifecycle", "lead routing", "RevOps", "MOPS", "marketing + operations". Outputs BR-MOPS-* lifecycle rules and GTM-MOPS-* handoff flow entries. +context: fork +allowed-tools: + - Read + - Write + - Edit + - Glob + - Grep + +execution_modes: + default: standard + supports: [quick, standard, deep] +--- + +# Marketing-Ops Handoff (Lead Lifecycle + Sales Routing) + +Position in workflow: v0.8 Monitoring Setup → **v0.8 Marketing-Ops Handoff** → v0.9 Launch Channels (ORB), v0.9 Cold Outreach + +## Execution Mode + +Default is **standard**. See [`.claude/rules/08-skill-execution-modes.md`](../../rules/08-skill-execution-modes.md) for selection logic. + +| Mode | What this skill produces | +|------|--------------------------| +| **quick** | 3-stage lifecycle (Anonymous → Lead → Customer); single handoff rule; SLA per stage | +| **standard** | Full 5-stage lifecycle (Anonymous → MQL → SQL → Opportunity → Customer); entry/exit criteria; handoff payload spec; SLAs | +| **deep** | Full lifecycle + per-segment routing (by ICP / region / size); scoring model; rejection-loop rules; SLA monitoring + escalation | + +## What This Does + +Defines the **lifecycle stages** a lead passes through from first touch to customer (or churn), plus the **handoff rules** at each transition. Without this, marketing-captured leads get dropped, double-worked, or never followed up. With this, you have an auditable definition of who owns what at each moment. + +This skill applies primarily to B2B and prosumer products with a human-touch sales motion (founder-led sales, BDR/SDR teams, customer-success-led expansion). Pure self-serve products use a simpler version: lifecycle = Anonymous → Trial → Paid, with no human handoff. + +## How It Works + +1. **Pick the lifecycle shape** — Match the product: + - **Self-serve**: Anonymous → Signup → Activated → Paid → Expanded + - **Sales-assisted**: Anonymous → MQL → SQL → Opportunity → Customer + - **Hybrid (PLG + Sales)**: Anonymous → Signup → Activated → Paid → SQL → Opportunity → Expansion +2. **Define entry criteria per stage** — What event/behavior moves a lead into this stage? Examples: + - MQL: filled out a high-intent form, downloaded gated content, hit usage threshold + - SQL: explicit "talk to sales" or scoring threshold reached + - Opportunity: discovery call held, budget + authority confirmed +3. **Define exit criteria per stage** — Two paths out: progress (to next stage) and disqualify (back to nurture or out). Disqualification rules matter as much as progression. +4. **Map ownership** — Who owns the lead at each stage: + - Anonymous: marketing automation + - MQL: BDR/SDR + - SQL: AE / founder + - Opportunity: AE / founder + - Customer: CS / founder +5. **Define handoff payload** — When a lead moves between owners, what context goes with them? At minimum: + - Source (which GTM-* channel produced this lead) + - Touchpoint history (what they've engaged with) + - Best-fit signals (firmographic match, behavioral fit) + - Disqualifiers (anything that ruled out an earlier stage) + - Open questions (what the next owner should clarify) +6. **Set SLAs per stage** — How fast must the new owner respond after handoff? MQL → BDR typically <1 business hour for high-signal, <1 business day for low-signal. SQL → AE typically <30 minutes. +7. **Plan rejection routing** — When SQL → AE handoff is rejected ("not a fit"), where does the lead go? Back to nurture, disqualified, requeued? Without this rule, leads die in limbo. + +## Example + +B2B SaaS, $200/month entry price, sales-assisted motion. + +| Stage | Entry criteria | Exit criteria | Owner | SLA | +|-------|----------------|---------------|-------|-----| +| Anonymous | Any first touch | Filled form OR signed up | Marketing | n/a | +| MQL | Filled high-intent form (demo request, pricing page) | BDR qualifies in OR disqualifies | BDR | 1 business hour | +| SQL | BDR confirms fit + intent | AE accepts OR rejects | BDR → AE | 30 min | +| Opportunity | AE held discovery, budget + authority confirmed | Closed-won OR closed-lost | AE | 24 hr per touch | +| Customer | Closed-won contract signed | Churn OR expand | CS | Onboarding kickoff <1 business day | + +Handoff payload at MQL → SQL (BDR → AE): +- Source: GTM-002 (Product Hunt) + retargeting +- Touchpoints: 3 blog posts, demo video, pricing page (3×) +- Best-fit signals: 50-person SaaS (matches PER-001), VP Eng signed up +- Disqualifiers: none +- Open questions: confirm budget owner; confirm timeline + +Rejection routing at SQL → AE rejection ("too small"): lead returns to MQL queue with "small-team" tag; BDR can re-engage in 90 days if size signal changes. + +## What You Get Back + +- **BR-MOPS-\* lifecycle rule entries** — One per stage with entry/exit/owner/SLA +- **GTM-MOPS-\* handoff flow entries** — One per transition (MQL→SQL, SQL→OPP, etc.) with payload spec +- **Rejection-routing rules** — Disqualifier-aware routing back to nurture +- **SLA monitoring plan** — Hooks into MON-DRIFT-* for SLA drift watching + +## When to Use It + +| Trigger | Mode | +|---------|------| +| B2B / sales-assisted product, pre-launch | standard | +| Hybrid PLG + Sales motion | deep | +| Pure self-serve consumer product | **skip** — overkill | +| Adding human sales to existing self-serve | standard | +| Sales velocity issues (leads dying in queue) | deep (rebuild with SLAs) | +| Pre-Series A audit (investor wants to see process) | deep | + +## Consumes + +- **PER-\* best-fit characteristics** (sharpened by v0.9 Positioning when available) — Defines what fit-signal scoring looks like +- **GTM-\* channel mix** (from v0.9 Launch Channels ORB, when available) — Lead sources feed into Anonymous stage +- **GTM-\* offer card** (from v0.9 Offer Construction) — Determines what "qualified" means (price tier sets bar) +- **BR-PRICING-\*** (from v0.3 + v0.9) — Sets stage thresholds (above $X/year → SQL; below → self-serve) +- **KPI-\* baseline targets** — Stage conversion targets feed into KPI- entries + +> When this skill runs before v0.9, channel and offer references use placeholders that get reconciled when v0.9 finalizes. + +## Produces + +- **BR-MOPS-\* entries** (lifecycle stage rules) in `SoT/SoT.BUSINESS_RULES.md` +- **GTM-MOPS-\* entries** (handoff flow specs) — One per stage transition +- **CFD-\* gaps surfaced** — When stage criteria can't be cleanly defined, log as research gap + +## Output Template + +``` +BR-MOPS-XXX: Lifecycle Stage — [Stage name] +Type: Lifecycle-Stage +Order: [#] +Status: Active + +Stage: [Anonymous | Signup | Activated | MQL | SQL | Opportunity | Customer | Expansion] + +Entry criteria: + - [Criterion 1 — e.g., "Filled out demo request form"] + - [Criterion 2 — e.g., "Reached usage threshold X"] + +Exit criteria (progression): + - To [next stage]: [Criterion] + +Exit criteria (disqualification): + - [Criterion that routes back to earlier stage or out] + +Owner: [Marketing automation | BDR/SDR | AE | CS | Founder] + +SLA: + Response time after entering this stage: [duration] + Escalation: [What happens if SLA missed] + +Linked IDs: PER-XXX (fit signals), GTM-YYY (source channels), BR-PRICING-ZZZ (tier threshold), KPI-AAA (conversion rate) +``` + +``` +GTM-MOPS-XXX: Handoff — [Stage A] → [Stage B] +Type: Handoff +Status: Active + +From: [Stage A] (owner: ...) +To: [Stage B] (owner: ...) + +Trigger: [Specific event — e.g., "BDR marks lead as Qualified in CRM"] + +Payload (what context transfers): + - Source: [GTM-* channel] + - Touchpoint history: [What they engaged with] + - Best-fit signals: [Firmographic + behavioral match] + - Disqualifiers: [Anything that ruled out earlier stages] + - Open questions: [What new owner should clarify] + +Rejection rule: + Condition: [When does the new owner reject this handoff?] + Routing: [Where does the rejected lead go? Nurture / disqualified / requeue] + Re-engagement: [Conditions under which this lead can return] + +SLA: [Response time required from new owner] + +Linked IDs: BR-MOPS-AAA (Stage A rule), BR-MOPS-BBB (Stage B rule) +``` + +## Anti-Patterns + +| Pattern | Signal | Fix | +|---------|--------|-----| +| **MQL = "anyone who filled a form"** | High-volume MQLs with 1% SQL conversion | Tighten MQL entry criteria; add fit-signal scoring | +| **No rejection routing** | Leads die when SQL → AE rejects | Define where rejected leads go (nurture, disqualified, requeue) | +| **SLA without escalation** | "Respond in 1 hour" with no consequence if missed | SLA must have an escalation path | +| **Handoff without payload** | New owner asks "who is this?" | Mandatory payload fields at every handoff | +| **Stages without owners** | "We'll figure out who handles SQLs later" | One owner per stage; named role minimum | +| **Lifecycle for self-serve** | $20/month consumer product with MQL/SQL/OPP | Use Signup → Activated → Paid; no human handoff | +| **No SLA monitoring** | SLAs exist on paper, missed in practice | Drift-monitor SLA via MON-DRIFT- | + +## Quality Gates + +Before activating handoff: + +- [ ] Lifecycle shape matches product motion (self-serve / sales-assisted / hybrid) +- [ ] Every stage has entry, exit-progression, and exit-disqualification criteria +- [ ] Every stage has a named owner (role minimum) +- [ ] Every stage has an SLA with escalation path +- [ ] Every transition has a handoff payload spec +- [ ] Rejection routing defined for every owner-changing handoff +- [ ] SLA drift monitoring set up via MON-DRIFT- + +## Downstream Connections + +| Consumer | What it uses | Example | +|----------|--------------|---------| +| **Launch Channels (ORB)** | Each channel's leads enter the lifecycle at Anonymous | GTM-002 (Product Hunt) → Anonymous → MQL routing | +| **Cold Outreach (Tiered)** | Tier 1/2/3 sequences map to lifecycle stages | Tier 1 = SQL-tier ABM; Tier 3 = MQL nurture | +| **Launch Metrics** | Stage conversion rates become KPI- entries | KPI-MQL-to-SQL-conversion | +| **Feedback Loop Setup** | Rejected leads' "why we passed" reasons feed CFD- | Pattern: "too small" rejections → CFD- pricing signal | +| **Drift Monitoring** | SLA drift catches process decay | MON-DRIFT-MQL-response-SLA | + +## Detailed References + +- alirezarezvani's `marketing-ops` and `revenue-operations` skills (claude-skills) +- *Predictable Revenue* (Aaron Ross) — sales handoff structure +- *From Impossible to Inevitable* (Aaron Ross + Jason Lemkin) — stage discipline +- SiriusDecisions lead-lifecycle framework (the canonical B2B reference) +- (No bundled `references/` — lifecycle shapes vary; this skill encodes the discipline, not a specific shape) diff --git a/.claude/skills/prd-v08-monitoring-setup/SKILL.md b/.claude/skills/prd-v08-monitoring-setup/SKILL.md index 272395d..028e9e6 100644 --- a/.claude/skills/prd-v08-monitoring-setup/SKILL.md +++ b/.claude/skills/prd-v08-monitoring-setup/SKILL.md @@ -13,12 +13,26 @@ allowed-tools: - Glob - Grep - Bash + +execution_modes: + default: standard + supports: [quick, standard, deep] --- # Monitoring Setup Position in workflow: v0.8 Runbook Creation → **v0.8 Monitoring Setup** → v0.9 GTM Strategy +## Execution Mode + +Default is **standard**. See [`.claude/rules/08-skill-execution-modes.md`](../../rules/08-skill-execution-modes.md) for selection logic. + +| Mode | What this skill produces | +|------|--------------------------| +| **quick** | RED metrics on critical path only; 3–5 alerts linked to RUN-; single overview dashboard | +| **standard** | RED + USE coverage; SLOs for tier-1 services; full alert routing to RUN-; dashboards by audience | +| **deep** | Layered coverage (RED + USE + business + UX); multi-tier SLOs with error budgets; baseline calibration from staging; escalation routing | + ## Consumes This skill requires prior work from v0.8 Runbook Creation and earlier stages: diff --git a/.claude/skills/prd-v08-release-planning/SKILL.md b/.claude/skills/prd-v08-release-planning/SKILL.md index 3e61f8e..292f914 100644 --- a/.claude/skills/prd-v08-release-planning/SKILL.md +++ b/.claude/skills/prd-v08-release-planning/SKILL.md @@ -13,12 +13,26 @@ allowed-tools: - Glob - Grep - Bash + +execution_modes: + default: standard + supports: [quick, standard, deep] --- # Release Planning Position in workflow: v0.7 Implementation Loop → **v0.8 Release Planning** → v0.8 Runbook Creation +## Execution Mode + +Default is **standard**. See [`.claude/rules/08-skill-execution-modes.md`](../../rules/08-skill-execution-modes.md) for selection logic. + +| Mode | What this skill produces | +|------|--------------------------| +| **quick** | Staging→prod only; 3–5 release criteria; one rollback trigger | +| **standard** | Dev/staging/preview/prod environments; full criteria checklist; multiple rollback triggers; post-deploy validation | +| **deep** | Full environments + IaC review + canary/blue-green strategy + risk-weighted criteria + post-mortem hooks | + ## Consumes This skill requires prior work from v0.7 Implementation Loop and v0.6-v0.9: diff --git a/.claude/skills/prd-v08-runbook-creation/SKILL.md b/.claude/skills/prd-v08-runbook-creation/SKILL.md index 133b412..f8c3635 100644 --- a/.claude/skills/prd-v08-runbook-creation/SKILL.md +++ b/.claude/skills/prd-v08-runbook-creation/SKILL.md @@ -13,12 +13,26 @@ allowed-tools: - Glob - Grep - Bash + +execution_modes: + default: standard + supports: [quick, standard, deep] --- # Runbook Creation Position in workflow: v0.8 Release Planning → **v0.8 Runbook Creation** → v0.8 Monitoring Setup +## Execution Mode + +Default is **standard**. See [`.claude/rules/08-skill-execution-modes.md`](../../rules/08-skill-execution-modes.md) for selection logic. + +| Mode | What this skill produces | +|------|--------------------------| +| **quick** | 2–3 runbooks covering the top RISK-/MON- pairs | +| **standard** | Incident + deployment + maintenance runbooks linked to MON- and DEP-, with escalation paths | +| **deep** | Full matrix + drill schedule + recovery scenarios + tabletop exercise outputs | + ## Consumes This skill requires prior work from v0.8 Release Planning and earlier stages: diff --git a/.claude/skills/prd-v09-aeo-audit/SKILL.md b/.claude/skills/prd-v09-aeo-audit/SKILL.md new file mode 100644 index 0000000..dcae51b --- /dev/null +++ b/.claude/skills/prd-v09-aeo-audit/SKILL.md @@ -0,0 +1,203 @@ +--- +name: prd-v09-aeo-audit +description: > + Audit how AI search engines (ChatGPT, Perplexity, Google AI Overviews, Claude) describe and + recommend your product, then propose fixes. Triggers on requests to audit AI search visibility, + improve AEO/GEO, check ChatGPT/Perplexity coverage, or when user asks "do we show up in AI + search?", "AEO audit", "generative engine optimization", "AI discoverability", "how does + ChatGPT describe us?", "Perplexity ranking". Outputs GTM-AEO-* entries and a Coverage Matrix. +context: fork +allowed-tools: + - Read + - Write + - Edit + - Glob + - Grep + - WebSearch + - WebFetch + +execution_modes: + default: standard + supports: [quick, standard, deep] +--- + +# AEO Audit (AI Search Discoverability) + +Position in workflow: v0.9 Launch Channels (ORB) → **v0.9 AEO Audit** → v0.9 Alternatives Pages, Launch Metrics + +## Execution Mode + +Default is **standard**. See [`.claude/rules/08-skill-execution-modes.md`](../../rules/08-skill-execution-modes.md) for selection logic. + +| Mode | What this skill produces | +|------|--------------------------| +| **quick** | 5 target queries × 2 AI surfaces (ChatGPT + Perplexity); top 3 gaps with fixes | +| **standard** | 10–15 queries × 3–4 AI surfaces; full Coverage Matrix; ranked fix backlog | +| **deep** | 20–30 queries × all major surfaces; per-surface citation analysis; structured-data audit; before/after re-test plan | + +## What This Does + +Tests whether AI search engines surface, recommend, and accurately describe the product when a target customer asks a relevant question. AEO (answer-engine optimization) and GEO (generative-engine optimization) are the post-SEO distribution layer — when ChatGPT/Perplexity/AI Overviews answer a buyer's question, the product either is in the answer or isn't. + +This is a **diagnostic** skill. It produces a gap map and a ranked fix backlog. The fixes are executed by [prd-v09-alternatives-pages](../prd-v09-alternatives-pages/SKILL.md), content updates, and structured-data work — not by this skill. + +## How It Works + +1. **Build a query set** — From the Positioning best-fit characteristics (jobs to be done, triggers, search intent), generate target queries an actual best-fit buyer would type. Mix high-intent ("best X for Y"), comparison ("X vs Y"), and category ("what is X"). +2. **Run each query against AI surfaces** — At minimum: ChatGPT (free tier — what the median buyer sees), Perplexity, Google AI Overviews. Deep mode adds Claude, Brave Search, Kagi. Save raw responses with timestamps. +3. **Score each result** on five dimensions: + - **Mentioned?** (yes / no) + - **Position** in recommendation list (1st, 2nd, not listed) + - **Description accuracy** (matches positioning vs. miscategorized vs. wrong) + - **Competitive frame** (which alternatives are listed alongside) + - **Citation sources** (which URLs/domains the AI cited to build the answer) +4. **Identify the gap pattern**: + - **Absence gaps** — product not mentioned at all + - **Category gaps** — mentioned in the wrong category (positioning failure) + - **Citation gaps** — answer is built from sources the product doesn't appear in (need to be on those sources) + - **Comparison gaps** — competitor wins the comparison query because comparison content doesn't exist on your side +5. **Propose ranked fixes** — Each fix maps to a specific gap type: + - Absence → content on best-fit query intent, JSON-LD structured data, citation-source targets + - Category → positioning content (handoff to Positioning skill) + - Citation → outreach/contribution to high-citation sources (G2, Reddit, blog posts on cited domains) + - Comparison → handoff to [prd-v09-alternatives-pages](../prd-v09-alternatives-pages/SKILL.md) + +## Example + +A best-fit buyer types **"best CRO tool for early-stage SaaS founders"** into ChatGPT. Result: + +| Surface | Mentioned? | Position | Accuracy | Citations | +|---------|-----------|----------|----------|-----------| +| ChatGPT | No | n/a | n/a | 5 sources, none ours | +| Perplexity | Yes | 4th of 5 | "an analytics tool" (wrong category) | Sources include our pricing page only | +| AI Overviews | No | n/a | n/a | G2, Reddit r/SaaS, two competitor blog posts | + +Gaps identified: +- **Absence** in ChatGPT — no high-intent landing for this query +- **Category miscoding** in Perplexity — we're being summarized as "analytics", not "CRO" +- **Citation gap** — we don't appear in G2 or r/SaaS threads about CRO + +Ranked fixes: +1. Publish CRO-anchored guide ([prd-v09-alternatives-pages](../prd-v09-alternatives-pages/SKILL.md) handles competitor variants) +2. Rewrite product schema (JSON-LD) with the Dunford category claim +3. Outreach to G2 (claim profile, request reviews) and post a substantive thread in r/SaaS + +## What You Get Back + +- **GTM-AEO-\* entries** — one per query × surface gap, with the proposed fix and ranking +- **Coverage Matrix** (single GTM-* with Type=Audit) — full query × surface × status table +- **Fix backlog** — ranked list with handoff target skills + +## When to Use It + +| Trigger | Mode | +|---------|------| +| Pre-launch sanity check (before paid channels activate) | quick | +| Standard launch wave audit | standard | +| Quarterly retention/competitive intelligence review | deep | +| After major positioning change (re-test) | standard | +| When organic signups stall and paid CAC rises | deep | + +Do **not** run before Positioning is complete — without a sharpened category claim, every "miscategorized" result is unfixable. + +## Consumes + +- **GTM-\* positioning statement + category claim** (from v0.9 Positioning) — Defines what "accurate description" looks like; without this, scoring is opinion +- **CFD-\* competitive alternatives** (from v0.2) — Source for comparison-intent queries +- **PER-\* best-fit characteristics** (sharpened by Positioning) — Source for query intent +- **GTM-\* channel mix** (from v0.9 Launch Channels) — AEO is a channel; surfaces tested should match best-fit channel use + +## Produces + +- **GTM-AEO-\* entries** with `Type=AEO-Recommendation`, one per gap-fix pair +- **GTM-\* with `Type=Audit`** — the Coverage Matrix +- **Fix backlog** — handoff list referencing [prd-v09-alternatives-pages](../prd-v09-alternatives-pages/SKILL.md), Positioning re-run, content production tickets + +Confidence guidance (P4): AEO scoring is **3/5 minimum** because it's based on observed AI responses, not opinion. Quick mode may produce 2/5 outputs (limited sampling) and must tag them. + +## Output Template + +``` +GTM-AEO-XXX: [Gap Title] +Type: AEO-Recommendation +Status: Open +Priority: [High | Medium | Low] +Owner: [Person / role] + +Query: "[the exact query]" +Surface: [ChatGPT | Perplexity | AI Overviews | Claude | Brave | Kagi] +Date observed: [YYYY-MM-DD] + +Result summary: + Mentioned? [yes | no] + Position: [#] + Accuracy: [matches positioning | miscategorized | wrong] + Competitive frame: [list of alternatives shown] + Citation sources: [URLs/domains used] + +Gap type: [Absence | Category | Citation | Comparison] + +Proposed fix: + - [Specific action 1] + - [Specific action 2] + +Handoff: [Target skill or owner — e.g., prd-v09-alternatives-pages, content team] + +Re-test: [Date to verify fix] + +Linked IDs: GTM-YYY (positioning), CFD-ZZZ (competitor), PER-AAA (best-fit) +``` + +``` +GTM-XXX: AEO Coverage Matrix +Type: Audit +Status: Snapshot — [YYYY-MM-DD] + +| Query | ChatGPT | Perplexity | AI Overviews | Gap Type | +|-------|---------|------------|--------------|----------| +| ... | ✓ #2 | ✗ | ✗ | Absence (2 surfaces) | +| ... | ✗ | ✓ #4 (miscat) | ✗ | Category + Absence | + +Total queries: X +Coverage rate: Y% (mentioned in any surface) +Accurate-description rate: Z% (mentioned AND correctly described) + +Linked IDs: All GTM-AEO-* entries above +``` + +## Anti-Patterns + +| Pattern | Signal | Fix | +|---------|--------|-----| +| **Vanity queries** | Auditing "best [exact product name]" — you'll always win that one | Use buyer-intent queries the buyer would actually type | +| **No timestamp / no re-test** | Results saved but never re-tested | AI surfaces change; re-test every fix within 2 weeks | +| **Surface monoculture** | Only testing ChatGPT | Each surface has different model/data; minimum 3 surfaces | +| **Fix all gaps equally** | 20 gaps, parallel work, no ranking | Rank by query buyer-intent strength × surface adoption | +| **Treating absence as failure** | "We're not in any results — game over" | Absence is often the easiest fix (publish high-intent content); category miscoding is the harder one | +| **Skipping citation analysis** | Knowing you're absent but not why | Citation sources reveal *where* you need to appear | + +## Quality Gates + +Before proceeding to fix execution: + +- [ ] At least 5 queries tested (quick) / 10–15 (standard) / 20+ (deep) +- [ ] At least 3 AI surfaces sampled (standard+) +- [ ] Every gap has a typed classification (Absence / Category / Citation / Comparison) +- [ ] Every gap has a proposed fix with a handoff target +- [ ] Coverage Matrix exists and is dated +- [ ] Fix backlog is ranked + +## Downstream Connections + +| Consumer | What it uses | Example | +|----------|--------------|---------| +| **Alternatives Pages** | Comparison-gap fixes become alternatives-page targets | "X vs us" comparison gap → SCR-ALT- page | +| **Positioning (re-run)** | Category-coding gaps signal positioning weakness | Recurring miscategorization → re-run prd-v09-positioning-dunford | +| **Launch Metrics** | Coverage Matrix becomes a KPI baseline | KPI-AEO-coverage% | +| **v1.0 Continuous Discovery** | Recurring gap patterns inform discovery questions | "Users keep finding competitor X — why?" | + +## Detailed References + +- Sanity team's `seo-aeo-best-practices` skill (VoltAgent index) +- Princeton AI Search benchmark studies +- (No bundled `references/` — AI surfaces change too quickly to canonize) diff --git a/.claude/skills/prd-v09-alternatives-pages/SKILL.md b/.claude/skills/prd-v09-alternatives-pages/SKILL.md new file mode 100644 index 0000000..7ea8d24 --- /dev/null +++ b/.claude/skills/prd-v09-alternatives-pages/SKILL.md @@ -0,0 +1,191 @@ +--- +name: prd-v09-alternatives-pages +description: > + Generate "X vs Y" and "Alternative to X" SEO/CRO pages targeting competitive search intent + during PRD v0.9 Go-to-Market. Triggers on requests to build comparison pages, target + competitive search traffic, or when user asks "build alternatives pages", "X vs Y page", + "competitor comparison page", "we're better than X page", "capture branded search", + "competitive SEO". Outputs SCR-ALT-* page specs and GTM-* channel entries. +context: fork +allowed-tools: + - Read + - Write + - Edit + - Glob + - Grep + - WebSearch + - WebFetch + +execution_modes: + default: standard + supports: [quick, standard, deep] +--- + +# Alternatives Pages (Competitive Comparison SEO/CRO) + +Position in workflow: v0.9 AEO Audit → **v0.9 Alternatives Pages** → v0.9 Launch Metrics + +## Execution Mode + +Default is **standard**. See [`.claude/rules/08-skill-execution-modes.md`](../../rules/08-skill-execution-modes.md) for selection logic. + +| Mode | What this skill produces | +|------|--------------------------| +| **quick** | 2 pages for the single most-searched competitor (X-vs-us + alternative-to-X) | +| **standard** | 5–10 pages covering top 3–5 competitors with both variant types; CRO copy + comparison table | +| **deep** | Full competitor portfolio (10+ competitors); plus multi-way comparison ("X vs Y vs Z"); page-level A/B test plan; SEO targeting per page | + +## What This Does + +Produces a portfolio of high-intent comparison pages — `/x-vs-us` and `/alternative-to-x` — that capture buyers actively searching for competitor names + comparison/alternative keywords. These are the highest-converting acquisition surface for B2B SaaS and many consumer products: the buyer has already passed awareness and is in active evaluation. + +The pages must be **fair, credible, and conversion-oriented** — acknowledging where the competitor wins, claiming where you win, with social proof and a clear "when to pick each" guide. Aggressive trashing fails: buyers fact-check, and one false claim loses the page. + +## How It Works + +1. **Source the competitor list** — From the AEO Audit's comparison gaps and v0.2 CFD- competitive landscape. Rank by search volume (use Ahrefs/Semrush/free volume estimators) × buyer-intent strength. +2. **For each competitor, design two pages**: + - **`/-vs-`** — Symmetric comparison. Buyer is comparing both. + - **`/alternative-to-`** — Asymmetric. Buyer is leaving competitor or shopping replacements. +3. **Apply the page template** (see Output Template) — Honest comparison table on 5–8 dimensions, "When to pick each" guidance, your unique attributes (from Dunford positioning), social proof, CTA. +4. **Anchor in positioning rules** — Each page must respect the BR-POS-* constraints. If positioning says "not for enterprise procurement," the page does not court enterprise buyers. +5. **Plan attribution** — Each page gets its own UTM source and a conversion event. Track per-page activation rate to identify dead pages. + +## Example + +Competitor: **Mixpanel** (mid-search-volume, B2B SaaS analytics). + +**Page 1: `/mixpanel-vs-us`** + +Symmetric comparison table: + +| Dimension | Mixpanel | Us | +|-----------|----------|-----| +| Setup time | 1–2 weeks (data engineering required) | 15 minutes (autoinstrument) | +| Analytics depth | Industry-leading (cohorts, retention, funnels) | Solid (cohorts, funnels — no formula language) | +| Pricing | Custom enterprise; usage-based | Flat tier; predictable | +| Best-fit team | 50+ person product orgs | 1–20 person teams | + +"**Pick Mixpanel if**: you have a data team and need advanced funnel/cohort analysis." +"**Pick us if**: you're a small team that needs analytics today, not after a 2-week setup." + +CTA: "Start free trial — full setup in under an hour" + +**Page 2: `/alternative-to-mixpanel`** + +Asymmetric, replacement-oriented. Headline: "Looking for a faster Mixpanel alternative?" Same table, plus migration guide ("export your Mixpanel events; we'll set up identical funnels in 1 hour"), plus customer story ("[Customer X] moved off Mixpanel in 2 days — here's how"). + +## What You Get Back + +- **SCR-ALT-\* page specs** — One per page. Includes URL slug, headline, comparison table content, "when to pick each" copy, social proof references, CTA. Hands off to design/dev for build. +- **GTM-\* with Type=Channel** for each page — The page treated as a channel (Owned layer), with attribution plan +- **Page priority queue** — Build order ranked by competitor search volume × conversion potential + +## When to Use It + +| Trigger | Mode | +|---------|------| +| AEO Audit identified comparison gaps | standard | +| Competitor raised prices / had a public incident (capture displaced buyers) | quick (single page, fast) | +| Quarterly competitive SEO refresh | standard | +| Launch wave needs additional Owned-channel surfaces | standard | +| Enterprise / paid-tier buyer education | deep | + +Do **not** use for products in tightly regulated categories where comparison claims have legal exposure (e.g., medical devices, financial advice) without legal review. + +## Consumes + +- **CFD-\* competitive alternatives** (from v0.2 + v0.3 Moat) — Anchor for honest comparison; CFD- entries should include competitor strengths, not just weaknesses +- **GTM-AEO-\* gaps** (from v0.9 AEO Audit) — Comparison gaps become page priorities +- **GTM-\* positioning** + **BR-POS-\*** (from v0.9 Positioning) — Defines "when to pick us" claims; pages must honor BR-POS- constraints +- **CFD-\* customer stories** (from v0.1–v0.4 + post-launch) — Social proof and migration stories +- **FEA-\* feature list** — Anchor for "what we have" claims (no vaporware) + +## Produces + +- **SCR-ALT-\* page specs** (subcategorized SCR- entries for alternatives pages, lives in `SoT/SoT.USER_JOURNEYS.md` alongside other SCR- entries) +- **GTM-\* with Type=Channel** for each page (the page-as-channel with attribution plan) +- **CFD-\* gaps surfaced** — If a competitor strength is unaddressed, log CFD- research-gap + +## Output Template + +``` +SCR-ALT-XXX: Comparison page — [Competitor] vs. Us +Type: ScreenAlternatives +Variant: [vs | alternative-to] +URL slug: /-vs- (or /alternative-to-) +Owner: [Person / role] +Status: [Draft | Review | Live] + +Headline: "[Headline]" +Subhead: "[Subhead]" + +Comparison table (5–8 dimensions, honest): + | Dimension | Competitor | Us | + | ... | ... | ... | + +"Pick competitor if": [Honest acknowledgment] +"Pick us if": [Anchored in BR-POS-* and positioning value claims] + +Social proof: + - CFD-XXX (testimonial or migration story) + - [Customer logo references] + +CTA: [Specific action; matches Offer Construction CTA where possible] + +Linked IDs: CFD-XXX (competitor), GTM-YYY (positioning), FEA-ZZZ (feature claims), BR-POS-AAA (constraints) +Linked Channel: GTM-ALT-XXX +``` + +``` +GTM-ALT-XXX: Channel — Alternatives page +Type: Channel +Layer: Owned +Status: Live + +Channel: SEO/CRO page at +Attribution: utm_source=alt-page&utm_medium=organic&utm_campaign= +KPI target: KPI-AAA (alt-page → trial signup conversion rate) + +Linked IDs: SCR-ALT-XXX (page), GTM-YYY (positioning), KPI-AAA +``` + +## Anti-Patterns + +| Pattern | Signal | Fix | +|---------|--------|-----| +| **Trash the competitor** | Page reads like a hit piece | Acknowledge where they win; credibility > short-term clicks | +| **Same page, find/replace competitor name** | 8 pages with identical structure | Each page tunes for the *specific* alternative's buyer profile | +| **Stale comparison data** | Comparison table is 18 months old | Quarterly refresh; date the page; cite version | +| **Vaporware feature claims** | Claiming features that don't ship | Every "we have" claim must trace to FEA- | +| **Ignoring BR-POS-*** | Page courts buyers positioning says aren't best-fit | Add "this might not be for you if..." section | +| **No "when to pick each"** | Pure us-favored framing | Buyers know it's biased; the "when to pick each" earns trust | +| **No social proof** | Empty assertion of superiority | Cite CFD- customer stories or migration data | + +## Quality Gates + +Before pages go live: + +- [ ] Each page traces to one CFD- competitor entry +- [ ] Each page traces to GTM- positioning + at least one BR-POS- constraint +- [ ] "Pick competitor if" section exists on every page (the credibility test) +- [ ] All feature claims trace to shipping FEA- +- [ ] Attribution plan (UTM + KPI- target) per page +- [ ] Date on page; refresh schedule documented +- [ ] (deep mode) A/B test plan documented + +## Downstream Connections + +| Consumer | What it uses | Example | +|----------|--------------|---------| +| **Launch Channels (ORB)** | Pages = Owned channels; added to mix matrix | `/x-vs-us` → GTM- Owned entry | +| **Launch Metrics** | Per-page conversion rates roll up to KPI-acquisition | KPI-ALT-conversion-rate | +| **Feedback Loop Setup** | Page bounce/scroll signals feed CFD- | Bounce on a specific section → CFD-gap | +| **AEO Audit (re-run)** | Pages should resolve comparison gaps; re-test after 4–6 weeks | Gap closure verification | +| **v1.0 Continuous Discovery** | Page winners suggest positioning sharpenings | High-converting page → positioning hypothesis | + +## Detailed References + +- jonathimer's `alternatives-pages` skill (devmarketing-skills) +- Corey Haines's `competitors` and `competitor-profiling` skills (marketingskills) +- (No bundled `references/` — competitor data lives in CFD-, not here) diff --git a/.claude/skills/prd-v09-cold-outreach-tiered/SKILL.md b/.claude/skills/prd-v09-cold-outreach-tiered/SKILL.md new file mode 100644 index 0000000..bc08c67 --- /dev/null +++ b/.claude/skills/prd-v09-cold-outreach-tiered/SKILL.md @@ -0,0 +1,208 @@ +--- +name: prd-v09-cold-outreach-tiered +description: > + Build Tier 1/2/3 cold outreach sequences differentiated by personalization depth and research + signal strength during PRD v0.9 Go-to-Market. Triggers on requests to plan cold outreach, + founder-led sales, or when user asks "cold email sequence", "outbound campaign", "founder + outreach", "LinkedIn outreach", "Tier 1 personalization", "predictable revenue", "sales + cadence", "BDR sequence". Outputs GTM-OUT-* sequence entries and lead-list references. +context: fork +allowed-tools: + - Read + - Write + - Edit + - Glob + - Grep + - WebSearch + - WebFetch + +execution_modes: + default: standard + supports: [quick, standard, deep] +--- + +# Cold Outreach (Tiered: 1:1 / 1:few / 1:many) + +Position in workflow: v0.9 Offer Construction → **v0.9 Cold Outreach (Tiered)** → v0.9 Launch Metrics + +## Execution Mode + +Default is **standard**. See [`.claude/rules/08-skill-execution-modes.md`](../../rules/08-skill-execution-modes.md) for selection logic. + +| Mode | What this skill produces | +|------|--------------------------| +| **quick** | One tier (typically Tier 2); 3-touch sequence; lead-list scoring rubric | +| **standard** | All three tiers; 3–5 touches each; lead-list scoring + tier-assignment logic; reply-handling guide | +| **deep** | All tiers + A/B subject lines per tier; channel mix (email + LinkedIn + voicemail); reply-rate baselines; objection library | + +## What This Does + +Builds three differentiated cold-outreach sequences, each calibrated to a different ratio of research-per-lead: + +- **Tier 1 (1:1, founder-led)** — Hand-researched. Highly personalized. Each touch references something specific. Volume: 10–30 contacts. +- **Tier 2 (1:few, semi-automated)** — Segment-personalized. Template with 3–5 dynamic variables per recipient. Volume: 100–500 contacts. +- **Tier 3 (1:many, automated)** — Broad-fit. Template only, minimal personalization. Volume: 1,000–10,000+ contacts. + +The tiers are **not "good/better/best"** — each has its place. Tier 3 fills the top of the funnel cheaply. Tier 2 carries the bulk. Tier 1 closes the highest-value targets that templates can never reach. + +## How It Works + +1. **Source lead lists from ICP** — Pull from the Positioning best-fit characteristics. Use enrichment tools (Apollo, Clay, Clearbit) or LinkedIn Sales Nav search anchored on firmographic + behavioral signals from PER-. +2. **Score each lead's signal strength** (1–5): + - **Trigger signal** — Recent funding, hiring, product launch, public pain (5) + - **Fit signal** — Strong firmographic/behavioral match without specific trigger (3–4) + - **Cold signal** — Broad-fit only; no specific signal (1–2) +3. **Tier assignment**: + - Signal 4–5 + opportunity size ≥ threshold → **Tier 1** + - Signal 3–4 → **Tier 2** + - Signal 1–2 → **Tier 3** (or drop if list is large enough) +4. **Build per-tier sequences** — Each tier gets its own template structure (see Output Template). Tier 1 is hand-drafted; Tier 2 is template + variables; Tier 3 is template only. +5. **End every sequence on the guarantee** — The guarantee from [prd-v09-offer-construction-hormozi](../prd-v09-offer-construction-hormozi/SKILL.md) is the reply-friction killer. Don't ask for a meeting cold; ask them to invoke the guarantee. +6. **Plan reply handling** — Define what counts as a reply (positive, ask, objection, unsubscribe), and have a response cadence for each. Tier 1 replies go to founder immediately. Tier 3 replies route through a templatized objection library. + +## Example + +B2B SaaS founder launching, ICP = Series A SaaS PMs. + +**Tier 1** (20 hand-picked targets): +- Touch 1 (Day 0, email): Reference specific recent blog post + offer specific insight on their problem +- Touch 2 (Day 4, LinkedIn): Connect with a one-line follow-up referencing the email +- Touch 3 (Day 10, email): Share a relevant case study from a similar company; mention the guarantee +- Touch 4 (Day 18, email): Soft breakup — "want me to circle back in a quarter?" + +**Tier 2** (200 mid-signal leads): +- Touch 1 (Day 0, email): Template with 3 variables ({company}, {pain point}, {peer company}). 6–10 sentences max. +- Touch 2 (Day 3, email): One-line bump +- Touch 3 (Day 7, email): Case study + guarantee mention +- Touch 4 (Day 14, email): Breakup + +**Tier 3** (2,000 broad-fit leads): +- Touch 1 (Day 0, email): Template only. 4–6 sentences. Lead with category insight, not pitch. +- Touch 2 (Day 5, email): Case study +- Touch 3 (Day 12, email): Breakup ("last note from me") + +Expected reply rates: Tier 1 = 30–50%; Tier 2 = 8–15%; Tier 3 = 1–3%. + +## What You Get Back + +- **GTM-OUT-\* entries** (one per tier sequence) — Tier metadata, per-touch templates, channel mix, timing +- **GTM-OUT-touch-\*** entries — Individual touch templates with subject line, body, channel +- **Lead-list scoring rubric** (single GTM-*) — How to assign tier +- **Reply-handling guide** — What counts as a reply; routing rules + +## When to Use It + +| Trigger | Mode | +|---------|------| +| B2B / founder-led sales motion | standard | +| Post-launch acquisition push | standard | +| Paid channels too expensive (high CAC) | standard | +| Specific ABM-style campaign against named accounts | deep, Tier 1 only | +| Mass-market consumer product with no individual-buyer relationship | **do not use** — wrong channel | + +## Consumes + +- **GTM-\* positioning** + **PER-\* best-fit characteristics** — Source for ICP and message anchoring +- **GTM-\* offer card** + **GTM-\* guarantee** (from v0.9 Offer Construction) — Sequences end on the guarantee, not a meeting ask +- **CFD-\* customer stories** (from v0.1–v0.4 + post-launch) — Case studies for touch 3 +- **BR-POS-\* constraints** — Tier targeting must honor "not for" rules +- **KPI-\* targets** (from v0.3 + v0.9 Launch Metrics) — Reply rate and meeting-booked targets per tier + +## Produces + +- **GTM-OUT-\* tier entries** — One per tier with sequence metadata +- **GTM-OUT-touch-\* entries** — Per-touch templates (subject, body, channel, timing) +- **GTM-\* lead-list scoring rubric** +- **CFD-\* gaps** — When sequences reveal objections we can't answer, log as CFD- research gaps + +## Output Template + +``` +GTM-OUT-XXX: Tier [1 | 2 | 3] Sequence +Type: Outreach +Tier: [1 | 2 | 3] +Volume: [target lead count] +Owner: [Person / role] +Status: [Planned | Active | Paused] + +Lead profile: + Signal strength: [4–5 | 3–4 | 1–2] + Source: [Apollo | LinkedIn Sales Nav | Clay | Manual] + Best-fit criteria: [Anchored in PER- characteristics] + +Sequence: + Touch 1: GTM-OUT-touch-AAA — Day 0, [channel] + Touch 2: GTM-OUT-touch-BBB — Day [N], [channel] + Touch 3: GTM-OUT-touch-CCC — Day [N], [channel] + Touch 4: GTM-OUT-touch-DDD — Day [N], [channel] + +Reply handling: + Positive: [Routing] + Ask: [Routing] + Objection: [Routing — point to objection library] + Unsubscribe: [Action] + +KPI targets: + Reply rate: [Tier 1: 30–50% | Tier 2: 8–15% | Tier 3: 1–3%] + Meeting-booked rate: [varies] + +Linked IDs: PER-XXX, GTM-YYY (positioning), GTM-ZZZ (offer), GTM-AAA (guarantee), KPI-BBB +``` + +``` +GTM-OUT-touch-XXX: Touch [N] — Tier [1|2|3] +Channel: [Email | LinkedIn | Voicemail | SMS] +Subject: "[Subject line — A/B variants for deep mode]" + +Body: + [Template body, with {variable} markers for tiers 2 and 3] + +Personalization tier: + Tier 1: Hand-drafted; each touch references something specific + Tier 2: Template + 3–5 variables — {company}, {pain_point}, {peer_company} + Tier 3: Template only + +Ends on: [Guarantee mention | Case study | Soft ask | Breakup] + +Linked IDs: GTM-OUT-XXX (parent sequence), GTM-AAA (guarantee) +``` + +## Anti-Patterns + +| Pattern | Signal | Fix | +|---------|--------|-----| +| **Same template for all tiers** | Tier 1 reply rate < 10% | Tier 1 must be hand-drafted; templates are the floor, not the ceiling | +| **Fake personalization** | "{first_name}, I love what {company} is doing" | Either personalize for real (Tier 1) or stop pretending (Tier 3) | +| **Ask for meeting cold** | "Got 15 min next week?" in touch 1 | Lead with value; ask for guarantee invocation or content engagement instead | +| **No breakup** | Sequence runs forever, hurting deliverability | Always include a final-touch breakup | +| **No tier assignment logic** | All leads in same tier | Build the scoring rubric before sending anything | +| **Outreach without offer** | Sequence runs before Offer Construction is complete | Wait — without the guarantee, the sequence ends on weak CTAs | +| **Outreach without positioning** | Generic value claims | Reply rates die; honor the Dunford positioning | + +## Quality Gates + +Before launching: + +- [ ] All three tiers defined (or quick-mode single tier with documented reason) +- [ ] Per-touch templates exist and respect BR-POS-* constraints +- [ ] Sequences end on the guarantee (or explicit reason why not) +- [ ] Reply-handling rules documented +- [ ] KPI- targets set per tier (reply rate + meeting-booked rate) +- [ ] Unsubscribe path is one-click and honored +- [ ] Spam-compliance check (CAN-SPAM, GDPR if applicable) done + +## Downstream Connections + +| Consumer | What it uses | Example | +|----------|--------------|---------| +| **Launch Channels (ORB)** | Cold outreach is a Borrowed channel; rolls into mix matrix | Tier 1 = Borrowed-time; Tier 2/3 = Borrowed-volume | +| **Launch Metrics** | Per-tier reply rates become KPI- entries | KPI-tier1-reply-rate | +| **Feedback Loop Setup** | Reply objections feed CFD- | "Why we passed" replies → CFD- pattern | +| **v1.0 Continuous Discovery** | High-engagement Tier 1 replies = founder interviews | Reply → CFD- interview with confidence ≥ 3/5 | + +## Detailed References + +- Aaron Ross, *Predictable Revenue* (2011) — Tier 2/3 outbound structure +- Aaron Ross, *From Impossible to Inevitable* (2016) — Sequencing +- BrianRWagner's `cold-outreach-sequence` skill (ai-marketing-claude-code-skills) +- (No bundled `references/` — sequences are templates, not theory) diff --git a/.claude/skills/prd-v09-feedback-loop-setup/SKILL.md b/.claude/skills/prd-v09-feedback-loop-setup/SKILL.md index 27088f7..9b43664 100644 --- a/.claude/skills/prd-v09-feedback-loop-setup/SKILL.md +++ b/.claude/skills/prd-v09-feedback-loop-setup/SKILL.md @@ -14,12 +14,26 @@ allowed-tools: - Grep - WebSearch - WebFetch + +execution_modes: + default: standard + supports: [quick, standard, deep] --- # Feedback Loop Setup Position in workflow: v0.9 Launch Metrics → **v0.9 Feedback Loop Setup** → v1.0 Market Adoption +## Execution Mode + +Default is **standard**. See [`.claude/rules/08-skill-execution-modes.md`](../../rules/08-skill-execution-modes.md) for selection logic. + +| Mode | What this skill produces | +|------|--------------------------| +| **quick** | 1–2 channels (in-app + support); basic triage workflow | +| **standard** | 3–4 channels; full processing workflow + sentiment tracking + SLAs | +| **deep** | All channels + closed-loop tracking + voice-of-customer synthesis + escalation rules | + ## Consumes This skill requires prior work from v0.9 Launch Metrics and v0.1-v0.8: diff --git a/.claude/skills/prd-v09-gtm-strategy/SKILL.md b/.claude/skills/prd-v09-gtm-strategy/SKILL.md index 4d9f520..e329dc2 100644 --- a/.claude/skills/prd-v09-gtm-strategy/SKILL.md +++ b/.claude/skills/prd-v09-gtm-strategy/SKILL.md @@ -1,10 +1,11 @@ --- name: prd-v09-gtm-strategy description: > - Define go-to-market strategy including launch plan, messaging, channels, and timing during PRD v0.9 Go-to-Market. - Triggers on requests to plan launch, define GTM strategy, or when user asks "how do we launch?", - "go-to-market", "launch plan", "marketing strategy", "messaging", "launch channels", "GTM". - Outputs GTM- entries with launch plan components. + Orchestrate go-to-market strategy by running positioning, offer construction, and channel + allocation as a sequenced workflow during PRD v0.9 Go-to-Market. Triggers on requests to + plan launch, define GTM strategy, or when user asks "how do we launch?", "go-to-market", + "launch plan", "marketing strategy", "GTM", "launch this product". Chains three + framework-grounded sub-skills (Dunford → Hormozi → ORB) and reconciles their outputs. context: fork allowed-tools: - Read @@ -12,387 +13,131 @@ allowed-tools: - Edit - Glob - Grep - - WebSearch - - WebFetch ---- - -# GTM Strategy - -Position in workflow: v0.8 Monitoring Setup → **v0.9 GTM Strategy** → v0.9 Launch Metrics - -## Consumes - -This skill requires prior work from v0.2-v0.8: - -- **PER-\* persona entries** (from v0.4 Persona Definition) — Target audience definition; messaging and channel selection must match persona behaviors and preferences -- **CFD-\* customer feedback entries** (from v0.1-v0.2 value hypotheses and competitive analysis) — Evidence-based value propositions; messaging must anchor in validated CFD- evidence, not speculation -- **BR-\* business rules and product type** (from v0.2-v0.3 Commercial Model) — Product type (Clone/Unbundle/Undercut/Slice/Innovation) determines channel strategy and positioning narrative -- **DEP-\* deployment criteria** (from v0.8 Release Planning) — Release readiness gates inform launch timing and go/no-go decision window -- **MON-\* monitoring setup** (from v0.8 Monitoring Setup) — Baseline metrics and dashboards to track during launch; MON- thresholds inform launch day response triggers - -This skill assumes v0.8 Monitoring Setup is complete and DEP- release criteria are met. - -## Produces - -This skill creates/updates: - -- **GTM-\* entries** (launch campaign specifications, type-based) — Messaging, channel strategy, launch timeline, task assignments, creative assets with explicit links to personas, evidence, and product positioning -- **Launch campaign roadmap** — Pre-launch, launch day, and post-launch phases with dependencies and milestones -- **Channel-to-persona matrix** — Validation showing each channel reaches target PER- personas and messaging matches PER- values - -All GTM- entries are **campaign specifications**, not confidence-based. They are: -- **Evidence-grounded** (messaging anchors in CFD- value hypotheses) -- **Persona-targeted** (channel selection based on PER- behaviors) -- **Executable** (every GTM- has owner, timeline, deliverable) -- **Measurable** (GTM- channels trace to KPI- metrics for launch) -- **Coordinated** (timeline shows dependencies; tasks assigned) - -Example GTM- entries: -```markdown -GTM-001: Primary Value Proposition -Type: Messaging -Owner: Product Marketing -Status: Ready - -Audience: PER-001 (Startup Founder), PER-002 (Team Lead) -Format: Value Prop -Message: "Ship faster with AI that understands your codebase. Context-aware coding assistance that reduces debugging time by 40%." -Supporting Evidence: CFD-010 (40% time savings validated in 5 user interviews), CFD-025 (competitive analysis shows context awareness as key differentiator) -Where Used: GTM-005 (Landing Page Hero), GTM-010 (Product Hunt), GTM-002 (Email Campaign) - -Linked IDs: PER-001, PER-002, CFD-010, CFD-025, KPI-101/102/103 +execution_modes: + default: standard + supports: [quick, standard, deep] --- -GTM-002: Product Hunt Launch -Type: Channel -Owner: Growth Team -Status: Planned - -Channel: Product Hunt -Audience Fit: PER-001 (Startup Founder) + PER-002 (Team Lead) — both frequent PH for tools; developer-focused community -Strategy: - - Launch on Tuesday 12:01 AM PT (optimal PH timing) - - Engage with comments first 24 hours - - Share founder story (GTM-003) - - Demo video showing AI in action -Content Plan: - - Tagline: GTM-001 (Primary Value Prop) - - Maker comment: GTM-003 (Founder Story) - - Demo video: GTM-006 (Product Demo) -Success Metric: Top 5 product of the day, 500+ upvotes, 100+ engaged comments - -Linked IDs: PER-001, PER-002, GTM-001, GTM-003, GTM-006, KPI-101 (traffic), KPI-102 (conversions) - ---- - -GTM-003: Launch Week Timeline -Type: Timeline -Owner: Launch Coordinator -Status: Planned - -Phase: Launch Week - -Day -7 (Pre-launch): - - [ ] Email list teaser (GTM-004) - - [ ] Social media hints across GTM channels - - [ ] PR outreach to tech media - - [ ] Staging environment verification - -Day -1 (Final): - - [ ] All GTM assets approved - - [ ] MON- dashboards live and verified - - [ ] Team roles + escalation paths confirmed - - [ ] Support team briefed (CFD- processing workflow ready) - -Day 0 (Launch): - - [ ] Product Hunt live at 12:01 AM PT (GTM-002) - - [ ] Social media posts scheduled (GTM channels) - - [ ] Email to waitlist with GTM-001 messaging - - [ ] Monitor KPI-101 (reach), KPI-102 (acquisition), MON- dashboards - -Day 1-3: - - [ ] Respond to all PH comments and support tickets - - [ ] Share early wins (feedback testimonials) - - [ ] Watch KPI-103 (activation) — adjust onboarding if needed - -Day 4-7: - - [ ] Analyze KPI- metrics vs targets - - [ ] Publish case study from early adopter (CFD-) - - [ ] Plan rapid iteration based on KPI- signals - -Dependencies: DEP-002 (release criteria met), MON-005 (dashboards ready), GTM-assets ready -Milestones: 1000 signups (Day 3), 40%+ activation (Day 7), First paying customer (Day 14) - -Linked IDs: DEP-001/002/003, MON-005, KPI-101/102/103, GTM-001/002/004/005/006 -``` - -## Core Concept: Launch as Campaign - -> A launch is not "making the product available." It is a **coordinated campaign** that creates awareness, drives activation, and captures feedback. Every touchpoint should move users toward value. - -## GTM Components +# GTM Strategy (Orchestrator) -| Component | Purpose | Output | -|-----------|---------|--------| -| **Messaging** | What we say | GTM- (value props, headlines) | -| **Channels** | Where we say it | GTM- (channel strategy) | -| **Timing** | When we launch | GTM- (timeline, phases) | -| **Coordination** | Who does what | GTM- (RACI, tasks) | +Position in workflow: v0.8 Monitoring Setup → **v0.9 GTM Strategy (Orchestrator)** → v0.9 Launch Metrics -## Execution +> **This skill is an orchestrator, not a primary skill.** GTM strategy is composed of three +> framework-grounded sub-skills that run in sequence. This skill chains them and reconciles +> outputs. New work on positioning, offers, or channels should invoke the sub-skills directly. -1. **Review target personas** - - Pull PER- from v0.4 - - Understand where they spend time - - Know what messages resonate +## Execution Mode -2. **Define core messaging** - - Value proposition (from CFD- value hypotheses) - - Positioning (from BR- product type) - - Key differentiators (from v0.2 competitive landscape) +Default is **standard**. See [`.claude/rules/08-skill-execution-modes.md`](../../rules/08-skill-execution-modes.md) for selection logic. -3. **Select launch channels** - - Match channels to personas - - Prioritize by reach and conversion potential - - Consider owned, earned, and paid media +| Mode | What this skill produces | +|------|--------------------------| +| **quick** | Each sub-skill in quick mode; reconciled GTM index | +| **standard** | Each sub-skill in standard mode; full reconciliation pass over outputs | +| **deep** | Each sub-skill in deep mode; multi-pass reconciliation + risk register | -4. **Plan launch timeline** - - Pre-launch: Build anticipation - - Launch day: Maximum impact - - Post-launch: Sustain momentum +## The Three Sub-Skills -5. **Assign ownership** - - Who creates content? - - Who monitors channels? - - Who handles support surge? +GTM is **positioning before offer before channels**. Running them out of order produces channel plans that don't reach the right people with the right pitch. -6. **Create GTM- entries** with full traceability +| Step | Sub-skill | Framework | Owner | +|------|-----------|-----------|-------| +| 1 | [`prd-v09-positioning-dunford`](../prd-v09-positioning-dunford/SKILL.md) | April Dunford, *Obviously Awesome* (5-step) | Founder + PM | +| 2 | [`prd-v09-offer-construction-hormozi`](../prd-v09-offer-construction-hormozi/SKILL.md) | Alex Hormozi, *$100M Offers* (value equation + Grand Slam) | Founder + Sales | +| 3 | [`prd-v09-launch-channels-orb`](../prd-v09-launch-channels-orb/SKILL.md) | Corey Haines, ORB framework (Owned / Rented / Borrowed) | Growth | -## GTM- Output Template - -``` -GTM-XXX: [GTM Item Title] -Type: [Messaging | Channel | Timeline | Task | Asset] -Owner: [Person or team responsible] -Status: [Planned | In Progress | Ready | Live] - -For Messaging Type: - Audience: [PER-XXX targeted] - Format: [Headline | Value Prop | Tagline | Elevator Pitch] - Message: [The actual copy] - Supporting Evidence: [CFD-XXX value hypothesis it's based on] - Where Used: [GTM-YYY channels, assets] - -For Channel Type: - Channel: [Specific platform or medium] - Audience Fit: [Why this channel reaches PER-XXX] - Strategy: [How we'll use this channel] - Content Plan: [What content goes here] - Success Metric: [How we measure effectiveness] - Linked Assets: [GTM-YYY assets for this channel] - -For Timeline Type: - Phase: [Pre-launch | Launch Day | Week 1 | Month 1] - Date: [Specific date or relative timing] - Activities: [What happens in this phase] - Dependencies: [What must be ready] - Milestones: [Key checkpoints] - -For Task Type: - Task: [What needs to be done] - Owner: [Who is responsible] - Due: [When it's due] - Dependency: [What it depends on] - Deliverable: [What's produced] - -For Asset Type: - Asset: [What this is — landing page, email, video] - Purpose: [What it accomplishes] - Channel: [GTM-YYY where it's used] - Copy: [GTM-YYY messaging used] - Status: [Draft | Review | Approved | Live] - -Linked IDs: [PER-XXX, CFD-XXX, KPI-XXX related] -``` +Use the v0.9 tactical playbooks ([`prd-v09-aeo-audit`](../prd-v09-aeo-audit/SKILL.md), [`prd-v09-alternatives-pages`](../prd-v09-alternatives-pages/SKILL.md), [`prd-v09-cold-outreach-tiered`](../prd-v09-cold-outreach-tiered/SKILL.md), [`prd-v09-hn-reddit-launch`](../prd-v09-hn-reddit-launch/SKILL.md)) **after** these three are complete — each plugs into a specific channel from step 3. -**Example GTM- entries:** +## Orchestration Workflow ``` -GTM-001: Primary Value Proposition -Type: Messaging -Owner: Product Marketing -Status: Ready - -Audience: PER-001 (Startup Founder) -Format: Value Prop -Message: "Ship faster with AI that understands your codebase. - Context-aware coding assistance that reduces debugging - time by 40%." -Supporting Evidence: CFD-010 (time savings validated in interviews) -Where Used: GTM-005 (Landing Page), GTM-010 (Product Hunt) - -Linked IDs: PER-001, CFD-010, KPI-001 +1. Positioning (Dunford) → GTM-*(positioning), BR-POS-* + ↓ +2. Offer (Hormozi) → GTM-*(offer, guarantee), BR-PRICING-* + ↓ +3. Channels (ORB) → GTM-*(channel, sequence, mix-matrix) + ↓ +4. Reconciliation (this skill) → GTM-*(index) with cross-skill checks + ↓ +5. Tactical playbooks → AEO audit, alt pages, cold outreach, HN/Reddit (v0.9 tactical) + ↓ +6. Launch Metrics + Feedback → v0.9 Launch Metrics, Feedback Loop Setup ``` -``` -GTM-002: Product Hunt Launch -Type: Channel -Owner: Growth Team -Status: Planned - -Channel: Product Hunt -Audience Fit: PER-001 (Startup Founder) frequents PH for tools -Strategy: - - Launch on Tuesday 12:01 AM PT - - Engage with comments first 24 hours - - Share maker story - - Prepare demo video -Content Plan: - - Tagline: GTM-001 (Primary Value Prop) - - Maker comment: GTM-003 (Founder Story) - - Demo video: GTM-006 (Product Demo) -Success Metric: Top 5 product of the day, 500+ upvotes - -Linked IDs: PER-001, GTM-001, GTM-003, GTM-006, KPI-005 -``` - -``` -GTM-003: Launch Week Timeline -Type: Timeline -Owner: Launch Coordinator -Status: Planned +## Reconciliation (this skill's actual work) -Phase: Launch Week +After the three sub-skills run, check for cross-skill consistency: -Day -7 (Pre-launch): - - [ ] Email list teaser - - [ ] Social media hints - - [ ] Press outreach +| Check | Question | Fix if no | +|-------|----------|-----------| +| **Best-fit alignment** | Are channels (step 3) actually used by the best-fit segment defined in positioning (step 1)? | Re-run step 3 with corrected segment lens | +| **Promise consistency** | Does the offer (step 2) promise more or less than the positioning supports? | Adjust offer down; do not silently inflate positioning | +| **Guarantee viability** | Can the guarantee in the offer survive the launch volume from step 3? | Tighten guarantee terms or reduce paid-channel reach until guarantee can scale | +| **Category-channel fit** | Is the launch channel mix appropriate for the market category claimed in positioning? | Drop channels that don't fit the category (e.g., enterprise category → no TikTok) | +| **KPI rollup** | Do per-channel attribution targets sum to v0.3 baseline KPI- targets? | Adjust channel budget/effort allocation | -Day -1: - - [ ] Final staging verification - - [ ] Launch assets approved - - [ ] Team roles confirmed +Reconciliation is the load-bearing work — without it, the three sub-skill outputs are incoherent. -Day 0 (Launch): - - [ ] Product Hunt live at 12:01 AM PT - - [ ] Social media posts scheduled - - [ ] Email to waitlist - - [ ] Monitor and engage +## Consumes -Day 1-3: - - [ ] Respond to all feedback - - [ ] Fix any critical issues - - [ ] Share early wins +This skill's `Consumes` is the **union** of the three sub-skills' `Consumes`: -Day 4-7: - - [ ] Publish case study - - [ ] Analyze metrics - - [ ] Plan iteration +- From v0.2 (CFD-, BR-product-type), v0.3 (FEA-, KPI-, BR-pricing), v0.4 (PER-), v0.8 (DEP-, MON-) +- See each sub-skill for the specific IDs it pulls -Dependencies: DEP- release criteria met, MON- monitoring active -Milestones: 1000 signups (Day 3), First paying customer (Day 7) +## Produces -Linked IDs: DEP-002, MON-005, KPI-001 -``` +This skill produces the **reconciled GTM- index** — a single entry pointing at all GTM- entries created by the three sub-skills, with reconciliation notes: ``` -GTM-004: Landing Page Hero Section -Type: Asset -Owner: Design + Marketing -Status: In Progress - -Asset: Landing page hero section -Purpose: Convert visitors to signups -Channel: GTM-007 (Website), GTM-002 (Product Hunt referrals) -Copy: GTM-001 (Primary Value Prop) -Status: Review - -Components: - - Headline: "Ship faster with AI that understands your codebase" - - Subhead: "Context-aware coding assistance that reduces - debugging time by 40%" - - CTA: "Start Free Trial" → /signup - - Social proof: "Trusted by 500+ developers" - - Demo video thumbnail: GTM-006 - -Linked IDs: GTM-001, GTM-006, SCR-001 -``` - -## Channel Selection Framework - -Match channels to product type (from v0.2 BR-): - -| Product Type | Primary Channels | Strategy | -|--------------|------------------|----------| -| **Fast Follow** | SEO, Paid, Aggregators | "We're the better [competitor]" | -| **Slice** | Community, Integrations, Partnerships | "Best [thing] for [ecosystem]" | -| **Innovation** | Content, PR, Events | "Here's why this matters" | +GTM-XXX: GTM Strategy Index +Type: Index +Owner: Launch Coordinator +Status: Approved -## Channel Categories +Positioning: GTM-AAA (statement), BR-POS-* (rules) +Offer: GTM-BBB (card), GTM-CCC (guarantee) +Channels: GTM-DDD/EEE/FFF (channel entries), GTM-GGG (mix matrix), GTM-HHH (sequence) +Tactical (when active): GTM-* from AEO, alternatives, cold outreach, HN/Reddit playbooks -| Category | Examples | Best For | -|----------|----------|----------| -| **Owned** | Website, Blog, Email, Product | Control message, build audience | -| **Earned** | PR, Reviews, Word-of-mouth | Credibility, reach | -| **Paid** | Ads, Sponsorships, Influencers | Scale, targeting | -| **Community** | Forums, Discord, Twitter | Engagement, feedback | +Reconciliation notes: + - Best-fit alignment: [PASS | issue + fix] + - Promise consistency: [...] + - Guarantee viability: [...] + - Category-channel fit: [...] + - KPI rollup: [...] -## Messaging Hierarchy +Linked IDs: All GTM-* created in this lifecycle iteration +``` -| Level | Purpose | Example | -|-------|---------|---------| -| **Mission** | Why we exist | "Make developers 10x more productive" | -| **Value Prop** | What we offer | "AI that understands your codebase" | -| **Differentiator** | Why us vs others | "Context-aware, not just autocomplete" | -| **Proof Point** | Why believe us | "40% reduction in debugging time" | -| **CTA** | What to do next | "Start your free trial" | +## Migration Note (legacy entries) -## Launch Phases +Prior to this refactor, this skill produced GTM-* entries directly with Type=Messaging, Type=Channel, Type=Timeline, Type=Task, Type=Asset. Existing entries with those types remain valid — the sub-skills produce comparable types structured around their respective frameworks. -| Phase | Duration | Focus | Success Metric | -|-------|----------|-------|----------------| -| **Teaser** | 2 weeks pre | Build anticipation | Waitlist signups | -| **Launch** | Day 0-3 | Maximum impact | Traffic, signups | -| **Momentum** | Week 1-4 | Sustain interest | Activation, feedback | -| **Steady State** | Month 2+ | Optimize funnel | Conversion, retention | +If you have legacy GTM-* entries created before the split, run each sub-skill once over the existing material to: -## Anti-Patterns +- Reclassify messaging entries as Type=Positioning (anchored in Dunford's 5 steps) +- Validate offer-related entries against the Hormozi value equation +- Reclassify channel entries by ORB layer (Owned / Rented / Borrowed) -| Pattern | Signal | Fix | -|---------|--------|-----| -| **Launch and leave** | Big launch day, then silence | Plan 30 days of post-launch activity | -| **Everything everywhere** | All channels, no focus | Pick 2-3 channels, do them well | -| **Features not benefits** | "We have X, Y, Z" | "You can achieve X, Y, Z" | -| **No measurement** | "The launch went well (I think)" | Define KPI- before launch | -| **Ignoring personas** | Generic messaging for everyone | Tailor by PER- | -| **Over-promising** | "Revolutionary AI" without proof | Ground in CFD- evidence | +No automatic migration — the reclassification is a deliberate decision that surfaces gaps in the original work. ## Quality Gates Before proceeding to Launch Metrics: -- [ ] Core messaging defined (GTM- Messaging type) -- [ ] Primary channels selected (GTM- Channel type) -- [ ] Launch timeline created (GTM- Timeline type) -- [ ] All tasks assigned owners (GTM- Task type) -- [ ] Key assets identified (GTM- Asset type) -- [ ] Messaging traces to CFD- evidence -- [ ] Channel selection matches PER- personas +- [ ] All three sub-skills have completed (or quick-mode placeholders exist for each) +- [ ] Reconciliation table filled with all five checks (PASS or fix logged) +- [ ] GTM- index entry created pointing at all sub-skill outputs +- [ ] No unreconciled contradictions between positioning, offer, and channels ## Downstream Connections -| Consumer | What It Uses | Example | -|----------|--------------|---------| -| **Launch Metrics** | GTM- channels inform tracking | GTM-002 (PH) → KPI-005 (PH upvotes) | -| **Feedback Loop Setup** | GTM- channels become feedback sources | GTM-002 comments → CFD-100 | -| **Content Creation** | GTM- messaging guides content | GTM-001 → blog post theme | -| **Sales** | GTM- messaging for outreach | GTM-001 → sales email template | - -## Detailed References +See each sub-skill for direct downstream connections. This orchestrator's downstream is: -- **Messaging framework examples**: See `references/messaging-examples.md` -- **GTM- entry template**: See `assets/gtm-template.md` -- **Channel evaluation guide**: See `references/channel-guide.md` -- **Launch timeline template**: See `references/timeline-template.md` +| Consumer | What it uses | +|----------|--------------| +| **v0.9 Tactical playbooks** | The GTM index identifies which channels are active for tactical-skill plug-in | +| **v0.9 Launch Metrics** | The reconciled KPI rollup | +| **v0.9 Feedback Loop Setup** | The reconciled channel list | diff --git a/.claude/skills/prd-v09-hn-reddit-launch/SKILL.md b/.claude/skills/prd-v09-hn-reddit-launch/SKILL.md new file mode 100644 index 0000000..f6f8720 --- /dev/null +++ b/.claude/skills/prd-v09-hn-reddit-launch/SKILL.md @@ -0,0 +1,228 @@ +--- +name: prd-v09-hn-reddit-launch +description: > + Build a Hacker News + Reddit launch playbook for developer-tools and community-led products + during PRD v0.9 Go-to-Market. Triggers on requests to plan HN/Reddit launch, "Show HN" post, + community launch, or when user asks "HN launch", "Show HN", "Reddit launch", "launch on + /r/SaaS", "Product Hunt vs HN", "community launch", "developer launch". Outputs GTM-* with + Type=Channel-HN / Type=Channel-Reddit entries with timing, title, story angle, and + engagement plan. +context: fork +allowed-tools: + - Read + - Write + - Edit + - Glob + - Grep + - WebSearch + - WebFetch + +execution_modes: + default: standard + supports: [quick, standard, deep] +--- + +# HN + Reddit Launch Playbook + +Position in workflow: v0.9 Launch Channels (ORB) → **v0.9 HN + Reddit Launch** → v0.9 Launch Metrics + +## Execution Mode + +Default is **standard**. See [`.claude/rules/08-skill-execution-modes.md`](../../rules/08-skill-execution-modes.md) for selection logic. + +| Mode | What this skill produces | +|------|--------------------------| +| **quick** | Single Show HN post draft; title; first 4-hour engagement plan | +| **standard** | HN post + 2 Reddit cross-posts; story angle decision; comment-engagement rules; non-launch follow-up wave | +| **deep** | HN + 3–5 Reddit subreddits + Lobsters + Indie Hackers; pre-launch warm-up posts; subreddit-specific tone variants; AMA scheduling | + +## What This Does + +Produces a launch playbook for Hacker News and Reddit — two channels where developer-tool, technical, and community-friendly products win launches if executed well and lose them silently if executed badly. Both platforms reward authenticity, technical depth, and founder presence; both punish marketing-speak, top-of-funnel sales tactics, and absent founders. + +This is a **channel-execution** skill. It assumes the ORB channel mix already includes HN/Reddit; it doesn't second-guess that choice. If positioning best-fit doesn't live on these platforms, this skill should not run. + +## How It Works + +1. **Decide if HN/Reddit fits** — Re-check positioning best-fit characteristics. HN/Reddit work for: developer tools, technical products, B2B with developer/PM buyer, indie/bootstrapped story, open-source. HN/Reddit are wrong for: enterprise procurement, regulated B2B with non-technical buyer, consumer products targeting non-technical users. +2. **Pick the story angle** — One of: + - **Show HN** (product) — "Show HN: [Product] — [one-line description]" — works when product itself is interesting + - **Ask HN** (problem) — "Ask HN: How do you handle [pain]?" — works when category needs education before product + - **Story** — "I built X because Y" or "Why we [unusual decision]" — works when founder narrative is the hook + - **Open source** — "[Project] is now open source" — works when there's something to release + - **Technical writeup** — "How we built X" — works for HN; less for Reddit +3. **Craft the title** — Platform-specific: + - **HN**: Factual, no marketing words, no emoji. Example: "Show HN: An open-source alternative to X". HN guidelines reject hype. + - **Reddit**: Subreddit-specific. Each subreddit has tone norms. Read the subreddit's pinned rules and recent top posts. +4. **Plan timing**: + - **HN**: Post Tue–Thu, 8–10am PT. Avoid Mondays and weekends. The first hour matters most — upvote velocity determines front-page placement. + - **Reddit**: Subreddit-specific peak time. Read subreddit traffic patterns. Some subreddits ban "self-promotion" posts on certain days. +5. **Founder presence (first 24h)** — Founder responds to every substantive comment in the first 4 hours. No "thanks!" replies; engage with the argument. This is the difference between a 50-comment thread and a 500-comment thread. +6. **Non-launch follow-up** [standard+] — 30–60 days post-launch, return to HN/Reddit with: + - Technical writeup of how you built it + - "What I learned launching on HN" retrospective (if appropriate) + - Case study or growth update + - AMA if launch generated real interest + +## Example + +Developer tool launching. Best-fit = solo developers + small dev teams. ORB matrix has HN as the primary Borrowed channel. + +**Story angle**: "Show HN" — product is self-evident; demo is the hook. + +**Title**: `Show HN: [Product] – Type-safe contracts between your frontend and backend` + +**Timing**: Tuesday 9:00 AM PT. Founder cleared calendar for the next 4 hours. + +**Post body** (HN expects substance): + +> Hi HN — I built this because I spent 2 years debugging "frontend says string, backend says number" issues at my last job. +> +> [Product] generates type-safe API clients from your OpenAPI spec. It works with TypeScript, Python, Go, and Rust. +> +> Tech stack: [...] +> +> Some things that worked and didn't: [...] +> +> Free for individuals; paid for teams. Source is on GitHub: [link]. +> +> Happy to answer questions. + +**First 4 hours**: Founder watches `Show HN` ranking. Responds substantively to every technical question. Doesn't engage with off-topic critique. Posts updates if relevant. + +**Reddit cross-post**: 24 hours later, post to `/r/programming` (technical), `/r/typescript` (community), `/r/SaaS` (founder story). Each with a subreddit-tuned title and intro. + +**Follow-up wave** (Day 30): "Building [Product]: 30 days after launch" — retrospective post. + +## What You Get Back + +- **GTM-\* with Type=Channel-HN** (one entry) — Title, body, timing, founder-engagement plan +- **GTM-\* with Type=Channel-Reddit** (one per subreddit) — Subreddit-tuned title, body, posting time +- **GTM-\* engagement rules** — Comment-response policy, when to escalate to founder +- **GTM-\* follow-up wave** — 30/60-day post-launch content plan + +## When to Use It + +| Trigger | Mode | +|---------|------| +| Developer-tool launch | standard | +| Open-source release | standard | +| Indie / bootstrapped product launch (story angle) | standard | +| B2B SaaS with technical buyer | quick (just HN; skip Reddit) | +| Big technical decision worth a writeup ("how we migrated to X") | quick (one HN post, no Reddit) | +| Enterprise / non-technical buyer | **do not use** | +| Regulated category (medical, financial) | **do not use** without legal review | + +## Consumes + +- **GTM-\* positioning** + **PER-\* best-fit characteristics** — Anchors the story angle and confirms HN/Reddit is even appropriate +- **GTM-\* launch channels** (from v0.9 Launch Channels ORB) — HN/Reddit must already be in the mix matrix +- **GTM-\* offer card** — Determines the post's CTA (free tier, beta, open source, paid trial) +- **CFD-\* customer stories** — Anchors social proof in comments and follow-up +- **BR-POS-\* constraints** — Tone guardrails (no enterprise speak in /r/SaaS, etc.) + +## Produces + +- **GTM-\* with Type=Channel-HN** (one entry) +- **GTM-\* with Type=Channel-Reddit** (one per subreddit) +- **GTM-\* engagement-rules** entry — Comment policy, who escalates what +- **GTM-\* follow-up-wave** entry — Post-launch content plan (30/60 day) + +## Output Template + +``` +GTM-XXX: Channel — Hacker News Launch +Type: Channel-HN +Layer: Borrowed +Owner: Founder (must be founder, not marketing) +Status: [Planned | Active] + +Story angle: [Show HN | Ask HN | Story | Open source | Technical writeup] +Title: "[Exact title — no marketing words]" +Timing: [Day + hour, with rationale] + +Post body: + [Full body — what HN expects: substance, tech detail, honest tradeoffs] + +CTA: [Free tier link | GitHub link | Beta signup link] + +Founder presence: + - Watch ranking for first 4 hours (block calendar) + - Respond to every substantive comment + - Update post if relevant + - No "thanks!" replies — engage with the argument + +Failure modes to avoid: + - Marketing language in title + - Absent founder + - "Buy now" CTA (HN punishes) + - Astroturf upvotes (HN detects, instantly bans) + +Linked IDs: GTM-YYY (positioning), GTM-ZZZ (offer), PER-AAA (best-fit), KPI-BBB (HN→signup target) +``` + +``` +GTM-XXX: Channel — Reddit /r/ +Type: Channel-Reddit +Layer: Borrowed +Owner: Founder +Subreddit: /r/ +Status: [Planned | Active] + +Subreddit norms: + - Tone: [Pinned-rules summary] + - Self-promotion rule: [Subreddit's specific rule] + - Peak posting time: [Day + hour] + - Banned formats: [e.g., no link posts, no images-only] + +Title: "[Subreddit-tuned title]" +Body: [Tuned to subreddit tone] +CTA: [Whatever the subreddit allows] + +Founder presence: Same as HN — engage substantively for first 4 hours + +Linked IDs: GTM-YYY (positioning), PER-AAA (best-fit) +``` + +## Anti-Patterns + +| Pattern | Signal | Fix | +|---------|--------|-----| +| **Marketing title** | "Revolutionary AI-powered X" on HN | Rewrite as factual; HN strips marketing | +| **Absent founder** | Post goes up; founder is in a meeting | If you can't be present 4 hours, postpone the launch | +| **"Thanks!" replies** | Comment thread is full of "Thanks for the kind words!" | Engage with the argument or don't reply | +| **Astroturfing upvotes** | Asking team/friends to upvote | HN and Reddit detect coordinated voting; instant ban | +| **Cross-posting too fast** | Same post to 5 subreddits in 10 minutes | Stagger by 24+ hours; each post is rewritten for the subreddit | +| **Ignoring subreddit rules** | Banned within an hour of posting | Read the pinned rules; some subreddits ban self-promotion entirely | +| **No follow-up wave** | Launch spikes traffic, then silence | Plan 30/60-day return posts before launch day | +| **Wrong product / wrong channel** | Enterprise procurement product on /r/programming | Re-check positioning; HN/Reddit doesn't fit every product | + +## Quality Gates + +Before launch day: + +- [ ] Best-fit segment confirmed to use HN/Reddit (not assumption) +- [ ] Story angle chosen and matches the product's actual hook +- [ ] Title drafted; passes "no marketing words" check (HN) +- [ ] Founder calendar cleared for first 4 hours +- [ ] Post body has substance (technical detail, honest tradeoffs) +- [ ] CTA matches platform norms (free / GitHub / beta — not "buy now") +- [ ] Subreddit rules read for every targeted subreddit +- [ ] Follow-up wave (30/60 day) drafted in outline +- [ ] No astroturfing plan exists or has been considered + +## Downstream Connections + +| Consumer | What it uses | Example | +|----------|--------------|---------| +| **Launch Channels (ORB)** | Each HN/Reddit post is a Borrowed-channel entry | Rolls into channel-mix matrix | +| **Launch Metrics** | Per-post attribution → KPI-HN-signups, KPI-Reddit-signups | UTM-tagged links per post | +| **Feedback Loop Setup** | Comments become CFD- feedback entries | Top-voted comment thread → CFD- pattern | +| **v0.9 Case Study Builder (v1.0)** | High-engagement HN/Reddit launches → case study | "How we got 800 upvotes on Show HN" | +| **v0.9 AEO Audit** | HN/Reddit threads become AI-citation sources | Hi-rank threads → AEO inclusion | + +## Detailed References + +- jonathimer's `hacker-news-strategy` and `reddit-engagement` skills (devmarketing-skills) +- HN guidelines: news.ycombinator.com/showhn.html +- (No bundled `references/` — HN/Reddit norms change; read current pinned rules) diff --git a/.claude/skills/prd-v09-launch-channels-orb/SKILL.md b/.claude/skills/prd-v09-launch-channels-orb/SKILL.md new file mode 100644 index 0000000..4a12c56 --- /dev/null +++ b/.claude/skills/prd-v09-launch-channels-orb/SKILL.md @@ -0,0 +1,240 @@ +--- +name: prd-v09-launch-channels-orb +description: > + Allocate launch channels using the Owned / Rented / Borrowed (ORB) framework during PRD v0.9 + Go-to-Market. Triggers on requests to pick launch channels, distribute the offer, build a + channel portfolio, or when user asks "where do we launch?", "what channels?", "ORB", + "owned vs rented vs borrowed", "channel allocation", "channel mix", "Corey Haines launch". + Outputs GTM-* entries with Type=Channel, a channel-mix matrix, and a launch sequence. +context: fork +allowed-tools: + - Read + - Write + - Edit + - Glob + - Grep + - WebSearch + - WebFetch + +execution_modes: + default: standard + supports: [quick, standard, deep] +--- + +# Launch Channels (ORB: Owned / Rented / Borrowed) + +Position in workflow: v0.9 Offer Construction (Hormozi) → **v0.9 Launch Channels (ORB)** → v0.9 Launch Metrics + +## Execution Mode + +Default is **standard**. See [`.claude/rules/08-skill-execution-modes.md`](../../rules/08-skill-execution-modes.md) for selection logic. + +| Mode | What this skill produces | +|------|--------------------------| +| **quick** | 1 channel per layer (3 channels total); single-week sequence | +| **standard** | 2–3 channels per layer; pre-launch / launch / post-launch sequence; attribution plan per channel | +| **deep** | Full portfolio; per-channel content strategy; budget allocation; per-channel ROI projection; channel-mix risk register | + +## Framework: Owned / Rented / Borrowed (ORB) + +ORB classifies every distribution channel by **who controls the audience**. The rule: **own the relationship, rent the platform, borrow the reach** — and balance the portfolio so no single channel can take you out. + +| Layer | Definition | Examples | Cost | Compounding | +|-------|------------|----------|------|-------------| +| **Owned** | You control the audience and the channel | Email list, website, product itself, blog you host, customer base | Time + tools | High — every additional list member compounds future launches | +| **Rented** | You build presence on someone else's platform | Twitter/X, LinkedIn, YouTube, Slack/Discord communities, podcasts you host | Time | Medium — platform changes rules; audience is portable but messy | +| **Borrowed** | You access someone else's audience temporarily | Press, podcast guesting, influencers, paid acquisition, integrations, partnerships, affiliate | Money or favor | Low — one-time reach unless converted to Owned/Rented | + +### The Channel Allocation Principles + +1. **Build Owned before launch, rent through launch, borrow at launch.** Without an owned audience, the launch is a one-shot dependent on borrowed reach. +2. **Pick channels your best-fit segment already uses.** Pulled from the Positioning best-fit characteristics — not from "what's popular this quarter." +3. **One channel per layer to start.** Too many channels at once = no signal which is working. Add channels by tier 2–3 only once tier-1 attribution is clean. +4. **Convert Borrowed → Owned aggressively.** Every press hit, podcast guest spot, or partnership should funnel to an owned channel (email signup, demo request) — otherwise it's vanity reach. +5. **Borrowed scales reach; Owned scales repeat.** A launch is a moment; the goal is a list. + +## Consumes + +- **GTM-\* positioning statement** (from v0.9 Positioning) — Best-fit characteristics define where this segment actually spends time +- **GTM-\* offer card** (from v0.9 Offer Construction) — The unit being distributed; channels must accommodate the offer's complexity +- **PER-\* personas** (sharpened by Positioning) — Channel behavior data +- **BR-\* product type** (from v0.2) — Clone/Innovation/Slice/Wrapper channel mixes differ: Clone leans Borrowed-paid, Innovation leans Owned-content, Slice leans Rented-community +- **KPI-\* baseline targets** (from v0.3 Outcome Definition) — Per-channel attribution targets must roll up to baseline KPIs +- **DEP-\* release readiness** (from v0.8) — Channels only fire after DEP- criteria met + +## Produces + +- **GTM-\* with Type=Channel** (one per channel) — Channel name, layer (O/R/B), best-fit fit rationale, content plan, attribution plan, owner, timeline phase +- **GTM-\* channel-mix matrix** (one entry) — Portfolio summary: which channels in which phase, with budget/effort allocation +- **GTM-\* with Type=Sequence** — Pre-launch / launch / post-launch channel firing order + +## Execution + +### Step 1: Map the best-fit segment's channels + +From the Positioning best-fit characteristics, list **where this segment is right now**. Be specific: + +- Owned channels they already subscribe to (newsletters, podcasts) +- Rented platforms they actively use (with handles / community names) +- Borrowed sources they trust (publications, influencers, conferences) + +Do not guess. If you don't know, that's a CFD- research gap. + +### Step 2: Audit your existing assets + +What do you already have in each ORB layer? + +| Layer | Asset | Reach (est.) | Activation | Notes | +|-------|-------|--------------|------------|-------| +| Owned | Email list | | | | +| Owned | Existing customers | | | | +| Rented | Founder Twitter | | | | +| Rented | Company LinkedIn | | | | +| Borrowed | Press relationships | | | | +| Borrowed | Partner integrations | | | | + +This audit reveals leverage — most launches over-rely on Borrowed because they have no Owned to lean on. Honest audit prevents that. + +### Step 3: Pick channels per layer [standard+] + +| Mode | Owned | Rented | Borrowed | +|------|-------|--------|----------| +| quick | 1 | 1 | 1 | +| standard | 2–3 | 2–3 | 2–3 | +| deep | Full portfolio | Full portfolio | Full portfolio | + +For each candidate channel, score: +- **Fit**: Does best-fit segment actually use this? (1–5) +- **Reach**: How many of them does this channel touch? (Est.) +- **Effort**: What's the time cost per launch wave? (Hours) +- **Cost**: Direct $ cost? +- **Attribution**: Can we measure conversion from this channel? + +Drop any candidate below **Fit 3/5** — no channel is worth it if best-fit doesn't show up there. + +### Step 4: Sequence the launch + +Three phases: + +| Phase | Timeline | Channels active | Purpose | +|-------|----------|-----------------|---------| +| **Pre-launch** | T-30 to T-1 | Owned + Rented (warm) | Build anticipation, grow list | +| **Launch** | T-0 to T+7 | All three (Borrowed peaks here) | Maximum reach | +| **Post-launch** | T+7 to T+30 | Owned + Rented (sustain) | Convert reach to relationship | + +Quick mode collapses this to a single week. Deep mode extends to 90 days with explicit content per phase. + +### Step 5: Plan per-channel attribution + +Every channel gets an attribution plan that ties to KPI-: + +| Channel | UTM / tracking | KPI- attribution target | Conversion event | +|---------|----------------|-------------------------|------------------| +| Owned: Email | utm_source=email | KPI-XX signup | clicked email → reached offer page | +| Rented: Twitter | utm_source=twitter | KPI-XX signup | clicked tweet → reached offer page | +| Borrowed: PH | utm_source=producthunt | KPI-XX signup | PH referrer → reached offer page | + +If a channel can't be attributed, demote it to "supporting" status (still useful for context, but don't count it). + +### Step 6: Convert Borrowed → Owned [standard+] + +For every Borrowed channel, define the **next step that converts to Owned**. Examples: +- Press hit → article includes "join our list for [bonus]" +- Podcast guest → custom URL with email opt-in +- Product Hunt launch → "early-access list" signup as primary CTA, not "buy now" + +If a Borrowed channel has no conversion-to-Owned plan, the launch is leaking value. + +### Step 7: Build the channel-mix matrix + +A single GTM-* entry summarizing the portfolio. See output template below. + +## Output Template + +``` +GTM-XXX: Channel — [Channel Name] +Type: Channel +Layer: [Owned | Rented | Borrowed] +Owner: [Person / team] +Status: [Planned | Active | Live] + +Channel: [Specific platform or property] +Best-fit fit: [Why this channel reaches PER-XXX — anchored in Positioning best-fit characteristics] +Fit score: X/5 +Reach estimate: [#] +Effort per wave: [Hours] +Cost: [$] +Attribution: [Tracking method, e.g., utm_source=...] + +Content plan: + Pre-launch: [What goes out, when, what messaging] + Launch: [...] + Post-launch: [...] + +Conversion-to-Owned [if Borrowed]: [How this channel funnels to email list / signup] + +Linked IDs: PER-XXX (segment), GTM-YYY (positioning), GTM-ZZZ (offer), KPI-AAA (attribution target) +``` + +``` +GTM-XXX: Channel-Mix Matrix +Type: Sequence +Status: Approved + +Pre-launch (T-30 to T-1): + Owned: GTM-AAA (email), GTM-BBB (blog) + Rented: GTM-CCC (Twitter) + Borrowed: — (none active yet) + +Launch (T-0 to T+7): + Owned: GTM-AAA, GTM-BBB + Rented: GTM-CCC, GTM-DDD (LinkedIn) + Borrowed: GTM-EEE (Product Hunt), GTM-FFF (Press) + +Post-launch (T+7 to T+30): + Owned: GTM-AAA (drip sequence) + Rented: GTM-CCC (results / social proof posts) + Borrowed: GTM-FFF (case study placements) + +Total budget: $X (Borrowed: $X; Rented tools: $Y; Owned: $Z) +Total effort: X hours/week pre-launch; Y hours during launch week + +Linked IDs: GTM-YYY (positioning), GTM-ZZZ (offer), DEP-AAA (release readiness), KPI-BBB (attribution rollup) +``` + +## Anti-Patterns + +| Pattern | Signal | Fix | +|---------|--------|-----| +| **Borrowed-only launch** | "We'll launch on Product Hunt and Twitter" with no email list | Build Owned for 30+ days pre-launch or accept the one-shot risk | +| **All channels at once** | 8 channels in launch week, no idea which worked | Cut to 1 per layer until attribution is clean | +| **Channels not used by best-fit** | "We should be on TikTok" when segment is on LinkedIn | Drop the channel; segment fit > channel popularity | +| **No conversion path** | Press hit drives traffic to a homepage with no CTA | Every Borrowed channel needs an email-capture CTA | +| **Sequence flattening** | All channels fire on launch day | Pre-launch matters — borrow only after Owned and Rented are warm | +| **Vanity reach** | "We got 50k impressions" but no signups | Drop the channel or fix attribution | + +## Quality Gates + +Before proceeding to Launch Metrics: + +- [ ] At least one channel per layer (Owned + Rented + Borrowed), each with Fit ≥ 3/5 +- [ ] Every channel traces to best-fit characteristics from Positioning +- [ ] Every channel has an attribution plan (UTM or equivalent) +- [ ] Every Borrowed channel has a defined conversion-to-Owned path +- [ ] Sequence covers pre-launch, launch, post-launch phases (standard+) +- [ ] Channel-mix matrix GTM-* entry exists and references all channel GTM-* entries + +## Downstream Connections + +| Consumer | What it uses | Example | +|----------|--------------|---------| +| **Launch Metrics** | Per-channel attribution targets become KPI- entries | Per-channel UTM → KPI-channel-signups | +| **Feedback Loop Setup** | Active channels become feedback sources | Twitter mentions → CFD- entries | +| **v0.9 Tactical playbooks** | AEO audit, alternatives pages, cold outreach, HN/Reddit launch all attach to specific channels named here | Channel = AEO target | +| **v1.0 Crossing the Chasm (Moore)** | Channel mix shifts per adoption stage | Early-adopter channels ≠ early-majority channels | + +## Detailed References + +- Corey Haines, *Marketing Skills* repo — `launch` skill (ORB classification) +- Joe Pulizzi, *Content Inc.* (Owned-first compounding) +- (No bundled `references/` — read source skills for depth) diff --git a/.claude/skills/prd-v09-launch-metrics/SKILL.md b/.claude/skills/prd-v09-launch-metrics/SKILL.md index 7bd6fdf..2ae70ed 100644 --- a/.claude/skills/prd-v09-launch-metrics/SKILL.md +++ b/.claude/skills/prd-v09-launch-metrics/SKILL.md @@ -14,12 +14,26 @@ allowed-tools: - Grep - WebSearch - WebFetch + +execution_modes: + default: standard + supports: [quick, standard, deep] --- # Launch Metrics Position in workflow: v0.9 GTM Strategy → **v0.9 Launch Metrics** → v0.9 Feedback Loop Setup +## Execution Mode + +Default is **standard**. See [`.claude/rules/08-skill-execution-modes.md`](../../rules/08-skill-execution-modes.md) for selection logic. + +| Mode | What this skill produces | +|------|--------------------------| +| **quick** | 3 KPIs (one each for Reach/Acquisition/Activation); Day 7 targets; basic dashboard | +| **standard** | Full funnel (Reach → Referral); Day 1/7/30 targets; dashboards + alerts | +| **deep** | Full funnel + tier targets + Day 1/7/30/90 + product-type calibration + cohort analysis | + ## Consumes This skill requires prior work from v0.3-v0.9: diff --git a/.claude/skills/prd-v09-offer-construction-hormozi/SKILL.md b/.claude/skills/prd-v09-offer-construction-hormozi/SKILL.md new file mode 100644 index 0000000..7701950 --- /dev/null +++ b/.claude/skills/prd-v09-offer-construction-hormozi/SKILL.md @@ -0,0 +1,227 @@ +--- +name: prd-v09-offer-construction-hormozi +description: > + Construct a high-conversion offer using Alex Hormozi's value equation and Grand Slam Offer + mechanics during PRD v0.9 Go-to-Market. Triggers on requests to design the offer, set up the + pitch, build bonuses or guarantees, or when user asks "how do we package this?", "what's the + offer?", "build a grand slam offer", "Hormozi", "$100M offers", "guarantee", "bonus stack". + Outputs GTM-* entries with Type=Offer / Type=Guarantee and BR-PRICING-* updates. +context: fork +allowed-tools: + - Read + - Write + - Edit + - Glob + - Grep + - WebSearch + +execution_modes: + default: standard + supports: [quick, standard, deep] +--- + +# Offer Construction (Hormozi $100M Offers) + +Position in workflow: v0.9 Positioning (Dunford) → **v0.9 Offer Construction (Hormozi)** → v0.9 Launch Channels (ORB) + +## Execution Mode + +Default is **standard**. See [`.claude/rules/08-skill-execution-modes.md`](../../rules/08-skill-execution-modes.md) for selection logic. + +| Mode | What this skill produces | +|------|--------------------------| +| **quick** | One offer; 1–2 named bonuses; one simple guarantee; price anchor | +| **standard** | Full value equation calibrated; 3–5 bonuses with anchored values; one named guarantee; scarcity / urgency rule | +| **deep** | Multi-tier offers (entry / mid / premium); guarantee experimentation plan; price anchor A/B; bonus value validation plan | + +## Framework: Value Equation and Grand Slam Offer + +From *$100M Offers: How To Make Offers So Good People Feel Stupid Saying No* (Alex Hormozi, 2021). An offer is the **complete commercial proposition** — what they get, what it costs, what's guaranteed, what's bundled, what's urgent — not just the product or the price. + +### The Value Equation + +Perceived Value = **(Dream Outcome × Perceived Likelihood of Achievement)** / **(Time Delay × Effort & Sacrifice)** + +Four levers — increase the numerator, decrease the denominator: + +1. **Dream Outcome** — What does the customer actually want? Express in their words. (Higher = better.) +2. **Perceived Likelihood of Achievement** — How sure are they it will work? (Higher = better. Anchored by guarantees, social proof, case studies.) +3. **Time Delay** — How long until they get the outcome? (Lower = better.) +4. **Effort & Sacrifice** — How much work do they have to do? (Lower = better.) + +If perceived value < price, the offer fails regardless of product quality. + +### Grand Slam Offer Components + +A complete offer stacks five things: + +1. **Core promise** — the headline outcome (anchored in the value equation) +2. **Bonus stack** — additional named items, each with anchored monetary value, that increase perceived value without proportionally increasing cost-to-deliver +3. **Guarantee** — one of: unconditional refund, conditional ("if X doesn't happen, we Y"), anti-guarantee ("we don't refund — here's why we're so confident"), implied (case studies, results), or service-level +4. **Scarcity** — limited supply (real: capacity, beta seats, custom service slots) +5. **Urgency** — limited time (real: cohort start, price increase, bonus expiration) + +Scarcity and urgency must be **real**. Manufactured scarcity erodes trust and is incompatible with Dunford's positioning ([prd-v09-positioning-dunford](../prd-v09-positioning-dunford/SKILL.md)). + +## Consumes + +- **GTM-\* positioning statement** (from v0.9 Positioning) — Dream Outcome and Likelihood of Achievement language comes from the positioning's value claims; the offer cannot promise more than the positioning supports +- **BR-\* pricing model** (from v0.3 Pricing Model) — Existing price tiers; offer can stack on top but should not silently change the model +- **FEA-\* features** (from v0.3 Feature Value Planning) — Bonuses must be real product features or real services, not vapor +- **CFD-\* value evidence** (from v0.1–v0.4) — "Dream Outcome" wording comes from customer interviews; "Likelihood of Achievement" anchors come from case studies and usage data +- **PER-\* best-fit segment** (sharpened by Positioning) — Determines what "Dream Outcome" actually means to this buyer + +This skill assumes Positioning is complete (positioning statement at confidence ≥ 3/5) and v0.3 Pricing Model is set. + +## Produces + +- **GTM-\* with Type=Offer** — The full offer card: core promise, bonus stack with anchored values, guarantee reference, scarcity/urgency rule, price anchor +- **GTM-\* with Type=Guarantee** (separate ID) — The guarantee in standalone form so messaging can reference it directly +- **BR-PRICING-\* updates** — If the offer changes the pricing model (e.g., adds a one-time payment option, changes refund policy), update the BR- entries +- **CFD-\* gaps surfaced** — If the offer's Likelihood-of-Achievement claims can't be substantiated, log a CFD- research gap + +## Execution + +### Step 1: Calibrate the Value Equation + +Write down each lever in the customer's words. Score each on a 1–5 scale: + +| Lever | Current | Target | Gap | +|-------|---------|--------|-----| +| Dream Outcome | | | | +| Likelihood of Achievement | | | | +| Time Delay | | | | +| Effort & Sacrifice | | | | + +The largest gap = the lever to attack first. + +### Step 2: Design the core promise + +State the headline outcome in one sentence: *"You will [Dream Outcome] in [Time Delay] without [Effort & Sacrifice]."* Test the sentence against the positioning statement — if they conflict, fix the offer, not the positioning. + +### Step 3: Build the bonus stack [standard+] + +Aim for 3–5 bonuses. For each: +- Name it concretely (not "additional support" — "1:1 setup call with founder, 30 min") +- Assign an anchored value (what would this cost separately?) +- Confirm it's deliverable at near-zero marginal cost (or factor cost into pricing) + +Total stacked value should be ≥ 3× the price. If it isn't, the offer's perceived value is too low. + +### Step 4: Choose a guarantee + +Pick the strongest guarantee you can deliver: + +| Guarantee Type | When to Use | Risk | +|----------------|-------------|------| +| Unconditional refund | Confident in product; low-touch sale | Refund-fraud exposure | +| Conditional ("if X doesn't happen, we Y") | Specific outcome promised | Requires clear measurement | +| Anti-guarantee | Premium / high-status positioning | Loses risk-averse buyers | +| Implied (case studies) | Long sales cycle, B2B | Slower trust-building | +| Service-level | Ongoing relationship | Operational commitment | + +Write the guarantee in the customer's words. If you cannot stand behind it, choose a weaker one or fix the product. + +### Step 5: Add scarcity and urgency [standard+] + +| Type | Examples | +|------|----------| +| **Scarcity (supply)** | Beta seats (real cap), capacity-limited service tier, founding-member pricing | +| **Urgency (time)** | Cohort start date, price increase scheduled, bonus expiration | + +Both must be real. Document the *mechanism* — what triggers the cap or deadline — in the GTM- entry. If you can't document the mechanism, drop the claim. + +### Step 6: Anchor the price [deep only] + +Present the offer in this order: **Dream Outcome → Stack value → Guarantee → Scarcity → Price**. The price should feel inevitable given everything before it. + +If running multiple offer tiers in deep mode, design the middle tier as the anchor (most buyers pick the option positioned next to the highest-priced option they almost-picked). + +## Output Template + +``` +GTM-XXX: Offer Card +Type: Offer +Owner: Founder / Sales +Status: Ready + +Core promise: [One-sentence headline outcome] +Best-fit segment: PER-XXX +Linked positioning: GTM-YYY (Positioning Statement) + +Value equation: + Dream Outcome: [In customer words] + Likelihood of Achievement: [What anchors this — case studies, guarantees] + Time Delay: [Target] + Effort & Sacrifice: [Target] + +Bonus stack: + 1. [Bonus name] — anchored value: $X (real cost: ~$Y) — FEA-ZZZ or service + 2. [Bonus name] — ... + 3. ... + +Total stacked value: $X (vs. price $Y — ratio ≥ 3:1) + +Guarantee: GTM-ZZZ (separate entry) + +Scarcity: [Real mechanism — beta cap, capacity limit, etc.] +Urgency: [Real deadline — cohort start, price change, etc.] + +Price: $X (anchored against stacked value) +Payment terms: [One-time / monthly / annual / split] + +Linked IDs: PER-XXX, GTM-YYY (positioning), FEA-ZZZ (bonus features), BR-PRICING-AAA, CFD-BBB (value evidence) +``` + +``` +GTM-XXX: Guarantee +Type: Guarantee +Owner: Founder / Legal +Status: Approved + +Guarantee type: [Unconditional refund | Conditional | Anti-guarantee | Implied | Service-level] +Stated in customer words: "[The exact wording]" +Eligibility: [Who, when, how] +Measurement: [How "did it work?" is determined] +Failure procedure: [What happens if invoked — refund process, etc.] + +Linked IDs: GTM-YYY (Offer Card), BR-PRICING-ZZZ (if affects pricing model) +``` + +## Anti-Patterns + +| Pattern | Signal | Fix | +|---------|--------|-----| +| **Manufactured scarcity** | "Only 7 spots left" reset every week | Drop the claim or make the cap real (e.g., one cohort per quarter) | +| **Vapor bonuses** | Bonus = "lifetime access" to a thing that costs you nothing | Replace with something that has anchored value, even if cheap to deliver | +| **Promise mismatch** | Offer promises more than positioning supports | Fix the offer down; do not quietly upgrade positioning | +| **Guarantee you can't honor** | "100% refund anytime" with 60% refund-fraud rate | Pick a stronger conditional guarantee instead | +| **Stack ratio < 2:1** | Stacked value barely beats price | Either add more bonuses or drop the price; thin stacks don't convert | +| **No best-fit segment** | Offer designed for "everyone" | Pull the PER- from positioning and design for them | + +## Quality Gates + +Before proceeding to Launch Channels: + +- [ ] Value equation calibrated with current vs. target per lever +- [ ] Core promise written in one sentence +- [ ] Stack value ≥ 3× price (standard+); ≥ 2× (quick) +- [ ] Guarantee chosen and writable in customer's words +- [ ] Scarcity and urgency mechanisms are real and documented +- [ ] Offer does not contradict positioning statement +- [ ] All bonuses trace to real FEA- or service deliverables + +## Downstream Connections + +| Consumer | What it uses | Example | +|----------|--------------|---------| +| **Launch Channels (ORB)** | Offer card = the unit being distributed | Owned-channel emails sell the offer, not the product | +| **Launch Metrics** | Offer becomes KPI- conversion target | KPI: offer page → purchase rate | +| **Cold Outreach (Tactical)** | Tier 1/2/3 cold sequences end on the guarantee | Guarantee = reply-friction killer | +| **v1.0 Crossing the Chasm (Moore)** | Offer shifts as adoption stage shifts | Early-adopter offer ≠ early-majority offer | + +## Detailed References + +- Alex Hormozi, *$100M Offers* (2021) — canonical source +- Acquisition.com offer-construction resources +- (No bundled `references/` — read the book for depth) diff --git a/.claude/skills/prd-v09-positioning-dunford/SKILL.md b/.claude/skills/prd-v09-positioning-dunford/SKILL.md new file mode 100644 index 0000000..3a3dcc6 --- /dev/null +++ b/.claude/skills/prd-v09-positioning-dunford/SKILL.md @@ -0,0 +1,193 @@ +--- +name: prd-v09-positioning-dunford +description: > + Define product positioning using April Dunford's 5-step framework during PRD v0.9 Go-to-Market. + Triggers on requests to position the product, define category, frame against competitors, + or when user asks "what category are we?", "how do we position?", "Dunford positioning", + "obviously awesome", "market frame of reference", "positioning statement". + Outputs GTM-* entries with Type=Positioning and BR-POS-* positioning rules. +context: fork +allowed-tools: + - Read + - Write + - Edit + - Glob + - Grep + - WebSearch + +execution_modes: + default: standard + supports: [quick, standard, deep] +--- + +# Positioning (Dunford 5-Step) + +Position in workflow: v0.8 Monitoring Setup → **v0.9 Positioning (Dunford)** → v0.9 Offer Construction (Hormozi) → v0.9 Launch Channels (ORB) + +## Execution Mode + +Default is **standard**. See [`.claude/rules/08-skill-execution-modes.md`](../../rules/08-skill-execution-modes.md) for selection logic. + +| Mode | What this skill produces | +|------|--------------------------| +| **quick** | One positioning statement; one best-fit segment; one category claim | +| **standard** | Full 5 steps; one segment + ≥3 alternatives + 3–5 attributes mapped to value; category claim with frame of reference | +| **deep** | Multiple segment variants; A/B positioning candidates to test; competitor positioning teardown; "best-fit" disqualification rules | + +## Framework: Dunford's 5 Steps + +From *Obviously Awesome: How to Nail Product Positioning* (April Dunford, 2019). Positioning is **the act of deliberately defining how you are the best at something a defined market cares a lot about** — not a feature list, not a tagline, not your founder's story. + +The five steps run in order: + +1. **Competitive alternatives** — What would your customers use if you did not exist? (Status-quo wins as often as competitor products do.) +2. **Unique attributes** — What capabilities or qualities do *you* have that those alternatives don't? +3. **Value (and proof)** — Translate each attribute into the value it delivers to a customer. Anchor in evidence, not aspiration. +4. **Customers who care a lot** — Among all possible buyers, which segment cares *most* about that value? This is your "best-fit" target. +5. **Market category** — Pick the category (the **frame of reference**) that puts your unique strengths at the center and is intelligible to your best-fit customer. + +A 6th step (**relevant trends**) is optional and used only when a current market trend reinforces the positioning. Skip it in quick mode. + +The work product is a **positioning statement** plus a small set of **positioning rules** that downstream skills (Offer Construction, Launch Channels, GTM messaging) must honor. + +## Consumes + +- **CFD-\* competitive alternatives** (from v0.2 Competitive Landscape Mapping) — Anchors step 1; without real alternatives, positioning is hypothetical +- **CFD-\* customer interviews** (from v0.1 + v0.4) — Source for "who cares a lot" in step 4; the strongest evidence for value claims in step 3 +- **BR-\* product type** (from v0.2 Product Type Classification) — Clone/Unbundle/Undercut/Slice/Wrapper/Innovation shapes the kind of category claim that's credible +- **FEA-\* feature list** (from v0.3 Feature Value Planning) — Source for step 2 (unique attributes); attribute claims must trace to shipping features +- **PER-\* personas** (from v0.4 Persona Definition) — Step 4 best-fit segment is one of these PER- entries, sharpened + +This skill assumes v0.2 (competitive landscape, product type) and v0.4 (personas) are complete. + +## Produces + +- **GTM-\* entries with Type=Positioning** — The positioning statement, the category claim, and the frame of reference. Each downstream messaging GTM- must trace to one of these. +- **BR-POS-\* positioning rules** — Constraint-style rules: *who we are*, *who we are not*, *what category we live in*. These become guardrails for v0.9 Offer Construction, Launch Channels, and v1.0 adoption work. +- **CFD-\* updates** — When step 3 reveals value claims are weakly evidenced, surface them as research gaps with confidence ≤ 2/5. + +Confidence guidance per P4: a positioning statement should reach **3/5** before downstream skills consume it (i.e., grounded in actual customer interviews, not internal opinion). Quick mode may produce 2/5 outputs but must tag them. + +## Execution + +Run the five steps in order. Each step has a single deliverable. + +### Step 1: List competitive alternatives + +Inventory CFD- entries that name alternatives. Include the status quo ("spreadsheet + email"), not just competitor products. Cluster into 2–4 alternative categories. + +**Deliverable**: A ranked list of competitive alternatives with rough usage volume estimates. + +### Step 2: Identify unique attributes [standard+] + +For each FEA- you ship, ask: "Does this alternative have it? At this quality?" Keep only attributes that are demonstrably *yours*. Quick mode picks the top 3. + +**Deliverable**: 3–5 attributes that are uniquely yours vs. the alternatives. + +### Step 3: Translate attributes to value + +For each attribute, write the value it creates *for the customer*. Anchor in CFD- evidence (interview quotes, beta data, usage metrics). Mark each value claim with a confidence score. + +**Deliverable**: An attribute → value table with evidence and confidence per row. + +### Step 4: Identify customers who care a lot + +Cross-reference the value claims against your PER- personas. Which persona's pains are *most* addressed by your unique values? That is your best-fit segment. Write a "best-fit characteristics" list (firmographics, behaviors, triggers). + +**Deliverable**: One sharpened best-fit PER- variant with "ideal customer" characteristics. + +### Step 5: Pick a market category + +Choose the **frame of reference** — the category that puts your strengths at the center and is meaningful to your best-fit customer. Test against three checks: +- Does it make the value claims feel inevitable? +- Does it disqualify alternatives that aren't a good fit? +- Would your best-fit customer recognize the category name? + +**Deliverable**: One category claim ("we are the X for Y who need Z") and a one-paragraph positioning statement. + +### Step 6: Trends [deep only] + +If a current market trend reinforces the positioning (e.g., "AI-native", "compliance-first"), name it. Otherwise skip — trends without product fit are noise. + +**Deliverable** (deep mode): One sentence connecting the positioning to a current trend, with citation. + +## Output Template + +``` +GTM-XXX: Positioning Statement +Type: Positioning +Owner: Founder / Product Marketing +Status: Ready + +Best-fit segment: PER-XXX (sharpened — see characteristics below) +Category: [the frame of reference, e.g., "Conversion-rate optimization platform"] +Statement: + For [best-fit customer] + Who [trigger / pain] + [Product name] is the [category] + That [unique value] + Unlike [primary alternative], we [unique attribute → value]. + +Best-fit characteristics: + - [Firmographic 1] + - [Behavior 1] + - [Trigger 1] + +Competitive alternatives considered: CFD-001, CFD-002, CFD-003 +Unique attributes: FEA-001, FEA-005, FEA-008 +Value claims (with evidence): + - [Attribute] → [Value] (CFD-XXX, confidence: X/5) + +Linked IDs: PER-XXX (best-fit), CFD-XXX (alternatives + interviews), FEA-XXX (attributes), BR-POS-XXX (rules) +``` + +``` +BR-POS-XXX: Positioning Rule +Type: Constraint +Status: Active + +Rule: [What this rule says, e.g., "We do not market to enterprise procurement teams"] +Rationale: [Why — usually traces to the best-fit segment OR a positioning attribute] +Enforced by: + - GTM-* messaging skills (no enterprise language) + - Offer Construction (no procurement-friendly contract terms) + - Launch Channels (no Gartner/analyst channels in launch wave) +``` + +## Anti-Patterns + +| Pattern | Signal | Fix | +|---------|--------|-----| +| **Feature-list positioning** | "We have X, Y, Z" | Translate each to value (step 3); cut what doesn't translate | +| **Aspirational alternatives** | Only listing competitors as alternatives | Include status quo and non-purchase ("spreadsheet + manual") | +| **Best-fit = everyone** | "We're for SMBs and enterprise and individual users" | Pick one; the others become "not for us" | +| **Category claim too broad** | "We're the platform for X" (where X is huge) | Tighten the frame of reference until it disqualifies bad-fit buyers | +| **No evidence in step 3** | Value claims with confidence 1/5 across the board | Stop and run more interviews before launching | +| **Skipping step 1** | "Our positioning is..." without alternatives discussion | Step 1 is mandatory — positioning without alternatives is internal monologue | + +## Quality Gates + +Before proceeding to Offer Construction: + +- [ ] All 5 steps have a deliverable (Step 6 optional, deep only) +- [ ] Best-fit segment is one sharpened PER- (not 3 personas) +- [ ] At least 3 competitive alternatives listed (including status quo) +- [ ] At least 3 unique attributes, each with a value translation +- [ ] Each value claim has CFD- evidence and confidence ≥ 2/5 (standard) or ≥ 3/5 (deep) +- [ ] One positioning statement and one category claim, both ≤ 3 sentences +- [ ] At least one BR-POS-* rule encoded (a "we do not" constraint) + +## Downstream Connections + +| Consumer | What it uses | Example | +|----------|--------------|---------| +| **Offer Construction (Hormozi)** | Best-fit segment + value claims | Hormozi's value equation anchors on the value claims here | +| **Launch Channels (ORB)** | Best-fit characteristics + category claim | Channel selection must reach the sharpened best-fit segment | +| **Launch Metrics** | Positioning statement = KPI- attribution baseline | "Did messaging at category X drive signups?" | +| **v1.0 Crossing the Chasm (Moore)** | Best-fit segment = beachhead anchor | Moore's "bowling-alley beachhead" = Dunford's best-fit | + +## Detailed References + +- April Dunford, *Obviously Awesome: How to Nail Product Positioning* (2019) — canonical source +- Dunford's blog: [aprildunford.com/positioning](https://aprildunford.com) +- (No bundled `references/` — read the book for depth) diff --git a/.claude/skills/prd-v10-case-study-builder/SKILL.md b/.claude/skills/prd-v10-case-study-builder/SKILL.md new file mode 100644 index 0000000..2c71b10 --- /dev/null +++ b/.claude/skills/prd-v10-case-study-builder/SKILL.md @@ -0,0 +1,230 @@ +--- +name: prd-v10-case-study-builder +description: > + Build customer case studies as marketing and chasm-crossing reference assets during PRD v1.0 + Market Adoption. Triggers on requests to build case studies, produce customer stories, create + reference content, or when user asks "build a case study", "customer story", "reference + account", "case study interview", "before/after story", "social proof page", "logo wall". + Outputs CFD-CASE-* evidence entries, GTM-CASE-* marketing assets, and updates ADO-REF-* with + story status. +context: fork +allowed-tools: + - Read + - Write + - Edit + - Glob + - Grep + +execution_modes: + default: standard + supports: [quick, standard, deep] +--- + +# Case Study Builder + +Position in workflow: v1.0 Mom Test Interview → **v1.0 Case Study Builder** → v1.0 Testimonial Collector, GTM channels + +## Execution Mode + +Default is **standard**. See [`.claude/rules/08-skill-execution-modes.md`](../../rules/08-skill-execution-modes.md) for selection logic. + +| Mode | What this skill produces | +|------|--------------------------| +| **quick** | Short-format case (testimonial + 1-paragraph story + logo); single placement | +| **standard** | Full case study (1,500 words) + short and medium derivatives + customer-approved + 3 channel placements | +| **deep** | Long-form case (2,500–4,000 words) + multi-format derivatives (PDF, blog, video, conference talk) + measurable outcome quantified + outcome-attribution interview | + +## What This Does + +Turns customer success — already documented as CFD-* evidence and ADO-REF-* candidates — into structured **case studies**. Case studies are the pragmatist buyer's #1 reference signal: they need to see a customer in their segment achieving the outcome they want, with enough detail to make it credible. + +This is an **operational** "doing" skill, not a strategy skill. The strategic question (which segment, what story angle, what outcome to highlight) was answered by [prd-v10-chasm-adoption-moore](../prd-v10-chasm-adoption-moore/SKILL.md). This skill produces the artifact. + +## How It Works + +1. **Identify candidate customers** — Pull from ADO-REF-* candidates and CFD-* entries with strong outcome quantification. Must satisfy: + - In-beachhead (or in an adjacent segment where the story would still resonate) + - Has a quantifiable outcome to talk about + - Willing to be public (consent path is clear) +2. **Run the case-study interview** — Extended Mom Test interview (45–60 min), focused on: + - Before-state (specific past: what life was like, what tools, what cost) + - Trigger (what changed; why they evaluated alternatives) + - Evaluation (who they considered; how they chose) + - Implementation (what happened in onboarding; what was hard) + - After-state (specific present: quantified outcome, time/money saved, what they can do now they couldn't) +3. **Structure the story** — Situation → Complication → Question → Resolution (the McKinsey SCQR pattern): + - **Situation**: where they were before + - **Complication**: what broke / changed / hit a wall + - **Question**: what they needed to figure out + - **Resolution**: how they solved it (your product as one part of the answer, ideally credibly) +4. **Quantify outcome** — Specific numbers beat vague claims: + - "Cut tier-selection time from 3 days to 30 minutes" beats "much faster" + - "Saved $12k/year on tool consolidation" beats "saves money" + - "85% activation rate (industry average 35%)" beats "great activation" +5. **Get customer review** — Send draft to customer for accuracy + tone + legal. Iterate until approved. +6. **Produce in 3 formats**: + - **Short** (testimonial — 1–2 sentences + name + role + logo): for landing pages, pricing page, ad creative + - **Medium** (1-paragraph + 3 bullet outcomes + logo + linked deeper): for "Customers" page, social, email + - **Long** (1,500–2,500 word case study): for blog, sales enablement, sales call followup + +## Example + +Customer: Acme Logistics (beachhead segment: freight forwarders, 50-200 employees, US PNW). ADO-REF-002. + +**Interview**: 50 minutes with Acme's VP Operations. + +**Quantified outcome**: +- Tier-selection time: 3 days → 30 min (90% reduction) +- Annual savings from tool consolidation: $14k +- Onboarding time per new hire: 2 weeks → 3 days (after migrating to product) + +**SCQR**: +- **Situation**: Acme used 4 disjointed tools to track shipments, with manual export every Friday for ops reporting +- **Complication**: Two new hires + a Q3 customer surge meant the manual export bottlenecked the team; ops director was working Saturdays to keep the dashboards current +- **Question**: How could Acme consolidate tooling without disrupting an in-flight Q4 customer onboarding? +- **Resolution**: Acme migrated to [product] over 3 weeks; consolidated 4 tools to 1; automated the Friday export. VP Operations reclaimed 6 hours/week. New hires onboard in 3 days instead of 2 weeks. + +**Three formats produced**: +- **Short**: *"We replaced 4 tools with [product] and cut new-hire onboarding from 2 weeks to 3 days." — [Name], VP Ops, Acme Logistics* +- **Medium**: 1-paragraph + 3 bullet outcomes + Acme logo + "Read the full story →" +- **Long**: 1,800-word blog case study with screenshots, quotes, before/after metrics, and an embedded testimonial video. + +## What You Get Back + +- **CFD-CASE-\* entries** — One per case-study interview; the durable evidence record +- **GTM-CASE-\* entries** (one per produced format) — Marketing assets with placement plan +- **Updates to ADO-REF-\* entries** — Reference status: "draft pending" → "approved" → "published" +- **Customer approval record** — Signed approval + version-controlled draft history + +## When to Use It + +| Trigger | Mode | +|---------|------| +| First reference customer in beachhead is ready to talk | standard | +| Chasm-crossing push needs 3+ in-segment case studies | deep | +| Pricing-page logo wall expansion | quick (short format only) | +| Sales enablement asset for new segment | standard | +| Investor / partner update | standard | +| Customer success milestone (e.g., 1-year anniversary) | quick | + +Do **not** use for: customers outside beachhead during chasm crossing (their story doesn't resonate with pragmatists); customers without consent (legal risk); customers without quantifiable outcomes (story will feel vague). + +## Consumes + +- **CFD-\* customer evidence** (Mom Test discipline) — Source for candidate selection +- **ADO-REF-\* candidates** (from prd-v10-chasm-adoption-moore) — Cultivated reference targets +- **ADO-BEACHHEAD-\*** — Defines "in-segment" for case priority +- **KPI-\* outcomes** — Defines what "outcome" means; case quantification must speak to these +- **GTM-\* positioning + offer** — Tone, voice, and value claims must match positioning +- **BR-POS-\*** — Constraints (e.g., "no enterprise procurement language") + +## Produces + +- **CFD-CASE-\* entries** in `SoT/SoT.customer_feedback.md` +- **GTM-CASE-\* entries** (with Type=Case-Asset) for each produced format +- **ADO-REF-\* updates** — Status, placement, consent tracking +- **CFD-\* gaps surfaced** — If outcome can't be quantified, log as research gap + +## Output Template + +``` +CFD-CASE-XXX: Case Study — [Customer Name] +Type: Case-Study +Date: YYYY-MM-DD +Customer: [Logo / company name] +Customer fit: [In-beachhead | Adjacent segment] +Interview length: [minutes] +Interviewer: [Name] + +Quantified outcome (the proof): + Before: [Specific number / state] + After: [Specific number / state] + Delta: [%change or $ value] + Time horizon: [over what period] + +Story (SCQR): + Situation: [Where they were before] + Complication: [What changed / broke / hit a wall] + Question: [What they needed to figure out] + Resolution: [How it got solved — your product as part of the answer] + +Quotes (verbatim, approved): + - "[Quote]" — [Name, Role] + - "[Quote]" — [Name, Role] + +Customer approval: + Approved by: [Name, Role] + Approved version: vX + Date: YYYY-MM-DD + Scope: [logo only | quote | full case study | on-stage] + +Linked formats: + Short: GTM-CASE-AAA + Medium: GTM-CASE-BBB + Long: GTM-CASE-CCC + +Linked IDs: ADO-REF-XXX (cultivation), PER-YYY (segment fit), KPI-ZZZ (outcome), CFD-AAA (interview source) +``` + +``` +GTM-CASE-XXX: Case-Study Asset — [Format] +Type: Case-Asset +Format: [Short | Medium | Long] +Channel: [Landing page | Pricing page | Blog | Sales deck | Email | Ad creative] +Owner: [Person / role] +Status: [Draft | In review | Approved | Live] + +Content: [The actual asset content — quote, paragraph, full case] + +Placement plan: + - [URL or section, e.g., "/pricing — Acme logo wall, position 3"] + +Attribution: utm_campaign=case- + +Linked IDs: CFD-CASE-AAA (parent case), ADO-REF-BBB (reference account), GTM-YYY (positioning) +``` + +## Anti-Patterns + +| Pattern | Signal | Fix | +|---------|--------|-----| +| **No quantified outcome** | "Customer loves us!" | Specific numbers or skip; vague cases don't move pragmatists | +| **Wrong segment** | Featuring a startup case to a pragmatist enterprise audience | In-segment cases only during chasm crossing | +| **No customer approval on record** | Published with assumed approval | Always get signed approval; preserve version history | +| **Marketing voice override** | Customer's actual words rewritten into your marketing tone | Their voice; light edits for clarity only | +| **Single-format publish** | Long-form blog only | Three formats: short for placement, medium for browsing, long for depth | +| **One-and-done** | Case study published, never updated | Refresh quarterly with new outcome data; cases stale fast | +| **Featuring failures-rebranded-as-wins** | "We rebuilt their entire infrastructure" hides "we replaced a failed implementation" | Don't dress up bad stories; pragmatists smell it | + +## Quality Gates + +Before publishing: + +- [ ] Customer in-beachhead or rationale for cross-segment placement +- [ ] Outcome quantified with specific numbers +- [ ] SCQR structure complete (Situation, Complication, Question, Resolution) +- [ ] Verbatim quotes with name + role +- [ ] Customer approval on record (scope explicit) +- [ ] Three formats produced (short, medium, long) — or rationale for fewer +- [ ] Placement plan per format +- [ ] Voice matches GTM- positioning (and customer's actual words) +- [ ] BR-POS-* constraints honored + +## Downstream Connections + +| Consumer | What it uses | Example | +|----------|--------------|---------| +| **Launch Channels (ORB)** | Cases become Owned and Borrowed channel content | Blog case = Owned; co-marketing case = Borrowed | +| **Alternatives Pages** | Cases anchor "when to pick us" sections with real proof | Page references Acme case for migration-from-X story | +| **Cold Outreach (Tiered)** | Cases referenced in Touch 3 of sequences | Tier 1 outreach mentions in-segment case study | +| **Testimonial Collector** | Short-format derivatives are testimonial-shaped | Auto-eligible for testimonial walls | +| **AEO Audit** | Cases become AI-citation sources | High-traffic case pages cited by AI search | +| **Sales / Investor** | Direct asset for sales calls and investor updates | "Here's how Acme uses [product]" | + +## Detailed References + +- BrianRWagner's `case-study-builder` skill (ai-marketing-claude-code-skills) +- Joe Pulizzi, *Epic Content Marketing* (case study as content) +- Annette Franz, *Customer Understanding* (interview discipline) +- McKinsey's SCQR (Situation/Complication/Question/Resolution) framework +- (No bundled `references/` — the case study itself is the artifact) diff --git a/.claude/skills/prd-v10-chasm-adoption-moore/SKILL.md b/.claude/skills/prd-v10-chasm-adoption-moore/SKILL.md new file mode 100644 index 0000000..825d8db --- /dev/null +++ b/.claude/skills/prd-v10-chasm-adoption-moore/SKILL.md @@ -0,0 +1,217 @@ +--- +name: prd-v10-chasm-adoption-moore +description: > + Assess adoption-lifecycle stage, plan the chasm crossing, and build a beachhead strategy using + Geoffrey Moore's Crossing the Chasm framework during PRD v1.0 Market Adoption. Triggers on + requests to assess adoption stage, plan beachhead, cross the chasm, scale from early adopters, + or when user asks "are we in the chasm?", "crossing the chasm", "beachhead strategy", "Moore", + "whole product", "pragmatist buyers", "from early adopters to early majority". Outputs + ADO-STAGE-*, ADO-BEACHHEAD-*, ADO-WHOLE-*, ADO-REF-* entries. +context: fork +allowed-tools: + - Read + - Write + - Edit + - Glob + - Grep + - WebSearch + +execution_modes: + default: deep + supports: [quick, standard, deep] +--- + +# Crossing the Chasm (Moore) — the v1.0 Spine + +Position in workflow: v0.9 Feedback Loop Setup → **v1.0 Crossing the Chasm (Moore)** → all v1.0 work + +## Execution Mode + +Default is **deep** (this is a major strategic decision; quick mode is for hypothesis pre-work only). See [`.claude/rules/08-skill-execution-modes.md`](../../rules/08-skill-execution-modes.md). + +| Mode | What this skill produces | +|------|--------------------------| +| **quick** | Stage assessment only (ADO-STAGE-*); beachhead candidate hypothesis | +| **standard** | Stage assessment + beachhead segment + top 3 whole-product gaps + reference-account candidate list | +| **deep** (default) | Full stage assessment with evidence + sharpened beachhead with in/not-in criteria + complete whole-product gap analysis + reference-account cultivation plan + chasm-crossing risk register | + +## Framework: Moore's Technology Adoption Lifecycle + +From *Crossing the Chasm* (Geoffrey Moore, 1991, updated 2014). The bestselling tech-strategy book of the 1990s, and still the canonical model for understanding why early traction doesn't predict mass adoption. + +### The lifecycle + +| Stage | % of market | Buyer mindset | What they buy | +|-------|-------------|---------------|----------------| +| **Innovators** (2.5%) | Tinkerers; technology enthusiasts | Want to try new things; tolerate incomplete products | Vision, technical depth, access | +| **Early Adopters** (13.5%) | Visionaries | Want strategic advantage from non-mainstream tech | Bold vision + first-mover ROI | +| **— THE CHASM —** | — | — | — | +| **Early Majority** (34%) | Pragmatists | Want reliable productivity gains from proven solutions | **Whole product** + segment-specific references | +| **Late Majority** (34%) | Conservatives | Want safe, mature defaults | Market leadership, low risk | +| **Laggards** (16%) | Skeptics | Resist change | (Generally not worth targeting) | + +### The chasm + +The gap between **Early Adopters** and **Early Majority** is the chasm. Most products die here. The reason: visionary buyers (who got you to early traction) actively *want* the cutting-edge, while pragmatist buyers want to be the second penguin off the iceberg — they need to see peers in their segment succeeding first. + +### The chasm-crossing playbook + +1. **Pick a beachhead segment** — A single, narrowly-defined sub-segment of the early majority. Not "small businesses." Specific: "freight-forwarding firms with 50-200 employees in the US Pacific Northwest using ERP X." +2. **Build the whole product for that beachhead** — Pragmatists don't buy your core product; they buy your core + integrations + reference customers + support + training + everything else they need to deploy. Identify and close the gaps. +3. **Cultivate references in segment** — A reference from outside the beachhead is worthless to a beachhead buyer. Three references *inside* the beachhead is the unlock. +4. **Concentrate, then expand** — Don't try to cross the chasm broadly. Win the beachhead, then use it as a reference base to win adjacent segments ("bowling alley" stage). + +## Consumes + +- **CFD-\* customer evidence** (all stages, especially v0.9 post-launch feedback) — Composition of paying customers; stage signal +- **PER-\* personas** (sharpened by v0.9 Positioning) — Beachhead is a sharper variant of an existing PER- +- **GTM-\* positioning** (from v0.9 Positioning) — Best-fit segment is the *starting point* for beachhead selection; beachhead is usually tighter +- **GTM-\* offer card** (from v0.9 Offer Construction) — Offer must match beachhead expectations (pragmatists need different guarantees than visionaries) +- **FEA-\* features** (from v0.3) — Whole-product gap analysis cross-references current feature set +- **KPI-\* baseline metrics** (from v0.3 + v0.9) — Stage assessment uses retention shape, NPS by segment, conversion rate +- **BR-PRICING-\*** (from v0.3 + v0.9) — Pragmatist buyers expect different pricing/contract terms than visionaries + +## Produces + +- **ADO-STAGE-\* entries** in `SoT/SoT.ADOPTION.md` — Current adoption-stage assessment with evidence +- **ADO-BEACHHEAD-\* entries** — Beachhead segment definition with strict in/not-in criteria +- **ADO-WHOLE-\* entries** — Whole-product gaps (one per gap, with owner and close date) +- **ADO-REF-\* entries** — Reference-account targets (one per candidate, with consent + placement status) +- **CFD-\* gaps surfaced** — When stage evidence is thin or beachhead selection lacks data, log as research gaps + +## Execution + +### Step 1: Assess current adoption stage + +Audit current paying-customer composition. For each customer, classify by stage indicators: + +| Indicator | Innovator/Early Adopter | Early Majority | +|-----------|------------------------|-----------------| +| Sales motion | Direct founder relationship | Asked for demo / pricing / case studies | +| Setup tolerance | "I'll figure it out" | "Show me the integration with X" | +| Reference need | None | Asked "who else in my industry uses this?" | +| Renewal motivation | "We're betting on this" | "It saves us $X/month" | +| Procurement | Single buyer | Procurement / SOC2 / contracts review | + +Stage signal: +- **Innovators / Early Adopters**: >70% of paid customers show visionary indicators +- **At the chasm**: Mixed composition; new inbound asking pragmatist questions ("references", "integrations", "SOC2"); flat MRR despite growing leads +- **Bowling Alley** (post-chasm): >50% of new customers in one identifiable segment +- **Tornado**: Rapid acquisition across multiple segments +- **Main Street**: Stable growth, focus on expansion and retention + +**Deliverable**: One ADO-STAGE-* entry with evidence, stage classification, and confidence score. + +### Step 2: Pick the beachhead segment [standard+] + +Generate 3–5 candidate beachhead segments. Score each: + +| Criterion | Question | Weight | +|-----------|----------|--------| +| **Pragmatist density** | Is this segment mostly pragmatists (already buying mature solutions)? | High | +| **Whole-product proximity** | How close is our current product to the segment's whole-product expectation? | High | +| **Reference accessibility** | Can we get 3 references in this segment within 6 months? | High | +| **Compelling reason to buy** | Is there an urgent, segment-specific pain we solve uniquely? | High | +| **Adjacency value** | If we win this segment, what adjacent segments unlock? | Medium | +| **Competitive intensity** | How saturated is this segment with established competitors? | Medium | +| **Market size** | Is this segment large enough to support a beachhead? | Low (most beachheads are small; that's fine) | + +Pick the top-scoring segment. Write strict **in-segment** and **not in-segment** criteria. + +**Deliverable**: One ADO-BEACHHEAD-* entry with in/not-in criteria, rationale, target (e.g., "10 closed-won in segment within 6 months"), confidence. + +### Step 3: Whole-product gap analysis + +For the beachhead segment, list everything a pragmatist buyer in that segment expects to receive when they pay you: + +- Core product (what you ship) +- Integrations (with their existing stack — specific) +- Compliance (SOC2, HIPAA, ISO — segment-specific) +- Support (response-time SLA, dedicated CSM if appropriate) +- Training / onboarding (videos, docs, certifications) +- References (segment-specific, named, willing to talk) +- Pricing / contract terms (annual contracts, MSAs, custom DPAs) +- Migration / data import +- Professional services (implementation help) +- Roadmap visibility + +For each, score: **Ship today? / Gap?** + +For each gap, create an ADO-WHOLE-* entry with severity (blocker / serious / nice-to-have), owner, target close date. + +**Deliverable**: List of ADO-WHOLE-* entries. Blockers must close before sustained beachhead motion. + +### Step 4: Reference-account cultivation plan [standard+] + +Identify 5–10 existing or near-term customers in the beachhead segment that could become public references. For each: + +| Field | Notes | +|-------|-------| +| Customer | Name + segment fit confirmation | +| Story strength | What outcome can they speak to publicly? (Quantified > qualitative) | +| Relationship | Who owns the relationship internally? | +| Consent path | What approval do they need internally to be public? | +| Target placement | Logo on pricing page / quote on landing / blog case study / on-stage / podcast | +| Confidence | 1–5 of "will become a reference within 90 days" | + +**Deliverable**: 5–10 ADO-REF-* entries with cultivation plan. + +### Step 5: Chasm-crossing risk register [deep only] + +For each major chasm risk, log a RISK-* entry: + +- **Reference-cold risk** — Can't get 3 references in beachhead within 6 months +- **Whole-product gap risk** — Critical gap can't be closed in time +- **Beachhead-too-small risk** — Segment doesn't sustain the company economically even if won +- **Competitor-incumbency risk** — Pragmatist defaults are competitor X; switching cost too high +- **Internal motion risk** — Sales / support / product can't pivot from visionary motion to pragmatist motion + +Each risk gets mitigation actions tied to ADO-WHOLE-*, ADO-REF-*, or BR-* updates. + +**Deliverable** (deep): Risk register with mitigations. + +## Output Templates + +See [`SoT/SoT.ADOPTION.md`](../../../SoT/SoT.ADOPTION.md) for the complete entry templates for ADO-STAGE-, ADO-BEACHHEAD-, ADO-WHOLE-, and ADO-REF-. + +## Anti-Patterns + +| Pattern | Signal | Fix | +|---------|--------|-----| +| **"We're in the chasm" without evidence** | Stage assessment based on vibes | Audit actual paying-customer composition; require ADO-STAGE-* confidence ≥ 3/5 | +| **Beachhead too broad** | "Small businesses" or "B2B SaaS" | Tighten until it disqualifies most buyers; segment of 100–10,000 prospects max | +| **Skipping whole-product gap** | "Our product is great; we just need more marketing" | Pragmatists buy whole product, not core product; list every gap | +| **Reference from wrong segment** | Touting a visionary customer to a pragmatist buyer | In-segment references only; cross-segment is worthless | +| **Crossing the chasm broadly** | "Let's just scale paid ads" | Concentrate on beachhead; broad CAC will be 5× higher and worse-converting | +| **Confusing best-fit with beachhead** | Treating Dunford best-fit as the beachhead | Beachhead is *tighter* than best-fit; usually one sub-segment of the best-fit | +| **Skipping stage assessment** | Jumping to "we need to scale" without checking where we are | Step 1 is mandatory; without it, the rest is guesswork | + +## Quality Gates + +Before proceeding to other v1.0 work: + +- [ ] ADO-STAGE-* entry exists with evidence and confidence ≥ 3/5 +- [ ] If stage is "at the chasm" or beyond: ADO-BEACHHEAD-* defined with strict in/not-in criteria +- [ ] At least 3 ADO-WHOLE-* gap entries identified (blockers + serious) +- [ ] At least 3 ADO-REF-* candidate accounts (standard+) +- [ ] RISK-* entries cover the top chasm risks (deep only) +- [ ] Beachhead does not contradict v0.9 Positioning's best-fit (or contradiction is explicit and rationalized) + +## Downstream Connections + +| Consumer | What it uses | Example | +|----------|--------------|---------| +| **Continuous Discovery (Torres)** | Beachhead segment = discovery interview pool | Weekly interviews drawn from ADO-BEACHHEAD- | +| **Mom Test Interview** | Beachhead-segment interview discipline | Validate ADO-STAGE- and ADO-WHOLE- via Mom Test | +| **Case Study Builder** | Reference candidates = case study targets | ADO-REF-* graduates to case study | +| **Testimonial Collector** | Reference candidates = testimonial targets | ADO-REF-* (lower-effort placement) | +| **v0.9 Re-runs** | Beachhead may sharpen Positioning; whole-product gaps may shift Offer | Re-run Dunford with sharper segment | +| **Feedback Loop Setup** | Pragmatist-shaped feedback signals chasm crossing | Inbound pattern shift → re-run stage assessment | + +## Detailed References + +- Geoffrey Moore, *Crossing the Chasm* (1991, revised 2014) — canonical source +- Geoffrey Moore, *Inside the Tornado* (1995) — post-chasm bowling alley / tornado / main street +- Eric Ries, *The Lean Startup* (incompatible motion before chasm; useful contrast) +- wondelai's `crossing-the-chasm` skill (wondelai/skills) +- (No bundled `references/` — read the book for depth) diff --git a/.claude/skills/prd-v10-continuous-discovery-torres/SKILL.md b/.claude/skills/prd-v10-continuous-discovery-torres/SKILL.md new file mode 100644 index 0000000..5b73276 --- /dev/null +++ b/.claude/skills/prd-v10-continuous-discovery-torres/SKILL.md @@ -0,0 +1,223 @@ +--- +name: prd-v10-continuous-discovery-torres +description: > + Establish weekly customer-discovery cadence and Opportunity Solution Tree practice using Teresa + Torres's Continuous Discovery Habits framework during PRD v1.0 Market Adoption. Triggers on + requests to set up discovery cadence, build opportunity solution tree, run weekly customer + interviews, or when user asks "Torres", "continuous discovery", "opportunity solution tree", + "outcomes vs outputs", "weekly interviews", "assumption mapping". Outputs CFD-* discovery + entries and updates to ADO-STAGE-* and PER-* with new evidence. +context: fork +allowed-tools: + - Read + - Write + - Edit + - Glob + - Grep + +execution_modes: + default: standard + supports: [quick, standard, deep] +--- + +# Continuous Discovery (Torres) + +Position in workflow: v1.0 Crossing the Chasm (Moore) → **v1.0 Continuous Discovery (Torres)** → v1.0 Mom Test, Case Study Builder + +## Execution Mode + +Default is **standard**. See [`.claude/rules/08-skill-execution-modes.md`](../../rules/08-skill-execution-modes.md) for selection logic. + +| Mode | What this skill produces | +|------|--------------------------| +| **quick** | One outcome + 3–5 opportunities + interview cadence proposal | +| **standard** | Full Opportunity Solution Tree (outcome → opportunities → solutions → assumption tests); weekly 3-interview cadence; assumption-mapping for top solution | +| **deep** | Multi-outcome tree; per-opportunity confidence scoring; full assumption tests with experiment plans; cross-discipline trio (PM/design/eng) participation rules | + +## What This Does + +Establishes **continuous discovery** as a weekly habit, not a one-time research phase. The shift from "we do research before building" to "we talk to customers every week" is what separates teams that find PMF from teams that drift. + +The work product is the **Opportunity Solution Tree** — a structured artifact that connects a measurable business outcome to opportunities (customer needs), to candidate solutions, to assumption tests. The tree is *living*: it grows and prunes as interviews accumulate. + +This skill assumes [prd-v10-mom-test-interview](../prd-v10-mom-test-interview/SKILL.md) is the discipline for *how* to interview; this skill is the discipline for *what to do with* the interviews. + +## How It Works + +1. **Define one measurable outcome** — Not an output ("ship feature X"), but an outcome ("activated users in beachhead segment grow 20% MoM"). Anchor in [ADO-STAGE-*](../prd-v10-chasm-adoption-moore/SKILL.md) and KPI-*. +2. **Set up weekly cadence** — 3+ customer interviews per week, ongoing. Not "until we feel done." Continuous. +3. **Map opportunities under the outcome** — Each opportunity is a customer pain or need (not a feature). Phrased in customer words. Grouped under the outcome. Sourced from interviews. +4. **Pick top opportunity** — Score by outcome-impact × evidence-strength × addressability. Focus on one at a time. +5. **Brainstorm solutions** — Multiple candidate solutions per opportunity. Not "the obvious one." Force divergent options. +6. **Assumption-map the top solution** — What must be true for this solution to work? Three categories: desirability (do they want it?), viability (will it grow our outcome?), feasibility (can we build it?). +7. **Test the riskiest assumption first** — Smallest experiment that disproves the assumption if it's wrong. Update tree. + +## Example + +**Outcome**: "Activated users in beachhead segment grow 20% MoM" (anchored in KPI-103 + ADO-BEACHHEAD-001). + +**Opportunities** (from 8 weekly interviews): +- O1: "I don't know what to do first when I sign up" (4 mentions) +- O2: "Integration with [our stack tool] is missing" (3 mentions, all beachhead) +- O3: "Pricing is confusing — I don't know which tier I need" (5 mentions) +- O4: "I'd recommend it but I'm afraid teammates won't get the value" (2 mentions, low confidence) + +Pick top: **O3** (highest mentions, blocks revenue conversion, addressable in product). + +**Candidate solutions** (force divergence): +- S1: Simplify to 1 tier +- S2: Pricing wizard (3 questions → recommendation) +- S3: Annotated comparison page with "most popular" anchor +- S4: Self-serve trial extended to all features + +**Top solution**: S2 (pricing wizard). + +**Assumptions** for S2: +- D1 (desirability): Users will engage with a wizard before signing up +- D2: The wizard's recommendation will feel right (no "this isn't me") +- V1 (viability): Self-selected tier through wizard → fewer downgrades +- V2: Doesn't tank conversion overall +- F1 (feasibility): Engineering can ship 3-question wizard in 2 weeks + +**Riskiest**: D1 — without engagement, nothing else matters. + +**Test for D1**: Add wizard to /pricing for 50% of traffic. Measure engagement rate. Threshold: ≥30% engage = D1 valid. If <15%, drop S2. + +## What You Get Back + +- **Opportunity Solution Tree** in `temp/_discovery-tree.md` (or harvested to UJ-/CFD- when stable) — Living structured artifact +- **CFD-\* discovery insights** (one per interview) with confidence ≥ 3/5 per the Mom Test discipline +- **CFD-\* opportunity entries** with frequency + evidence + outcome-link +- **CFD-\* assumption-test results** as experiments run +- **PER-\* / ADO-STAGE-\* / ADO-BEACHHEAD-\* updates** when discovery accumulates contradicting evidence + +## When to Use It + +| Trigger | Mode | +|---------|------| +| Post-launch standard practice | standard (ongoing) | +| Pre-chasm crossing research push | deep | +| Investigating a specific stalled metric | quick (focused on one outcome) | +| New team member onboarding to discovery | standard (with mentorship) | +| Outcome target is unclear | **stop** — go fix the outcome definition first | + +## Consumes + +- **ADO-STAGE-\* and ADO-BEACHHEAD-\*** (from prd-v10-chasm-adoption-moore) — Defines the segment to interview +- **KPI-\* outcome targets** (from v0.3 + v0.9) — Anchors the outcome at the top of the tree +- **PER-\* personas** (from v0.4 + v0.9) — Interview pool definition +- **CFD-\* existing evidence** (all prior stages) — Inputs that need fresh validation in this stage +- **GTM-\* positioning** (from v0.9) — Discovery should reveal whether positioning lands with pragmatists + +## Produces + +- **Opportunity Solution Tree** in `temp/` while active, harvested to durable IDs at EPIC close +- **CFD-\* entries** with discovery interview content (confidence 3/5+ via Mom Test discipline) +- **Updates to**: PER-* (sharpened by interviews), ADO-STAGE-* (evidence accumulation), ADO-BEACHHEAD-* (refined criteria) +- **EPIC-\* recommendations** — When an opportunity becomes high-confidence + high-impact, it becomes an EPIC candidate + +## Output Templates + +### Opportunity Solution Tree (temp/ artifact) + +``` +# Opportunity Solution Tree — [Date / EPIC] + +## Outcome +KPI-XXX: [measurable outcome statement] + +Anchored in: ADO-STAGE-AAA (stage assessment), ADO-BEACHHEAD-BBB (segment) +Time-bound: [timeframe] + +## Opportunities + +### O1: [Customer pain in their words] +- Frequency: [N interviews mention this] +- Confidence: X/5 +- Outcome-link: [How does solving this move the outcome?] +- CFD-* sources: CFD-XXX, CFD-YYY +- Status: [Active | Deprioritized | Solved] + + #### Solutions for O1 + + - S1.1: [Candidate solution] + - Outcome-impact: [Predicted lift] + - Effort: [Rough scope] + - Status: [Brainstormed | Assumption-mapped | Experimenting | Validated | Killed] + + ##### Assumptions for S1.1 + - D1 [desirability]: [Must be true about user wanting it] + - V1 [viability]: [Must be true about business impact] + - F1 [feasibility]: [Must be true about building it] + + Test plan for [riskiest assumption]: + - Experiment: [Smallest test] + - Success threshold: [Specific metric] + - Failure path: [What we do if it fails] + - Status: [Planned | Running | Result] +``` + +### CFD-* discovery entry + +``` +CFD-XXX: Discovery Interview — [interview title] +Type: Discovery-Interview +Date: YYYY-MM-DD +Interviewee segment: [PER-XXX] [in-beachhead: yes/no] +Interviewer: [Name] + +Key story (specific past behavior, not opinion): + [Mom Test-disciplined quote — what they DID, not what they THINK] + +Pain mentioned: [One concrete pain in their words] +Workaround used: [What they currently do] +Feature requests (discounted): [What they asked for — note as IDEA, not data] + +Confidence: [3/5 — qualitative single interview; 4/5 — pattern across cohort] +Linked outcomes / opportunities: [KPI-XXX, O1, O3] +Tree position: [Which opportunity this evidence supports] + +Linked IDs: PER-XXX, ADO-BEACHHEAD-XXX, KPI-XXX +``` + +## Anti-Patterns + +| Pattern | Signal | Fix | +|---------|--------|-----| +| **Discovery as project, not habit** | "We did discovery in Q1" | Weekly cadence, ongoing. Tree is living. | +| **Outcome = output** | "Outcome: ship feature X" | Outputs are what you make; outcomes are what changes for the customer/business | +| **Skipping divergent solutions** | One solution per opportunity, no alternatives considered | Force ≥3 solution candidates per opportunity | +| **Solution-first thinking** | Brainstorming features before opportunities are mapped | Tree top-down: outcome → opportunities → solutions, not reverse | +| **Treating feature requests as opportunities** | "Add dark mode" treated as a customer need | That's a solution; the opportunity is the underlying job | +| **No assumption test before building** | "We'll just ship it and see" | At least one assumption test (smallest experiment) before significant engineering | +| **Solo discovery** | One PM doing all interviews; eng/design unaware | Continuous discovery is a *trio* practice (PM + design + eng); rotating attendance | + +## Quality Gates + +For ongoing discovery to count: + +- [ ] 3+ customer interviews per week (standard cadence) +- [ ] Outcome (not output) at top of tree +- [ ] Opportunities phrased in customer words with frequency data +- [ ] One opportunity is "active" focus at a time +- [ ] Top solution has assumption map (D/V/F) before engineering work begins +- [ ] Riskiest assumption has a planned test +- [ ] CFD-* entries follow Mom Test discipline (confidence ≥ 3/5) + +## Downstream Connections + +| Consumer | What it uses | Example | +|----------|--------------|---------| +| **Mom Test Interview** | Interview discipline for the actual conversations | Every CFD-discovery entry follows Mom Test rules | +| **Case Study Builder** | High-engagement interviewees become case-study candidates | Strong CFD- → ADO-REF- → case study | +| **Chasm Adoption (Moore)** | Discovery evidence updates ADO-STAGE- and ADO-BEACHHEAD- | Pattern shifts trigger stage re-assessment | +| **EPIC-* planning** | Validated solutions become EPIC candidates | S2 wizard validated → EPIC-XX delivery | +| **Feedback Loop Setup** | Continuous discovery is the structured arm of feedback loop | Discovery = scheduled interview; feedback loop = inbound channels | + +## Detailed References + +- Teresa Torres, *Continuous Discovery Habits* (2021) — canonical source +- Teresa Torres, productchats.com (blog and tools) +- Marty Cagan, *Inspired* + *Empowered* (complementary product-leadership reading) +- wondelai's `continuous-discovery` skill (wondelai/skills) +- (No bundled `references/` — read the book for depth) diff --git a/.claude/skills/prd-v10-mom-test-interview/SKILL.md b/.claude/skills/prd-v10-mom-test-interview/SKILL.md new file mode 100644 index 0000000..648954a --- /dev/null +++ b/.claude/skills/prd-v10-mom-test-interview/SKILL.md @@ -0,0 +1,215 @@ +--- +name: prd-v10-mom-test-interview +description: > + Apply Rob Fitzpatrick's Mom Test discipline to customer interviews during PRD v1.0 Market + Adoption. Triggers on requests to interview customers, run discovery calls, validate ideas + with users, or when user asks "how do I interview customers?", "Mom Test", "Rob Fitzpatrick", + "customer interview", "user research without lies", "talking to humans", "discovery + conversation". Outputs CFD-* discovery entries with Mom Test-calibrated confidence. +context: fork +allowed-tools: + - Read + - Write + - Edit + - Glob + - Grep + +execution_modes: + default: standard + supports: [quick, standard, deep] +--- + +# Mom Test Interview Discipline + +Position in workflow: v1.0 Continuous Discovery (Torres) → **v1.0 Mom Test Interview** → v1.0 Case Study Builder, Testimonial Collector + +## Execution Mode + +Default is **standard**. See [`.claude/rules/08-skill-execution-modes.md`](../../rules/08-skill-execution-modes.md) for selection logic. + +| Mode | What this skill produces | +|------|--------------------------| +| **quick** | Single interview prep + question list + CFD-* discovery entry post-interview | +| **standard** | Interview prep + scripted opening + 5–7 questions + CFD-* entry with confidence calibration + Bad Data flagged | +| **deep** | Multi-interview cohort plan + cross-interview synthesis + pattern flagging at 3-mention threshold + assumption-test handoff | + +## Framework: The Mom Test + +From *The Mom Test: How to Talk to Customers and Learn If Your Business is a Good Idea When Everyone is Lying to You* (Rob Fitzpatrick, 2013). Premise: People lie to spare your feelings — especially about your business idea. Learn to ask questions that get truth. + +### The three Mom Test rules + +1. **Talk about their life, not your idea.** Ask about how they actually live and work, not whether they'd like your hypothetical feature. +2. **Ask about specifics in the past, not generics or opinions about the future.** "Last time you faced X, what did you do?" beats "Would you use a tool that does Y?" +3. **Talk less and listen more.** If you're talking more than 30% of the time, you're pitching, not learning. + +### Three types of Bad Data to avoid + +| Bad Data type | Example | Why it's bad | What to do | +|---------------|---------|--------------|------------| +| **Compliments** | "That sounds awesome!" | Politeness; not predictive | Discard; don't update confidence | +| **Fluff** | "I usually..." "I would probably..." | Generics, future hypotheticals | Anchor to specifics: "When did you last do that?" | +| **Ideas** | "You should add X" | Solution suggestions disguised as needs | Note as IDEA; ask "what would solving X enable you to do?" — get the underlying job | + +### Confidence calibration + +Mom Test-disciplined interviews produce **higher-confidence CFD- entries** because the data is grounded in observed past behavior, not opinion. Confidence floors per P4: + +- 2/5 — Generic statement ("I sometimes have this problem") +- 3/5 — Specific past instance ("Last Tuesday, I spent 2 hours doing X") +- 4/5 — Specific past instance + paid-money-for-a-workaround / hired-a-person / built-a-script ("I'm paying $30/mo for a tool that almost solves this") +- 5/5 — Repeated specific past instances + ongoing willingness to invest in better solution (commit > talk) + +## Consumes + +- **ADO-BEACHHEAD-\* and PER-\* personas** — Defines the interview pool; non-segment interviews are still useful but get lower weight +- **Opportunity Solution Tree** (from prd-v10-continuous-discovery-torres) — Interview goals trace to specific opportunities being tested +- **CFD-\* prior research** — Patterns to validate or contradict +- **KPI-\* outcomes** — Why we're interviewing (anchor to what we're trying to move) + +## Produces + +- **CFD-\* discovery interview entries** — One per interview, with confidence calibrated by Mom Test rules +- **CFD-\* pattern entries** — When 3+ interviews mention the same specific behavior, promote to a pattern entry with frequency +- **Bad Data inventory** — Compliments, fluff, ideas captured for context but not data +- **Discovery Tree updates** — Each interview either strengthens an opportunity, weakens an opportunity, or surfaces a new one + +## Execution + +### Step 1: Define the goal of this interview + +Not "validate the idea." Specifically: which opportunity / assumption from the Opportunity Solution Tree is this interview testing? + +| Goal | Example | +|------|---------| +| Validate opportunity exists | "Do beachhead pragmatists actually struggle with pricing-tier selection?" | +| Test assumption | "Will users engage with a pricing wizard before signup?" | +| Map workaround | "How are they solving this today?" | +| Quantify pain | "How much time/money does this cost them currently?" | + +Write the goal at the top of the interview notes. + +### Step 2: Prep the question list (Mom Test-shaped) + +Use specifics-in-the-past form. Avoid hypotheticals. + +| Bad question | Better (Mom Test) version | +|--------------|---------------------------| +| "Would you use a pricing wizard?" | "Walk me through how you picked the tier when you signed up." | +| "Do you think analytics is important?" | "Tell me about the last time you looked at analytics." | +| "What features do you wish we had?" | "Tell me about the last time the tool didn't do what you needed." | +| "How would you describe X?" | "Tell me about the last time X came up at work." | + +5–7 questions is plenty for a 25–30 minute interview. Leave room to follow threads. + +### Step 3: Run the interview + +- **Open** with a short framing: who you are, why this conversation, no sales pitch +- **Ask the past-behavior questions**, listen, follow threads +- **Probe specifics** when they generalize: "When was that specifically?" / "What was the dollar / time cost?" / "What did you do next?" +- **Flag Bad Data internally**: when they compliment, smile and move on; when they fluff, anchor to specifics; when they suggest ideas, note as IDEA and dig for the underlying job +- **Talk less than 30%** of the total minutes +- **Don't pitch.** If they ask what you're building, give a one-sentence answer and pivot back + +### Step 4: Write up the CFD-* entry within 4 hours + +Memory decays fast. Within 4 hours of the interview, write up the CFD- entry. Include: +- Verbatim quotes (the best evidence) +- Specific past instances (the gold) +- Bad Data inventory (compliments, fluff, ideas) — kept for context but not counted as data +- Confidence per P4 calibration + +### Step 5: Update the Opportunity Solution Tree [standard+] + +Did this interview: +- **Strengthen** an existing opportunity (add to frequency count)? +- **Contradict** an existing opportunity (note dissenting evidence)? +- **Surface** a new opportunity (add to tree)? + +Promote a pattern to "Active" focus when 3+ interviews mention the same specific behavior. + +### Step 6: Cross-interview synthesis [deep only] + +After every cohort of 5–8 interviews, synthesize: +- What patterns emerged at the 3+ mention threshold? +- What hypotheses were contradicted? +- What new opportunities surfaced? +- What's the next interview cohort target? + +## Output Template + +``` +CFD-XXX: Mom Test Interview — [Brief title] +Type: Discovery-Interview +Date: YYYY-MM-DD +Length: [minutes] +Interviewee: [PER-XXX + in-beachhead: yes/no] +Interviewer: [Name] +Goal: [Specific opportunity/assumption being tested] + +Specific past instances captured (the gold): + - "[Verbatim quote — describes a specific past behavior]" + Context: [When, where, what they did, what it cost] + Confidence: 3/5 or 4/5 (per P4 calibration) + +Workarounds observed: + - [What they currently do; tools/spend/time invested] + +Bad Data (logged but not counted): + - Compliments: ["That sounds awesome"] + - Fluff: ["I'd probably use that"] + - Ideas: ["You should add X"] → underlying job: [What X would enable] + +Pattern strengthening: + - O1 [opportunity]: +1 mention (now N total) + +New opportunity surfaced (if any): + - [Description] + +Overall confidence of this interview's data: X/5 +Linked IDs: PER-XXX, ADO-BEACHHEAD-XXX, KPI-XXX, Opportunity-Tree-Node +``` + +## Anti-Patterns + +| Pattern | Signal | Fix | +|---------|--------|-----| +| **Pitching disguised as interview** | Interviewer talking >40% of the time | Talk less; ask follow-ups; let silence happen | +| **Future-hypothetical questions** | "Would you use..." | Reframe to past-behavior | +| **Treating compliments as data** | "5 people said it sounds great → strong signal" | Compliments are not data; discount | +| **Recording feature requests as opportunities** | "User asked for dark mode → opportunity: dark mode" | Dark mode is a solution; the opportunity is the underlying job (e.g., late-night use, eye strain) | +| **No specifics-probe** | Interview ends without a single "what specifically" follow-up | Build the habit; specifics are the gold | +| **Writing up days later** | Interview Friday, CFD- entry Monday | Memory decays; write within 4 hours | +| **No goal for interview** | "Just talking to users" | Each interview tests one specific opportunity or assumption | +| **All interviews from outside beachhead** | Strong patterns but not in segment | In-segment interviews dominate; out-of-segment is supplementary | + +## Quality Gates + +For each interview: + +- [ ] Goal stated before interview (which opportunity/assumption is being tested) +- [ ] Question list is past-behavior shaped, not hypothetical +- [ ] Interviewer talked <30% of minutes +- [ ] At least one "what specifically" follow-up was asked +- [ ] Bad Data inventory exists (compliments / fluff / ideas — even if empty) +- [ ] CFD- entry written within 4 hours +- [ ] Confidence per P4 calibration (not "feels good") +- [ ] Discovery Tree updated (pattern strengthen / contradict / new opportunity) + +## Downstream Connections + +| Consumer | What it uses | Example | +|----------|--------------|---------| +| **Continuous Discovery (Torres)** | Every interview updates the Opportunity Solution Tree | This skill is the *how*; Torres is the *what to do with* | +| **Chasm Adoption (Moore)** | In-beachhead interviews update ADO-STAGE-* and ADO-BEACHHEAD-* | Patterns strengthen stage assessment | +| **Case Study Builder** | High-impact interviewees become case-study candidates | CFD- with 5/5 confidence + outcome → ADO-REF-* | +| **Testimonial Collector** | Strong endorsement interviews become testimonial sources | Specific past-instance quote + consent → testimonial | +| **Feedback Loop Setup** | Mom Test is the discipline for the structured-interview arm | Inbound feedback ≠ Mom Test (still useful, lower confidence) | + +## Detailed References + +- Rob Fitzpatrick, *The Mom Test* (2013) — canonical source, short and readable +- Rob Fitzpatrick, *The Workshop Survival Guide* (companion) +- Steve Portigal, *Interviewing Users* (complementary depth) +- wondelai's `mom-test` skill (wondelai/skills) +- (No bundled `references/` — read the book; it's 130 pages) diff --git a/.claude/skills/prd-v10-testimonial-collector/SKILL.md b/.claude/skills/prd-v10-testimonial-collector/SKILL.md new file mode 100644 index 0000000..7d1ce1a --- /dev/null +++ b/.claude/skills/prd-v10-testimonial-collector/SKILL.md @@ -0,0 +1,236 @@ +--- +name: prd-v10-testimonial-collector +description: > + Systematically harvest short testimonials from customers via NPS, milestones, post-purchase, + and email during PRD v1.0 Market Adoption. Triggers on requests to collect testimonials, + set up social proof harvest, gather customer quotes, or when user asks "how do we get + testimonials?", "social proof harvest", "NPS responses", "testimonial wall", "customer quotes", + "post-purchase survey", "milestone follow-up". Outputs CFD-TST-* testimonial entries and + GTM-TST-* placement assets. +context: fork +allowed-tools: + - Read + - Write + - Edit + - Glob + - Grep + +execution_modes: + default: standard + supports: [quick, standard, deep] +--- + +# Testimonial Collector + +Position in workflow: v1.0 Case Study Builder → **v1.0 Testimonial Collector** → GTM channels (placement) + +## Execution Mode + +Default is **standard**. See [`.claude/rules/08-skill-execution-modes.md`](../../rules/08-skill-execution-modes.md) for selection logic. + +| Mode | What this skill produces | +|------|--------------------------| +| **quick** | One trigger (e.g., NPS promoters) + collection email + 5–10 testimonials processed | +| **standard** | 3 triggers (NPS, milestone, post-purchase) + processing workflow + consent management + per-placement formatting | +| **deep** | 5+ triggers + automated harvest + sentiment-segmentation + per-segment placement targeting + measurement loop | + +## What This Does + +Systematically harvests **short-form testimonials** — 1–3 sentence quotes with name + role + logo — and processes them into placement-ready assets. Testimonials are the lower-effort complement to case studies: they don't carry a full story but they multiply social proof on landing pages, pricing pages, ad creative, and outreach. + +This skill solves the "we have happy customers but no quotes" problem — most teams have plenty of positive feedback in support tickets, NPS responses, and renewal calls, but never capture it as marketing-ready assets. The fix is a system, not heroic effort. + +## How It Works + +1. **Identify collection triggers** — Each trigger is an event that suggests the customer is in a moment to share positive feedback: + - **NPS Promoter response** (score 9–10) — Lowest-friction; they already wrote feedback + - **Activation milestone** (Day 30 / Day 90 active) — They've seen value by now + - **Post-purchase / post-upgrade** — Decision fresh in mind + - **Renewal** — Strong signal of ongoing value + - **Support resolution (positive)** — Acute "you saved my day" moment + - **Referral from customer** — They already advocated +2. **Build per-trigger collection mechanism**: + - NPS Promoter → automated email asking permission to use response + adding 1-question follow-up + - Milestone → in-app prompt or email with one-line ask + - Post-purchase → email 7 days after purchase + - Renewal → CSM-led ask during renewal call + - Support → followup in support thread after positive resolution +3. **Process incoming testimonials** — Each goes through: + - Consent confirmation (scope: name? role? logo? use anywhere?) + - Light edit for clarity (their voice; don't rewrite) + - Tag by segment fit (in-beachhead / adjacent / off-segment) + - Tag by outcome theme (speed / cost / activation / quality / etc.) +4. **Place in marketing surfaces** — Per testimonial: + - Pricing page (logo + quote) + - Landing page hero (1 prominent quote) + - Feature pages (segment-relevant quotes) + - Ad creative (testimonial-style ads) + - Email signatures / sales decks + - Investor decks +5. **Measure placement performance** [standard+] — Some testimonials convert; some don't. Track per-placement conversion to identify which quotes earn their spot. + +## Example + +B2B SaaS, 3 collection triggers active. + +**Trigger 1: NPS Promoter (9–10)**. +NPS run quarterly. Promoters get followup email: + +> *Thanks for the 10! Your response — "Cut our reporting time in half" — would be a powerful testimonial for our pricing page. May we use it with your name and role? Reply YES and we'll send back the version we'd publish for your approval.* + +Auto-fires when NPS response submitted with score ≥ 9. + +**Trigger 2: Day-30 active milestone**. +In-app prompt at first login after Day 30 active: + +> *You've been active for a month! In one sentence, what's working best?* → [text box] → [Submit + permission checkbox] + +**Trigger 3: Post-purchase (Day 7)**. +Email 7 days after first paid charge: + +> *Quick favor — what convinced you to upgrade? Your answer might appear (with your permission) on our pricing page.* + +**Processing**: Inbound testimonials enter a triage doc. Per testimonial: +- Consent confirmed (scope: name / role / logo / anywhere) +- Light edit (clarity only — kept their voice) +- Segment tag (in-beachhead: yes/no) +- Theme tag (speed / cost / activation / quality) +- Placement decision (pricing / landing / feature page / ad / multi) + +**Placement**: Pricing page logo wall expanded with 6 new testimonials in the beachhead segment. A/B test the hero-section quote on landing pages. + +## What You Get Back + +- **CFD-TST-\* entries** — One per testimonial; the durable record with consent, source, segment, theme +- **GTM-TST-\* entries** — Per-placement formatting (the placed quote with surrounding context) +- **Consent records** — Customer-by-customer scope and version history +- **Placement-performance log** — Per-quote conversion rate (which testimonials earn their spot) + +## When to Use It + +| Trigger | Mode | +|---------|------| +| First testimonial harvest system (none in place) | standard | +| Quarterly NPS run + harvest | quick | +| Pricing page redesign needs more social proof | standard | +| Landing page A/B test needs quote variants | quick | +| Pre-investor / pre-Series A push for logo + quote density | deep | +| New segment expansion (need segment-specific testimonials) | deep | + +## Consumes + +- **CFD-\* customer feedback** (all sources, especially v0.9 feedback loop) — Raw inbound testimonial material +- **NPS / CSAT data** (from v0.9 Feedback Loop Setup) — Promoter responses are the highest-yield source +- **ADO-REF-\* candidates** — Reference accounts already in cultivation are testimonial-eligible +- **PER-\* personas** + **ADO-BEACHHEAD-\*** — Segment tagging +- **BR-POS-\*** — Tone constraints; testimonials shouldn't contradict positioning + +## Produces + +- **CFD-TST-\* entries** in `SoT/SoT.customer_feedback.md` +- **GTM-TST-\* entries** (with Type=Testimonial-Placement) per placement +- **Consent records** — Append-only log with scope and version +- **Placement-performance metrics** — Per-quote A/B data feeding back into selection + +## Output Template + +``` +CFD-TST-XXX: Testimonial — [Customer name] +Type: Testimonial +Date received: YYYY-MM-DD +Source trigger: [NPS-promoter | Day-30-milestone | Post-purchase | Renewal | Support | Referral] +Customer: [Name, Role, Company, Logo] + +Verbatim text: + "[The actual quote, lightly edited for clarity only]" + +Original text (for audit): + "[The raw response]" + +Tags: + Segment fit: [In-beachhead | Adjacent | Off-segment] + Theme: [Speed | Cost | Activation | Quality | Reliability | Specific-use-case] + Length: [Words / chars] + +Consent: + Scope: [Name? Role? Logo? Use-anywhere?] + Approved by: [Customer name] + Approved date: YYYY-MM-DD + Approved version: vX + +Placement eligibility: + - Pricing page logo wall: [Yes/No] + - Landing page hero: [Yes/No] + - Feature page (which): [Yes/No] + - Ad creative: [Yes/No] + - Sales deck: [Yes/No] + - Investor deck: [Yes/No] + +Linked IDs: PER-XXX (segment), ADO-REF-YYY (if cultivated), CFD-ZZZ (interview source if applicable) +``` + +``` +GTM-TST-XXX: Testimonial Placement — [Quote summary] +Type: Testimonial-Placement +Source: CFD-TST-AAA +Placement: [URL or surface, e.g., "/pricing — hero zone"] +Format: [Quote + Name + Role + Logo | Quote + Logo only | Quote in card] + +Surrounding context: + [What this testimonial sits next to — headline, CTA, product feature] + +A/B test (if active): + Variant A: [This testimonial] + Variant B: [Alternative] + Metric: [Click-through, signup-rate, etc.] + Started: YYYY-MM-DD + +Performance (if measured): + [Per-quote conversion data] + +Linked IDs: CFD-TST-AAA (source), GTM-YYY (page channel), KPI-ZZZ (placement metric) +``` + +## Anti-Patterns + +| Pattern | Signal | Fix | +|---------|--------|-----| +| **Heroic one-time harvest** | "We collected 20 testimonials in a sprint, then stopped" | Triggers run continuously; harvest is a system, not a project | +| **No consent record** | Publishing without explicit approval | Consent record per testimonial, scope-explicit | +| **Marketing rewrite** | "I love [product]" rewritten from "It's pretty useful" | Light edits for clarity only; their voice | +| **No segment tagging** | All testimonials placed everywhere | Segment-relevant placement converts better; tag and target | +| **Stale walls** | Pricing page testimonials from 2 years ago | Refresh quarterly; rotate underperformers | +| **No placement measurement** | All testimonials treated as equally good | Some quotes convert 3× others; measure and prune | +| **Anonymous testimonials** | "VP at major fintech" with no name/logo | Pragmatists discount anonymous; named + logo or skip | +| **Off-segment testimonials during chasm crossing** | Visionary-startup quotes on a page targeting enterprise pragmatists | In-segment placements only during chasm crossing | + +## Quality Gates + +Before placing testimonials: + +- [ ] Consent on record (scope explicit) +- [ ] Customer name + role + logo (or rationale for less) +- [ ] Segment tag applied +- [ ] Theme tag applied +- [ ] Light edit only (their voice preserved) +- [ ] Placement matches segment fit (in-beachhead testimonials for pragmatist surfaces) +- [ ] BR-POS-* constraints honored (no contradiction with positioning) +- [ ] Refresh cadence committed (quarterly minimum) + +## Downstream Connections + +| Consumer | What it uses | Example | +|----------|--------------|---------| +| **Launch Channels (ORB)** | Testimonials are Owned-channel content + Borrowed-channel ad creative | Pricing-page testimonials = Owned; testimonial-style ads = Paid-Borrowed | +| **Alternatives Pages** | "Pick us if..." sections feature segment-relevant testimonials | Migration-from-X testimonial anchors the alt page | +| **Case Study Builder** | Strong testimonials surface case-study candidates | Repeat testimonialer with strong outcome → case study | +| **Cold Outreach (Tiered)** | Testimonials cited in Touch 2/3 of sequences | Tier 2 email includes in-segment testimonial | +| **Feedback Loop Setup** | Testimonial sources tie back to feedback channels | NPS promoters feed both feedback and testimonial flow | +| **Investor / Sales decks** | Logo wall + theme-curated testimonials | "Customers in segment X say..." | + +## Detailed References + +- BrianRWagner's `testimonial-collector` skill (ai-marketing-claude-code-skills) +- Sean D'Souza, *The Brain Audit* (using testimonials to overcome buying objections) +- Joanna Wiebe, Copy Hackers — testimonial-driven landing pages +- (No bundled `references/` — testimonials are the artifact) diff --git a/.claude/skills/skills-inventory.md b/.claude/skills/skills-inventory.md index c1e90bc..84ad1ca 100644 --- a/.claude/skills/skills-inventory.md +++ b/.claude/skills/skills-inventory.md @@ -28,14 +28,29 @@ | **v0.7 Build Execution** | [Epic Scoping](#skill-epic-scoping) | ✅ Ready | [`prd-v07-epic-scoping/`](prd-v07-epic-scoping/) | | **v0.7 Build Execution** | [Test Planning](#skill-test-planning) | ✅ Ready | [`prd-v07-test-planning/`](prd-v07-test-planning/) | | **v0.7 Build Execution** | [Implementation Loop](#skill-implementation-loop) | ✅ Ready | [`prd-v07-implementation-loop/`](prd-v07-implementation-loop/) | -| **v0.8 Release & Deployment** | [Release Planning](#skill-release-planning) | ✅ Ready | [`prd-v08-release-planning/`](prd-v08-release-planning/) | -| **v0.8 Release & Deployment** | [Runbook Creation](#skill-runbook-creation) | ✅ Ready | [`prd-v08-runbook-creation/`](prd-v08-runbook-creation/) | -| **v0.8 Release & Deployment** | [Monitoring Setup](#skill-monitoring-setup) | ✅ Ready | [`prd-v08-monitoring-setup/`](prd-v08-monitoring-setup/) | -| **v0.9 Launch** | [GTM Strategy](#skill-gtm-strategy) | ✅ Ready | [`prd-v09-gtm-strategy/`](prd-v09-gtm-strategy/) | -| **v0.9 Launch** | [Launch Metrics](#skill-launch-metrics) | ✅ Ready | [`prd-v09-launch-metrics/`](prd-v09-launch-metrics/) | -| **v0.9 Launch** | [Feedback Loop Setup](#skill-feedback-loop-setup) | ✅ Ready | [`prd-v09-feedback-loop-setup/`](prd-v09-feedback-loop-setup/) | -| **Methodology** | [SoT Builder](#skill-sot-builder) | ✅ Ready | [`ghm-sot-builder/`](ghm-sot-builder/) | -| **Methodology** | [Template Sync](#skill-template-sync) | ✅ Ready | [`ghm-template-sync/`](ghm-template-sync/) | +| **v0.8 Release & Deployment** | Release Planning | ✅ Ready | [`prd-v08-release-planning/`](prd-v08-release-planning/) | +| **v0.8 Release & Deployment** | Runbook Creation | ✅ Ready | [`prd-v08-runbook-creation/`](prd-v08-runbook-creation/) | +| **v0.8 Release & Deployment** | Monitoring Setup | ✅ Ready | [`prd-v08-monitoring-setup/`](prd-v08-monitoring-setup/) | +| **v0.8 Release & Deployment** | Changelog-as-Marketing | ✅ Ready | [`prd-v08-changelog-as-marketing/`](prd-v08-changelog-as-marketing/) | +| **v0.8 Release & Deployment** | Drift Baseline/Compare | ✅ Ready | [`prd-v08-drift-baseline-compare/`](prd-v08-drift-baseline-compare/) | +| **v0.8 Release & Deployment** | Marketing-Ops Handoff | ✅ Ready | [`prd-v08-marketing-ops-handoff/`](prd-v08-marketing-ops-handoff/) | +| **v0.9 Launch** | GTM Strategy (orchestrator) | ✅ Ready | [`prd-v09-gtm-strategy/`](prd-v09-gtm-strategy/) | +| **v0.9 Launch** | Positioning (Dunford) | ✅ Ready | [`prd-v09-positioning-dunford/`](prd-v09-positioning-dunford/) | +| **v0.9 Launch** | Offer Construction (Hormozi) | ✅ Ready | [`prd-v09-offer-construction-hormozi/`](prd-v09-offer-construction-hormozi/) | +| **v0.9 Launch** | Launch Channels (ORB) | ✅ Ready | [`prd-v09-launch-channels-orb/`](prd-v09-launch-channels-orb/) | +| **v0.9 Launch** | AEO Audit | ✅ Ready | [`prd-v09-aeo-audit/`](prd-v09-aeo-audit/) | +| **v0.9 Launch** | Alternatives Pages | ✅ Ready | [`prd-v09-alternatives-pages/`](prd-v09-alternatives-pages/) | +| **v0.9 Launch** | Cold Outreach (Tiered) | ✅ Ready | [`prd-v09-cold-outreach-tiered/`](prd-v09-cold-outreach-tiered/) | +| **v0.9 Launch** | HN + Reddit Launch | ✅ Ready | [`prd-v09-hn-reddit-launch/`](prd-v09-hn-reddit-launch/) | +| **v0.9 Launch** | Launch Metrics | ✅ Ready | [`prd-v09-launch-metrics/`](prd-v09-launch-metrics/) | +| **v0.9 Launch** | Feedback Loop Setup | ✅ Ready | [`prd-v09-feedback-loop-setup/`](prd-v09-feedback-loop-setup/) | +| **v1.0 Market Adoption** | Crossing the Chasm (Moore) — the spine | ✅ Ready | [`prd-v10-chasm-adoption-moore/`](prd-v10-chasm-adoption-moore/) | +| **v1.0 Market Adoption** | Continuous Discovery (Torres) | ✅ Ready | [`prd-v10-continuous-discovery-torres/`](prd-v10-continuous-discovery-torres/) | +| **v1.0 Market Adoption** | Mom Test Interview (Fitzpatrick) | ✅ Ready | [`prd-v10-mom-test-interview/`](prd-v10-mom-test-interview/) | +| **v1.0 Market Adoption** | Case Study Builder | ✅ Ready | [`prd-v10-case-study-builder/`](prd-v10-case-study-builder/) | +| **v1.0 Market Adoption** | Testimonial Collector | ✅ Ready | [`prd-v10-testimonial-collector/`](prd-v10-testimonial-collector/) | +| **Methodology** | SoT Builder | ✅ Ready | [`ghm-sot-builder/`](ghm-sot-builder/) | +| **Methodology** | Template Sync | ✅ Ready | [`ghm-template-sync/`](ghm-template-sync/) | **Legend:** ✅ Ready = SKILL.md complete | 📋 Spec = specification below, needs implementation diff --git a/PRD.md b/PRD.md index 910d855..c7c4801 100644 --- a/PRD.md +++ b/PRD.md @@ -310,39 +310,89 @@ For each deployment target (web, mobile, API), document: ## v0.9 Go-to-Market — Launch & Feedback -> **ID Note**: GTM-XXX (Go-to-Market) IDs are defined inline in this section, not in a separate SoT file. +> **ID Note**: GTM-XXX (Go-to-Market) IDs are defined inline in this section, not in a separate SoT file. GTM- entries are typed: `Positioning`, `Offer`, `Guarantee`, `Channel`, `Sequence`, `Index`, `AEO`, `OUT` (outreach), `CHG` (changelog), `MOPS` (marketing-ops), `CASE`, `TST` (testimonial). +> **Skills**: v0.9 runs as a chained workflow — `prd-v09-positioning-dunford` → `prd-v09-offer-construction-hormozi` → `prd-v09-launch-channels-orb`, orchestrated by `prd-v09-gtm-strategy`. Tactical playbooks (`aeo-audit`, `alternatives-pages`, `cold-outreach-tiered`, `hn-reddit-launch`) attach to specific channels. -**Launch Plan Summary** +**Positioning** (from `prd-v09-positioning-dunford`, Dunford 5-step) -- Channels: {Email / Sales / Community} -- Messaging Pillars: {1-3 bullets} -- Launch Owner: {Name / Team} +- Best-fit segment: PER-### (sharpened) +- Category claim: {frame of reference} +- Positioning statement: GTM-### +- Positioning rules: BR-POS-### + +**Offer** (from `prd-v09-offer-construction-hormozi`) + +- Core promise: {one-sentence outcome} +- Stack value vs price: {ratio ≥ 3:1} +- Guarantee: GTM-### (Type=Guarantee) + +**Launch Channels** (from `prd-v09-launch-channels-orb`, Owned/Rented/Borrowed) + +- Owned: GTM-### +- Rented: GTM-### +- Borrowed: GTM-### +- Channel-mix matrix: GTM-### (Type=Sequence) + +**Tactical Plays Active** + +- AEO/AI search: GTM-AEO-### (from `prd-v09-aeo-audit`) +- Alternatives pages: SCR-ALT-### (from `prd-v09-alternatives-pages`) +- Cold outreach tiers: GTM-OUT-### (from `prd-v09-cold-outreach-tiered`) +- HN / Reddit launch: GTM-### Type=Channel-HN / Channel-Reddit (from `prd-v09-hn-reddit-launch`) **Analytics & Feedback Loop** -- Key Metrics: {Metric + target} -- Feedback Sources: {CFD-###, analytics dashboards} +- Launch metrics: KPI-### (from `prd-v09-launch-metrics`) +- Feedback sources: CFD-###, analytics dashboards +- Reconciliation: GTM-### (Type=Index, by `prd-v09-gtm-strategy` orchestrator) **Outstanding Work → v1.0** -- {Adoption / revenue milestone} +- {Adoption stage assessment readiness} +- {Beachhead candidate hypothesis} --- -## v1.0 Market Adoption — Optimize & Expand +## v1.0 Market Adoption — Crossing the Chasm + +> **Spine**: This stage runs on Geoffrey Moore's *Crossing the Chasm*. See [`SoT/SoT.ADOPTION.md`](SoT/SoT.ADOPTION.md) for the full ADO- entry registry. +> **ID Note**: ADO-XXX (Adoption) IDs are defined in `SoT/SoT.ADOPTION.md` (not inline). Sub-types: `ADO-STAGE-`, `ADO-BEACHHEAD-`, `ADO-WHOLE-`, `ADO-REF-`. + +**Adoption Stage Assessment** (from `prd-v10-chasm-adoption-moore`) + +- Current stage: ADO-STAGE-### → {Innovators / Early Adopters / At the Chasm / Bowling Alley / Tornado / Main Street} +- Evidence: {Paying-customer composition + interview cohort} +- Confidence: X/5 + +**Beachhead Strategy** (when at or beyond the chasm) + +- Beachhead segment: ADO-BEACHHEAD-### +- Whole-product gaps: ADO-WHOLE-### (blockers + serious) +- Reference accounts in cultivation: ADO-REF-### (count + status) + +**Discovery + Validation** (continuous) + +- Discovery cadence: 3+ interviews/week via `prd-v10-continuous-discovery-torres` + `prd-v10-mom-test-interview` +- Opportunity Solution Tree: `temp/_discovery-tree.md` (harvested to CFD-/UJ-/ADO- at EPIC close) + +**Social Proof Production** + +- Case studies: CFD-CASE-### + GTM-CASE-### (from `prd-v10-case-study-builder`) +- Testimonials: CFD-TST-### + GTM-TST-### (from `prd-v10-testimonial-collector`) -**Adoption Status** +**Adoption Health** -- Paying Customers: {# / MRR} -- Usage Health: {Metric + target} +- Paying customers: {# / MRR} +- Retention shape (cohort): {Day 7 / 30 / 90 retention by cohort} +- Adoption-stage drift: monitored via `prd-v08-drift-baseline-compare` (MON-DRIFT-### baselines) **Optimization Backlog** -- {Idea / hypothesis} → EPIC-{YY} +- {Idea / hypothesis from discovery} → EPIC-{YY} **Future Bets & Loopbacks** -- {Potential revisits to earlier lifecycle stages} +- {Potential revisits to earlier lifecycle stages — usually triggered by ADO-STAGE re-assessment} --- diff --git a/README.md b/README.md index b753423..be8244b 100644 --- a/README.md +++ b/README.md @@ -205,9 +205,9 @@ We do not proceed to the next stage until the **Definition of Done (DoD)** is me | **v0.5** | **Red Team Review** | Risks & Feasibility | Risks (Market/Tech) identified, Mitigations linked to tests. | | **v0.6** | **Architecture** | Technical Strategy | Stack selected, API contracts (`API-`) drafted, Cost guardrails. | | **v0.7** | **Build Execution** | Implementation Loop | Code tested (`TEST-`), SoT updated, Epic loop execution. | -| **v0.8** | **Release & Deployment** | Operational Readiness | Runbooks (`RUN-`), Monitoring (`MON-`), Rollback plan. | -| **v0.9** | **Launch** | Go-to-Market | Launch metrics (`KPI-`), Feedback channels (`CFD-`) active. | -| **v1.0** | **Growth** | Market Adoption | Paying customers, Retention analysis, Optimization loop. | +| **v0.8** | **Release & Deployment** | Operational Readiness | Runbooks (`RUN-`), Monitoring (`MON-`, `MON-DRIFT-`), Rollback plan, Changelog system, MOPS handoff. | +| **v0.9** | **Launch** | Go-to-Market | Positioning (Dunford), Offer (Hormozi), Channels (ORB), Launch metrics (`KPI-`), Feedback channels (`CFD-`), Tactical playbooks (AEO, alternatives, outreach, HN/Reddit). | +| **v1.0** | **Growth** | Market Adoption | Adoption stage (`ADO-STAGE-`), Beachhead (`ADO-BEACHHEAD-`), Whole product (`ADO-WHOLE-`), References (`ADO-REF-`), Continuous discovery, Case studies, Testimonials. | ### The Iterative Ecosystem diff --git a/SoT/SoT.ADOPTION.md b/SoT/SoT.ADOPTION.md new file mode 100644 index 0000000..40b33f6 --- /dev/null +++ b/SoT/SoT.ADOPTION.md @@ -0,0 +1,141 @@ +--- +version: 1.0 +purpose: Source of Truth for adoption-stage data using Geoffrey Moore's Technology Adoption Lifecycle. +id_prefix: ADO-XXX +last_updated: 2026-05-22 +authority: This is a SoT file - entries created and updated by v1.0 skills (chasm-adoption-moore, continuous-discovery-torres, mom-test-interview, case-study-builder, testimonial-collector) +--- + +# Adoption (SoT File) + +> **Purpose**: Track current adoption-stage position, beachhead segment, whole-product gaps, reference accounts, and chasm-crossing strategy. +> **ID Prefix**: ADO-XXX +> **Status**: Active SoT file (v1.0 stage) +> **Source**: Created and updated by v1.0 PRD skills +> **Audience**: All agents (post-launch and v1.0 work especially) +> **Cross-References**: Referenced by GTM-* (positioning, channels), KPI- (adoption metrics), CFD- (customer evidence) + +## ID Categories + +Each ADO- entry belongs to one of four sub-types. Confidence scoring (1-5) per [P4](../`.claude/skills/PRINCIPLES.md`). + +### ADO-STAGE-XXX: Adoption-stage assessment + +Where the product currently sits on Moore's lifecycle. One active entry at a time (older snapshots remain in history). Confidence based on evidence (qualitative customer composition, paid-customer composition, growth rate, retention shape). + +### ADO-BEACHHEAD-XXX: Beachhead segment definition + +The single early-majority sub-segment chosen as the chasm-crossing target. Sharper than the Dunford best-fit (which spans early adopters + early majority). Strict "in / not in" criteria. + +### ADO-WHOLE-XXX: Whole-product gap + +Specific product / service / integration / reference / process that pragmatist buyers expect but is currently missing. Each gap has an owner and a target close date. + +### ADO-REF-XXX: Reference account + +Named customer being cultivated as a public reference for the beachhead segment. Tracks reference-readiness (consent, story strength, target placement — pricing page, case study, conference talk). + +--- + +## Stage Reference: Moore's Technology Adoption Lifecycle + +| Stage | % of market | Buyer mindset | What they need to buy | +|-------|-------------|---------------|------------------------| +| **Innovators** (2.5%) | Technologists / tinkerers | Want to try new things; high tolerance for incomplete products | Vision, access, technical depth | +| **Early Adopters** (13.5%) | Visionaries | Want strategic advantage; tolerate rough edges if upside is large | Bold vision + ROI story | +| **— THE CHASM —** | — | — | — | +| **Early Majority** (34%) | Pragmatists | Want reliable productivity gains; need proof from peers | Whole product + references in their segment | +| **Late Majority** (34%) | Conservatives | Want safe, mature, defaults | Maturity, market leadership, low risk | +| **Laggards** (16%) | Skeptics | Resist change | (Generally not worth targeting) | + +The chasm — the gap between Early Adopters and Early Majority — is where most products die. The buyer behavior change from "I love bold new ideas" to "show me 3 references in my industry" is enormous. + +--- + +## Example Entries + +### ADO-STAGE-001: Current Adoption Stage Assessment + +- **Stage**: Early Adopters (with first chasm signals) +- **Evidence**: + - Paying customers: 12. Of those: 9 are early-adopter shape (technologist founders, willing to debug, talk to founder weekly). 3 are early-majority shape (asked about SOC2, references, integration with existing stack). + - Inbound shape changing: recent inquiries asking "do you have X integration?" — pragmatist behavior. +- **Confidence**: 3/5 (qualitative interview evidence, n=12) +- **Implications**: Chasm crossing is the next strategic question, not an aspiration. Beachhead selection needed (ADO-BEACHHEAD-). +- **Linked IDs**: CFD-100 (interview cohort), GTM-001 (positioning best-fit), KPI-101 (paid conversion rate) +- **Last verified**: YYYY-MM-DD +- **Status**: Active + +### ADO-BEACHHEAD-001: Beachhead Segment + +- **Segment**: [Specific firmographic + behavioral + use-case slice] +- **In-segment criteria** (must satisfy ALL): + - [Firmographic: company size, industry, geography] + - [Behavioral: tool stack, workflow, team shape] + - [Trigger: when they need this NOW vs eventually] +- **Not in-segment** (explicitly excluded for chasm crossing): + - [Adjacent segments — record them; come back via "bowling alley" later] +- **Rationale**: Why this segment first? (Pragmatist density + lowest whole-product gap + reference accessibility.) +- **Confidence**: 2/5 → 3/5 with first 5 closed-won deals in segment +- **Target**: 10 closed-won in this segment within [timeframe] +- **Linked IDs**: PER-001 (sharpened beachhead persona), CFD-XXX (segment interviews), ADO-STAGE-001 +- **Status**: Active + +### ADO-WHOLE-001: Whole-Product Gap — SSO Integration + +- **Gap type**: Integration +- **Description**: Beachhead pragmatists require SSO (Okta / Azure AD) before purchase. Currently not shipped. +- **Reported by**: CFD-105, CFD-108, CFD-112 (three lost deals cited SSO) +- **Severity**: Blocker (no SSO = no deal in segment) +- **Owner**: Engineering Lead +- **Target close date**: YYYY-MM-DD +- **Confidence**: 4/5 (multiple lost-deal CFD- entries confirm) +- **Linked IDs**: FEA-X (SSO feature), EPIC-Y (delivery), ADO-BEACHHEAD-001 + +### ADO-REF-001: Reference Account — [Customer Name] + +- **Customer**: [Logo / company name] +- **Segment fit**: ✓ In beachhead (ADO-BEACHHEAD-001) +- **Story strength**: [What outcome are they willing to talk about publicly?] +- **Consent**: [Approved for: logo / quote / case study / on-stage / podcast] +- **Target placement**: [Pricing page logo, blog case study, conference talk, AE talking points] +- **Confidence**: 4/5 (signed consent, story drafted, awaiting review) +- **Linked IDs**: CFD-XXX (customer interview), GTM-CASE-XXX (case study asset), ADO-BEACHHEAD-001 + +--- + +## Update Protocol + +1. **Created by**: + - `prd-v10-chasm-adoption-moore` — initial ADO-STAGE-, ADO-BEACHHEAD-, ADO-WHOLE- + - `prd-v10-case-study-builder` — populates ADO-REF- as cases ship + - Continuous discovery skills update ADO-STAGE- confidence as evidence accumulates +2. **Confidence progression** (P4): + - 1/5: Internal assumption only + - 2/5: Secondary research / competitor signal + - 3/5: Qualitative customer evidence (interviews) + - 4/5: Quantitative beta-cohort or pre-launch usage data + - 5/5: Production evidence (paying-customer behavior at scale) +3. **Re-assess cadence**: + - ADO-STAGE: Monthly during v1.0 push; quarterly after stable + - ADO-BEACHHEAD: Re-test only when 10+ closed-won evidence available or chasm-crossing strategy shifts + - ADO-WHOLE: Reviewed every sprint until closed + - ADO-REF: Updated as consent / placement status changes +4. **Stale flag**: Entries older than 90 days without re-verification get `⚠️ STALE`. +5. **Archive**: When ADO-STAGE moves forward (Early Adopters → Bowling Alley → Tornado), preserve prior snapshots in `## Stage History` section below. + +--- + +## Stage History + +> **Append-only**: When ADO-STAGE assessment changes, snapshot the prior state here. + +_(No entries yet)_ + +--- + +## Cross-Reference Index + +| ADO ID | Related IDs | Sub-type | +|--------|-------------|----------| +| _(populated as entries are created)_ | | |