How To Build The Smallest Version Of Your Idea

In 1971, Bill Bowerman was the track coach at the University of Oregon and one of the two founders of a small shoe company, Blue Ribbon Sports, that had just started selling shoes under a new brand name: Nike.

Oregon's track was being switched to an artificial surface, and Bowerman wanted a running shoe without spikes that could grip on the new track, on grass, and on bark dust, while staying as light as possible. He was so focused on the problem that his wife, Barbara, later said he couldn't think about anything else.

One morning at breakfast, Barbara was making waffles. As one came out of the iron, Bowerman looked at the grid pattern and said that if you turned it upside down, so the waffle part touched the track, it might work.

He got up from the table, went to his workshop, and came back with the chemicals to make liquid urethane. He poured it straight into the family waffle iron, a wedding present the couple had owned for 35 years. The iron glued itself shut and was ruined.

But the idea worked. Bowerman kept experimenting, and by November 1971, Oregon's cross-country team was wearing early versions of the waffle sole when it won the national championship. Nike released the Oregon Waffle in 1973, and in 1974 came the Waffle Trainer, Nike's first big hit and its most popular running shoe.

Barbara threw the ruined waffle iron away. Decades later, it was dug up from the family's property, and it's now kept at Nike's headquarters.

Bowerman didn't build a factory to test his idea, design a full shoe line, or hire anyone. He used what was sitting on his kitchen counter to make the smallest thing that could answer his question: would this pattern grip?

If you've tested your idea the way we covered in Vol. 2 and found real people who want it, you're probably facing the next question now. What do you actually build? It's tempting to imagine the finished version: the full website, the app, the complete course, the polished product with every feature you've ever thought of.

That version feels like the real thing, and anything less feels unprofessional. So people spend months, and often their savings, building it before a single customer uses it. Many of them find out too late that customers wanted something different from what they built.

This issue is about the other way: figuring out the smallest version of your idea that still delivers what people want, building it quickly and cheaply with what you already have, and then letting real customers show you what to build next.

The usual name for the smallest version of an idea is a minimum viable product, or MVP. The term was coined around 2001 by the entrepreneur Frank Robinson, and it was made famous about a decade later by Eric Ries, whose work is the subject of the next section.

The phrase has two halves, and both matter. Minimum means you strip it down to the least you can build. Viable means it still actually works and delivers the main value people want.

Most mistakes come from forgetting one half or the other. Some people forget "minimum" and build far too much. Others forget "viable" and launch something so broken or bare that nobody gets any value from it, then conclude that nobody wants the idea.

So here's a plain definition: the smallest version of your idea is the simplest thing you can build that delivers the core value to real people, so you can learn what works before you spend more.

Think of it as a focused version of your idea rather than a cheap one. It does one thing, and it does that one thing well enough that people would use it again.

This picks up where Vol. 2 left off. Vol. 2 was about finding out whether people want your idea at all, using conversations, a page with a price, and early commitments. Once you have that evidence, the smallest version is the first real product you put in their hands.

In 2004, Eric Ries was the chief technology officer of a new company called IMVU. The idea was a 3D avatar chat program, and the founders were sure about one thing: it had to work as an add-on to the instant messaging programs people already used, like AOL Instant Messenger.

That way, customers could bring their existing friends along without switching to a new program. The team agreed to a hard deadline of six months to launch, and Ries built the add-on to work with more than a dozen different instant messaging networks.

When they finally launched, almost nobody used it. So they brought people into the office to try it and watched. The customers enjoyed the avatars, but they didn't want to use the add-on with their existing friends. They kept asking how to add the interesting strangers they met to their buddy lists.

When the team explained that the whole point was to use their regular buddy list, customers looked at them as if they were crazy. They already ran several instant messaging programs and didn't mind adding one more. Ries later wrote that he had committed the biggest waste of all: building a product that customers refused to use.

The question that bothered him afterward was simple. If they could have learned all of that from customers without building a dozen network connections, why had it taken six months? IMVU changed course, built what customers actually wanted, and became a successful company. And Ries turned what he learned into a book, The Lean Startup, published in 2011.

Ries defined the minimum viable product as the version of a new product that lets a team collect the maximum amount of validated learning about customers with the least effort.

"Validated learning" is his term for what you find out by watching what real customers actually do, as opposed to what you assume or what they say. The point of the smallest version is to learn as much as possible, as fast and cheaply as possible.

The core of the book is a loop with three steps. Build the smallest thing that can test an idea. Measure how real customers use it. Learn from the results, then decide what to build next. Then you go around the loop again.

Ries argued that the speed of this loop is what matters most. A team that goes around it every two weeks will learn far more in a year than a team that spends six months building before anyone sees the product.

