When creating new technology products and businesses, it was once standard practice to build first and ask questions of the marketplace later. It was a risky and expensive way to launch untested ideas, but it was how things were done.
This habit persists in many organizations today, and it’s increasingly problematic for two reasons:
- The cost of learning is too high. Today’s design and testing tools make it easier than ever to create realistic prototypes of ideas and validate them in the marketplace without building them first.
- The cost of failure is even higher. The accelerated pace of change today and the sheer number of bets required to discover winning ideas have made it too wasteful, slow and impractical for organizations to code software ideas before it’s absolutely necessary.
What’s the harm if we build it and they don’t come?
Consider the story of Trov, a startup provider of on-demand insurance for consumer items like bicycles, personal electronics and sporting goods. Industry website Coverager reported last June that Trov had just pivoted from its direct to consumer business model after seven years and $99 million in investment.
According to Coverager, even where Trov did find a fit, the market was too small and the product too complicated to scale.
In today’s world, it should never take years and $99 million to learn that we don’t have product-market fit.
While Trov might be an extreme example, there are dozens of mini-Trovs unfolding today in most large organizations.
Too much, too soon?
The movement away from building early took off in 2011 when Eric Ries published The Lean Startup and introduced the idea of the Minimum Viable Product, or MVP, which allowed teams to collect “the maximum amount of validated learning about customers with the least amount of effort and investment.”
Although a huge step forward, those MVPs still required teams of engineers and a few months or longer to get working software into the hands of customers.
In a blog post last Autumn (“Avoiding the Wrong MVP Approach”), software usability expert Jared Spool described a team that was exploring whether auto insurance customers could upload accident photos from their phones that were comparable in quality to the photos provided by expensive professional photographers (the answer was yes).
The team considered coding a streamlined version of the idea as an MVP. But as Spool put it, even a limited functionality software version for customer-supplied photos would still require a lot of work and disruption.
They’d need a way to upload the photos to the company mainframe system used for claims processing. They’d have to build something that attached the photos to customer claim records. They’d have to change the adjusters’ workflow. That’s a lot of difficult system-wide changes for one unproven idea.
#product-management #startup #ux #entrpreneurship #innovation
