A minimum viable product (MVP) is a concept that I feel is often misunderstood, particularly by people who are not technical or used to building technology products. In this blog, I’m going to explain why I feel MVPs are misunderstood and explore the difference between an MVP and a 1.0 delivery of a technical product.
What follows is my opinion of an MVP and my experience of it in the context of a software development environment. You may well have come across a different definition for an MVP, as there are many different opinions on this.
In my experience, MVP is quite a misunderstood term, because there are so many varying definitions of it. When you’re running a software development company or a technical team and a client comes to you and asks you to build a minimum viable product, it’s very important that you’re both on the same page. This means it’s important to work closely with your clients to ensure the vision surrounding the MVP is realistic and that it reflects what the client wants to achieve. In some cases, a client’s expectations of an MVP will be higher than it should be, simply because their understanding of the MVP concept is different. Therefore, if you don’t align expectations from the outset, they may be disappointed with what you deliver. It is in no one’s interest to have that kind of misunderstanding.
What is an MVP?
As I’ve said, there are many definitions of a minimum viable product (MVP), but the way I describe it is as a no-frills, feature-poor application that has enough functionality and content to show users what it could look like and get them to go through the process of using the system, whatever that system is.
For example, if it was an e-commerce app, you would be able to sell one product for one penny on the app. The MVP will have enough functionality to allow you to sell one product whether that’s for one pence or maybe £100. You might want to add more than one product on there, but it will be the most basic version of what you’re ultimately aiming to create.
The main purpose of an MVP is to get feedback, either from a small group of friends and family, or other people in your network. The point is to get early feedback and test the market to a very limited number of informed people. You want to make sure that you are happy that you’re in a place where you can then build this MVP out to a full, what I’d call 1.0 version – and I’ll come on to what a 1.0 is a bit later in the blog.
Why are MVPs important?
Fundamentally, though, an MVP is really important for gathering feedback and it can be really important for beginning to test the market in a very limited fashion, but that’s all it is. Quite often clients expect that they’re going to make lots of money from an MVP for selling that product or service, but that’s highly unlikely if you’re building a true MVP.
It’s your job to help your clients understand not only what you define an MVP to be, but also why it’s so important to start here rather than going straight to a 1.0. As I’ve said, the main reason for an MVP is to allow your client to receive early feedback on their idea and on their product. The key is in the name here: minimum viable product. You’re using the MVP to find out whether an idea is viable. Is this something that the market requires? Are you adding sufficient value to people’s lives that they will pay money for it?
The second reason to create an MVP is to get early feedback on the branding and the user experience – or how easy it is to use. Even though it’s not fully finished and there may well be elements that you’re still going to improve, it will be really useful to get that kind of early feedback on how you think the process should be working and how you build that MVP.
The beauty of an MVP is that you’ve not spent all the money you would on taking a full 1.0 version of your idea to market. With an MVP, you spend a smaller portion of that money and if you decide to pivot or even stop the idea altogether because the feedback isn’t great then you’ve lost less money.
If you decide to pivot, you’ll also lose less money because you’ve got less to change because you haven’t built the whole thing. That means it’s an easier task to make changes based on the feedback that you’ve received from clients. You can also gather feedback from people outside your circle of friends and outside your network by placing a few fairly cheap Google ads and offering your product or service for free, or offering a cheaper version of whatever you’re selling. As long as you collect people’s details, you can reach out to them and ask if they’d like to give you feedback. That’s a useful thing to do because it extends the feedback circle away from the people you know among your friends and network who might not be quite as honest with you as complete strangers.
What’s the difference between an MVP and a 1.0?
A 1.0 version is a more fully-featured version of your MVP. I’ll give you a specific example of a project that I’m working on at the moment to help you understand the difference. I can’t go into too much detail, because we haven’t launched this product yet, but in essence, I’m working with a business partner to build a legal document platform.
Our MVP for this platform will have three basic products which will allow the user to geb=nerate the three main types of legal documents from the application sitting on the platform. When we go to 1.0, we’re probably going to have eight or nine different products, however, we don’t want to build all those out, spend all the money and go to all that trouble before building an MVP. Our MVP will be used to test the market, we’ll get feedback on the user experience, on the branding and design that we put in place, and maybe even on some of the advertising and wording that we’re using. This will help inform exactly what we do for the 1.0. It might tell us that we’ve got it exactly right and we should carry on as we are. There might be some really useful small changes. Or there might be some bad news in the fact that we actually haven’t got it right at all and we might need to make some wholesale changes.
Either way, the feedback will be really useful and it’s at a really early stage so it’s a lot easier to make those changes. Once we’ve got this, we’ll go to the 1.0 version. The 1.0 is not the end of it, but it is a far more complete version of our vision for this project.
From there we can get our user experience on those eight or nine products nailed and when everyone seems happy, we can continue to add other features that are hopefully going to add more value. For us, after our 1.0 we might be adding some automated marketing tools so that we can send out automatic reminders and maybe some special offers to people who go partway through the process and then stop for whatever reason, just to encourage them to finish up. We might also introduce some added value items where there are little extras, for example, a legal document could be checked over by a lawyer or you could buy some of a lawyer’s time to ask specific questions about a particular legal document.
Our intention is to continue to build out the products, as well as the offering. With the legal document service, there will be other document services we might add onto the system, such as conveyancing, wills and trusts, or any number of different legal contracts.
Mitigate project risks
I learned in the very early days of running my software engineering company Cake that there can quite often be misunderstandings with clients if we are working with differing expectations. There are no winners in that situation, because if the client’s expectations are different then they’ll be disappointed when you build the product, even though you might put your heart and soul into it and do exactly what you thought they were expecting.
I’d like to leave you with the point that it’s really important to define what constitutes an MVP in any proposal document or legal contract. You don’t have to define this to the nth degree, but you need to have enough detail in there to prevent those kinds of misunderstandings. Just to add clarity, you might want to articulate what the 1.0 could be as well, which will further explain the differences between an MVP and a 1.0 for your client.