Prototype Day
It's Thursday. In a five-day Design Sprint, the team spends Monday to Wednesday arguing toward one idea, Thursday you build, Friday a real customer tests it. So by now the team has spent three days arguing toward one direction, and Wednesday's Decide sequence turned the winning sketch into a storyboard: the shot-by-shot plan of the one customer journey you're going to test. Now you have one day to put something real enough in front of a customer that Friday's test answers your question.
That question is the whole reason any of this exists. The one thing you need to find out before you spend real money. Will a customer actually use this?
One day. Not one sprint. Not one quarter. One day.
So you don't build the product. You build a fake front.
Jake Knapp's word for it in Sprint is blunt: fake it. A realistic front with a hollow back. The customer-facing surface looks finished, and behind it there's nothing. No database, no logic, no engineering, no working anything. Just enough of a front to answer your question, and not one ounce more.
This is the move on prototype day, and you'll reach for it far more often than the full five-day sprint. You can run a fake front on a Thursday inside a sprint, or on a Tuesday afternoon when a meeting won't stop circling a feature nobody has tested. Same skill either way.
Why a fake front beats a real thing
Building the real thing is the most expensive way to learn whether anyone wants it. If you read What is an MVE? over in the discovery part, this is the same idea with a sharper tool. An MVE, a minimum viable experience, is the smallest experience you put in front of a real customer to learn something. A fake front is one of the cleanest ways to make that experience feel real without building the product behind it.
Here's why faking it works. A customer can't see your codebase. They can't see your database. They see a screen, a flow, a thing they tap through, and they react to what's in front of them. If the front is convincing, the reaction is honest, and the honest reaction is the only thing you came for.
So you spend your one day on the part the customer touches. The part they don't touch costs you zero, which is exactly how a single day is enough.
The same move goes by a second name, and once you see it the principle sticks. Wizard of Oz. The man-behind-the-curtain trick. You build a front and operate it by hand, behind the curtain, without the user knowing. The customer types a request to your "AI assistant," and the assistant is a person typing back fast. It tests whether the thing works for them without anyone building the thing. Same principle as the sprint's Thursday. A real-looking front, a hollow back, an honest answer.
Goldilocks quality
The trap on prototype day runs in two directions, and Knapp named the fix.
Build it too cheap and the customer doesn't believe it. They see the seams, they know it's pretend, and they stop reacting like a real user and start being polite to you. Now you're back to stated interest. A customer saying they'd use it, which is cheap talk that predicts nothing. Worth what it costs, which is nothing.
Build it too polished and two things go wrong. You don't finish in a day. And worse, you fall in love with it, because you spent real hours on it, and a thing you love is a thing you can't kill when Friday's test tells you to.
Knapp calls the target Goldilocks quality. Not too high, not too low. Just right. Real enough that a customer believes it, fake enough that you built it in a day and could throw it away that night without flinching.
That's the bar everything else aims at. Every call you make today is downstream of it.
Pick the right tool for the question
Before you build anything, answer one question. What are you actually testing? The answer picks your tool. This is the same matching logic the Lean Experiments menu runs on, because a fake front is a lean experiment, a small cheap test built to answer one question, that happens to live inside a sprint.
- Testing desirability (do they even want it?) → a clickable prototype (linked screens you can tap through, built in a design tool), a fake landing page that looks like a real product's homepage, a Wizard of Oz front. You want it real enough that they'll actually commit. Enter their email, click buy, put their name down. A click that costs them nothing tells you nothing.
- Testing usability (can they use it?) → paper, or a clickable prototype with linked screens. You want to watch where their finger hesitates.
- Testing the story (does the pitch land?) → a storyboard, a fake landing page, a short walkthrough. You're testing whether the words sell it (the headline, the promise, the way you describe what it does), not whether the buttons work.
Match the tool to the question, then pick the lowest-fidelity version of that tool that still answers it. Fidelity is just how finished and real it looks. Start low. Add fidelity only when you need more specific feedback. The line worth keeping in your head. Don't build an app, build a paper sketch of the app.
For a software flow, a fake front is usually a few stitched-together screens in a design tool (the kind where you draw the screens and link them so they tap through like a real app), real enough to move through, with the real words written in. Slides can work. A clickable file can work. Paper can work if the question is simple. The tool is whatever gets you to a believable front by end of day. The tool is never the point.
Assign the roles
A team of seven all reaching for the same file is how a day disappears. A fake front gets built in a single day the same way Knapp's sprint teams do it. Split the work into roles, then run in parallel.
Steal his roles directly. They work.
- Makers (two or more). Each maker takes a chunk of the storyboard and builds that piece: these screens, that section, this part of the flow. They work in parallel, not in sequence. Most of the team are makers.
- The stitcher (one). One person owns the master file and assembles every maker's piece into one flow, so that on Friday the customer moves through it without hitting a seam. The stitcher usually owns the design tool. This is the role that keeps a pile of parts from staying a pile of parts.
- The writer (one). Real words, everywhere. No placeholder gibberish, no "headline goes here," no "[button text]." Fake copy reads as fake and breaks the spell. The writer makes the words sound like a real product talking to a real person.
- The asset collector (one). Finds the images, the logos, the sample data, the realistic-looking content that makes a screen read as a live product instead of a wireframe. Borrows, fakes, and fills so the makers don't each stop to hunt for a placeholder photo.
- The interviewer (one). This person does not build. They write Friday's interview script and stay out of the prototype entirely, on purpose, so that tomorrow they can run the test without rooting for the thing they made. Distance is the job.
That last role is the one teams skip, and it's the one that protects the result. The person who built it can't run an honest test of it. Keep them separate.
Build one flow, not the product
One discipline makes a day enough. You build one realistic path, not the whole product.
The storyboard from Wednesday already tells you which path. It's the shot-by-shot of the one journey you're testing, the one customer moving through the one moment you decided matters. Build exactly that and nothing around it.
That means the buttons off the one path you're testing don't have to work. The settings screen doesn't have to exist. The edge cases, the error states, the second user type, the admin view. None of it gets built, because none of it is in tomorrow's test. If the customer wanders off the path, the interviewer nudges them back. You built a hallway, not a house, and the hallway is all they need to walk.
This is where teams blow the day. Somebody starts building the parts a real product would need, and by 4pm there's no testable flow because the effort got spread across everything instead of poured into the one thing. One flow. Built deep enough to believe, narrow enough to finish.
What good looks like
You'll know you nailed the fake front on Friday, not Thursday.
A real customer sits down, starts tapping, and forgets it isn't real. For twenty minutes they treat your hollow front like a live product. They try things, they get confused at the spots you were worried about, they light up at the spots you hoped they would, and not once do they say "well, if this were real, I guess I'd..." They're not imagining the product. They're using it. That's the test passing in real time.
And when it's done, you can throw it away. You spent a day, not a quarter. If Friday says the idea is wrong, you delete the file and you've lost a day, which is the cheapest tuition in product. If Friday says the idea is right, you've got a tested direction and a team that already agrees on it, and now you go build the real back behind the front you proved people want.
That's the trade a fake front buys you. An honest answer about a real product, before you pay to build one.
Credit where it's due: the prototype-day method here, the "fake it" mindset, Goldilocks quality, and the named roles are Jake Knapp's, with John Zeratsky and Braden Kowitz, from Sprint (GV / Google Ventures, 2016). What's mine is the judgment about when to reach for it outside the full sprint.