This article originally appeared on The Next Web
“Minimum” is a strong word… and not one usually associated with a good product. Yet lately, the term “Minimum Viable Product” is thrown around as widely accepted advice for startups. Is there truth to this, or is it just another fly-by-night trend?
That all depends on who you ask.
The idea is this: a company without the resources to fully realize their vision should release their product prematurely with only the minimum features. By making it public, they will be able to receive feedback and criticism on their work early — saving time and money in future development since they have a clearer end-goal — and the sales may also help raise funds for the finalization of the complete product.
But MVPs raise a lot of questions, not to mention objections. What is the right level of quality to include in an MVP? How much time should you spend on it? Will your users get onboard, or will they jump ship?
The MVP vs. the EVP
Rand Fishkin, co-founder of Moz, states his opinion bluntly when he says, “MVPs kinda suck.” Like many other entrepreneurs, he doesn’t believe in releasing a lesser product, even if it does generate valuable production data or earlier profits. His philosophy is that companies should only release EVPs: Exceptional Viable Products.
But how would a low-resource, low-funding company find the means to do that? Fishkin suggests creating an MVP, but not releasing it publicly.
Instead, keep it in-house, dogfood it with your team and maybe a few select customers, and compile your data that way. Fix the bugs, discover which additional features would help, and only when you have something remarkable — “exceptional” — do you release it to the public.
Fishkin admits that, yes, this does take more time and energy on the part of the company, but it will be. “Don’t be minimum,” Fishkin told us, “Be exceptional.”
It’s a strategy that I’ve recently become very familiar with. At UXPin, we started back in 2011 making paper prototyping notepads for designers. These notepads were our MVP for testing the assumption that designers needed a simpler solution for wireframing and prototyping — even if it wasn’t some sexy digital wonder-program.
As with all product endeavors, the execution was more difficult than imagined. We went through multiple rounds of iteration on small details: making sure the typeface showed up crisply on paper, checking that we left enough room for comments, and sizing and resizing our tearable grids to make the best use of the 8.5” x 11” size.
We went through all the trouble not because we knew what an EVP was, but because we honestly didn’t know any better. Thinking back now, our MVP really was an EVP because the paper notepad was a small product idea (not even terribly sophisticated) executed with extreme thoroughness.
By focusing on quality over scope, we were able minimize our resources and still get cleaner feedback on our hypothesis.
But why go through all that extra trouble when the general public can “test” the product faster and without wasting company resources? Because you always want to impress your customers, and releasing a “minimum” product might essentially scare them away.
“The problem with Minimum Viable Products is that they are very rarely worthy of dramatic praise, very rarely produce exceptional value, and very rarely earn the attention of the influencers & amplifiers (or at least the early adopters) critical to getting traction.
And yet, that’s exactly what a startup needs. You want people to get religious about their love for what you’ve built – so much so that they devote real time to evangelizing your company.”
And Fishkin isn’t alone in this perspective. Steve Blank, a serial-entrepreneur and author/lecturer on MVPs, insists that influencers and amplifiers — not just any user or customer — are critical for getting the traction necessary for startups to succeed.
To be fair, Blank has a softer view on MVPs than Fishkin. He believes that releasing what he calls a Minimum Feature Set (essentially the same thing as an MVP) is a great way to sell your vision, but it’s not a scaleable product in-and-of itself.
As Blank states plainly, “Most customers will not want a product with a minimal feature set. In fact, the majority of customers will hate it.”
Then what’s the point? Under Blank’s ideology, his version of the MVP isn’t meant for regular customers, it’s meant for Earlyvangelists.
The Earlyvangelist (early adopter + internal evangelist) is, according to Blank, the only justifiable reason to release an MVP. As described in his own words:
“Earlyvangelists are a special breed of customers willing to take a risk on your startup’s product or service. They can actually envision its potential to solve a critical and immediate problem—and they have the budget to purchase it. Unfortunately, most customers don’t fit this profile.”
But, if you’re experimenting with the MVP strategy, it seems important to be able to identify this special breed of user. Blank further explains that an earlyvangelist has five telltale characteristics.
- They have a problem that, presumably, your product will solve.
- They understand that they have this problem.
- They have already been actively searching for a solution, and are under some kind of time constraint to find it.
- The problem has affected them so much, they have already tried an (ineffective) interim solution.
- They have, or can quickly acquire, the money necessary to afford a product that can solve their problem.
But the thing to remember is that earlyvangelists aren’t buying your product, they’re buying your vision. No one is under the assumption that the MVP is the final solution.
The main danger in MVPs is that a deficient product will not impress anyone, neither normal users nor earlyvangelists. Although they may help with initial visitors and signups, users and customers — especially influencers and early adopters — are hardly loyal to mediocre products.
Products that fail to hit that “A-Ha” moment will churn their user and customer base as quickly as they acquired them.
In our case, I think our earlyvangelists really bought into the vision behind the notepads. Sure, the notepads were helpful, but they more importantly represented an almost stupidly simple approach to putting design ideas in front of someone quickly. It was more professional than drawing on a napkin, and less cumbersome than diving into Photoshop or Axure.
Luckily, our first customers responded pretty well to our vision of a simpler yet crisper design process — our first batch sold out in under 48 hours.
The Magic Mouse example
Now let’s look at how one user described using Apple’s Magic Mouse compared to an alternative product, MagicPrefs. Brian Donohue recounted his experience in a true tech-enthusiast fashion: the graph.
While Brian had no initial expectations of the Magic Mouse, he ended up loving it because of a feature he didn’t even know he needed. In his eyes, Apple creates a truly delightful technology — a mouse with a trackpad that can support several different gestures and actions — by limiting the functionality to a small percentage of what it’s capable of (i.e., displaying dramatic design restraint).
At the same time, MagicPrefs released a similar product, this one with higher expectations for what a user can do and, therefore, a higher risk of disappointment. Right away, one of the problems was remembering how to use all of the various features that set it apart from the Magic Mouse.
Sure, a devoted power user will adjust their habits to optimize the additional benefits, but odds are the everyday consumer will just buy the simpler version with the same delightful twist.
The moral of the story is that Brian — and many, many other users — stayed loyal to the product with the “A-ha” moment. In a sense, he was an earlyvangelist: he had a problem, he used an experimental product, and liked it so much he described the experience in his blog.
Because the MagicPrefs mouse was not yet a “ready” product (too many functionality problems), it failed to hit that “A-ha” moment and failed to win over its customer base.
A lot of bad cake vs. A little good cake
In order to illustrate a point about successful customer experience in the short- and long-term, Brandon Schauer, CEO of Adaptive Path, shared a framework he’s used over the years to help teams. He detailed two drastically different approaches, the Dry Cake model and the Cupcake model, highlighting the superiority of the latter approach.
In the Dry Cake model, the more common of the two, product teams start with a very basic product that may not be very interesting — like a plain dry cake. Then, as their resources expand, they are able to add new features such as icing or filling to get a more interesting and complete end product.
While it makes great sense operationally, it’s problematic from a competitive and customer perspective. As Schauer puts it, “cake with no filling or icing isn’t that appealing. Plus, anyone can just make a cake.”
In the Cupcake model, product teams start with a smaller yet complete product that — as anyone who was once a child knows — is far more desirable. It has all the appeal of a complete cake, icing and filling, etc., but its production costs are much lower.
People want a complete product, and they’ll pay for it. Plus, selling a Cupcake product also sets you apart from the bland or chaotic alternatives.
“The MVP has been (ab)used as a justification for sub-par product experiences where quality is sacrificed on the altar of speed,” says Stephen P. Anderson, UX consultant and author of Seductive Interactive Design.
“If you’re building something entirely new, a buggy prototype can be good for learning. More often than not, though, you’ll be competing in mature spaces where others have already set the bar for quality and a poor experience can produce misleading data.”
The Cupcake Theory is in essence an application of Fishkin’s EVP concept. Even thinking literally about the concept, you realize that a beautiful gourmet cupcake is much more exceptional than a bland cake.
If you’re truly first-to-market (e.g. you invented the concept of cake), then you might be able to get away with releasing something blander. But if you’re coming along as the underdog, as it seems most companies are nowadays, skimming on quality can be a death sentence.
Groupon is a perfect example of the Cupcake Theory in practice. In the Guide to Minimum Viable Products, we describe how the company started as a WordPress blog and hundreds of manually emailed PDFs. When enough people signed up for a deal on the WordPress blog, Mason’s team would manually send them the coupons via Apple Mail.
It wasn’t pretty, but it was a complete product that delivered the same value as today’s Groupon.
Utilize networks — but don’t rely on them
It’s easy to see that the major flaw in most MVPs is the disregard to quality. Gerard J. Tellis, a professor at the USC Business School, explains that product quality has become greatly important in recent years. It has not only eclipsed network effects, but has done so to the point where network effects now reinforce quality by driving users and customers to higher quality products.
He noted that brand loyalty — and, therefore, network effects — were so weak that market dominance tended to shift every few years in various industries.
If you want to inspire a user to share your product with their friends, family, peers, etc., you must first capture their heart and mind. Beyond rigid buying processes, security, and user management constraints, many business applications traditionally haven’t been that viral, in part because they failed to make the end user care.
These products were not quality: they were far from pretty, they weren’t easy to use, and they were completely forgotten by 5 pm.
That’s now changing, but mostly because business apps are building for the user as much as for the overall business. Remember that every time you have a meeting about increasing your K-Factor.
A complete product trumps complete features
Product quality extends beyond aesthetics or technical breakthroughs. There is a component of deeply understanding your user, of considering even the tiniest aspects of the product, and of capturing the loyalty of an individual user — not necessarily a network of followers — through adding real-life value.
This requires building a complete product as the first version, an EVP, that can be expanded and improved continuously. If you’re building a partial product with the plan of adding distinct layers on top later, then you’re making a dry cake and should get used to the taste — you’re going to be eating it for a while because no one will buy it.