Minimum Viable Product: How it helps Time to Market?

Minimum Viable Product: How it helps Time to Market?

Enterprises frequently undertake large, multi-million dollar Transformation Programs to leapfrog competition or remain competitive. These transformation programs typically introduce many ‘new’ elements to the enterprise including new product development, new technologies, new people, new skill sets, new vendors, new processes etc. Enterprises do the required due diligence including internal and external research to define the Transformation Strategy and Roadmap to ensure the Transformation Program is set-up for success. Still, enterprises continue to struggle to deliver Transformation Program as per planned timelines and budget. Similarly, smaller start-ups have brilliant ideas but struggle to bring the product to market quickly. Start-ups spend more than required time and effort to validate whether a market exists for their brilliant ideas.

The below picture depicts how a typical Transformation Program or New Product Development cycle progresses.

MVP - Typical Development Life Cycle Chart

The Product Manager or Business comes up with an ultimate product specification, packed with features, that will revolutionize the market. Engineering team estimates all the features, lay the features against their resource availability and comes up with a project schedule and cost estimates. The schedule and cost estimates are typically months longer and many million dollars more than what the product manager/business hoped for. Then the negotiating game starts—cutting features, arguing estimates, minimizing QA and non-essential activity times or trying to hire contract staff etc.— all while the clock is ticking. Finally, product and engineering agree on a product that they think will revolutionize the market but can be delivered within acceptable budget and timelines.

But when engineering starts to build the product, they encounter numerous unforeseen challenges due to all the ‘new’ elements associated with the ultimate product including new technology, new skill sets and new processes etc. This results in cost escalations and schedule slippages. Product manager stats cutting more features but the cost/schedule slippages continue. More features are cut to ‘somehow’ get to the finish line. Finally, engineering delivers the product which has lot less features than what was promised but quite costly than what was estimated.

Minimum Viable Product strategy is very useful in the above Enterprise Transformation Programs or Start-up New Product Development scenario to quickly validate the potential business case. First, we need to develop deep understanding of core customer needs that must be satisfied. Based on those core needs, develop a Minimum Viable Product that can be deployed to early adopters or pilot group to quickly validate the business case. Based on the real user feedback, further investment in the transformation program or new product development is made. This ensures that any future investment is really going to add value to the end customer.

Minimum Viable Product - Graph

This is how a Transformation Program or New Product Development with a focus on Minimal Viable Product progresses.

MVP - MVP Product Development Life Cycle Chart

Create a Minimal Viable Product prototype so that customers can interact with the product and validate their true core needs. E.g. for a web application, a high-fidelity prototype can be created using HTML. Once the Minimal Viable product is agreed, engineering is able to provide better schedule and cost estimates due to clear understanding of the needs via high-fidelity prototypes. Once the project starts, engineering will face unexpected challenges. Because the product is already the ‘required minimum’, there wont be any argument about cutting features. As all the bells and whistles type features were already removed (or not included), the project is still likely to be delivered far more quickly and within reasonable budget than when a typical ‘ultimate’ product could be delivered in. In parallel, engineering team should start discussing about version 2.0 of the product so that product team can delay their urge to introduce last minute ‘must-have’ features in version 1.0 itself.

What have been your experience in delivering Transformation Programs or New Product Development that contained many ‘new’ elements outlined above?

What strategies did you find useful to ensure a more predictable outcome?

Did you find Minimum Viable Product useful?

[Images: Guilhembertholet, Transform Customers, Kata Blog]

DISCLAIMER: The opinions expressed on this blog are my personal opinions. Content published here is not read or approved by my current or past employer(s) and does not reflect their views or opinions.

About JP

Have more than 19 years of experience in IT including business transformation, Digital IT strategy, strategic planning, enterprise architecture, planning and delivering highly complex, integrated, large transformational IT solutions.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>