Instead of MVPs, Maybe We Should Be Releasing SMURFS

I’ve come to dislike the term minimum viable product, or MVP. The problem is that while the concept is great, the term is misunderstood and misused in many organizations.

This misunderstanding begins with the very first word: minimum. It seems this is often interpreted as imperfect, incomplete, or unfinished. The next issue is the word viable, which gets heard as “mostly capable of working.” When combined into minimum viable product, the term is typically implemented as a “half-baked, barely feasible” product. If that isn’t bad enough, there’s also no concept of a customer or end-user (unless very indirectly via the word product

I find this misunderstanding encourages wrong behaviors such as mindlessly adding and removing unvalidated features from a product, lowering quality or maintainability standards, and sometimes, oddly, inflating MVPs until they are huge.

Now, remember I said the MVP concept was a good one—but what if instead of “minimally viable” we thought “specifically marketable and useful”? The more specifically marketable something is, the narrower the slice of market segment is likely to be. This would help us really focus on a target group of customers or users and produce something useful for them.

To me, this is much more of what an MVP is supposed to be about. I also find it drives better behaviors, or at least better questions. What is the market we’re after? Can we be more specific? How do we know? Will it be useful? How will we know that? These are all better places to begin that tend to drive better outcomes later in terms of market fit and customer value.

A Success Story

A few years back I was working with a company to create a replacement system. The old system had grown in use over the years such that it was integral to many facets of the company’s business all over the world. The team was behind and the problem was obvious: The rewrite was trying to be everything all at once for every user.

The product owner had heard the term minimum viable product in her two-day certification course but didn’t believe it applied. This wasn't a startup, and the rewrite needed to be high-quality and address all the current use cases, plus a few new ones. So I introduced the concept of “specifically marketable and useful” to the team. I asked them to think of all the people in all the places that used the system in different ways as a whole market with many segments. The new system would certainly need to address the “whole market,” but eventually, not all at once.

We worked together to brainstorm and break down all the various market segments. Then we stack ranked the top five according to value and risk involved. Next we story mapped out the number one segment into user goals, steps, and capabilities. By the end of the day, the team felt they had a reasonable plan and something they could demonstrate to users in a couple of weeks.

As time went on the team got better at identifying narrower specifically useful segments as well as demonstrating their work every few weeks. After a month they had released a pilot to a subsegment of users and got great feedback. Another month later they released their first MVP to the entire segment. The team kept up this cadence, releasing every few months to another segment while continuously incorporating user feedback and demonstrating something new every couple of weeks. After eighteen months—half the original schedule—the project was considered done.

The Problems with MVPs

An interesting problem I see arise with the term MVP is that many folks seem to think it’s only the first release—after all, only the first release should be barely feasible, right? Every release afterward should enhance the half-baked product. A fun question to ask in many organizations is “What is your second MVP for that product?” If you see perplexed faces, you know you're at one of those places where they don’t fully get the MVP concept.

This brings up another important aspect of MVPs (and second MVPs, and thirds, and fourths, etc.): They need to be releasable for both you and your customers. There is always some cost to an organization for doing a release. In the best cases, we have fully automated, push-button deploys with auto rollbacks that kick in if production business metric monitors exceed a certain threshold. (Yeah, I’ve never worked in one of those places either.) Typically there is some effort in the integration, build, and deployment processes. Many orgs still have some in-the-tail testing left to do, and of course there are all the other departments to consider—sales training, support and services updates, marketing material, legal review . . . the list can go on. If you have a very costly release process, you simply can't afford to ship very frequently. It’s not uncommon for these costs to limit larger organizations to only three or four releases a year.

Further, you have to consider the cost to your customers to receive a release. They may need to do independent validation. They might need to restart key systems. Perhaps they have to custom integrate needed third-party software. Or maybe your upgrade or install process is just painful for them, so they don’t want to go through it very often. No matter the reasons, your customers’ costs or needs involving a release also need to be considered.

The last problem I see with MVPs is that they can be very large. This can happen for any number of reasons. Sometimes it’s because a salesperson thinks they need every bell and whistle to be competitive. Other times its because product folks are afraid this is the only chance they’ll have to get their ideas into the product. It doesn’t matter why; MVPs are supposed to be small, and organizations should work on making them smaller and then smaller again.

To address this, I find the phrase feature sets helpful. Defining a feature as a specific capability in a product also helps. People seem to easily understand that we likely need some set of capabilities to address our specific market in a useful way in order to balance against our cost of releasing both internally and to our customers. Best of all, it seems to drive the size of MVPs down, and it helps us constantly question if a given capability is specifically useful for a market.

So, if we put it all together, an MVP should be thought of as a Specifically Marketable, Useful, Releasable Feature Set—or SMURFS.

Now, I don’t really think it will help to just rebrand MVPs as SMURFS. As soon as a simple moniker is created using easy-to-understand words that folks know, assumptions will be made, and then misunderstanding isn't far behind. So perhaps your organization can use the above advice as a guide to create your own brief definition and then assign it whatever label you like—although it would be fun to say, “Release the SMURFS!”