How to build an MVP that matters

How to build an MVP that matters

In my two decades as a product manager, I’ve seen how much value agile tools can bring to software development. However, they’re often misunderstood and abused. Minimum Viable Product (MVP) is a powerful tool, driving production and cutting waste, but it’s often misinterpreted as “the lowest quality thing I can build.” In this article I’ll show how I’ve used the MVP process in my career and how I’ve built MVPs that matter.

---

Building a product means making trade-offs. You always want to build a product that meets three criteria: price, speed, and quality. Conventional wisdom holds that you can only have two of the three. This is called the Iron Triangle. As an example, think about buying a cake:

• Price + Speed: Buy a cake from the grocery store (sacrifice quality).
• Price + Quality: Bake the cake yourself (sacrifice speed).
• Speed + Quality: Buy a freshly baked cake at the local bakery (sacrifice price).

It seems like an intractable problem. Is there a way to build something great that doesn’t compromise?

The wrong way to view the MVP

My CEO at BigCo (he’s fictional, based on an old boss from a long time ago) bursts into my office. He has a solution! He tells me to build a Minimum Viable Product. “It’s awesome!” he says, “I went to this lunch and learn with our transformation team. All we have to do is create the smallest and cheapest thing to solve the problem. I…” he pauses and then corrects himself, “I mean we… will be heroes!”

“I know exactly what we need,” he continues.  “The company needs a new app.  It should be revolutionary—like nothing else in the market—and completely different from anything we do today. It should be a chatbot that analyzes all of the user’s communications on LinkedIn, analyzes them with ChatGPT, and then provides personalized advice on cryptocurrencies. We don’t have any additional money to invest in this, but that’s OK.  I know we can do this because Reid Hoffman says, ‘If you are not embarrassed by the first version of your product, you’ve launched too late.’. That shouldn’t be that hard to build right? You can get it done fast now that I’ve given you all the requirements.”

Our boss here clearly doesn’t understand Agile. In fact, as Reid writes in his article If There Aren’t Any Typos In This Essay, We Launched Too Late!, many people misunderstand his quote about being embarrassed.

Like most things in Agile, an MVP is about empowerment. Agile methodologies give us tools to help us get the job done more quickly and efficiently, but Agile is not a magic bullet that automatically gets us to the right answer. It’s as much a way of quickly identifying the right paths from the wrong ones. Agile is like anabolic steroids for athletes – they don’t automatically make the athlete stronger but let them train harder and recover better, so they become stronger over time. 

The CEO’s problem is organizational hubris. He’s used to decision making via the HiPPO (Highest Paid Person’s Opinion) method. He’s grown up where the boss tells everyone what to do. Therefore, the boss must know what to do. Why else would everyone listen to him? He must have some sort of intuitive customer understanding to make these decisions. But while bosses have honed many skills in their lives, they can’t predict what customers want. That’s where the MVP comes in.

The job of an MVP

An MVP is about experimentation. As Eric Ries says in Lean Startup: “An MVP 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.” In fact, an MVP is really an experiment and the form of an MVP changes over time. While product development is about innovation and creation, it can also be seen as an exercise in risk management. Each step in the process increases your confidence about what the customer wants and whether your solution will be successful.

As the product becomes more refined, we want to delve deeper into the following questions.

• Do they want it?
• Will they try it?
• Will they pay money for it?
• Will they continue to use it over time?

It’s important just to ask customers, “Do you want this?” in the early stages. It’s an obvious but often overlooked question. If a customer says that they don’t even want a feature, there’s really no reason to go further. For example, I once worked on building new types of credit cards. We were very excited about building a “Family Card”, where everyone could share points and all members could have different permissions. However, when we asked customers, they said: “This is great, but it should come as standard on all of my cards.”

Market research and customer research are great. But asking a customer for feedback only goes so far. As one of my friends once said: “If I ask my customers if they want a free pony, they will say, ‘Sure! I’d love a free pony’.” But once they realize that they have to pay for the pony, maintain it, and exercise it every day they are far less excited about the pony idea.

An MVP is really about making a specific promise to customers and delivering on it. It’s the simplest thing you can build that solves a customer’s needs. It’s tempting to try to build something with lots of bells and whistles, But that’s where Reid’s embarrassment quote comes in. You should be a little embarrassed by an MVP because it often feels too simple to solve your customer’s problem. But the simpler the promise to the customer, and the more targeted the solution, the better the MVP.

