Don’t Build a MVP!
A popular term in the startup world is MVP, or Minimum Viable Product. An MVP is the simplest version of your product that’s capable of demonstrating the value you have to offer the customer.
A common mistake people make with an MVP is to build something that’s too focused on the mechanics of the task. It might help people accomplish the task, but it’s not easy to use, and it doesn’t generate delight. Consider the illustration below:
Most people think the MVP just needs to be viable. They ask themselves: “Does it prove people can accomplish a task?” They don’t think about making it useful, useable, or delightful. They think it’s okay to add usability and delight later on. You can do it that way, and people have, but there’s a better way.
The best MVPs deliver value on all four levels from the start. Sure, they deliver the raw utility of accomplishing a task. They also do it in a way that’s easy and intuitive for the user, and they add a little bit of delight in the process. Brian Chesky and Joe Gebbia, two of the co-founders of Airbnb, said when they first thought about the level of service they wanted to provide, they asked themselves, “How do we take it to 11?” In other words, how can we create an experience that really dazzles the user? What would make the experience so good the customer wants to do it again?
What would you rather someone say about what you’re building?
- “I used this app and it worked.”
- “I used this app and it was awesome!”
You need to start with a sliver of viability, usefulness, usability, and delightfulness, and as you iterate and improve on the product, you want to build sideways across the pyramid to add more of each attribute with each update.
The Minimum Delightful Product
Instead, consider how you can build a MDP: Minimum Delightful Product. What is the smallest thing you can build that not only helps someone accomplish a task and generate value but is also fun to use, something that brings a bit of joy into their world?
Delight helps people build an emotional connection to your product. As we all know, people are automatically attracted to products they enjoy using, even if they lack features they might want. Any time you can build a product that is more enjoyable than your competitor’s product, you’ll have the advantage.
The Zappos mobile app shows us a small way to add delight. When a Zappos VIP logs into the app, it rains VIP badges from the top of the screen. Totally unnecessary. A little silly if you think about it, but it adds a tiny bit of delight to the experience. Another example is when you add an item to your cart, you’ll see an animation of a cat wearing a parachute with a box that falls into the cart icon and updates the quantity of items in the cart. They could have easily just added to the number on the cart icon, but they chose to add a little bit of delight. Ask yourself, how can you add delight to your product? Where are the tiny opportunities to make something that will put a smile on the users’ faces? Take those opportunities when you can. They might feel silly now, but those little differences add up to create a memorable experience. That said, don’t overdo it. Too many little things aimed at adding delight can be too much and feel like a cheap gimmick instead of an enhancement to the experience.
As Thin as Possible
In this age of technology it’s really easy to think about building a piece of software to solve almost any problem. The “there’s an app for that” mentality is pervasive. What most people don’t realize is exactly how expensive software can be to build. The good news is you don’t have to build software right away in many cases. A lot of what products and services do behind the scenes can be delivered manually by a human being. In the early stages of product development, I’m giving you permission to cheat. You can create manuware, which is a term I just invented to describe creating a product that might look like software but is actually powered by manual labor behind the scenes.
I recommend starting this way because it’s cheaper, faster, and will teach you a lot. It may not seem cheaper because you or someone on your team will have to do a lot of manual labor. But putting in all that manual labor will tell you what works and what doesn’t work, and what repeated processes make sense to be replaced with code. When you go to build your first piece of software, you’ll have a clearer target to hit, which lowers your risk and saves you money.
Of course, there are some types of products and services where you can’t do things manually because they’re predicated on the underlying technology itself, like a complex data analysts or a machine learning algorithm. Obviously, that’s a bit different. However, even in those instances, you don’t have to build a lot of surrounding software to deliver the core value of the product. In the beginning, your goal should be to simply deliver an MDP to your customers, not a fully finished one.
After all, software is never finished. Never.
