Although a lot of what I write is about building a startup and developing the next generation of apps, I have over the years done a lot of work in the corporate world either as part of a contract or as a full-time employee.
One thing I’ve always found interesting is how advances in development practices filter into these organizations, and what often goes wrong! I’ve seen this happen with agile development practices and I can see this starting to happen with lean startup methods, and especially with the minimum viable product.
What is a Minimum Viable Product (MVP)
I think the MVP is one of the first big messages that people take away from lean. Its starting to find its way into agile practices like scrum, and is fast becoming part of the software development vernacular.
An MVP is essentially a way to learn about a market in a very real way, very quickly. This means an MVP can take many forms, from a finished product, to a single landing page on the internet. There are numerous examples of MVPs out there, to name a few:
- Dropbox validating its concept with a simple website and video.
- Buffer validating its business model with a simple landing page and click-through to pricing models.
- Practically every KickStarter product is an MVP – the product is validated before building even begins.
Almost everything written about MVPs is from the perspective of a brand new startup, as startups are always operating in an environment of extreme uncertainty. But the principles apply equally when running projects in large corporate environments. The fact of the matter is that practically all innovative software projects are running in an environment of uncertainty, whether your customers are consumers, other businesses or internal staff.
In order to leverage a successful MVP there are a few things that need to be kept in mind:
1. An MVP should have an hypothesis
The crooks of an MVP is that you’re trying to answer a question. That question might be:
- How much would people be willing to pay for your product?
- Can I reach my target customers?
- Will feature x get used?
You need to have defined an hypothesis that your mvp is testing before building and launching it. If you don’t have an hypothesis, its difficult to really learn anything that you can rely on.
2. An MVP is designed only to test the hypothesis
Once you have your hypothesis its time to define your MVP – whats important here is that your MVP is designed with the smallest feature set possible to test that hypothesis.
This is always the most difficult for developers to stick to – as developers we like to build products and features, we like to build something we can be proud of. There’s a great quote by Reid Hoffman (co-founder of twitter) that if “you’re not embarrassed of the first version of your product, you’ve released too late”.
So strip away as much as possible – this will enable you to deliver sooner and therefore learn more quickly, which ultimately means you spend more time developing the things that people actually want, rather than trying to guess. So remember:
- You don’t need a working product to find out what people are willing to pay, or if you can reach them.
- You don’t need a fully functioning feature, to find out if it will get used.
- You can launch with a minimal feature set, and build on it post go-live.
3. An MVP is not an Half-Arsed Product (HAP)
I originally tweeted about this a few weeks ago:
Is it a MVP (Minimum Viable Product) or an HAP (Half Arsed Product)? A distinction that is often ignored!!!
— Matthew Whetton (@codenutz) March 27, 2014
One thing I see happening is a tendency to think of an MVP as a half-finished or half-arsed product – and this couldn’t be further from the truth. Just because an MVP doesn’t represent a fully functioning product, doesn’t mean that its half-finished. When an MVP is released it is complete and ready for the purpose it was designed for – to learn.
You could argue that all software products are half-finished because we’re continually adding features and improving them, but in no case should we release something that doesn’t suit its needs under the guise of an MVP – thats just an excuse for not finishing what you’re doing!
When developing a new product its important to find the minimum feature set that will allow you discover what you need. In some cases this means build very little such as a landing page, but in other cases this means building a full product. Whats important to remember is that the features we decide to include are solid and work as expected…we don’t get half-way through developing and think ‘sod it, lets ship this and call it an MVP’!
A lot of the methods used by lean startups allow them to learn more effectively – this kind of learning is something that many product development projects could do with. At first glance it seems that they’re only really applicable to startups, but the reality is that they have much wider applications. The one thing we have to be really careful to do is understand these tactics and leverage them in the correct way, otherwise we could end up throwing the lean baby out with the bath water. (In many cases this has happened / is happening with agile)
The MVP is not the only facet of the lean startup methodology, but its is an important one that can deliver tremendous value. Its important that we truly understand the point of it, and leverage it in the correct way.
What are your experiences with leanb methodologies? Are you using them in a startup environment, or maybe you’re seeing them emerge in the corporate world?