Build minimum viable or minimum awesome?
MVP or minimum viable product is one of the more commonly misunderstand concepts in lean entrepreneurship. And it’s no wonder. The term “viable” means different things to different people and “minimum” is often misinterpreted to mean, “requiring the least amount of effort possible”. This couldn’t be further from the truth. Creating a quality MVP requires quite a bit of research, planning, and effort. But, properly implemented, an MVP is one of the best methods available to entrepreneurs to deliver quality products that customers want.
How things used to be done (And why you shouldn’t do them this way anymore)
To understand what a minimum viable product is we first need to establish some context. Before MVPs became commonplace most start-ups spent their time, often years, developing in secret fully realized, fully functional applications, which they then released and attempted to sell.
This approach is, at first blush, quit rational. If you were building a car wouldn’t you make certain every single system needed to make the car function as optimally as possible was in place before you sent models out to dealerships? You wouldn’t include wheels but no engine. You wouldn’t install a driver’s seat but leave holes in the floor where passengers might sit. You would build a finished car and then attempt to sell it.
The problem with this approach is that, assuming you don’t run out of seed money before bringing your product to market, you have no idea whether the product you’ve built for your potential customers is the product they want. Developers are smart people, certainly, but they’re not mind readers. It’s entirely possible that after years of development that shiny new product they’re proudly parading out to customers is a lemon, a spiffy, feature-rich failure that no one wants and that no one will ever buy.
MVP to the rescue!
A minimum viable product attempts to short circuit this quagmire of uncertainty by getting something in front of potential customers as quickly as possible in order to learn as much as possible about exactly what sort of product these customers need.
Put simply, the first version of your product doesn’t need to have every single possible feature implemented fully. It just needs to have a minimum subset of features that allow it to be useable by a portion of your potential customer base. This group, generally early adopters, is capable of understanding your vision for the product even in an incomplete form. As long as it possesses a rich enough feature set to allow it to address the central problem your product is designed to solve these power users are willing to overlook missing functionality. They’ll use your product and give you feedback. You can then use this feedback to improve your MVP, add features and then iterate.
Building a product through iteration
In order to understand how this works let’s return to our car analogy. Imagine they don’t exist and your start-up is trying to solve the problem of how to move people around quickly from place to place. Instead of designing an entire car from the ground up as we did earlier in the article we could instead develop a car MVP. We need only build a product with a minimum feature set to solve the proposed problem. We might take a plank of wood, screw axles onto the front and back and add some wheels.
Bingo! We have an MVP that moves people from place to place quicker than they could if they walked.
It’s car-like but not yet a car. It is a glorified skateboard at best. It fulfills the basic problem we’re trying to solve, so we roll it out to customers (no pun intended).
They buy it, try it out and give us feedback.
The early adopters generally like it but they tell us, among other things, it isn’t fast enough, it’s difficult to steer and they’re not fans of having to stand up.
We have feedback! We just learned very useful information about what our customers want without spending years building a fully realized car. So now we take that data and iterate. Maybe we add in a seat, attach the wheels to a steering mechanism and install pedals to allow faster movement. It’s still not a car. But Release. Get feedback. Iterate.
Are we done yet?
In the next version of our car MVP we replace the pedals with an engine. Release. Feedback. Iterate. We go from two wheels to four for increased stability. We enclose the passenger area to keep out the elements. Iterate. We improve the engine for greater horsepower. Iterate.
You get the idea. By the end of this process 
we have a function-rich, fully realized car built incrementally with constant feedback from our end users. By the time our car is released we’re about as certain as we can be that it’s exactly what our customers want because they’ve been involved throughout the entire development process.
In a nutshell, that’s MVP. Products are developed with only those features that are absolutely necessary for the savvy user to get it and give us feedback on how to proceed. After multiple iterations, each round improving existing features and adding new ones for testing we arrive finally at a finished product that does exactly what it needs to in exactly the right way. We know our customers will buy it because in a very real sense they helped develop it.
Should you build viable or build awesome?
We started this article off talking about how many people interpret “minimum viable” to mean, “requiring the least amount of effort possible”. This misunderstanding has led to some pretty lousy MVPs because their creators focused too much on “minimum” and not enough on “viable”. They didn’t put enough effort into thinking through exactly what their customers needed from a minimum viable experience in order to see the vision and appreciate what the product might eventually do for them.
As a result, a contingent of thought leaders in the industry have called for a nomenclature shift. Instead of “minimum viable product” they’ve coined the term “minimum awesome product” or MAP. This new way of thinking better captures the spirit of the MVP. It isn’t about delivering a barebones experience that leaves your customers confused and dissatisfied. It’s about providing them a great experience, built with just the features needed to test the current product hypothesis. Your MAP/MVP isn’t complete. That’s explicit in the idea. But it shouldn’t FEEL incomplete.
I am not a fan of this kind of visuals as example, because that is kind of cliché, however, like they say, it is a cliché because it is true!
And there’s another reason to consider MAP versus MVP. A minimum viable product is fine in situations where there’s little competition, where users have no pre-existing expectations.
But what about situations where products like the one being developed already exist?
In this case you need to include these pre-existing expectations in your design. It’s not enough to include only basic viability. You need to make sure your user experience stacks up to what users already imagine it should be. And the greater the density of competition, the more awesome you need to make your MAP. Otherwise even early adopters may ignore you.
Consider our car analogy again. Midway through our iterative process earlier we created an MVP product that functioned like a bicycle. If bicycles didn’t already exist then no one would have any expectations for how they should look and feel. You could get away with two wheels bolted roughly to a single metal bar with a plank on top for a seat. But ask yourself if that would satisfy a customer that already had experience with existing bicycles. The answer is a resounding, “no”. In order to satisfy these customers your design needs to be elevated to match their pre-existing expectations. This, in simple terms, is the difference between an MVP and an MAP.
The thing to remember about MAP is that it still agrees that an MVP, in terms of features, should only include those needed for minimum viability. What’s in question is the user experience, the look and feel of the product. With MAP, you need to give this more love than you might with a classic MVP implementation. But otherwise the concept is very much the same.
The market is saturated and there are hardly any new ideas. What that means is, your product needs to kickass, and has to offer a better user experience than other products out there.
Again, think of the car companies. Every company tries to lure customers by offering a better model than their competition at an almost similar price. If they don’t do it, how long do you think they can survive?
The same logic applies to your startup. If you are trying to build a product where competition exists, you have no choice but to make it awesome. Now, that doesn’t mean that you need to spend drastically more efforts, time and money on making your product awesome. It all starts with planning and research. You need to keep your user in the center and then start thinking around their pain points and possible solutions. In other words, listen to your users and focus on delivering an awesome user experience. It won’t cost a lot, but the number of users adopting for your product will definitely be significantly higher.
So, what are you waiting for? Get iterating!
MVPs, or MAPs if you’re feeling saucy, are the best way for a start-up interested in controlling costs to deliver quality products that they know their customers are interested in. And now that you understand exactly what goes into an MVP you’re ready to get your team working on one for your customers. So get started, and happy iterating! If you need help defining your MVP, feel free to schedule a call with our experts.
