@veyralabs/skills 0.5.1 → 0.5.3
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/package.json +1 -1
- package/skills/venture-suite/venture-analyst/SKILL.md +213 -1
- package/skills/venture-suite/venture-analyst/references/execution-roadmap.md +187 -0
- package/skills/venture-suite/venture-analyst/references/moat-patterns.md +176 -0
- package/skills/venture-suite/venture-analyst/templates/verdict.md +132 -0
package/package.json
CHANGED
|
@@ -9,13 +9,14 @@ Research a startup or SaaS idea and determine if it's worth building. No fluff -
|
|
|
9
9
|
|
|
10
10
|
## What this does
|
|
11
11
|
|
|
12
|
-
|
|
12
|
+
Six phases, each producing structured output:
|
|
13
13
|
|
|
14
14
|
1. **Problem Discovery** - Find evidence the problem actually exists (Reddit, HN, GitHub issues, trends)
|
|
15
15
|
2. **Competitor Intelligence** - Map the landscape, find gaps, extract pricing signals
|
|
16
16
|
3. **Validation Experiments** - Generate 3 prioritized experiments to test demand before building
|
|
17
17
|
4. **Verdict** - Bull/Bear/Judge debate with Confidence Engine and scored recommendation
|
|
18
18
|
5. **Decision Intelligence** - Contradiction detection, founder trap check, reality check, distribution plan, time-to-first-dollar
|
|
19
|
+
6. **Execution & Moat** - 30-day roadmap, moat scoring, PMF simulation, market timing
|
|
19
20
|
|
|
20
21
|
## How to use
|
|
21
22
|
|
|
@@ -394,6 +395,212 @@ What would accelerate this: [specific factor]
|
|
|
394
395
|
What would delay this: [specific risk]
|
|
395
396
|
```
|
|
396
397
|
|
|
398
|
+
### Assumption Map
|
|
399
|
+
|
|
400
|
+
Every startup decision rests on assumptions. Most founders know the surface ones. The dangerous ones are buried.
|
|
401
|
+
|
|
402
|
+
Identify the 3 critical assumptions this startup cannot survive without. For each:
|
|
403
|
+
- What the startup is betting on being true
|
|
404
|
+
- Confidence level based on actual evidence collected (not gut feel)
|
|
405
|
+
- What would validate or invalidate it
|
|
406
|
+
|
|
407
|
+
```
|
|
408
|
+
Critical Assumption A1:
|
|
409
|
+
[The core belief about the problem/customer]
|
|
410
|
+
Confidence: [0-100]
|
|
411
|
+
Based on: [evidence or lack of it]
|
|
412
|
+
Validates if: [specific observable outcome]
|
|
413
|
+
Kills startup if: [falsified by X]
|
|
414
|
+
|
|
415
|
+
Critical Assumption A2:
|
|
416
|
+
[Usually the monetization or switching assumption]
|
|
417
|
+
Confidence: [0-100]
|
|
418
|
+
Based on: [evidence or lack of it]
|
|
419
|
+
Validates if: [specific observable outcome]
|
|
420
|
+
Kills startup if: [falsified by X]
|
|
421
|
+
|
|
422
|
+
Critical Assumption A3:
|
|
423
|
+
[Usually the distribution or growth assumption]
|
|
424
|
+
Confidence: [0-100]
|
|
425
|
+
Based on: [evidence or lack of it]
|
|
426
|
+
Validates if: [specific observable outcome]
|
|
427
|
+
Kills startup if: [falsified by X]
|
|
428
|
+
```
|
|
429
|
+
|
|
430
|
+
Rank them: most dangerous assumption first (lowest confidence that is also most critical to survival).
|
|
431
|
+
|
|
432
|
+
This is not a list of things to do. It is a map of what the founder believes vs what the evidence supports.
|
|
433
|
+
|
|
434
|
+
## Phase 6 - Execution & Moat
|
|
435
|
+
|
|
436
|
+
**Goal:** Answer "should you dedicate the next 2 years of your life to this?" - not just "is it a good idea?"
|
|
437
|
+
|
|
438
|
+
This phase converts the analysis into action and answers the defensibility question.
|
|
439
|
+
|
|
440
|
+
### Execution Roadmap
|
|
441
|
+
|
|
442
|
+
Use `references/execution-roadmap.md` for the full framework. Output a week-by-week plan tailored to the verdict:
|
|
443
|
+
|
|
444
|
+
**If BUILD:**
|
|
445
|
+
- Week 1: find 5 people with the problem (specific communities from the research)
|
|
446
|
+
- Week 2: deliver value manually before building
|
|
447
|
+
- Week 3: charge for it
|
|
448
|
+
- Week 4: find customer 2-3 and a referral
|
|
449
|
+
|
|
450
|
+
Key rule: no code until someone commits to paying. The roadmap builds toward a transaction, not a product.
|
|
451
|
+
|
|
452
|
+
**If VALIDATE FIRST:**
|
|
453
|
+
- Define the one critical unknown in one sentence
|
|
454
|
+
- Run the cheapest test that could falsify it (2 weeks max)
|
|
455
|
+
- Define pass/fail threshold before starting
|
|
456
|
+
- Week 4: commit to BUILD or pivot/stop based on data
|
|
457
|
+
|
|
458
|
+
**If AVOID:**
|
|
459
|
+
- 2-week pivot investigation using the most interesting signal from the research
|
|
460
|
+
- Or clean stop criteria with specific trigger conditions for revisiting
|
|
461
|
+
|
|
462
|
+
Always include:
|
|
463
|
+
```
|
|
464
|
+
Do NOT build yet: [specific features to avoid and why]
|
|
465
|
+
Reassess if: [specific trigger that means the plan is failing]
|
|
466
|
+
```
|
|
467
|
+
|
|
468
|
+
### Kill Criteria
|
|
469
|
+
|
|
470
|
+
Most founders know when to start. Almost none know when to stop.
|
|
471
|
+
|
|
472
|
+
Generate kill criteria calibrated to the specific idea and market type. These are not generic - they come from the evidence and experiment plan.
|
|
473
|
+
|
|
474
|
+
```
|
|
475
|
+
Kill Criteria for [idea]:
|
|
476
|
+
|
|
477
|
+
If after [days] from starting:
|
|
478
|
+
|
|
479
|
+
Experiments:
|
|
480
|
+
- Fewer than [n] real customer interviews completed
|
|
481
|
+
- Fewer than [n] people willing to schedule a call
|
|
482
|
+
- Zero payment intent (pre-order, deposit, contract signed)
|
|
483
|
+
|
|
484
|
+
Signals:
|
|
485
|
+
- [specific negative signal tied to the idea]
|
|
486
|
+
- [specific negative signal]
|
|
487
|
+
|
|
488
|
+
-> Stop. Do not pivot yet. First answer: was the problem real or did we imagine it?
|
|
489
|
+
|
|
490
|
+
Pivot trigger (instead of stop):
|
|
491
|
+
If the problem gets validated but [specific conversion/monetization step] fails -> pivot to [specific narrower scope or different monetization]
|
|
492
|
+
```
|
|
493
|
+
|
|
494
|
+
Thresholds must be concrete numbers, not vague goals. "Not enough traction" is not a kill criterion. "Zero paying customers after 21 days of direct outreach" is.
|
|
495
|
+
|
|
496
|
+
### Pivot Engine
|
|
497
|
+
|
|
498
|
+
Run this when verdict = AVOID or when Kill Criteria are hit.
|
|
499
|
+
|
|
500
|
+
Based on the signals collected in Phases 1-2, identify 2-3 realistic pivot directions. Pivots must be grounded in actual evidence - not invented alternatives.
|
|
501
|
+
|
|
502
|
+
Pivot types to consider (from `references/lean-startup.md`):
|
|
503
|
+
- **Segment pivot** - same problem, different customer (who else has this pain?)
|
|
504
|
+
- **Problem pivot** - same customer, different problem (what else do they complain about?)
|
|
505
|
+
- **Channel pivot** - same product, different distribution (where are buyers actually found?)
|
|
506
|
+
- **Scope pivot** - same idea, 80% smaller (which one feature has the most evidence?)
|
|
507
|
+
|
|
508
|
+
Output format:
|
|
509
|
+
```
|
|
510
|
+
Pivot Option 1: [type]
|
|
511
|
+
From: [current idea]
|
|
512
|
+
To: [specific pivot]
|
|
513
|
+
Evidence: [signal from research that supports this direction]
|
|
514
|
+
Risk: [what could still be wrong]
|
|
515
|
+
|
|
516
|
+
Pivot Option 2: [type]
|
|
517
|
+
From: [current idea]
|
|
518
|
+
To: [specific pivot]
|
|
519
|
+
Evidence: [signal from research that supports this direction]
|
|
520
|
+
Risk: [what could still be wrong]
|
|
521
|
+
|
|
522
|
+
Recommended pivot: [1 or 2] - because [one sentence reason]
|
|
523
|
+
```
|
|
524
|
+
|
|
525
|
+
Do not generate pivots if no supporting evidence exists. If the research found nothing reusable, state: "No evidence-backed pivot found. Consider a different problem space entirely."
|
|
526
|
+
|
|
527
|
+
### Moat Intelligence
|
|
528
|
+
|
|
529
|
+
Score all 5 moat types using `references/moat-patterns.md`. For each:
|
|
530
|
+
|
|
531
|
+
```
|
|
532
|
+
Distribution moat: [1-10] - [one-line reason]
|
|
533
|
+
Data moat: [1-10] - [one-line reason]
|
|
534
|
+
Community moat: [1-10] - [one-line reason]
|
|
535
|
+
Switching cost: [1-10] - [one-line reason]
|
|
536
|
+
Execution moat: [1-10] - [one-line reason]
|
|
537
|
+
|
|
538
|
+
Overall Moat Score: [weighted average of top 2]
|
|
539
|
+
|
|
540
|
+
Most realistic moat: [type]
|
|
541
|
+
How to build it: [specific action, not generic advice]
|
|
542
|
+
```
|
|
543
|
+
|
|
544
|
+
Do not score high without evidence. "We will accumulate data" is not a data moat - it is a plan. Score what exists or can realistically exist in 6 months.
|
|
545
|
+
|
|
546
|
+
### PMF Simulation
|
|
547
|
+
|
|
548
|
+
Generate 3 ICP personas based on the evidence found in Phases 1-2. Each persona is grounded in actual signals from the research, not invented.
|
|
549
|
+
|
|
550
|
+
```
|
|
551
|
+
Persona A: [job title / situation]
|
|
552
|
+
- Current workflow for the problem: [specific, from research]
|
|
553
|
+
- What they hate about current solution: [from Reddit/HN quotes]
|
|
554
|
+
- What they pay today: [from competitor pricing research]
|
|
555
|
+
- What they would never pay for: [inferred from pain signals]
|
|
556
|
+
- Adoption trigger: [what would make them switch]
|
|
557
|
+
- Adoption blocker: [what would stop them even if interested]
|
|
558
|
+
```
|
|
559
|
+
|
|
560
|
+
Then simulate a 4-week adoption arc for each persona:
|
|
561
|
+
|
|
562
|
+
```
|
|
563
|
+
Week 1: discovers product (channel: [specific channel from distribution plan])
|
|
564
|
+
Week 2: [tries free / books demo / reads docs]
|
|
565
|
+
Week 3: [converts / churns / stalls - and why]
|
|
566
|
+
Week 4: [retained / referred / cancelled]
|
|
567
|
+
```
|
|
568
|
+
|
|
569
|
+
From the 3 simulations, identify the PMF friction points:
|
|
570
|
+
```
|
|
571
|
+
Main adoption blockers:
|
|
572
|
+
- [blocker 1]: affects [n/3] personas
|
|
573
|
+
- [blocker 2]: affects [n/3] personas
|
|
574
|
+
|
|
575
|
+
Easiest persona to convert: [A/B/C] - because [reason]
|
|
576
|
+
Start here.
|
|
577
|
+
```
|
|
578
|
+
|
|
579
|
+
### Market Timing
|
|
580
|
+
|
|
581
|
+
Based on data already collected (trend, GitHub, competition):
|
|
582
|
+
|
|
583
|
+
```
|
|
584
|
+
Market timing: [Too Early / Good Window / Late / Saturated]
|
|
585
|
+
|
|
586
|
+
Signals:
|
|
587
|
+
+ [positive timing signal]
|
|
588
|
+
+ [positive timing signal]
|
|
589
|
+
- [negative timing signal]
|
|
590
|
+
|
|
591
|
+
Window estimate: [closes in X months / open for X years / unclear]
|
|
592
|
+
|
|
593
|
+
Timing verdict:
|
|
594
|
+
[One sentence. Is this the right moment? Why?]
|
|
595
|
+
```
|
|
596
|
+
|
|
597
|
+
Timing patterns to detect:
|
|
598
|
+
|
|
599
|
+
- **Too early:** trend rising but community not formed, infrastructure missing, no paying competitors yet
|
|
600
|
+
- **Good window:** trend rising, 2-5 established players with clear weaknesses, market education done by competitors
|
|
601
|
+
- **Late entry:** dominant player has >50% share and a free tier, market consolidating
|
|
602
|
+
- **Saturated:** 10+ funded competitors, VC money flooding in, CAC rising, differentiation collapsing
|
|
603
|
+
|
|
397
604
|
## Enhancement detection
|
|
398
605
|
|
|
399
606
|
Run at session start to unlock better sources:
|
|
@@ -436,6 +643,8 @@ From `calculate_evidence_score()` in `sources.py`:
|
|
|
436
643
|
- `references/blue-ocean.md` - Value Curve, ERRC Grid, finding uncontested space
|
|
437
644
|
- `references/traction.md` - 19 acquisition channels, Bullseye framework
|
|
438
645
|
- `references/founder-traps.md` - 8 trap patterns with evidence criteria
|
|
646
|
+
- `references/moat-patterns.md` - 5 moat types with scoring criteria 1-10
|
|
647
|
+
- `references/execution-roadmap.md` - 30-day BUILD/VALIDATE/AVOID roadmap framework
|
|
439
648
|
|
|
440
649
|
## Output principles
|
|
441
650
|
|
|
@@ -447,3 +656,6 @@ From `calculate_evidence_score()` in `sources.py`:
|
|
|
447
656
|
6. Check for founder traps before finalizing verdict
|
|
448
657
|
7. Verdict must commit - no "it depends" without specifics and a path forward
|
|
449
658
|
8. Distinguish Opportunity Score from Startup Score
|
|
659
|
+
9. Phase 6 is not optional - the roadmap is what makes the analysis useful
|
|
660
|
+
10. Moat scoring must be honest - score what exists, not what is planned
|
|
661
|
+
11. Tag every factual claim: `[EVIDENCE]` (backed by collected data), `[INFERENCE]` (logical conclusion from data), or `[SPECULATION]` (no direct data, informed guess). Never mix them silently. This applies to the Bull case, Bear case, moat scoring, PMF simulation, and market timing sections.
|
|
@@ -0,0 +1,187 @@
|
|
|
1
|
+
# Execution Roadmap Framework
|
|
2
|
+
|
|
3
|
+
The analysis means nothing if the founder doesn't know what to do on Monday morning.
|
|
4
|
+
|
|
5
|
+
This framework converts a venture-analyst verdict into a concrete 30-day action plan. The output is not generic advice - it is specific actions based on the evidence collected in Phases 1-5.
|
|
6
|
+
|
|
7
|
+
---
|
|
8
|
+
|
|
9
|
+
## The core principle
|
|
10
|
+
|
|
11
|
+
Most validators end with BUILD or AVOID. That is not enough.
|
|
12
|
+
|
|
13
|
+
The right output is:
|
|
14
|
+
- What to do this week (not "validate the idea" - specific tasks)
|
|
15
|
+
- What NOT to build yet (and why)
|
|
16
|
+
- When to stop and reassess (specific trigger conditions)
|
|
17
|
+
|
|
18
|
+
The roadmap changes based on the verdict:
|
|
19
|
+
- **BUILD** → 30-day sprint to first paying customer
|
|
20
|
+
- **VALIDATE FIRST** → 30-day experiment plan
|
|
21
|
+
- **AVOID** → pivot path or stop criteria
|
|
22
|
+
|
|
23
|
+
---
|
|
24
|
+
|
|
25
|
+
## BUILD path - 30-day roadmap
|
|
26
|
+
|
|
27
|
+
The goal is one paying customer in 30 days. Not an MVP. Not a waitlist. One customer who pays.
|
|
28
|
+
|
|
29
|
+
### Week 1 - Find the customer before building
|
|
30
|
+
|
|
31
|
+
Actions:
|
|
32
|
+
1. Identify 50 people who have the problem (from the research: which subreddits, which GitHub repos, which communities had the most signal?)
|
|
33
|
+
2. Reach out to 20 with a Mom Test message - not a pitch, a question about their current workflow
|
|
34
|
+
3. Book 5 discovery calls
|
|
35
|
+
4. Run all 5 calls using Mom Test structure from `references/mom-test.md`
|
|
36
|
+
5. By end of week: can you describe the customer's pain in their exact words?
|
|
37
|
+
|
|
38
|
+
Do NOT build anything this week.
|
|
39
|
+
|
|
40
|
+
Decision gate: if you cannot find 5 people willing to talk, the ICP is wrong. Stop and reassess before continuing.
|
|
41
|
+
|
|
42
|
+
### Week 2 - Build only what closes the first sale
|
|
43
|
+
|
|
44
|
+
Based on the 5 conversations:
|
|
45
|
+
1. Identify the one outcome the customer cares most about
|
|
46
|
+
2. Can you deliver that outcome manually? (Concierge MVP)
|
|
47
|
+
3. If yes: offer to do it for free or at a steep discount for 2-3 people
|
|
48
|
+
4. If the outcome requires software: build only the path from input to that outcome. Nothing else.
|
|
49
|
+
|
|
50
|
+
Scope rule: if it takes more than 5 days to build, you are building too much.
|
|
51
|
+
|
|
52
|
+
Decision gate: if you cannot articulate what the customer is paying for in one sentence, do not build yet.
|
|
53
|
+
|
|
54
|
+
### Week 3 - Deliver and charge
|
|
55
|
+
|
|
56
|
+
1. Deliver the concierge MVP or minimal software to the 2-3 people from Week 2
|
|
57
|
+
2. At delivery: ask "would you pay [price] per month for this if it continued?"
|
|
58
|
+
3. If yes: send them a payment link (Stripe, Gumroad, bank transfer - whatever works)
|
|
59
|
+
4. If no: ask what would have to be different for them to pay
|
|
60
|
+
|
|
61
|
+
First payment is the signal. Not a letter of intent. Not "I would pay". An actual transaction.
|
|
62
|
+
|
|
63
|
+
Decision gate: if nobody pays after Week 3, you have a problem with price, value, or ICP. Identify which one before continuing.
|
|
64
|
+
|
|
65
|
+
### Week 4 - Stabilize and find customer 2-3
|
|
66
|
+
|
|
67
|
+
1. Deliver reliably to paying customer 1
|
|
68
|
+
2. Ask for referral: "who else do you know with this problem?"
|
|
69
|
+
3. Run outreach to 10 more people from the original 50 list
|
|
70
|
+
4. Goal: 2-3 paying customers by end of month
|
|
71
|
+
|
|
72
|
+
---
|
|
73
|
+
|
|
74
|
+
## VALIDATE FIRST path - 30-day experiment plan
|
|
75
|
+
|
|
76
|
+
The goal is to answer the one critical unknown identified in Phase 5.
|
|
77
|
+
|
|
78
|
+
### Week 1 - Define the question precisely
|
|
79
|
+
|
|
80
|
+
Write this sentence: "We do not know if [specific assumption]. If we knew [assumption] is true, we would build. If false, we would not build."
|
|
81
|
+
|
|
82
|
+
Examples:
|
|
83
|
+
- "We do not know if freelancers will pay for automated invoicing when free tools exist."
|
|
84
|
+
- "We do not know if HR teams have budget for this outside their annual planning cycle."
|
|
85
|
+
|
|
86
|
+
Everything in the next 3 weeks answers this one question.
|
|
87
|
+
|
|
88
|
+
### Week 2 - Run the cheapest test that could falsify it
|
|
89
|
+
|
|
90
|
+
Based on the assumption type:
|
|
91
|
+
|
|
92
|
+
| Assumption type | Best test | Cost | Time |
|
|
93
|
+
|----------------|-----------|------|------|
|
|
94
|
+
| Does the problem exist? | 10 Mom Test interviews | 0 | 1 week |
|
|
95
|
+
| Will they pay? | Concierge MVP with payment ask | 0 | 2 weeks |
|
|
96
|
+
| Does the message resonate? | Fake door landing page | 0-30€ | 1 week |
|
|
97
|
+
| Is the ICP right? | Cold outreach to 3 different segments | 0 | 1 week |
|
|
98
|
+
|
|
99
|
+
Do not run more than one test at a time. You need clean signal.
|
|
100
|
+
|
|
101
|
+
### Week 3 - Collect and evaluate data
|
|
102
|
+
|
|
103
|
+
By end of week 3 you need a number against a threshold:
|
|
104
|
+
- Interviews: at least 7 out of 10 describe the same problem unprompted
|
|
105
|
+
- Payment ask: at least 2 out of 5 say yes and follow through
|
|
106
|
+
- Fake door: CTR above 5% from cold traffic
|
|
107
|
+
- ICP test: one segment responds 3x better than others
|
|
108
|
+
|
|
109
|
+
### Week 4 - Decision
|
|
110
|
+
|
|
111
|
+
Three possible outcomes:
|
|
112
|
+
|
|
113
|
+
**Assumption confirmed:** move to BUILD path. Start Week 1 of the BUILD roadmap.
|
|
114
|
+
|
|
115
|
+
**Assumption partially confirmed:** the test worked but raised a new question. Run a second 2-week experiment targeting the new unknown.
|
|
116
|
+
|
|
117
|
+
**Assumption falsified:** the critical assumption is wrong. Before stopping:
|
|
118
|
+
- Is there a pivot? (different customer, different problem, different solution)
|
|
119
|
+
- If yes: restart from Phase 1 with the new hypothesis
|
|
120
|
+
- If no: stop. Time is the most valuable resource.
|
|
121
|
+
|
|
122
|
+
---
|
|
123
|
+
|
|
124
|
+
## AVOID path - what to do instead
|
|
125
|
+
|
|
126
|
+
If the verdict is AVOID, the roadmap is not "do nothing." It is:
|
|
127
|
+
|
|
128
|
+
### Option A - Pivot investigation (2 weeks)
|
|
129
|
+
|
|
130
|
+
The research surfaced something. What was the most interesting unexpected signal?
|
|
131
|
+
- A different customer segment with stronger pain
|
|
132
|
+
- A related problem that nobody is solving
|
|
133
|
+
- A gap in the competitor landscape that the original idea missed
|
|
134
|
+
|
|
135
|
+
Spend 2 weeks doing Phase 1 research on the pivot hypothesis before committing.
|
|
136
|
+
|
|
137
|
+
### Option B - Clean stop criteria
|
|
138
|
+
|
|
139
|
+
If no pivot is visible, document:
|
|
140
|
+
- What was learned (specific, honest)
|
|
141
|
+
- What would have to change in the market for this to be worth revisiting
|
|
142
|
+
- Time horizon: reassess in [6/12/24] months if [specific trigger] occurs
|
|
143
|
+
|
|
144
|
+
This is not failure. It is validated learning. The next idea starts from a better place.
|
|
145
|
+
|
|
146
|
+
---
|
|
147
|
+
|
|
148
|
+
## Roadmap anti-patterns
|
|
149
|
+
|
|
150
|
+
**Anti-pattern 1: Building before selling**
|
|
151
|
+
The roadmap assumes zero code until someone has committed to paying. Build only what closes the next sale.
|
|
152
|
+
|
|
153
|
+
**Anti-pattern 2: Optimizing before validating**
|
|
154
|
+
Do not improve the landing page conversion rate before you have 100 cold visitors. Do not A/B test before you have a working baseline.
|
|
155
|
+
|
|
156
|
+
**Anti-pattern 3: Scaling before repeating**
|
|
157
|
+
Do not invest in marketing before you have 3 customers who came through the same process. One customer is an anecdote. Three is a pattern.
|
|
158
|
+
|
|
159
|
+
**Anti-pattern 4: Measuring vanity metrics**
|
|
160
|
+
The only metric that matters in week 1-4 is: did someone pay? Every other metric is a proxy.
|
|
161
|
+
|
|
162
|
+
**Anti-pattern 5: Moving the goalposts**
|
|
163
|
+
Define success criteria before starting each week. Do not redefine "success" after seeing results.
|
|
164
|
+
|
|
165
|
+
---
|
|
166
|
+
|
|
167
|
+
## Output format for roadmap
|
|
168
|
+
|
|
169
|
+
```
|
|
170
|
+
## 30-Day Execution Roadmap
|
|
171
|
+
|
|
172
|
+
Path: [BUILD / VALIDATE FIRST / AVOID]
|
|
173
|
+
|
|
174
|
+
Critical constraint: [the one thing that must be true for this plan to work]
|
|
175
|
+
|
|
176
|
+
Week 1: [specific tasks + decision gate]
|
|
177
|
+
Week 2: [specific tasks + decision gate]
|
|
178
|
+
Week 3: [specific tasks + decision gate]
|
|
179
|
+
Week 4: [goal + decision]
|
|
180
|
+
|
|
181
|
+
Do NOT build yet:
|
|
182
|
+
- [specific feature or system to avoid]
|
|
183
|
+
- [reason]
|
|
184
|
+
|
|
185
|
+
Reassess if:
|
|
186
|
+
- [specific trigger that means the plan is failing]
|
|
187
|
+
```
|
|
@@ -0,0 +1,176 @@
|
|
|
1
|
+
# Moat Patterns
|
|
2
|
+
|
|
3
|
+
A moat is why you keep customers after a competitor copies your features. Without a moat, you build a product, not a business.
|
|
4
|
+
|
|
5
|
+
Most startup validators say "competitive advantage" and leave it there. This reference gives scoring criteria for 5 real moat types so the analysis can score each one and identify which is most realistic for a given idea.
|
|
6
|
+
|
|
7
|
+
---
|
|
8
|
+
|
|
9
|
+
## The 5 moat types
|
|
10
|
+
|
|
11
|
+
### 1. Distribution Moat
|
|
12
|
+
|
|
13
|
+
You control a channel others cannot easily access.
|
|
14
|
+
|
|
15
|
+
**What it looks like:**
|
|
16
|
+
- Exclusive partnership with a platform (e.g. pre-installed on hardware)
|
|
17
|
+
- Large owned audience (email list, YouTube, community)
|
|
18
|
+
- SEO dominance in a niche that takes years to replicate
|
|
19
|
+
- Embedded in a workflow that creates daily habit (Slack, Notion)
|
|
20
|
+
|
|
21
|
+
**Evidence signals (score higher for each present):**
|
|
22
|
+
- Founder already has relevant audience or network
|
|
23
|
+
- Product embeds into existing workflow daily
|
|
24
|
+
- Partnership or distribution deal possible that others can't easily get
|
|
25
|
+
- SEO moat: high-intent keywords with low competition
|
|
26
|
+
|
|
27
|
+
**Score 1-10:**
|
|
28
|
+
- 1-3: No distribution advantage, same channels as competitors
|
|
29
|
+
- 4-6: Some channel advantage but replicable with money
|
|
30
|
+
- 7-10: Structural distribution advantage that compounds over time
|
|
31
|
+
|
|
32
|
+
**Most realistic for:** content businesses, platforms with network effects, tools that embed into a daily workflow
|
|
33
|
+
|
|
34
|
+
---
|
|
35
|
+
|
|
36
|
+
### 2. Data Moat
|
|
37
|
+
|
|
38
|
+
You accumulate proprietary data that makes your product better over time and is impossible to replicate from scratch.
|
|
39
|
+
|
|
40
|
+
**What it looks like:**
|
|
41
|
+
- Each user interaction improves the model/output for all users
|
|
42
|
+
- Unique dataset nobody else has (e.g. proprietary industry data)
|
|
43
|
+
- Network of data contributors locked in by switching cost
|
|
44
|
+
- Longitudinal data that takes years to accumulate
|
|
45
|
+
|
|
46
|
+
**Evidence signals:**
|
|
47
|
+
- Product gets meaningfully better with more users or usage
|
|
48
|
+
- Data collected is not available from public sources
|
|
49
|
+
- Users contribute data as part of normal use (not just consume)
|
|
50
|
+
- The gap between early data and mature data is the moat
|
|
51
|
+
|
|
52
|
+
**Score 1-10:**
|
|
53
|
+
- 1-3: Uses same public data sources as everyone else
|
|
54
|
+
- 4-6: Collects user data but competitors could replicate with time
|
|
55
|
+
- 7-10: Proprietary data flywheel that widens with scale
|
|
56
|
+
|
|
57
|
+
**Most realistic for:** AI products, marketplaces, analytics platforms, any product where N+1 users make the product better for all N users
|
|
58
|
+
|
|
59
|
+
---
|
|
60
|
+
|
|
61
|
+
### 3. Community Moat
|
|
62
|
+
|
|
63
|
+
Users identify with the product and each other. Leaving means leaving the community.
|
|
64
|
+
|
|
65
|
+
**What it looks like:**
|
|
66
|
+
- Strong brand identity (users say "I'm a [product] user" as part of identity)
|
|
67
|
+
- Active user community that is product-adjacent (Slack, Discord, events)
|
|
68
|
+
- User-generated content that attracts more users
|
|
69
|
+
- Power users who become advocates and contributors
|
|
70
|
+
|
|
71
|
+
**Evidence signals:**
|
|
72
|
+
- Reddit or HN discussions about the product are enthusiastic, not just transactional
|
|
73
|
+
- Users refer others without being asked
|
|
74
|
+
- Community exists or could exist around the problem space
|
|
75
|
+
- Identity signal: does the target customer identify strongly with a community?
|
|
76
|
+
|
|
77
|
+
**Score 1-10:**
|
|
78
|
+
- 1-3: No community signal, purely transactional product
|
|
79
|
+
- 4-6: Some user loyalty but no real community
|
|
80
|
+
- 7-10: Product is central to a user identity or community
|
|
81
|
+
|
|
82
|
+
**Most realistic for:** developer tools, creator tools, niche B2B, products solving problems with strong in-group identity
|
|
83
|
+
|
|
84
|
+
---
|
|
85
|
+
|
|
86
|
+
### 4. Switching Cost Moat
|
|
87
|
+
|
|
88
|
+
Leaving is painful because of data, integrations, learned behavior, or sunk cost.
|
|
89
|
+
|
|
90
|
+
**What it looks like:**
|
|
91
|
+
- Data locked in proprietary format
|
|
92
|
+
- Deep integration into other tools (replacing means replacing the whole stack)
|
|
93
|
+
- Trained behavior - users have built muscle memory around the product
|
|
94
|
+
- Team adoption - everyone on the team uses it, coordination cost to switch
|
|
95
|
+
|
|
96
|
+
**Evidence signals:**
|
|
97
|
+
- Product stores user data that is hard to export
|
|
98
|
+
- Integration depth: does it connect to 5+ other tools in the workflow?
|
|
99
|
+
- Time-to-value is long (users invest time before they get value)
|
|
100
|
+
- Team product vs individual product (team switching cost >> individual switching cost)
|
|
101
|
+
|
|
102
|
+
**Score 1-10:**
|
|
103
|
+
- 1-3: Easy to replace, data fully portable, no integrations
|
|
104
|
+
- 4-6: Some friction to switch but not prohibitive
|
|
105
|
+
- 7-10: Switching requires significant time, data migration, or retraining
|
|
106
|
+
|
|
107
|
+
**Most realistic for:** B2B SaaS, CRMs, project management, any product that stores meaningful user data or integrates deeply
|
|
108
|
+
|
|
109
|
+
---
|
|
110
|
+
|
|
111
|
+
### 5. Execution Moat
|
|
112
|
+
|
|
113
|
+
The team can build and ship faster or better than others. Not a durable moat alone, but can be decisive in a fast-moving market.
|
|
114
|
+
|
|
115
|
+
**What it looks like:**
|
|
116
|
+
- Unique domain expertise that takes years to acquire
|
|
117
|
+
- Technical complexity that requires rare skills
|
|
118
|
+
- Speed advantage from existing infrastructure or team
|
|
119
|
+
- Regulatory or compliance knowledge that creates a barrier
|
|
120
|
+
|
|
121
|
+
**Evidence signals:**
|
|
122
|
+
- Founder has 5+ years of domain expertise
|
|
123
|
+
- Technical stack requires rare specialization
|
|
124
|
+
- Regulatory approval process exists (creates time barrier for followers)
|
|
125
|
+
- Existing codebase or infrastructure gives head start
|
|
126
|
+
|
|
127
|
+
**Score 1-10:**
|
|
128
|
+
- 1-3: Anyone with enough money can hire the team to replicate this
|
|
129
|
+
- 4-6: Some execution advantage but not structural
|
|
130
|
+
- 7-10: Rare expertise or regulatory barrier that cannot be bought quickly
|
|
131
|
+
|
|
132
|
+
**Most realistic for:** deep tech, regulated industries, products where domain expertise is genuinely scarce
|
|
133
|
+
|
|
134
|
+
---
|
|
135
|
+
|
|
136
|
+
## Moat Scoring Guide
|
|
137
|
+
|
|
138
|
+
Score each moat 1-10 using the criteria above. Then:
|
|
139
|
+
|
|
140
|
+
**Moat Score = weighted average:**
|
|
141
|
+
- Take the top 2 moat scores
|
|
142
|
+
- The highest becomes the primary moat
|
|
143
|
+
- The second becomes the secondary moat
|
|
144
|
+
- Overall Moat Score = (primary * 0.6) + (secondary * 0.4)
|
|
145
|
+
|
|
146
|
+
**Interpretation:**
|
|
147
|
+
| Score | Meaning |
|
|
148
|
+
|-------|---------|
|
|
149
|
+
| 1-3 | No real moat. Features will be copied. Compete on speed only. |
|
|
150
|
+
| 4-5 | Weak moat. Some defensibility but competitors can close the gap. |
|
|
151
|
+
| 6-7 | Moderate moat. Viable business, but needs to strengthen before scaling. |
|
|
152
|
+
| 8-10 | Strong moat. Structural advantage that compounds with growth. |
|
|
153
|
+
|
|
154
|
+
**Critical output:**
|
|
155
|
+
After scoring, answer: "What is the most realistic moat for this idea, and what specific actions build it?"
|
|
156
|
+
|
|
157
|
+
Do not just name the moat. Give the action. Example:
|
|
158
|
+
- Data moat: "Every analysis run should store anonymized patterns. At 1,000 analyses, the pattern database becomes a proprietary asset."
|
|
159
|
+
- Community moat: "Build in public. Ship a free tool that attracts the exact ICP and turns them into advocates before monetizing."
|
|
160
|
+
- Distribution moat: "Identify the one community where the ICP concentrates and become the go-to contributor before launching."
|
|
161
|
+
|
|
162
|
+
---
|
|
163
|
+
|
|
164
|
+
## Common moat mistakes
|
|
165
|
+
|
|
166
|
+
**Mistake 1: Confusing features with moats**
|
|
167
|
+
"We have AI" is not a moat. Every competitor will have AI. The question is what the AI produces that is unique and hard to replicate.
|
|
168
|
+
|
|
169
|
+
**Mistake 2: Assuming complexity = moat**
|
|
170
|
+
Hard to build does not mean hard to copy. Once you show it works, a well-funded competitor can hire the engineers.
|
|
171
|
+
|
|
172
|
+
**Mistake 3: Planning a moat that requires scale you don't have yet**
|
|
173
|
+
Data moats require data. Network effects require network. These are goals, not current advantages. Score them based on realistic trajectory, not end state.
|
|
174
|
+
|
|
175
|
+
**Mistake 4: Relying on execution moat alone**
|
|
176
|
+
Speed is not a business. It buys time to build a real moat. Always pair execution moat with a second structural moat.
|
|
@@ -199,6 +199,117 @@ Alternative path: [reduced scope or different entry point]
|
|
|
199
199
|
**What would accelerate this:** [factor]
|
|
200
200
|
**What would delay this:** [risk]
|
|
201
201
|
|
|
202
|
+
### Assumption Map
|
|
203
|
+
|
|
204
|
+
```
|
|
205
|
+
A1 (most dangerous): [core belief about problem/customer]
|
|
206
|
+
Confidence: [0-100]
|
|
207
|
+
Based on: [evidence or lack of it]
|
|
208
|
+
Validates if: [observable outcome]
|
|
209
|
+
Kills startup if: [falsified by X]
|
|
210
|
+
|
|
211
|
+
A2: [monetization or switching assumption]
|
|
212
|
+
Confidence: [0-100]
|
|
213
|
+
Based on: [evidence or lack of it]
|
|
214
|
+
Validates if: [observable outcome]
|
|
215
|
+
Kills startup if: [falsified by X]
|
|
216
|
+
|
|
217
|
+
A3: [distribution or growth assumption]
|
|
218
|
+
Confidence: [0-100]
|
|
219
|
+
Based on: [evidence or lack of it]
|
|
220
|
+
Validates if: [observable outcome]
|
|
221
|
+
Kills startup if: [falsified by X]
|
|
222
|
+
```
|
|
223
|
+
|
|
224
|
+
**Know:** [what the evidence clearly supports]
|
|
225
|
+
**Believe:** [what is inferred but not proven]
|
|
226
|
+
**Imagining:** [what has no data behind it]
|
|
227
|
+
|
|
228
|
+
---
|
|
229
|
+
|
|
230
|
+
## Phase 6 - Execution & Moat
|
|
231
|
+
|
|
232
|
+
### Moat Intelligence
|
|
233
|
+
|
|
234
|
+
| Moat type | Score (1-10) | Reason |
|
|
235
|
+
|-----------|-------------|--------|
|
|
236
|
+
| Distribution | [n] | [one line] |
|
|
237
|
+
| Data | [n] | [one line] |
|
|
238
|
+
| Community | [n] | [one line] |
|
|
239
|
+
| Switching cost | [n] | [one line] |
|
|
240
|
+
| Execution | [n] | [one line] |
|
|
241
|
+
|
|
242
|
+
**Overall Moat Score:** [weighted avg of top 2]
|
|
243
|
+
**Most realistic moat:** [type]
|
|
244
|
+
**How to build it:** [specific action, not generic advice]
|
|
245
|
+
|
|
246
|
+
### PMF Simulation
|
|
247
|
+
|
|
248
|
+
**Persona A:** [job title / situation]
|
|
249
|
+
- Current workflow: [specific]
|
|
250
|
+
- Main pain: [from research quotes]
|
|
251
|
+
- Adoption trigger: [what makes them switch]
|
|
252
|
+
- Adoption blocker: [what stops them]
|
|
253
|
+
- Simulated arc: discovers (Week 1) -> [Week 2] -> [Week 3: converts/churns] -> [Week 4]
|
|
254
|
+
|
|
255
|
+
**Persona B:** [job title / situation]
|
|
256
|
+
- [same structure]
|
|
257
|
+
|
|
258
|
+
**Persona C:** [job title / situation]
|
|
259
|
+
- [same structure]
|
|
260
|
+
|
|
261
|
+
**PMF friction report:**
|
|
262
|
+
- Main blockers: [list, note how many personas affected]
|
|
263
|
+
- Easiest persona to convert first: [A/B/C] - because [reason]
|
|
264
|
+
|
|
265
|
+
### Market Timing
|
|
266
|
+
|
|
267
|
+
```
|
|
268
|
+
Timing: [Too Early / Good Window / Late / Saturated]
|
|
269
|
+
|
|
270
|
+
Signals:
|
|
271
|
+
+ [positive]
|
|
272
|
+
- [negative]
|
|
273
|
+
|
|
274
|
+
Window: [closes in X months / open for X years / unclear]
|
|
275
|
+
Verdict: [one sentence]
|
|
276
|
+
```
|
|
277
|
+
|
|
278
|
+
### Execution Roadmap
|
|
279
|
+
|
|
280
|
+
**Path:** [BUILD / VALIDATE FIRST / AVOID]
|
|
281
|
+
**Critical constraint:** [the one thing that must be true]
|
|
282
|
+
|
|
283
|
+
| Week | Actions | Decision gate |
|
|
284
|
+
|------|---------|--------------|
|
|
285
|
+
| 1 | [specific tasks] | [pass/fail condition] |
|
|
286
|
+
| 2 | [specific tasks] | [pass/fail condition] |
|
|
287
|
+
| 3 | [specific tasks] | [pass/fail condition] |
|
|
288
|
+
| 4 | [goal] | [commit or reassess] |
|
|
289
|
+
|
|
290
|
+
**Do NOT build yet:**
|
|
291
|
+
- [feature/system] - [reason]
|
|
292
|
+
|
|
293
|
+
**Reassess if:** [specific trigger condition]
|
|
294
|
+
|
|
295
|
+
### Kill Criteria
|
|
296
|
+
|
|
297
|
+
```
|
|
298
|
+
If after [n] days from starting:
|
|
299
|
+
|
|
300
|
+
< [n] real customer interviews completed
|
|
301
|
+
< [n] people willing to schedule a call
|
|
302
|
+
Zero payment intent (pre-order, deposit, or signed LOI)
|
|
303
|
+
[idea-specific negative signal]
|
|
304
|
+
|
|
305
|
+
-> Stop. Do not pivot yet.
|
|
306
|
+
First answer: was the problem real or did we imagine it?
|
|
307
|
+
|
|
308
|
+
Pivot trigger (instead of stop):
|
|
309
|
+
If problem is validated but [specific step] fails
|
|
310
|
+
-> [specific narrower pivot]
|
|
311
|
+
```
|
|
312
|
+
|
|
202
313
|
---
|
|
203
314
|
|
|
204
315
|
## Next Steps
|
|
@@ -238,3 +349,24 @@ If not: [specific pivot or kill condition].
|
|
|
238
349
|
|
|
239
350
|
**Adjacent opportunity (if found):**
|
|
240
351
|
[Related problem the research surfaced that IS worth pursuing.]
|
|
352
|
+
|
|
353
|
+
### Pivot Engine
|
|
354
|
+
|
|
355
|
+
[If no evidence-backed pivot exists: "No evidence-backed pivot found. Consider a different problem space entirely."]
|
|
356
|
+
|
|
357
|
+
[If pivots found:]
|
|
358
|
+
```
|
|
359
|
+
Pivot Option 1: [segment / problem / channel / scope]
|
|
360
|
+
From: [current idea]
|
|
361
|
+
To: [specific pivot]
|
|
362
|
+
Evidence: [signal from research that supports this]
|
|
363
|
+
Risk: [what could still be wrong]
|
|
364
|
+
|
|
365
|
+
Pivot Option 2: [segment / problem / channel / scope]
|
|
366
|
+
From: [current idea]
|
|
367
|
+
To: [specific pivot]
|
|
368
|
+
Evidence: [signal from research that supports this]
|
|
369
|
+
Risk: [what could still be wrong]
|
|
370
|
+
|
|
371
|
+
Recommended: Option [1/2] - [one sentence reason]
|
|
372
|
+
```
|