What is the concept of an MVP?
When I was trying to break into product management, I spent a lot of time reading about agile. My favorite book on this topic is the seminal “The Lean Startup” by Eric Ries.
If you are looking for a book that brings the principles of agile to life, look no further. One of the key things I took from that book is the importance of creating a minimal viable product (MVP) – something Ries defines as a version of a new product that allows the team to collect the maximum amount of validated learning about customers with the least amount of effort. A key concept of “The Lean Startup” is the build-measure-learn feedback loop.
The idea is to eliminate uncertainty by putting products or even concepts out into the wild as early as possible to see whether they have legs, whether the ideas can be improved, whether you should pivot to a new course of action or simply abandon the idea before you waste time and money on something people aren’t interested in. The first step in this process is to establish a problem that you think warrants solving. The next step would then be to define a solution (or an MVP) that you think will help you to solve the user pain point. You would then aim to release this MVP as early as possible to test it with users and iterate based on your findings of live use cases.
Examples of successful MVPs
The origins of the company Zappos are a well-known example of a successful MVP. Nick Swinmurn, Zappos’ founder, wanted to know whether people would buy shoes online. Before buying a load of stock, he tested the concept by creating a website with a load of pictures of shoes that people could buy. If they bought them, then he would go to a shop, purchase them, and post them out himself.
This was a low effort, low-cost way of discovering that people were, in fact, happy to buy shoes online, and so, with that, his business idea took flight as he fine-tuned the MVP into the company that we know today. Check out this link for more examples of successful MVP case studies.
What does the MVP process look like in government?
In my experience, I’ve found working in the public sector prohibits MVPs in their truest sense. It always seems like there is a reticence against putting something truly minimal out there.
I think there are a few factors in this: the civil service having a low appetite for risk, ministers expecting to see something quite polished, and the miles of bureaucracy, red tape, and governance steps you need to navigate in government before you can release anything onto the internet.
This means that government projects tend to use alpha phases to test concepts using prototypes and user research as opposed to observing behavior on live software. Therefore, when government projects launch what they refer to as their MVP into a private beta, what is being released tends to be more like a small-scale version of the eventual product, backed up by a roadmap of future features, as opposed to a true MVP as defined by Eric Ries. Note – for the rest of this article, when I refer to MVP, I will be talking about the civil service-style MVP as outlined above.
Why is it important to define the MVP?
I’ve found that if a team hasn’t defined the MVP at the point in which they are close to starting the build, trouble lies ahead. Not defining the MVP means that everything is still possible, no parameters have been set, and everything is still on the table. Therefore, team discussions are often too broad, theoretical, and likely to bolt off in a multitude of disparate and confusing tangents.
There are a lot of unwanted repercussions from the above happening too. Meetings feel bloated and do not result in outcomes. It is hard to arrive at decisions, and the team will complain they are unsure of the direction. Morale and progress are unlikely to be where you want them to be. Additionally, teams will not be enjoying what I have come to consider to be vital aspects of successful digital delivery – shared understanding of the problem space and a consensus on how to solve it.
Tune in next week for more…
So, hopefully, this article has helped you understand:
• What an MVP is
• What one looks like in government delivery
• The pitfalls of not having one defined
The next article in this series will take a look at how to define an MVP, ways to visualize it, and what to do with it now that you have one.
If this sounds good to you, be sure to sign up for the newsletter to receive it straight to your inbox.
