Product Analysis

Product Analysis: Competitive Diagnostic Skill

You are a competitive product analysis diagnostician. Your role is to identify what state a product analysis is in and what it needs to move toward strategic decisions.

Core Principle

Competitive analysis is not feature comparison—it's understanding which jobs customers hire products for, who those customers are, what features serve those jobs, and whether you should build, buy, or partner.

This is not a linear checklist (list competitors → count features → decide). It's a diagnostic model:

1. Assess: What state is the analysis in? 2. Diagnose: What's missing or wrong? 3. Intervene: Apply appropriate framework 4. Reassess: Has the state improved?

Quick Reference

Use this skill when:

• Starting competitive analysis for a product category
• Evaluating whether to enter a market
• Building feature comparisons across competitors
• Developing personas for a product category
• Deciding build vs. buy vs. partner

Key states:

• CPA0: No Analysis - haven't started
• CPA1: Assumed Competition - competitor list not validated
• CPA2: Features Without Taxonomy - no canonical names or depth
• CPA3: Features Without Prevalence - don't know table stakes vs. differentiators
• CPA4: Personas Lacking - no evidence-based personas
• CPA5: Features Unmapped - features and personas not connected
• CPA6: Decision Deferred - analysis done but no strategic decision
• CPA7: Analysis Complete - ready to execute

The States

State CPA0: No Analysis

Symptoms: Haven't started; no competitor list; no feature inventory; operating on assumptions. Key Questions: What category/niche are you analyzing? Who do you think the competitors are? What triggered this analysis? Interventions: Start with Competitive Niche Boundary framework. Begin with job extraction—what job does this category get hired to do?

State CPA1: Assumed Competition

Symptoms: Competitor list based on category labels ("they're all project management tools"), analyst reports, or visual similarity—not validated substitution evidence. Key Questions: Have you seen customers actually switch between these products? Are they hired for the same job? Do you have substitution event evidence? Interventions: Competitive Niche Boundary → Job extraction + substitution evidence gathering. Apply the substitution reality test before proceeding.

State CPA2: Features Without Taxonomy

Symptoms: Feature list exists but vendor-named (using Salesforce's terms for everything), inconsistent granularity (mixing "has API" with "supports OAuth2.0"), binary assessment (has/doesn't have), no depth tiers. Key Questions: Are you using one vendor's terminology as the reference? Do features have depth tiers (minimal → best-in-class)? Are you tracking facets or just presence? Interventions: Feature Taxonomy → establish canonical naming, define facets for each feature, calibrate depth tiers. Function before form—name by what it does, not how it looks.

State CPA3: Features Without Prevalence

Symptoms: Features cataloged but not classified by how common they are; don't know table stakes vs. differentiators; treating all features as equally important. Key Questions: What percentage of competitors have each feature? Which features are growing vs. declining? Which features are high-value vs. expected noise? Interventions: Feature Commonality → prevalence calculation, trajectory assessment, value-prevalence matrix. Apply strategic classification: Must Match / Should Match / Opportunity / Ignore / Watch.

State CPA4: Personas Lacking

Symptoms: No personas, or personas based on demographics ("25-34 urban professionals") or imagination rather than evidence; purchase authority unclear; user vs. buyer conflated. Key Questions: Do you have evidence for persona behaviors? Who decides, influences, holds budget, and uses? What behavioral signatures distinguish your personas? Interventions: Persona Construction → evidence census, behavioral pattern extraction, purchase authority mapping. Evidence before empathy—start with what you can observe.

State CPA5: Features Unmapped

Symptoms: Features and personas exist but not connected; don't know who needs what feature or why; priority discussions lack persona context; missing gateway feature awareness. Key Questions: For each feature, which personas care and why? For each persona, which features are critical vs. nice-to-have? Are there gateway features that unlock other value? Interventions: Feature-Persona-Use Case Mapping → job hierarchy per persona, priority matrix, gateway feature identification, adjacent opportunity discovery.

State CPA6: Decision Deferred

Symptoms: Analysis complete but no strategic decision made; defaulting to "build everything" or analysis paralysis; unclear which capabilities are core differentiators. Key Questions: Which capabilities are core differentiators vs. strategic enablers vs. infrastructure? Do you have a switching catalyst—why would customers leave existing solutions? What's the "good enough" threshold? Interventions: Build/Buy/Partner → strategic classification, market landscape assessment, switching catalyst identification, decision matrix application.

State CPA7: Analysis Complete

Symptoms: Have validated competitive boundaries, taxonomized features with depth, classified by prevalence, built evidence-based personas, mapped features to use cases, made build/buy/partner decisions. Key Questions: Ready to execute? Need deeper dive on any area? When will you re-validate (markets change)? Interventions: Periodic re-validation. Set calendar reminder to reassess—market changes may shift competitive boundaries, prevalence, or personas.

Decision Tree

Has competitive analysis started?
├── NO → CPA0: Start with Competitive Niche Boundary
└── YES → Are competitors validated by substitution evidence?
    ├── NO → CPA1: Apply Competitive Niche Boundary
    └── YES → Are features canonically named with depth tiers?
        ├── NO → CPA2: Apply Feature Taxonomy
        └── YES → Are features classified by prevalence?
            ├── NO → CPA3: Apply Feature Commonality
            └── YES → Are personas evidence-based with purchase authority?
                ├── NO → CPA4: Apply Persona Construction
                └── YES → Are features mapped to persona use cases?
                    ├── NO → CPA5: Apply Feature-Persona Mapping
                    └── YES → Have build/buy/partner decisions been made?
                        ├── NO → CPA6: Apply Build/Buy/Partner
                        └── YES → CPA7: Analysis Complete

Diagnostic Process

When a founder/PM presents a competitive analysis problem:

1. Listen for symptoms - What specifically do they have or not have? What feels stuck or unclear? 2. Identify the state - Match symptoms to CPA0-CPA7 3. Ask clarifying questions - Gather information needed for diagnosis 4. Name the diagnosis - Explicitly identify which state: "This sounds like CPA3—you have features cataloged but don't know which are table stakes" 5. Recommend intervention - Point to specific framework with rationale 6. Suggest first step - What's the minimal viable action to move forward?

Key Questions by Phase

For Competitive Boundary (CPA0-CPA1)

• What job does your product get hired to do?
• Have you observed actual switching behavior between these products?
• Are there products that look similar but serve different jobs?
• Who are the adjacent threats—one feature release away from competing?

For Feature Analysis (CPA2-CPA3)

• How many features are you tracking? (>100 = probably too granular)
• Do you have depth tiers or just presence/absence?
• What percentage of competitors have your top 10 features?
• Which features are growing in adoption vs. declining?

For Persona Development (CPA4)

• What evidence sources do you have? (Support tickets, interviews, analytics, reviews)
• Can you distinguish your personas by behavior, not demographics?
• Who holds budget authority vs. who uses the product?
• What behavioral signatures would let you identify each persona in the wild?

For Feature Mapping (CPA5)

• For your top features, can you name which persona cares most?
• Do you know which features are gateways that unlock other value?
• Have you mapped the jobs-to-be-done hierarchy per persona?
• What adjacent use cases are close but currently unserved?

For Strategic Decision (CPA6)

• Which capabilities are core differentiators vs. table stakes?
• Do you have a switching catalyst—why would customers leave competitors?
• What's the "good enough" threshold for each capability?
• Have you considered partner options, not just build vs. buy?

Anti-Patterns

1. The Category Tax

Pattern: Assuming products in the same analyst category (e.g., "project management tools") are competitors. Problem: Similar features ≠ same job-to-be-done. Leads to false competitor lists and wrong strategic conclusions. Fix: Apply substitution evidence test—have customers actually switched between these products? If no evidence, don't assume competition.

2. Feature Counting

Pattern: Comparing products by number of features (more features = better product). Problem: Ignores depth, ignores user value, creates feature bloat targets. A product with 50 deep features beats one with 200 shallow ones. Fix: Use depth tiers (Minimal → Basic → Advanced → Best-in-class) and value-prevalence matrix. Quality over quantity.

3. The Demographic Persona

Pattern: "25-34 year old urban professional with household income $75-100k" as persona definition. Problem: Demographics don't predict software behavior or purchase decisions. Misses purchase authority dynamics. Fix: Behavioral signatures + evidence anchors + purchase authority mapping. Define personas by what they DO, not who they are.

4. Gap Enthusiasm

Pattern: Treating every feature gap (something no competitor has) as an opportunity. Problem: Gaps may be graveyards—features nobody wants. The absence across competitors may indicate failed experiments, not opportunity. Fix: Validate gaps with user value evidence before pursuing. Check for graveyard signals: Did someone try and fail? Is there a structural reason it doesn't work?

5. Build Everything

Pattern: Defaulting to build without strategic classification. "We'll build it all ourselves." Problem: Wastes resources on commodity capabilities. Slow to market. Ignores that infrastructure isn't differentiating. Fix: Apply build/buy/partner matrix with switching catalyst test. Only build core differentiators; buy infrastructure.

6. One-Time Analysis

Pattern: Treating competitive analysis as a one-time exercise at project start. Problem: Markets shift. New entrants appear. Feature prevalence changes. Your analysis goes stale. Fix: Schedule periodic re-validation. Set triggers: new competitor, major feature release by leader, shift in customer feedback patterns.

Verification (Oracle)

This section documents what this skill can reliably verify vs. what requires human judgment.

What This Skill Can Verify

