Prototyping & Pretotyping
Table of Contents
- Workflow
- Common Patterns
- Fidelity Ladder
- Guardrails
- Quick Reference
Workflow
Copy this checklist and track your progress:
Prototyping Progress:
- [ ] Step 1: Identify riskiest assumption to test
- [ ] Step 2: Choose pretotype/prototype approach
- [ ] Step 3: Design and build minimum test
- [ ] Step 4: Run experiment and collect data
- [ ] Step 5: Analyze results and decide (pivot/persevere/iterate)
Step 1: Identify riskiest assumption
List all assumptions (demand, pricing, feasibility, workflow), rank by risk (probability of being wrong × impact if wrong). Test highest-risk assumption first. See Common Patterns for typical assumptions by domain.
Step 2: Choose approach
Match test method to assumption and available time/budget. See Fidelity Ladder for choosing appropriate fidelity. Use resources/template.md for experiment design.
Step 3: Design and build minimum test
Create simplest artifact that tests assumption (landing page, paper prototype, manual service delivery). See resources/methodology.md for specific techniques (fake door, concierge, Wizard of Oz, paper prototyping).
Step 4: Run experiment
Deploy test, recruit participants, collect quantitative data (sign-ups, clicks, payments) and qualitative feedback (interviews, observations). Aim for minimum viable data (n=5-10 for qualitative, n=100+ for quantitative confidence).
Step 5: Analyze and decide
Compare results to success criteria (e.g., "10% conversion validates demand"). Decide: Pivot (assumption wrong, change direction), Persevere (assumption validated, build it), or Iterate (mixed results, refine and re-test).
Common Patterns
By assumption type:
Demand Assumption ("People want this"):
- Test: Fake door (landing page with "Buy Now" → "Coming Soon"), pre-orders, waitlist sign-ups
- Success criteria: X% conversion, Y sign-ups in Z days
- Example: "10% of visitors sign up for waitlist in 2 weeks" → validates demand
Pricing Assumption ("People will pay $X"):
- Test: Price on landing page, offer with multiple price tiers, A/B test prices
- Success criteria: Z% conversion at target price
- Example: "5% convert at $49/mo" → validates pricing
Workflow Assumption ("This solves user problem in intuitive way"):
- Test: Paper prototype, task completion with clickable prototype
- Success criteria: X% complete task without help, <Y errors
- Example: "8/10 users complete checkout in <2 minutes with 0 errors" → validates workflow
Feasibility Assumption ("We can build/scale this"):
- Test: Technical spike, proof-of-concept with real data, manual concierge first
- Success criteria: Performance meets targets, costs within budget
- Example: "API responds in <500ms at 100 req/sec" → validates architecture
Value Proposition Assumption ("Customers prefer our approach over alternatives"):
- Test: A/B test messaging, fake door with different value props, competitor comparison
- Success criteria: X% choose our approach over alternative
- Example: "60% choose AI-powered vs manual curation" → validates differentiation
Fidelity Ladder
Choose appropriate fidelity for your question:
Level 0 - Pretotype (Hours to Days, $0-100):
- What: Fake it before building anything real
- When: Test demand, pricing, value prop assumptions
- Methods: Landing page with sign-up, fake door test, manual concierge, video mockup
- Example: Dropbox video showing product before building it (3-4 min video, 70K→75K sign-ups overnight)
- Pros: Fastest, cheapest, tests real behavior (not opinions)
- Cons: Can't test workflow/usability in detail, ethical concerns if too deceptive
Level 1 - Paper Prototype (Hours to Days, $0-50):
- What: Hand-drawn sketches, printed screens, index cards
- When: Test workflow, information architecture, screen structure
- Methods: Users "click" on paper, you swap screens, observe confusion points
- Example: Banking app - 10 paper screens, users simulate depositing check, identify 3 workflow issues
- Pros: Very fast to iterate (redraw in minutes), forces focus on structure not polish
- Cons: Can't test real interactions (gestures, animations), feels "fake" to users
Level 2 - Clickable Prototype (Days to Week, $100-500):
- What: Interactive mockups in Figma, InVision, Adobe XD (no real code)
- When: Test user flow, UI patterns, interaction design
- Methods: Users complete tasks, measure success rate/time/errors, collect feedback
- Example: E-commerce checkout - 8 screens, 20 users, 15% abandon at shipping → fix before coding
- Pros: Looks real, easy to change, tests realistic interactions
- Cons: Can't test performance, scalability, backend complexity
Level 3 - Coded Prototype (Weeks to Month, $1K-10K):
- What: Working software with limited features, subset of data, shortcuts
- When: Test technical feasibility, performance, integration complexity
- Methods: Real users with real tasks, measure latency/errors, validate architecture
- Example: Search engine - 10K documents (not 10M), 50 users, <1s response time → validates approach
- Pros: Tests real technical constraints, reveals integration issues
- Cons: More expensive/time-consuming, harder to throw away if wrong
Level 4 - Minimum Viable Product (Months, $10K-100K+):
- What: Simplest version that delivers core value to real customers
- When: Assumptions mostly validated, ready for market feedback
- Methods: Launch to small segment, measure retention/revenue, iterate based on data
- Example: Instagram v1 - photo filters only (no video, stories, reels), launched to small group
- Pros: Real market validation, revenue, learning
- Cons: Expensive, longer timeline, public commitment
Guardrails
Ensure quality:
Test riskiest assumption first: Don't test what you're confident about
- ✓ "Will customers pay $X?" (high uncertainty) before "Can we make button blue?" (trivial)
- ❌ Testing minor details before validating core value
Match fidelity to question: Don't overbuild for question at hand
- ✓ Paper prototype for testing workflow (hours), coded prototype for testing latency (weeks)
- ❌ Building coded prototype to test if users like color scheme (overkill)
Set success criteria before testing: Avoid confirmation bias
- ✓ "10% conversion validates demand" (decided before test)
- ❌ "7% conversion? That's pretty good!" (moving goalposts after test)
Test with real target users: Friends/family are not representative
- ✓ Recruit from target segment (e.g., enterprise IT buyers for B2B SaaS)
- ❌ Test with whoever is available (founder's friends who are polite)
Observe behavior, not opinions: What people do > what they say
- ✓ "50% clicked 'Buy Now' but 0% completed payment" (real behavior → pricing/friction issue)
- ❌ "Users said they'd pay $99/mo" (opinion, not reliable predictor)
Be transparent about faking it: Ethical pretotyping
- ✓ "Sign up for early access" or "Launching soon" (honest)
- ❌ Charging credit cards for fake product, promising features you won't build (fraud)
Throw away prototypes: Don't turn prototype code into production
- ✓ Rebuild with proper architecture after validation
- ❌ Ship prototype code (technical debt, security issues, scalability problems)
Iterate quickly: Multiple cheap tests > one expensive test
- ✓ 5 paper prototypes in 1 week (test 5 approaches)
- ❌ 1 coded prototype in 1 month (locked into one approach)
Quick Reference
Resources:
- Quick start: resources/template.md - Pretotype/prototype experiment template
- Advanced techniques: resources/methodology.md - Fake door, concierge, Wizard of Oz, paper prototyping, A/B testing
- Quality check: resources/evaluators/rubric_prototyping_pretotyping.json - Evaluation criteria
Success criteria:
- ✓ Identified 3-5 riskiest assumptions ranked by risk (prob wrong × impact if wrong)
- ✓ Tested highest-risk assumption with minimum fidelity needed
- ✓ Set quantitative success criteria before testing (e.g., "10% conversion")
- ✓ Recruited real target users (n=5-10 qualitative, n=100+ quantitative)
- ✓ Collected behavior data (clicks, conversions, task completion), not just opinions
- ✓ Results clear enough to make pivot/persevere/iterate decision
- ✓ Documented learning and shared with team
Common mistakes:
- ❌ Testing trivial assumptions before risky ones
- ❌ Overbuilding (coded prototype when landing page would suffice)
- ❌ No success criteria (moving goalposts after test)
- ❌ Testing with wrong users (friends/family, not target segment)
- ❌ Relying on opinions ("users said they liked it") not behavior
- ❌ Analysis paralysis (perfect prototype before testing)
- ❌ Shipping prototype code (technical debt disaster)
- ❌ Testing one thing when could test many (cheap tests run serially/parallel)
When to use alternatives:
- A/B testing: When have existing product/traffic, want to compare variations
- Surveys: When need quantitative opinions at scale (but remember: opinions ≠ behavior)
- Customer interviews: When understanding problem/context, not testing solution
- Beta testing: When product mostly built, need feedback on polish/bugs
- Smoke test: Same as pretotype (measure interest before building)
1---2name: prototyping-pretotyping3description: Guides validation of ideas before full development using pretotyping (fake doors, concierge MVPs, Wizard of Oz) and prototyping at appropriate fidelity (paper, clickable, coded) to test assumptions about demand, pricing, and feasibility. Use when testing ideas cheaply before building, choosing prototype fidelity, running experiments to validate assumptions, or when user mentions prototype, MVP, fake door test, concierge, Wizard of Oz, landing page test, smoke test, or asks "how can we validate this idea before building?".4---5# Prototyping & Pretotyping
6
7## Table of Contents
81. [Workflow](#workflow)
92. [Common Patterns](#common-patterns)
103. [Fidelity Ladder](#fidelity-ladder)
114. [Guardrails](#guardrails)
125. [Quick Reference](#quick-reference)
13
14## Workflow
15
16Copy this checklist and track your progress:
17
18```
19Prototyping Progress:
20- [ ] Step 1: Identify riskiest assumption to test
21- [ ] Step 2: Choose pretotype/prototype approach
22- [ ] Step 3: Design and build minimum test
23- [ ] Step 4: Run experiment and collect data
24- [ ] Step 5: Analyze results and decide (pivot/persevere/iterate)
25```
26
27**Step 1: Identify riskiest assumption**
28
29List all assumptions (demand, pricing, feasibility, workflow), rank by risk (probability of being wrong × impact if wrong). Test highest-risk assumption first. See [Common Patterns](#common-patterns) for typical assumptions by domain.
30
31**Step 2: Choose approach**
32
33Match test method to assumption and available time/budget. See [Fidelity Ladder](#fidelity-ladder) for choosing appropriate fidelity. Use [resources/template.md](resources/template.md) for experiment design.
34
35**Step 3: Design and build minimum test**
36
37Create simplest artifact that tests assumption (landing page, paper prototype, manual service delivery). See [resources/methodology.md](resources/methodology.md) for specific techniques (fake door, concierge, Wizard of Oz, paper prototyping).
38
39**Step 4: Run experiment**
40
41Deploy test, recruit participants, collect quantitative data (sign-ups, clicks, payments) and qualitative feedback (interviews, observations). Aim for minimum viable data (n=5-10 for qualitative, n=100+ for quantitative confidence).
42
43**Step 5: Analyze and decide**
44
45Compare results to success criteria (e.g., "10% conversion validates demand"). Decide: Pivot (assumption wrong, change direction), Persevere (assumption validated, build it), or Iterate (mixed results, refine and re-test).
46
47## Common Patterns
48
49**By assumption type:**
50
51**Demand Assumption** ("People want this"):
52- Test: Fake door (landing page with "Buy Now" → "Coming Soon"), pre-orders, waitlist sign-ups
53- Success criteria: X% conversion, Y sign-ups in Z days
54- Example: "10% of visitors sign up for waitlist in 2 weeks" → validates demand
55
56**Pricing Assumption** ("People will pay $X"):
57- Test: Price on landing page, offer with multiple price tiers, A/B test prices
58- Success criteria: Z% conversion at target price
59- Example: "5% convert at $49/mo" → validates pricing
60
61**Workflow Assumption** ("This solves user problem in intuitive way"):
62- Test: Paper prototype, task completion with clickable prototype
63- Success criteria: X% complete task without help, <Y errors
64- Example: "8/10 users complete checkout in <2 minutes with 0 errors" → validates workflow
65
66**Feasibility Assumption** ("We can build/scale this"):
67- Test: Technical spike, proof-of-concept with real data, manual concierge first
68- Success criteria: Performance meets targets, costs within budget
69- Example: "API responds in <500ms at 100 req/sec" → validates architecture
70
71**Value Proposition Assumption** ("Customers prefer our approach over alternatives"):
72- Test: A/B test messaging, fake door with different value props, competitor comparison
73- Success criteria: X% choose our approach over alternative
74- Example: "60% choose AI-powered vs manual curation" → validates differentiation
75
76## Fidelity Ladder
77
78**Choose appropriate fidelity for your question:**
79
80**Level 0 - Pretotype (Hours to Days, $0-100):**
81- **What**: Fake it before building anything real
82- **When**: Test demand, pricing, value prop assumptions
83- **Methods**: Landing page with sign-up, fake door test, manual concierge, video mockup
84- **Example**: Dropbox video showing product before building it (3-4 min video, 70K→75K sign-ups overnight)
85- **Pros**: Fastest, cheapest, tests real behavior (not opinions)
86- **Cons**: Can't test workflow/usability in detail, ethical concerns if too deceptive
87
88**Level 1 - Paper Prototype (Hours to Days, $0-50):**
89- **What**: Hand-drawn sketches, printed screens, index cards
90- **When**: Test workflow, information architecture, screen structure
91- **Methods**: Users "click" on paper, you swap screens, observe confusion points
92- **Example**: Banking app - 10 paper screens, users simulate depositing check, identify 3 workflow issues
93- **Pros**: Very fast to iterate (redraw in minutes), forces focus on structure not polish
94- **Cons**: Can't test real interactions (gestures, animations), feels "fake" to users
95
96**Level 2 - Clickable Prototype (Days to Week, $100-500):**
97- **What**: Interactive mockups in Figma, InVision, Adobe XD (no real code)
98- **When**: Test user flow, UI patterns, interaction design
99- **Methods**: Users complete tasks, measure success rate/time/errors, collect feedback
100- **Example**: E-commerce checkout - 8 screens, 20 users, 15% abandon at shipping → fix before coding
101- **Pros**: Looks real, easy to change, tests realistic interactions
102- **Cons**: Can't test performance, scalability, backend complexity
103
104**Level 3 - Coded Prototype (Weeks to Month, $1K-10K):**
105- **What**: Working software with limited features, subset of data, shortcuts
106- **When**: Test technical feasibility, performance, integration complexity
107- **Methods**: Real users with real tasks, measure latency/errors, validate architecture
108- **Example**: Search engine - 10K documents (not 10M), 50 users, <1s response time → validates approach
109- **Pros**: Tests real technical constraints, reveals integration issues
110- **Cons**: More expensive/time-consuming, harder to throw away if wrong
111
112**Level 4 - Minimum Viable Product (Months, $10K-100K+):**
113- **What**: Simplest version that delivers core value to real customers
114- **When**: Assumptions mostly validated, ready for market feedback
115- **Methods**: Launch to small segment, measure retention/revenue, iterate based on data
116- **Example**: Instagram v1 - photo filters only (no video, stories, reels), launched to small group
117- **Pros**: Real market validation, revenue, learning
118- **Cons**: Expensive, longer timeline, public commitment
119
120## Guardrails
121
122**Ensure quality:**
123
1241. **Test riskiest assumption first**: Don't test what you're confident about
125 - ✓ "Will customers pay $X?" (high uncertainty) before "Can we make button blue?" (trivial)
126 - ❌ Testing minor details before validating core value
127
1282. **Match fidelity to question**: Don't overbuild for question at hand
129 - ✓ Paper prototype for testing workflow (hours), coded prototype for testing latency (weeks)
130 - ❌ Building coded prototype to test if users like color scheme (overkill)
131
1323. **Set success criteria before testing**: Avoid confirmation bias
133 - ✓ "10% conversion validates demand" (decided before test)
134 - ❌ "7% conversion? That's pretty good!" (moving goalposts after test)
135
1364. **Test with real target users**: Friends/family are not representative
137 - ✓ Recruit from target segment (e.g., enterprise IT buyers for B2B SaaS)
138 - ❌ Test with whoever is available (founder's friends who are polite)
139
1405. **Observe behavior, not opinions**: What people do > what they say
141 - ✓ "50% clicked 'Buy Now' but 0% completed payment" (real behavior → pricing/friction issue)
142 - ❌ "Users said they'd pay $99/mo" (opinion, not reliable predictor)
143
1446. **Be transparent about faking it**: Ethical pretotyping
145 - ✓ "Sign up for early access" or "Launching soon" (honest)
146 - ❌ Charging credit cards for fake product, promising features you won't build (fraud)
147
1487. **Throw away prototypes**: Don't turn prototype code into production
149 - ✓ Rebuild with proper architecture after validation
150 - ❌ Ship prototype code (technical debt, security issues, scalability problems)
151
1528. **Iterate quickly**: Multiple cheap tests > one expensive test
153 - ✓ 5 paper prototypes in 1 week (test 5 approaches)
154 - ❌ 1 coded prototype in 1 month (locked into one approach)
155
156## Quick Reference
157
158**Resources:**
159- **Quick start**: [resources/template.md](resources/template.md) - Pretotype/prototype experiment template
160- **Advanced techniques**: [resources/methodology.md](resources/methodology.md) - Fake door, concierge, Wizard of Oz, paper prototyping, A/B testing
161- **Quality check**: [resources/evaluators/rubric_prototyping_pretotyping.json](resources/evaluators/rubric_prototyping_pretotyping.json) - Evaluation criteria
162
163**Success criteria:**
164- ✓ Identified 3-5 riskiest assumptions ranked by risk (prob wrong × impact if wrong)
165- ✓ Tested highest-risk assumption with minimum fidelity needed
166- ✓ Set quantitative success criteria before testing (e.g., "10% conversion")
167- ✓ Recruited real target users (n=5-10 qualitative, n=100+ quantitative)
168- ✓ Collected behavior data (clicks, conversions, task completion), not just opinions
169- ✓ Results clear enough to make pivot/persevere/iterate decision
170- ✓ Documented learning and shared with team
171
172**Common mistakes:**
173- ❌ Testing trivial assumptions before risky ones
174- ❌ Overbuilding (coded prototype when landing page would suffice)
175- ❌ No success criteria (moving goalposts after test)
176- ❌ Testing with wrong users (friends/family, not target segment)
177- ❌ Relying on opinions ("users said they liked it") not behavior
178- ❌ Analysis paralysis (perfect prototype before testing)
179- ❌ Shipping prototype code (technical debt disaster)
180- ❌ Testing one thing when could test many (cheap tests run serially/parallel)
181
182**When to use alternatives:**
183- **A/B testing**: When have existing product/traffic, want to compare variations
184- **Surveys**: When need quantitative opinions at scale (but remember: opinions ≠ behavior)
185- **Customer interviews**: When understanding problem/context, not testing solution
186- **Beta testing**: When product mostly built, need feedback on polish/bugs
187- **Smoke test**: Same as pretotype (measure interest before building)