In sports, MVP is simply, ‘Most Valuable Player’, which has spiralled off into its own meme and is now being used far beyond any sporting achievements. But you’re probably not here for that story. We’re here to talk about MVP in a digital product sense.
MVP in our world is ‘Minimum Viable Product’. We’re going to explore what it is, what it isn’t, how it may differ between groups, and how you should be a little cautious around the way you define MVP in your agency or business.
A brief history of MVP
The concept first appeared in ‘The Lean Startup’, a methodology and book by Eric Ries. He defined an MVP as the version of a new product that allows a team to collect the maximum amount of validated learning about customers, with the least amount of effort. Ultimately, this process will be the deciding factor in whether your product will be accepted by your customers, or not. It’s at this point that you can choose to go back to the drawing board (sometimes this is referred to as ‘failing fast’) or in some cases, abandoning the idea altogether.
So what form does an MVP take? Is it a digital prototype in the same way that architects build scale models? Well, that depends on which sub-definition of MVP that you follow. Because naturally, the concept has taken on a number of new guises over the years, as groups have introduced their own ‘flavours’ of the methodology. We’ll talk a little later about how an MVP and a prototype differ, but for the most part, an MVP is an actual product with some form of functionality.
That functionality may appear ‘working’ at the front-end, but perhaps it’s not built the same way at the back-end that you’d expect the final product to be. And that’s a pretty good example of how an MVP is built… for instance, a seemingly functional application may just be series of designs brought to life with tools just Figma, Adobe XD, Framer or Proto.io. Of course, these designs need to be high-res and good quality for the user (or tester subject) to believe they are using a final product, and respond accordingly.
This approach can be applied to apps, landing pages, websites, platforms or just about any digital product you can think of. There’s a lot to take in there, so here’s a nice definition I saw from a Portland-based web agency…
“An MVP is the best solution that meets the needs of the target audience with the least amount of risk – it’s the first step towards achieving your long-term vision.”
A fun way to visualise this looks at the iterative design approach. I think this diagram (below) is pretty frank, and it says to me that an MVP isn’t working through the ‘expected’ stages of a final idea, and it isn’t working through a series of seemingly random stages until you land on a final idea. Instead, it’s iterating and evolving a strong central concept through a progressive process that gets you to the final idea, and a final idea that works.
Essentially, ‘stage four’ should be an evolution of ‘stage one’. But it’s also important to note that ‘stage one’ on the bottom row does in some way deliver a solution to the user, and a solution that isn’t a million miles away from the brief. A scooter or a wheel when you ask for a car, however, doesn’t really help anyone. As cool as scooters are.
So what are the benefits of an MVP?
- Audience and product insight. By delivering an MVP to a small group of people, you are garnering feedback, responses and learnings at an early stage. A good product team should deliver something good to the user at this point, but it’s not always that simple…
- Challenges and pivots. Whilst these words may send a shiver down your spine, they’re not necessarily bad things, especially when you’re already using some form of agile methodology. Your audiences’ responses may challenge your design decisions and this may mean that you have to pivot or adjust your idea, either minutely or dramatically. So maybe ‘good’ isn’t the right word after all. A failed MVP isn’t necessarily a bad design.
- Driving down risk. Rather than looking at a pivot as a random and reactive change of direction, think of it more like a progressive and proactive refocus, one that’s based on real and trusted feedback. Making changes now is far less costly and complicated than waiting until later down the line, or even worse, once a product has been entirely built or released. (This happens! Think Amazon Fire Phone or Facebook Home.)
- Making friends early. In my experience, agile, sprint and MVP processes have made a huge difference to how quickly teams hit that collaboration sweet spot. The sprint methodologies, however you undertake them, stress huge importance on client and stakeholder involvement from day zero. This makes processes such as decision making and continuous improvement far more fluid and inclusive, and it cuts down siloing.
- Speed. It goes without saying, really. Adding an MVP to your product design journey, despite it being another step between you and final delivery, will enhance your speed to market. Unless you learn that your product really has no chance of success, the MVP process makes it easier to iterate your existing design, and redeliver. There’s also the added ‘incentive’ of having limited time to develop your MVP, which cuts down on unnecessary and often painful to and fro amongst design teams, development teams and the client.
How is an MVP different to a prototype?
Believe it or not, there is a difference, despite both being early versions of a product.
A prototype has more tangibility than an MVP, at least to a design and development team. You should be able to walk into a studio with a prototype, say “We need to build this” and for people to have a good understanding of what needs to be built and how to build it. A prototype in this context could be something as simple as a mockup, a wireframe or a more detailed and interactive piece.
An MVP is… well, we already know. But in comparison to a prototype, you can theoretically place an MVP in a potential customer’s hands, for them to be able to interact with it. In contrast, put a prototype into a customer’s hands and they may well pass it back to you and tell you to come back when it’s finished.
Anything to watch out for?
Generally, you can ‘own’ your MVP process and make it yours. But it’s important that your definition of MVP, whatever it is, is clearly communicated to your client at an early stage. With myriad versions of MVP now out there, the client may well have worked with other businesses or agencies that follow a different process. Be clear with your client what form your MVP takes and how simple or advanced it’s likely to be, and of course, how you intend to validate it.
What is the AndAnotherDay flavour of MVP?
We use one of two types of MVP, depending on what we are building and the long-term aim of the project itself.
If the project is an ecommerce or brochure website, we will create something with fewer pages, features or products. This means the site can go live to generate interest or income in the short term, which can then be reinvested for the future enhancements. It also means that the site isn’t delayed while copy and content are being worked on. They can be added as and when they’re ready. Our own site is a constant MVP; there are features we want to add or enhancements we would like to make all the time, but our clients’ projects always have priority.
If the project is a software solution, we will create enough features to make the tool usable to a small group of users. While it’s in use we can gather user feedback along with the client’s own thoughts to build the next iteration of the tool. We will keep doing this until a version is ready for a wider audience or commercial release. This is particularly useful for spreading the cost and minimising risk. If the end product is an app, revisions are usually quicker, using web-based technologies (read more about that in our app blog).
Our own tool, ready for the world in 2021, will be released as a (very good) MVP, which we will add features to based on user feedback as we receive it. This is a particularly good case for using an MVP as the tool is ultimately for clients themselves to be able to use.
We’d love to hear your thoughts on MVP. Do you use this methodology? Are you interested in using it? Can we help you use it? Let us know in the comments below.