Skill: quochungto/bookforge-discovery-prototype-selection (version 1.0.0)

--- name: discovery-prototype-selection description: "Select the right prototype type and fidelity level for any discovery risk. Use when deciding what kind of prototype to build, when choosing between a feasibility spike, user prototype, live-data prototype, or Wizard of Oz prototype, or when someone asks 'what prototype should we build?' Also use when prototyping for usability testing, when validating a technical approach before building, when building a simulation for stakeholder alignment, or when an AI/ML feature needs pre-model validation. Maps the active risk (feasibility/usability/value/viability) to one of four prototype types and determines fidelity. Includes anti-pattern warnings for ambush estimation and prototype-as-value-proof confusion. Best triggered after product-discovery-risk-assessment. For executing usability or value tests after the prototype, use value-testing-technique-selection." version: 1.0.0 homepage: https://github.com/bookforge-ai/bookforge-skills/tree/main/books/inspired-how-to-create-tech-products/skills/discovery-prototype-selection metadata: {"openclaw":{"emoji":"📚","homepage":"https://github.com/bookforge-ai/bookforge-skills"}} status: published source-books: - id: inspired-how-to-create-tech-products title: "INSPIRED: How to Create Tech Products Customers Love" authors: ["Marty Cagan"] chapters: [45, 46, 47, 48, 49, 55] tags: [product-management, product-discovery, prototyping] depends-on: [product-discovery-risk-assessment] execution: tier: 1 mode: hybrid inputs: - type: document description: "Risk assessment output from product-discovery-risk-assessment, or description of the risk being addressed" tools-required: [Read, Write] tools-optional: [] mcps-required: [] environment: "Document-based product management environment" discovery: goal: "Select the right prototype type and fidelity for the active risk, then guide its creation" tasks: - "Identify which risk is being addressed (feasibility/usability/value/viability)" - "Select the matching prototype type" - "Determine correct fidelity level for the testing purpose" - "Identify who creates the prototype and what constraints apply" - "Flag anti-patterns before creation begins" audience: roles: [product-manager, product-designer, tech-lead, startup-founder] experience: any when_to_use: triggers: - "Risk assessment has identified prototyping as a required technique" - "Deciding which prototype approach to use for a discovery question" - "Team is about to build a prototype and needs to align on type and fidelity" - "Evaluating whether to use a user prototype, feasibility spike, or live-data experiment" prerequisites: - "product-discovery-risk-assessment completed (or risk explicitly identified)" not_for: - "Executing usability tests (prototype is an input to testing, not the test itself)" - "Value testing — user prototypes do not validate value; use value-testing techniques after prototyping" - "Delivery work — feasibility prototypes are discovery code, not production code" environment: codebase_required: false codebase_helpful: true works_offline: true quality: scores: with_skill: 0 baseline: 0 delta: 0 tested_at: "" eval_count: 0 assertion_count: 0 iterations_needed: 0 --- # Discovery Prototype Selection ## When to Use Apply this skill when a risk assessment has identified prototyping as a needed technique, or when the team needs to decide which prototype approach to use. This skill answers three questions: 1. Which prototype type matches the risk being addressed? 2. What fidelity level is appropriate for the testing purpose? 3. Who creates it, and what constraints apply? Run this before building any prototype. The wrong prototype type wastes significant time — a user prototype cannot answer a feasibility question, and a feasibility prototype cannot answer a usability question. ## Governing Principles Five principles apply to all prototype types. Violating any of them is a common source of wasted effort. **Principle 1 — Cost of learning, not cost of building.** The overarching purpose of any prototype is to learn something at a much lower cost in time and effort than building a product. All forms of prototype should require at least an order of magnitude less time and effort than the eventual product. If a prototype is taking as long as shipping would, it has become delivery work. **Principle 2 — Creation forces depth.** Creating a prototype forces the team to think through a problem at a substantially deeper level than talking about it or writing a document. This is why the act of creating a prototype so often exposes major issues otherwise left uncovered until much later. Do not skip prototyping in favor of documents or meetings. **Principle 3 — Shared understanding tool.** A prototype is a powerful tool for team collaboration and stakeholder alignment. Members of the product team and business partners can all experience the prototype to develop shared understanding. Use prototypes in stakeholder reviews, not just user tests. **Principle 4 — No single correct fidelity.** There is no such thing as one appropriate level of fidelity. The right level depends entirely on the testing purpose. Lower fidelity is faster and cheaper than higher fidelity. Only do higher fidelity when the testing purpose requires it. **Principle 5 — Prototypes are disposable.** The primary purpose of a prototype is to address product risks in discovery. The prototype itself is not the product. Feasibility prototypes are throwaway code. User prototypes are simulations. Live-data prototypes are not commercially shippable. Treat all of them as disposable. > **Critical warning — Prototype does not equal value validation.** A user prototype — even a high-fidelity one that 15 users say they "love" — does not validate value. User prototypes test usability and comprehension. They cannot prove purchase intent, retention, or behavioral change. People say all kinds of things when looking at a prototype and then do something completely different when real money or real effort is required. If the team needs to validate value, use a dedicated value-testing technique (demand validation, fake door test, live-data prototype with real behavior measurement) after — not instead of — usability testing. This is one of the most common and expensive mistakes in product discovery. ## Process ### Step 1: Identify the Risk Being Addressed Read the risk assessment output. Determine which risk the prototype is meant to address: - **Feasibility risk** — Can the team build this at all? (algorithm, performance, scalability, unfamiliar technology, third-party integration, legacy system, cross-team dependency) - **Usability risk** — Can users figure out how to use this? (workflow complexity, novel interaction, multi-step process, error-prone operations) - **Value risk (qualitative)** — Do users understand and respond to the value proposition when they see it? (distinct from demand validation — this tests comprehension and perceived value) - **Viability risk** — Does this work for the business? (requires stakeholder review using prototype as communication tool) **WHY:** Each risk requires a different prototype type. Mismatching the prototype to the risk produces invalid signal. A user prototype cannot tell you if an algorithm will work. A feasibility prototype cannot tell you if a workflow is learnable. If multiple risks are present, select the prototype type that addresses the highest-priority risk first. Run multiple prototypes in sequence if necessary — do not try to address all risks with one prototype. ### Step 2: Select the Prototype Type Use this decision table: | Risk Being Addressed | Prototype Type | Creator | Output | |---|---|---|---| | Feasibility | Feasibility prototype | Engineer(s) | Working code demonstrating the approach | | Usability | User prototype | Designer | Simulation (interactive wireframe to high-fidelity mock) | | Value (qualitative, perceived) | User prototype (high fidelity) | Designer | Realistic simulation for qualitative testing | | Value (quantitative, behavioral) | Live-data prototype | Engineer(s) | Limited real implementation collecting analytics | | Automation / AI / ML viability + UX simultaneously | Hybrid prototype — Wizard of Oz | Designer + Engineer | Human operator simulates the automated behavior behind a realistic UI | | Stakeholder alignment | User prototype | Designer | Communication artifact showing what will be built | **Wizard of Oz prototype (Hybrid variant for AI/ML features):** When the team is validating whether an AI- or automation-powered feature would be valuable and usable before the model or automation exists, a human operator manually performs the automated action in real time while the user interacts with a realistic front-end. The user does not know a human is behind the curtain. This technique answers both value and usability questions for features that would be difficult or slow to build as live-data prototypes (because the model doesn't exist yet). Constraint: only works at very small scale — one session at a time, manually operated. Never use for quantitative validation. See `references/prototype-type-details.md` for full descriptions of each type, their limitations, and canonical use cases. ### Step 3: Determine Fidelity For user prototypes, fidelity is the primary variable. Apply this fidelity rule: | Testing Purpose | Required Fidelity | Rationale | |---|---|---| | Value testing (qualitative: does the user perceive value?) | High | Must feel realistic; if users can tell it is fake, their reactions are not valid. People say all kinds of things about low-fi prototypes and then do something different. | | Usability testing (can they complete the workflow?) | Low to medium acceptable | Information architecture and workflow are testable even without visual polish. | | Demand validation (will they buy or sign up?) | Live-data or fake door | A user prototype cannot prove purchase behavior. Use live-data prototype or a fake door (demand test). | | Stakeholder communication | Medium to high | Stakeholders need to experience the product concept clearly. | | Team alignment / internal exploration | Low | Speed matters more than realism for internal thinking. | **WHY:** Fidelity is a cost dial. High-fidelity user prototypes take significantly more time to create. Only spend that time when the testing purpose actually requires realism. For usability testing, a low-fidelity prototype is often more than adequate and faster to iterate. For feasibility prototypes, fidelity is irrelevant — they are code with no user interface, no error handling, and no polish. Write just enough code to answer the feasibility question. For live-data prototypes, include only the instrumentation needed for the specific use cases being measured. Do not build full analytics infrastructure. ### Step 4: Confirm Creator and Constraints **Feasibility prototype:** - Created by: one or more engineers (not designers, not product managers) - Typical time: one to two days for most questions; longer for major new technology (machine learning, novel algorithms) - Constraint: this is discovery code — throwaway. No productization judgment from the product manager. If engineers need to productize, they must be given full delivery time. **User prototype:** - Created by: designer (primary); some designers prefer to hand-code high-fidelity prototypes — acceptable if fast and treated as disposable - Tools: standard prototyping tools (Figma, Framer, etc.) or hand-coded - Constraint: this is a simulation. There is nothing behind the curtain. No real data, no real transactions. Do not show user prototype results as proof of value. **Live-data prototype:** - Created by: engineer(s) — designers cannot create this - Typical scope: 5–10% of eventual productization effort - Constraint: not commercially shippable. Explicitly communicate this to executives and stakeholders. The product manager does not decide when this is "good enough" — that judgment belongs to the engineers when they productize. **Hybrid prototype:** - Created by: designer (front-end simulation) + engineer or team member operating the backend manually - Constraint: not scalable — never send significant traffic to a Wizard of Oz prototype. Its value is qualitative learning, not quantitative proof. ### Step 5: Check Anti-Patterns Before Proceeding Before creating a feasibility prototype, check for these two anti-patterns: **Anti-pattern: Ambush estimation.** Demanding that engineers provide time or effort estimates in a planning meeting, without giving them time to investigate, produces conservative and inflated answers. Engineers put on the spot without investigation time will give answers designed to make the questioner go away. The correct question is not "Can you do this?" but "What is the best way to do this and how long would it take?" — and only after giving engineers time to investigate. If the answer is a feasibility prototype, encourage them to proceed. **Anti-pattern: Feasibility-averse product management.** Product managers who hate any idea that requires engineering investigation systematically kill the most innovative product ideas. Many of the best product ideas are based on approaches that are only now possible — which means new technology and investigation time. When engineers say they need a day or two to investigate, treat it as an opportunity, not a liability. Engineers given even a day or two often come back not only with answers to the feasibility question but also with better ways to solve the problem. Before creating a user prototype, check for this anti-pattern: **Anti-pattern: Prototype-as-validation confusion.** Showing a high-fidelity user prototype to 10–15 people who say they love it does not validate value. People say all kinds of things and then do something different. A user prototype is not good for proving anything — including whether a product will sell. Use separate value testing techniques (demand validation, quantitative value testing) after usability is confirmed. The user prototype is the input to usability testing and stakeholder alignment, not the output of value validation. ### Step 6: Document the Prototype Plan Write a brief prototype plan (one page or less) capturing: ``` # Prototype Plan: [Feature / Product Name] ## Risk Being Addressed [Feasibility / Usability / Value-qualitative / Viability] ## Prototype Type Selected [Feasibility / User / Live-Data / Hybrid] Rationale: [one sentence] ## Fidelity Level (for user prototypes) [Low / Medium / High] Rationale: [testing purpose requires X] ## Creator [Engineer(s) / Designer / Both] Estimated time: [X days] ## What Question This Prototype Answers [Specific, testable question — e.g., "Can we achieve sub-200ms response time with this algorithm?" or "Can a new user complete account setup without help?"] ## What This Prototype Cannot Answer [List what will NOT be learned — important for setting expectations] ## Anti-Pattern Check [ ] No ambush estimation applied to engineers [ ] Team understands this prototype does not validate value [ ] Prototype is scoped to just enough to answer the question [ ] Prototype is treated as disposable ## Next Step After Prototype [Usability test / Feasibility go/no-go decision / Quantitative value test / Stakeholder review] ``` ## Outputs - Prototype plan document (per template above) - Prototype artifact (created by engineer or designer per type) - Anti-pattern check completed and documented ## Key Principles Summary | Principle | What It Means in Practice | |---|---| | Learn at fraction of cost | If prototype takes as long as shipping, it has become delivery | | Creation forces depth | Build the prototype even when discussion feels sufficient | | Shared understanding | Use prototypes in stakeholder reviews, not just user tests | | Right fidelity, not one fidelity | Value testing → high fi; usability → low/medium fi acceptable | | Prototypes are disposable | Discovery code is not production code; simulations are not products | ## References - `references/prototype-type-details.md` — Full descriptions of all four prototype types, canonical use cases, limitations, and creation guidance - `references/fidelity-decision-guide.md` — Fidelity selection decision tree with examples across product types - `references/feasibility-testing-questions.md` — The 10 feasibility questions engineers answer in discovery (Ch55) and how to structure engineer-led investigation ## License This skill is licensed under [CC-BY-SA-4.0](https://creativecommons.org/licenses/by-sa/4.0/). Source: [BookForge](https://github.com/bookforge-ai/bookforge-skills) — INSPIRED: How to Create Tech Products Customers Love by Marty Cagan. ## Related BookForge Skills Install related skills from ClawhHub: - `clawhub install bookforge-product-discovery-risk-assessment` Or install the full book set from GitHub: [bookforge-skills](https://github.com/bookforge-ai/bookforge-skills)