After each turn of the loop, you make a decision. If what you're learning shows your idea is working, you persevere and keep improving it. If it shows a key part of your idea is wrong, you pivot: change one important piece, like the customer, the problem you're solving, or the way you deliver it, while keeping what you've learned. IMVU's move from an add-on to a stand-alone network was a pivot.

The rest of this issue follows the same loop: find the core of your idea, build the smallest version of it, measure what happens, and decide what comes next.

The hardest part of building small is deciding what to leave out. Most ideas come with a long list of features, and every one of them seems important. The way through is to find the one thing your idea must do well, the core value from Vol. 1, and cut almost everything else.

Instagram is a good example. It started as an app called Burbn, built by Kevin Systrom and later Mike Krieger. Burbn let people check in at locations, make plans, earn points, and post photos, along with a long list of other features.

It was cluttered, and the founders weren't happy with it. When they looked at how people actually used the app, they noticed that almost nobody used the check-in features. What people were doing was posting and sharing photos.

So they cut everything except photos, comments, and likes, and added a small set of filters to make phone photos look better. The new app, Instagram, launched in October 2010 and signed up about 25,000 people on its first day.

To find your own core, ask a few questions. If your product could only do one thing, what would it be? Which part of your idea did people in your Vol. 2 conversations get most excited about, or pay for?

Which features would you add only because they seem expected, not because anyone asked for them? Write down the one thing, then look at every other feature and ask whether the first version can work without it. Usually it can.

Once you know the core, there are a handful of ways to build it quickly and cheaply. Most of them involve doing things that won't work forever, and that's the point.

In 2013, four Stanford students, Tony Xu, Stanley Tang, Andy Fang, and Evan Moore, wanted to find out whether people in Palo Alto would pay for food delivery from restaurants that didn't deliver. In one afternoon, they built a basic website called PaloAltoDelivery.com.

It had PDF copies of local restaurant menus they found online, and a phone number at the bottom that rang their own cell phones.

Their first call was someone ordering Thai food. They drove to the restaurant, picked it up, and delivered it themselves.

For a while, they did everything by hand: they answered every call, used Square to charge customers, and tracked orders in a shared Google document because they didn't have a dispatch system yet The company became DoorDash.

Doing it by hand means delivering the value yourself, before you build any system to do it automatically. It's slow and doesn't scale, but it lets you serve real customers right away and learn exactly what they need.

When Andrew Mason started Groupon in 2008, the team didn't build a shopping website. They took a WordPress blog, put the Groupon name on it, and posted a new deal every day.

When people bought a deal, the team created PDF coupons and emailed them out. The first deal was for a pizza place in the same building as their Chicago office, and they sold about 20 coupons.

Today you can do the same with website builders, payment links, email tools, scheduling apps, spreadsheets, and online forms. Most first versions can be pieced together from tools that already exist, without writing any code.

When Jeff Bezos started Amazon, he wanted to build an online store that sold everything. He didn't start that way. Amazon launched in 1995 selling only books.

Starting with one narrow category let the company learn how online shopping, shipping, and customer service worked before taking on anything bigger. You can do the same: serve one type of customer, in one place, with one product, before expanding.

Bowerman's waffle iron is the example here. If your idea is a physical product, the first version doesn't need to come from a factory.

It can be handmade, 3D-printed, assembled from parts of other products, or made in small batches in your kitchen or garage. It only needs to be good enough to show whether the core idea works.

One note on doing things by hand: be truthful with customers about what they're getting. It's fine if your service is run by a person with a spreadsheet instead of software. It's not fine to promise features or results you can't deliver yet.

Here's how those approaches translate to the most common kinds of ideas, each with a real example of a company that started that way.

A service

Like coaching, cleaning, consulting, styling, or tutoring. The smallest version is you delivering it yourself to a handful of customers, with a simple way to book and a payment link.

Before building a website, Jennifer Hyman and Jennifer Fleiss, two Harvard Business School students, tested their idea for renting designer dresses by setting up a pop-up shop on Harvard's campus in April 2009, where students could try on dresses and rent them on the spot.

They bought the dresses at retail and ran trials at Harvard and then Yale to answer one question: would women actually rent dresses? The company became Rent the Runway.

A digital product

Like a guide, e-book, template, or course. The smallest version is one focused piece, a single e-book or a handful of recorded lessons, sold through a simple checkout page to people who signed up to hear about it.

In 2012, a designer named Nathan Barry spent about three months writing an e-book called The App Design Handbook, while building a list of people who wanted to know when it came out. When he launched it to that list of about 800 people, he made more than $12,000 in the first day.

Instead of building a course platform or a membership first, he wrote one book. Barry later founded ConvertKit, now called Kit.

Software or an app

The smallest version is often no software at all: you do the work by hand for a few customers, or piece it together with no-code tools, before writing any code. Manuel Rosso's company, Food on the Table, wanted to build software that created weekly meal plans and grocery lists based on what was on sale at a family's local store.

