Developing an app can be a time-consuming, expensive endeavor. As such, it’s important to work with a methodology that will deliver on ROI and business objectives. Many companies however choose the wrong approach. You have numerous startups which have failed because they took an idea, developed it for months, or even years, and never market tested it until launch. The results from taking this approach can range from disappointing to disastrous. To address this, companies have started working with MVPs, or Minimum Viable Products.
How to Develop an MVP
The methodology starts with identifying a problem and then building a bare bones product known as the MVP, in order to test assumptions and customer reactions to it.With each iteration of the MVP, the company gathers actionable data and metrics in order to determine various cause and effect relationships.
If everything goes as expected, the MVP is developed further by adding new features and functionalities. However, if at a certain point, it becomes clear that the product idea is not viable, the company can pivot at a relatively low cost, and revert to a previous functional step of the development process. For example, if it becomes clear that the current development path will lead to a product that will not be financially viable for the current marketplace, the company can rollback changes easily, or even scrap the project in its entirety. However, the latter option is fairly rare when working with an MVP.
The process of developing an MVP starts with a planning phase. During this phase, you will want to map out the long-term goals of the product, identify the reasoning behind its development, and the criteria which will indicate whether the product is successful or not.You then need to take a look at your users. This is where you create user personas, identify use cases, and map out the journey each user needs to undertake in order to achieve their end goal with the product.
Once the conceptual framework is in place, it’s time to start thinking about features. In an MVP, features are ranked according to importance, and the most important features relate to your user map and your end business goals. For example, if you own a chain of coffee shops, and you would like to build an app that reduces the number of time people wait in line for their coffee, you might be looking to implement features that allow customers to pre-order coffee online before they reach the coffee shop.
In this case, you will need several essential features: clients have to be able to pay through the app, they will have to be registered in a database, and they will need to receive a proof-of-payment on their phone, in order to redeem their order when they reach the coffee-shop. At this point, we’ve identified three essential features for your app. In order to build an MVP, we will have to break these features down even further, and perhaps only market test one or two of them, so that we can reduce costs and development time.
Let’s say we’ve decided to test the concept: are clients really interested in pre-ordering coffee? The MVP will perhaps allow customers to simply pre-order coffee without paying for it, and the app will log their order into a database. The experiment can be run for a couple of days with a handful of loyal customers, in order to test results. If everything looks good, the mobile payment feature can be added and tested next.
Features to avoid in an MVP
That said, there are features which are almost universally poorly suited for an MVP. Features that are completely aesthetic in nature, for example, do not have to be added to the MVP, because they provide very little quantifiable value. These features should be added only after the core functionality has been tested. Other features such as social media integration also fall into this category.
You then have copycat features. Adding features that are similar to more established apps will extend your timeline and budget, but they will not provide new insights into the usefulness of your product. Copycat features have already been tested by the larger, more successful app, and as such, they can be added at a later stage of the product development.
Finally, you have features which are requested by early users. This may seem a little counter intuitive because one of the main purposes of the MVP is to test the users’ response to a product. However, features requested by early users might not actually be a good fit for your business goals. For example, some users may request social media integration at a very early stage of the product, which would take time and resources to implement, without providing any quantifiable value to the MVP. These requested features should be noted down and kept in mind for later versions of the product.
The Most Common MVP Development Pitfall
The main purpose of the MVP is to provide validated learning. Validated learning is the iterative process which measures the effectiveness of a product in reaching the set business goals. As such, it’s important to keep in mind that any feature added to the MVP has to have a measurable impact across relevant metrics. Some companies will make the mistake of not taking this into account, and they will go on to view the MVP as the most stripped down version of a product, removing essential features in the process.
To avoid this mistake, always keep the business goal in mind, as this will help you reach a balance between cost-effectiveness, and validated learning. However, balance is the key word here. Some companies will go overboard with the initial features of the MVP, to the tune of the MVP occupying 97% of their backlog which contradicts the whole idea of an MVP. The MVP should have several key features that will be tested, with the rest of the functionality being implemented once the market responds positively to the concept behind your product.
The Benefits of Developing an MVP
So what are the benefits of developing an MVP? The first benefit would be a rapid development process. It usually takes one or two months to have a market ready MVP. You will also need a much smaller budget to develop an MVP since most features will not make it into the product.
Since the MVP is a lightweight version of a larger final product, the risk for investors is much smaller. With a reduced development timeframe and budget, investors are much more willing to test an idea and see if it is well received by the market. And, once the concept has proven itself within the market, stakeholders and investors will be much more willing to buy in.
Finally, the MVP development process itself builds an audience. At first, the MVP may be used to test market reactions, and see if a product is welcome by users. But once the MVP starts to gain traction, some users will become early adopters, and develop loyalty towards the product. This means that by the time you get to market, not only will your basic assumptions about the user base be validated, you will have a core set of users ready to support the product.