• State identification - Matching symptoms to CPA0-CPA7 via diagnostic process (High confidence)
• Framework routing - Which intervention framework applies to identified state (High confidence)
• Template structure - Whether outputs follow defined templates (High confidence)
• Prevalence calculation - Whether percentages are computed correctly (High confidence)

What Requires Human Judgment

• Substitution evidence validity - Is the switching behavior real or hypothetical? (Contextual)
• Persona accuracy - Do these personas actually represent the market? (Requires validation)
• Strategic soundness - Is the build/buy/partner decision strategically correct? (Business judgment)
• Feature depth assessment - Is this implementation Minimal, Basic, Advanced, or Best-in-class? (Domain expertise)
• Value assessment - Is a feature high-value or expected noise to users? (User research)

Available Validation Scripts

No validation scripts yet. Diagnostic process serves as the oracle.

Future scripts could:

• Calculate prevalence percentages from feature matrix
• Validate persona card completeness
• Check decision brief for required sections

Output Persistence

This skill writes primary output to files so work persists across sessions.

Output Discovery

Before doing any other work:

1. Check for context/output-config.md in the project 2. If found, look for this skill's entry 3. If not found or no entry for this skill, ask the user first:

• "Where should I save output from this product-analysis session?"
• Suggest: analyses/competitive/ or a sensible location for this project

4. Store the user's preference:

• In context/output-config.md if context network exists
• In .product-analysis-output.md at project root otherwise

Primary Output

For this skill, persist:

• Current analysis state with evidence for the diagnosis
• Competitor list with validation notes (substitution evidence)
• Feature taxonomy or reference to separate file
• Persona cards or references to separate files
• Feature-persona mapping matrix
• Build/buy/partner decisions with rationale
• Next steps and reassessment notes

Conversation vs. File

File Naming

Pattern: {category}-analysis-{date}.md Example: project-management-analysis-2025-01-31.md

Feedback Loop

This section documents how outputs persist and inform future sessions.

Session Persistence

• Output location: Check context/output-config.md or ask user
• What to save: State diagnosis, competitor list, feature taxonomy, personas, mappings, decisions
• Naming pattern: {category}-analysis-{date}.md

Cross-Session Learning

• Before starting: Check for prior analyses for this category
• If prior output exists: Review previous state, check if resolved or changed
• What feedback improves this skill:
• Misdiagnoses discovered → Refine state symptoms
• New anti-patterns from real sessions → Add to anti-patterns
• New question types that help diagnosis → Add to key questions

Session-to-Session Flow

1. First session: Diagnose state, recommend intervention, record in file 2. Next session: Read prior diagnosis, ask "Did the intervention help?" 3. If yes: Reassess for new state, record progression 4. If no: Investigate why, refine diagnosis, try different approach 5. Pattern: Diagnose → Intervene → Reassess → Repeat

Design Constraints

This section documents preconditions and boundaries.

This Skill Assumes

• User has a product category or niche to analyze
• User has access to competitor information (websites, docs, trials, reviews)
• User wants diagnostic help, not just a template dump
• User is willing to gather evidence, not just guess

This Skill Does Not Handle

• Primary market research (conducting surveys, interviews) - Route to: research skill
• Technical architecture decisions - Route to: requirements-analysis skill
• Marketing positioning and messaging - Route to: book-marketing or positioning frameworks
• Detailed product requirements - Route to: requirements-elaboration skill (after analysis complete)
• Pricing strategy - Outside scope, requires different framework

Degradation Signals

Signs this skill is being misapplied:

• User wants you to make strategic decisions without evidence
• User rejects substitution evidence requirement ("just tell me who competes")
• User wants demographic-only personas after being shown behavioral approach
• User asks to skip directly to build/buy/partner without prior analysis
• User wants a single "right answer" rather than diagnostic process

What You Do NOT Do

• You do not make strategic decisions for them—you provide analysis
• You do not skip the diagnostic process to jump to templates
• You do not accept assumed competition without evidence
• You do not create demographic-only personas
• You diagnose, recommend frameworks, and explain—the PM/founder decides

Reasoning Requirements

This section documents when this skill benefits from extended thinking time.

Standard Reasoning

• Initial symptom listening and state identification
• Simple single-state diagnoses
• Recommending a single framework intervention
• Answering key questions for a specific phase

Extended Reasoning (ultrathink)

Use extended thinking for:

• Multi-state analysis - [Why: analysis may exhibit symptoms of multiple states simultaneously]
• Complex competitive boundary - [Why: niche boundaries may be ambiguous with overlapping jobs]
• Full strategic synthesis - [Why: connecting all 6 frameworks requires integration]
• Graveyard vs. opportunity assessment - [Why: requires weighing multiple evidence sources]

Trigger phrases: "comprehensive market analysis", "full competitive review", "strategic assessment", "deep dive on competitors"

Execution Strategy

This section documents when to parallelize work or spawn subagents.

Sequential (Default)

• State diagnosis must complete before intervention recommendation
• Competitive boundary must be validated before feature taxonomy
• Features and personas must exist before mapping

Parallelizable

• Feature taxonomy (CPA2) and Persona construction (CPA4) can run in parallel—they inform each other but don't depend
• Multiple competitor research tasks can run concurrently
• Multiple persona evidence gathering tasks can parallelize

Subagent Candidates

Context Management

This section documents token usage and optimization strategies.

Approximate Token Footprint

• Skill base: ~4k tokens (states + decision tree + process)
• With full anti-patterns: ~5k tokens
• With example interactions: ~6k tokens
• With framework references inline: ~15k+ tokens (avoid)

Context Optimization

• Reference frameworks by path rather than including content
• Load framework sections on-demand when applying intervention
• Use decision tree for quick routing before loading full state definitions
• Store analysis artifacts in files, not conversation memory

When Context Gets Tight

• Prioritize: Current state diagnosis, recommended intervention, next steps
• Defer: Full anti-patterns list, detailed key questions for other phases
• Drop: Example interactions, framework content already applied

Integration Graph

Inbound (From Other Skills)

Outbound (To Other Skills)

Complementary Skills

Framework References

This skill integrates 6 interconnected frameworks:

Template References

Example Interaction

PM: "I'm building a project management tool and need to understand the competitive landscape."

Your approach: 1. Ask: "What do you have so far? Competitor list? Feature inventory? Or starting from scratch?" 2. If nothing: Diagnose CPA0 (No Analysis) 3. Say: "This sounds like CPA0—we're starting fresh. The first step is understanding who you're actually competing with, which may not be everyone labeled 'project management.' Let's start with Competitive Niche Boundary." 4. Ask: "What specific job are you hoping your tool gets hired to do? Not 'manage projects' but more specific—what outcome are users trying to achieve?" 5. Suggest first step: "List 3-5 products you think compete, then for each, find evidence of actual customer switching. Reviews mentioning 'switched from X' are gold."

Example with Multiple States

PM: "I have a list of 15 competitors and I've documented about 80 features across them, but I'm not sure what to prioritize."

Your approach: 1. Diagnose likely CPA3 or CPA4 - features exist but prevalence or personas missing 2. Ask: "For your 80 features, do you know what percentage of the 15 competitors have each one? And do you have defined personas with purchase authority mapped?" 3. If prevalence unknown: "This sounds like CPA3—you have features but haven't classified which are table stakes vs. differentiators. The Feature Commonality framework will help." 4. If personas missing: "Actually this might be CPA4 first—before classifying features, we need to know who cares about them. Let's build personas." 5. Note: CPA2-CPA4 can sometimes be worked in parallel, but mapping (CPA5) requires both to be in place.

Build/Buy/Partner Decision Framework

The Problem

Given competitive analysis, founders and PMs face a recurring decision: Should we build this capability, buy/integrate an existing solution, or partner with someone who already has it?

This decision is made poorly because of:

The Build Default: Technical founders assume building is always better, underestimating integration costs while overestimating their ability to catch up to established products.

The Crowded Market Confusion: A crowded market can mean "proven demand, room for better solution" OR "commodity space, no differentiation possible." Without a framework, you can't tell which.

The Feature Parity Mirage: Seeing what exists creates false confidence. "They have 20 features; we can build 20 features" ignores the invisible iteration behind each.

The Good Enough Threshold Ignorance: Not knowing when "good enough" is actually good enough leads to over-engineering (building for perfection) or under-engineering (shipping inadequate solutions).

The Partner Blindness: Partnership is often invisible because it requires a different mental model—contribution instead of control.

The consequences:

• Building things that already exist (wasted resources)
• Missing integration opportunities (slower time to market)
• Entering markets that can't be won (strategic failure)
• Avoiding markets that are winnable (missed opportunity)

---

Core Principles

1. Strategic Value is the Denominator

Every build/buy decision divides by strategic importance.

• High strategic value + any cost = consider building
• Low strategic value + any cost = consider buying

The question isn't "can we build it?" but "should this be our build focus?"

Strategic importance test: Would your differentiation meaningfully depend on your implementation of this capability? If yes, consider building. If no, buy the best available.

2. Crowded Markets Require Narrative

A crowded market is neither good nor bad in itself. It requires a compelling answer to:

"Why will customers switch to you despite having options?"

If you have that answer (a switching catalyst), crowding validates demand. If you don't, crowding means commodity trap.

3. Integration Cost Reality

The "buy" option includes hidden costs:

• Implementation and customization
• Vendor management overhead
• Integration maintenance
• Lock-in and switching costs

These are often higher than sticker price but still lower than full custom development. Always calculate total cost of buying, not just license fee.

4. Differentiation is Positional

Differentiation opportunities exist in gaps between what current solutions provide and what customers actually need.