path: references/feasibility-testing-questions.md
content: # Feasibility Testing Questions

Source: INSPIRED by Marty Cagan, Chapter 55 (Testing Feasibility)

## The 10 Feasibility Questions Engineers Answer in Discovery

When engineers validate feasibility in discovery, they are trying to answer a set of related questions about whether and how the team can build a proposed solution:

1. **Do we know how to build this?** — Does the technical approach exist and is it understood?
2. **Do we have the skills on the team to build this?** — Are the required engineering capabilities present?
3. **Do we have enough time to build this?** — Within acceptable constraints, can this be delivered?
4. **Do we need any architectural changes to build this?** — Will this require significant platform or infrastructure changes?
5. **Do we have on hand all the components we need to build this?** — Are required libraries, services, and building blocks available?
6. **Do we understand the dependencies involved in building this?** — Are cross-team or cross-system dependencies identified and manageable?
7. **Will the performance be acceptable?** — Will the solution meet latency, throughput, or response time requirements?
8. **Will it scale to the levels we need?** — Can the solution handle the expected load?
9. **Do we have the infrastructure necessary to test and run this?** — Are the required environments and tooling available?
10. **Can we afford the cost to provision this?** — Are the operational costs (compute, storage, API costs, etc.) acceptable?

Most of the time, engineers will review product ideas in discovery and quickly say "No problem" — because most work is not all that new, and engineers have typically built similar things before.

