According to one of the most highly regarded innovation experts, Clayton Christensen, about 60% of corporate innovations never see the light of day and another 40% of those that are launched into a market never see a positive return on investment (The Innovator’s Solution, page 73). That means that only one in four innovations released by established companies are successful. After having worked on over fifty innovation projects for various companies and organizations, I started to see a pattern of constraints impeding successful innovation no matter the size of the company, the industry, corporate organization, or talent pool. Time and time again projects lagged, products got diluted, and useless solutions were built despite the best efforts of team members. A combination of outdated methodology, risk-averse culture, and office politics create a hostile environment for good solutions to take root in a market. This article lays out the ten most common and deleterious factors that I’ve seen suffocate successful innovation in established companies and organizations.
1. More than one person creating the vision and making decisions
When most people think about the most innovative companies in recent history, they tend to equate those firms with their leaders. Apple had Steve Jobs, Microsoft had Bill Gates, Tesla has Elon Musk, and Facebook has Mark Zuckerberg. We do not often think of groups of people when we talk about esteemed businesses or breakthrough products. Instead, we equate those companies and products with visionaries. Apple had Steve Jobs that brought to the world the iPhone among other disruptive innovations. Even though there were clearly huge teams behind the most famous innovations and many people contributed to their design and implementation, they were often driven by one visionary leader rather than a committee of corporate elites.
At the same time, many of the most challenging innovation projects that I’ve seen involve multiple product owners. This results in a disastrous dynamic for a number of reasons. The first common issue is that multiple product owners often do not agree on a single vision or on product decisions, and the more product owners there are, the less likely they are to see eye-to-eye. Every disagreement leads to substantial amounts of wasted time and halts the entire implementation team, which is hugely disruptive to productivity and moral.
Even worse than the wasted time is the outcome, which is the second impediment. Imagine if rather than Steve Jobs leading the vision for the iPhone, Apple had a committee of product managers and executives that set the product strategy and design. We’d probably end up with some kind of clunky mashup of a BlackBerry, a Motorola Razor, and the Apple Newton. (How many readers actually remember those products?) That is exactly what often happens in many corporate settings. Rather than empowering one product owner to lead the vision for an innovation, there are other executives or stakeholders that waltz in and impose their own ill-conceived changes and requirements without having immersed themselves in the need and solution design. The result is either a Frankennovation or a watered down, forgettable product that has no chance in the market.
Many of the innovation leaders that we admire founded their companies on disruptive innovations for which they provided the vision and around which they rallied their team. Indeed, it’s no coincidence that most startup businesses have three or less co-founders. Some investors and accelerators won’t even invest in startups with more than three co-founders. Moreover, even those startups that have more than one founder, one is usually entrusted with the product strategy and implementation, while the other founders focus on running the business and marketing the innovation.
Of course, having one product owner that is responsible for the product vision and decisions does not mean that nobody else has a voice. One of the central roles of the product owner is to listen to his or her stakeholders, process their feedback, and decide what to act on and what to disregard. There are exceptions to this rule such as Larry Page and Sergey Brin leading Google, but there are almost never more than two leaders, and even two rarely produce successful innovations. Any organization that does not empower its product owners to own the innovation vision and make product decisions is setting its efforts up for failure.
2. Product owner working on other projects concurrently
How many founders do you know that are working on multiple startups at the same time? Did Bill Gates create the Microsoft operating system while working part-time on another innovation? You would be hard pressed to find examples of innovation leaders successfully creating multiple breakthroughs at once. There is a simple reason for that. It’s hard enough to create one successful innovation that trying to lead two such successful efforts at once is basically impossible. Innovation just takes too much time, energy, and mental engagement to leave any extra capacity for a second or third innovation.
Now ask me how many times I’ve seen innovation leads and product managers working on two, three, even four innovations projects at once in a corporate setting. It happens all the time! If your company truly wants to create meaningful and viable innovations, you absolutely cannot allow your innovation leaders to work on multiple projects at once. If you do, you might as well write them all off. Instead, ensure that your product managers and intrapreneurs (internal entrepreneurs) only need to focus on one breakthrough at one time to allow them to truly live and breathe the problem, solution, implementation, and go-to-market efforts.
3. Product strategy and design are created by committee
Early on in my career, I was leading the strategy and design for an innovation project for a large government organization. Our team kicked off the first day of the project by gathering all the official project stakeholders in an auditorium; there were well over thirty people in the audience. Unfortunately, the expectation had been set that all the stakeholders would have input on each deliverable as the project went on.
This turned out to be a Titanic disaster as each review cycle took weeks and the design process seemed to never end. Our team would finish a round of product design, and then we’d spend the next week or two just getting stakeholders in the room for a design review. We would gather everyone’s feedback and incorporate it in the design. Then we’d have to spend another week or two getting everyone in the room again to review the revised design. In the process, those stakeholders that could not make the first review would send their feedback separately, so we’d have to reschedule the review meeting to incorporate the last-minute feedback. This pattern went on for months. Not only that, once we started building the solution, some stakeholders insisted that we stop because they felt that their feedback was not fully addressed.
It’s simply a matter of probability that the more stakeholders you have, the smaller the chance that you will be able to get everyone in a room or get everyone’s feedback in a timely manner. At the same time, it becomes more likely that stakeholders will disagree or will try to torpedo your efforts if they are not happy. Yet are internal stakeholders the true customers of the innovation that you are creating? Unless you are making an internal tool, the answer is probably ‘no.’
The primary stakeholders to whom you should be listening are customers. It is critical to set the expectation internally that unless internal stakeholders are the beneficiaries of the innovation, they are not guaranteed a say in the product strategy, design, or implementation. Once again, they should be welcomed to provide their feedback and insights, but the timing and direction of the project should not revolve around internal stakeholders if your organization does not wish to innovate at a glacial speed. The challenge is that this is often a cultural shift for established companies and this shift in thinking often needs to come from upper management.
It’s also important to note that although the above example was clearly from a waterfall based project management approach, the same inefficiencies and risks exist for agile product development efforts. In fact, they are often worse because instead of stopping just the business or design team in their tracks, stakeholders would be stopping the entire implementation team including project managers, business analysts, designers, engineers, marketers, etc.
4. Product owner never experiencing the problem firsthand
One of the key questions that venture capitalists and angel investors ask of entrepreneurs is what personal experience do the founders have with the problem that their solution is seeking to solve. This is because the founders bring a mission to the company and a vision for a solution, so they need to have completely internalized all the details of the problem. The best way to truly understand something is to experience it yourself, if possible. Although observations and interviews are great, they cannot substitute the thoroughness of understanding that personal experience affords you. It’s no coincidence that some of the most innovative products that we know today such as AirBnb and Mint started with the founders intending to solve their own challenges.
Many innovation leaders at established organizations that never take the time to experience the problem themselves. Indeed, I was guilty of skipping this step many times early in my career until I saw that lacking the insight and intuition from first-hand experience really stymied my own problem solving capabilities and intuition. I often found myself architecting solutions based on assumptions that eventually turned out to be wrong, and those product designs tumbled like a house of cards. When product owners have personal knowledge of the problem and solution space, they can build their innovation on facts rather than assumptions leading to a much higher likelihood of success.
Of course, it’s very rare that the market opportunity that the company wants to pursue exactly matched the innovation leader’s personal challenges. Instead, it’s much more likely that the product owner has to simulate what it’s like to experience and solve a certain problem. For example, long before I bought my first home, I was working on an innovation project for a large financial institution and was responsible for leading an innovation project to help bank customers find out about and apply for a mortgage. Even though I didn’t actually need a mortgage, I went through the application experience starting from square one: needing to learn about different kinds of mortgages. As MIT innovation expert and author Luis Perez-Breva states that sometimes innovation leaders need to prototype the problem, so they can experience it firsthand.
5. Product owner not leaving the building to talk to and observe people
Clayton Christensen recounts the story of Sony in The Innovator’s Solution. Christensen asks why Sony was so incredibly innovative in its early years, spawning a number of market-defining breakthroughs such as the Walkman, while it struggled to create disruptive innovations later in the company’s history. He explains that the main difference seems to have been a change in culture and approach to innovation. In the early days of Sony, the founder, Akio Morita, focused on observing and questioning people to understand what they were really trying to get done in their everyday lives. Steve Blank, another top innovation expert, coined this approach as “getting out of the building.” This approach helped Morita and his team find day-to-day challenges that people faced that could be solved for them with innovative engineering.
As Christensen points out, this period of innovation ended around 1981 after which point Sony did not create another disruptive innovation for another eighteen years. The main change during this period was a shift to hiring product leaders with MBA training to lead innovation efforts. Christensen writes:
In the early 1980s Morita began to withdraw from active management of the company…. To take his place, Sony began to employ marketers with MBA’s to help identify new-growth opportunities. The MBA’s brought with them sophisticated, quantitative, attribute-based techniques for segmenting markets and assessing market potential. Although these methods uncovered some underserved opportunities on trajectories of sustaining improvement in established markets, they were weak at synthesizing insights from intuitive observations. (80)
Indeed, in my own experiences I have witnessed a great number of product owners conceive solutions without ever personally observing or talking with customers. Quite to the contrary, those innovation leaders build complete product strategies based on spreadsheets, PowerPoint presentations, and summarized second-hand research. Once again, the typical way that leaders in corporations formulate their mission and product vision is based on generalities and assumptions rather than on detailed first-hand knowledge. It’s perhaps no wonder that a great majority of innovation efforts fail given this kind of a genesis.
Imagine if great innovators such as Mark Zuckerberg, Steve Jobs, and Akio Morita conceived their breakthrough products completely from within a boardroom. How likely do you think it would have been that a Facebook, iPhone, or Walkman would have ever been implemented as we know them? Certainly Facebook is not the only social network of the era, nor was the iPhone the only mobile phone that customers could buy. It was the details of their implementation that made Facebook and the iPhone stand out from competition and eventually dominate their respective product spaces. Can you imagine any survey or market segmentation providing the insights necessary to conceive of an iPhone or Facebook? Innovation leaders that do not get out of the building and speak to the people they are trying to serve are only setting themselves up for failure.
6. Never validating that the need actually exists and is big enough
According to one CB Insights study, about 42% of startups attributed lack of market need as a key reason the venture failed. Although I haven’t seen a similar study for corporate innovation efforts, I’m willing to bet that even fewer solutions conceived and implemented by established companies find a market need. It is exceedingly rare that product owners in established companies validate the market need in the field by speaking to and observing people, and projects often get green-lighted without convincing indications that a particular problem actually exists and that it is acute enough to address with a new product or service.
Moreover, those same innovation leaders often do not spend enough time with potential customers to understand the underlying details of the problem or why other existing solutions fail to address those details. Instead, they often rely on general market research that asks sweeping questions such as “Are you currently satisfied with your current mobile phone?” but does not provide the detailed information needed to truly understand an opportunity space and how a new innovation can improve on existing solutions. Of course, it’s not possible to answer those questions with absolute certainty, but all innovation leaders should seek to validate the need through conversation and observations and not just high-level surveys or other generic marketing research tools before leaping into a multi-million dollar innovation project.
7. Starting to build before validating solution
Does your company need to spend millions of dollars and years to validate whether your solution might be viable? Certainly not. In fact, it is often possible to get insights about a proposed solution from real people without building anything. Often times, showing people a product design or simulating a service is enough to get meaningful, actionable feedback. There is certainly a time and a place for building prototypes and minimum viable products to test solutions in truer contexts, but it’s often worth it to consider ways of testing a solution in ways that would require little or no engineering. In many cases, it’s enough to show people product designs or to manually simulate automated tasks.
For example, let’s say that your company is a financial institution that identified a need to help customers choose financial products, and the solution your team came up with was to create a chatbot with artificial intelligence (AI). Rather than actually building an AI-powered chatbot, you might simulate it by allowing customers to type in questions and return answers manually rather than using AI. There is no need to build an expensive AI engine to validate whether or not an AI-powered chatbot would be a good solution to this problem. Perhaps you’d find that a chatbot is just not an appealing way for customers to make such important financial decisions. It’d be good to know that before embarking on a costly engineering effort.
Often times, innovation teams will launch right into building under the guise of calling their work an “minimum viable product” or MVP. However, even though this term is in vogue, just calling something an MVP does not mean it’s actually minimal, and a multi-year, multi-million dollar project is almost certainly not a “minimum viable product” unless your business is a pharmaceutical company. A minimum viable product is meant to be a market-ready implementation that captures just those essential features to satisfy early adopter customers. An MVP is not meant to test the viability of a solution; prototypes are meant to do that. Creating an MVP should follow validation of the solution rather than being an instrument for the validation itself.
An even greater misstep than building solutions before they are validated is building solutions without really defining the problem or understanding the details of the problem. It is very common for companies to approve projects based on ideas rather than real market opportunities. They almost always start out with “our customers will love this product” or “our customers need this product.” Once again, successful solutions are built on the details of real-life challenges and not on assumptions.
8. Focusing on details that don’t really matter to customers
During one innovation project where I was leading the design and engineering teams, the product owners debated what shade of blue to use for over two months wasting hours of meeting time and stalling implementation. On another project, a product owner went through at least a dozen designs of one tiny icon that was found on a page buried deeply on an online tool — an effort that lasted in excess of three months and required many days of revisions and review. In both cases, our innovation teams were working on “minimum viable products.” I wish that I could say that these kinds of practices are uncommon on innovation projects in established companies, but unfortunately I have seen this pattern repeated constantly.
Customers will not choose a product simply because it is turquoise blue or sky blue or because some icon that they will rarely see satisfies their sense of aesthetic. Instead, people have limited time, attention, and cognitive bandwidth in a world where they have to process 34GB of information, make 35,000 decisions, and evaluate probably dozens of product options every day.
Many prominent entrepreneurs focus on just two or three key features that will distinguish their product from the competition. For example, Paul Buchheit, who led the invention of GMail at Google, chronicled how his team focused on just three key features when creating the first version of the breakthrough web-based email client:
- Outstanding search for email (something Google was already great at)
- Threaded email conversations
- Practically unlimited storage (initially 1GB, which as more than nearly anyone needed in 2004)
Stewart Butterfield, the founder of Slack, followed a similar ethos in creating the wildly popular business messaging app. The Slack team likewise focused on three key features:
- Outstanding search for conversations
- Synchronization across devices
- Seamless file sharing
Buchheit and Butterfield didn’t build products with just three features, but they focused their team’s efforts to perfect those features that would make their solutions stand out from the competition and made everything else good enough. Later on, as GMail and Slack gained plenty of traction, their respective teams could focus on the other details and fine-tuning their products as they went on to dominate their markets.
Unfortunately, the opposite is often true with regard to innovation projects at established companies. Rather than focusing on two or three key features meant to squarely meet a customer need, corporate product teams tend to spend too much time on second-order details that don’t really matter to most people. Even worse than that, those teams spend time and resources on making everything perfect before validating the core problem is substantial and their solution is better than alternatives. This mentality is what gives rise to multiyear, multimillion dollar “minimum viable products” and leads to unimaginable inefficiency and loss.
9. Not continuing significant product improvements after launch
A common practice among startups is getting a minimum viable product to market quickly and then iteratively improving it once people use it in a real-life context and can provide feedback based on reality rather than conjecture. This approach let’s startups adapt quickly as they receive fresh input from customers. At the same time, they can build new features incrementally rather than spending tons of resource on creating feature sets that might turn out to be poorly implemented or just not useful to customers.
Unfortunately, corporations tend to launch innovation projects and directly go into maintenance mode rather than treat the launch as the beginning of empirical product development conducted in a real-life context rather than in a lab or conference room. This misstep is often driven by spending too many resources going to market with the initial implementation and running out of runway to iteratively perfect the product after launch. It is critical, therefore, to launch early and build into all innovation projects a period of iterative product development once the minimum viable product has been launched in the real world.
10. Never finding product-market-fit
No matter how great an innovation is, it is worthless if the business does not effectively find and reach a group of people that will use it or buy it. Any impactful innovation needs to provide a superior solution to an acute problem. Additionally, the company needs to find and effectively reach the corresponding market. Product-market-fit is when the right solution meets the right market. However, companies often just launch innovations and fail to find traction for them in the market. Worse, some companies never even try to validate whether or not the company has found the right market for the innovation and if it meets people’s needs well enough that a significant number of them will pay for it or will use it regularly.
Many established companies launch innovations but never ensure that they can effectively reach the right customers. Instead, those companies launch solutions without organic product-market-fit — traction with customers that is not bolstered primarily by the company’s brand or marketing spend. Why engage in costly efforts to create innovations if they are left to drift along and sap the company’s brand equity or marketing resources? Creating a solution is just one part of product-market-fit. Without spending resources to ensure that the solution reaches traction in the market by measuring adoption and iteratively improving the solution, companies miss the other half of what is needed to create a viable innovation that adds to — not detracts from — the company’s bottom.
Avoiding the 10 deadly sins of corporate innovation
There are a number of pitfalls along the long journey of innovation in established companies, but it’s possible to avoid them and increase the probability of creating successful solutions. To a large extent, the above challenges can be mitigated with good planning and setting the right expectations. For example, it’s important to plan for project phases aimed at understanding the problem and validating solutions early. At the same time, by setting expectations that the product owner will be solely responsible for the vision and major strategic decisions, leaders can ensure that their innovation efforts won’t be stymied by design-by-committee and endless review and feedback cycles. We will cover specific tactics to address the innovation challenges mentioned in this article next week, so be sure to check back then.