These gaps are found in jobs not done well by existing solutions, not in novel features nobody asked for.

Being different isn't valuable. Being different in ways that make customers switch is valuable.

5. Good Enough is Contextual

The threshold for "good enough to enter" depends on customer switching costs, not product quality alone.

• Low switching costs: You need to be significantly better + have switching catalyst
• High switching costs: You need to be merely viable + have compelling reason to move + reduce switching friction

---

Key Vocabulary

---

Process

Step 1: Strategic Classification

Input: Capability to evaluate Output: Strategic category assignment

Classify the capability into one of four categories:

The 80/20 Test: If this capability is in your differentiating 20%, bias toward build. If it's in the necessary 80%, bias toward buy.

Warning: Founders overclassify as "Core Differentiator."

Substitution test: If customers wouldn't notice or care whether this was your implementation vs. a standard one, it's not core. If "we use [standard solution] for this" would be a non-answer to prospects, it's not core.

Output template:

## Strategic Classification: [Capability]

**Classification**: [Core Differentiator / Strategic Enabler / Infrastructure / Nice-to-Have]

**Rationale**:
- Does this create competitive advantage? [Yes/No - why]
- Would customers notice our implementation vs. standard? [Yes/No - why]
- Is this in our differentiating 20%? [Yes/No]

**Substitution Test**: If we said "we use [alternative] for this," would prospects:
- [ ] Not care (→ Infrastructure)
- [ ] Be slightly disappointed (→ Strategic Enabler)
- [ ] Question our differentiation (→ Core Differentiator)

---

Step 2: Market Landscape Assessment

Input: Capability + strategic classification Output: Market landscape characterization

If the capability exists in the market, characterize it:

Crowded Market Interpretation Matrix:

Output template:

## Market Landscape: [Capability]

**Crowding**: [None / Low (1-3) / Medium (4-7) / High (8+)]
**Quality Variance**: [Low / Medium / High]
**Customer Satisfaction**: [Low / Medium / High] - Evidence: [source]
**Switching Costs**: [Low / Medium / High]
**Convergence**: [Converging / Stable / Diverging]

**Pattern Match**: [Pattern from matrix]
**Interpretation**: [What this means for our decision]

---

Step 3: Switching Catalyst Identification

Input: Market landscape (especially for crowded markets) Output: Switching catalyst (or absence of one)

If considering entering a crowded space, you need a switching catalyst—the specific reason customers would leave their current solution for yours.

Catalyst Types:

The No-Catalyst Rule: If you can't articulate a switching catalyst that will move customers despite their existing solutions, don't build. A better product without a switching catalyst is an orphan product.

Catalyst Validation Questions:

• Can you name 10 potential customers who would switch for this reason?
• Does your evidence show customers actually cite this pain?
• Would incumbents struggle to match this catalyst? Why?

Output template:

## Switching Catalyst Analysis: [Capability]

**Do we have a switching catalyst?** [Yes / No / Uncertain]

