Is your Minimum Viable Product Really Minimum?

Posted January 19, 2017 by Dan Moore in Product Management, Startups

Having consulted with over 30 startups in the last 3 years, we have experienced working with entrepreneurs that have never launched a company or product before into the marketplace.

When learning the Lean Startup process for the first time, a first-time entrepreneur will come across the concept of a Minimum Viable Product (MVP).

While Eric Ries's book and experience does a good job documenting a manual MVP, the experience he shares with a software MVP isn't the best guide to following the process yourself. So how do you know if your MVP is actually minimum and will still create value for your users?

The quick and dirty way, released in our online tool DefineMyMVP](https://www.definemymvp.com/) is to simply pare down your concept to the smallest thing possible.

With this online tool, we take 16 points that go into an application, and turn the list into the core 2 points. That process is dead simple, the product owner goes through 3 rounds of questions and sorting, throwing away half of the options each time.

How to Evaluate and Prioritize Features

In reality, this is simply a good starting point -- an introduction to separating your ideas and prioritizing -- an impossibly hard practice when we're married to our ideas. When working with our clients, we consider 4 holistic perspectives to evaluate and prioritize features between development and the guillotine's basket (ok, that's a little dramatic, it's more like an icebox that we'll get to if we're successful with the most important features).

1. Effort

First and foremost, we consider the effort required to complete the feature. How much work is going to take before we can call it "done"?

There's a large difference between a value proposition that takes a week and a month to deliver to a client and that's often the deciding factor. In the lean methodology, our goal is to prioritize and deliver features with the least amount of effort and largest amount of gains.

One model to perform this is the RICE methodology, which follows a simple equation of prioritizes features based on the highest RICE score:

Reach x Impact x Confidence / Effort

Without delving into the entire ranking system, notice that the higher the effort, the lower the RICE score -- an inverse relationship. So with this model we can prioritize features with the smallest effort -- or change features to use the least amount of effort as possible to get the same value proposition.

2. Cost

Secondly, we look at how much money the feature is going to cost. While this includes upfront development costs, often a labor expense in modern software development, it also includes the maintenance and per-operation costs.

This comes in the form of usage of services, consumption of consumerable goods, or timeliness. If we can correctly minimize investment, then you can maximize the returns of the MVP.

3. Marketing Cost

Third, how much marketing is required for the feature? Just like the product, the marketing needs to be the bare minimum.

If the product takes weeks to train people how to use, it's not minimal enough. The value proposition of the feature and product released as an MVP needs to be lightening focused to ultimately convert targeted and informed users of the product. If the value proposition is longer than a sentence to any customer segment, then the marketing should be revisited and focused more.

Just like the product, the marketing needs to be the bare minimum. If the product takes weeks to train people how to use, it's not minimal enough.

4. Usability

Once those overlooked (and arguably more important) variables are considered, we can return to minimizing what you've already considered -- the product's usability. While this is captured in methodologies like RICE (Impact), product owners usually prioritize features by how valuable it is to their customers naturally.

With a properly prioritized feature list in place, the decision on when to release to customers is the only remaining question.

In our process, we release a prototype early before development begins and a functional product to early adopters (who are still paying customers) as soon as possible. In our experience, this is often a month into product design and development -- when users are in need of the solution and are willing to deal with rough edges of the product or service.

So with this information in mind -- is you MVP really as minimum as it can be?

Try out DefineMyMVP today to see how you prioritize your feature list. If you've developed a product in the past, we'd love to see how you prioritize those features and if the results are what you experienced or something new.

Leave your results in the comments below, or tell us what you think over at definemymvp.com.

Vaporware

Related Insights