By David DeWolf
There has been a lot of chatter in the tech community about the minimum viable product (MVP) and the importance of experimentation in innovation. Some have even have been so bold to call this an obsession. While I do believe that over-pursuing MVPs can be the fastest way for a company to “go broke saving money,” I also believe we are at a point in time where something more damaging than an obsession with MVPs is the case. There now seem to be dangerous and widespread misunderstandings of what an MVP really is. It’s essential that our industry come to a proper understanding of what MVP is and what it is not in order to put the MVP in its rightful place.
An MVP, by definition, is one that requires the absolute smallest amount of development work necessary to gain customer feedback. Sure, the MVP is no golden hammer and, as with all things, we can become overly reliant on it. What’s more dangerous, however, is dismissing the MVP without really understanding what it is. Let’s not throw the baby out with the bathwater.
The MVP was first brought to prominence in Eric Ries’ The Lean Startup. In the book, Ries is quite clear that the entire purpose of the MVP is to shorten the feedback cycle in order to obtain more customer feedback. He even argues that sketches and mockups are quite sufficient MVPs early on in the product development cycle. Building in a vacuum, which is commonly encouraged when working on MVPs, is the furthest thing from his mind.
It is important for the industry to understand what an MVP is not. It is not a beta or initial release of a product. The objective of an MVP is not to grow revenue or capture market share. Its entire purpose is to solicit valuable feedback in order to understand what could drive revenue, capture market share, and drive user adoption. It is simply a tool, not a result.
In other words, an MVP should never be positioned as the end goal. It is simply the first, second, and third step along the way to building a sustainable, market-ready product. The ultimate goal of the product development cycle is to build a sustainable product, not merely a viable idea. A successful MVP results in one of three outcomes—enough information to prove that the idea will not work, enough information to accelerate and build the full product, or enough information to show that there are valid concepts but the idea needs to “pivot.” A successful product, on the other hand, results in real business results—revenue, market share, and user adoption.
A frequent objection and barrier to successfully deploying an MVP is the argument that “no one would ever use it.” Product managers and engineers are not often challenged to envision what an incomplete, truly minimal product might look like, never mind understand why anyone would choose to use it. In his book, Crossing the Chasm, Geoffrey Moore outlines the technology adoption cycle and the psychological profiles of each adoption group, along with the continuum of adoption. In the incubation stages of a product, where the MVP is most relevant, it is the “innovator”—not even the early adopter—that needs to be attracted. These individuals are dominated by curiosity and intrigued by risk. They have a different psychological makeup than an early adopter, or even the early majority.
Two common techniques—the “Flintstone” and the “Steel Thread”—can be used to help pare down a product concept to the minimally viable feature set.
The Flintstone refers to a product that is essentially mocked up. It has the appearance of being complete, but relies on manual processes where automation would typically be assumed by the user. CardMunch, the app acquired by LinkedIn that processes pictures of business cards in order to convert them into digital contact cards, may be the most famous business to use this technique. In fact, it was so successful that Flintstoning remains a key differentiator for their business today. In order to test the market and adoption, CardMunch made the decision to build only the functionality necessary to upload a picture of the business card from your smartphone. Unlike competitors in the space, they manually transcribed the business cards before pushing the results back to the user.
What happened? Adoption exploded. Within five months they were acquired by LinkedIn, and in less than a year they had processed their millionth business card. There was obviously a market. What they learned, however, was even more compelling. Their core differentiation became accuracy. By manually transcribing the business cards, they were able to do something others were unable to match with technology. If they had automated the process in the first place, they may have never discovered their true differentiator and their technology development efforts may have been a total waste.
The Steel Thread refers to a singular, core feature that by itself would not make for a sustainable product. Gmail is likely the most famous product ever launched as a Steel Thread MVP. Paul Buchheit, the original creator of Gmail, wrote in a blog post about the genesis of Gmail,1 “The first version of Gmail was literally written in a day.” This original version was iterated upon and developed internally based on the feedback of innovators within Google before finally being rolled out to the public market as a beta release several years later. This feedback proved invaluable in helping to shape the product direction of Gmail to be focused on search rather than taxonomy.
The true problem with the MVP is that, as an industry, we have bastardized its meaning, not that we have become obsessed with it. Being fixated on MVPs and changing product direction whichever way the wind blows is not a viable long-term strategy. Successful startups and enterprises can embrace the original intent of the MVP, build incrementally, and create value for shareholders while leveraging customer feedback along the way. SW
David DeWolf is the founder/CEO of 3Pillar Global, a software product development firm that builds innovative, revenue-generating software products, enabling businesses to quickly turn ideas into value. 3Pillar balances business-minded thinking with engineering expertise in disruptive technologies, such as mobile, cloud, and big data, to develop products that meet real business needs. For more information, visit www.3pillarglobal.com
Source:
- Paul Buchheit, “Communicating with Code”
http://paulbuchheit.blogspot.com/2009/01/communicating-with-code.html
Apr2014, Software Magazine