Feasibility investigation is needed when one or more of these questions cannot be answered quickly.

---

## How to Structure Engineer-Led Feasibility Investigation

**The right question to ask:** Not "Can you do this?" but "What is the best way to do this, and how long would it take?" The first question invites a binary yes/no that puts engineers on the spot. The second question opens an investigation and invites engineering judgment.

**Give engineers time to investigate.** Holding a planning meeting and demanding instant estimates on ideas engineers have not had time to consider will produce conservative, inflated answers designed to make the questioner go away. Ambush estimation is a named anti-pattern (see main skill).

**Engineers who have been following discovery will estimate better.** If engineers have been present during discovery — watching users try prototypes, understanding the problems being solved — they will have already been thinking about feasibility for some time. Their estimates will be more accurate because they have context. This is another reason why engineers belong in discovery, not just delivery.

**When engineers say they need a feasibility prototype:** First consider whether the idea is potentially worth the necessary investigation time in discovery. If so, encourage engineers to proceed. The feasibility prototype answers the question; the product manager then decides whether to pursue the approach.

**What engineers produce:** A feasibility prototype — throwaway code that answers the specific feasibility question. No user interface, no error handling, no productization work. Just enough code to demonstrate whether the approach is viable.

---

## Feasibility Anti-Patterns

### Anti-pattern: Ambush Estimation

