It’s cheaper and easier than ever before for ambitious organizations to explore new ideas at lightning speed. The costs of prototyping are so slight as to seem insignificant. The inevitable result of all this, as Michael Schrage predicted over 15 years ago, is a state of hyper-innovation.
Sounds great, doesn’t it? The excitement and promises of new and better products, taken to seemingly infinite levels of possibility thanks to the ease of rapid iteration.
But it’s not all rainbows and puppies. The intoxicating potential of hyper innovation is a double edged sword. Hyper innovators, after all, need hyper adopters, a fancy word for customers who will actually buy the product. And, Schrage cautions, “Speed for the sake of speed is as valueless as innovation for the sake of innovation. That's not business; that's self-indulgence. The challenge is to treat the economic virtues of speed, cycle-time compression, and their concomitant savings less as ultimate ends and more as creative means.”
What does this mean in practice? Well, it’s tempting to pounce on your Great Idea and get it out into the world as quickly as possible. But launching anything before doing your research, interrogating your assumptions, and asking the right questions will very likely result in a lot of wasted time and failed, dead-in-the-water products.
This doesn’t mean quashing innovation - quite the opposite! It means asking the right questions. It means being a good team, one that engages directly with end-users regularly to better understand the customer, one that gathers end user intel before building anything. And it means never, ever mistaking yourself for the customer.
It’s only by interrogating your own assumptions about feasibility, desirability, and viability -- and validating them with potential customers before you rush out a mediocre product -- that you can channel your ideas into awesome products, embody the true spirit of innovation, and avoid time-wasting and potentially costly bad iterations -- the kind that actually kill innovation.
The Flip Side of Innovation Drivers
You’re probably familiar with the three main innovation drivers: feasibility, desirability, and viability. It seems like a straightforward enough process to suss out whether an idea is feasible, desirable, or viable. But it’s not always so simple to see past our own biases when determining if our idea has the potential to fall in the sweet spot where the three drivers intersect. That’s why it’s so important to validate and interrogate ideas before iterating on them - to make sure we aren’t being seduced by the siren song of our own product wishes and fantasies.
Chances are, you’ve made one or more of the following three arguments in support of your idea:
“It’s futuristic!”
Who isn’t attracted to the idea of a futuristic product? “Futuristic” is synonymous with sexy, cutting-edge, and craveable. It seems to push the boundaries of what’s possible. The mania that surrounded the launch of the first iPhone demonstrates (to the extreme) the strong appeal and depths of devotion a well-timed futuristic product can inspire among consumers.
But there’s a difference between something seeming futuristic and something that’s so futuristic it isn’t even possible. Sure, compared to the phones on the market at the time, the first gen iPhone seemed like it was beamed to us straight from the future -- but clearly, this product was entirely feasible to make. How did Apple know this? Because they researched the technical requirements rather than rushing out a half baked product that would have failed when its limitations became apparent -- or couldn’t even be built at all.
Sometimes, “futuristic” is really just another way to say “I wish we could make this ... let’s pretend we can and move forward and worry about the rest of it later.” Unfortunately, wishing for a feasible product doesn’t make it real. If, for example, you have a great idea for an iPhone app that will revolutionize the way people watch media, by say, projecting lifelike holograms onto their coffee tables, but there is literally no way this can be accomplished from a technical standpoint, your actual product is either going to be a watered down, inferior version of your idea, or it’s going to be shelved until such tech becomes possible. Isn't it better to validate the feasibility before moving forward?
As Marty Cagan wrote in the introduction to the book User Story Mapping:
Good teams understand who each of their key stakeholders are, they understand the constraints that these stakeholders operate in, and they are committed to inventing solutions that work not just for users and customers, but also work within the constraints of the business. Bad teams gather requirements from stakeholders.
The takeaway? If you can’t launch it with the tech you have right now, then it’s not feasible, and you shouldn’t iterate. Go back to the drawing board and tweak your idea until it’s actually do-able.
“Sure, it’s a bit complex, but … .”
You know in your gut that your idea fills a need. No one else out there is doing what you propose - maybe you have figured out a way to automate payroll in a way that will save companies hundreds of hours; or perhaps you have figured out a way for social apps to instantly vet anyone who makes a friend request, so users don’t have to worry about imposters or catfishers.
Is this desirable? Will people want this? “Hell yes!” is your firm conviction.
There’s just one problem: It’s really hard to explain how it actually works, and users will face multiple pain points getting set up due to the complexity of your app. “So what?” You counter. “This is something no one else is doing -- of course they’ll want it. The trouble will be totally worth it!”
Only … it probably won’t be. At least not from a customer’s perspective.
The truth is, no matter how new and novel your singular solution is, if people cannot grasp the value of it immediately and unmistakably, then launching and then iterating on your product is a bad idea. Why? Well, essentially, it comes down to the change function, a term global strategist Pip Coburn discussed in Fast Company, “People change habits when the pain of their current situation exceeds their perceived pain of adopting a possible solution. I call that the ‘change function.’ It may seem simplistic. It's supposed to be.” In other words, people will only want your product if the existing problem is more painful than the perceived pain of adopting your solution.
So rather than forging ahead and launching and iterating on a confusing solution, first tweak your idea and find a way to create and convey clear, unmistakable value, and then validate that proposition before you iterate.
“It’s a bit of an improvement, and we can get it out quickly!”
You’ve come up with a way to improve on an existing solution. It’s not earth shattering or leagues better than the old way, but it definitely speeds up an old process, or makes it easier to perform certain tasks -- say, keep track of sales prospects.
Sure, you could make your solution more forward thinking, a bit more grand and innovative, but that would take longer. As it is, you can launch that MVP in no time. That’s great, right?
Actually, no. It’s not so great. The thing is, that word, “minimum,” in minimum viable product, isn’t supposed to be a synonym for “mediocre.” Your MVP shouldn’t be merely passable, or good enough, no matter how quickly you can get it out.
A better way to think of an MVP, as venture capitalist Sean Ammirati points out, is a Minimally Awesome Product. What you should be doing, he says, is “Building the least amount of product possible, in an awesome way, that delivers the maximum amount of validated learning.”
Longtime design and tech writer Andy Budd asserts that “In the rush to deliver a minimum viable set of features … we often ignore the elements that make the product really great (the exciters and delighters in the Kano model). As quality gets stripped back in preference for functionality, we slowly see our products become ever more minimal and ever less viable. It’s very rarely one thing that does it. Instead MVP often turns into death by a thousand paper cuts.”
So rather than prioritize marginally-better ideas for the sake of expediency, go for true innovation, ideas that take your product from just okay to great. Viable doesn’t mean it can be done quickly -- viable means people will *love* it. And there’s simply no good reason to launch and iterate on a marginally better product, no matter how quickly you can do it.
Bottom line? No one is suggesting that you sacrifice an attitude of innovation or forward thinking. In fact, researching, interrogating your assumptions, and doing the right prep before you launch anything only serves to improve and enhance the innovative process.
But at the same time, it’s important to be ruthless when examining bias, and not allow a weakness to masquerade as a virtue. As consultant Roman Pichler reminds us, “The three innovation drivers help you understand where innovation occurs and where uncertainty is present. This enables you to ask the right questions, formulate appropriate hypotheses, and carry out helpful, focused experiments.”