技能备份 - 2026-04-15 (40个技能)
This commit is contained in:
@@ -0,0 +1,265 @@
|
||||
# AI Product Craft
|
||||
|
||||
Compressed decision logic for AI product managers: readiness assessment, context architecture, orchestration patterns, and validation methodology. Derived from ai-shaped-readiness-advisor, context-engineering-advisor, and pol-probe-advisor.
|
||||
|
||||
---
|
||||
|
||||
## AI-Shaped Readiness
|
||||
|
||||
### AI-First vs. AI-Shaped
|
||||
|
||||
| Dimension | AI-First (table stakes) | AI-Shaped (defensible) |
|
||||
|-----------|------------------------|------------------------|
|
||||
| Mindset | Automate existing tasks | Redesign how work gets done |
|
||||
| Goal | Speed up artifact creation | Compress learning cycles |
|
||||
| AI Role | Task assistant | Strategic co-intelligence |
|
||||
| Test | Competitor replicates by adding headcount | Competitor must redesign entire org |
|
||||
|
||||
### The 5 Competencies
|
||||
|
||||
**1. Context Design** — Build a durable "reality layer" humans and AI both trust. Treat AI attention as scarce. Persist constraints + glossary; retrieve everything else on demand. Foundational: blocks all other competencies if missing.
|
||||
|
||||
**2. Agent Orchestration** — Repeatable, traceable AI workflows (research -> synthesis -> critique -> decision -> log rationale). Version-controlled prompts. Each step shows its work. One-off prompts are tactical; orchestrated workflows are strategic.
|
||||
|
||||
**3. Outcome Acceleration** — Compress learning cycles, not just task speed. Eliminate validation lag (PoL probes in days, not weeks). Remove approval delays (AI pre-validates against constraints). Cut meeting overhead (async AI synthesis).
|
||||
|
||||
**4. Team-AI Facilitation** — AI operates as co-intelligence, not accountability shield. Review norms (AI outputs = drafts). Evidence standards (cite sources, reject "I think"). Decision authority (AI recommends, humans decide). Psychological safety to challenge AI.
|
||||
|
||||
**5. Strategic Differentiation** — New customer capabilities competitors can't replicate by throwing bodies at it. Workflow rewiring requiring full org redesign to copy. Economics competitors can't match (10x cost advantage through AI).
|
||||
|
||||
### Maturity Levels (per competency)
|
||||
|
||||
- **Level 1 — AI-First:** One-off prompts, no structure, efficiency only
|
||||
- **Level 2 — Emerging:** Some saved prompts/templates, scattered docs, modest gains
|
||||
- **Level 3 — Transitioning:** Multi-step workflows, structured context, learning cycles compressing
|
||||
- **Level 4 — AI-Shaped:** Autonomous orchestrated workflows, durable reality layer, defensible moat
|
||||
|
||||
### Priority Dependency Chain
|
||||
|
||||
```
|
||||
Context Design (foundation)
|
||||
└─> Agent Orchestration (requires context)
|
||||
└─> Outcome Acceleration (requires orchestration)
|
||||
└─> Strategic Differentiation (requires all above)
|
||||
Team-AI Facilitation ──── (parallel track, required for scale)
|
||||
```
|
||||
|
||||
If Context Design is Level 1-2, fix it first. Everything else is fragile without it.
|
||||
|
||||
---
|
||||
|
||||
## Context Engineering
|
||||
|
||||
### Context Stuffing vs. Context Engineering
|
||||
|
||||
| Dimension | Stuffing | Engineering |
|
||||
|-----------|----------|-------------|
|
||||
| Mindset | Volume = quality | Structure = quality |
|
||||
| Approach | "Add everything just in case" | "What decision am I making?" |
|
||||
| Persistence | Persist all context | Retrieve with intent |
|
||||
| Agent chains | Share everything between agents | Bounded context per agent |
|
||||
| Failure response | Retry until it works | Fix the structure |
|
||||
| Economic model | Context as storage | Context as attention (scarce) |
|
||||
|
||||
**Why stuffing fails:** Accuracy degrades significantly as context grows — models prioritize beginning and end, ignore the middle (Liu et al. 2023, "Lost in the Middle"). Dead ends and errors accumulate (context rot). Retries become normalized.
|
||||
|
||||
### 5 Diagnostic Questions
|
||||
|
||||
1. **What specific decision does this support?** Can't answer = don't need it.
|
||||
2. **Can retrieval replace persistence?** Just-in-time beats always-available.
|
||||
3. **Who owns the context boundary?** No owner = unbounded growth.
|
||||
4. **What fails if we exclude this?** No concrete failure = delete it.
|
||||
5. **Are we fixing structure or avoiding it?** Stuffing often masks bad info architecture.
|
||||
|
||||
### Persist vs. Retrieve Rule
|
||||
|
||||
- **Persist (80%+ of interactions):** Core constraints, user preferences, operational glossary, non-negotiable rules
|
||||
- **Retrieve (<20% of interactions):** Project details, historical PRDs, competitive analysis, past transcripts
|
||||
- **Gray zone (20-80%):** Weigh retrieval latency vs. context window cost
|
||||
|
||||
### Two-Layer Memory Architecture
|
||||
|
||||
**Short-term (conversational):** Immediate interaction history. Single session. Summarize/truncate older parts.
|
||||
|
||||
**Long-term (persistent):** Constraints registry + operational glossary + user preferences. Vector database for semantic retrieval. Two subtypes:
|
||||
- Declarative: facts ("We follow HIPAA")
|
||||
- Procedural: patterns ("Always validate feasibility before usability")
|
||||
|
||||
### Research -> Plan -> Reset -> Implement Cycle
|
||||
|
||||
The core context rot prevention pattern:
|
||||
|
||||
1. **Research:** Agent gathers data. Context grows large and messy. Expected.
|
||||
2. **Plan:** Synthesize into high-density SPEC.md/PLAN.md (source of truth).
|
||||
3. **Reset:** Clear entire context window. Non-negotiable.
|
||||
4. **Implement:** Fresh session with only the plan as context.
|
||||
|
||||
**Why it works:** Eliminates context rot, dead ends, and goal drift. Agent starts clean with compressed, high-signal context.
|
||||
|
||||
### Efficiency Formula
|
||||
|
||||
```
|
||||
Context Efficiency = (Accuracy x Coherence) / (Tokens x Latency)
|
||||
```
|
||||
|
||||
Key finding: RAG with 25% of available tokens preserves 95% accuracy while cutting latency and cost.
|
||||
|
||||
### Context Manifest Template
|
||||
|
||||
```
|
||||
Always Persisted: constraints (technical, regulatory), user prefs, glossary
|
||||
Retrieved On-Demand: historical PRDs, transcripts, competitive analysis
|
||||
Excluded: meeting notes >30 days, full codebase, marketing materials
|
||||
Boundary Owner: [Name]
|
||||
Next Review: [Date + 90 days]
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Agent Orchestration
|
||||
|
||||
### Core Workflow Pattern
|
||||
|
||||
```
|
||||
Research -> Synthesis -> Critique -> Decision -> Log Rationale
|
||||
```
|
||||
|
||||
Each step must be: traceable (cites sources), bounded (own context window), version-controlled (prompts in Git), consistent (same inputs -> predictable process).
|
||||
|
||||
### Maturity Progression
|
||||
|
||||
1. **Ad-hoc prompts:** Type into ChatGPT as needed. No reuse.
|
||||
2. **Saved templates:** Reusable prompts, custom GPTs/Claude Projects. Manual steps.
|
||||
3. **Multi-step workflows:** Research -> synthesis -> critique. Manual handoffs between steps.
|
||||
4. **Autonomous orchestration:** Runs end-to-end. Traceable. Version-controlled. Auditable.
|
||||
|
||||
### Bounded Context per Agent
|
||||
|
||||
Anti-pattern: Agent A passes everything to Agent B to Agent C (context window explodes to 100k+).
|
||||
|
||||
Fix: Each agent outputs a bounded synthesis (2-page max) to the next agent. Apply Research->Plan->Reset->Implement between agent handoffs.
|
||||
|
||||
### Building Your First Orchestrated Workflow
|
||||
|
||||
1. Pick most frequent AI use case
|
||||
2. Document every step you currently take manually
|
||||
3. Design loop: research -> synthesis -> critique -> decision -> log
|
||||
4. Implement (Claude Projects for simple; API orchestration for complex)
|
||||
5. Run on 3 past examples; compare to manual process
|
||||
6. Version-control prompts; train 2 teammates; iterate
|
||||
|
||||
---
|
||||
|
||||
## AI Validation (PoL Probes)
|
||||
|
||||
### The 5 Probe Types
|
||||
|
||||
| Probe | Core Question | Timeline | AI-Specific Use |
|
||||
|-------|---------------|----------|-----------------|
|
||||
| **Feasibility Check** | Can we build this? | 1-2 days | GenAI prompt chains, API sniff tests, data integrity sweeps |
|
||||
| **Task-Focused Test** | Can users complete this without friction? | 2-5 days | Test AI-generated UIs, chatbot flows, recommendation quality |
|
||||
| **Narrative Prototype** | Does this earn buy-in? | 1-3 days | Explain AI capabilities to stakeholders via Loom/video |
|
||||
| **Synthetic Data Simulation** | Can we model without production risk? | 2-4 days | Test prompt logic, simulate edge cases, Monte Carlo on AI outputs |
|
||||
| **Vibe-Coded Probe** | Will this survive real user contact? | 2-3 days | Frankensoft stack (ChatGPT Canvas + Replit + Airtable) for workflow validation |
|
||||
|
||||
### Selection Logic
|
||||
|
||||
Work backwards from hypothesis:
|
||||
1. What specific risk am I eliminating?
|
||||
2. What's the cheapest path to harsh truth?
|
||||
3. Match method to hypothesis, not tooling comfort.
|
||||
|
||||
**Golden rule:** Use the cheapest prototype that tells the harshest truth.
|
||||
|
||||
### AI-Specific Feasibility Checks
|
||||
|
||||
For AI product features, feasibility checks are critical because AI capabilities are non-obvious:
|
||||
- **Prompt chain testing:** Run 100 real examples through your proposed prompt. Measure error rate.
|
||||
- **API sniff tests:** Verify third-party AI integrations return expected format, latency, cost.
|
||||
- **Data integrity sweeps:** Check if your data supports the AI feature (quality, volume, format).
|
||||
- **Disposal protocol:** Delete all spike code after documenting findings. Spike-and-delete, not spike-and-ship.
|
||||
|
||||
### Success Criteria Template
|
||||
|
||||
- **Pass:** [Quantitative threshold, e.g., <5% error rate, 80%+ task completion]
|
||||
- **Fail:** [Observable failure, e.g., >18% errors, users abandon mid-flow]
|
||||
- **Learn:** [Specific insight regardless of pass/fail]
|
||||
|
||||
Write criteria before building. "We'll know it when we see it" is not a success criterion.
|
||||
|
||||
### Troubleshooting Common AI Product Issues
|
||||
|
||||
**Hallucination (output contains fabricated facts):**
|
||||
1. Measure: run 100+ real queries, categorize errors (factual, format, reasoning, refusal)
|
||||
2. Reduce context window — strip to minimum required tokens per the 5 diagnostic questions above
|
||||
3. Add retrieval with source citations — ground answers in specific documents, not parametric memory
|
||||
4. Add output validation — regex/rule checks for structured fields, LLM-as-judge for open text
|
||||
5. Set confidence thresholds — if model confidence is low, return "I don't know" instead of guessing
|
||||
|
||||
**Latency (AI response too slow for UX):**
|
||||
1. Profile the pipeline — which step is slow? (retrieval, inference, post-processing)
|
||||
2. Reduce input tokens — smaller context = faster inference. Apply persist vs. retrieve rule.
|
||||
3. Use streaming — display partial results as they generate
|
||||
4. Cache common queries — if 30% of queries are similar, pre-compute answers
|
||||
5. Consider smaller model for simple tasks — route easy queries to fast model, hard queries to capable model
|
||||
|
||||
**Inconsistency (same input, different outputs):**
|
||||
1. Lower temperature — 0.0-0.3 for factual tasks, 0.5-0.7 for creative tasks
|
||||
2. Pin model version — don't use "latest" in production
|
||||
3. Structured output — JSON schema or enum constraints reduce variation
|
||||
4. Add few-shot examples — 2-3 input/output pairs anchor the response pattern
|
||||
5. Evaluate on a fixed test set — track consistency score across versions
|
||||
|
||||
---
|
||||
|
||||
## Quality Gates
|
||||
|
||||
### AI Product Anti-Patterns
|
||||
|
||||
**1. Prompt-and-Pray**
|
||||
Shipping AI features with untested prompts. No evaluation framework, no error rate measurement. Fix: Run feasibility checks (100+ examples) before committing to build.
|
||||
|
||||
**2. Context Stuffing at Scale**
|
||||
Pasting entire knowledge bases into AI. "More tokens = better results." Fix: Apply the 5 diagnostic questions. Accuracy degrades significantly as context grows (Lost in the Middle effect).
|
||||
|
||||
**3. No Evals**
|
||||
Launching AI features without quantitative success criteria. "Users seem to like it." Fix: Define pass/fail thresholds before building. Measure error rates, task completion, hallucination frequency.
|
||||
|
||||
**4. Efficiency Masquerading as Strategy**
|
||||
"We use AI to write PRDs 2x faster — we're AI-shaped!" If a competitor matches it by hiring 2 more people, it's table stakes. Fix: Ask the replication test — does copying require org redesign?
|
||||
|
||||
**5. Tool Fetishism**
|
||||
"Should we use Claude or ChatGPT?" Tool debates replace workflow redesign. Fix: Tools don't matter. Workflows matter.
|
||||
|
||||
**6. Speed Without Learning**
|
||||
Shipping faster without validating faster. AI accelerates building the wrong thing. Fix: Compress learning cycles (PoL probes in days), not just build cycles.
|
||||
|
||||
**7. Prototype Theater**
|
||||
Building polished demos to impress executives instead of testing hypotheses with users. Fix: Test with users first, present findings to executives. Narrative prototypes over production polish.
|
||||
|
||||
**8. Skipping the Reset**
|
||||
Never clearing context between research and implementation. Context rot poisons execution. Fix: Mandatory reset after plan synthesis. Start implementation with only the high-density plan.
|
||||
|
||||
**9. Individual AI, Not Team AI**
|
||||
"I'm AI-shaped, but my team isn't." Can't scale; workflows die when you're on vacation. Fix: Codify review norms, evidence standards, decision authority. Team transformation > individual productivity.
|
||||
|
||||
**10. Testing Multiple Variables**
|
||||
One probe testing workflow + pricing + UI simultaneously. Ambiguous results. Fix: One probe, one hypothesis. Three hypotheses = three probes.
|
||||
|
||||
### The Falsification Protocol
|
||||
|
||||
For every AI feature decision, complete:
|
||||
> "If I exclude [context/feature/test], then [specific failure] will occur in [specific scenario]."
|
||||
|
||||
If you can't complete the sentence, you don't need it. Vague failures ("AI might not fully understand") are not valid.
|
||||
|
||||
### Minimum Viable AI Product Checklist
|
||||
|
||||
- [ ] Hypothesis written before building
|
||||
- [ ] Feasibility check run (100+ examples, error rate measured)
|
||||
- [ ] Context architecture defined (persist vs. retrieve vs. exclude)
|
||||
- [ ] Success criteria quantified (pass/fail/learn thresholds)
|
||||
- [ ] Disposal date set for probes (spike-and-delete)
|
||||
- [ ] Context boundary owner assigned
|
||||
- [ ] AI outputs treated as drafts (human review protocol)
|
||||
- [ ] Learning cycle measured (before vs. after AI intervention)
|
||||
@@ -0,0 +1,241 @@
|
||||
# PM Artifacts & Delivery
|
||||
|
||||
Compressed reference for the full PM artifact lifecycle: from proto-personas and problem framing through PRDs, user stories, epics, story maps, and end-of-life communications.
|
||||
|
||||
## PRD Development
|
||||
|
||||
10-section document, built over 2-4 days.
|
||||
|
||||
**Template structure (10 sections):**
|
||||
1. Executive Summary -- "We're building [solution] for [persona] to solve [problem], resulting in [impact]."
|
||||
2. Problem Statement -- Who, what, why, evidence (quotes, analytics, tickets)
|
||||
3. Target Users & Personas -- Primary + secondary proto-personas
|
||||
4. Strategic Context -- OKRs, TAM/SAM/SOM, competitive landscape, "why now?"
|
||||
5. Solution Overview -- High-level description + user flows (not pixel specs)
|
||||
6. Success Metrics -- Primary metric (optimize), secondary (monitor), guardrail (don't regress)
|
||||
7. User Stories & Requirements -- Epic hypothesis + broken-down stories with acceptance criteria
|
||||
8. Out of Scope -- Explicit exclusions with rationale
|
||||
9. Dependencies & Risks -- Technical, external, team; risks + mitigations
|
||||
10. Open Questions -- Unresolved decisions needing discovery
|
||||
|
||||
**Metrics structure:** Always define current baseline, target, and measurement timeline. Format: "Metric: Current X -> Target Y, measure Z days post-launch."
|
||||
|
||||
**Phase sequence:**
|
||||
- Day 1: Exec summary (30m) + Problem (60m) + Personas (30m) + Strategy (45m)
|
||||
- Day 2: Solution (60m) + Metrics (30m) + Stories (90-120m)
|
||||
- Day 3: Scope/Dependencies (30m) + Review (60m)
|
||||
|
||||
## User Stories
|
||||
|
||||
**Format (Mike Cohn + Gherkin):**
|
||||
```
|
||||
As a [specific persona], I want to [action], so that [outcome/motivation].
|
||||
|
||||
Scenario: [description]
|
||||
Given: [preconditions -- multiple Givens OK]
|
||||
When: [single trigger event -- aligns with "I want to"]
|
||||
Then: [single outcome -- aligns with "so that"]
|
||||
```
|
||||
|
||||
**Quality gates:**
|
||||
- "As a" uses specific persona, not generic "user"
|
||||
- "So that" states motivation, not restatement of action
|
||||
- One When, one Then per story. Multiple = split signal.
|
||||
- Acceptance criteria are testable by QA -- no "better experience" or "faster"
|
||||
- Summary is value-centric: "Enable Google login for trial users" not "Add login button"
|
||||
|
||||
### Splitting Stories
|
||||
|
||||
8 patterns applied in order (Richard Lawrence / Humanizing Work). Stop at first match:
|
||||
|
||||
| # | Pattern | Signal | Split strategy |
|
||||
|---|---------|--------|----------------|
|
||||
| 1 | Workflow steps | Multi-step sequence | Thin end-to-end slices (full workflow, increasing sophistication) |
|
||||
| 2 | Business rules | Different rules per scenario | One story per rule variation |
|
||||
| 3 | Data variations | Different data types/formats | One story per data type, simplest first |
|
||||
| 4 | AC complexity | Multiple When/Then | One story per When/Then pair |
|
||||
| 5 | Major effort | Hard first build, easy additions | "Implement one + add remaining" |
|
||||
| 6 | External deps | Multiple APIs/third parties | One story per dependency boundary |
|
||||
| 7 | DevOps steps | Infrastructure/deployment work | Split by operational complexity |
|
||||
| 8 | Tiny Acts of Discovery | High uncertainty, none above apply | Time-boxed experiments, not stories |
|
||||
|
||||
**Validation after split:** Each piece must (a) deliver user value independently, (b) be testable independently, (c) fit in a sprint (1-5 days), (d) all pieces combined equal the original.
|
||||
|
||||
**Critical rule:** Always split vertically (front-end + back-end = user value). Never horizontally ("Build API" / "Build UI").
|
||||
|
||||
## Story Mapping
|
||||
|
||||
**Jeff Patton framework -- 2D map:**
|
||||
- Horizontal (left-right): Activities in narrative/workflow order = backbone
|
||||
- Vertical (top-down): Priority within each activity
|
||||
|
||||
**Hierarchy:** Segment -> Persona -> Narrative (goal) -> Activities (3-5) -> Steps (3-5 per activity) -> Tasks (5-7 per step)
|
||||
|
||||
**Building the map:**
|
||||
1. Define segment + persona + narrative (one-sentence JTBD goal)
|
||||
2. Identify 3-5 backbone activities in sequential workflow order
|
||||
3. Break each activity into steps (user actions, observable, logical sequence)
|
||||
4. Break steps into tasks (granular, prioritizable)
|
||||
5. Prioritize vertically: top = MVP, middle = R2, bottom = future
|
||||
6. Draw horizontal release lines
|
||||
|
||||
**Walking skeleton:** Top-priority task from EVERY activity = minimal end-to-end functionality. Build across all activities incrementally, not one activity fully before starting the next.
|
||||
|
||||
**Release slicing:**
|
||||
- R1 (Walking skeleton): Simplest version across all activities
|
||||
- R2 (Enhanced): Second-priority tasks improving core workflow
|
||||
- R3 (Polish): Nice-to-haves, edge cases, optimizations
|
||||
|
||||
## Epics
|
||||
|
||||
### Epic Hypothesis
|
||||
|
||||
**Template (Tim Herbig / Lean UX):**
|
||||
```
|
||||
If we [specific action/solution]
|
||||
for [specific persona]
|
||||
Then we will [measurable outcome]
|
||||
```
|
||||
|
||||
**Tiny Acts of Discovery:** 2-3 lightweight experiments before full build.
|
||||
- Types: prototype + user test, concierge test, landing page test, Wizard of Oz, A/B test
|
||||
- Constraint: days/weeks not months; cheap; falsifiable
|
||||
|
||||
**Validation measures:**
|
||||
```
|
||||
We know our hypothesis is valid if within [2-4 weeks]
|
||||
we observe:
|
||||
- [Quantitative: "20% increase in activation rate"]
|
||||
- [Qualitative: "8/10 users say it saved time"]
|
||||
```
|
||||
|
||||
**Decision gate:** Validated -> write user stories. Invalidated -> kill or pivot. Inconclusive -> more experiments.
|
||||
|
||||
### Epic Breakdown (9 Patterns)
|
||||
|
||||
Pre-split: INVEST check (Independent, Negotiable, Valuable, Estimable, Small, Testable). If not Valuable, STOP -- combine with other work, don't split.
|
||||
|
||||
**9 patterns applied sequentially** (superset of story splitting):
|
||||
1. **Workflow steps** -- thin end-to-end, NOT step-by-step
|
||||
2. **Operations (CRUD)** -- "manage" = Create + Read + Update + Delete
|
||||
3. **Business rule variations** -- each rule = separate story
|
||||
4. **Data variations** -- add data types just-in-time
|
||||
5. **Data entry methods** -- basic input first, fancy UI later
|
||||
6. **Major effort** -- implement one + add remaining
|
||||
7. **Simple/Complex** -- simplest core first, variations later
|
||||
8. **Defer performance** -- "make it work" then "make it fast"
|
||||
9. **Break out a spike** -- time-box investigation when uncertainty blocks splitting
|
||||
|
||||
**Meta-pattern across all:** Identify core complexity -> list variations -> reduce to one complete slice -> make other variations separate stories.
|
||||
|
||||
**Evaluate splits:** (a) Does it reveal low-value work you can kill? (b) Are resulting stories roughly equal-sized?
|
||||
|
||||
**Cynefin adjustment:** Low uncertainty = find all stories, prioritize by value. High uncertainty = identify 1-2 learning stories only. Chaos = defer splitting, stabilize first.
|
||||
|
||||
## Proto-Personas
|
||||
|
||||
**Hypothesis-driven persona, not validated research.** Created in hours from available data.
|
||||
|
||||
**Template sections:**
|
||||
1. **Name** -- alliterative, memorable ("Manager Mike")
|
||||
2. **Bio & Demographics** -- behavioral, not just age/location. Include career, online presence, tech habits.
|
||||
3. **Quotes** -- real or representative; revealing mindset, not facts
|
||||
4. **Pains** -- specific and product-relevant ("3 hrs/week copying data between tools")
|
||||
5. **What they're trying to accomplish** -- observable behaviors and outcomes
|
||||
6. **Goals** -- short-term + long-term, personal + professional
|
||||
7. **Attitudes & Influences** -- decision authority, influencers, beliefs affecting adoption
|
||||
|
||||
**Mark uncertainty:** Tag unvalidated items with [ASSUMPTION--VALIDATE]. Plan research to fill gaps. Limit to 1-2 personas initially.
|
||||
|
||||
## Press Release / PRFAQ
|
||||
|
||||
**Amazon Working Backwards format.** Written BEFORE building. Planning tool, not launch copy.
|
||||
|
||||
**Structure:**
|
||||
1. **Headline** -- benefit-focused, specific ("Cut Invoice Processing by 60%")
|
||||
2. **Dateline** -- city, date
|
||||
3. **Introduction** -- what launched, for whom, key benefit (2-3 sentences)
|
||||
4. **Problem paragraph** -- specific customer problem with data
|
||||
5. **Solution paragraph** -- outcome-focused, not feature list
|
||||
6. **Executive quote** -- customer-empathetic, visionary (not "excited to innovate")
|
||||
7. **Supporting details** -- additional benefits with data
|
||||
8. **Boilerplate** -- company background
|
||||
9. **CTA + media contact**
|
||||
|
||||
**Litmus tests:** Would a customer care? Is the problem clear? Are benefits measurable? Is it jargon-free? Does it survive "so what?"
|
||||
|
||||
## Storyboards
|
||||
|
||||
**6-frame narrative arc** for pitching, alignment, and emotional validation.
|
||||
|
||||
| Frame | Name | Content |
|
||||
|-------|------|---------|
|
||||
| 1 | Main character | Persona + context (specific, not "busy professional") |
|
||||
| 2 | Problem emerges | Challenge + how it affects life |
|
||||
| 3 | "Oh crap" moment | Escalation creating urgency |
|
||||
| 4 | Solution appears | Realistic discovery of product |
|
||||
| 5 | "Aha" moment | Breakthrough experience (outcome, not feature demo) |
|
||||
| 6 | Life after | Improved state with specifics |
|
||||
|
||||
**Visual style default:** Fat-marker sharpie sketches, minimal, monochrome. Low-fidelity is fine.
|
||||
|
||||
**7 input questions:** Who is the character? What problem? What's the escalation? How is solution introduced? What's the breakthrough? What's life after? Visual style preferences?
|
||||
|
||||
## Recommendation Canvas
|
||||
|
||||
**11-section strategic proposal** for AI/high-uncertainty product decisions. Executive-friendly.
|
||||
|
||||
1. **Business Outcome** -- [Direction] [Metric] [Outcome] [Context] [Criteria]
|
||||
2. **Product Outcome** -- same format, customer perspective
|
||||
3. **Problem Statement** -- persona-centric narrative
|
||||
4. **Solution Hypothesis** -- If/Then + Tiny Acts of Discovery + Proof-of-Life measures
|
||||
5. **Positioning Statement** -- For/That need/Is a/That + Unlike/Provides differentiation
|
||||
6. **Assumptions & Unknowns** -- explicit, testable
|
||||
7. **PESTEL Risks (Investigate)** -- Political, Economic, Social, Tech, Environmental, Legal (specific, not generic)
|
||||
8. **PESTEL Risks (Monitor)** -- lower priority watch list
|
||||
9. **Value Justification** -- data-backed case for C-level ("addresses #1 pain point, $500k ARR impact")
|
||||
10. **Success Metrics** -- SMART format
|
||||
11. **What's Next** -- ordered action steps
|
||||
|
||||
## End-of-Life Communication
|
||||
|
||||
**9-section empathy-first EOL message.** Never send without a complete transition plan.
|
||||
|
||||
**Structure:**
|
||||
1. **Company context** -- who you are, customer commitment
|
||||
2. **Announcement** -- single clear sentence: what's ending, what's replacing it, when
|
||||
3. **Rationale** -- framed as customer benefit, not cost savings
|
||||
4. **Current product context** -- acknowledge what's being lost and who it served
|
||||
5. **Customer impact** -- explicitly name disruptions (migration time, learning curve, integration updates)
|
||||
6. **Transition solution** -- positioning format: For/That currently use/Is a/That + continuity + improvements
|
||||
7. **Support measures** -- 1:1 assistance, auto-migration, discounts, training
|
||||
8. **Timeline** -- specific dates: migration tool available, read-only date, full shutdown, data export deadline. 6-12 months lead time.
|
||||
9. **Call to action** -- next steps + contact info
|
||||
|
||||
**Tone rules:** Empathetic, not defensive. Forward-looking, not apologetic. Specific, not vague. Never blame customers for low usage.
|
||||
|
||||
## Quality Gates
|
||||
|
||||
### Cross-cutting anti-patterns
|
||||
|
||||
| Anti-pattern | Appears in | Fix |
|
||||
|---|---|---|
|
||||
| Written in isolation | PRD, story map | Collaborate with design + eng on stories/map |
|
||||
| No evidence in problem statement | PRD, press release, canvas | Include quotes, analytics, tickets |
|
||||
| Solution too prescriptive | PRD | Keep solution high-level; let design own UI |
|
||||
| Feature list instead of benefits | Press release, canvas | Translate features to outcomes |
|
||||
| Generic "As a user" | User stories | Use specific persona names/roles |
|
||||
| "So that" restates "I want to" | User stories | Dig into real motivation |
|
||||
| Multiple When/Then | User stories | Split the story |
|
||||
| Horizontal slicing | Story splitting, epic breakdown | Always vertical: each story delivers end-to-end user value |
|
||||
| Skipping experiments | Epic hypothesis, canvas | Define lightweight validation before build |
|
||||
| Vague validation measures | Epic hypothesis, canvas | Specific metrics + timeframe (2-4 weeks) |
|
||||
| Treating hypotheses as commitments | Epic hypothesis | Frame as bets; allow invalidation |
|
||||
| Activities are features, not behaviors | Story map | Map user actions, not product capabilities |
|
||||
| Technical backbone | Story map | Backbone follows user workflow, not system layers |
|
||||
| Feature-complete waterfall releases | Story map | Walking skeleton = thin slice across ALL activities |
|
||||
| Demographics without behavior | Proto-persona | Add behavioral context, not just age/location |
|
||||
| Too many personas | Proto-persona | Start with 1-2; expand as validated |
|
||||
| Business-centric EOL rationale | EOL message | Frame as customer benefit |
|
||||
| Vague EOL timeline | EOL message | Specific dates with milestones |
|
||||
| No transition support plan | EOL message | Migration assistance, tools, discounts |
|
||||
@@ -0,0 +1,250 @@
|
||||
# Career & Leadership
|
||||
|
||||
Compressed knowledge module covering the PM-to-Director and Director-to-VP/CPO career transitions, diagnostic coaching logic, executive onboarding methodology, and named failure modes at each level.
|
||||
|
||||
## Altitude-Horizon Framework
|
||||
|
||||
Two axes define the PM-to-Director shift:
|
||||
|
||||
**Altitude (Scope)**
|
||||
- PM: customer problems, individual features, sprint priorities, specific team dynamics.
|
||||
- Director: product portfolio, cross-functional systems, organizational dynamics, budget allocation, market positioning.
|
||||
|
||||
**Horizon (Time)**
|
||||
- PM: days, weeks, sprints. A quarter at most.
|
||||
- Director: quarter as starting point. Annual planning cycles, multi-year strategy.
|
||||
|
||||
**Waiter vs. Restaurant Operator** — the core analogy:
|
||||
|
||||
| Dimension | PM (Waiter) | Director (Operator) |
|
||||
|---|---|---|
|
||||
| Focus | Individual diner experience | Entire system: staffing, margins, menu, suppliers |
|
||||
| Authority | Influence without control | Portfolio decisions, budget, resource allocation |
|
||||
| Success metric | Table seven is happy | Restaurant is profitable, consistent, scalable |
|
||||
| Customer relationship | Direct, daily, intimate | Aggregate patterns, market cohorts |
|
||||
|
||||
### Four Transition Zones
|
||||
|
||||
1. **Thinking Altitude** — Stop solving individual problems directly. Start designing systems and teams that solve classes of problems.
|
||||
2. **Persona Shift** — Stop obsessing over individual user personas. Start thinking in buyer personas, market cohorts, organizational stakeholders, executive dynamics.
|
||||
3. **Hero Syndrome Recovery** — Stop being the person who saves the day. Start getting satisfaction from team success. Your product is your people, not the roadmap.
|
||||
4. **Direction Creation** — Stop waiting for clear direction from above. Start creating context cascades that translate strategy into team clarity, even when inputs are incomplete.
|
||||
|
||||
### Cascading Context Map
|
||||
|
||||
When direction is vague, Directors cascade rather than wait:
|
||||
|
||||
1. Listen to top-level strategy (QBRs, exec comms)
|
||||
2. Extract 3-5 key priorities leadership stated
|
||||
3. Map: "How does our BU accomplish these?"
|
||||
4. Map: "How does our product portfolio accomplish that?"
|
||||
5. Map: "What are my team's specific accountabilities?"
|
||||
6. Communicate the cascade — not just what, but why it connects upward
|
||||
|
||||
Template:
|
||||
```
|
||||
Company Priority: [leadership's words]
|
||||
BU Translation: [how your BU contributes]
|
||||
Portfolio Translation: [how your products contribute]
|
||||
Team Accountabilities: [what each team owns]
|
||||
Why This Matters: [what changes, what stays the same]
|
||||
```
|
||||
|
||||
Core principle: even with incomplete direction from above, a Director's job is to fill the gap downward. Creating imperfect-but-useful clarity is a Director skill.
|
||||
|
||||
### Named Failure Modes (PM-to-Director)
|
||||
|
||||
**Hero Syndrome** — Jumping in to solve problems directly. Regressing to the old reward loop of visible IC wins. Cost: you under-perform as Director while over-functioning as senior IC. Your team doesn't develop.
|
||||
|
||||
**Allergic to Process** — Letting high-performing PMs run independent playbooks. Cost: stakeholders across marketing, finance, leadership can't synthesize inconsistent outputs.
|
||||
|
||||
**People-Pleaser Leadership** — Wanting the team to like you. Avoiding hard feedback. Saying yes to preserve relationships. Cost: confuse "popular" with "effective."
|
||||
|
||||
**Instant Gratification Trap** — Reading leadership books, collecting certifications, asking "what do I need to do to get promoted?" Cost: Director readiness requires war stories and lived humility, not study.
|
||||
|
||||
**Black-and-White Thinking** — "This seems obvious." "Why is everything so political?" Cost: fast decisions with low confidence create downstream chaos. Grayscale is the actual terrain.
|
||||
|
||||
## PM to Director Transition
|
||||
|
||||
### Four Coaching Situations
|
||||
|
||||
| Situation | Description | Coaching Priority |
|
||||
|---|---|---|
|
||||
| Preparing | Still a PM, building toward Director | Identify weakest transition zone; practice cascade thinking; audit Hero Syndrome habits |
|
||||
| Interviewing | Active internal or external search | Build one story per transition zone; reframe PM wins in Director language; prepare for the gap question honestly |
|
||||
| Newly Landed | First 6 months as Director | Run Cascading Context Map immediately; reframe 1-on-1s to strategic altitude; name ambiguity explicitly; resist premature reorgs |
|
||||
| Recalibrating | Been a Director; something broken | Track IC-vs-coaching time ratio (target: 20% IC); identify what keeps you in Hero Syndrome; create deliberate handoffs |
|
||||
|
||||
### Readiness Signals (Preparing)
|
||||
|
||||
Assess across four gap areas:
|
||||
1. **Thinking altitude** — still default to solving customer problems directly?
|
||||
2. **Stakeholder navigation** — struggle with politics, exec dynamics, cross-functional influence?
|
||||
3. **Strategic narrative** — can't connect work to company strategy in leadership conversations?
|
||||
4. **Direction creation** — wait for clarity from above rather than creating it?
|
||||
|
||||
Development timeline matters: 6+ months out = build deliberately. 3-6 months = signal readiness, prepare manager conversation. Actively applying = shift to interview prep.
|
||||
|
||||
### Interview Preparation
|
||||
|
||||
- Work through Altitude-Horizon Framework as a study session: after each section, identify your own story.
|
||||
- Build one concrete story per transition zone. Use zone names as structure.
|
||||
- Reframe PM wins: don't open with "I shipped X." Open with "The strategic question my team faced was [X]. Here's how I thought about the portfolio tradeoff."
|
||||
- For the gap question: "Here's the gap, here's how I've been developing toward it, here's what I'd focus on learning in the first 90 days." Honesty with a plan beats avoidance.
|
||||
|
||||
### Newly Landed Coaching
|
||||
|
||||
Challenge-specific guidance for inherited teams without clear direction:
|
||||
1. Run a Cascading Context Map this week. Don't wait for perfect clarity.
|
||||
2. Redirect 1-on-1s: "Help me see how your product connects to the business goals I'm accountable for."
|
||||
3. Name ambiguity explicitly: "Here's my best current translation. I'll update it in two weeks."
|
||||
4. Wait 60-90 days before reorganizing. Understand what's working first.
|
||||
|
||||
### Recalibrating Coaching
|
||||
|
||||
For Directors still doing IC work after 12+ months:
|
||||
- Track the ratio: most are at 60-70% IC work. Target is 20%.
|
||||
- Identify root cause: (a) trust own judgment over team, (b) team undeveloped, (c) getting reward signals from IC behavior.
|
||||
- Create deliberate handoff for top 3 IC activities with written "done well" criteria.
|
||||
- Change the reward loop: notice quieter Director wins (PM ships a hard stakeholder conversation alone, team creates its own cascade).
|
||||
- If entrenched at 1-2 years: consider whether the role fits. Senior IC / Principal PM is a legitimate path.
|
||||
|
||||
## Director to VP/CPO Transition
|
||||
|
||||
### The Three Ps Framework
|
||||
|
||||
VP/CPO accountability spans three dimensions:
|
||||
- **Product** — Portfolio decisions, roadmap strategy, product family coherence
|
||||
- **Practice** — How work gets done; process discipline, execution consistency, cross-functional operating rhythms
|
||||
- **People** — The dominant focus: org structure, talent matching, developing leaders, setting and inspecting expectations
|
||||
|
||||
Most Directors are strong in Product, adequate in Practice. People is where the VP/CPO transition most often breaks down.
|
||||
|
||||
### The Empowerment Myth
|
||||
|
||||
False belief: "Once I get there, I'll finally have authority to do what I always knew was right."
|
||||
Reality: constraints don't disappear, they change shape. PM = 3x3 Rubik's Cube. Director = 5x5. VP = 7x7. CPO = 9x9. Same principles; exponentially larger blast radius per decision.
|
||||
|
||||
### VP to CPO Paradigm Shift
|
||||
|
||||
| Dimension | VP Mindset | CPO Mindset |
|
||||
|---|---|---|
|
||||
| Core question | "What are we releasing?" | "What business outcomes is the product org accountable for?" |
|
||||
| Language | Product vocabulary (features, roadmaps, sprints) | Business vocabulary (ROI, revenue, retention, margin, EBITDA) |
|
||||
| Primary customer | End user | May be investor, buyer, or board — depends on business context |
|
||||
| Primary team | Product organization | Executive staff (CEO, CFO, CRO, CMO) |
|
||||
|
||||
### Time Horizon by Level
|
||||
|
||||
| Level | Short-term | Long-term |
|
||||
|---|---|---|
|
||||
| IC | Sprint | Quarter |
|
||||
| Director | Quarter | 1-2 years |
|
||||
| VP | 1-2 quarters | 3 years |
|
||||
| CPO | 1-2 quarters | 3-5 years |
|
||||
|
||||
Quarterly delivery doesn't stop. Long-term horizon runs in parallel with short-term accountability at every level.
|
||||
|
||||
### Alliance Building (Executive Level)
|
||||
|
||||
Without executive alliances, you're a "dead man walking." Requirements:
|
||||
- Weekly engagement with peer executives (CRO, CFO, CMO) — not annual roadmap reviews
|
||||
- Proactive trade-off communication: "You're not getting X this quarter because of Y, and here's why"
|
||||
- Bring people along before decisions are announced, not after
|
||||
- Understand each peer's real priorities, not just stated ones
|
||||
|
||||
### CEO Interview Questions (Pre-Acceptance)
|
||||
|
||||
Five questions to probe before accepting a VP/CPO role:
|
||||
|
||||
1. "What are you expecting from the product org in the first 90 days? The first year?" — Surfaces unrealistic transformation timelines.
|
||||
2. "Who are the all-stars on your product team, and why?" — Reveals CEO's perceptions and biases.
|
||||
3. "Who has gaps, and why?" — What does the CEO believe the org weakness is?
|
||||
4. "What constraints am I working with that I should understand upfront?" — Your actual degrees of freedom.
|
||||
5. "What does success look like for this role at one year?" — Force specificity. Vague answers are red flags.
|
||||
|
||||
**Red flags:** "You can't change the existing roadmap" (loss of basic authority). "Transform the org in six months" (setup for failure). Misalignment between CEO's talent assessment and what you hear elsewhere.
|
||||
|
||||
### VP/CPO Readiness Assessment
|
||||
|
||||
Four coaching situations mirror the Director advisor:
|
||||
|
||||
| Situation | Key Assessment Areas |
|
||||
|---|---|
|
||||
| Preparing | Which of the Three Ps is weakest? What's your exposure to executive dynamics? |
|
||||
| Evaluating/Interviewing | Can you demonstrate executive-level thinking vs. Director-level work? Have you run CEO interview questions? |
|
||||
| Newly Landed | Getting oriented without acting prematurely? Executive dynamics navigation? People/org assessment? Surfacing unwritten strategy? |
|
||||
| Recalibrating | Still operating at Director level? Executive relationships broken? Organization underperforming? Unclear success criteria? |
|
||||
|
||||
## Executive Onboarding (30-60-90)
|
||||
|
||||
### Consultant Mindset
|
||||
|
||||
Enter every new VP/CPO role as an external consultant assessing the organization before you're responsible for changing it.
|
||||
- Observe before diagnosing. Ask questions before declarations.
|
||||
- Understand how steering connects to rudder — org charts lie; map actual reality.
|
||||
- Don't throw the big red switch. Understand what inherited structures control first.
|
||||
- Negotiate upfront: tell your boss Month 1 is explicitly a learning phase.
|
||||
|
||||
### Phase 1: Diagnose (Month 1)
|
||||
|
||||
**Objective:** Build the body of evidence. Understand reality, not the official version.
|
||||
|
||||
1. **Interview everyone** — Direct reports, cross-functional peers (CRO, CFO, CMO, Eng leads), sample of PMs. Questions: "What's working?" / "What's not working?" / "What won't I hear in official briefings?" / "Who should I talk to?"
|
||||
2. **Let people find you** — Those who proactively schedule time have an agenda. Surface it, evaluate it, note the signal.
|
||||
3. **Take detailed notes** — Who said it, what their incentive might be, whether multiple independent sources confirm it.
|
||||
4. **Resist action** — When you see something broken, note it. You don't yet know why it's broken, what it's connected to, or what previous fix attempts failed.
|
||||
|
||||
**Deliverable:** Detailed notebook of organizational reality, not yet interpreted.
|
||||
|
||||
### Phase 2: Validate (Month 2)
|
||||
|
||||
**Objective:** Surface patterns, challenge conclusions, identify people situations.
|
||||
|
||||
1. **Reality-check with your boss** — "I'm hearing [X]. This differs from what I understood coming in. Help me understand the history."
|
||||
2. **Map unwritten strategy** — Ask: "What does the organization actually optimize for when things get hard?" Answer is usually different from mission statement.
|
||||
3. **Complete people assessment** — Diamonds in the rough (give more scope). Strong but wrong role (have the conversation). Not coachable to needed level (determine timeline).
|
||||
4. **Identify 3-5 highest-leverage changes** — Not a full transformation plan. These become Month 3 agenda.
|
||||
|
||||
**Deliverable:** Interpreted organizational assessment with people map and initial strategic priorities.
|
||||
|
||||
### Phase 3: Act with Evidence (Month 3)
|
||||
|
||||
**Objective:** Make decisions grounded in collected evidence.
|
||||
|
||||
1. **Share organizational assessment** — Bring findings to boss and direct reports. Transparency builds trust and surfaces disagreements before you act.
|
||||
2. **Run first Cascading Context Map** — Create direction even if strategy above you is still ambiguous. Team has been waiting for context.
|
||||
3. **Start people conversations** — Diamonds: stretch assignment. Wrong role: honest conversation about mismatch and options. Exits: honesty and care, not avoidance.
|
||||
4. **Build executive alliance deliberately** — Start weekly alignment practice with CRO, CFO, CMO. Don't wait for them to be surprised.
|
||||
|
||||
**Deliverable:** Shared assessment, initial strategic direction, 3-5 active changes underway with clear rationale.
|
||||
|
||||
### People Assessment Categories
|
||||
|
||||
**Diamonds in the rough:** Capable, undervalued, no champion. Find them by listening for "she's talented but nobody gives her the hard problems" or noticing who provides the most unvarnished information. They become critical early allies.
|
||||
|
||||
**Strong people in wrong roles:** Strengths mismatched to scope. Common in fast-growth, post-acquisition, or tenure-based promotion orgs. Coach up if coachable, find another role, or part ways. All three better than leaving mismatch in place.
|
||||
|
||||
## Quality Gates
|
||||
|
||||
### Anti-Patterns Across All Transitions
|
||||
|
||||
**Premature action** — Making structural changes before building the body of evidence. Month 1 changes guarantee expensive reversals.
|
||||
|
||||
**Consultant mode too long** — Still gathering information in Month 3. Organizational confidence erodes. Act on best current evidence.
|
||||
|
||||
**Title-chasing** — Optimizing for promotion appearance rather than building actual muscles. Interviewers and managers detect the difference.
|
||||
|
||||
**Skipping altitude shifts** — Using strategy vocabulary while still making sprint-level decisions (Altitude Theater). If you're in the details, own it. If you're not, delegate fully.
|
||||
|
||||
**Empowerment fantasy** — Taking a VP/CPO role expecting constraints to vanish. They scale up, they don't disappear.
|
||||
|
||||
**Alliance neglect** — Treating executive peer relationships as secondary to managing direct reports. At VP/CPO, the exec team is your primary operating environment.
|
||||
|
||||
**Loudest voice bias** — Forming early opinions from the most vocal person met in Month 1. Only act on themes confirmed by 3+ independent sources.
|
||||
|
||||
**Conflating VP and CPO** — Treating Director-to-VP and VP-to-CPO as the same move at different scale. VP-to-CPO is a qualitative change (product-first to business-first), not scope expansion.
|
||||
|
||||
**One-and-done cascade** — Running the Context Map once at annual planning, never revisiting. Revisit at major inflection points: quarterly planning, exec changes, pivots, restructuring.
|
||||
|
||||
**Kindness confusion** — Shielding teams from hard decisions, softening feedback into meaninglessness. Be transparent about the "why." What you share should be honest and actionable.
|
||||
@@ -0,0 +1,375 @@
|
||||
# Discovery & Research
|
||||
|
||||
Compressed decision logic, frameworks, and quality gates for running product discovery end-to-end: framing problems, interviewing customers, mapping jobs and journeys, generating solutions, and validating hypotheses before committing to build.
|
||||
|
||||
## Problem Framing
|
||||
|
||||
### Problem Statement (Component)
|
||||
|
||||
**Template -- write from the user's perspective:**
|
||||
|
||||
```
|
||||
I am: [persona with 3-4 key characteristics]
|
||||
Trying to: [desired outcome -- measurable, not a task]
|
||||
But: [barriers preventing the outcome]
|
||||
Because: [root cause, not symptom]
|
||||
Which makes me feel: [authentic emotion from research]
|
||||
```
|
||||
|
||||
**Final statement formula:** `[Persona] needs a way to [outcome] because [root cause], which currently [impact].`
|
||||
|
||||
**Quality gates:**
|
||||
- "I am" passes if you can picture a real person (not "busy professionals")
|
||||
- "Trying to" is an outcome, not an activity
|
||||
- "Because" survives 5-why interrogation
|
||||
- "Makes me feel" uses verbatim customer language, not marketing copy
|
||||
- Final statement fits one sentence and is measurable
|
||||
|
||||
**Top anti-patterns:**
|
||||
1. **Solution smuggling** -- "The problem is we don't have X." Fix: reframe around user outcome.
|
||||
2. **Business problem disguised as user problem** -- "Users want to reduce our churn." Fix: dig into why users leave from their perspective.
|
||||
3. **Symptom instead of root cause** -- "Because the UI is confusing." Fix: keep asking "why" until you hit structural cause.
|
||||
|
||||
---
|
||||
|
||||
### Problem Framing Canvas (MITRE, Interactive)
|
||||
|
||||
**Three-phase bias-check before you write a problem statement.**
|
||||
|
||||
**Phase 1 -- Look Inward:**
|
||||
- What is the problem? (symptoms only)
|
||||
- Why haven't we solved it? (new / hard / low priority / lack of resources / authority / systemic inequity)
|
||||
- How are we part of the problem? (confirmation bias / internal bias / survivorship bias / premature convergence)
|
||||
|
||||
**Phase 2 -- Look Outward:**
|
||||
- Who experiences it? When, where, consequences?
|
||||
- Who else has it? Who doesn't? (counter-examples reveal root cause)
|
||||
- Who's been left out of the conversation?
|
||||
- Who benefits from the problem existing? Who benefits from it being solved?
|
||||
|
||||
**Phase 3 -- Reframe:**
|
||||
- Restate: "[Who] struggles to [what] because [root cause], leading to [consequence]. Affects [segments], overlooked because [bias]."
|
||||
- HMW: "How might we [action] as we aim to [objective]?"
|
||||
|
||||
**Quality gates:**
|
||||
- HMW is broad enough to permit multiple solutions, narrow enough to be actionable
|
||||
- Canvas was completed cross-functionally, not solo
|
||||
- "Who benefits from the status quo?" was explicitly answered
|
||||
|
||||
**Top anti-patterns:**
|
||||
1. **Skipping Look Inward** -- groupthink persists. Fix: force explicit bias discussion.
|
||||
2. **Generic reframe** -- "Improve user experience." Fix: include who, what, when, consequence, root cause.
|
||||
3. **HMW too narrow** -- "How might we add a mobile app?" Fix: state the job, not the solution.
|
||||
|
||||
---
|
||||
|
||||
## Customer Discovery
|
||||
|
||||
### Discovery Process (Workflow, 6 phases / 3-4 weeks)
|
||||
|
||||
```
|
||||
Phase 1: Frame (Day 1-2)
|
||||
-> Problem Framing Canvas (120 min) + Problem Statement (30 min)
|
||||
-> Optional: Proto-Persona, JTBD
|
||||
-> Output: problem hypothesis, 3-5 research questions, success criteria
|
||||
-> Gate: enough context to start research? If no, gather data first (+2-3 days)
|
||||
|
||||
Phase 2: Plan Research (Day 3)
|
||||
-> Discovery Interview Prep (90 min)
|
||||
-> Recruit 5-10 participants, schedule across 1-2 weeks
|
||||
-> Output: interview guide (5-7 Mom Test questions), participant roster
|
||||
|
||||
Phase 3: Conduct Research (Week 1-2)
|
||||
-> 5-10 interviews + support ticket analysis + analytics review
|
||||
-> Note template per interview: participant, context, actions, pain points, workarounds, verbatim quotes, insights
|
||||
-> Gate: saturation? Same pains across 3+ interviews = proceed. Still learning = +3-5 interviews.
|
||||
|
||||
Phase 4: Synthesize (End of Week 2)
|
||||
-> Affinity mapping: sticky notes -> themed clusters with frequency counts
|
||||
-> Optional: Customer Journey Map workshop
|
||||
-> Prioritize: score each pain on frequency x intensity x strategic fit (1-5 each)
|
||||
-> Output: top 3-5 pain points, 3-5 verbatim quotes per pain, validated problem statement
|
||||
|
||||
Phase 5: Generate & Validate Solutions (Week 3)
|
||||
-> Opportunity Solution Tree OR Lean UX Canvas
|
||||
-> Design experiments: concierge / prototype / landing page / A/B test
|
||||
-> Run experiments (1-2 weeks each)
|
||||
-> Gate: validated? If no, pivot to next solution (+1-2 weeks)
|
||||
|
||||
Phase 6: Decide & Document (Week 3-4)
|
||||
-> GO (roadmap + epics + PRD) / PIVOT (next solution) / KILL (deprioritize)
|
||||
-> 30-min stakeholder readout: problem validation, solution validation, recommendation
|
||||
```
|
||||
|
||||
**Timeline ranges:** fast track 3 weeks (5 interviews, 1 experiment) | typical 4 weeks | thorough 6-8 weeks.
|
||||
|
||||
**Top anti-patterns:**
|
||||
1. **Skipping interviews** -- relying only on analytics. Fix: always 5-10 qualitative interviews.
|
||||
2. **Analysis paralysis** -- 6 weeks synthesizing. Fix: time-box to 3-4 weeks total.
|
||||
3. **Discovery as one-time event** -- run continuous (Teresa Torres: 1 interview/week).
|
||||
|
||||
---
|
||||
|
||||
### Interview Prep (Interactive, 4 adaptive questions)
|
||||
|
||||
**Q1 -- Research Goal:** problem validation | JTBD discovery | retention/churn investigation | feature prioritization
|
||||
|
||||
**Q2 -- Target Segment:** people who experience problem regularly | people who tried to solve it | people in target segment regardless of awareness | people who recently experienced it
|
||||
|
||||
**Q3 -- Constraints:** limited access (5-10, 2 weeks) | existing base (100+ customers) | cold outreach required | internal stakeholders only (proxy)
|
||||
|
||||
**Q4 -- Methodology (context-aware on Q1-Q3):**
|
||||
- **Mom Test (Rob Fitzpatrick — problem validation):** past behavior, not hypotheticals. "Tell me about the last time..."
|
||||
- **JTBD interviews:** what customers hire/fire. "What were you trying to get done?"
|
||||
- **Switch interviews:** push/pull of changing solutions. "What prompted you to look?"
|
||||
- **Timeline/journey mapping:** chronological walkthrough of full experience
|
||||
|
||||
**Output: interview plan with opening (5 min), 5 core questions with follow-ups and anti-patterns, closing (5 min), bias checklist, success criteria, logistics.**
|
||||
|
||||
**5 biases to avoid in every interview:**
|
||||
1. Confirmation bias -- don't ask "Don't you think X is a problem?"
|
||||
2. Leading questions -- don't ask "Would you use this?"
|
||||
3. Hypothetical questions -- don't ask "If we built Y, would you pay?"
|
||||
4. Pitching disguised as research -- don't explain your solution
|
||||
5. Yes/no questions -- don't ask "Is invoicing hard?"
|
||||
|
||||
**Interview success = specific stories (not generic complaints) + past behavior (not wishes) + patterns across 3+ interviews + at least one surprise.**
|
||||
|
||||
**Top anti-patterns:**
|
||||
1. **Asking what customers want** -- gets feature requests, not problems. Fix: ask about past behavior.
|
||||
2. **Pitching instead of listening** -- don't mention your solution until last 5 min (if at all).
|
||||
3. **Stopping at 1-2 interviews** -- small sample = confirmation bias. Fix: 5-10 minimum.
|
||||
|
||||
---
|
||||
|
||||
## Jobs to Be Done
|
||||
|
||||
### JTBD Framework (Component)
|
||||
|
||||
**Three categories of customer jobs:**
|
||||
|
||||
| Type | Question | Examples |
|
||||
|------|----------|----------|
|
||||
| **Functional** | What tasks to complete? | "Reconcile monthly expenses for tax filing" |
|
||||
| **Social** | How to be perceived? | "Be seen as strategic by exec team" |
|
||||
| **Emotional** | What state to achieve/avoid? | "Feel confident I'm not missing details" |
|
||||
|
||||
**Four categories of pains:**
|
||||
- **Challenges:** obstacles preventing job completion
|
||||
- **Costliness:** excessive time, money, or effort
|
||||
- **Common mistakes:** preventable errors
|
||||
- **Unresolved problems:** gaps in current solutions
|
||||
|
||||
**Four categories of gains:**
|
||||
- **Expectations:** what exceeds current solutions
|
||||
- **Savings:** time/money/effort reductions
|
||||
- **Adoption factors:** what triggers switching
|
||||
- **Life improvement:** how life gets better
|
||||
|
||||
**Quality gates for jobs:**
|
||||
- Verb-driven (actions, not nouns)
|
||||
- Solution-agnostic ("communicate with team" not "use Slack")
|
||||
- Specific ("track expenses for tax deductions" not "manage finances")
|
||||
|
||||
**Prioritization:** rank pains by intensity (acute vs. mild). Ask: "If we solved one pain, which has biggest impact?"
|
||||
|
||||
**Top anti-patterns:**
|
||||
1. **Confusing jobs with solutions** -- "I need Slack." Fix: ask "Why?" 5 times.
|
||||
2. **Ignoring social/emotional jobs** -- people buy on emotion, justify with logic. Fix: explicitly ask about perception and feelings.
|
||||
3. **Fabricating JTBD without research** -- assumptions aren't insights. Fix: conduct switch interviews or contextual inquiries.
|
||||
|
||||
---
|
||||
|
||||
## Opportunity Mapping
|
||||
|
||||
### Opportunity Solution Tree (Teresa Torres — Interactive, 2 phases)
|
||||
|
||||
**Structure:**
|
||||
```
|
||||
Desired Outcome (1 measurable metric)
|
||||
|
|
||||
+-- Opportunity 1 (customer problem, not solution)
|
||||
| +-- Solution A + experiment
|
||||
| +-- Solution B + experiment
|
||||
| +-- Solution C + experiment
|
||||
|
|
||||
+-- Opportunity 2
|
||||
| +-- Solutions...
|
||||
|
|
||||
+-- Opportunity 3
|
||||
+-- Solutions...
|
||||
```
|
||||
|
||||
**Phase 1 -- Generate tree:**
|
||||
1. Extract desired outcome (revenue growth / retention / acquisition / efficiency)
|
||||
2. Generate 3 opportunities per outcome (customer problems with evidence)
|
||||
3. Generate 3 solutions per opportunity (with hypothesis + experiment for each)
|
||||
|
||||
**Phase 2 -- Select POC:**
|
||||
- Score each solution: Feasibility (1-5) + Impact (1-5) + Market Fit (1-5)
|
||||
- Feasibility: 1 = months, 5 = days. Impact: 1 = minimal, 5 = major. Market Fit: 1 = customers don't care, 5 = actively request.
|
||||
- Pick highest total score as POC. Define experiment type: A/B test, prototype + usability, or concierge.
|
||||
|
||||
**Hypothesis template:** "If we [solution], then [metric] will [change] from [X] to [Y] because [rationale]."
|
||||
|
||||
**Top anti-patterns:**
|
||||
1. **Opportunities disguised as solutions** -- "We need a mobile app." Fix: reframe as customer problem: "Mobile users can't access product on the go."
|
||||
2. **Skipping divergence** -- "We know the solution." Fix: generate 3+ per opportunity. Force divergence before convergence.
|
||||
3. **No experiments** -- picking solution and going to roadmap. Fix: every solution must map to an experiment.
|
||||
4. **Vague outcomes** -- "Improve UX." Fix: make measurable: "Reduce drop-off from 60% to 40%."
|
||||
|
||||
---
|
||||
|
||||
## Customer Journey
|
||||
|
||||
### Journey Map (Component)
|
||||
|
||||
**Horizontal axis (stages):** Awareness -> Consideration -> Decision -> Service -> Loyalty
|
||||
|
||||
**Vertical axis (per stage):**
|
||||
- Customer Actions (observable, specific)
|
||||
- Touchpoints (digital + physical + human)
|
||||
- Customer Experience (emotions with customer quotes)
|
||||
- KPIs (measurable, stage-appropriate)
|
||||
- Business Goals (outcome-focused, stage-aligned)
|
||||
- Teams Involved (cross-functional with specific roles)
|
||||
|
||||
**Quality gates:**
|
||||
- Emotions are specific ("relieved setup took 30 min, not 3 hours") not generic ("happy")
|
||||
- Touchpoints include offline (conferences, calls), not just digital
|
||||
- Map reflects what customers actually do, not what you want them to do
|
||||
- KPIs and goals present for every stage
|
||||
|
||||
---
|
||||
|
||||
### Journey Mapping Workshop (Interactive, 5 questions)
|
||||
|
||||
**Q1 -- Actor:** select persona (primary / secondary / high-churn / newly discovered)
|
||||
**Q2 -- Scenario + Goal:** first-time use / core workflow / problem resolution / upgrade-expansion
|
||||
**Q3 -- Journey Phases:** generate 4-6 phases based on scenario (e.g., Discover -> Evaluate -> Try -> Activate -> Use -> Expand)
|
||||
**Q4 -- Per-phase mapping:** 3-5 actions, thoughts, emotions, and pain points per phase
|
||||
**Q5 -- Opportunities:** rank 5-7 pain points by impact (HIGH/MEDIUM/LOW) with evidence
|
||||
|
||||
**Output:** full journey map + prioritized opportunity list.
|
||||
|
||||
**Top anti-patterns:**
|
||||
1. **Mapping internal process, not customer experience** -- "Lead generated -> Qualified -> Demo." Fix: map from customer POV.
|
||||
2. **No emotions** -- actions only. Fix: add customer quotes and emotional states.
|
||||
3. **Too many personas in one map** -- loses focus. Fix: one map per persona.
|
||||
|
||||
---
|
||||
|
||||
## Lean Validation
|
||||
|
||||
### Lean UX Canvas (v2, Interactive, 8 boxes)
|
||||
|
||||
**Fill order:**
|
||||
|
||||
| Box | Question | Content Type |
|
||||
|-----|----------|-------------|
|
||||
| 1. Business Problem | What changed that created a problem? | Context + trigger |
|
||||
| 2. Business Outcomes | What behavior change = success? | Metrics (not emotions) |
|
||||
| 3. Users | Which persona first? | Specific segment |
|
||||
| 4. User Outcomes & Benefits | Why would users seek this? | Goals, emotions, empathy (not metrics) |
|
||||
| 5. Solutions | What might solve it? | 3+ candidate features/initiatives |
|
||||
| 6. Hypotheses | Testable if/then statements | "We believe [outcome] if [user] attains [benefit] with [solution]" |
|
||||
| 7. Learn First | What's the riskiest assumption? | Value > usability > feasibility > viability risk |
|
||||
| 8. Least Work | Smallest experiment to test it? | Must complete in <2 weeks |
|
||||
|
||||
**Box 2 vs Box 4 distinction:** Box 2 = behavior change metrics. Box 4 = human motivation and empathy.
|
||||
|
||||
**Top anti-patterns:**
|
||||
1. **Starting with solutions** -- Box 1 says "build X." Fix: ask "What changed? Why is this a problem now?"
|
||||
2. **Confusing Box 2 and Box 4** -- metrics in the empathy box. Fix: Box 2 = numbers, Box 4 = feelings.
|
||||
3. **Only one solution in Box 5** -- no exploration. Fix: force 3+ candidates.
|
||||
4. **Skipping experiments** -- "just build it." Fix: design smallest test first.
|
||||
|
||||
---
|
||||
|
||||
### PoL Probe (Component) -- Proof of Life
|
||||
|
||||
**A disposable, hypothesis-driven validation artifact. Not an MVP. Planned for deletion.**
|
||||
|
||||
**5 required characteristics:** Lightweight (hours/days) + Disposable (deletion date set) + Narrow Scope (one hypothesis) + Brutally Honest (surfaces harsh truth) + Tiny & Focused (reconnaissance, not product).
|
||||
|
||||
**Template fields:** hypothesis, risk being eliminated, probe type, target users, success criteria (pass/fail/learn thresholds), tools, timeline, disposal plan, owner, status.
|
||||
|
||||
**5 Probe Flavors:**
|
||||
|
||||
| Flavor | Core Question | Timeline | When to Use |
|
||||
|--------|---------------|----------|-------------|
|
||||
| Feasibility Check | Can we build this? | 1-2 days | Technical unknowns, API deps, data integrity |
|
||||
| Task-Focused Test | Can users complete this job? | 2-5 days | Critical UI moments, navigation, drop-off zones |
|
||||
| Narrative Prototype | Does this earn buy-in? | 1-3 days | Complex flow explanation, stakeholder alignment |
|
||||
| Synthetic Data Simulation | Can we model without production risk? | 2-4 days | Edge cases, unknown-unknowns, load testing |
|
||||
| Vibe-Coded Probe | Will this survive real user contact? | 2-3 days | Workflow/UX validation needing real interaction |
|
||||
|
||||
**Golden Rule:** Use the cheapest prototype that tells the harshest truth.
|
||||
|
||||
---
|
||||
|
||||
### PoL Probe Advisor (Interactive, decision logic)
|
||||
|
||||
**Selection flow:** hypothesis -> risk type -> core question -> recommended probe.
|
||||
|
||||
**Decision matrix:**
|
||||
- Technical feasibility unknown -> **Feasibility Check** (spike-and-delete, API sniff tests)
|
||||
- Critical UI friction -> **Task-Focused Test** (Optimal Workshop, UsabilityHub, Maze)
|
||||
- Need stakeholder alignment -> **Narrative Prototype** (Loom walkthrough, slideware storyboard)
|
||||
- Edge case exploration -> **Synthetic Data Simulation** (Monte Carlo, synthetic users, LangFlow)
|
||||
- Need real user interaction -> **Vibe-Coded Probe** (ChatGPT Canvas + Replit + Airtable Frankensoft)
|
||||
|
||||
**Refinement questions when hypothesis is too broad:**
|
||||
1. What's the smallest thing you could test first?
|
||||
2. What would failure look like?
|
||||
3. Is this testing user behavior, technical feasibility, or stakeholder alignment? Pick one.
|
||||
|
||||
**Top anti-patterns:**
|
||||
1. **Choosing based on tooling comfort** -- "I know Figma, so I'll prototype." Fix: match method to hypothesis, not skillset.
|
||||
2. **Defaulting to code** -- "Let's just build it." Fix: ask what's cheapest path to harsh truth.
|
||||
3. **Confusing vibe-coded probes with MVPs** -- scope creep, refusal to dispose. Fix: set disposal date before building.
|
||||
4. **Testing multiple things at once** -- ambiguous results. Fix: one probe, one hypothesis.
|
||||
5. **No success criteria** -- "we'll know it when we see it." Fix: define pass/fail/learn before building.
|
||||
|
||||
---
|
||||
|
||||
## Quality Gates
|
||||
|
||||
### Consolidated Anti-Patterns Across All 11 Skills
|
||||
|
||||
**Problem framing failures:**
|
||||
- Solution smuggling in problem statements
|
||||
- Business metrics framed as user problems
|
||||
- Generic personas ("busy professionals")
|
||||
- Skipping bias examination (Look Inward)
|
||||
|
||||
**Research failures:**
|
||||
- Leading / hypothetical / yes-no questions
|
||||
- Pitching disguised as research
|
||||
- Stopping at 1-2 interviews (need 5-10 minimum)
|
||||
- Not recording insights immediately post-interview
|
||||
- Never reaching saturation (same patterns in 3+ interviews)
|
||||
|
||||
**Synthesis failures:**
|
||||
- Analysis paralysis (6+ weeks, no decisions)
|
||||
- Opportunities disguised as solutions in OST
|
||||
- Vague outcomes that can't be measured
|
||||
- Journey maps reflecting internal wishful thinking, not customer reality
|
||||
- Generic emotions ("happy") instead of specific states
|
||||
|
||||
**Validation failures:**
|
||||
- Prototype theater (impressive demos that teach nothing)
|
||||
- Choosing validation method by tooling comfort, not hypothesis
|
||||
- Testing multiple variables in one experiment
|
||||
- No pre-defined failure criteria
|
||||
- Treating disposable probes as production code
|
||||
- Discovery as one-time event instead of continuous practice
|
||||
|
||||
### Universal Quality Checks
|
||||
|
||||
Every discovery artifact should pass these:
|
||||
1. **Falsifiable:** can you describe what failure looks like?
|
||||
2. **Evidence-backed:** grounded in customer research, not assumptions?
|
||||
3. **Specific:** can you picture the person, the problem, the metric?
|
||||
4. **Actionable:** does it inform a concrete next step?
|
||||
5. **Time-boxed:** is there a deadline that prevents indefinite exploration?
|
||||
@@ -0,0 +1,260 @@
|
||||
# Finance & Metrics
|
||||
|
||||
Compressed reference for SaaS finance: 32 metrics with formulas and benchmarks, diagnostic frameworks, and decision logic for feature investment, channel evaluation, and pricing changes.
|
||||
|
||||
## SaaS Revenue & Growth Metrics
|
||||
|
||||
### Core Revenue Metrics
|
||||
|
||||
| Metric | Formula | Benchmarks |
|
||||
|--------|---------|------------|
|
||||
| **Revenue** | Sum of all customer payments in period | Growth rate >20% YoY (varies by stage) |
|
||||
| **ARPU** | Total Revenue / Total Users | B2C: $5-50/mo; B2B: $50-500+/mo; track trend |
|
||||
| **ARPA** | MRR / Active Accounts | SMB: $100-$1K/mo; Mid: $1K-$10K; Ent: $10K+ |
|
||||
| **ACV** | Annual Recurring Revenue per Contract (exclude one-time fees) | SMB: $5K-$25K; Mid: $25K-$100K; Ent: $100K+ |
|
||||
| **MRR/ARR** | MRR = sum of recurring subs; ARR = MRR x 12 | Track components: New + Expansion - Churned - Contraction |
|
||||
| **Gross vs Net Revenue** | Net = Gross - Discounts - Refunds - Credits | Refunds >10% = product problem; Discounts >20% = pricing power problem |
|
||||
|
||||
**ARPA/ARPU combined analysis:** Average Seats per Account = ARPA / ARPU. High ARPA + low ARPU = undermonetized seats. Low ARPA + high ARPU = small deal sizes.
|
||||
|
||||
### Retention & Expansion Metrics
|
||||
|
||||
| Metric | Formula | Benchmarks |
|
||||
|--------|---------|------------|
|
||||
| **Churn Rate (Logo)** | Customers Lost / Starting Customers | Monthly: <2% great, 2-5% ok, >5% crisis |
|
||||
| **Churn Rate (Revenue)** | MRR Lost / Starting MRR | Annual: <10% great, 10-30% ok, >30% crisis |
|
||||
| **NRR** | (Start ARR + Expansion - Churn - Contraction) / Start ARR x 100 | >120% excellent; 100-120% good; <90% problem |
|
||||
| **Expansion Revenue** | Upsells + Cross-sells + Usage Growth | Should be 20-30% of total revenue |
|
||||
| **Quick Ratio** | (New MRR + Expansion MRR) / (Churned MRR + Contraction MRR) | >4 excellent; 2-4 healthy; <2 leaky bucket |
|
||||
|
||||
**Churn compounding:** 3% monthly != 36% annual. Use `Annual Churn = 1 - (1 - Monthly)^12`. 3% monthly = ~31% annual. 5% monthly = ~46% annual.
|
||||
|
||||
### Analysis Frameworks
|
||||
|
||||
**Revenue Mix:** Product/Segment Revenue / Total Revenue x 100. No single product >60% ideal. Top customer <10% revenue; top 10 <40%.
|
||||
|
||||
**Cohort Analysis:** Group customers by join date, track retention/expansion over time. Recent cohorts should perform same or better than older ones. If newer cohorts degrade, PMF is eroding -- stop scaling, fix product.
|
||||
|
||||
## Unit Economics & Efficiency
|
||||
|
||||
### Customer-Level Profitability
|
||||
|
||||
| Metric | Formula | Benchmarks |
|
||||
|--------|---------|------------|
|
||||
| **Gross Margin** | (Revenue - COGS) / Revenue x 100 | SaaS: 70-85% good; <60% concerning |
|
||||
| **CAC** | Total S&M Spend / New Customers Acquired | Enterprise: $10K+ ok; SMB: <$500 target |
|
||||
| **LTV (simple)** | ARPU x Avg Customer Lifetime (months) | Must be 3x+ CAC |
|
||||
| **LTV (better)** | ARPU x Gross Margin % / Monthly Churn Rate | Use this for decisions |
|
||||
| **LTV:CAC** | LTV / CAC | <1:1 unsustainable; 1-3:1 marginal; 3-5:1 healthy; >5:1 underinvesting |
|
||||
| **Payback Period** | CAC / (Monthly ARPU x Gross Margin %) | <12mo great; 12-18 ok; >24 concerning |
|
||||
| **Contribution Margin** | (Revenue - All Variable Costs) / Revenue x 100 | 60-80% good; <40% concerning |
|
||||
| **Gross Margin Payback** | CAC / (Monthly ARPU x Gross Margin %) | Same formula as Payback above; use this version |
|
||||
|
||||
**COGS includes:** Hosting, infrastructure, payment processing, customer onboarding costs.
|
||||
**Variable costs include:** COGS + support + payment processing + variable customer success.
|
||||
|
||||
**Critical insight:** 4:1 LTV:CAC with 36-month payback is a cash trap. 3:1 LTV:CAC with 8-month payback is better for growth.
|
||||
|
||||
### Capital Efficiency
|
||||
|
||||
| Metric | Formula | Benchmarks |
|
||||
|--------|---------|------------|
|
||||
| **Burn Rate (Gross)** | Total Monthly Cash Spent | Context-dependent |
|
||||
| **Burn Rate (Net)** | Monthly Cash Spent - Monthly Revenue | Early <$200K manageable; >$500K needs revenue path |
|
||||
| **Runway** | Cash Balance / Monthly Net Burn | 12+ good; 6-12 ok; <6 crisis. Raise at 6-9 months, not 3 |
|
||||
| **OpEx** | S&M + R&D + G&A | Should grow slower than revenue |
|
||||
| **Net Income** | Revenue - COGS - OpEx | Early negative ok; mature 10-20%+ margin |
|
||||
|
||||
**Working capital:** Annual contracts paid upfront boost cash. Monthly billing delays collection. Cash-based runway != revenue-based runway.
|
||||
|
||||
### Efficiency Ratios
|
||||
|
||||
| Metric | Formula | Benchmarks |
|
||||
|--------|---------|------------|
|
||||
| **Rule of 40** | Revenue Growth % + Profit Margin % | >40 healthy; 25-40 ok; <25 concerning |
|
||||
| **Magic Number** | (Q Revenue - Prev Q Revenue) x 4 / Prev Q S&M Spend | >0.75 scale; 0.5-0.75 optimize; <0.5 fix GTM |
|
||||
| **Operating Leverage** | Revenue Growth Rate vs OpEx Growth Rate | Revenue growth must exceed OpEx growth |
|
||||
|
||||
**Rule of 40 by stage:** Early = 60% growth + (-20%) margin = 40. Growth = 40% + 5% = 45. Mature = 20% + 25% = 45.
|
||||
|
||||
## Business Health Diagnostic
|
||||
|
||||
### Four-Dimension Framework
|
||||
|
||||
1. **Growth & Retention** -- Revenue growth, NRR, churn, Quick Ratio
|
||||
2. **Unit Economics** -- CAC, LTV, LTV:CAC, payback, gross margin
|
||||
3. **Capital Efficiency** -- Burn, runway, Rule of 40, Magic Number
|
||||
4. **Strategic Position** -- Market pricing, moat, concentration, leverage
|
||||
|
||||
### Stage-Specific Benchmarks
|
||||
|
||||
| Metric | Early (<$10M ARR) | Growth ($10-50M) | Scale ($50M+) |
|
||||
|--------|-------------------|-------------------|---------------|
|
||||
| Growth YoY | >50% | >40% | >25% |
|
||||
| LTV:CAC | >3:1 | -- | -- |
|
||||
| NRR | -- | >100% | >110% |
|
||||
| Gross Margin | >70% | -- | -- |
|
||||
| Rule of 40 | -- | >40 | >40 |
|
||||
| Magic Number | -- | >0.75 | -- |
|
||||
| Profit Margin | negative ok | -- | >10% |
|
||||
| Runway | >12 months | -- | positive cash flow |
|
||||
|
||||
### Red Flag Severity
|
||||
|
||||
**Critical (fix immediately):** Runway <6mo, LTV:CAC <1.5:1, churn accelerating cohort-over-cohort, NRR <90%, Magic Number <0.3.
|
||||
|
||||
**High priority (fix within quarter):** Rule of 40 <25, payback >24mo, Quick Ratio <2, gross margin <60%, revenue concentration >50% in top 10.
|
||||
|
||||
**Medium priority (address within 6 months):** NRR 90-100%, Magic Number 0.3-0.5, negative operating leverage, stable but high churn (>5% monthly).
|
||||
|
||||
### Diagnostic Scoring
|
||||
|
||||
- **Healthy:** All dimensions at/above stage benchmarks, no critical flags, improving trends. Action: scale aggressively.
|
||||
- **Moderate:** 1-2 dimensions need attention, medium-priority flags. Action: fix specific issues before scaling further.
|
||||
- **Concerning:** Multiple critical flags, 2+ dimensions problematic. Action: urgent intervention -- stop scaling, fix retention and unit economics.
|
||||
- **Critical:** Runway <3mo or LTV:CAC <1:1. Action: survival mode -- emergency fundraise or cut burn 50%+.
|
||||
|
||||
## Feature Investment Analysis
|
||||
|
||||
### Revenue Connection Types
|
||||
|
||||
1. **Direct monetization** -- new tier, paid add-on, usage fee. Calculate: Customer Base x Adoption Rate x Price.
|
||||
2. **Retention improvement** -- addresses churn reason. Calculate: LTV Impact = Lifetime Increase x Base x ARPU x Margin.
|
||||
3. **Conversion improvement** -- trial-to-paid lift. Calculate: Trial Users x Conversion Lift x ARPU.
|
||||
4. **Expansion enabler** -- upsell/cross-sell path. Calculate: Base x Expansion Rate x ARPU Increase.
|
||||
|
||||
### ROI Thresholds
|
||||
|
||||
| Scenario | Build if | Don't build if |
|
||||
|----------|----------|----------------|
|
||||
| Direct monetization | ROI >3x year one | Negative contribution margin in downside case |
|
||||
| Retention feature | LTV impact >10x dev cost | Payback exceeds avg customer lifetime |
|
||||
| Strategic override | Competitive moat, platform enabler, compliance | "Strategic" without clear definition |
|
||||
|
||||
### Cost Structure Check
|
||||
|
||||
- One-time: development cost (team size x time)
|
||||
- Ongoing: COGS impact (hosting, infra) + OpEx (support, maintenance)
|
||||
- Margin impact: if COGS >20% of projected revenue, flag margin dilution
|
||||
- Contribution margin: (Revenue - COGS) / Revenue must stay positive
|
||||
|
||||
### Decision Patterns
|
||||
|
||||
**Build now:** ROI >3:1 (direct) or LTV impact >10:1 (retention), positive contribution margin, payback < customer lifetime.
|
||||
|
||||
**Build for strategic reasons:** ROI <2:1 but competitive moat, platform enabler, or compliance. Cap investment, monitor adoption, re-evaluate at 6 months.
|
||||
|
||||
**Don't build:** ROI <1:1, negative contribution margin, no strategic value. Consider reducing scope or changing monetization.
|
||||
|
||||
**Build later:** High uncertainty in adoption or impact assumptions. Validate with surveys, prototypes, churn interviews first.
|
||||
|
||||
## Channel Economics
|
||||
|
||||
### Channel Evaluation Framework
|
||||
|
||||
Evaluate each channel on four dimensions:
|
||||
|
||||
1. **Unit economics** -- CAC, LTV, LTV:CAC, payback (per channel, not blended)
|
||||
2. **Customer quality** -- cohort retention, churn rate, NRR, ICP fit (per channel)
|
||||
3. **Scalability** -- Magic Number, addressable volume, CAC trend
|
||||
4. **Strategic fit** -- segment match, sales motion compatibility
|
||||
|
||||
### Channel Decision Matrix
|
||||
|
||||
| LTV:CAC | Payback | Customer Quality | Scalability | Decision |
|
||||
|---------|---------|------------------|-------------|----------|
|
||||
| >3:1 | <12mo | Good retention | High volume | **Scale aggressively** |
|
||||
| 2-3:1 | 12-18mo | Average retention | Medium | **Test & optimize** |
|
||||
| <2:1 | >18mo | Poor retention | Low | **Kill or fix** |
|
||||
|
||||
### Scale Criteria
|
||||
|
||||
Scale when ALL met: LTV:CAC >3:1 AND payback <12mo AND Magic Number >0.75 AND customer quality >= blended. Increase budget 50-100%, monitor weekly for CAC increase >20% (saturation signal).
|
||||
|
||||
### Optimize Playbook
|
||||
|
||||
- **If CAC too high:** Improve conversion rate, reduce cost-per-click, shorten sales cycle.
|
||||
- **If LTV too low:** Improve onboarding for channel cohort, target higher-value segments, add expansion plays.
|
||||
- **If targeting off:** Narrow audience, improve messaging, add qualification step.
|
||||
- Timeline: 4-8 weeks. Target LTV:CAC >3:1, payback <12mo. If unachievable, kill.
|
||||
|
||||
### Kill Criteria
|
||||
|
||||
LTV:CAC <1.5:1 with no clear improvement path. Reallocate budget to top-performing channel. Exception: strategic channels (enterprise field sales) get capped spend and 6-12 month runway to prove out.
|
||||
|
||||
### Incrementality
|
||||
|
||||
Test with holdout groups. Only count truly incremental conversions. Retargeting campaigns often claim credit for conversions that would have happened organically.
|
||||
|
||||
## Pricing Analysis
|
||||
|
||||
### Pricing Change Types
|
||||
|
||||
- **Price increase** -- new customers only (grandfather existing) vs all customers
|
||||
- **New premium tier** -- upsell path, watch cannibalization
|
||||
- **Paid add-on** -- monetize feature; assess retention risk if previously free
|
||||
- **Usage-based** -- charge per unit (seats, API calls, storage); enables expansion revenue
|
||||
- **Discount strategy** -- annual prepay (cash flow), volume (larger deals), promotional (urgency)
|
||||
- **Packaging change** -- rebundle features, change pricing metric
|
||||
|
||||
### Five-Dimension Impact Assessment
|
||||
|
||||
1. **Revenue:** ARPU lift = (New ARPU - Current ARPU) / Current ARPU. Expected MRR increase = Base x ARPU Lift.
|
||||
2. **Conversion:** Higher prices may reduce trial-to-paid. Model conversion drop and its effect on new customer volume.
|
||||
3. **Churn:** Model scenarios -- conservative (+2pp churn), base (+1pp), optimistic (+0). Churn-driven MRR loss = additional churn % x base x new ARPU.
|
||||
4. **Expansion:** Does change create upsell path? Usage-based pricing enables natural expansion as customers grow.
|
||||
5. **CAC Payback:** Higher ARPU = faster payback, but lower conversion = higher effective CAC. Calculate net effect.
|
||||
|
||||
### Decision Patterns
|
||||
|
||||
**Implement broadly:** Net revenue clearly positive (>10% ARPU lift, <5% churn risk), minimal conversion impact. Grandfather existing customers.
|
||||
|
||||
**Test first (A/B):** Uncertain impact, moderate risk. Test 60-90 days with 100+ customers per cohort. Roll out if conversion stays within acceptable range.
|
||||
|
||||
**Modify approach:** Original proposal too risky. Options: smaller increase, grandfather existing, segment-based pricing (raise enterprise only).
|
||||
|
||||
**Don't change:** Churn-driven loss exceeds revenue gains, or high competitive pressure. Focus on retention/expansion instead.
|
||||
|
||||
### Annual Discount Guardrails
|
||||
|
||||
Limit to 10-15% for annual prepay. 30% annual discounts destroy LTV. Balance cash flow improvement with revenue protection.
|
||||
|
||||
## Quality Gates
|
||||
|
||||
### Vanity Metric Traps
|
||||
|
||||
- **Revenue without margin:** $1M at 80% margin >> $2M at 20% margin
|
||||
- **ARPU growth from mix shift:** ARPU rose because small customers churned, not because monetization improved
|
||||
- **Signups without conversion:** 10,000 signups at 5% conversion = 500 customers. Calculate CAC on paid, not signups
|
||||
- **Engagement without revenue:** Feature increases engagement but not retention or monetization -- not a business outcome
|
||||
- **Gross revenue hiding net contraction:** Track discounts and refunds; gross up 20% but discounts doubled = flat net
|
||||
|
||||
### Blended Metric Dangers
|
||||
|
||||
Never use blended averages for decisions. Always segment by:
|
||||
- **Channel:** One channel at $10K CAC hides in $500 blended CAC
|
||||
- **Segment:** $100 ARPU blends $10 SMB and $1,000 enterprise -- useless for decisions
|
||||
- **Cohort:** Blended 3% churn hides newer cohorts at 6% and old cohorts at 1%
|
||||
- **Product:** 67% legacy product dying at -5% growth masked by 33% new product at +80%
|
||||
|
||||
### Common Calculation Errors
|
||||
|
||||
- **LTV without margin:** Use `ARPU x Margin % / Churn`, not `ARPU x Lifetime`
|
||||
- **Churn multiply-by-12:** Churn compounds. 3% monthly = 31% annual, not 36%
|
||||
- **Payback without margin:** Use gross margin payback, not revenue payback
|
||||
- **CAC comparison without payback:** $5K CAC with 24mo payback is worse than $8K CAC with 8mo payback
|
||||
- **Rule of 40 without runway:** Score of 50 means nothing with 3 months runway
|
||||
- **LTV:CAC without payback:** 6:1 ratio with 48-month payback is a cash trap
|
||||
|
||||
### Decision-Making Anti-Patterns
|
||||
|
||||
- Scaling acquisition when Quick Ratio <2 (leaky bucket)
|
||||
- Raising prices without modeling churn scenarios
|
||||
- Celebrating NRR >100% from low churn alone (not expansion-driven)
|
||||
- Using "strategic" as catch-all for building low-ROI features
|
||||
- Fixing everything simultaneously instead of prioritizing top 1-3 issues
|
||||
- Killing channels before 3-6 months and 100+ customers of data
|
||||
- Over-relying on one channel (>50% of acquisition)
|
||||
- Annual discounts >15% that destroy LTV for short-term cash
|
||||
- Testing pricing on 10 customers (need 100+ per cohort for significance)
|
||||
- Celebrating feature requests from 0.5% of base while ignoring the other 99.5%
|
||||
@@ -0,0 +1,241 @@
|
||||
# Strategy & Positioning
|
||||
|
||||
Compressed knowledge module covering company/market research, positioning, product strategy, prioritization, and roadmap planning.
|
||||
|
||||
## Company & Market Research
|
||||
|
||||
### Company Research Framework
|
||||
|
||||
Research across 7 dimensions: Company Overview, Executive Quotes, Product Insights, Transformation Strategies, Organizational Impact, Future Roadmap, Product-Led Growth.
|
||||
|
||||
**Research steps:**
|
||||
1. Define scope: company name, research purpose, 3 key questions
|
||||
2. Gather overview: headquarters, industry, founding, size, key milestones
|
||||
3. Extract executive quotes: CEO (vision), COO (operations), VP Product (strategy), Group PM (initiatives). Cite source + date. Prioritize last 12-24 months.
|
||||
4. Document product insights: strategy overview, recent launches with market impact, product philosophy/principles
|
||||
5. Identify transformation strategies: digital (architecture shifts), AI (ML in product), Agile (methodology adoption)
|
||||
6. Map organizational PM impact: PM role in strategic decisions, cross-functional collaboration model, career paths
|
||||
7. Analyze future roadmap: planned initiatives, anticipated challenges, competitive threats
|
||||
8. Document PLG insights: self-serve onboarding, data-driven decisions, activation/retention/expansion patterns
|
||||
9. Synthesize: 3 strategic principles, 3 PM lessons, unanswered questions
|
||||
|
||||
**Source priority:** Earnings transcripts > podcast interviews > conference talks > executive blog posts > LinkedIn > company website. Go deeper than "About Us" pages.
|
||||
|
||||
### PESTEL Analysis
|
||||
|
||||
Six macro-environmental factors. Define scope first: product name, analysis purpose, geographic scope, time horizon.
|
||||
|
||||
| Factor | Key Questions | Example Sources |
|
||||
|--------|--------------|-----------------|
|
||||
| **Political** | Government policies, stability, trade regs, taxation | Legislative databases, trade reports |
|
||||
| **Economic** | GDP growth, inflation, exchange rates, consumer spending | Census Bureau, BLS, World Bank |
|
||||
| **Social** | Demographics, cultural trends, lifestyle shifts, attitudes | Pew Research, demographic studies |
|
||||
| **Technological** | Advancements, R&D activity, automation, digital adoption | Gartner, industry reports |
|
||||
| **Environmental** | Climate impact, sustainability, resource scarcity, green regs | If impact is minimal, say so honestly |
|
||||
| **Legal** | Compliance (GDPR, AI Act), IP, employment law, safety regs | Legal databases, regulatory filings |
|
||||
|
||||
**For each factor:** State the specific impact on your product and what strategic action it implies. Generic statements ("regulations exist") are useless.
|
||||
|
||||
**Synthesis output:** Top 3 opportunities (with actions), top 3 threats (with mitigations), 3 strategic recommendations. Reassess annually or on major external events.
|
||||
|
||||
### TAM/SAM/SOM Calculation
|
||||
|
||||
Three-tier market sizing with citation-backed data.
|
||||
|
||||
**TAM** = Total market demand at 100% capture. Broadest possible.
|
||||
**SAM** = TAM narrowed by geography, firmographics, product constraints. "Who can we actually reach?"
|
||||
**SOM** = SAM narrowed by competition, GTM capacity. "What can we capture in 1-3 years?" Typically 1-20% of SAM in Year 1-3.
|
||||
|
||||
**Calculation process:**
|
||||
1. Define problem space (B2B SaaS, consumer fintech, healthcare, etc.)
|
||||
2. Select geographic region (US = Census/BLS data; EU = Eurostat; Global = World Bank/IMF)
|
||||
3. Identify industry segments with population + revenue data
|
||||
4. Narrow to target customer segment with firmographics/demographics
|
||||
|
||||
**Output format:** For each tier, show population estimate, market size ($), calculation math, source citation with URL, and key assumptions.
|
||||
|
||||
**Year 1-3 projections for SOM:** Include customer count and revenue. Ground in GTM constraints (sales capacity, conversion rates, marketing budget).
|
||||
|
||||
**Data sources:** US Census Bureau, BLS, IBISWorld, Statista, Gartner, Forrester, World Bank, Eurostat.
|
||||
|
||||
## Product Positioning
|
||||
|
||||
### Geoffrey Moore Positioning Statement
|
||||
|
||||
Two-part structure from *Crossing the Chasm*:
|
||||
|
||||
**Value Proposition:**
|
||||
- **For** [specific target customer/persona]
|
||||
- **that need** [underserved need -- pains, gains, JTBD]
|
||||
- [product name]
|
||||
- **is a** [product category]
|
||||
- **that** [benefit statement -- outcomes, not features]
|
||||
|
||||
**Differentiation Statement:**
|
||||
- **Unlike** [primary competitor or actual substitute behavior]
|
||||
- [product name]
|
||||
- **provides** [unique differentiation -- outcomes, not features]
|
||||
|
||||
### Stress Tests (apply to every draft)
|
||||
|
||||
1. Would the target customer recognize themselves in the "For" statement?
|
||||
2. Can you point to research validating the need?
|
||||
3. Does the category anchor you against the right competitors (or box you in)?
|
||||
4. Is differentiation provable with a demo, case study, or data?
|
||||
5. Does this positioning help answer "Should we build feature X?"
|
||||
|
||||
### Positioning Workshop Flow (Interactive)
|
||||
|
||||
5-question discovery sequence:
|
||||
1. **Target customer segment** -- B2B SMB / B2B Enterprise / B2C mass / B2C niche (or custom)
|
||||
2. **Underserved need** -- Adapted to segment from Q1 (time waste, lack of visibility, compliance burden, costly inefficiency)
|
||||
3. **Product category** -- Anchors buyer evaluation. Pick existing category unless you have strong rationale for category creation.
|
||||
4. **Key benefit** -- Outcome, not feature. Must be measurable (time saved, errors reduced, cost cut).
|
||||
5. **Competitive differentiation** -- Name the actual competitor or substitute behavior. Differentiate on outcomes.
|
||||
|
||||
Output: Complete positioning statement + one-sentence summary + stress-test checklist + next steps (test with 5 customers, share with stakeholders, apply to artifacts).
|
||||
|
||||
### Positioning Quality Criteria
|
||||
|
||||
- Target specificity: describable to a recruiter
|
||||
- Need clarity: emotionally resonant, not generic
|
||||
- Category fit: helps buyer evaluation, not "next-generation platform"
|
||||
- Outcome focus: what user gets, not what product has
|
||||
- Competitor honesty: real alternative buyers consider
|
||||
- Differentiation durability: not copyable in 6 months
|
||||
|
||||
## Product Strategy
|
||||
|
||||
### Strategy Session Phases (2-4 week process)
|
||||
|
||||
**Phase 1: Positioning & Market Context (Days 1-2)**
|
||||
- Run positioning workshop. Define proto-personas. Map JTBD.
|
||||
- Decision gate: Enough customer context? If NO, run 5-10 discovery interviews (+1 week).
|
||||
|
||||
**Phase 2: Problem Framing & Validation (Days 3-5)**
|
||||
- Run problem framing canvas. Create formal problem statement. Optional: customer journey map.
|
||||
- Decision gate: Problem validated? If NO, run discovery interviews (+1 week).
|
||||
|
||||
**Phase 3: Solution Exploration (Week 2, Days 1-3)**
|
||||
- Generate opportunity solution tree (3 opportunities, 3 solutions each, POC recommendation). Define epic hypotheses.
|
||||
- Decision gate: Need to test solutions? If YES (high uncertainty), run experiments (+1-2 weeks).
|
||||
|
||||
**Phase 4: Prioritization & Roadmap (Week 2, Days 4-5)**
|
||||
- Choose prioritization framework. Score and rank epics. Sequence roadmap by release. Optional: TAM/SAM/SOM for exec presentations.
|
||||
|
||||
**Phase 5: Stakeholder Alignment (Week 3)**
|
||||
- Present strategy: positioning + problem + solutions + prioritization + roadmap.
|
||||
- Include "What's NOT on roadmap and why." Refine based on feedback.
|
||||
|
||||
**Phase 6: Execution Planning (Week 4)**
|
||||
- Break top epic using splitting patterns (workflow, CRUD, business rules). Write user stories with acceptance criteria. Plan first sprint.
|
||||
|
||||
**Decision gates are mandatory.** Skipping them causes building solutions to unvalidated problems or wasting time on low-uncertainty activities.
|
||||
|
||||
## Prioritization
|
||||
|
||||
### Framework Selection Matrix
|
||||
|
||||
| Context | Recommended Framework | Why |
|
||||
|---------|----------------------|-----|
|
||||
| Pre-PMF, minimal data, small team | **ICE** or **Value/Effort matrix** | Lightweight, gut-check, fast scoring |
|
||||
| Early PMF, some data, aligned team | **RICE** | Structured but not overwhelming; balances data + speed |
|
||||
| Mature product, rich data | **Opportunity Scoring** or **Kano** | Leverages analytics, customer surveys |
|
||||
| Multiple stakeholders, misaligned | **Weighted Scoring** or **Buy-a-Feature** | Transparent, consensus-building |
|
||||
| Large org, cross-team dependencies | **Cost of Delay** or **Impact Mapping** | Handles coordination complexity |
|
||||
| Strategic bets vs. quick wins | **Value/Effort matrix** | Visual, intuitive for tradeoff conversations |
|
||||
|
||||
### RICE Scoring
|
||||
|
||||
Formula: `(Reach x Impact x Confidence) / Effort`
|
||||
- **Reach:** Users affected per month/quarter
|
||||
- **Impact:** 1 (minimal), 2 (high), 3 (massive)
|
||||
- **Confidence:** 50% (low data), 80% (good data), 100% (certain)
|
||||
- **Effort:** Person-months (include design, eng, QA)
|
||||
|
||||
Use RICE as input, not automation. PM judgment overrides scores when strategic context requires it. Always adjust for strategic fit after raw scoring.
|
||||
|
||||
### Prioritization Decision Logic
|
||||
|
||||
4-question assessment to select framework:
|
||||
1. Product stage (pre-PMF / early PMF / mature / multi-product)
|
||||
2. Team context (small + focused / cross-functional aligned / stakeholders misaligned / large org)
|
||||
3. Primary challenge (too many ideas / stakeholder disagreement / no data-driven process / strategic vs. tactical tradeoffs)
|
||||
4. Data availability (minimal / some / rich)
|
||||
|
||||
Stick with one framework 6-12 months. Reassess only when stage or context changes.
|
||||
|
||||
## Roadmap Planning
|
||||
|
||||
### Roadmap Types
|
||||
|
||||
| Type | Structure | Best For |
|
||||
|------|-----------|----------|
|
||||
| **Now/Next/Later** | Committed / High confidence / Exploration | Agile teams, uncertainty, continuous discovery |
|
||||
| **Theme-Based** | Strategic themes (Retention, Enterprise, Mobile) | Exec communication, strategic intent |
|
||||
| **Timeline (Quarters)** | Q1: A, B; Q2: C, D; Q3: E, F | Resource planning, stakeholder comm |
|
||||
| **Feature-Based** | Lists features without context | Anti-pattern. No strategic narrative. |
|
||||
|
||||
### Roadmap Planning Process (5 phases, 1-2 weeks)
|
||||
|
||||
**Phase 1: Gather Inputs (Days 1-2)**
|
||||
- Business goals: top 3 company priorities, key metrics, strategic bets
|
||||
- Customer problems: top 3-5 validated pain points (from discovery)
|
||||
- Technical constraints: blockers, enabling investments, migrations
|
||||
- Stakeholder requests: sales, marketing, CS inputs (not yet committed)
|
||||
|
||||
**Phase 2: Define Initiatives (Days 3-4)**
|
||||
- Write epic hypotheses: "We believe [building X] for [persona] will achieve [outcome] because [assumption]."
|
||||
- T-shirt size effort: S (1-2 wk), M (3-4 wk), L (2-3 mo), XL (3+ mo)
|
||||
- Map each epic to primary business outcome
|
||||
|
||||
**Phase 3: Prioritize (Day 5)**
|
||||
- Select framework using prioritization advisor
|
||||
- Score all epics collaboratively (PM + eng + product leadership)
|
||||
- Adjust scores for strategic fit (strategic overrides are legitimate)
|
||||
|
||||
**Phase 4: Sequence (Days 6-7)**
|
||||
- Map dependencies (technical and logical)
|
||||
- Assign to Now (committed), Next (high confidence), Later (exploration)
|
||||
- Validate sequence with engineering for feasibility
|
||||
|
||||
**Phase 5: Communicate (Week 2)**
|
||||
- Presentation structure: strategic context, roadmap overview, per-quarter deep dive, what's NOT on roadmap (and why), dependencies and risks
|
||||
- Focus on strategic narrative: "Here's why X over Y"
|
||||
- Frame as plan, not commitment: "Subject to change based on learning"
|
||||
- Gather feedback, refine, publish internally (and optionally externally in Now/Next/Later format)
|
||||
|
||||
## Quality Gates
|
||||
|
||||
### Positioning Anti-Patterns
|
||||
- **"For Everyone"** -- No one feels it's for them. Pick the first segment; expand later.
|
||||
- **Feature Creep in Benefits** -- "AI, automation, analytics" is a feature list. Lead with outcome.
|
||||
- **Imaginary Competitor** -- "Unlike outdated legacy systems" is a straw man. Name the actual alternative.
|
||||
- **Category Confusion** -- "Next-generation platform for digital transformation" has no mental shelf. Pick a known category or commit to category creation.
|
||||
- **Differentiation Without Proof** -- "Revolutionary AI" without evidence is noise. Make it falsifiable.
|
||||
|
||||
### Research Anti-Patterns
|
||||
- **Surface-Level Research** -- Find executive interviews and product blogs, not just "About Us" pages.
|
||||
- **No Citations** -- Always cite source + date. Unverifiable = low credibility.
|
||||
- **Analysis Without Action** -- PESTEL and company research must end in strategic recommendations, not just lists.
|
||||
- **Outdated Information** -- Prioritize sources from last 12-24 months.
|
||||
|
||||
### Market Sizing Anti-Patterns
|
||||
- **TAM Without Citations** -- Cite industry reports (Gartner, IBISWorld, Statista) with URLs.
|
||||
- **SOM = SAM** -- No market has zero competition. SOM = 1-20% of SAM in Year 1-3.
|
||||
- **No Population Estimates** -- Always include customer counts alongside dollar amounts.
|
||||
- **Ignoring GTM Constraints** -- Ground SOM in sales capacity, conversion rates, marketing budget.
|
||||
|
||||
### Prioritization Anti-Patterns
|
||||
- **Wrong Framework for Stage** -- Pre-PMF startup using weighted scoring with 10 criteria kills speed.
|
||||
- **Framework Whiplash** -- Switching frameworks every quarter causes confusion. Stick for 6-12 months.
|
||||
- **Scores as Gospel** -- Scores are input, not automation. Strategic context overrides.
|
||||
- **Solo PM Scoring** -- Collaborative scoring (PM + design + eng) builds buy-in.
|
||||
- **HiPPO Prioritization** -- Any framework beats "who shouts loudest."
|
||||
|
||||
### Roadmap Anti-Patterns
|
||||
- **Feature-Driven Roadmap** -- Frame epics as hypotheses with success metrics, not feature names.
|
||||
- **Roadmap as Commitment** -- Communicate as strategic plan, subject to change based on learning.
|
||||
- **No Dependencies Mapped** -- Validate sequence with engineering. Unmapped deps = blocked quarters.
|
||||
- **Solo PM Roadmap** -- Gather inputs from all stakeholders (Phase 1), present draft for feedback (Phase 5).
|
||||
- **Strategy Without Exec Sponsorship** -- Secure exec commitment upfront. Schedule alignment presentation before starting.
|
||||
Reference in New Issue
Block a user