Through their Lean Startup work, Steve Blank and Eric Ries have popularized the idea of focusing on delivering a Minimum Viable Product (MVP) which will meet a customer’s core needs while minimize investment and providing opportunities for learning, refinement and the ability to fail fast. Organizations have latched on to MVP principles and reworked development approaches as a means to avoid gold-plating and to achieve time to market and early ROI benefits.
But minimum is very context-specific.
If we are developing a product to address a newly expressed or generated customer need, expectations will be low.
For example, when the first personal quadcopter kits became available, expectations centred around attributes such as stability of flight, range or battery life. But now that these devices are commonplace, the expected set of features for a new entrant into the market are much richer. The barrier to entry for a new competitor is much higher.
Even if you are an entrant into an emerging market, if there is a well established product or service which you are attempting to disrupt, you will need to meet that product or service’s base requirements to effectively compete. You might attract some early adopters who are willing to sacrifice features which don’t specifically address their core needs but it will be very difficult to cross the chasm to mainstream adoption. Electric cars are a good example of this. While the market is still new, attempting to release an electric vehicle without power doors and windows is unlikely to satisfy most potential buyers.
And the same applies to projects.
If our project goal is to deliver a new business capability, it might be possible to develop and release a minimum feature set and then incrementally evolve the capability. For example, when developing a new business process, we could deliver the happy path first and then implement exception cases in subsequent releases. But when the goal of our project is to replace an existing capability, the size of the first release might represent the lion share of the project’s cost or schedule.
Minimizing investment and failing fast and cheap are no longer feasible.
But this shouldn’t prevent us from applying MVP principles when planning such projects. We should still defer those features which don’t directly address our stakeholders’ needs for the first release.
Let’s just be realistic that minimum isn’t the same as small.
Easy in theory, difficult in practice 