This piece is inspired by Startup Edition in response to, “How do you define an MVP?”

This should sound familiar: startup creates product, ships it to their initial users (lukewarm response), iterates around the edges for months or even years, gets demoralized, and finally dies.

Why does this happen? As a community, we’ve done a great job accepting the idea that we should start by quickly building something small and putting it in front of users to see if they like it, but generally we have no clue what to do when the MVP isn’t an instant success.

We’ve been told to iterate, but what should our iterations look like? Changing the headline on the homepage? Adding a new feature? That’s the kind of incremental iteration you should do when it’s clear the product is already working well. If you want a dramatically different result, you can’t expect to get it from marginal changes.

That’s why I’m a proponent of designing the first version of your product to be thrown away. This may sound a bit extreme, and it certainly won’t work for all use cases, but I think far more startups should try this approach out than currently are.

There are several reasons why it’s beneficial to build a disposable MVP, but the most important is that once you’ve spent effort building something, you’ll irrationally cling to it longer than you should. Psychologists refer to this tendency as loss aversion. By building your MVP in such a manner that you’re forced to throw it away, it increases the chances that you actually will.

Why is it better to start over from scratch? Because usually the key to success is looking at the problem from a different angle. This is usually easy to fix design-wise, but often requires throwing away a lot of code. Let me show you what I mean:

Case Study: remind101

When we were in college my friend Brett realized that it would be awesome to get reminders via text message that assignments for class were due. So he and his brother started a company, raised some money from friends and family, and hired a dev shop to build an web-app that would let you input your syllabus and schedule text message reminders.

They launched at Michigan State, and got a couple thousand people signed up, but growth flatlined quickly. The problem was that students didn’t want to sit down at the beginning of the semester and type their whole syllabus into this app. It’s just too much work.

For the next year, they struggled to recruit new users, trying to do partnerships with schools and signing up teachers, but progress was slow. They iterated on the product around the edges, but didn’t make any major changes until summer of 2011, when they were accepted into imagineK12 (YC for education startups).

In talking to the iK12 partners, they quickly realized they had to start over from scratch. Brett went out and spoke with over 200 teachers about problems in their classroom, and figured out a simple shift in how they designed the product would make a world of difference.

Instead of chaining students and teachers to a syllabus, they realized they should just open up a one-to-many line of communication between teachers and students via text. The reason why many teachers don’t text students already is that 1) it’s a pain to mass-text 30 numbers, and 2) you don’t really want all your students to have your personal phone number, and vice versa.

Brett’s co-founder (and brother) David quickly got to work hacking together a new version of the product (goodbye outsourced dev shop) and within a few weeks they re-launched to great success. Since then, they’ve scaled to millions of teachers, parents, and students all over the world and raised money from the best investors in Silicon Valley.

The Moral of the Story

I think Brett and David could have saved a lot of time, money, and emotional stress by pivoting sooner, and letting go of their first product earlier. Problem is, they were chained to the sunk costs of spending a bunch of cash to have the first product built.

The same thing happens even if you build your product in-house. If you invest a lot of energy into making a well-tested, highly polished version 1, you’ll be significantly more reluctant to throw it away and start from scratch.

This is why MVPs are supposed to be minimal: so you don’t waste a lot of time and energy building something people don’t want. My argument here is essentially that you should not only make your MVP minimal, it should also be disposable, because it’s a good thing to re-write your app from scratch a lot when you’re starting out.

This is true not just from a growth / business perspective, but also from a technical point of view. Here’s a quote from Paul Graham’s classic “Holding a Program In One’s Head

Keep rewriting your program. Rewriting a program often yields a cleaner design. But it would have advantages even if it didn’t: you have to understand a program completely to rewrite it, so there is no better way to get one loaded into your head.

The key to making this work is to learn techniques for building products as quickly as possible. I could write a whole follow-up blog post about this, but here’s a quick list of principles that have helped me build products faster:

  1. Become a generalist. If one person can design and code a product from scratch they can move much faster.
  2. Take shortcuts with code, even if it pains you. Don’t write any tests, use a crappy database schema, etc. Remember, the point is that you will throw this away. It’s something in between a prototype and a product.
  3. Sacrifice visual design for usability / UX design.
  4. Stick with what you know - limit your use of fancy new technologies to only the most mission-critical. They’ll slow you down.

I hope this helps you think about decisions you’re making at your startup or side project right now. If you’re not sure what to do next, consider taking a week to re-build your product from scratch from a slightly different point of view.

Just remember - even if what you make is a hit - all the code gets thrown away ;)


Read more on this topic from an awesome group of entrepreneurs at Startup Edition.