Rapid Prototyping & MVP Playbook

Rapid Prototyping & MVP Playbook

Purpose: Help teams learn what matters quickly and cheaply by running focused prototypes and experiments that validate value before building production systems.

Welcome — the hunger this playbook serves

If you want to reduce risk, stop building polished features no one uses, and surface the real trade-offs between desirability, feasibility, and viability, this playbook gives a compact, practical path. Use it to choose the right fidelity for each question, capture reliable learning, and turn those learnings into a minimum viable offering or a clear decision to stop.

When to use this playbook

• You're unsure which customer needs are real and which are internal assumptions.
• You need to validate operational constraints (cost, throughput, safety) quickly.
• You want a structured way to move from idea → experiment → decision within 1–4 weeks.

Quick overview

This playbook contains:

• A prototype decision matrix (paper, click-through, Wizard-of-Oz, functional)
• Guidelines for mapping fidelity to learning objectives
• Sprint plan and role checklist for a 1–4 week prototype
• Minimum measurement and go/no-go criteria
• Sample demo script and user test checklist
• A simple evaluation rubric to translate observations into decisions

Prototype decision matrix (choose by question)

Pick fidelity to answer the single hardest question you need to resolve. Use the matrix below as a guide.

• Paper / Sketch — Best for: early desirability, concept framing, flow issues. Low cost. Use when you need rapid user reactions to an idea or workflow.
• Click-through / Clickable Prototype — Best for: usability, navigation, messaging, conversion flows. Medium cost. Use when you need to test a user path without backend logic.
• Wizard-of-Oz (manual backend) — Best for: testing complex behaviors, service workflows, or constrained automation assumptions. Medium cost. Use when backend can be simulated by a person.
• Functional (thin production) — Best for: validating operational feasibility, performance bounds, integrations, and end-to-end economics. Higher cost; use only when prior learning supports it.

Fidelity vs. learning mapping

Map each experiment to one primary learning objective. Example pairings:

• Desirability (will customers want this?) — Paper, Click-through
• Usability (can users complete key tasks?) — Click-through, Wizard-of-Oz
• Value capture (will users pay / adopt?) — Click-through with pricing experiment, Wizard-of-Oz
• Operational feasibility (can ops deliver at scale?) — Functional prototype
• Safety/regulatory constraints — Narrow functional prototype + regulatory checklist

Sprint plan (1–4 week structure)

Use this flexible cadence. Adjust scope to fit the available time and risk appetite.

1. Day 0 — Alignment (half-day)
   • Define the experiment question (framed as a hypothesis).
   • Identify the primary metric and a minimum success threshold.
   • Choose prototype fidelity that maps to this question.
2. Days 1–3 — Build & recruit
   • Create the prototype and recruit test participants or pilot customers.
   • Prepare demo script, consent language, and measurement plan.
3. Days 4–10 — Run tests / pilot
   • Execute user sessions or pilot runs. Capture observations, metrics, and verbatim quotes.
   • Log defects, workarounds, and operational constraints.
4. Days 10–14 — Analyze & decide
   • Score learning against the rubric, synthesize themes, and recommend next step: pivot, persevere, fix, kill, or harden.

Role checklist

• Experiment lead — owns the hypothesis, metrics, and decision recommendation.
• Designer — builds flows, prototypes, and test materials.
• Engineer — supports technical prototyping or implements Wizard-of-Oz scaffolding.
• Researcher / Facilitator — runs sessions and captures qualitative data.
• Operations / Domain SME — validates operational assumptions and safety needs.

Minimum measurement to decide go/no-go

Keep measurement focused. Capture three things at minimum:

1. Primary metric: a single quantitative measure tied to your hypothesis (e.g., conversion rate, time-to-complete, percent willing to pay). Define a clear threshold for success.
2. Signal metrics: two or three supporting metrics (e.g., task completion, error rate, repeat use indicator).
3. Qualitative evidence: direct quotes, observed workarounds, and notable emotional reactions.

Sample evaluation rubric (score 0–3 for each dimension)

Sum scores and use thresholds to guide recommendations.

• Desirability — 0 (no interest) to 3 (strong intent / paid commitment)
• Feasibility — 0 (impractical/safety/regulatory blocker) to 3 (operationally sound)
• Viability — 0 (unsustainable economics) to 3 (clear path to positive unit economics)
• Learning quality — 0 (no usable insight) to 3 (clear, actionable insight)

Example decision guidance: total >=10 — proceed to harden; 7–9 — iterate with adjustments; <7 — pivot or stop.

Sample demo script (for user sessions or pilot customers)

Use a short, neutral script to ensure consistent delivery:

1. Greeting and consent: "Thanks for participating — I’ll ask you to try X. This is a prototype and not a finished product. We’re testing ideas, not you."
2. Context: "We’re exploring whether [problem statement]. Please think aloud as you use the prototype."
3. Task(s): Provide 2–3 realistic tasks that map to your hypothesis.
4. Observation prompts: Ask clarifying questions only after the session; otherwise let the user speak freely.
5. Closing: Ask open questions: "What would you change? What would make you use this regularly? Would you pay or recommend? Why or why not?"

User test checklist (what to capture during each session)

• Participant ID / segment
• Prototype fidelity used
• Tasks attempted and completion status
• Time-on-task
• Observations (workarounds, confusion points)
• Direct quotes (short verbatim phrases)
• Likely-to-recommend / willing-to-pay signals
• Unexpected insights or risks

Prototype artifacts & templates (copy and adapt)

Prototype brief (one page):

• Hypothesis: "If we [intervention], then [expected outcome] because [assumption]."
• Primary metric & success threshold
• Prototype fidelity & scope
• Participants (who & how many)
• Timeline & owners

Safety, legal, and mal-hunger reminders

This playbook is about rapid learning, not production safety or regulatory compliance. Label prototypes clearly, maintain data privacy and consent, and involve legal or safety experts before testing anything that could cause harm, violate regulations, or affect protected data.

Next steps: turning validated learning into an MVP

1. Synthesize learning into concrete requirements (what must be present in an MVP).
2. Prioritize features by impact on the primary metric and operational risk.
3. Plan a hardening sprint: address technical debt, safety, accessibility, and compliance before production launch.

Included samples

The playbook includes:

• Prototype brief template
• Experiment plan & measurement sheet
• Sample demo script and user test checklist
• Evaluation rubric

Use this playbook as a living tool: capture your experiment data, iterate on the templates, and grow a library of validated learnings that inform future work.