Instead of MVPs, Maybe We Should Be Releasing SMURFS


The term minimum viable product, or MVP, has come to be misunderstood and misused in many organizations. It doesn’t mean you should be releasing half-baked, barely feasible software. Instead, you should be thinking of your product’s capabilities as a Specifically Marketable, Useful, Releasable Feature Set—or 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!”

User Comments

Brad White's picture

I can see that the MVPs that we've done that were successful roughly followed this path, and the ones that weren't as successful went off the path at some point.

This is a great framework for thinking through the feature set for an MVP.


September 29, 2016 - 5:15pm
Brad Murphy's picture

While I agree with the sentiment and frustration expressed in this article about how poorly traditional companies employ MVP's, I can't be silent on couple of ideas that I think are very dangerous. Let me explain

The biggest and most dangerous issue with those promoting lean start-up ideas, is that 99.999% of the agile practitioners advocating these techniques have NEVER STARTED A COMPANY and risked their own livelihood and money...  

I'm a three-time entrepreneur and what I know from experience is that "small" is in the eye of the beholder...  Small is for speed, NOT striping out utility and value.  For any product to be successful you need to deliver something that is NO SMALLER than what a user/customer finds meaningful, useful, and valuable.  And here's the reality... Sometimes this is actually a pretty large set of features.   In the B2C space it's not uncommon to deliver something of great utility and value to a consumer that is very limited in functionality... sometimes downright simple.  In B2B, not so much.  So let's be VERY careful to encourage small as an "absolute".


Let me also add that today we also now have design and prototyping tools that allow us to engage prospective clients in simulated product experiences WITHOUT WRITGING A SINGLE LINE OF CODE.  Here in lies another issue with MVP… the idea that I “iterate” to a solution using developers and code to validate and refine my product.  FAIL.  The WORST possible way to validate products is using developers to write code.  Again, if you’ve ever had to start a product company and risk your own capital you navigate risk and product innovation very differently.  For me this is what we should be teaching our large companies… how to be entrepreneurs, NOT copy-cat implementers of someone else’s packaged “process” or method.

September 29, 2016 - 6:26pm
Brad White's picture


Your cautions are well founded. But if we are going to have a software product, eventually we are going to get to the point that we have to write some code. I assume we've valididate the overall concept by this point. The question the MVP is trying to answer is "What features should be in the first release?"

It seems clear to me that we shouldn't be writing code without an answer to that question.

I think the framework that Matthew is suggesting is an excellent starting point for the discussion. Open to hearing your improvements.

> For any product to be successful you need to deliver something that is NO SMALLER than what a user/customer finds meaningful, useful, and valuable.

Absolutely. And I think Matthew's suggestions are a great way of thinking through what is small enough but no smaller than useful.

When we released our initial Document Management system for banks, it was a significant amount of work, but focused on solving a single problem. Much smaller than our overall vision. Looking back I'd say we did a good job of unwittingly following the guidelines laid out here. And that's part of why we were successful. Banks ate it up. And gave us invaluable feedback about what they needed that was quite different from the requirements they were giving us before the release. That feedback radically changed the direction of the next release.

I find having this framework valuable because it makes it easy to communicate what features we are including/excluding and why.

HTH, Brad.

September 30, 2016 - 10:57am
Lev Ayzner's picture

How about simply recognizing that MVP could also mean M VALUEable ?.. MV&VP would cover all the SPURFS criteria; as well as potentially address Brad's very valid concerns for either small/startup or Corp brand environments.

September 29, 2016 - 10:13pm
Greg Fabian's picture

I agree with the author that the term MVP is fraught with danger. I’m involved in a similar project where we are replacing a legacy system using a hybrid agile-waterfall method to develop the new system. The current system is marginally serviceable and the new system has to provide comparable functionality (i.e., use cases). When one of our project managers used the term “MVP” during a stakeholder meeting, we had a revolt on our hands. We ended up backtracking and using the term “core” to describe the initial system release, which covers the same user stories as the legacy system. This project is a bit different because there isn’t a profit motive, but there is still a marketing angle to the whole release. We want all the agencies to use the software to address long standing data quality issues.

November 22, 2016 - 9:17am

About the author

AgileConnection is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.