**What it looks like:** The product manager presents a list of ideas at a weekly planning meeting and asks engineers to estimate them in time or story points on the spot.

**Why it fails:** Engineers put on the spot without investigation time give conservative answers partly designed to make the questioner go away. The estimate is not a real estimate — it is a defensive answer. The team then makes decisions based on inflated numbers, systematically undervaluing complex but high-impact ideas.

**Correct approach:** Ask engineers "What is the best way to do this and how long would it take?" — and give them time to actually investigate before expecting an answer. If investigation requires a feasibility prototype, support that.

### Anti-pattern: Feasibility-Averse Product Management

**What it looks like:** The product manager refuses or avoids any product idea that engineers say requires time to investigate. The product manager treats "needs investigation" as equivalent to "too risky" and filters out these ideas systematically.

**Why it fails:** Many of the best product ideas are based on approaches that are only now possible — which means new technology that engineers need time to learn and evaluate. A product manager who avoids all such ideas systematically kills innovation. The most innovative opportunities are frequently the ones that require investigation because they are genuinely new.

**Three reasons to embrace feasibility investigation:**
1. Many best product ideas are based on newly possible technology — which by definition requires investigation time.
2. Engineers given even one or two days to investigate often return not just with feasibility answers but with better ways to solve the problem.
3. Feasibility investigation is often highly motivating for engineers — it gives them opportunity to learn and shine.