Instead of building it, the team started with a single customer at a single grocery store in Austin, Texas, and gave her what they called the concierge treatment, putting together her recipes and shopping list in person.

They added customers one at a time, and only built the software after they understood what customers needed. Food on the Table eventually grew to more than 1.5 million registered users.

A physical product

The smallest version is a handmade or small-batch prototype you can put in people's hands, or a pre-order before you buy inventory. Sara Blakely started Spanx after cutting the feet off a pair of control-top pantyhose to wear under white pants.

She kept her day job selling office equipment, put $5,000 of her savings into the business, and tested her prototypes on real women, including her mom, her grandmother, and her friends. She launched with one product, footless pantyhose, in 2000.

A community or membership

The smallest version is a group chat and regular calls with a small founding group, led by you, the way Marcus does in section 09. Vol. 2's section on testing ideas where the product is other people covers how to start one.

There's a line on the other side too. If your smallest version is so bare or so broken that it doesn't deliver the core value, you won't learn anything useful from it. People will stop using it, and you won't know whether that's because they don't want the idea or because your version didn't work.

Look at what the examples in this issue got right. DoorDash's website was crude, but the food still showed up hot at the customer's door. Groupon's blog was basic, but people still got a real discount at a real restaurant.

Instagram had very few features, but taking a good-looking photo and sharing it with friends was fast and easy. Each one was rough everywhere except the core, and the core worked well.

So the rule is to cut everything you can around the core, but don't cut the core itself. Make the main thing work well enough that a customer who wanted it would come back for it again. The extra features, the polish, the design, and the automation can all come later.

Once real people are using your smallest version, the measure and learn steps of Ries's loop begin. The most useful things to watch are what people do, more than what they say:

Those answers tell you what to do next. If people use it, come back, and pay, you persevere and start improving it. The best guide to what to build next is usually the thing that's stopping you from serving more customers well.

DoorDash eventually had to hire drivers and build a dispatch system because the founders couldn't deliver every order themselves anymore. That's a good reason to build. Adding a feature because it would be nice, or because a competitor has it, usually isn't.

If people try it once and don't come back, or never pay, it's time to look closely at what you're learning and consider a pivot, the way IMVU did. Change one important piece, like who it's for, what problem it solves, or how it's delivered, and test again with a new smallest version.

The opposite mistake is building and spending too much before customers are ready for it, and the research suggests it's one of the most damaging mistakes a young business can make.

In 2011, a research project called the Startup Genome studied more than 3,200 fast-growing technology startups. It found that 70 percent of them had scaled prematurely in some way, meaning they had grown one part of the business ahead of the others: hiring a big team, spending heavily to attract customers, raising a lot of money, or building out the product, before they had customers who needed it.

One of the examples they gave was adding "nice to have" features. The researchers concluded that premature scaling was the most common reason the startups in their data failed, and estimated that 74 percent of high-growth internet startups fail because of it.

Startups that grew in step with their customers grew about 20 times faster than those that scaled too early.

The Startup Genome study looked at technology startups, but the lesson holds for almost any business.

A bakery that signs a five-year lease on a big storefront before it knows what sells, a coach who spends months building an online course before working with a single client, and a product company that orders 10,000 units before selling 100 are all making the same mistake.

They're betting everything on a finished version of an idea that customers haven't shaped yet.

In Vol. 2, we followed Marcus, the real estate agent who wanted to start a paid community for new agents. His first test failed, so he changed the offer to an eight-week small-group program focused on getting a first three deals, ran it by hand on video calls, and ended with three people asking to keep meeting monthly and offering to pay for it. Here's what he does next.

He finds the core. Marcus has a long list of ideas for the community: an app, a library of training videos, a lead-sharing board, in-person events, guest speakers, and a certification program. He goes back to what people actually paid for and asked to continue. It was one thing: a small group of new agents getting real help from someone experienced, on a regular schedule. That's the core.

He builds the smallest version. Everything else goes on a list for later. The first version is a monthly membership at $40 with two things in it: a group video call every other week, led by him, and a group chat where members can ask questions between calls. He uses tools that already exist, a video calling app, a free group chat, and a payment link, and he sets it all up in an afternoon.

He measures. The three members from the program join, and they bring four more agents they know. Over the first three months, Marcus watches what people do. Attendance on the calls stays high. Most of the activity in the chat is people asking the same few questions: how to price a listing, what to say at an open house, how to follow up with a lead.

He learns, and builds the next piece. The repeated questions tell Marcus what to build next. He doesn't build an app or plan events. He records short answers to the five most common questions and pins them in the chat. That takes him a weekend. Members use them constantly, and the time he spends answering the same questions drops.

He keeps going around the loop. At the end of six months, he has 18 paying members, almost all of whom have renewed every month. Some of the ideas on his original list, like the app and the certification program, never got built, because nobody asked for them. Some things he never would have thought of, like the pinned answers, turned out to matter most.