The Art of the MVP: Creating Technology that Resonates with Customers
We all want to create something people want. Yet, how we do that seems to be a holy grail kept only for the few. Like other things we explore in this substack, building something people want has been buried under years of rebrands, pivots, and intentional obscurity to push out competitors.
Through all of that, there is one approach that has become quite popular and because of that, has felt more of the pains from rebranding than others. In the hopes of clarifying it before it's rebranded into obscurity, we'll explain it today.
The approach is - at its core - shipping your product and learning from your customers.Â
That's it.
The difficulty comes in the difficulty that is reality. If this were a tweet, I would perhaps leave it at that:
What's an MVP? Ship your product and learn from your customers.
Luckily, it's not a tweet, so we can actually explore this difficulty and perhaps make it easier.Â
And yes, we're talking about the idea of an MVP, a minimum viable product.
Minimum Viable Products... They have to be one of the most controversial ideas in tech community. Belief in them takes on cult-like attributes. If you're an Apple acolyte, then you likely believe Apple would never approach something as an MVP; there is too much soul in their products, and so you shouldn't either. If you're more of a Google acolyte, you may embrace the idea of an MVP. No company leaves their products in beta longer than Google.
We'll explore how those beliefs are wrong and how Apple is perhaps the best company in the world at shipping a minimum viable product. But first - what is an MVP, and why is there so much confusion around it?
The idea for an MVP was originally created by Frank Robison in 2001, but later popularized by Eric Ries and Steve Blank. Currently, Eric defines it on the Lean Startup website as:
The minimum viable product is that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort.
As far as explanations go - this is pretty *ok*. It describes it well but leaves too much flexibility. Where it is lacking is not in accuracy but in precision. Like all explanations, once it is out in the world, you no longer own it. And the ambiguity around it has led people to interpret what an MVP is with great liberty.
As I summarized above, this approach to building what customers want is simply shipping something and learning from your customers. The refinement that Eric is bringing in here is trying to answer the question - how much of your product do you build before you learn?
His answer? As little as possible.
And that's correct, but still confusing. Mostly, this is because a product is not a straight line. Building a product is more like a choose-your-own-adventure game that never ends. When you bring in the idea of maximizing learning as well, then you have another important but ambiguous variable to deal with.
Depending on the product, you could spend two years building it because taking that long would allow you to learn 500x what you could learn by spending two weeks building a product. A pretty decent improvement on the return of spending two weeks.
In reality, the ability to learn probably looks something like the following:
There's a minimum amount you can learn without building anything. This is actually more than people think - a simple landing page can be a fine signal sometimes. But, at some point, and for some products, you actually have to ship something. Then there's a steep leap up in the ability to learn after you've shipped something. It likely continues to rise after that point before flattening out. So, being at the end of the graph isn't really any better than being early on it. Not to mention that you benefit from compounded learning through each thing you ship. So, shipping earlier provides more ability to learn again in the future.
The difficulty is that you don't know what this graph looks like for you. The graph also changes depending on what you build. There is a way to shorten the early part of that graph, say from two months to one week. And there is a way to increase the learning at every point along the curve drastically.
The ability to alter this graph, is really the nuance in an MVP.Â
The worry those have who push others to ship MVPs is that they are worried a team will spend 3x the time on a project as they should spend so they learn the same as they could have in 1/3rd the time. They don’t want to end up at the far right of the graph.
The worry of those who push against an MVP is that they believe the beginning part of limited learning is far longer than most will admit. They’re skeptical that they far left part of the curve will only move up once the product is complete.
Expressed in their own words, it boils down to something like this:
"You're wasting time building stuff nobody cares about. Just ship, and learn."
"If we ship what we have, we'll learn nothing. It's an incomplete experience, and users will know that."
They're both right. This is because we've missed sight of the goal. You're trying to build something customers want and will pay for.
To do that, you have to take the most important first step. One that's so easy to miss.
What do you think customers want?
You must have a view here. The more time you spend clarifying that view, the better. Let's move out of the abstract world of software and into the physical world to highlight this.
If you are looking to build a restaurant, there is some minimum version you could build to validate whether or not people want to dine at your restaurant. But you must understand what customer you are trying to serve.
If you are creating a low-end fast-food restaurant, the minimum version might be a cart on the side of a busy walkway with one dish. You'll find out quickly if people like the dish. You don't need chairs, you don't need a menu, you might not even need a sign.
This is completely different if your belief is that customers want a luxury dining experience. If that is your belief, you must have the core elements of a luxury dining experience. You must have chairs, you must have well-trained waiters, etc.Â
You can still launch with an MVP, though. Where you turn the dial down is different. Maybe you still have a limited selection. This time, instead of a single dish, it is only a tasting menu, with no improvisations off of it. You likely start with a smaller space as well and keep your wait staff to a minimum. Highly trained but very few. Everything you create goes into ensuring people walk away with an idea of "luxury." But that's it. Nothing extra.
You'll realize that nowhere in either of these two examples is the idea of a 'bad' product, a half-built one. This is such a common misconception of an MVP. The argument that Apple doesn't ship MVPs often tries to prove itself through pointing out that Mac laptops actually have all the keys you'd expect on a keyboard.
This is ridiculous. Like the luxury restaurant, an Apple product must ship the product that actually accomplishes what they expect the customer to want. Even when shipping and MVP. When the iPhone launched, it did not have copy/paste, but it did have an incredible touch screen experience and the ability to make phone calls. Like the luxury restaurant, they left the metaphorical oyster fork out of the experience yet remained focused on delivering the true core of what they thought the customer wanted.
You can choose any of the rebranded names out there for MVP - "minimum lovable product," "minimum desirable product," or whatever else the next rebrand happens to be. If you choose this method for validating what customers want, the important thing is to remember that it is just that - a way to understand what your customers want.
So - by all means build an MVP. Use that as your method to validate whether or not your customer wants your product. As you do that, remain focused and true to what you think your customer wants. Be clear about it. If they want a delightful experience - build that. If they need to actually just get one thing done - build that. If they just want to eat, build that. Then, build that and only that.
Have your own thoughts on MVPs? Agree? Disagree? Other questions? Just respond to this email, or let me know at me@joewilkinson.me. I read every one.