The concept of "Minimum Viable Product" has made its way to the heart of startups. Largely through the work of Eric Ries (The Lean Startup, #leanstartup) and Steve Blank (Customer Development, #CustDev), the MVP is a key product development strategy for early stage companies. If you're not familiar with this concept, the idea is to build the simplest thing possible to test the waters before going all in on the larger project.
Even though startups around the world are making use of MVPs, there are lessons to be learned for CIOs and IT Pros in larger organizations. Let's break down the essential ideas behind the MVP.
First, a Minimum Viable Product is a mechanism for testing the fundamental assumptions that need to be true for the product to have any chance of success. It allows you to make the smallest possible investment to validate those assumptions before you invest in the larger project. For the Minimum Viable Product, the hypothesis replaces the requirement.
Second, a Minimum Viable Product doesn't even have to be a product to test hypotheses. Probably the most famous example is Dropbox. The company used a video to test the validity of what it envisioned. When the video went viral, it knew it had something. Zynga (the social gaming company behind Farmville) uses a very disciplined process for testing new game ideas. It uses landing pages that have a measurable call to action. If a sufficient number of users express interest, Zynga builds a simple version of the game to further measure interest and iterate features from there. Clickable prototypes are another way to create MVPs. Build out the basic idea as a set of linked pages or even a simple HTML mockup. Put it in front of potential users and see how they react.
Third, MVPs are useful when you have some fundamental uncertainty that you need to overcome before heavily investing in the larger vision. While "extreme uncertainty" defines a startup (according to Ries), larger companies face uncertainties in a lot of their customer-facing systems. When those uncertainties are fundamental to the success of a new system (or a significant enhancement), you can use MVPs to help determine if the larger investment is warranted.
How can larger IT shops put Minimum Viable Products to work? MVPs are useful in the following situations:
Leaps of faith. When your company is contemplating a new system, but there are some grand assumptions that, if wrong, would sink the project and never allow it to be successful. For any project in the queue, ask yourself, "What's the leap of faith we're making that, if wrong, would mean wasted time and effort?" There is probably more than one leap of faith for any major effort.
Prioritizing enhancements. Let's say you have a list of possible enhancements for a product, but you're not sure how to prioritize them. MVPs are ways to test and prioritize. Start by looking at the list of enhancements and ask the leap of faith question for each one. This will provide you with a shorter list of assumptions you need to test.
While the MVP is fundamental to how we now think about startups, peeling back the onion on the concept opens up many possibilities for larger companies. Many projects face some level of uncertainty and leaps of faith that could determine whether the large investment is worth it. It often doesn't take a big investment in the whole thing to prove out the basic assumptions.
RE: Minimum Viable Products Are Not Just for Startups
"The key contributors to an out-of-control burn rate [are]1) hiring a sales force too early, 2) turning on the demand creation activities too early, 3) developing something other than the minimum feature set for first customer ship."
Brilliant Article & the excellent explanations Greg. My organization experienced significant losses by committing these first two mistakes. But, the main reason for the very aggressive marketing to earn most of the market shares & prevent the new entrants, which eventually lead to blunders. I wish I had gone through this valuable knowledge earlier.
kstaron: Your question gets to the heart of the confusion around MVPs -- the tension between the words "minimum" and "viable." How you decide what is minium and what is viable depends entirely on sound business judgment and your tolerance for risk. If you are launching a product into an already competitive market, then what is "minimally viable" is going to be a lot more than if you are in completely uncharted waters. (Check out this post at Groove about MVPs and competitive markets.)
To me the key is being brutally honest about your assumptions -- what has to be true for my product to be successful? Write them down as precisely as possible. Typically, these will be assumptions about "value" (does anyone find what I'm doing valuable?), "money" (will people pay for that value, and how much?), "scale" (are there enough of these people and can I sell to them profitably?), the list goes on. Prioritize these assumptions. For instance, if you've proven value but not money, then start with money. Maybe you've proven value and money but not sure if there is enough of a market out there (scale).
With these assumptions in hand, you need to assess your risk tolerance. What level of certainty do you need to declare your assumption valid and move forward? 90%? 50%? Then decide what MVP gives you that desired level of certainty. Maybe it's a few users reviewing a prototype; maybe it's an actual product. The key is to always ask yourself, "What do I need to know and what will give me the level of certainty I need to take the next step." Only the entreprenuer him/herself can answer that question to his/her own satisfaction.
This looks like a good plan to test the market. Is there also danger here that the product you're testing won't have enough viability? How do you know where the minimum amount to illicit change in consumers is?
DBK: Great questions. The MVP concept has definitely found a home with digital products. I'm sure there are plenty of product managers of tangible products who take one look at the MVP concept as it's being expounded in technology (and startup) circles and say, "Of course you test first before building the larger vision. You'd be crazy not to." For whatever reason, it resonates in the technology startup community. That said, here's an interesting article on a few tangible products (the original Nike running shoes, Powerbar) that started as MVPs.
RE: Minimum Viable Products Are Not Just for Startups
@Dave: There is certainly a longer answer here (and maybe worth a follow-up post) but think of it like this: "Minimum Viable Product" is more a way of thinking than an actual thing, and a prototype is just one way to do an MVP. If I'm envisioning a product that has some risky assumptions that are fundamental to its viability, find a way to test the assumptions to your satisfaction for the least cost. Sometimes, you can use a prototype; sometimes you need to build an actual product and put it in the market. I'll use my experience with a startup in the online mental health space. There are many assumptions about the mental health market that are fundamental to the business plan, but the one that had to be right or little else would matter was this: individuals, clinicians, and mental health institutions are willing to address mental health using online tools. (This was 2 years ago.) We believed that we needed more than a prototype to test this. We believed an actual product was needed, but it didn't have to be everything we imagined right out of the gates. Besides, we assumed most of what we built would be wrong anyhow. The product had to be good enough to be a compelling product offering, but we decided to hold off on a number of features that weren't relevant to validating the fundamental business assumption. We also have worked closely with users (using prototypes in some cases) to validate additional features and modifications to existing ones.
Clickable proto types, is that like focus groups in the cloud?Makes sense for certain products and social media can certainly help to fuel and validate the hypothesis. I am curious about how this could apply to more tangible products; you know things that we can actually touch, not just virtual?More research on my part may be required.
RE: Minimum Viable Products Are Not Just for Startups
@singlemud: I hear you. It's actuallly hard to take that step back and ask what I need to learn to know if I have a long-term viable vision. It's easier for the entrepreneur to just start building toward the vision. (I did that in my first venture.) Thinking about hypotheses and step-by-step experimentation and learning doesn't come naturally to some. Those entrepreneurs end up spending too much to launch something much larger than it needs to be to test the market. Steve Blank has a good discussion here about how the initial stages of a company should be about spending only enough capital to prove out the "product/market fit" and "repeatable sales model" for your idea. Once that's done, then you spend to build the market. Here are the three mistakes he points out: "The key contributors to an out-of-control burn rate [are]1) hiring a sales force too early, 2) turning on the demand creation activities too early, 3) developing something other than the minimum feature set for first customer ship."
The blogs and comments posted on EnterpriseEfficiency.com do not reflect the views of TechWeb, EnterpriseEfficiency.com, or its sponsors. EnterpriseEfficiency.com, TechWeb, and its sponsors do not assume responsibility for any comments, claims, or opinions made by authors and bloggers. They are no substitute for your own research and should not be relied upon for trading or any other purpose.
Enterprise Efficiency is looking for engaged readers to moderate the message boards on this site. Engage in high-IQ conversations with IT industry leaders; earn kudos and perks. Interested? E-mail: firstname.lastname@example.org
Dell's Efficiency Modeling Tool The major problem facing the CIO is how to measure the effectiveness of the IT department. Learn how Dell’s Efficiency Modeling Tool gives the CIO two clear, powerful numbers: Efficiency Quotient and Impact Quotient. These numbers can be transforma¬tive not only to the department, but to the entire enterprise. Read the full report
Now that TGen has broken new ground in genomic research by using Dell's storage, cloud, and high-performance computing solutions, the company discusses what will come next for it and for personalized medicine.
The Translational Genomics Research Institute wanted to save lives, but its efforts were hobbled by immense computing challenges related to collecting, processing, sharing, and storing enormous amounts of data.
Office and personal productivity tools come in a first-class and coach flavor set, but what makes the difference is primarily little things that most users won't encounter. What's the big issue in using something other than Office, and can you get around it?
We really don't want an "Internet of Everything" but even building an Internet of Everythinguseful means setting some ground rules to insure there's value in the process and that costs and risks are minimized.
Google's Chrome OS has a lot of potential value and a lot of recent press, but it still needs something to make it more than a thin client. It needs cloud integration, it needs extended APIs via web services, and it needs to suck it up and support a hard drive.
On a recent African trip I saw examples of the value of the cloud in developing nations, for educational and community development programs. We could build on this, but not only in developing economies, because these same programs are often under-supported even in first-world countries.
VMware's debate with Cisco on SDN might finally create a fusion between an SDN view that's all about software and another that's all about network equipment. That would be good for every enterprise considering the cloud and SDN.
Wearing a bulky, oversized watch is good training for the next phase in wristwatches: the Internet-enabled, connected watch. Why the smartphone-tethered connected watch makes sense, plus Ivan demos an entirely new concept for the "smart watch."
Cloud storage costs are determined primarily by the rate at which files are changed and the possibility of concurrent access/update. If you can structure your storage use to optimize these factors you can cut costs, perhaps to zero.
The Internet has evolved into a machine for drumming up a chorus of "Happy Birthday" messages, from family, friends, friends of friends who you added on Facebook, random people that you circled on G+, and increasingly, automated bots. Enough already.