**Correct approach:** When engineers say they need time to investigate, treat it as an opportunity signal, not a risk signal. Evaluate whether the idea is worth the investigation time. If yes, encourage investigation.


path: references/fidelity-decision-guide.md
content: # Fidelity Decision Guide

Source: INSPIRED by Marty Cagan, Chapters 45 and 47

## Core Principle

There is no such thing as one appropriate level of fidelity for a prototype. Fidelity primarily refers to how realistic the prototype looks. The principle is to create the right level of fidelity for the intended purpose, knowing that lower fidelity is faster and cheaper than higher fidelity — so only do higher fidelity when you need to.

## Decision Tree

**What is the testing purpose?**

### 1. Value testing (qualitative) — "Does the user perceive value when they see this?"

Required fidelity: **High**

Why: Value perception depends on realism. If users can tell the prototype is fake — through low-quality visuals, placeholder data, or missing interactions — their reactions are not valid signal. People react to what they actually see and experience. A low-fidelity prototype triggers "this doesn't look real" responses that contaminate the value signal. High fidelity is required so users can genuinely assess whether they would want this product.

Warning: Even high-fidelity user prototypes cannot prove purchase behavior. They test perceived value — "this seems useful" — not behavioral value — "I will pay money for this." Do not mistake positive reactions to a high-fidelity prototype for validated demand.

### 2. Usability testing — "Can the user complete the workflow without help?"

Acceptable fidelity: **Low to medium**

Why: Usability testing is primarily about information architecture, workflow sequencing, and interaction clarity — not visual design. A low-fidelity prototype (interactive wireframe) is often more than adequate for identifying where users get stuck, what labels confuse them, or where the workflow breaks down. Moving to high fidelity before resolving major usability issues wastes time on polish that may be discarded.

Exception: If the usability question involves visual design specifically (e.g., "is the call-to-action button visible?"), medium to high fidelity may be needed.

Low-fidelity prototypes do not capture:
- The impact of visual design on user confidence
- Differences caused by actual data (vs. placeholder content)
- The impact of visual hierarchy on attention

If those dimensions matter for the usability question, increase fidelity accordingly.

### 3. Demand validation — "Will users buy or sign up for this?"

Required approach: **Live-data prototype or fake door (demand test) — not a user prototype**

Why: A user prototype is a simulation. It cannot generate real behavioral data. Showing a user prototype to users and asking "would you buy this?" produces stated preference, not revealed preference. People say all kinds of things and then do something different. Demand validation requires users to actually take an action with real consequences — visiting a real landing page, attempting a real sign-up, or clicking a real "buy" button. A live-data prototype or demand-testing technique is the right tool for this, not a user prototype at any fidelity level.

### 4. Stakeholder communication — "Does leadership understand and support what we are building?"