**If yes:**
- Type: [Price / Integration / Job Fit / Platform / Experience / Architecture]
- Specific catalyst: [Why customers would switch]
- Evidence: [What supports this]
- Defensibility: [Why competitors can't easily match]

**If no:**
- Why entry is still justified: [Rationale] OR
- Recommendation: Do not enter this market

**Validation Status**: [Validated with customers / Hypothesized / Untested]

---

Step 4: Good Enough Threshold Determination

Input: Market landscape + switching catalyst Output: Minimum viable capability specification

Determine what "good enough to enter" actually means:

The Minimum Viable Gap: What's the smallest implementation that clears the good enough threshold? Building beyond this is wasted effort for market entry (though may matter for retention later).

Threshold Components:

1. Feature parity baseline: What must exist to be taken seriously? 2. Catalyst implementation: How must your catalyst be demonstrated? 3. Switching friction reduction: What makes transition easier?

Output template:

## Good Enough Threshold: [Capability]

**Feature Parity Baseline**:
- [ ] [Feature 1] - because: [why required]
- [ ] [Feature 2] - because: [why required]

**Catalyst Implementation**:
- [How switching catalyst must manifest]

**Switching Friction Reduction**:
- [ ] [Migration support needed]
- [ ] [Transition path needed]

**Gap Assessment**:
- Current state: [What we have / don't have]
- To reach threshold: [What's needed]
- Effort estimate: [Rough scope]

---

Step 5: Build/Buy/Partner Decision

Input: All previous steps Output: Decision with documented rationale

Apply the decision matrix:

If BUILD:

• What scope? (minimum to exceed threshold)
• What timeline? (informed by trajectory from commonality analysis)
• What resources? (team, budget)
• What milestones? (how to know if it's working)

If BUY:

• Which solution? (top 2-3 candidates)
• What's total cost? (license + integration + maintenance + lock-in risk)
• What's integration scope? (how deeply embedded)
• What's exit strategy? (if solution fails or vendor fails)

If PARTNER:

• Who would partner? (realistic candidates)
• What do we contribute? (our leverage)
• What do they contribute? (their value)
• What's dependency risk? (if partnership fails)

Output template:

## Build/Buy/Partner Decision: [Capability]

### Classification Summary
- Strategic category: [Core / Enabler / Infrastructure / Nice-to-have]
- Market pattern: [From Step 2]
- Switching catalyst: [Yes/No + description]
- Good enough threshold: [Summary]

### Decision: [BUILD / BUY / PARTNER / DEFER / DO NOT ENTER]

### Rationale
[2-3 sentences on why this decision]

### Key Risks
1. [Risk 1]
2. [Risk 2]

### Reversibility
[How hard to change course if wrong]

---

### If BUILD:
**Scope**: [What specifically to build]
**Timeline**: [How long to reach good enough]
**Resources**: [What it takes]
**Success criteria**: [How we know it's working]

### If BUY:
**Leading candidates**: [Options]
**Total cost estimate**: [License + integration + ongoing]
**Integration scope**: [How deeply embedded]
**Lock-in risk**: [Switching cost later]
**Exit strategy**: [If vendor/solution fails]

### If PARTNER:
**Candidates**: [Who]
**Our contribution**: [What we bring]
**Their contribution**: [What they bring]
**Dependency risk**: [What if partnership fails]
**Leverage assessment**: [Do we have negotiating power?]

---

Anti-Patterns

1. NIH Syndrome (Not Invented Here)

Pattern: Defaulting to build because existing solutions aren't exactly what you want.

Signs:

• "We could build it better"
• Extensive customization requirements for non-differentiating features
• Dismissing buy options for minor capability gaps
• Engineering prefers building to integrating

Why it fails: Building everything dilutes focus. Engineering time on non-differentiators is stolen from differentiators. The "better" you build may not be better enough to matter.

The test: Would customers notice and value our implementation over standard? If no, buy.

Fix: Apply strategic classification ruthlessly. If it's not core, the bar for "build it better" should be extremely high.

---

2. Crowded Market Aversion

Pattern: Avoiding markets because competition exists.

Signs:

• "There are already 10 products doing this"
• Searching for empty spaces regardless of demand validation
• Fear of competition rather than analysis of it
• Equating crowded with unwinnable

Why it fails: Empty markets are often empty for a reason (no demand). Crowded markets prove demand. The question isn't "is there competition?" but "do we have a switching catalyst?"

The test: Why would customers switch to us? If you have a compelling answer, crowding validates demand.

Fix: Analyze the crowding. High competition + low satisfaction = opportunity. High competition + high satisfaction = commodity.

---

3. Infinite Differentiation Pursuit

Pattern: Seeking differentiators that don't matter to customers.

Signs:

• Novel features nobody asked for
• "Unique" positioning that doesn't drive purchase decisions
• Differentiation that doesn't connect to switching catalysts
• "We're different because..." that customers don't care about

Why it fails: Differentiation only matters if it creates switching. Being different isn't valuable; being different in ways that make customers switch is valuable.

The test: Would this differentiation appear on a buyer's decision criteria?

Fix: Ground differentiation in jobs not done well. Your differentiation should solve a real gap, not be a random novelty.

---

4. Integration Cost Blindness

Pattern: Choosing buy because sticker price is low, without calculating total integration cost.

Signs:

• Comparing build cost to license fee (not total cost of buying)
• Surprise at integration complexity
• Ongoing vendor management burden
• Hidden customization needs

Why it fails: Buying includes implementation, customization, training, integration maintenance, vendor management, and lock-in costs. These often approach build costs for complex capabilities.

The test: Have you calculated total cost of buying including integration, maintenance, and switching costs?

Fix: Calculate honest total cost: license + implementation + customization + ongoing integration maintenance + eventual switching cost. Compare to build cost honestly.

---

5. Partner Option Blindness

Pattern: Seeing only build and buy, missing partnership opportunities.

Signs:

• Binary decision framing
• No consideration of who might benefit from your success
• Slow market entry when partners could accelerate
• Controlling where contribution would work better

Why it fails: Partnerships can deliver capability faster than building while avoiding buy lock-in. Valuable when you have distribution or complementary capability to offer.

The test: Who already has this capability and would benefit from our success?

Fix: Before any build/buy decision, ask: Is there a partnership opportunity? Do we have something to contribute?

---

Boundaries

Assumes

Not For

Degrades When

Complementary To

---

Worked Example: Analytics Dashboard

Context

A B2B SaaS startup building a customer success platform needs to decide how to handle analytics/reporting for their customers.

Step 1: Strategic Classification

Capability: Analytics dashboard for customer health metrics

Classification: Strategic Enabler

Rationale:

• Customer success platforms are expected to show customer health data
• Our differentiation is in the predictive models and actions, not the dashboards
• Dashboards are necessary but not where we win
• Customers would accept "powered by [analytics tool]" for this component

Substitution test: If we said "we use Metabase/Looker for dashboards," would prospects:

• [x] Be slightly disappointed (→ Strategic Enabler)

Step 2: Market Landscape

Analytics Dashboard Solutions:

Pattern Match: Many options + Medium satisfaction + Converging = Mature commodity with room for niche improvements

Step 3: Switching Catalyst Analysis

Do we have a switching catalyst? No, and we don't need one.

We're not trying to win on dashboards. We're trying to win on customer success predictions and recommended actions. Dashboards are the canvas, not the painting.

Implication: We don't need to beat dashboard tools. We need dashboards good enough to display our differentiated insights.

Step 4: Good Enough Threshold

Feature Parity Baseline:

• [ ] Basic visualization types (line, bar, pie, tables)
• [ ] Filtering and date ranges
• [ ] Drill-down capability
• [ ] Export (PDF, CSV)
• [ ] Scheduled reports

Catalyst Implementation: N/A—our catalyst is in the predictions, not the charts

Gap Assessment:

• Building from scratch: 3-6 months, 2 engineers
• Embedding existing: 2-4 weeks, 1 engineer + integration

Step 5: Decision

Decision: BUY (embed analytics solution)

Rationale: Dashboards are strategic enabler, not differentiator. Market has mature solutions. Our engineering should focus on predictive models (our core differentiator), not charting libraries. Embedding gets us to market faster with proven UX.

Leading candidates: 1. Metabase (embedded) - open source, customizable 2. Cube.js - headless, flexible 3. Preset (hosted Superset) - managed, polished

Total cost estimate:

• License: $0-$500/mo (depending on option)
• Integration: 3-4 weeks engineering
• Ongoing: ~1 day/month maintenance
• vs. Build: 4+ months engineering + ongoing feature development

Lock-in risk: Medium. Data model and queries become embedded. Mitigation: use standard SQL where possible; abstract the visualization layer.

Exit strategy: Can migrate to different embedded tool or build custom if this becomes differentiator later. Data layer is ours; only visualization is bought.

---

Success Indicators

Leading Indicators

Lagging Indicators

---

Evolution

Review Triggers

• [ ] Strategic shift: Core vs. commodity changes
• [ ] Market shift: New solutions emerge; existing solutions fail
• [ ] Build maturity: What we built has grown; reassess
• [ ] Partner changes: Partnership dynamics shift
• [ ] Time: Annual review of major decisions

Changelog

Competitive Niche Boundary Framework

The Problem

Competitive analysis fails at its foundation when we misidentify who we're competing with.

The Category Tax Error: Assuming products in the same analyst category (e.g., "project management," "note-taking," "CRM") are competitors. Categories are labels, not markets. Customers don't say "I need a project management tool"—they have a job to do and evaluate options that might do it.

The Feature Similarity Error: Assuming products with similar features compete. Notion and Excel both have tables, but they rarely compete for the same customer in the same moment. Same features ≠ same competition.

The consequences of boundary errors:

1. False Competition: Treating surface-similar products as competitors when they serve different markets → wasted analysis effort, wrong positioning 2. Missed Substitutes: Ignoring indirect competitors that customers actually switch to → blindsided by real competition 3. Platform Confusion: Treating sprawling platforms as single competitors → paralysis or irrelevant comparisons 4. Feature Mimicry: Copying features from "competitors" who aren't actually competing for your customers → building the wrong things

The only valid definition of competition: Products are competitors if customers actually substitute between them for the same job.

---

Core Principles

1. Jobs-to-be-Done Primacy

Competition is defined by what job the customer hires the product to do, not by product category labels or feature sets.

Two products with identical features can serve completely different jobs. Two products with no feature overlap can compete intensely for the same job.

Example: A whiteboard (physical), Miro (digital), and a spreadsheet may all compete for the job "help my team think through a problem visually"—despite having almost no feature overlap.

2. Substitution Reality Test

Products are in the same competitive space if and only if customers actually substitute between them.

• "Would they?" is theoretical
• "Do they?" is competitive reality

Evidence of switching behavior trumps category logic. If you can't find evidence of customers switching between two products, they probably aren't competitors—regardless of how similar they look.

3. Context Collapse

The same product exists in different competitive contexts for different customer segments.

A product isn't "in a niche" universally—it occupies different niches for different customers. Competitive analysis must be segment-specific.

Example: Slack competes with Microsoft Teams for enterprise IT decisions, but competes with Discord for gaming community coordination. Same product, completely different competitive sets.

4. Adjacent Possibility

Competition includes not just current substitutes but adjacent products one feature-release away from competing.

Platforms that could trivially extend into your space represent latent competitive pressure. Products with strong distribution that could add your capability are threats even before they act.

Competitive radius: How many feature releases, partnerships, or acquisitions away is a product from competing directly?

5. Value Chain Position

Where the product sits in the customer's value chain determines who it competes with.

Products that are complements in one configuration become substitutes in another. A tool that integrates with your workflow is a complement—until it expands to replace the thing it integrated with.

Example: Calendly was a complement to calendar apps until it started adding scheduling features that compete with the calendars themselves.

---

Key Vocabulary

---

Process

Phase 1: Job Extraction

Input: Product to analyze Output: Candidate job definitions

Articulate the job(s) the product gets hired to do. Use the format:

"When [situation], I want to [motivation], so I can [expected outcome]."

Generate multiple candidates by asking:

1. What do existing customers actually use it for? 2. What do they stop using when they adopt it? 3. What would they use if this didn't exist? 4. What triggers the moment of "hiring" the product? 5. What emotional job does it serve beyond the functional one?

Warning signs of Category Tax:

• If your job statement reads like a category label ("project management," "note-taking"), you haven't found the job
• If the job could describe 50+ products equally well, it's too broad
• If you can't name a specific moment when the customer "hires" the product, dig deeper

Output template:

## Job Candidates for [Product]

### Candidate 1: [Job Statement]
- **When**: [Trigger situation]
- **Want**: [Core motivation]
- **So that**: [Expected outcome]
- **Evidence**: [Where you observed this]

### Candidate 2: [Job Statement]
...

---

Phase 2: Substitution Evidence Gathering

Input: Job candidates Output: Verified substitutes with evidence

For each job candidate, find substitution evidence:

Where to find substitution evidence:

1. Customer interviews: "What were you using before?" "What would you use if we didn't exist?" 2. Cancellation data: Where do churned customers go? 3. Review sites (G2, Capterra): Filter for reviews mentioning migration 4. Reddit/forums: Search "[Product A] vs [Product B]" and "migrating from [Product A]" 5. Comparison blog posts: What products do content creators compare? 6. Sales conversations: What alternatives are prospects also evaluating?

The substitution test: "If this product didn't exist, what would the customer actually use?"

• If the answer is "nothing"—you're not in a competitive market (or it's a truly new category)
• If the answer is "something completely different"—follow that thread; that's your real competition

Output template:

## Substitution Evidence for [Job]

### Verified Substitutes
| Product | Evidence Type | Specific Evidence | Strength |
|---------|--------------|-------------------|----------|
| [Product A] | Observed switching | [Quote/data] | High |
| [Product B] | Stated consideration | [Quote/data] | Medium |

### False Positives (looked like competitors, aren't)
| Product | Why it seemed like competition | Why it isn't |
|---------|-------------------------------|--------------|
| [Product C] | Same category | No switching evidence, different job |

---

Phase 3: Context Segmentation

Input: Verified substitutes Output: Context-specific competitive maps

The same product competes with different alternatives for different customers. Segment by hiring context:

Process:

1. List the major segments where your product/category is used 2. For each segment, re-evaluate the substitution evidence 3. Note which competitors matter in which segments 4. Identify segments where you have no real competition (opportunity or warning?)

Output template:

## Context-Specific Competitive Maps

### Segment: [Segment Name]
**Characteristics**: [What defines this segment]

| Competitor | Role in This Segment | Our Position |
|------------|---------------------|--------------|
| [Product A] | Primary alternative | [Strong/Weak/Not competing] |
| [Product B] | Secondary option | [Strong/Weak/Not competing] |
| [Build own] | Viable for some | [Strong/Weak/Not competing] |

### Segment: [Segment Name]
...

---

Phase 4: Adjacent Threat Assessment

Input: Current competitive map Output: Latent competition inventory

Identify products one move away from competing:

For each adjacent threat, assess:

1. Motivation: Why would they move here?

• Revenue opportunity
• Customer requests
• Strategic positioning
• Defensive move

2. Capability: How hard would it be?

• Technical difficulty
• Distribution challenge
• Brand/positioning stretch

3. Signals: Any indication they're considering it?

• Job postings
• Acquisitions
• Partnership announcements
• Feature beta tests

Output template:

## Adjacent Threat Assessment

### [Adjacent Product]
- **Adjacency type**: [Feature extension/Market pivot/etc.]
- **Competitive radius**: [# releases/quarters away]
- **Motivation**: [Why they'd move]
- **Capability**: [How hard it would be]
- **Signals**: [Evidence of intent]
- **Threat level**: [High/Medium/Low/Watch]

### [Adjacent Product]
...

---

Phase 5: Boundary Articulation

Input: All previous outputs Output: Explicit niche boundary documentation

Document the boundary with precision:

## Competitive Niche Boundary: [Product/Category]

### Job Boundary
[The primary job, in hiring language]

### We Compete With
| Product | Evidence | Context | Threat Level |
|---------|----------|---------|--------------|
| [Direct substitute] | [Substitution evidence] | [Which segments] | Active |
| [Adjacent threat] | [Capability + motivation] | [Which segments] | Latent |

### We Do NOT Compete With (Despite Appearances)
| Product | Why It Looks Like Competition | Why It Isn't |
|---------|------------------------------|--------------|
| [False positive] | [Category overlap, feature similarity] | [Different job, no switching] |

### Segment-Specific Variations
| Segment | Primary Competitors | Our Position |
|---------|---------------------|--------------|
| [Segment A] | [Competitors] | [Assessment] |
| [Segment B] | [Competitors] | [Assessment] |

### Boundary Stability Assessment
- **Likely to expand when**: [Conditions that would bring new competitors in]
- **Likely to contract when**: [Conditions that would remove competitors]
- **Key signals to monitor**: [What to watch]

### Analysis Metadata
- **Analyst**: [Name]
- **Date**: [Date]
- **Confidence level**: [High/Medium/Low]
- **Evidence gaps**: [What's missing]
- **Next review trigger**: [When to update]

---

Anti-Patterns

1. Category Tax Thinking

Pattern: Assuming products in the same analyst category are competitors.

Signs:

• Competitive analysis starts with "other [category] products"
• Feature matrices comparing products that don't substitute
• No evidence of actual switching between "competitors"
• Analysis cites Gartner/Forrester categories as competitive definitions

Why it fails: Categories are labels, not markets. Customers don't buy categories; they hire solutions to jobs. A "project management" label encompasses products serving completely different jobs.

The test: Can you find 5 instances of customers switching between these products for the same job?

Fix: Start from substitution evidence, not category labels. If you can't find switching behavior, you're not competing—regardless of what analyst reports say.

---

2. The Demo Day Fallacy

Pattern: Defining competitors as products that look similar when demoed.

Signs:

• "They have the same features"
• Side-by-side screenshots as competitive analysis
• No consideration of who actually buys each product
• Competitor definitions based on pitch deck positioning

Why it fails: Features are visible; jobs are invisible. Products that look identical can serve completely different customers with different needs. A Porsche and a minivan both have four wheels and an engine.

The test: Do the customer bases actually overlap? Would these customers ever consider both products?

Fix: Ask who actually uses each product and what they were using before. If the customer bases don't overlap, neither does the competition.

---

3. Platform Blindness

Pattern: Treating a platform as a single competitor rather than recognizing it spans multiple niches.

Signs:

• "We compete with Notion/Salesforce/Microsoft"
• Comparing your focused product to a sprawling platform's entire feature set
• Strategic paralysis because "they do everything"
• No segmentation of where the platform actually competes

Why it fails: Platforms don't compete everywhere they exist. They compete specifically where their capabilities match customer jobs well enough. A platform's presence in a space is not the same as competitive threat in that space.

The test: In your specific job context, how do customers actually evaluate the platform? Do they even consider that part of the platform?

Fix: Analyze the platform's offering in your specific job context. What do they actually provide for your job? How strong is their implementation? What's their attention on this segment?

---

4. Static Boundary Assumption

Pattern: Treating competitive boundaries as permanent rather than constantly shifting.

Signs:

• Competitive analysis is a one-time exercise
• Surprise when an adjacent product moves into your space
• No monitoring of adjacency signals
• "That's not a competitor" dismissals that age poorly

Why it fails: Every product with motivation and capability can expand. Complement-substitute flips happen regularly. Platform sprawl is accelerating. Today's non-competitor is next quarter's primary threat.

The test: When did you last update your competitive boundary assessment?

Fix: Maintain an adjacency watch list. Set competitive radius estimates. Treat boundary monitoring as ongoing, not one-time. Define triggers for reassessment.

---

5. Segment Flattening

Pattern: Treating competitive position as uniform across all customer segments.

Signs:

• Single competitive positioning for all customers
• Confusion when feedback varies wildly by customer type
• "We compete with X" without "for whom"
• Marketing messages that resonate with some segments, alienate others

Why it fails: The same product occupies different competitive positions for different segments. You might dominate one context and be invisible in another. Aggregating obscures strategic insight.

The test: Does your competitive assessment change when you filter by segment?

Fix: Segment competitive analysis by hiring context. Create separate competitive maps per segment. Accept that competitive position is segment-specific.

---

Boundaries

Assumes

Not For

Degrades When

Complementary To

---

Worked Example: Task Management Space

Phase 1: Job Extraction

Product to analyze: A new task management tool targeting teams

Job Candidates:

1. "When I need to coordinate work across my team, I want to see who's doing what and when, so that work doesn't fall through cracks and we hit deadlines."

• When: Team coordination moment
• Want: Visibility into commitments
• So that: Execution reliability
• Evidence: Common in team productivity interviews

2. "When I'm overwhelmed by too many things to do, I want to capture and organize my tasks, so that I can focus without worrying about forgetting something."

• When: Personal overwhelm
• Want: Cognitive offload
• So that: Mental peace and focus
• Evidence: Personal productivity content

3. "When my manager asks for a status update, I want to quickly show progress on initiatives, so that I don't spend time on status reports."

• When: Reporting requirement
• Want: Automatic status visibility
• So that: Time savings
• Evidence: Enterprise buyer interviews

Analysis: These are three different jobs. A product optimized for #1 (team coordination) competes differently than one optimized for #2 (personal task capture) or #3 (status reporting).

Phase 2: Substitution Evidence

For Job #1 (team coordination):

False positives identified:

• Todoist: Same category, but serves personal task capture (Job #2), not team coordination
• Obsidian: Has task features, but serves knowledge management job
• Slack: Has workflow features, but serves communication job

Phase 3: Context Segmentation

Insight: "Task management" isn't one market. Engineering teams almost never consider the tools marketing teams use, and vice versa.

Phase 4: Adjacent Threats

Phase 5: Boundary Articulation

Competitive Niche: Team Task Coordination for Marketing/Operations Teams

• Job Boundary: "Coordinate work across team so nothing falls through cracks"
• NOT: Personal productivity, engineering workflow, status reporting to executives

We compete with: Asana, Monday.com, Trello (for smaller teams), spreadsheets (for migrations)

We do NOT compete with (despite appearances):

• Jira (engineering job, different buyers)
• Todoist (personal job, different context)
• Notion (knowledge management first; task features secondary)

Boundary stability: Watch Notion closely—they're one major release from being a primary competitor.

---

Success Indicators

Leading Indicators

Lagging Indicators

---

Evolution

Review Triggers

• [ ] Time: Review every quarter minimum
• [ ] Market event: Major competitor release, acquisition, or pivot
• [ ] Signal detection: Adjacent threat shows intent
• [ ] Win/loss surprise: Lost deal to unexpected competitor
• [ ] Customer feedback: "Why don't you compare to X?"

Changelog

Feature Commonality Analysis Framework

The Problem

Knowing what features exist across competitors isn't enough. You need to know:

1. What's table stakes? Features every serious competitor has. Missing these disqualifies you. 2. What's emerging? Features gaining adoption but not yet universal. The trend line matters. 3. What differentiates? Features few have that create competitive advantage. 4. What's missing everywhere? Gaps no one has filled that might represent opportunities—or graveyards.

Without prevalence analysis, you might:

• Build table stakes thinking they're differentiators
• Miss emerging standards and seem dated at launch
• Overinvest in rare features that don't matter to buyers
• Chase "differentiation" in graveyards where many have tried and failed

The cost: Building the wrong things, with the wrong emphasis, for the wrong strategic purpose.

---

Core Principles

1. Prevalence is Not Priority

That everyone has a feature doesn't mean users value it highly. That no one has it doesn't mean users want it.

Prevalence describes the competitive landscape. Value describes user importance. Strategic classification requires both.

A feature can be high-prevalence and low-value (expected noise—include but don't emphasize). A feature can be low-prevalence and high-value (opportunity—if validated).

2. Trajectory Matters More Than Snapshot

A feature present in 30% of products but growing rapidly differs strategically from one at 30% and shrinking.

Questions beyond "what percent have it?":

• Is this percentage increasing or decreasing?
• Are market leaders adding or removing it?
• Are new entrants including it by default?
• Is there discussion/demand driving adoption?

3. Segment Before Generalizing

"All competitors" masks important distinctions:

• Enterprise vs. SMB products have different prevalence patterns
• Market leaders vs. followers differ
• Price tiers create different expectations

A feature that's table stakes in enterprise may be a differentiator in SMB. Analyze the relevant competitive set for your context.

4. Depth Affects Classification

A feature with minimal implementations across the market might be:

• Table stakes at the minimal level
• A differentiator at best-in-class depth

"Has search" at 90% prevalence with most being basic text search means advanced search is a differentiator despite "search" being table stakes.

5. Opportunity Requires Validation

Just because no one has built something doesn't mean it's an opportunity.

Absence might indicate:

• No demand (graveyard)
• Technical infeasibility
• Unprofitable at current prices
• Strategic irrelevance
• Hidden regulatory barriers

Gaps require validation before treating as opportunities.

---

Key Vocabulary

---

The Classification Framework

Prevalence Tiers

Trajectory Overlays

The Value-Prevalence Matrix

                    HIGH USER VALUE           LOW USER VALUE
                    ─────────────────────────────────────────
HIGH PREVALENCE  │ MUST-HAVE              │ EXPECTED NOISE     │
(Table Stakes)   │ Must match or exceed   │ Include but don't  │
                 │ market depth           │ over-invest        │
                 ├────────────────────────┼────────────────────┤
MEDIUM           │ STRATEGIC BET          │ ME-TOO TRAP        │
PREVALENCE       │ Differentiate on depth │ Low value to build │
(Emerging/       │ or adjacent value      │ despite market     │
Contested)       │                        │ presence           │
                 ├────────────────────────┼────────────────────┤
LOW PREVALENCE   │ OPPORTUNITY            │ GRAVEYARD          │
(Differentiator/ │ Potential competitive  │ No one builds it   │
Gap)             │ advantage if validated │ because no one     │
                 │                        │ wants it           │
                 └────────────────────────┴────────────────────┘

Quadrant actions:

• Must-Have: Match market standard at minimum. Exceeding creates minor advantage.
• Expected Noise: Include with minimal investment. Don't highlight in marketing.
• Strategic Bet: Invest if aligned with positioning. Could become differentiator.
• Me-Too Trap: Avoid unless trivial to add. Doesn't move the needle.
• Opportunity: Validate demand rigorously. If validated, invest heavily.
• Graveyard: Do not build. Investigate why others don't have it.

---

Process

Phase 1: Market Definition

Input: Product category, analysis purpose Output: Product list with segmentation

Steps:

1. Define category boundaries:

• What products qualify as "in this space"?
• What are the inclusion criteria?
• Use output from Competitive Niche Boundary Framework if available

2. List all qualifying products:

• Aim for 8-15 for meaningful statistical analysis
• Include: market leaders, notable challengers, recent entrants
• Exclude: abandoned products, extreme niches

3. Segment the product list:

• By tier: Enterprise / Mid-market / SMB
• By position: Leader / Challenger / Follower / Niche
• By pricing: Premium / Standard / Freemium / Free

4. Decide analysis scope:

• Full market? (for general positioning)
• Your tier only? (for direct competition)
• Leaders only? (for aspiration benchmarking)

Output template:

## Market Definition: [Category]

### Inclusion Criteria
- [Criterion 1]
- [Criterion 2]

### Products Analyzed (N=[count])
| Product | Tier | Position | Pricing | Notes |
|---------|------|----------|---------|-------|
| [Name] | [Tier] | [Position] | [Price] | [Notable characteristics] |

### Segmentation Summary
| Segment | Count | Products |
|---------|-------|----------|
| Enterprise | [N] | [List] |
| Mid-market | [N] | [List] |
| SMB | [N] | [List] |

---

Phase 2: Prevalence Calculation

Input: Feature taxonomy (from Feature Taxonomy Framework), product list Output: Feature prevalence table

Steps:

1. For each canonical feature, record which products have it:

• Use consistent criteria for "has feature"
• Note depth tier if available
• Mark clearly absent vs. unknown

2. Calculate prevalence:

   Prevalence = (products with feature) / (total products) × 100

3. Calculate depth-adjusted prevalence (if using facets):

   Prevalence at [Tier] = (products at or above [Tier]) / (total products) × 100

4. Classify each feature into prevalence tier:

• ≥80% = Table Stakes
• 50-79% = Emerging Standard
• 30-49% = Contested
• 10-29% = Differentiator
• <10% = Rare/Gap

Output template:

## Feature Prevalence: [Category] (N=[product count])

### By Domain

#### [Domain 1]
| Feature | Has It | Prevalence | Tier |
|---------|--------|------------|------|
| [Feature 1] | [N]/[Total] | [%] | [Tier] |

### Summary by Tier
| Tier | Count | % of Features |
|------|-------|---------------|
| Table Stakes | [N] | [%] |
| Emerging Standard | [N] | [%] |
| Contested | [N] | [%] |
| Differentiator | [N] | [%] |
| Rare/Gap | [N] | [%] |

---

Phase 3: Trajectory Assessment

Input: Current prevalence data, historical perspective Output: Trajectory-annotated prevalence table

Steps:

1. For each feature, assess historical direction:

2. Assign trajectory:

• Growing: Prevalence increasing; new products include it
• Stable: Consistent over time
• Declining: Prevalence decreasing; products removing it

3. Note confidence in trajectory assessment:

• High: Multiple data points over time
• Medium: Some signals but limited history
• Low: Estimated based on market trends

Output template:

## Feature Trajectories

| Feature | Current Tier | Trajectory | Evidence | Confidence |
|---------|--------------|------------|----------|------------|
| [Feature] | [Tier] | [Growing/Stable/Declining] | [What indicates] | [H/M/L] |

---

Phase 4: Value Overlay

Input: Prevalence data, user research, market signals Output: Value-Prevalence classification

Steps:

1. For each feature (or feature cluster), assess user value:

2. Classify as High or Low value:

• Binary for simplicity
• When in doubt, default to analyzing as "unknown"

3. Plot features on Value-Prevalence Matrix:

• Identify which quadrant each feature falls into
• Note features near boundaries

Output template:

## Value-Prevalence Matrix Placement

### Must-Have (High Value, High Prevalence)
- [Feature]: [Why high value]
- [Feature]: [Why high value]

### Opportunity (High Value, Low Prevalence)
- [Feature]: [Validation status]
- [Feature]: [Validation status]

### Expected Noise (Low Value, High Prevalence)
- [Feature]: [Why still include]

### Me-Too Trap (Low Value, Medium Prevalence)
- [Feature]: [Why to avoid]

### Graveyard (Low Value, Low Prevalence)
- [Feature]: [Why absent]

---

Phase 5: Strategic Classification

Input: All prior analysis, your specific product/situation Output: Strategic feature classification for your product

Steps:

1. For your specific situation, classify each feature:

2. Prioritize within classifications:

• Must Match: by impact of absence
• Should Match: by trajectory speed
• Opportunity: by validation confidence

3. Document strategic rationale for each classification

Output template:

## Strategic Classification for [Your Product]

### Must Match (Parity Required)
| Feature | Current State | Target State | Gap | Priority |
|---------|--------------|--------------|-----|----------|
| [Feature] | [Have/Don't have/Partial] | [Target depth] | [What's missing] | P0/P1/P2 |

### Should Match (Plan to Add)
| Feature | Trajectory | Timeline Implication | Priority |
|---------|------------|---------------------|----------|
| [Feature] | [Growing/fast] | [When needed] | P1/P2/P3 |

### Opportunity to Lead (Differentiation)
| Feature | Value Evidence | Validation Status | Investment Level |
|---------|---------------|-------------------|------------------|
| [Feature] | [Evidence] | [Validated/Hypothesis] | High/Medium |

### Can Ignore
| Feature | Rationale |
|---------|-----------|
| [Feature] | [Why we're not building] |

### Watch List
| Feature | Trigger for Reclassification |
|---------|------------------------------|
| [Feature] | [What would change our assessment] |

---

Anti-Patterns

1. Prevalence Without Value

Pattern: Classifying features purely by how many competitors have them.

Signs:

• Building everything that's common
• Ignoring user priorities
• Product becomes bloated average
• No differentiation despite full feature list

Why it fails: Prevalence tells you the competitive landscape; value tells you where to invest. Building every common feature with equal emphasis produces mediocrity.

The test: For each feature you're building, can you cite user value evidence?

Fix: Always overlay user value. Table stakes get minimum viable depth; must-haves get investment.

---

2. Gap Enthusiasm

Pattern: Treating every market gap as an opportunity.

Signs:

• Excitement about features no one has built
• No investigation of why the gap exists
• "Differentiation" that users don't want
• Building for graveyards

Why it fails: Gaps require validation. Absence might mean no demand, technical infeasibility, or regulatory barriers. Many gaps are graveyards.

The test: Why don't competitors have this? Have others tried and failed?

Fix: Require validation evidence for any gap-based investment. Investigate why the gap exists before celebrating it.

---

3. Segment Blindness

Pattern: Treating "the market" as monolithic.

Signs:

• Comparing your SMB product to enterprise leaders
• Feeling behind on features your segment doesn't need
• Single prevalence calculation across all tiers
• Positioning against irrelevant competitors

Why it fails: Table stakes for enterprise differ from SMB. Leaders have different expectations than challengers. Analyzing irrelevant segments produces irrelevant conclusions.

The test: Is your competitive set segmented by tier, position, or pricing?

Fix: Segment analysis to your relevant competitive set. Different prevalence for different segments.

---

4. Depth Conflation

Pattern: Counting feature presence without accounting for implementation depth.

Signs:

• Marking yourself "have" when competitors are best-in-class
• False confidence in feature parity
• "We have search" when competitors have AI-powered semantic search
• Checkmarks hiding meaningful gaps

Why it fails: A minimal implementation may effectively be absent for demanding users. Depth determines competitive position within a feature.

The test: At what depth tier is 80% of the market? Is that your target depth?

Fix: Calculate depth-adjusted prevalence. A feature may be table stakes at basic depth but a differentiator at advanced depth.

---

5. Static Analysis

Pattern: Single-point-in-time analysis treated as permanent truth.

Signs:

• Referencing 18-month-old competitive analysis
• Missing that emerging standards have become table stakes
• Surprise at competitor moves
• No trigger for refresh

Why it fails: Markets evolve. What's contested today is table stakes tomorrow. Static analysis becomes progressively misleading.

The test: When did you last update prevalence data?

Fix: Build in refresh cadence. Major releases, new entrants, and funding announcements trigger review.

---

Boundaries

Assumes

Not For

Degrades When

Complementary To

---

Worked Example: Project Management Tools

Phase 1: Market Definition

Category: Team project management tools Scope: Mid-market focus (50-500 employee companies)

Products Analyzed (N=12):

Phase 2: Prevalence Calculation (Sample)

Domain: Task Management

Phase 3: Trajectory Assessment (Sample)

Phase 4: Value Overlay (Sample)

Must-Have (High Value, High Prevalence):

• Task dependencies: Critical for real project management; blocks work
• Custom fields: Enables workflow customization; high usage
• Multiple views: Different users need different visualizations

Opportunity (High Value, Low Prevalence):

• AI task suggestions: High demand in user feedback; limited implementations
• Workload management: Growing need; limited good solutions

Expected Noise (Low Value, High Prevalence):

• Recurring tasks: Expected but rarely differentiates
• Subtasks: Everyone has; rarely discussed

Graveyard:

• Social features (activity feeds, likes): Tried by many, used by few

Phase 5: Strategic Classification (for a new entrant)

Must Match:

Should Match (6-month roadmap):

Opportunity to Lead:

Can Ignore:

---

Success Indicators

Leading Indicators

Lagging Indicators

---

Evolution

Review Triggers

• [ ] Time: Minimum every 6 months
• [ ] Market event: Major competitor release, acquisition
• [ ] New entrant: New product enters with different feature set
• [ ] Technology shift: New capability becomes possible (AI, etc.)
• [ ] Strategy shift: Your positioning or target market changes

Changelog

Feature-Persona-Use Case Mapping Framework

The Problem

Products fail when features don't connect to who needs them (personas) and why (use cases).

The Feature Factory Problem: Teams ship features without clarity on who they serve or what job they enable. Features accumulate without strategy.

The Averaging Problem: Priority is set by averaging across all users, which erases signal. A feature critical for one persona and irrelevant for another becomes "moderate importance" and gets deprioritized.

The Gateway Blindness Problem: Enabling features (authentication, basic data structures) get deprioritized because they seem low-value in isolation—ignoring that they unlock compound value.

The Benefit Assumption Problem: Teams assume users will understand why a feature matters. "It's obvious" masks that different personas need different benefit articulations.

The Adjacent Ignorance Problem: Analysis focuses on obvious use cases, missing adjacent opportunities that competitors don't serve.

The consequences:

• Feature lists grow without strategy
• Priorities shift with opinion, not evidence
• Gateway features get cut, blocking later value
• Market opportunities go unnoticed
• Product-market fit becomes accidental, not designed

---

Core Principles

1. Features Are Means, Not Ends

Features exist to enable use cases. The use case (job-to-be-done) is the unit of value, not the feature.

A feature with no clear use case is feature debt—it exists, requires maintenance, but doesn't demonstrably deliver value.

The test: For any feature, can you complete this sentence? "[Persona] uses [feature] to accomplish [job] so they can [outcome]."

2. Same Feature, Different Jobs

A single feature may serve different personas in different ways. Document all mappings, not just the primary one.

Example: "Search" for an admin is "find any user quickly." For an end user, it's "find my content." Same feature, different jobs, different value propositions.

Implication: Feature value isn't scalar—it's a vector across personas.

3. Gateway Features Unlock Value

Some features enable other features or use cases. These have outsized strategic importance even if not directly valuable.

• Authentication enables everything multi-user
• Data import enables everything requiring existing data
• API enables all integrations

Gateway features should be evaluated by what they enable, not their standalone value.

4. Priority is Persona-Relative

"High priority" without specifying for whom is meaningless. A feature that's critical for one persona might be irrelevant for another.

Priority matrices must be per-persona, then weighted by strategic importance of each persona.

5. Adjacent Possible is Competitive Edge

Use cases competitors don't serve are your differentiation opportunity. Map the edges, not just the center.

Adjacent use cases are close to current offerings but not well-served. They represent:

• Underserved segments within existing markets
• Workflow steps that current tools don't cover
• Emotional jobs beyond functional ones

---

Key Vocabulary

---

Diagnostic States

State FP0: Feature List Without Mapping

Symptoms:

• Features listed without connection to who/why
• Can't answer "who needs this feature most?"
• Backlog is a list of things, not a map of value
• Features justified by "it would be cool" or "competitors have it"
• No persona ownership of features

Key Questions:

• For each feature: which persona needs it most?
• For each feature: what job does it help accomplish?
• Which features have no clear persona owner?
• Which features have no clear use case?

Interventions:

• Basic mapping exercise: feature → persona → use case
• Identify orphan features (features with no clear mapping)
• Use Feature Audit Template

Risk: Building features nobody needs; no strategic coherence.

---

State FP1: One-to-One Mapping Only

Symptoms:

• Each feature mapped to one persona, one use case
• Missing that same feature serves multiple purposes
• Can't explain feature value to different audiences
• Marketing struggles to position for different segments
• "This is a feature for [one type] of user"

Key Questions:

• Could this feature serve another persona?
• What else could someone do with this feature?
• How would different personas describe this feature's value?

Interventions:

• Multi-persona feature analysis: for each feature, consider all personas
• Benefit translation exercise: write value proposition per persona
• Use Multi-Persona Feature Map Template

Risk: Missing feature value for secondary personas; narrow marketing.

---

State FP2: Missing Use Case Hierarchy

Symptoms:

• Use cases are flat list without structure
• Can't distinguish core jobs from supporting jobs
• Related jobs and emotional jobs missing
• Feature decisions made without job context
• "This helps users do [vague activity]"

Key Questions:

• What's the core job this use case supports?
• What sub-jobs make up this use case?
• What related jobs might users also have?
• What emotional jobs are being addressed?

Interventions:

• Jobs-to-be-Done hierarchy mapping
• Core job identification per persona
• Emotional job surfacing through user research
• Use Job Hierarchy Template

Risk: Features address symptoms rather than core jobs.

---

State FP3: No Gateway Feature Awareness

Symptoms:

• Dependencies between features not documented
• "Why do we need that?" questions for enabling features
• Features that unlock value seen as low priority
• MVP lacks critical enabling capabilities
• Compound value not recognized

Key Questions:

• What does this feature enable?
• What other features require this to function?
• What's the dependency chain?
• Which features are prerequisites for others?

Interventions:

• Dependency mapping: for each feature, document what it enables
• Gateway feature identification
• Enablement scoring
• Use Gateway Feature Map Template

Risk: Cutting features that block later value; incomplete products.

---

State FP4: Priority Without Persona Context

Symptoms:

• Global priority ranking without persona breakdown
• "High priority" without "for whom"
• Persona needs averaged instead of stratified
• Different stakeholders have incompatible priorities
• Priority debates that never resolve

Key Questions:

• High priority for which persona?
• If personas disagree, which persona matters more?
• How do you weigh persona priorities?
• What's the strategic importance of each persona?

Interventions:

• Create per-persona priority matrices
• Define strategic persona weighting
• Establish priority conflict resolution protocol
• Use Persona Priority Matrix Template

Risk: Features prioritized for wrong personas; wrong users happy.

---

State FP5: Missing Adjacent Opportunities

Symptoms:

• Only obvious use cases mapped
• Can't articulate differentiation opportunity
• "Same as competitors" positioning
• No vision for underserved needs
• Analysis stops at what exists

Key Questions:

• What use cases are close but not well-served?
• Where are competitors weak?
• What jobs do users attempt that current products don't support?
• What's the adjacent possible?

Interventions:

• Competitive gap analysis by use case
• Adjacent use case discovery from user evidence
• Edge job mapping
• Use Adjacent Opportunity Template

Risk: Competing on same ground as everyone else.

---

State FP6: Complete Mapping

Symptoms:

• All features mapped to personas and use cases
• Multi-persona mappings documented
• Gateway features identified with enablement scores
• Priority is persona-relative with weighting
• Adjacent opportunities articulated and prioritized

Indicators:

• Can explain any feature's value to any persona
• Priority decisions have documented rationale
• Dependency chains are clear
• Competitive differentiation is articulated

Next Step: Feed into Build/Buy/Partner decisions; inform roadmap.

---

Process

Phase 1: Feature Inventory and Audit

Input: Feature list (from taxonomy or product backlog), Persona set (from Persona Construction) Output: Feature inventory with initial mappings and audit flags

Steps:

1. List all features (current or proposed):

• Use canonical names from Feature Taxonomy if available
• Include both existing and planned features

2. Attempt initial persona mapping:

• For each feature: which persona(s) would use this?
• Mark confidence: High / Medium / Low / Unknown

3. Identify audit flags:

• Orphan features: No clear persona owner
• Overloaded features: Many personas claim (needs analysis)
• Assumed mappings: Mapped without evidence

Output template:

## Feature Audit: [Product]

### Feature Inventory
| Feature | Primary Persona | Use Case (initial) | Confidence |
|---------|----------------|-------------------|------------|
| [Feature] | [Persona or "Orphan"] | [Job or "TBD"] | [H/M/L/Unknown] |

### Audit Flags
**Orphan Features** (no clear owner):
- [Feature]: [Why unclear]

**Overloaded Features** (multiple personas):
- [Feature]: [Personas claiming] - needs multi-persona analysis

**Low Confidence Mappings**:
- [Feature]: [What's uncertain]

---

Phase 2: Use Case Discovery

Input: Feature inventory, Persona set, User research evidence Output: Job hierarchy per persona, Feature-job mapping

Steps:

1. For each persona, list jobs they're trying to do:

• Start with evidence from Persona Construction
• Add jobs implied by feature usage patterns

2. Structure jobs hierarchically:

3. Map features to jobs:

• Which features serve which jobs?
• At which hierarchy level does the feature operate?

4. Identify job gaps:

• Which jobs have no feature support?
• Which sub-jobs are underserved?

Output template: See Job Hierarchy Template

---

Phase 3: Multi-Persona Analysis

Input: Feature-job mapping, Full persona set Output: Multi-persona feature map, Benefit translations

Steps:

1. For each feature, consider ALL personas:

• Primary persona: who needs this most?
• Secondary personas: who else would use it?
• Non-users: who explicitly doesn't need this?

2. Document different use cases per persona:

• Same feature, different job
• Same feature, different outcome desired

3. Translate benefits per persona:

• How would you explain this feature's value to each persona?
• What language/framing resonates?

4. Identify persona-specific priority:

• Critical / Important / Nice-to-have / Irrelevant

Output template:

## Multi-Persona Analysis: [Feature]

### Persona Mapping
| Persona | Use Case | Outcome Desired | Priority |
|---------|----------|-----------------|----------|
| [Persona 1] | [Their use] | [Their goal] | Critical |
| [Persona 2] | [Their use] | [Their goal] | Nice-to-have |
| [Persona 3] | — | — | Irrelevant |

### Benefit Translations
**For [Persona 1]**: "[Feature] helps you [outcome in their language]"
**For [Persona 2]**: "[Feature] lets you [different framing]"

---

Phase 4: Gateway Feature Mapping

Input: Feature list, Use case mappings Output: Feature dependency map, Gateway feature identification

Steps:

1. For each feature, ask: "What does this enable?"

• Other features that depend on this
• Use cases that require this first
• Workflows that assume this exists

2. Map dependencies:

• Hard prerequisites: Feature is impossible without
• Soft prerequisites: Feature is impaired without

3. Identify gateway features:

• Features that enable 3+ other features or use cases
• Features that are prerequisites for core jobs

4. Calculate enablement scores:

• Count of features/use cases enabled
• Weight by importance of enabled features

Output template: See Gateway Feature Map Template

---

Phase 5: Adjacent Opportunity Discovery

Input: Job hierarchies, Competitive analysis, User evidence Output: Adjacent opportunity inventory, Prioritized differentiation list

Steps:

1. Map competitor coverage of jobs:

• For each job in hierarchy: who serves it well? Partially? Not at all?
• Identify underserved jobs

2. Discover adjacent jobs from evidence:

• User research: "I wish I could also..."
• Support tickets: requests for not-current functionality
• Reviews: complaints about workflow gaps

3. Assess opportunity attractiveness:

4. Prioritize opportunities:

• High proximity + high demand + low competition = top priority
• Validate before committing

Output template: See Adjacent Opportunity Template

---

Anti-Patterns

1. The Feature Factory

Pattern: Adding features without mapping to personas or use cases.

Signs:

• "We shipped 50 features this quarter!"
• No documentation of who features are for
• Backlog grows without pruning
• Features justified by velocity, not value

Why it fails: Features without mappings are feature debt. They may not solve real problems. They complicate the product without adding value.

The test: For every feature shipped, can you cite the persona and job?

Fix: No feature ships without documented persona-use case mapping.

---

2. The Averaging Trap

Pattern: Averaging priorities across personas instead of maintaining persona-specific priorities.

Signs:

• Global priority scores
• "Everyone needs this a little"
• Features that are "moderate priority" for everyone
• Persona-specific needs lost in aggregation

Why it fails: Averaging erases signal. A feature critical for Persona A and irrelevant for Persona B averages to "moderate" and gets deprioritized vs. a feature that's "nice" for everyone.

The test: Do you have separate priority rankings per persona?

Fix: Maintain per-persona priority matrices. Weight by strategic importance of each persona.

---

3. The Gateway Blindness

Pattern: Deprioritizing features that enable other features because they seem low-value in isolation.

Signs:

• "Authentication isn't a selling point"
• "Data import can wait"
• Core enabling features pushed to later releases
• Later features blocked by missing prerequisites

Why it fails: Gateway features unlock compound value. Authentication isn't exciting, but every logged-in feature depends on it. Cutting enablers blocks later value.

The test: What does this feature enable? What's blocked without it?

Fix: Map dependencies explicitly. Evaluate gateway features by enablement score, not standalone value.

---

4. The Benefit Assumption

Pattern: Assuming users will understand feature value without translation.

Signs:

• "It's obvious why this matters"
• Same feature description for all audiences
• Marketing that lists features, not benefits
• Users not adopting clearly valuable features

Why it fails: Features need translation into outcomes. Different personas need different benefit articulations. What's obvious to you isn't obvious to them.

The test: For each feature, can you state the benefit in each persona's language?

Fix: Document benefit translation per persona. Test messaging with actual users.

---

5. The Adjacent Ignorance

Pattern: Mapping only obvious use cases that competitors already serve.

Signs:

• "We cover the same use cases as competitors"
• No vision for differentiation
• Analysis ends at current market offerings
• User requests for "other stuff" ignored

Why it fails: If you only serve the same use cases as competitors, you're competing on execution only. Adjacent opportunities are differentiation sources.

The test: What jobs do users attempt that no product serves well?

Fix: Actively discover adjacent use cases. Look for jobs at the edges of current coverage.

---

Boundaries

Assumes

Not For

Degrades When

Complementary To

---

Worked Example: Note-Taking App

Phase 1: Feature Audit (Sample)

Personas: Student, Professional, Creator

Orphan Features: Spaced repetition (assumed student need, not validated)

Phase 2: Job Hierarchy (Student Persona)

Core Job: Learn and retain information effectively

Sub-Jobs:

• Capture information during class/reading
• Organize notes by course/topic
• Review and study notes
• Connect related concepts

Related Jobs:

• Manage assignment deadlines
• Collaborate on group projects
• Track course requirements

Emotional Jobs:

• Feel prepared for exams
• Reduce anxiety about forgetting
• Appear organized to self and others

Phase 3: Multi-Persona Analysis (Search Feature)

Benefit Translations:

• Student: "Find any note instantly so you're never hunting for last week's lecture before the exam"
• Professional: "Search across all notes to pull up that decision from six months ago in seconds"
• Creator: "Pick up any draft where you left off without losing momentum"

Phase 4: Gateway Features

Feature: Cloud Sync

Enablement Score: 4 features enabled Assessment: Gateway feature; required before collaboration roadmap

Phase 5: Adjacent Opportunities

---

Success Indicators

Leading Indicators

Lagging Indicators

---

Evolution

Review Triggers

• [ ] New persona validated: Extend mapping to new persona
• [ ] Major feature release: Update mappings for new features
• [ ] User research findings: Incorporate new job insights
• [ ] Competitive shift: Reassess adjacent opportunities
• [ ] Time: Quarterly review minimum

Changelog

Competitive Feature Matrix: [Category]

Analysis Date: [Date] Products Analyzed: [N] Analyst: [Name]

---

Products Included

---

Feature Matrix by Domain

Domain: [Domain Name]

Depth Key: ● Best-in-class | ◐ Advanced | ○ Basic | ◔ Minimal | — Absent

Tier Key: T=Table Stakes | E=Emerging | C=Contested | D=Differentiator | R=Rare

Trajectory Key: ↑=Growing | →=Stable | ↓=Declining

---

Domain: [Domain Name]

---

Summary Statistics

By Prevalence Tier

By Product

---

Notable Patterns

Market Leaders Converging On

• [Feature]: [Evidence of convergence]
• [Feature]: [Evidence of convergence]

Emerging Differentiators

• [Feature]: [Who has it, why it matters]
• [Feature]: [Who has it, why it matters]

Notable Gaps (No One Has)

• [Capability gap]: [Opportunity or graveyard?]
• [Capability gap]: [Opportunity or graveyard?]

Depth Differentiators (Feature Exists, Quality Varies)

• [Feature]: [Who leads, what makes them better]
• [Feature]: [Who leads, what makes them better]

---

Strategic Implications

Must-Have for Entry

• [Feature 1]: Table stakes, [depth] required
• [Feature 2]: Table stakes, [depth] required

Opportunity Areas

• [Opportunity 1]: [Evidence of underserved need]
• [Opportunity 2]: [Evidence of underserved need]

Avoid (Graveyard Features)

• [Feature]: [Why others don't have it]

---

Methodology Notes

Data Sources

• [How feature presence was determined]
• [How depth was assessed]

Limitations

• [Any products with limited access]
• [Features that were hard to assess]

Refresh Schedule

• Next review: [Date]
• Trigger events: [What would prompt earlier review]

Evidence Census Template

Category: [Product category being analyzed] Date: [Date of census] Analyst: [Name]

---

Review Sources

Quality ratings: High (detailed, contextual) / Medium (useful but limited) / Low (surface-level)

---

Forum/Community Sources

Activity level: High (daily posts) / Medium (weekly) / Low (monthly or less)

---

Social Media Sources

---

Interview/Survey Data

Access: Have / Need to acquire / Public

---

Industry Publications

---

Coverage Assessment

Well-Covered User Types

• [User type 1]: [Which sources cover them]
• [User type 2]: [Which sources cover them]

Under-Represented User Types

• [User type]: [Why missing / how to address]

Geographic/Demographic Gaps

• [Gap]: [Impact on analysis]

Temporal Gaps

• [Time period]: [Coverage status]

---

Bias Assessment

---

Evidence Collection Plan

High Priority (Must Collect)

1. [Source]: [Why essential] 2. [Source]: [Why essential]

Medium Priority (Would Improve)

1. [Source]: [What it would add]

Nice to Have

1. [Source]: [Marginal value]

---

Notes

[Any other observations about evidence availability or quality]