Eye-opening insights from 700+ product managers & leaders.
Several years ago, I sat down with a group’s General Manager as she walked me through a new product launch. There was a well-defined timeline that started with a Minimum Viable Product, or ‘MVP,’ and ended a year or so later with something along the lines of ‘Version 3 Enterprise Edition.’ There were financial growth projections and hiring plans. There was a lot of excitement in the room. However, it seemed like no one actually understood what a Minimum Viable Product actually was.
I felt bad about being a little bit of a buzzkill.
“Just so we’re clear, that’s not an MVP. What you’re calling MVP is really Version 1.”
Maybe you could say my point was just semantics.
At that point, there hadn’t been many customer conversations, any mockups, or other kinds of collateral. There was a business plan and a marketing launch plan, though all based on the assumption that what they called the Minimum Viable Product was going to go off perfectly the first time around.
But as Alex Osterwalder points out in our eBook, “72% of new products do not meet customer expectations.” Unfortunately, but perhaps unsurprisingly, the product above was part of that statistic. If Version 1 was really an MVP, it might have been possible to avoid failure or to abandon the product before investing significant resources.
It’s hard to blame anyone. I think what often happens is that people throw around terminology and get caught up in the hype without taking the time to investigate what those terms truly mean for them.
There are a lot of resources out there that will define what Minimum Viable Product is and tell you how to go about building it. You can also find definitions for close alternatives, such as Minimum Viable Solution, Maximum Awesome Product, and so on. But before you focus on terminology and best practices, take a step back and evaluate what you’re trying to accomplish and where you are in that process.
Your goal is to build and deliver a product that offers some specific value for users. You can define value in many ways, but assuming you’re working at a for-profit company, the most direct measure is a customer’s willingness to pay. For non-profits or public-good services, you may need to assess that value through some other behavior (i.e., sending donations). But for now, let’s assume you’re creating a profitable enterprise.
“Plans are nothing; planning is everything.” – US President Dwight D. Eisenhower
So you’re at the beginning of the product development process. You have some general ideas about the market and customers. You may even have a few prototypes that you’ve gotten some feedback on. Whether you’re a new startup or an established company, what you do know is that building something of value at scale is going to take considerable effort and money. There are no sure bets, and every path forward entails some level of risk.
The difference between startups and more established companies is that you may have a bit more flexibility with building a product in a startup. Larger companies tend to operate with more planning and forecasting. But ultimately, for either organization, you have to minimize risk. You need some level of confidence that you’re on the right path before committing resources and capital. Perhaps more importantly, you need to make others confident in a development process that yields value for your customers.
So how can you do that?
The best way to minimize risk is to get actionable data, and the best way to gather that data is what is often called a Minimum Viable Product, or MVP. Eric Ries of Lean Startup fame describes a MVP as, “a version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort.”
I will just say that your MVP is the minimum investment you need to see if someone will pay for what you plan to sell. Maybe MVP isn’t the right term for this, but for the sake of familiarity, let’s stick with it.
Let’s look at 3 examples.
Steve Blank talks about two founders who wanted to help farmers better manage their crops by giving them regularly updated data about the health of their land. The data would help farmers assess whether to adjust water and fertilizer levels based on crop growth and if there were any diseases.
To produce these reports regularly, they needed to equip drones with camera technology (keep in mind, this is in the early 2010’s). They’d also need to create software to manage the drone and produce the reports. They asked Steve about his feedback on their prototype buildout.
He advised them to forget about drones and just to take pictures from a helicopter rental flight and to produce those reports by hand. Then he recommended that they review those reports with farmers to see if they found them useful enough to buy them. If not, then they could spend time with farmers, using those reports as a starting point, to see what they needed without building prototype drones.
As personalization became a big deal through the likes of Pandora and Netflix algorithms, some friends of mine had a few ideas to see if this would extend to food and drink. Some of them wanted to see if anyone would be interested in personalized granola.
They started thinking about how to recommend types and flavors of granola based on existing tastes. However, a professor suggested they first see if there was any interest in ‘customized’ granola at all. Was there any willingness to pay for granola that didn’t just come from the grocery store?
He advised them to put up a simple webpage where someone could choose their ingredients and to buy some Google ad traffic so people could find the site. When they got an order, they would just run to Rainbow Grocery store in San Francisco to buy what the customer asked for, mix it, and ship it.
They got a couple of orders but realized there wasn’t that much interest.
At a previous company, we built an add-ons marketplace to our Platform as a Service product that more easily allowed people to host their applications on AWS, Azure, etc. Before building a product that allowed users to add additional services and keep everything on one bill, we needed to see if there was interest. This was especially true as the marketplace would have significant billing and legal implications.
We first cut a partnership deal with an infrastructure monitoring company. We created a simple UI for a user to add the monitoring service to their infrastructure with some configuration. But behind the scenes, we were manually adding the service and manually updating their billing information. After we got some traction, we invested in building out a full marketplace with dozens of partner services.
People sometimes ask if MVPs are possible in enterprise B2B companies, and this is an example of one.
I chose these MVP examples because they not only focused on a product idea, they also focused on purchase intent. The easiest way to see if someone values what you’re making is if they give you money for it.
That said, it’s ultimately up to you what you want to achieve. I’ve seen others say an MVP can be a landing page where you ask for email addresses. I think this is a great tactic and you should consider it. But to be clear, what you’re doing here is validating interest, not value. Also, in this scenario, you may be appealing to the value that users think your potential solution may deliver, but not the actual value of a tangible deliverable. Either way, you’ll still need to develop an MVP to validate whether they value your product.
I said that an MVP is the minimum investment you need to figure out if someone will pay for what you need. You might think about it as the minimum “thing” you need. An MVP could be a working product, a prototype with fake data, a UI connected to a van outside the building where people are crunching data by hand, or even a PowerPoint presentation.
Whatever the minimum amount it takes to see if someone will pay money for it is your MVP. If you’re a consummate salesperson, your words alone may do the trick. Keep in mind that whatever tactic you choose, you should put in your very best effort to deliver on it.
Remember, a successful MVP isn’t a guarantee of long-term success. What you’re doing is minimizing risk and building confidence in your process to create something that customers value. You may restart the process with new data and new assumptions several times.
In a future post, we’ll go into some details on what we think goes into making a successful MVP. The reason I wanted to start with a definition is because I think people make the mistake of not determining what they need before starting the process. Whether you agreeor disagree with the way I’ve laid it out, you should still take time to figure out what your goals at the beginning of your journey. Figure out how you plan to minimize risk and maximize confidence in your long journey of product development.
. . .
productboard is a product management system that enables teams to get the right products to market faster. Built on top of the Product Excellence framework, productboard serves as the dedicated system of record for product managers and aligns everyone on the right features to build next. Access a 15-day free trial of productboard today.