In this 2nd installment of our agile series, we explore the Minimum Viable Product. This is one of the better known agile concepts but in practice we see it is still often misunderstood. With this blogpost, Tom Reed hopes to fix that.
What’s an MVP? What’s the point of one? I’ve heard these questions often and Google may not provide the clear cut answers you’re looking for.
Recently we re-worked our website from the ground up and practicing what we preach, we started out with an MVP version. Of course it has evolved since - this is exactly the point of an MVP.
Allow me to clarify.
At its core, the MVP is defined as “that version of a new product a team uses to collect the maximum amount of validated learning about customers with the least effort.” (Ries, Eric (August 3, 2009). "Minimum Viable Product: a guide")
Simply put this boils down to a product with the minimal amount of ‘features’ that allow you to gather useful user feedback fast. The MVP is the first version of your product you feel can gather the feedback you need to validate your product assumptions. Trusting that the users will appreciate the product for what it is and provide feedback whilst you gather data on their behaviour. Letting you know what they would like to see (more of) in future releases of your product.
The MVP is defined as “that version of a new product a team uses to collect the maximum amount of validated learning about customers with the least effort.
The important thing to keep in mind here is that the MVP is the first in a series of frequent releases of your product, the stepping stone towards the product you eventually want.
Whether you provide this release via public/private beta, open source or as a full product is up to you.
The above may sound relatively straightforward, but as soon as you get a group of stakeholders together in a boardroom the use of subjective terms like ‘viable’ and ‘minimal’ tend to cloud that definition. Minimal can mean something entirely different to a developer and a marketer.
You may find that some people struggle with the term MVP and you may not have the time to give an in-depth intro. What might help get your stakeholders on the same page is moving from MVP to an ‘earliest testable’ – ‘earliest useable’ – ‘earliest lovable’ format. This avoids discussion on minimal and viable. At the same time it clearly shows an MVP is not meant to be a single release and enables you to explicitly state which features would be part of which release, pending user feedback.
The ‘earliest testable’ is the first product a user can use and provide feedback on.
Think of a washboard for example. It should leave your clothes cleaner than they were before applying the washboard solution. It’s a step in the right direction but I’m sure the user will have plenty of feedback on how to improve the product.
The earliest useable is the product ‘early adopters’ would gladly use, it’s a definite improvement on their current situation. The HTC Vive (or the Oculus Rift) is an excellent example of this. It offers the users something solid and unique, but its high cost and low resolution, in addition to its lacking media library squarely keeps it from being fully mainstream.
The earliest lovable is the first release customers will love and convince people to buy. No one would confuse a washboard or the HTC Vive for an earliest lovable product but something like the first iPhone would fit this category. A lot of people (rightly) loved it back in the day, but if you pick one up today you’d be surprised at how much the newer generations have improved.
So how might MVP, Earliest Testable, Useable and Lovable fit in your product cycle?
The below image inspired by Henrik Kniberg (who has written an excellent blog on this subject) attempts to display the difference between how sceptics perceive agile/MVP/iterative releasing and how agile iterative product development should actually work using the metaphor of car production.
The point of an MVP is figuring out what your customer wants as early as possible during your iterative process. And I mean really figuring out what they want, not just what they might say they want. So when a customer asks for a car, try figuring out why they want a car.
Maybe they just don’t like walking 20 minutes to work every morning and when they think ‘faster transport’ their mind jumps to a car. This gives us something to work with.
Once this information becomes clear you can define the MVP as ‘transport faster than walking’ and start with a skateboard as the ‘earliest testable’ release. You are not selling the user a skateboard, you are simply saying ‘play around with this and let us know what you think whilst we continue working towards the best transportation for you’.
Each new step uses the same user feedback loop to improve until you end up with the perfect user pleasing product. Not a 5-door sedan, but a convertible because we learned the customer loves the feeling of wind in their hair.
The idea here is that somewhere halfway through the development process we’ve already learned enough about the requirements that we are able to more efficiently provide the optimal product, saving us precious resources on ‘dead-end’ or unrequired features.
Now, whilst the possibility of saving money might be a strong motivator, the fact that you are putting the product in the user’s hands, getting them invested in your development and gathering useful user data is an even larger advantage to this approach.
Before you reach your ‘lovable’ product you’ve already implemented the most common user feedback, stabilized your product, built up a roadmap and have a group of users that have been talking about your product for quite a while.
We can use our website as a quick example. After defining our perfect product, we created the epics and stories and estimated these. Like most companies, this is the point we realised it might be worth actually defining the base need we were trying to fulfil. The main focus of our website is to generate leads, which means we need to be able to (quickly) show what we do, what we’ve done, our expertise and a way for potential clients to contact us. We also need a way to hire people to fulfil the needs of prospective clients.
This gave us the features required before the website was considered ‘viable’. The features were then themselves ‘mvped’ to be as lightweight as possible. For the final MVP touch we stuck the website full of analytics in order to see how users interact with the website and gather data to improve the website on our way to our most lovable product. We haven’t forgotten about our perfect website and we are still working on it (and releasing frequently), but I’m willing to wager that the the perfect product created using customer feedback is going to be a lot better than the ‘perfect product’ we had originally envisioned during a workshop.
Hopefully this post has been able to clarify what an MVP is and what the point of one is.
To end this story in the true spirit of an MVP, feel free to let me know your feedback or if you disagree with anything I’ve written. I’ll use it for my next iteration.