wThe Case for Most Viable Product (MVP): Balancing Cost, Time, Quality, Scope

Often startups or companies trying to move quickly and meet or exceed market dynamics believe that making a minimal viable product (MVP) is the best way to expedite both getting a product or service to market and receiving feedback. I disagree. We need to change how we view MVP. We need to replace minimal with most and start talking in terms of the most viable product.

According to CB Insights research, 67% of startups end up either dead or become self-sustaining. It begs the question; what factors are contributing to such an alarming rate? Most of us are familiar with the idea of fail-forward-fast. That is, learn from your mistakes quickly, correct them and then re-deploy your product, services or MVP. However, if we combine the fail-forward-fast philosophy with minimal-viable-product, we are merely setting fledgling businesses up for being part of the 67% failure statistic.

The above chart lists the top 20 reasons why a start-up fails. However, I think we can reduce these 20 down into just four categories: time, cost, quality or scope. To illustrate, I’ve aligned each of the causes on the list with the corresponding factor or factors – clearly marked in red. The difference between success and failure is when you incorrectly trade off the wrong element you will doom your product/service to a point where it is too small which may force you to pivot or change when you are not ready.

How to move from minimal to most viable product

You must begin by paying more attention to the cost, time, quality and scope of every project. These four variables determine the difference between minimal and most but if you flex cost, time, and scope – quality is always a priority. You can build an MVP that will have a better chance of making it to a version 1.0 or 2.0. If you are genuinely trading off the other three variables to produce the best quality, then you will have a most viable product that I believe will have a better chance to succeed.

Let’s take a closer look at these elements. While each appears in all types of projects, today I want to focus on technology and developer-oriented projects.

Cost

It is critical that you understand what you get for what price and when. Do you have to pay more for some of the must-have capabilities for your most viable product? As Fred Brooks points out in his classic The Mythical Man-Month, spending more or putting more people on a project does not necessarily work. Organizations must be wary about just throwing money and people at a project you want to accelerate. A better tactic is scoping it from a features perspective sooner in your development cycle when the costs are lower, and the product is evolving.

Time

Remember that planning or delaying a schedule to accommodate more scope could cause broader issues. If there are team and feature dependencies reliant on delivery, delays will cascade throughout teams, programs and organizations. If one component or service is late because of dependencies, it will cause delays. Spend more time upfront on specifying what it is you are building and the timing. Plus it is easier to adjust early in your development before you are hurling through your beta stage with everything cascading around you.

Scope

Scope is the most valuable, predictable and fungible variable to ensure a most viable product release. Most product deliveries have too many features, capabilities, and external quality constraints. It is easier to build a product when you know someone will deliver at least a minimal version by a specific date, with the possibility of more features and enhancements. I'm arguing that you can do the same and deliver the most viable version, in scope, on-time, within budget and with the quality you expect if you approach it that way. It may not be easier, but it is more sustainable if you want a future.

Quality

Quality does not mean how the product performs, or looks or the external attributes of features, design, capabilities, and service scalability. Rather the intrinsic quality of the product affects your ability to continue to pivot, modify, enhance, or re-design the product. There is never a time to sacrifice quality for an external or customer facing product. Ensuring internal quality is more likely to increase your balancing of cost, time, and scope than it is to decrease it. Quality is free if you can balance the other three variables. However, a quality focus means you are building the most viable product for your launch, not a minimal one.

You may think this focus on most versus minimal is semantics; however, given the high failure rates around minimal product releases, I think it is an important distinction. For example, let’s look at Yahoo Pipes which fits squarely in the failure group. If they had planned their infrastructure to proliferate, they would not have experienced the total breakdown of allowing people to kick the tires of Pipes – that became the story, not how great the product could have been. Apple and Samsung dominated the cell phone market because they released most viable products in a quickly changing market at a cost that works within their means and have scoped well-honed features and capabilities for future releases. They both play the variables well and have benefited tremendously.

At Skillsoft our Technology, Developer and Certifications solutions all strive to meet the most viable product style of development. We are not going to trade off quality for a quick hit with potentially longer-term failure.

Mike Hendrickson is the VP, Technology & Developer Products at Skillsoft.