The Prototype Mindset

Eric Ries
Galleys
Published in
7 min readMar 8, 2016

I was really happy to get an early copy of Sprint: How to Solve Big Problems and Test New Ideas In Just Five Days, by three design partners at Google Ventures, Jake Knapp, John Zeratsky and Braden Kowitz. Several years ago, Jake developed the sprint, a process that allows you to quickly answer critical questions through design, prototyping, and testing ideas with customers. In a lot of ways, it’s a greatest hits of business strategy, innovation, behavior science, design thinking, and more — packaged into a battle-tested process for any team. It’s a process they use with their portfolio companies at GV, including Slack, Blue Bottle Coffee, and Foundation Medicine. Now, they’ve put all their methods into a book so that teams everywhere can start running their own sprints.

A sprint takes place over just five days. On Monday, you unpack a problem you want to solve. On Tuesday, you sketch competing solutions on paper. On Wednesday, you decide how to turn your ideas into a testable hypothesis. On Thursday, you hammer out a prototype. And on Friday, you test it with real live humans.

Jake offered to let me publish a brief excerpt from the book, and we chose one that is from one of my favorite chapters: on prototyping. The sprint offers a great way to start learning from customers who interact with your prototype, even before you start really building an MVP. Here it is, and be sure to check out the book — it’s out now and available to order everywhere.

The Prototype Mindset

A square-jawed cowboy stands outside a saloon. He adjusts his hat and squints across the dusty street, where five men in black suits sit on horseback, rifles clutched in their hands. Farther down the street, the townspeople huddle near the general store. A tumbleweed blows by. Nobody speaks, but everybody knows: There’s about to be some trouble in this town.

If you’ve ever watched an old Western movie, you’re probably familiar with this scene. Good guys in white hats, bad guys in black, plenty of melodrama. The town is often the most realistic part of the film: clapboard buildings, wooden boardwalks, and saloons with swinging doors.

Of course, those Old West scenes were never quite as real as they appeared. Sometimes, the director found an existing location that looked about right: an abandoned ghost town or a picturesque Italian village. But most films were shot on a set on some Hollywood backlot. That saloon behind the cowboy? Just a façade — an exterior wall with nothing behind it.

It makes no difference to the audience. For the few minutes we see the town, we get lost in the story. It all appears real. Whether it’s a façade or a ghost town, the illusion works.

In a sprint, Thursday is about illusion. You’ve got an idea for a great solution to a problem or question you’re tackling. But instead of taking weeks, months, or, heck, even years building that solution, you’re going to fake it. In one day, you’ll make a prototype that appears real, just like that Old West façade. And on Friday, your customers — like a movie audience — will forget their surroundings and just react.

Façades are easier to build than you might think. Let’s say you’re working on a project that will take a hundred days. And let’s say that 90 percent real is real enough to test. Simple math says it’ll take ninety days to get to that 90 percent real level, so you should be ready to test in about three months. But we’ve found that if you only build a façade, you can get to 90 percent on day one.

“Whoa, pardner,” you’re thinking. As of Thursday morning, you’ll have nothing but whiteboard drawings and paper sketches. Do we expect you to create a realistic prototype in just one day? Isn’t that impossible? It would be impossible, except that you’ve already done the difficult part on the first three days of the sprint. You created a storyboard to remove all guesswork about what to include. You made solution sketches, packed with specific text and details. And you’ve assembled the perfect team, with all the right skills to create your prototype.

Sure, you could take a longer time to build a more perfect prototype — but doing so would only slow down the learning process. That may not matter if you’re on the right path, but let’s face it — not every idea is a winner. Whether you’re taking a risk on a bold idea, or

you’re just not sure, it’s better to find out early. Wasting time on the wrong thing is a major bummer. But perhaps the biggest problem is that the longer you spend working on something, whether it’s a prototype or a real product — the more attached you’ll become, and the less likely you’ll be to take negative test results to heart. After one day, you’re receptive to feedback. After three months, you’re committed.

At the beginning, you’re in the sweet spot of all these charts. You’re not attached to your ideas yet, so if they don’t test well, you’ll be flexible enough to fix or cut them. You’re in the perfect position to take advantage of that fast curve to 90 percent real, if you limit yourselves to building a façade. No plumbing, no wiring, no structural engineering. Just a façade.

Building a façade may be uncomfortable for you and your team. To prototype your solution, you’ll need a temporary change of philosophy: from perfect to just enough, from long-term quality to temporary simulation. We call this philosophy the “prototype mindset,” and it’s made up of four simple principles.

  1. You Can Prototype Anything

This statement might sound corny, but here it is. You have to believe. If you go into Thursday with optimism and a conviction that there is some way to prototype and test your product, you will find a way. In the next chapter, we’ll talk about specific methods for prototyping hardware, software, and services. Those methods may work for you, or you may have to be resourceful and invent your own. But if you stay optimistic and adopt the prototype mindset, there is almost always a way.

  1. Prototypes Are Disposable

Don’t prototype anything you aren’t willing to throw away. Remember: This solution might not work. So don’t give in to the temptation of spending a few days or weeks getting your prototype ready. You’ll have diminishing returns on that extra work, and all the while, you’ll be falling deeper in love with a solution that could turn out to be a loser.

  1. Build Just Enough to Learn, but Not More

The prototype is meant to answer questions, so keep it focused. You don’t need a fully functional product — you just need a real-looking façade to which customers can react.

  1. The Prototype Must Appear Real

To get trustworthy results in your test on Friday, you can’t ask your customers to use their imaginations. You’ve got to show them something realistic. If you do, their reactions will be genuine.

How real is real enough? When you test your prototype on Friday, you’ll want your customers to react naturally and honestly. Show them something flimsy — a “paper prototype” made up of drawings, or a simplified wireframe of your design — and the illusion will break.

Once the illusion is broken, customers switch into feedback mode. They’ll try to be helpful and think up suggestions. In Friday’s test, customer reactions are solid gold, but their feedback is worth pennies on the dollar.

This distinction between feedback and reaction is crucial. You want to create a prototype that evokes honest reactions from your customers. You want it to be as real as possible, while sticking to your one-day timeline. As our partner Daniel Burka says, the ideal prototype should be “Goldilocks quality.” If the quality is too low, people won’t believe the prototype is a real product. If the quality is too high, you’ll be working all night and you won’t finish. You need Goldilocks quality. Not too high, not too low, but just right.

Of course, “Goldilocks quality” looks different for each product. The book includes detailed examples from five teams, prototyping everything from iPad apps to a medical clinic. As you read their stories, you’ll see how each team applies “Goldilocks quality” and the prototype mindset to their unique challenge.

This story was adapted, with permission, from the forthcoming book Sprint: How to Solve Big Problems and Test New Ideas in Just Five Days (Simon & Schuster) by Jake Knapp with John Zeratsky and Braden Kowitz. Order a copy here.

--

--

Galleys
Galleys

Published in Galleys

A home for books and authors on Medium

Eric Ries
Eric Ries

Written by Eric Ries

Trying to change how startups are built.

Responses (17)