Acceptable fidelity: **Medium to high**

Why: Stakeholders and business partners need to experience the product concept clearly enough to make decisions. A low-fidelity wireframe often fails to communicate the vision — stakeholders struggle to project what the finished product will look and feel like. Medium to high fidelity bridges this gap. The prototype does not need to be pixel-perfect, but it needs to be representative enough that stakeholders can give informed feedback and alignment.

### 5. Internal team alignment — "Are we all thinking about the same thing?"

Acceptable fidelity: **Low**

Why: For internal team thinking, speed matters more than realism. Creating a prototype (even a low-fidelity one) forces the team to think through the problem at a substantially deeper level than talking about it. Low-fidelity prototypes expose major issues that would otherwise remain hidden in conversations. Create quickly; iterate quickly.

---

## Fidelity by Prototype Type

| Prototype Type | Fidelity Concept | Notes |
|---|---|---|
| Feasibility | Not applicable | It is code, not a UI simulation |
| User (low) | Interactive wireframe | Fast; tests workflow, not visual design |
| User (medium) | Styled but not pixel-perfect | Balances speed and realism |
| User (high) | Looks and feels real | Required for value testing |
| Live-data | Actual implementation | Real data, limited scope, real users |
| Hybrid / Wizard of Oz | High visual fidelity + human backend | Looks real; backend is manual |

---

## Common Fidelity Mistakes

**Starting with high fidelity when low would suffice.** Teams that jump to high-fidelity prototypes for early usability testing spend time on polish before resolving fundamental workflow issues. Iterate at low fidelity until the workflow is sound, then increase fidelity for value testing.

**Using low fidelity for value testing.** Showing users a wireframe and asking if they value the concept produces unreliable signal. Users cannot properly evaluate value through placeholder-filled sketches.

**Treating any prototype fidelity as proof of demand.** The fidelity level of a user prototype does not change its fundamental limitation: it cannot prove purchase behavior. This is a category error, not a fidelity error.


path: references/prototype-type-details.md
content: # Prototype Type Details

Source: INSPIRED by Marty Cagan, Chapters 46–49

## Type 1: Feasibility Prototype (Ch46)

**What it is:** Working code written by one or more engineers to answer a specific technical question. It is not a user interface, not a product, and not productization-ready.

**When to use:** When engineers identify significant feasibility risk in the discovery process. Common triggers:
- Algorithm concerns (can we make this work at all?)
- Performance concerns (will it be fast enough?)
- Scalability concerns (will it hold up under load?)
- Fault tolerance concerns
- Use of a technology the team has not used before
- Use of a third-party component or service the team has not used before
- Use of a legacy system the team has not used before
- Dependency on new or related changes by other teams

**Who creates it:** Engineers only. Product managers and designers do not create feasibility prototypes.

**Fidelity:** None in the UI sense. It is code — throwaway code. No user interface, no error handling, no analytics, none of the work required for productization. Just enough code to answer the specific feasibility question.

**Typical time:** One to two days for most questions. Significantly longer for major new technology (machine learning, novel algorithms, major architectural changes).

**Key constraint — disposability:** Feasibility prototypes are intended to be throwaway code. It is normal and expected to be quick and dirty. The product manager does not judge when this code is "good enough" for production — that judgment belongs to engineers during productization, and they must be given full time to do delivery work properly.

**Key constraint — discovery framing:** Feasibility prototype work is discovery work, not delivery work. It is done as part of deciding whether to even pursue a particular approach. This distinction matters for team planning and morale.

---

## Type 2: User Prototype (Ch47)

**What it is:** A simulation. Smoke and mirrors. There is nothing behind the curtain. If you have a user prototype of an e-commerce site and enter credit card information, you will not actually be buying anything.

**When to use:** Usability testing, qualitative value testing, stakeholder alignment, team exploration of workflow.

**Who creates it:** Designers (primary). Some designers prefer to hand-code high-fidelity user prototypes, which is acceptable as long as they are fast and the prototype is treated as disposable.

**Fidelity spectrum:**

*Low-fidelity user prototype:* Does not look real — essentially an interactive wireframe. Useful for internal team thinking and testing information architecture and workflow. Does not capture the impact of visual design or differences caused by actual data. Faster and cheaper than high fidelity.

