Chapter 7: Prototyping & Rapid Testing

The Prototype Mindset

A prototype is a question in physical form. It asks: "If we built this, would it work?" The faster you can ask that question, the cheaper it is to learn the answer.

Three principles govern effective prototyping:

You can prototype anything. Products, services, marketing materials, sales conversations, onboarding flows, pricing pages — all of them can be faked convincingly enough to learn from real reactions ^sprint. Teams that limit "prototyping" to interactive mockups are leaving their riskiest assumptions untested.

Prototypes are disposable. The moment you become attached to a prototype, you have confused the map with the territory. A prototype exists to generate learning. Once you have that learning, the prototype has served its purpose. Build with materials — digital or physical — that you are willing to throw away ^sprint.

Build just enough. A prototype needs to be real enough that a person can react to it honestly, and fake enough that you did not waste a week building it. This is the Goldilocks quality principle, and getting it right is one of the highest-leverage skills in product development ^sprint.

Goldilocks Quality

The quality of your prototype sits on a spectrum. Too low, and the illusion breaks — participants react to the roughness of the artifact rather than the concept behind it. Too high, and you have spent time polishing something that might be the wrong thing entirely.

Too low: Wireframes on paper with handwritten labels. Participants spend cognitive effort interpreting what they are looking at instead of responding to the experience. They say "I can't really tell what this would be like" and your test produces noise, not signal.

Too high: A pixel-perfect, fully interactive prototype indistinguishable from a shipped product. You spent three weeks building it. Now the team is emotionally invested, and the sunk cost makes it psychologically difficult to hear negative feedback.

Just right: A realistic facade ^sprint. It looks like a real product, app, or website. It has real-seeming content (not lorem ipsum). It responds to the specific interactions you want to test. But it has no backend, no edge cases handled, and took one day to build. Participants believe they are using something real; you know it is a stage set.

The one-day build constraint is not arbitrary. It is a forcing function. When you have eight hours, you cannot over-engineer. You make ruthless decisions about what to include, which means you must know exactly what you are testing — and that clarity is itself valuable.

The Five-Day Sprint Structure

The design sprint, developed at Google Ventures and documented by Jake Knapp ^sprint, compresses months of debate into five days. It is not a brainstorming workshop. It is a structured process that moves from problem definition to tested prototype in a single week.

Monday: Map

The sprint begins by building shared understanding. The team creates a map of the problem space — a simple diagram showing how customers move through the experience from start to finish. The Decider (the person with authority to make the call) picks a target: a specific customer and a specific moment in their journey that the sprint will focus on.

Monday also includes expert interviews — short conversations with teammates, stakeholders, or subject-matter experts who have relevant knowledge. The team captures "How Might We" notes during these interviews, then organizes and votes on them to identify the most important questions.

The output of Monday is a single, focused target: one customer segment, one critical moment, one big question the sprint will answer.

Tuesday: Sketch

Tuesday is about generating solutions — individually, not as a group. The sprint uses structured individual work because group brainstorming reliably produces mediocre ideas shaped by the loudest voice in the room ^sprint.

The core mechanism is the Four-Step Sketch:

1. Notes: Each person reviews the Monday map, the HMW notes, and any existing inspiration. They jot down key ideas — raw material, not solutions.

2. Ideas: Rough sketches. Doodles, flow diagrams, half-formed concepts. Still private, still messy.

3. Crazy 8s: Each person folds a sheet of paper into eight panels and sketches eight variations of their best idea in eight minutes — one minute per panel. This forces rapid iteration and prevents premature attachment to the first idea.

4. Solution Sketch: A three-panel storyboard of the person's best concept, detailed enough that someone else can understand it without explanation. These are anonymous and self-explanatory — no pitching allowed.

The Four-Step Sketch works because it gives introverts equal footing, prevents anchoring on the first idea voiced aloud, and produces concrete artifacts rather than abstract discussion.

Wednesday: Decide

Wednesday morning, the team uses the Sticky Decision process to choose which solution(s) to prototype:

1. Art Museum: All solution sketches are taped to the wall. The team reads them silently — no presentations, no explanations. If a sketch cannot communicate its idea on its own, that is useful information.

