What’s the Purpose of a Minimum Viable Product?

Software product development is a design hypothesis testing exercise (as we pointed out in our post on the iterative process). You believe that this set of features used by that group of people will achieve your organization’s goals. But how do you know that’s true? One option is to dive right in and build the whole thing to find out, but you would be risking a lot of time and money on a guess.

Another option is the minimum viable product (MVP). This allows you to test that hypothesis in the fastest and cheapest manner possible. This gets you to working software and real-world feedback quickly, which is the purpose of the MVP: validate whether or not you’re on the right path.

What is an MVP?

Minimum Viable Product is a ubiquitous term in software development efforts these days, even in those organizations that have not adopted the Agile philosophy. Everyone has their own idea of what the word means. Frequently it’s just a new name for the first version of a product. And while, technically, that’s not wrong, it misses the core meaning of this version of the product, as addressed by the two adjectives:

1. Viable: The MVP must be a piece of software that could be used by the target audience in a real-world manner, generating analytics that will allow you to validate your design hypothesis.
2. Minimum: This is a product stripped down to its essentials. Only that needed to make the product viable should be built.

While the goal is working software, the ultimate objective is the real-life experience of target users that you will collect. Think of the MVP as the concept car that you see on display at an auto show. The company doesn’t intend to bring THAT car to market, but rather to test out the viability of its features.

What a Minimum Viable Product Is NOT

Some of us have learned through hard experience that we may get only one bite of the apple. That whatever we have at the end of this initial exercise may be all we’ll get, so we better be able to go to market, just in case. This is a self-defeating response:

• It expands the scope of minimum. To be able to go to market, we need to spend more time and resources despite not yet being confident that we’re building the right thing.
• Given that this is still a minimum product, the stakeholders may believe it’s not good enough for the market, so decide to kill the project.
• Even if they don’t, the additional effort may lead us to not react appropriately to what we’ve learned from real-life usage, especially if the conclusion requires radical change.

Resist the temptation to do more than gather feedback to test your design hypothesis.

What Are the Characteristics of a Minimum Viable Product?

What an MVP might look like for your product is dependent upon the context of your market, your business objectives, and the collective experience of your targeted users. Given that, however, the following describes at a high level what an effective approach might look like.

A Clear Definition of Minimum

Minimum applies to many facets of the Minimum Viable Product, including:

1. Targeted Users: Some segments of your market may be more valuable than others. Which customers, prospects, or other system users are more likely to help you vet your design hypothesis?
2. User Stories: You don’t need to do everything. Which activities do you need to witness your targetted users conducting?
3. Outcomes: You do not need to account for all possible permutations of a user story. Which ones, good and bad, matter most?

Once you’ve established this framework, you can plan your MVP.

Feature Stubs

There will be some fierce arguments about what features to include. There will be a number of features for which there are good arguments to include, but not enough to make them qualify for the MVP. This ambiguity may be because they’ll be expected by the user, their absence will make the user interface feel off balance, or stakeholders feel very strongly despite your pushback. In these cases, consider stubbing them out, much like the plumbing for an unfinished basement.

The example to the right is a snippet from a recent MVP I was working on that displays functionality we will not fully implement. Some additional steps you can take could be:

• Make the widget clickable: There will not be a user profile in the MVP, but the system can display a message describing what would happen when the user clicks the link.
• Give it some light functionality: Even though we’re not implementing the notification functionality, we could indicate when the user has a notification as well as the count. We’ll just leave the actual display of notifications to later.
• Show a mockup: Likely a user’s settings are hard-coded for the MVP. You may want to display a screen that shows what those settings are even though the user cannot change them.

The point is that you don’t have to fully implement a feature in order to include it in the MVP. This might be enough to mollify the loud voices calling for their inclusion.

Minimal Graphic Design

I’m calling this out separately to give it the emphasis that it needs. Resist the temptation to make the MVP pop. The whole purpose of the MVP is to determine if anyone needs this to pop and what pop actually means. The level of graphic design should be driven by the needs of the targeted users. If this is an internal product, you could probably get away with black, white, and shades of gray. If the idea is to publicly release this product and you would have to conform to an existing style guide, doing so may make sense for the MVP, depending on the maturity of that style guide. The point here is that you only need enough to elicit the right behavior out of the target users. Any more is a waste of time.

Metrics Collection

Real-world feedback is the whole reason why you’re doing the MVP. This will provide the baseline against which all future changes will be judged. As a product owner, I’m inclined to collect every click, keystroke, and pause. I’m realistic enough to know that this isn’t always possible. In addition to the expected user journeys in the MVP, some additional metrics that may prove useful are:

• Clicks on stubs: If you have a help link stubbed out on each page, it would be nice to know how often it was clicked. This wouldn’t be evidence of the need for a help feature, but rather what might need to be redesigned.
• Sorting: If lists are an important part of your product and you find users consistently re-sorting it a certain way, you may have a candidate for a new default sort order.
• Time spent on page: Are there pages that have a surprisingly long time spent on them? They might be candidates for redesign or an indication that this is when the user decided to go get lunch.
• Users with heavy usage: You may find a number of outliers who have clicked through every screen in the MVP even though it’s clear that they didn’t need to in order to execute the tasks in question. These people might be good candidates for additional user testing.

Maximize the Work Not Done

The biggest pitfall many face is falling prey to the fallacy of sunk costs. You need to be willing to throw out the MVP if you learn that your idea just isn’t going to work. The more you spend beyond what’s necessary for the MVP, the more pressure you’ll feel to continue down the same path. Besides, the essence of the Agile approach to software product development is to ensure that you’re building the right thing at the right time. Do not waste your time and resources on something for which there’s not a good case.