I recently got into an IT project with a dream to digitise the process and use the efficiency to drive down cost, improve experience and reduce marketplace inefficiency (matching demand with supply) – sounds all familiar?
As in any IT project, we envisioned an end product that would meet all our requirements but then decided to prioritise a few features given the realities such as budgets and timelines – Thus came the MVP, Minimum Viable Product.
As the name suggests, it is minimum! Something like start small and make it big. But if we make something very frugal, can it live upto the expectations of the future? Perhaps not! So comes the second name, viable. Anything that is viable, gives more economic returns than what is invested in. So theoretically, we could make something very small as to not give any ecconomic output and thus any small cost would mean the product is not viable. Mathematically, 0/(however small number/cost) still results in 0.
So ‘the small’ that we start with should deliver sufficient economic value inorder to justify the denominator – that is the cost.
Also who determines the minimum? The person who is closest to being able to calculate the economic output should. Because calculating the denominator, cost, in most cases is rather simple. So it’s essentially business that should tell IT team if the economic output for certain costs is high enough.
But will the minimum viable product actually give raise to the theoretical economic output that is estimated? That is a business risk. And things can go different from plan and therefore a minimum viable solution should have a 6 months vision of product road map so that the project can be added with more bells and whistles to deliver better economic value.
So next time you think k of creating an IT product, think of a Minimum Viable Product where you so big enough to deliver economic value to justify costs and plan for roadmap atleast for 6 months.