2. Heat Map: Each person places small dot stickers on parts of sketches they find compelling. This surfaces interesting details without requiring anyone to commit to a full solution.

3. Speed Critique: The facilitator narrates each sketch (the creator stays silent), the team discusses standout ideas for three minutes, and the creator can clarify at the end.

4. Straw Poll: Each person places a single large dot on the sketch they think best addresses the sprint question. This is a signal, not a decision.

5. Supervote: The Decider places their votes. The Decider's vote wins. This is not democracy — it is an efficient way to incorporate everyone's input while maintaining clear decision authority.

If two strong but fundamentally different solutions emerge, the team may run a Rumble: building two competing prototypes and testing them head-to-head on Friday. This is more work but eliminates the risk of choosing wrong without evidence.

After the decision, the team creates a storyboard: a 10-15 panel comic strip that serves as the blueprint for Thursday's prototype. The storyboard starts with an opening scene — how the customer first encounters the experience (a Google search, a friend's recommendation, an email). This context matters because it shapes the customer's expectations and mindset.

Thursday: Build

Thursday is build day. The team constructs the prototype in a single day using the storyboard as their guide. Key roles:

• Makers (typically 2): Build the core screens or artifacts using tools like Keynote, Figma, or Squarespace — whatever produces realistic output fastest.
• Stitcher (1): Combines the Makers' work into a seamless, clickable flow. Ensures transitions make sense and the whole thing hangs together.
• Writer (1): Creates all the text. Real words, not placeholder copy. The language is often the thing customers react to most strongly.
• Asset Collector (1): Gathers photos, icons, sample data — anything needed to make the prototype look populated and real.
• Interviewer (1): Spends the day writing the interview script, confirming the Friday schedule, and doing a trial run of the prototype.

The division of labor matters. Without a dedicated Writer, you get lorem ipsum. Without an Asset Collector, you get empty states. Without a Stitcher, you get disconnected screens. The prototype must feel like a cohesive experience, not a collection of parts.

Friday: Test

Friday is the payoff. Five customers use the prototype while the rest of the team watches from another room. Five is enough — Jakob Nielsen's research shows that five users typically surface approximately 85% of usability problems ^sprint. Diminishing returns set in quickly after that.

The interviews follow the Five-Act Interview structure:

1. Friendly welcome: Put the participant at ease. Establish that you are testing the product, not them, and that honest reactions (including negative ones) are the most helpful thing they can give you.

2. Context questions: Open-ended questions about the participant's background and current behavior relevant to the problem. This grounds their prototype reactions in real experience.

3. Introduction to the prototype: Explain that some things may work and some may not, and ask them to think aloud as they explore.

4. Tasks and nudges: Guide the participant through the storyboard's key scenarios. Use gentle nudges ("What would you do next?") rather than instructions ("Click the blue button").

5. Quick debrief: Ask for overall reactions. What stood out? How does this compare to what they do today? Would they use this?

While the Interviewer runs the sessions, the rest of the team watches and takes structured notes — typically on a grid with one column per customer and one row per scene or question. After all five interviews, the team reviews the grid together, looking for patterns. If three or more of five customers hit the same problem or had the same positive reaction, that is a strong signal.

The Brochure Facade

One of the most underrated sprint techniques is the Brochure Facade: instead of prototyping the product itself, you prototype the marketing material for the product ^sprint. Build a fake landing page, a product brochure, or a sales deck. Then show it to potential customers and see whether the value proposition resonates.

This technique is powerful for three reasons. First, it forces you to articulate the value proposition in plain language before you build anything. Second, it tests demand, not usability — a critical distinction early in the product lifecycle. Third, it is fast. A convincing landing page can be built in hours.

Disciplined Entrepreneurship recommends a similar exercise: creating a product brochure as an early prototype ^de. This is a one-page document (or a simple website) that describes the product as if it already exists — what it does, who it is for, and why it matters. You show it to prospective customers and ask whether they would want it. The brochure forces specificity. Vague ideas sound good in conversation but fall apart on paper.

High-Level Product Specification

Bill Aulet's approach to early prototyping emphasizes a visual first draft of the product ^de. The High-Level Product Specification is not a requirements document — it is a sketch of what the customer would see and experience, focusing on the key moments that deliver value. It should be visual, not textual: diagrams, wireframes, storyboards.

Aulet describes a process of spiraling innovation: you show the specification to customers, gather feedback, revise, and show again. Each cycle tightens the fit between what you are building and what the customer actually needs. The key discipline is showing the specification early and often, before you have invested enough to become defensive about it.

This approach complements the sprint methodology. A sprint produces a tested prototype in five days; the spiraling innovation model describes how to iterate on that prototype across multiple cycles.

Testing in Context

Where you test matters. A prototype tested in a sterile conference room produces different (and less reliable) reactions than one tested in the environment where the customer would actually use the product ^{sprint just-enough}.

If you are building a mobile app for warehouse workers, test it in a warehouse. If you are building a tool for doctors, test it in a clinic between appointments. Context triggers memories, surfaces constraints, and introduces the distractions and pressures that shape real behavior. A doctor who says "this looks useful" in a quiet meeting room might say "I'd never have time for this" when standing between exam rooms with a buzzing pager.

When real-environment testing is not feasible, bring context into the test room. Show photos of the real environment. Ask participants to describe their last real experience with the problem before introducing the prototype. Prime the contextual frame so their reactions are grounded in reality, not abstraction.

Connecting Prototyping to Continuous Discovery

The design sprint is a powerful intervention, but it is fundamentally episodic — a five-day event that produces a burst of learning. Teresa Torres argues that prototyping must become a continuous habit, not a special occasion ^cdh.

In continuous discovery, the product trio runs small tests every week as part of their regular workflow. These are not full sprints. They are assumption tests — lightweight experiments designed to test the riskiest assumption behind the team's current best idea. A prototype might be a single screen, a fake door test, a Wizard of Oz simulation, or a concierge version of a feature. The point is to maintain a steady cadence of learning rather than alternating between long build cycles and occasional research sprints.

See Assumption Testing for a step-by-step guide to identifying and testing assumptions.

Torres describes live prototypes as a bridge between discovery and delivery ^cdh. A live prototype is a real (but limited) version of a feature shipped to a small group of users. It is not a beta test — it is a research instrument. The team watches how the small group uses it, gathers feedback, and iterates before rolling out to everyone. This approach embeds prototyping into the delivery cycle itself, rather than treating it as a separate pre-build activity.

When to Sprint vs. When to Use Continuous Discovery

The sprint and continuous discovery are not competing approaches. They address different situations:

Use a sprint when:

• You face a big, ambiguous problem and need to rapidly converge on a direction
• The team is stuck in debate and needs a structured process to break the deadlock
• You are entering a new market or exploring a fundamentally new product concept
• Stakeholder alignment is low and you need shared evidence to move forward

Use continuous discovery when:

• You have an established product and a steady stream of customers to learn from
• You need to maintain weekly learning cadence rather than episodic bursts
• The questions are smaller and more focused: "Which version of this feature works better?" rather than "What should we build?"
• You want to integrate research into the delivery rhythm rather than treating it as a separate phase

In practice, mature teams use both. They run occasional sprints for big strategic questions and maintain continuous discovery habits for ongoing product evolution. The sprint provides the breakthrough; continuous discovery prevents the team from drifting back into assumption-driven building.

Common Prototyping Mistakes

Building too much. The most frequent mistake. If your prototype took more than a day, you almost certainly included things that are not being tested. Strip it down.

Testing with colleagues instead of real customers. Internal feedback has its place, but it cannot substitute for the reactions of people who actually have the problem. Colleagues know too much and care too little about the real use case.

Ignoring the opening scene. How a customer arrives at your product shapes their entire experience. A prototype that starts on the home screen misses the context of discovery — the Google search, the friend's recommendation, the email link. Include the entry point ^sprint.

Treating negative results as failure. A prototype that customers reject has succeeded — it saved you from building the wrong thing. The only failed test is one that produces no learning.

Skipping the debrief. The test is not over when the last customer leaves. The team must synthesize what they saw while it is fresh. The pattern-finding session after the interviews is where insight crystallizes.