If you have decided to create a tech-based product you have probably been told you need to build an MVP but have no idea what that means.
In this article, I describe what an MVP is and why you need one. I also look at some of the things you may be tempted to do but may cause you more problems than you would expect.
What is an MVP?
MVP stands for Minimum Viable Product and generally represents the version of your product that you take to launch.
The aim of an MVP is to help you reach launch day as soon as possible and ensuring you do not over-engineer your product. As the acronym says, it is the smallest amount of development that can be considered a product. It may be that the MVP does not have all the features you would like it to have, it may be of lower quality or the user experience may not be as smooth as you imagined but it will be useable by your customers.
Why start with an MVP?
As a founder you want your first release to be perfect. You have worked hard to create it and you want to make sure that following launch you attract minimum criticism and maximum praise. You believe that launch day is the most critical day in the life of your product.
This all drives you to want your product to be fully featured, high quality and to have a frictionless user experience.
This drive makes you ask ‘Why go with an MVP?’ An MVP could be embarrassing and attract negative press. It could destroy your day in the spotlight. It could be rejected by your customers.
You may feel there is too much to risk to go with an MVP.
In reality, when you get to launch, you realise that this is when the work really begins. You enter the continuous cycle of product enhancment based on feedback from your users. It is this cycle that will make your product stand out amongst your competitors. You ignore your users at your peril as you will likely end up building something they just do not want or cannot use.
This feedback is so valuable, I believe that you should treat it like gold. When you do this, you realise that delaying launch to improve your product is false economy and that it could cost you more in the long run.
When you realise how important it is to get to launch as soon as possible, you start to understand why your launch product should be an MVP.
What does minimal mean?
So you decide you want to build an MVP but what does the M and V in MVP really mean?
- Minimal – build the least you can get away with
- Viable – build enough that your users believe you have a product they can use
Getting the balance between minimal and viable right is crucial. Too minimal and it will not be viable. Too much development and your launch will be delayed.
Reid Hoffman, co-founder of LinkedIn, is often quoted:
If you are not embarrassed by the first version of your product, you’ve launched too late.
There is a lot of discussion about what his intention was when he said this but having been involved with a number of MVPs, my reading of this is this…
Most founders I have encountered are very passionate about their products and will work on them until they meet their expectations.
Unfortunately it this passion that drives them to continuously improve their product, always concerned that it is not good enough, always concerned that their users will demand more functionality. However, if they reach a point that they feel it is good enough and deploy it, the quote is basically saying they have left it too late.
By trying to reach perfection, you spend a lot of time and money getting to a point which is likely the wrong point. If you had launched earlier, you may have cringed to see your new product but, by following the user feedback, you will reach a much better place much more quickly and at less cost.
Customer Satisfaction
By building and deploying early, you have the additional benefit of bringing your customer along on the journey. The early adopters will forgive any teething issues and will be delighted with each, rapid improvement you make.
The following illustration is used widely on the Internet to explain how this works.
Not only is customer satisfaction greater in the skateboard to car line but you also start bringing in revenue earlier allowing you to accelerate your product development and to get to the car more quickly.
Beware the over-engineering temptation
I once reproduced the diagram above with the top line showing the final product as a truck. Whilst the truck is a great truck, it is no good for the customers expecting a car. You may have alienated your potential customer base completely by over engineering the solution.
There is a great temptation as you get closer to launch, to enhance your product again and again. Whilst you believe that this delivers the greatest thing since sliced bread, it will be the market that decides. If you delay your launch by building more features you risk building something that is not wanted.
Beware the temptation of perfection
It is tempting to make sure your product, even your MVP, is of the highest possible quality. You want perfection and may chase the proverbial end of the rainbow to reach it before you launch.
You should realise that the the level of quality is an economic decision and not based on desire.
Assuring quality costs. Whilst your specification, design and development processes can all be refined to improve quality, when it comes to Quality Assurance, you need to test. I can confidently say, as a developer, you should never trust the developer to test their code. I have come across very few developers that hand over code that they do not consider works correctly (if you do come across a developer who says their work does not work, you should look to remove them from your team). Developers always believe in the quality of their code.
To make sure that their claims are correct, you must test the development. The more you test, the higher the quality of the end product. The more you test, the more it will cost.
I have seen people chase perfection and I have seen the crippling impact it can have on getting to launch and on the development budget. Whilst I do not advocate throwing anything into production, you need to find a balance where the level of testing is sufficient to ensure your customer does not dismiss your product as junk but the cost of testing is within your budget.
Beware the temptation of just one more feature
As the founder of the product, it is easy to fall in to the trap of thinking you understand how your customers will use your product. I have heard this referred to as start-up myopia and it affects everyone.
I can be confident to say that when you first see a user use your perfect product, they will struggle, they will use it in ways you never envisioned and will like and dislike features that you dislike and like respectively.
It can be a bit of a shock.
So when you find yourself thinking that there is one more feature that your user will need to use your product, ask yourself if they can use it as it is. If they can, err on the side of caution and launch anyway. You will probably find the users have more problems with features you never would have thought were a problem.
With one product I was surprised when the biggest problem users were having was dragging and dropping a profile picture into their account. It had been tested. It had even been beta tested. It isn’t hard. We even gave the users all the instructions they needed.
But they still had difficulty.
The solution – some new complex way of uploading profile pictures? No. A user suggested we simply had to add the word ‘here’ to the instructions. After that, no more problems with uploading profile pictures.
Conclusion
In this article I have looked at what an MVP is and what building a Minimum Viable Product means.
Over-engineering the product for launch day is probably one of the most significant causes of delayed launch dates and excessive spends. It is understandably hard for founders who are truely passionate about their products, to cut back their expectations and to launch what they consider is a poor product.
Requillion Solutions has witnessed founders almost cringing at their launched product but also witnessed the work done following that cringeworthy launch to create an amazing second or third version. This happens because, following launch, you start to understand your product like you never did before launch and this helps you make sure that successive releases are so much more aligned to what the user needs and wants.
If you believe you may be stuck trying to launch and would like to understand the role of an MVP, book a confidential, obligation-free consultation with me here and we can discuss your ideas.
website: requillion-solutions.com.au