Take the case of Zappos. In 1999, Nick Swinmurn went to a San Francisco mall looking for brown Airwalk Desert Chukka boots. He looked for hours. One store had the right color but the wrong size. Another had the right size but the wrong color. He thought he could do better with an online shoe catalog. He could have shopped his business plan around to VC, building out a warehouse to store and ship the shoes. Instead, he built a website called ShoeSite where customers could browse and order shoes. But this was just an MVP—a test. When people ordered shoes from the site, Nick would go to the mall, purchase the shoes and ship them to the customer.

Zappos’ first MVP is so simple that looking back, it’s a little embarrassing. Nick didn’t even buy the shoes at a discount. But the MVP provided enormous benefits. It showed that customers were excited to buy shoes online. It also gave valuable feedback about customers’ pain points. Specifically, if a customer can’t try the shoes on, Zappos was going to need to provide an exceptional return policy—in its case, free two-way shipping and a 365-day return window.

Zappos was focused on one key thing – will customers buy shoes online and will this make their lives better? What one thing will you focus on in your MVP?

The magic of focus

There’s always so much to do, but a great MVP chooses one problem to solve and solves it well. Why do we care so much about focus here? Why can’t we just build the whole thing we (or our boss) wants built.

Imagine you have a birthday party coming up. You were working late last night and don’t have enough time to bake the cake for your friend’s birthday party. You have a choice. You can bake half of the cake or bake a half-baked cake. Baking half a cake is the superior solution. You end up with a finished product that works for the birthday party, you completed the task and people get smaller slices. People eat less and are excited for more. Baking a half-baked cake doesn’t work because no one wants to eat a gooey mess. Yes, you “tried your hardest” to meet the original spec but that doesn’t make it taste better.

I was working with a junior team of developers a few years ago. Our product had five different key use cases that our customers wanted. The team asked: “Why not tackle a little bit of each one for our MVP?” Then we could provide a full-service solution to make all of our customers happy.”

I said: “The problem is with expectations. If we release five okay features, people will say, ‘This thing doesn’t work that well.’ But if we go out to the market and say, ‘Hey! Take a look at this. It will solve this problem that you care about,’ people will keep coming back.”

I told them about the Head and Shoulders commercial from the 1980s. In the commercial, a man was on a date with a beautiful woman. Everything was going great until she saw the dandruff on his shoulders. Then everything went south. The tagline of the ad was “You never get a second chance to make a first impression.” If we built something and the first version didn’t meet expectations, they wouldn’t try it again. It’s one thing for our product to need a couple of nips and tucks and improvements, but we can’t be a product with dandruff on our shoulders. We need to be able to fulfill our promise to our users, even if that promise is smaller than they’d ideally want.

I told them the Zappos story. If Zappos had launched with what it ideally wanted in 1999 it would have to create a warehouse, a system to manage orders, and a huge inventory so that it could fulfill any order. This meant that it would be compromising on price, speed, or quality. It would have a product that doesn’t make anyone happy. Instead, it launched with something much simpler—basically just a list of shoes and an order form while Nick acted as “back office operations” himself.

Right after my lecture on Head and Shoulders to the team we had a big happy hour with some senior leaders. One of the junior members of the team told me that, while she’d met with a few seniors, she didn’t really get to meet as many people as she wanted. She was troubled, saying “I thought you said that you never had a second chance to make a first impression.”

I told her: “Your happy-hour performance was like an MVP. The people that you talked to saw that you were curious and engaged and really wanted to learn. Other people who didn’t talk to you saw this as well, even if they didn’t talk to you. You can build on these conversations next time. If you try to talk to everybody, you can’t give your full attention to anyone and you look like a person who was trying to just check all the boxes, that could’ve been a problem. Also, at a happy hour, as long as you don’t annoy people and don’t get horribly drunk you’ve done a pretty good job.”

Be careful: focusing too much on making a great first impression can lead you away from an MVP as well. Instead of building an MVP, you may end up building the full product. This is what Reid Hoffman warned about when he said you should be embarrassed by your first product. It’s not going to be perfect and you’re going to make compromises, but if you can solve customer problems and keep the promises you make to them, you will have a firm foundation to build on.

Takeaways

Building an MVP, or a series of MVPs, is about continually iterating and solving specific customer problems. Remember the following things:

1. You’re never going to do everything. There are always going to be compromises.
2. Instead of compromising on quality, cost, or speed, reduce your scope—focusing on the customer.
3. Focus on your customers’ needs, not what you want to build.
4. Make promises to customers and keep those promises.