Breakthrough Products Breaking Your Back?
How many times do you have to experience something painful to learn a lesson from it? It generally depends on how painful it was. But what if it’s not as simple as leaving your wallet in a cab and never doing that again? What if the situation is so complex that you’re struggling again and again but not sure what to change?
This describes many of our clients developing innovative technology products. It’s a painful process, but the challenges involved conspire to induce the same pain over and over again.
At Mindtribe, we have opportunity see development of perhaps a dozen products every year. By integrating with our client teams, we not only see the world through their eyes, we feel their pain. Since the factors involved are seemingly complex, we too only recently gained some clarity with what’s going on.
Crystal balls do not exist. Magic Eight Balls aren’t really magic. And you do not know exactly what your customers want until you ask them.
So you already knew the first two. And you’ve asked your customers what they want?
Do Your Customers Really Know What They Want?
If your product is innovative in that it enables potential customers to have an experience they haven’t had before, they will have no clue if you simply ask them what they want. They don’t share your vision, at least not collectively. Here’s a sure-fire way to kill an innovative product concept: define it based on the the sum of feedback from users who tell you exactly what they want from experiences they’ve never had.
No problem, right? You put a prototype in their hands and gauge reactions to the actual embodiment of your vision. It’s a lot easier to say whether or not you like a specific painting on your wall than to tell the artist exactly what to paint. This is a step in the right direction, but here’s where I get to the point I want to make:
Since traditional product development processes do not validate a product concept until significant resources have been committed, they are intolerant of any changes of course resulting from useful feedback gained throughout the course of development.
Innovation’s Enemy: Traditional Product Development
Here’s why. Product development is expensive. You have a certain budget and are getting pressure from all sides to make the development effort cost less, the product to cost less, and most importantly, get the product to market as fast as possible. We see that squeeze with nearly every client engagement at Mindtribe.
With that many variables—everything that goes along with obtaining lowest development cost, fastest time to market, and lowest product cost—getting the most of what you want requires optimization. Until someone finds a closed-form solution for reality, optimization consists of iteration cycles.
You pick a set of values, see what the results are, and feed those results back into choosing new values. Since your optimized schedule and budget need approval before the product development team can get started, you’re actually doing an optimization with results you imagine you’ll get with a given set assumptions relating to product features, resolution of unknowns, associated schedule impacts, what users will say about the product in their hands, how they will react to the cost, and so on. You’re actually optimizing with assumptions, not real feedback. That’s a lot of assumptions to get right even before the product development team kicks off.
Even if you are convinced you can skip the validation steps—say you are your target market and know your inner customer well—we’ve learned the hard way that being able to overcome totally unforeseen obstacles generally goes hand-in-hand with doing things that are truly new and innovative (in many cases the very reasons others haven’t pulled it off yet).
Breaking the Cycle by Using a New One
We’re working on helping our clients avoid the cycle of pain in the pursuit of innovative products that customers want. The essence of the approach is frequent, efficient validation cycles throughout the course of development, wrapped in a process that embraces change, guiding the product development team to a product customers know they want when they see it.
The concept is a familiar one if you’re versed in agile software development techniques. In fact, we’re borrowing many of our techniques from experts in that domain. And the idea of early and frequent prototyping is not new. The real challenge is how to do this with hold-in-your-hand, breaks-when-you-drop-it technology products that make people want that experience they haven’t had before.
Stay tuned as we take our approach to the streets and report back with successes or more likely—frequent changes to our own process.