*High-fidelity user prototype:* Looks and feels very real. Data appears realistic (though it is not real or live). With good high-fidelity prototypes, you need to look closely to see it is not real. Required when testing value perception — users must experience the product concept as realistic for their reactions to be valid signal.

**Tools:** Standard prototyping tools developed for designers. Your designer almost certainly already has a preferred tool.

**Key limitation — cannot prove value:** The big limitation of a user prototype is that it is not good for proving anything, including whether a product will sell. Where many novice product practitioners go sideways is when they create a high-fidelity user prototype, put it in front of 10–15 people who all say they love it, and think they have validated their product. People say all kinds of things and then do something different. Better value testing techniques exist — use them for demand validation.

**Key use — communication:** A user prototype is one of the most important communication tools in product discovery. It enables stakeholders, engineers, and business partners to experience the product concept and develop shared understanding.

---

## Type 3: Live-Data Prototype (Ch48)

**What it is:** A very limited real implementation designed to collect actual usage data. It is not a simulation — real users use it for real work, generating real analytics. But it is substantially smaller and lower quality than the eventual product.

**When to use:** When you need actual usage data to address a major risk, and a user prototype simulation is insufficient. Canonical use cases:
- Search relevance (does this ranking algorithm actually surface better results?)
- Game dynamics (do users actually engage with this mechanic?)
- Social features (do users actually connect and interact as hypothesized?)
- Product funnel optimization (where do users actually drop off?)

**Who creates it:** Engineers only — designers cannot create live-data prototypes. This is real code.

**What it excludes by design:** All the work normally required for productization:
- Full set of use cases
- Automated tests
- Full analytics instrumentation (only the specific use cases being measured)
- Internationalization and localization
- Performance and scalability work
- SEO work
- Error handling and edge cases

**Typical scope:** 5–10% of the eventual delivery productization effort.

**Key constraint — not shippable:** A live-data prototype is not commercially shippable. It is not ready for prime time and cannot run a business on it. If live-data tests go well and the team decides to productize, engineers must be given full delivery time. It is not acceptable for a product manager to tell engineers that the live-data prototype is "good enough." That judgment does not belong to the product manager.

**Key constraint — stakeholder communication:** Executives and key stakeholders must understand the limitations of the live-data prototype explicitly. Managing this expectation is the product manager's responsibility.

**Speed:** Modern tooling makes live-data prototypes achievable in a couple of days to a week. Iteration cycles are fast once the prototype exists.

---

## Type 4: Hybrid Prototype (Ch49)

**What it is:** A combination of elements from user prototypes, feasibility prototypes, and live-data prototypes. The most common and powerful hybrid is the Wizard of Oz prototype.

**Wizard of Oz prototype:** Combines the front-end user experience of a high-fidelity user prototype with an actual person behind the scenes performing manually what would ultimately be handled by automation. From the user's perspective, it looks and behaves like a real product. Behind the scenes, it is a human (often the product manager or another team member) performing the manual work.

**When to use:** When you need to test the user experience of an automated system before the automation exists. Most powerful for:
- Automated chat or messaging systems
- Recommendation engines
- Any feature that will ultimately be algorithm-driven but where the interaction design matters now

**Example:** You want to build an automated 24/7 chat support system. Build a simple chat interface (user prototype front-end), but behind the scenes your customer service team (or you) manually receives the requests and composes responses. Users experience a realistic interaction. You learn what questions they ask, how they phrase them, and what responses satisfy them — all before writing any automation code.

**Key constraint — not scalable:** A Wizard of Oz prototype is absolutely not scalable. Never send significant amounts of traffic to one. Its value is qualitative learning, not quantitative proof.

**Key principle — build things that don't scale:** Hybrid prototypes embody the "build things that don't scale" philosophy of product discovery. By being a little clever, you can quickly create tools that let the team learn very quickly. The learning is mainly qualitative, but that is often where the biggest insights come from.

**Evolution path:** Wizard of Oz prototypes often evolve into live-data prototypes as the team begins to experiment with system-generated responses and algorithm-based approaches.


Security scan verdicts — ClawScan: clean | static analysis: clean | VirusTotal: clean | SkillSpector: clean (LOW)