Model 1: Invention
An old idiom states that “necessity is the mother of invention,” but if we look at the development efforts within many technology companies, we find that it’s just not so. Patent filings are replete with inventions that are seeking a need to fill, just as many unsuccessful solutions search for the problem they were meant to solve.
Invention—an old-school model that was predominant at 3M and a host of technology companies—is still at the forefront of what most people think of as innovation. Lots of smart folks—be they chemists, biologists, engineers, or physicists—are working hard to prove theories and successfully develop new technologies and combinations of technologies, often in collaborative environments. Killer stuff. The stuff that so much of our mechanization and technological advancement is based upon. But this isn’t necessarily innovation as much as it is invention. And this is not a particularly smart way to work.
Jared Spool recently tweeted, “Don’t confuse innovation w/invention. Invention is making a novelty. Innovation is making value.” While Jared may be taking liberties to enhance contrast, his point is quite valid. Jared further tweeted:
“This was the realization I had a little while back: Invention is important. It’s about creating something in the world that has never existed ever before.
“But that’s different from innovation. Innovation is about adding value to the world that didn’t exist before. Turns out, you can innovate without invention.
“In fact, some of the best innovations came by borrowing an old idea and applying it in a context that no-one had before. The value comes from the new application of the old thing, not from creating something new.”
When we talk about true innovation, it must have a purpose, and it must have an application. True innovation adds value as it enters and influences the marketplace. Inventing things because we can, then seeking a purpose or customer for our invention is a bit like fishing with a pistol. It’s a high-risk, low-probability proposition.
In one of my early business classes, a professor quoted a statistic along the lines of: “Only 10 percent of all new product introductions survive the first three years.” (His attempt at defining success.) The specifics of that statistic aren’t as important as the general notion of the failure that most new products face once they’re in the marketplace. Consider the resources expended on the development and launch of the other 90% of products that companies introduce.
Why did they fail? Many products fail because they don’t do what their makers promise, or they aren’t well marketed, but I posit that a huge percentage of the products that get introduced into the marketplace are complete misses. Customers flat out don’t want these products because their value propositions don’t meet their needs, so they aren’t profitable.
This is not to completely invalidate the invention model. I’ve worked on plenty of successful initiatives that began with this question: “We have this capability; what can we do with it?” If you have a product capability, you have a fiduciary responsibility to direct that capability toward a return on the cost of invention. But if you’re starting from scratch, this method does not present you or your organization with the highest probability of success.
Model 2: Blending Business and Customer Needs
It was just a few years ago that I rallied a team of managers, and we set out to do things differently. What we experimented with was looking at an area of interest and, we thought, opportunity, and putting together two separate strategies. One of the strategies specifically addressed a need the UX group was seeing in the marketplace. It was customer centric. We were asking broad questions of our customers and looking for specific opportunities, as well as problems to solve. Our user experience group was conducting its own form of competitive analysis, which was design- and use-centric. This varied from what the product and business group was doing because it focused upon users’ needs and how various competitors were addressing and satisfying those needs.
Meanwhile, the product managers (PMs) continued working as business owners to formulate a strategy that covered these fiduciary responsibilities. Their efforts included competitive analysis—though this focused more on core business concerns, including costs, returns, and feature-to-feature comparisons. The PMs also had access to and made great use of site metrics.
While both groups were analyzing quantitative data and trends, driving while looking at your rear-view mirror isn’t always optimal. The qualitative nature of our UX inquiries helped provide insights into the reasons why there were product gaps and made those gaps visible. But that’s not really enough. Both the UX group and the PMs were responsible for articulating a clearer and more far-reaching vision: what’s next; what could customers use that they can’t yet imagine?
As we formulated both our customer-focused and business-focused strategies, we stopped short of creating any final development documentation. At the draft stage, we pulled the Product Management and UX groups together, as well as Engineering. Working with a group of twenty plus in a room isn’t optimal for efficiency, but we were trying to accomplish a couple of things: First, we wanted to blend our separate knowledge pools and strategies into a single shared vision. Second, we wanted the Engineering group to have insight into where we were going with our designs and provide their insights to us. Often their first reaction was, “No, we can’t do that.” But in an age when there are fewer limitations in software, we were more interested in hearing the answer to the question, “When can we?”
As the team discussed various capabilities and debated our different perspectives on how to accomplish our goals, the conversation occasionally became passionate. But when we came to an impasse, we always seemed to have data to better inform our decisions—and if we didn’t, we reached out to get it. For the most part, while everyone in the room had an opinion, we tended toward relying on data, expertise, and skating within our lanes to resolve issues.
