Lately, I’ve been hearing from a lot of entrepreneurs experiencing pushback to the concept of minimum viable product. Their teams may disagree about what a product should look like, who the customer is, and which distributors to work with, but one thing they can all agree upon is: “We build high-quality products in this company. We wouldn’t even know how to go about building something ‘minimally viable.’”
How can we assure our teams that they won’t be penalized for adapting an iterative approach—even if the first version bombs? How can we make it clear that our goal is nothing less than delighting the customer? In fact, with an MVP we are not asking our teams to deliver low-quality work, we’re adopting a strategy for driving excellence throughout the organization.
An MVP is an experiment on the way to excellence.
When people hear the phrase “Minimum Viable Product” they sometimes forget to ask: minimum in regard to what? They worry they’ll need to do the same amount of work in less time by cutting corners. They fear they’re being asked to create a low-quality product that will put their reputation—or even people’s lives—at risk.
This is a misconception. “Minimally viable” does not mean operating in a sloppy or undisciplined way, building bad code that’s going to result in a lot of technical debt, or ignoring safety or health concerns. An MVP is not an excuse to throw our beliefs about quality out the window; it’s simply an experiment on the way to excellence.
Instead of taking one big swing with the launch of a new product—devoting months to the design of one technical feature or spending years in stealth mode developing a product without evidence that customers want it—it is an iterative approach to learn who the customer actually is, and what’s honestly required to delight them.
Why do we think that spending more time developing a product before sharing it with customers will get us closer to discovering what they really want? Or that mistakes are something to be swept under the rug? Who is familiar with a team that produced excellent work because they got less feedback and moved slower? Where is the evidence to support that belief?
An MVP approach can help us learn about what the customer truly values before we’ve invested too much time and money into building something they don’t need or want. Our work is not done until the customer is, in fact, delighted.
Of course, that’s easier said than done. But there are concrete steps we can take to create cultures of excellence in our organizations using an MVP approach.
1. Clarify what MVPs are and why they’re important. Remember, MVPs are just one part of an iterative Build-Measure-Learn process.
We use the term “Minimum Viable Product” as a reminder to people with product development backgrounds that we’re going to build something. We are going to take something to the customer that is as real as we can make it, but we’re not going to overdo it by trying to do something too elaborate. This is a built-in cure for the human tendency to over-engineer solutions.
It’s impossible to think about MVPs without remembering how they fit into the Build-Measure-Learn cycle:
- Enter the Build phase as quickly as possible with an MVP that will allow us to test a clear hypothesis we have about our product or strategy.
- Measure its impact in the marketplace using actionable metrics that help us analyze customer behavior.
- Learn whether our original assumptions about the product, process, and customer needs were correct or whether we need to change strategies to better meet our vision.
The Build-Measure-Learn feedback loop does not end once we’ve put our first product into the market. Every new launch of an MVP is an opportunity to gain valuable information about how well we’re meeting customer needs--and whether we need to adjust our strategy with a pivot.
2. Building a culture of excellence is our job as leaders.
I’ve long since lost track of the number of people who have given me excuses about about why the MVP approach “won’t work in our business.” Almost all of them have gone on to discover that it can, in fact, be made to work – in businesses as diverse as software, education, high-tech healthcare equipment and gas turbine manufacturing.
While every industry has unique challenges that make an iterative approach difficult, what teams are really saying when they balk at an MVP approach is they’re not willing to do the work required to run experiments. Creating hypotheses and then putting them to the test is never an impossible feat, but it is one that will require teams to work differently.
And that means nothing less than full support from leadership. That’s true in the tiniest startup and the world’s largest companies. New thinking requires a act of leadership.
As leaders, we’re responsible for creating and supporting the platforms that will allow for experimentation. We have to make sure that our teams have the right tools and insist the work be done iteratively. And we have to hold them accountable for a high standard of success: “Show me progress along the way, but remember that you’re not done until you’ve delighted the customer.”
Sometimes this means building infrastructure that makes experimentation possible: One way of doing this is creating an innovation sandbox to protect the rest of the organization from the experiment. For example, pick a few customers to experiment with and promise to pay them penalties for any kind of fault during the experimentation period. Or select a subset of your web traffic and divert those customers to a new experience. If customers are unhappy at any time during the experiment, the startup team has to promise to make it right. That often means engineers taking support calls and sales people working with existing customers. That’s a good thing, because it enhances the learning your team will get. It also gives your team the cover to work quickly; while you may lose money in these early days, you’ll have learned a great deal about what the customer really wants.
Often, it requires thinking creatively about what shape an MVP can take. One thing to keep in mind is that while every MVP provides some "quantum of utility" (to borrow Paul Graham's phrase) to the customer, there’s a wide range of MVPs. When your sales process is long and complicated, models and brochures can act as products. Even though they’re not “products” in the traditional sense of the word, they still offer us a chance to gauge customer interest by asking for some exchange of value, even if that exchange is not monetary. For example, we can ask customers to spend more time talking to us about the product, take part in a training program, or agree to recommend the product to other decision-makers in the buying process.
3. Cross-functional teams are key to delighting the customer.
Once we’ve set up the right conditions for experimentation, it’s important to create cross-functional teams who, together, can assess which features truly deliver value.
Say you wanted to run an experiment to test which aspects of a new appliance drive the most value. You couldn’t just send a salesperson because they would not know which features drove the most cost. Nor could you send a design team without knowledge of the supply chain or the current market landscape. This experiment requires a collaboration between the product designer, a salesperson, and someone on the manufacturing side. By working together, they can identify what drives cost and what drives value--when, prior to running such an experiment, you couldn’t really know what drives either.
It can be challenging to make the case that all functions should be represented at both large organizations where it’s difficult to get people assigned to any project full-time and at small startups where resources are scarce. But remember that the goal of Lean Startup methodology isn’t just to build a product, but to learn how to build a sustainable business: a cross-functional approach is key to this kind of learning.
Building a culture of excellence will also require rethinking the way you measure and evaluate performance. When evaluations are tied to functional performance, a good day is one in which everyone did their job well: Did engineers strive to create the “highest-quality” product or service? Did legal limit the company’s liability? Did marketing anticipate external trends accurately enough?
But if we build products we can’t sell or processes no one uses, it doesn’t matter if we executed on time and on budget. Entrepreneurs and general managers should not simply be content with functional excellence but strive for products, processes, and systems that delight our customers.
4. If a customer doesn’t like what you’ve made, that’s a discovery, not a failure.
Even after teams have grasped the concept of the MVP on an intellectual level, they often find it hard to pull the trigger on those first iterations; it takes them a while to set up those initial meetings with customers or launch their first MVP.
They can be held back by any number of worries: What if we show the customer something they don’t like? What if going in with a minimum viable product makes it seem as if we don’t know what we’re talking about?
As counterintuitive as it sounds, finding out that our minimum viable product is too “minimal” is good news. We can simply apologize, and use the customer feedback to build a new version that does meet their needs.
The good news about MVPs is that we can always make them more complicated as we go, so we might as well start simple and let the project grow in complexity until we have delighted the customer. If we do something we believe is too simple and customers agree, we can consider that a major win. It doesn’t mean the end of the project; it means we can use what we’ve learned to build the next iteration.
We don’t want to wait around for some mythical moment of perfection nor do we want to run around with no process. We use MVPs to test our strategy— if it’s not helping us achieve our visions, we need to make an adjustment.
If your team is concerned that creating an MVP will mean skimping on quality, it can be a good indication that they care about what they’re building. They recognize the importance of excellence and they strive to produce high-quality work —it’s why you hired them. This approach is not about asking people to ignore their skills, values and gut instincts about quality; it’s about making sure that they don’t waste their time and talent over-designing features that are not actually important to the customer. It’s about empowering your team to leave dead-end projects and activities behind so that they can invest their time into work that truly matters.
