When dreaming up an innovative new product, you must remember that the same reasons that make this product innovative bring the challenge of confirming or disproving its value proposition to your customer. Before you go spending thousands of dollars and months of development you should take some time to evaluate what should be in the first version, the simplest version of your product that will enable you to test your value hypothesis, and what can wait for a future version.
2016 is right around the corner! Many startups and IT departments of established companies are locking down their budgets and revising their final draft specifications for their digital projects for the New Year. This year we’ve met with hundreds of potential customers, and read countless specifications documents and would like to offer some food for thought to all of you planning the launch of your new app or web platform.
A few guidelines in determining what should be included in your Minimum Viable Product or MVP
Focus on the problem to be solved. Ideas will spawn new ideas, which is a good thing however you must be able to make the distinction between which functionalities are core to testing your value hypothesis and which are nice to have.
- Avoid big data aggregations. Unless the value of your product lies in the aggregations, for example in an environmental footprint or business intelligence tool, you should consider a phantom back-end. What I mean here is that if there are data aggregations in your specs that serve to make your job easier and not your customer’s, consider replacing them with a simple CSV type export and do the job yourself in Excel.
- Avoid excessive interactions in the interface. It is essential for your app or web platform to have clear and simple user journeys. In the MVP you don’t need to provide five routes to the same destination nor do you need to provide pivot table like functionality. These interactions are often deceptively complicated and time consuming to develop, so avoid them when possible.
- With a lean set of specifications the development will take less time, cost less money and enable you to test your value hypothesis faster. If you are a startup, most likely your budget is small and your deadlines are short so having lean specs aligns with the rest of your situation. Regardless if you are an IT manager with a substantial budget or a startup counting its pennies, it pays to be able to get fast feedback from whoever will be using your product early on. Early feedback will allow you to adapt your strategy before spending your entire development budget and going past your deadlines.
If you’d like some additional information please see the links below: