I really connected with many of the ideas presented in The Lean Startup when I read it last year. While it’s had its critics, there are few business books I’ve read that take such an engineering-based approach to the process of bringing a business to life, and many of the principles it encourages have strong parallels to techniques I’ve used in software development over the years.

  • The strong orientation toward working closely with customers mirrors the Product Owner role in the Scrum process.
  • Delivery of working software is the primary measure of progress for agile software projects because it’s objective and gives stakeholders an opportunity to compare their expectations, which might have been poorly elaborated in the initial requirements, to the real-world result. This correlates closely with the lean ideas of using validated learning and using iteration to refine the business concept.
  • Modern development methodologies of all stripes use an iterative approach to building software with regular checkpoints for evaluation. The goal is to learn more about the real requirements of the product as its being developed and to achieve a better fit to the audience’s expectations. Lean startups are constantly experimenting and using metrics gathered from techniques like A/B testing to determine what changes deliver better results.

The paradigm also promotes the use of the Minimum Viable Product (MVP) which refers to an experiment or prototype application designed to test the most basic assumptions about a business on customers and to gather evidence to support future product development decisions. Like many of the other concepts from the book, it’s the sort of thing that’s very approachable to almost anyone who’s been involved in product development in the past, but it’s that same approachability that’s caused it to be misunderstood and abused. There are a lot of terms in the definition above that themselves require definition.

Founders work on a product out of a sense of excitement and a need to build something the world won’t be able to live without. Each will want to put his best foot forward from the start with an initial release that represents his vision. But this is not a release. It’s a stick figure outline of the eventual concept. You keep things minimal and crappy at this stage in order to force as much learning and as many important decisions as possible early in the process when it’s cheap to do so. If every feature is critical from the beginning, you’re unlikely to realize the benefits of the tool.
Not valuable. Viable. The meaning of that word will largely depend on what you’re trying to test, but if you can build a prototype completely out of duct tape and used chewing gum that doesn’t fall over and tests your assumptions, go ahead and do that.
Not titlecased because it’s the least important part of the definition. Most people wouldn’t even recognize a true MVP as a finished product. If you’re not a little embarrassed by it, you probably spent too much time on it.
Every high school science student knows that an experiment has to have a hypothesis, a method, results, and conclusions. If any of these things is missing at the end, you didn’t conduct an experiment, you just tried something.
Most developers can tell you that a prototype is a requirements gathering tool. It’s not a demo or a proof of concept or even a rough first version. It’s meant to be put in front of a customer under observation in order to see how it’s used and then thrown away. Your MVP should be a one-night stand, not a life partner.
The most basic assumption of any business is: People will pay money for this. If you’re able to formulate and answer other questions, you should do so, but don’t let these obscure the primary question of value.
By this time, you should have some idea who you’re targeting with your product. (If your market is “everyone with money” you might want to think a little harder about it since very few things are for everyone.) You need to try to bring in a representative sampling of that group in any way you can. Friends and family are fine, but if everyone using your MVP is someone you knew before, you’re at risk of bias in your feedback.
The best evidence will be quantifiable, not open to interpretation, and based on observed, not theoretical, behavior. If you’re asking users how much they would pay or whether they might sign up, you’re going to get a lot of false positive answers that won’t correlate to real users or money down the line.

The most important take-away from all of this should be that no one can tell you what the MV in MVP should be. That’s for the team to decide.

Bringing all of these things together to produce a true MVP is a balancing act and requires a great deal of discipline from the whole team, but it’s the difference between making a long series of small, short-term bets over the entire product development cycle instead of one all-or-nothing bet at the beginning of the project and finding out whether it pays off at the end.