Why ‘Failing Faster’ is Often Folly
“I have not failed. I’ve just found 10,000 ways that didn’t work.” — Thomas Edison
This famous quote is often used to encourage rapid prototyping or launching minimum viable products (MVPs) as they are called in lean startup parlance.
But to hold up Edison as an exemplar of this practice does not square with the facts. Edison only ran his experiments after he understood his target customers’ unmet needs.
The lean startup process: Build – measure – learn
The lean startup process is comprised of the “build-measure-learn” loop which entails building your minimally viable product (MVP), measuring customers’ response, and validating your assumptions (learning) so you can either pivot (change course) or persevere on your current path.
An MVP is that version of the product that enables a full turn of the build-measure-learn to deliver the maximum amount of learning with the least amount of effort and development time.
In lean startup and design thinking, the objective of entrepreneurs and innovators is to launch an MVP quickly to validate assumptions about the customers’ need for an offering. The problem with this approach, however, is that it conflates two experiments: one experiment about the perceived customer needs and the other about the efficacy of the solution.
Consequently, instead of accelerating learning, this confounds learning because we cannot determine if the results are due to a misunderstanding about the customers’ needs or the failure of the solution to adequately address known customer needs.
What Edison learned early in his career
Sarah Miller Caldicott, the great-grandniece of Edison and author of Innovate Like Edison, tells an interesting story about how he learned early in his career the folly of building things before validating customer needs.
Edison thought he had identified a significant problem when he observed that Congress, whenever it voted on an issue, required each senator to stand to call out his vote, one at a time. Edison saw that this process was wasting a lot of time and envisioned a vote-tallying system that could count the votes instantaneously.
He designed the new system, got a patent, built a prototype, and took his new automatic vote-tallying system to Congress for validation. Much to his surprise, however, the senators quickly rejected it. It turned out they didn’t want it because the “problem” Edison was addressing was actually an opportunity for them to persuade their peers to vote with them.
After Edison’s experience with the vote-tallying system, he was quoted as saying, “I never want to build something that nobody wants to buy,” and made a point of validating customer needs separately before developing and testing solutions. Edison did eventually invalidate his assumption about the customer need with his vote-tallying machine, but he realized the entire effort of designing, patenting, and developing it was unnecessary and could have been avoided.
We don’t need MVPs to uncover customer needs
Had Edison simply asked a few senators if they wanted to minimize the time it takes to tally the vote, they could have told him “no” and why not without an MVP.
We need to remember that customer needs are separate and distinct from solutions. The drill is not the hole.
Hence, we do not need MVPs to validate customer needs. All we need is clarity about what type of information to obtain from customers (and how to obtain it), namely the functional, emotional, and social tasks they are trying to accomplish and where they struggle with the current solution(s).
When failing faster works
Forget about prototyping and MVPs until after you have nailed the customers’ unmet need. Then you can design and develop your MVP to address that unmet need and validate its efficacy. If you have validated the customers’ unmet need, then failing faster is an excellent objective, because the “experiment” is on the solution only and the results are much more informative.
It’s learning we want to celebrate, not failure, and the best way to accelerate learning is by asking customers upfront want they want to accomplish, how they measure success, and where they struggle. Customers can tell us what they want if we focus on what they want to accomplish rather than product specifications. Then, and only then, are entrepreneurs and innovators ready to build, measure, learn, and fail faster.
(This article first appeared in The Business Journals, July 19, 2016.)
