.claude/skills/prd-v03-moat-definition/SKILL.md
Assess competitor defensibility and define our own moat strategy during PRD v0.3 Commercial Model. Triggers on requests to analyze competitor moats, define our defensibility, assess switching costs, identify vulnerabilities, find wedge opportunities, or when user asks "what's our moat?", "how defensible are they?", "where can we compete?", "switching costs?", "defensibility", "who to target". Consumes Competitive Landscape (v0.2) CFD- entries. Outputs CFD- entries for competitor moats and BR- entries for targeting rules and our defensibility strategy.
npx skillsauth add mattgierhart/PRD-driven-context-engineering prd-v03-moat-definitionInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
Position in HORIZON workflow: v0.2 Competitive Landscape → v0.3 Moat Definition → v0.3 Pricing Model Selection
This skill requires prior work from v0.2:
This skill assumes v0.2 analysis is complete with documented competitors.
This skill creates/updates:
All CFD moat analysis entries should include:
confidence: 2-3/5 (based on public evidence + user interviews about switching friction)Example moat analysis entry:
CFD-055: Competitor Moat Analysis — Notion
Competitor: Notion
Primary Moat Type: Switching Costs (data lock-in)
Moat Strength Tier: Strong
Confidence: 3/5 (source: public-research + 2-user-interviews)
Date: 2026-02-01
Switching Cost Quantification:
- Financial: Multi-year contract, no early termination ($0 direct cost)
- Time/Effort: 20+ hours migration, team retraining
- Data Migration: Proprietary database format (complex export)
- Workflow Retraining: Unique templates, team habits
- Integration Rework: Deep Slack/GitHub dependencies
Total Switching Cost: $3K in labor + 20 hours = Material friction
Moat Verdict: Strong — switching costs >$3K + meaningful time investment
Vulnerability Signal: SMB segment with small teams; they use <20% of feature set (opportunity for simpler tool)
Targeting Decision: Avoid direct competition. Wedge in SMB with simplified, cheaper offering.
Evidence:
- CFD-042 (landscape): Reviews show enterprise love; SMB complaints focus on cost + complexity
- CFD-015 (value hypothesis): SMB would save $12,500/year with simpler tool
Next Target: "Would move to 4/5 if we interview 5+ SMB teams about exact switching cost dollars"
Every moat falls into one of six types. Identify primary + secondary moats per competitor:
| Moat Type | Definition | Strong When | Weak When | |-----------|------------|-------------|-----------| | Switching Costs | Friction to leave (data, workflow, contracts) | Multi-year data, deep integrations | Easy export, monthly contracts | | Network Effects | Value increases with users | Two-sided marketplace, content platform | Single-player tool, linear value | | Data/IP | Proprietary data or algorithms | Unique training data, patents | Commodity ML, public datasets | | Brand/Trust | Recognition, credibility | Regulated industry, high-risk decisions | Low-stakes, undifferentiated | | Scale/Cost | Volume economics | Infrastructure-heavy, marginal cost near zero | Labor-intensive, linear cost | | Regulatory | Compliance barriers | Certifications required, government contracts | No compliance requirements |
For micro-SaaS: Switching costs and brand/trust matter most. Network effects and scale rarely apply.
Rate each competitor's defensibility:
| Tier | Criteria | Evidence Signals | Targeting Implication | |------|----------|------------------|----------------------| | Impenetrable | Multi-layered moat, 10+ years data lock-in | "Would take years to switch" | Avoid direct competition | | Strong | Significant switching friction, 1-2 year contracts | High NPS + low churn despite complaints | Target underserved segments only | | Moderate | Some friction, workarounds exist | Churn 5-10%, export options | Wedge opportunity exists | | Weak | Easy to replace, commodity offering | Monthly plans, high churn, price shopping | Direct competition viable | | Eroding | Former strength declining | New alternatives gaining share | Aggressive targeting |
Gate rule: Don't compete where incumbent has Impenetrable or Strong moat unless targeting segment they explicitly ignore.
Quantify ALL switching costs — the sum determines moat strength:
| Cost Type | High Impact | Low Impact | How to Assess | |-----------|-------------|------------|---------------| | Financial | >6mo contract, early termination fees | Monthly billing, no penalty | Check pricing page terms | | Time/Effort | 40+ hr migration, retraining | <4 hr setup, familiar UX | Trial the competitor | | Data Migration | Proprietary format, no export | Standard export (CSV, API) | Test export function | | Workflow Retraining | Unique methodology, team habits | Standard patterns | Read onboarding docs | | Integration Rework | Deep API dependencies | Standalone tool | Map their integrations |
Calculation: Sum hours + dollars. >$5K or >40hr = material switching cost.
Use moat analysis to determine where to compete:
Moat Impenetrable/Strong → DON'T COMPETE HERE
↓ unless
Target ignored segment (SMB, specific vertical)
Moat Moderate → WEDGE STRATEGY
↓ identify
Entry point that bypasses switching friction
Moat Weak/Eroding → DIRECT COMPETITION
↓ execute
Feature + price attack on their core
A wedge exists when:
Retrieve CFD- entries from v0.2 Competitive Landscape. For each competitor, you need: pricing, complaints, feature set.
For each competitor, determine primary moat type. Use evidence from reviews, pricing structure, integration depth.
Apply tier criteria. Flag if insufficient evidence (Tier 4-5 confidence).
Complete the 5-category switching cost assessment. Quantify hours + dollars.
Where is their moat weakest? Which segments do they ignore? What's eroding?
CFD entries (customer_feedback.md): Template: assets/cfd-moat-analysis.md
CFD-MOT-###: [Competitor] Moat Analysis — [Moat Type], [Strength Tier]
BR entries (BUSINESS_RULES.md): Template: assets/br-targeting.md
BR-TGT-###: [Targeting Rule] — based on [Competitor] moat weakness
| Don't | Do Instead | |-------|------------| | "They're big" | Specify which moat type + evidence | | Assume low switching cost | Quantify: hours + dollars | | Only analyze direct competitors | Include Type 4-5 (workarounds, inertia) | | Underestimate integration moat | Map actual dependency depth | | Ignore eroding moats | Track signals: new entrants, complaints | | Target where moat is strong | Find the segment where moat doesn't apply |
Before advancing to Our Moat Articulation:
| Consumer | What It Needs | Format | |----------|---------------|--------| | v0.3 Our Moat Articulation | Where competitors are weak, what moats work | CFD-MOT entries | | v0.3 Pricing Model | What price points bypass switching friction | BR-TGT entries | | v0.5 Red Team | Risks of competitor response | Moat strength tiers | | v0.9 GTM | Positioning against competitor moats | Targeting rules |
references/examples.mdassets/cfd-moat-analysis.mdassets/br-targeting.mdtools
Make technology decisions for every product capability by discovering existing assets, evaluating vendor-aligned options, and categorizing as Reuse/Extend/Build/Buy/Integrate/Research during PRD v0.5 Red Team Review. Handles both greenfield and brownfield contexts. Triggers on "tech stack", "build or buy?", "what technologies?", "technical decisions", "what do we reuse?", "existing stack", "vendor constraint", "IBM-first", "what tools do we need?", "evaluate solutions", "select tech stack". Consumes FEA- (features), SCR- (screens), RISK- (constraints). Outputs TECH- entries with decisions, rationale, and cross-references. Feeds v0.6 Architecture Design.
development
Define success criteria and tracking setup for launch during PRD v0.9 Go-to-Market. Triggers on requests to define launch metrics, set up tracking, or when user asks "how do we measure launch success?", "launch KPIs", "tracking setup", "success criteria", "analytics", "launch goals". Outputs KPI- entries specialized for launch measurement.
development
Define go-to-market strategy including launch plan, messaging, channels, and timing during PRD v0.9 Go-to-Market. Triggers on requests to plan launch, define GTM strategy, or when user asks "how do we launch?", "go-to-market", "launch plan", "marketing strategy", "messaging", "launch channels", "GTM". Outputs GTM- entries with launch plan components.
development
Establish channels and processes for capturing and processing post-launch feedback during PRD v0.9 Go-to-Market. Triggers on requests to set up feedback systems, capture user input, or when user asks "how do we collect feedback?", "feedback loop", "user research", "post-launch feedback", "customer feedback", "NPS", "voice of customer". Outputs CFD- entries specialized for post-launch feedback capture.