Stripping the least useful third of the features requested allows you to deliver a 70 percent solution much more rapidly that’s often good enough.
Even For Demanding Markets, An MVP That’s a 70 Percent Solution is Often Good Enough
Today’s “Murphy’s Law” column (no relation) “Save The 70 Percent Solution” offers some lessons learned from combat for startups in considering how to craft and introduce and MVP into demanding markets.
July 23, 2013: When wars end there is a search for lessons. One of the most important lessons from Iraq and Afghanistan is that the same lessons tend to be relearned in war after war. Perhaps the most important lesson learned this time around was that a lot (usually most) wisdom and innovations begins at the bottom, not at the top. In Iraq and Afghanistan the military, especially the army, was quick to take advice from the troops actually doing the fighting. That was recognized even before Iraq and led to the RFI (Rapid Fielding Initiative). Established in 2002, RFI recognized that the American army did not always have the best weapons and equipment available and that the troops and low-level commanders had a better idea of what was needed than the senior generals and politicians. RFI was intended to do something about that and do it quickly.
Instead of always trying to “go to the top” it’s often better to look for an individual knowledge worker or first level manager who has a problem you can address.
During the next nine years the army approved the purchase of 409 items immediately, which is what RFI was all about. Last year the army began deciding which of these RFI items to make standard equipment (about a quarter of them) and which to discard (the rest, although many were obsolete and improved replacements were being sought). The marines went through this process and found that 63 percent of their RFI items were worth keeping, and only 17 percent were to be discarded. The rest are still being watched or being further developed.
These rates of failure are probably much better than the regular procurement process, especially when you factor in that the long acquisition times of ten to fifteen years leave older technology in the field longer.
70% Solution Rule: “Good Enough” can be produced quickly
Engineers often point out that they can deliver much more quickly if they are allowed to use the old “70 percent solution” rule. This bit of engineering wisdom is based on the fact that some capabilities of a weapon or other item are not essential but take an inordinate amount of effort to create. Thus a “good enough” item can be produced very quickly, if you are willing to sacrifice 30 percent of the capabilities you thought you needed (but probably don’t). Despite official opposition, the 70 percent solution has become all the rage over the last decade because the troops have found that this is frequently good enough and a real lifesaver in combat.
Even a 20% solution can address the core problem(s) that cause 80% of the pain.
You could see RFI coming. There were three existing trends pushing it. First, there was a lot more new technology coming on the market that troops could use. Some of it came from the companies that created equipment for the hiking and camping market (boots, rucksacks, all manner of outdoor clothing). Other stuff came from hunting and police suppliers (new gun sights and other accessories). There was a flood of new electronic gear, like lighter and more reliable GPS receivers and computer gear, plus new kinds of flashlights and, eventually, smart phones.
I think what’s called the “Consumerization of IT” is driven by the civilian version of these three trends. Consumer applications were easier to adopt and use than traditional IT solutions, especially for personal and small group productivity, and evolved more rapidly.
The second trend was that the troops were all on the Internet and, like never before, were in touch with each other via military related message boards, listservs, Facebook pages, and chat rooms. Troops have always been coming up with new ideas about how to use civilian gear for military purposes. But before the Internet each soldier’s discovery spread slowly. Now, information about new discoveries gets spread army-wide, and world-wide, within hours.
I think there is where the commercial sector has been less well served by trade press and startup blogs that tend to recycle funding and product announcements and do less to report real user experiences.
Finally, there was SOCOM (Special Operations Command), which had long possessed its own RFI-like powers and budget to go with it. SOCOM could buy neat new weapons, as well as equipment. SOCOM could also afford to buy expensive stuff (the first night vision gear and satellite phones). SOCOM personnel were on the Internet as well. By 2001, thousands of soldiers were speculating, via the Internet, how much more effective they could be if they had SOCOM’s freedom to quickly get new stuff that allowed them to do their job better.
I remember attending a talk on this at a Churchill Club event in the early 2000’s and someone at our table mentioned that you had to be very careful making promises to SOCOM because they would field immediately and ask you to support your claims. I think this is something that startups can lose sight off: early adopters are willing to invest time in a new technology because they can see long term but are normally looking for immediately application and a small payback. Y0ur offering has to provide a small amount of value quickly so that it can spread internally to provide more value.
Key take-aways for your first viable product:
- Sell low not high.
- Focus on the 20% of the problem that’s causing 80% of the pain.
- Be wary of long feature requirement lists unless most of these are available in the status quo: an MVP normally needs one or two differentiating features but may need other features (“the ante”) just to be viewed as a viable product compared to alternatives.
- Be candid about shortcomings and problems – let early adopters self-qualify.
- Provide immediate value or some value as quickly as possible.
Related Blog Posts
- MVP: Are You Building a Death Star?
- MVP: What’s Really Under Your Control
- An MVP is Finished Only After You Have Early Adopters
- A Common MVP Evolution: Service to System Integration to Product
- Q: How to Explore an MVP For Knowledge Worker Productivity
- Q: How Do You Iterate An MVP So That It’s “Good Enough For Government Work”
- Office Hours: Schedule Time To Walk Around Your MVP
Image Credit: Online Webfonts Seventy Percent