Jon Pittman says this about MVP in his Medium post: “engineering and business culture often focus (sic) on minimum features and forgets the viability part.” While I don’t think this tendency is limited to engineering and business culture, I agree that too many product development teams misuse MVP this way.
While approaches deal with that in different ways, I feel like they overlook one crucial thing…
However we choose to make an MVP, we need to make it meaningful.
Lean Startup, Summarized
First, some quick background. MVP stands for “Minimum Viable Product,” and it refers to a key component of the Lean Startup methodology. Lean Startup is a process for developing products by validating assumptions at every step of the way.
Instead of spending years and millions on developing a huge product that might fail, show something cheap to a small group of people and see if it works. If it fails, the losses are small; if it succeeds, make it a little bigger and keep trying. Check out Eric Ries’ book for more.
Jussi Pasanen’s MVP Pyramid Model beautifully illustrates the issue. On the left, we have the broad “many features, none of them good” approach. On the right, we have the “fewer features, all of them delightful” approach.
Jon Pittman’s Medium post is an appeal for us to strive for “romantic quality” when creating an MVP, the right pyramid. Other folks say the same thing, but refer to the idea as “minimum delightful product.”
While I agree with the “fewer features, all of them delightful” approach, its focus tends to be limited to how we make products. What people tend to forget is the step before that: which products should we make?
Let’s Make Meaningful Products
We make stuff to solve people’s problems, and meaningful solutions improve people’s lives in some way.
If a product isn’t meaningful for people, no amount of great design will make it successful.
Foursquare is a great example of this. A few years ago, they created a well-designed app and pioneered many of the gamification mechanisms we still use now. While they grew quickly, people eventually lost interest, because most didn’t see the point. Foursquare wasn’t helping them in any way.
Thankfully, the company pivoted and is successful again, because they re-evaluated what is important to people and adapted accordingly.
Make it Meaningful
Jussi Pasanen’s pyramid model reminded me of a similar one that Stephen Anderson presented back in 2006 with meaningful at its peak. Here are the two models combined.
The difference is subtle, but it’s also critical to a product’s success. If a product isn’t somehow meaningful, it won’t be successful.
Good news: the path to a meaningful product is validating your assumptions.
Most assumptions in product development revolve around these questions: which problem do we want to solve? Do enough people have that problem, and are they willing to pay to have it solved? Does our solution actually solve the problem? As LinkedIn founder Reid Hoffman puts it, “Getting engagement with members and seeing what is actually important is completely key.”
The Path to a Meaning
He goes on to say, “If you’re not embarrassed by your first product release, you’ve released too late.” Some think this means that an MVP should be what Adam Berrey calls a “very crappy product.” That’s a misconception!
The point of an MVP is to learn, so we need to give it the key parts that the product needs to address the customer need. That way, we can first validate the problem, then validate how our solution fits the problem. Only then can we start working on a marketable product and validating whether the product fits the solution and the market.
Henrik Kniberg illustrates this beautifully. The point of an MVP is to learn about our customers’ underlying, meaningful need by building the cheapest and fastest thing that addresses what we think that need is. Then we give that thing to customers, let them use it, and learn from their feedback.
Eric Ries uses Zappos (the online shoe marketplace) as a wonderful example of what he calls a concierge MVP. They didn’t start with a crappy website with crappy customer service and crappy shoes. “They went to local shoe store, took pictures of each of their products and put them online. If anyone bought shoes from them [at this early stage], they planned to go to the store, buy the shoes, and mail them to the customer.”
The point is that Zappos didn’t build warehouses, buy a fleet of trucks, or set up a logistics team. They needed to validate the assumption that people need to buy shoes without going to the store. So they gave customers a “scooter,” a simple website with only a few pairs of shoes. People could experience buying shoes without going to the store. And if people didn’t need that, Zappos could easily try something else.
Give People What They Need
In other words, before getting too caught up in the details of your design or engineering, validate your problem. And when you’ve done that, validate your solution. Understand what people really need, and the rest will fall into place naturally.
Any thoughts? Get in touch!
Special thanks to @Almar for inspiring this post.