The big buzzword these days seems to be MVP, meaning Minimum Viable Product. It’s a reference to the approach to product development described by Eric Ries in his book The Lean Startup. However, while I’ve been hearing and seeing the term MVP a lot, I’ve almost never seen anyone executing the process that Eric Ries describes.
More often than not, what is called MVP is what I call MPP, or Maximum Possible Product. The word Possible has a double meaning:
- Maximum Possible – “Deliver as much of the product we have described given these constraints.” The MPP starts with at least a fairly well defined list of features, usually with screen diagrams and workflows and the project is expected to deliver as much of what has been defined as possible before a certain deadline or budget.
- Possible Product – “We are confident that people want this.” The sponsor(s) or owner(s) is sure that the product, as defined above, will be worth the investment. This confidence may be based on focus groups, industry research, validation with experts or gut instinct.
What’s wrong with this? Nothing. This is an acceptable way to develop products and it’s how many of the products and systems we use today were built. However, it’s not the process that Eric describes, at least as I understand it, and shouldn’t be referred to as the Minimum Viable Product.
Eric Ries has defined the MVP as follows:
“[the] version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort”
Later he simplified it to:
“The smallest thing you can build that lets you quickly make it around the build/measure/learn loop”
The key difference in Ries’ MVP is you approach building the product as a feedback loop that allows you to learn. Developing an MVP requires testing assumptions and evaluating options early and frequently, and changing course when needed. This often means getting something in front of users as quickly as possible, and relying on the information you gather from these “tests” to guide your next steps. What is minimum and viable is not defined up front, oris at least considered flexible, and what you learn about your customers, users, product and idea are as valuable as what you build.
The MPP on the other hand often follows a more traditional process, although it may be disguised in an incremental or Agile development approach. There is usually some consultation with users or customers at the beginning, along with experts such as power users, industry experts, usability specialists and so on. The product is built based on this information, and users don’t see the product until some or most of the features defined as the minimum are complete. The emphasis is delivering the features that were requested, not on learning. The “minimum” is usually describing the resources or time available, not the product.
So as I said at the start, while I hear and see “MVP” used very often, very few organisations are using the method that Eric Ries described. Why is that? One, perhaps obvious, answer is that most people just don’t realise that there is a difference between the MVP and simply doing as much as you can before a deadline. However, I have seen that even when people have a solid understanding of the MVP method, they still end up doing an MPP instead. Why?
Simply put, because the MVP method is difficult. There are cultural, technical, organisational and personal challenges that have to be addressed for the methodology be executed. Over the next few blog posts I’m going to explain some of the more common barriers that I’ve seen (Organizational is here, Personal is here, technical is coming), and where I can I’ll try to provide some ideas on how to overcome them.