Building and releasing a product is a complex process that takes considerable effort, time and money. How can this process be made more efficient? How can you ensure that your ideas will really work in real life? The solution is simple: using an appropriate product development methodology based on the Minimum Viable Product approach will allow you to answer these questions, meet the needs of your customers and achieve your business goals.
A product that adds value for customers
Before you start building a product, be clear what value it will bring to your customers. This is what interests them most. Regardless of the form your product has—physical or digital—it should solve the customer’s problem. It may be a trivial one, e.g. how to find a particular book in a library catalogue or a very complex one, e.g. how to integrate private and public cloud with on-prem infrastructure into one environment maintaining a high level of security. It doesn't really matter how complicated the problem actually is. The answer is always the same. You can solve it by delivering a high-quality product that brings value to your customers. They also don't really care how you do it, as long as it suits their needs. This is also one reason the market is constantly changing and transforming.
What is MVP
Enter MVP, a concept that has recently undergone a thorough theoretical elaboration. In a nutshell, Minimum Viable Product (MVP) is a version of a software product that has enough functionalities to satisfy the basic needs of the first users and convince investors to sink money into it. It is not a fully-grown product, but it can nevertheless bring business benefits and has the potential for further development. In other words, an MVP is a working prototype that should:
- be fast to build
- concentrate all resources (money, developers, etc.) on providing customers with real value, i.e. solving their problems.
- have only those features that are necessary for a product to generate this value
The concept of an MVP was elaborated by Eric Ries in his book The Lean Startup. The author himself founded several startups that failed. Based on this experience he wrote a book explaining the methodology a startupper should follow to succeed. He believes that the most important factor is to focus on business goals (why customers should use your product), and not on the technology (how to create a product), which has only secondary importance. Therefore, you should focus on researching the market and understand the problems your potential customers want to solve. Armed with this knowledge you are more likely to succeed.
Why build an MVP
But why build a product that has only limited functionalities? The best answer to this question is what Jason Fried, Founder & CEO of Basecamp, once wrote on Twitter:
“You can only iterate on something after it’s been released. Prior to release, you’re just making the thing. Even if you change it, you’re just making it. Iterating is when you change/improve after it’s out. So if you want to iterate, SHIP.”
Any product before it is released to the public is a mere hypothesis. You need to test it in a real-life scenario and collect market feedback. Only then should you iterate, i.e. change something for the better or add a new functionality. Each idea, even the most brilliant one, brings no business value until it is put into practice. An MVP allows you to verify, without making a substantial investment of time and money, if your product will attract new customers once it is launched. This also limits the potential risk of loss should your product fail. If your idea fails to attract customers, you can shelve it before you lay out too much money.
If your product is successful, however, you can just continue to develop it. In fact, an MVP is a simplified, but working prototype, so it is a good foundation for a fully-grown product. There is also a third scenario to consider: when your MVP needs corrections to be transformed into a product. Still, regardless of whether it causes disruption in the market or needs to be completely reworked, an MVP strategy allows you to considerably shorten your time-to-market.
Fig 1. MVP development cycle
Build fast, fail fast
This short phrase epitomizes the entire MVP philosophy: building new features and testing them quickly. When developing an MVP, your goal is to provide value for customers by building features to satisfy their needs. This is the trickiest part of the entire process, as you don’t really know if your idea for a given functionality will be what your customers want. To make that determination, you need to test it as quickly and inexpensively as possible.
While the functionality may fail, you will have gained precious insights into customers’ expectations. That you know to remove the failed functionality from your product’s roadmap is yet another success, as is the redoubled focus you will now place on building new functionalities and testing them to get the fast feedback.
How to test your MVP functionalities
To test an idea quickly, treat it as a scientific experiment. First, clearly define the success/failure criteria. When can you say that your idea is not working and should receive no further investment? When will you know you’ve succeeded? The following checklist will help:
- Formulate a thesis
- Define the boundary conditions
- Define the success/failure criteria
- Define how the thesis should be verified
- Conduct the experiment
- Make conclusions
- Repeat
The thesis is what you want to achieve, e.g. functionality XYX will increase the number of customers by 10%. Boundary conditions are your product’s constant characteristics in a given situation. They should be met in order to succeed. A boundary condition can be a channel through which you are reaching your customers, system performance (i.e. the ability to handle a certain number of users at the same time), delivery method, etc.
Next, think carefully when you can say that your experiment has succeeded or failed. For example, if a conversion rate grows by 1.5% instead of the 2% you anticipate, is this a success or a failure? Such questions are important in order not to reject promising ideas too quickly. Then, you define what a tested functionality should do and how it can be built quickly and at minimal cost.
Once it is ready, deploy the new functionality. This is your experiment, during which you’ll collect the data required to determine if your functionality has succeeded or failed, and also, crucially, to begin to glean a bigger-picture view of your product and its customers. Finally, draw conclusions based on the data you have collected. Should this functionality stay or be rolled back? Does it have the potential to be developed into something even more innovative and interesting? When building products, data is power.
If your customers like a new feature, you can add it to your product. If not, you need to find another hypothesis and test it. This is an iterative process aiming at the constant and long-term improvement of a product.
Testing leads to mastery
In today's highly competitive startup market, the time-to-market of a new product or feature is often key to its success. The more tests you do and the more data you collect, the faster your product or feature will be released on the market. Data collected during the tests will allow you to take informed decisions and create a product roadmap that is more likely to meet business objectives.
Read our other MVP-related articles:
- Creating an MVP for a Network Application
- MVP vs prototype – which one do you need?
- MVP in software development - everything you should know about it
- MVP Implementation & Strategy for Network Applications
- Building an MVP: 6 common mistakes to avoid
