When executive management looks to improve a company’s innovation capability, their gaze typically settles on the group of technical folks; engineers, scientists and/or programmers collectively called something like R&D, Development or Engineering. I suppose this is a reasonable place to start, but true improvement needs to extend beyond the technical team as can be seen from the make-up of most product development teams actually deployed by companies. These teams typically include representation from marketing, sales, technical support, manufacturing, quality and perhaps finance in addition to technical representation. Why is this? Because it takes a village to produce a commercial success.
Note that when referencing the entire development team as outlined above the focus is more on execution than ideation. Despite this you could try to justify management’s focus on technical development by claiming that innovation comes from ideas and the technical team is where the ideas come from. I would argue against this narrow view of what innovation success depends on for two primary reasons:
- Companies have lots of ideas worth pursuing, many of which have no technical impediment but they still can’t make them work in the market; and
- Even the ideation phase is not solely the domain of the R&D team; in fact the technical team may not even be the leading contributor of ideas that get commercialized. Even for ideation – it takes a village but ideation is not all there is to innovation.
Learn Fast and Engage the Village in Thoughtful Planning
Let’s assume that we are past the initial ideation stage and have moved on to trying to make our product concept a reality in the market. Let’s also assume a typical development process in which, at this point, we should have eliminated the big technical risks (no requirement of a Nobel-prize-winning invention that has yet to be discovered). There are likely still some known technical problems to be solved and we are in the mode of learning fast to discover most of the additional impediments to success, technical and non-technical, that we have not yet uncovered prior to planning and committing significant resources to the project. This early phase may still be called “feasibility” or even “ideation” and most importantly, it is a precursor to developing an implementation plan that we will decide either to fund, incubate further or terminate.
These are perhaps the two most critical phases in the successful execution of an innovation effort: the rapid-learning feasibility and planning phases of a project.
Doing these well sets up the opportunity for successful innovation. It is often in these phases that we miss the opportunity to engage key players outside of the technical team in the success of the innovation. In most companies, by the end of feasibility or in planning, a broad set of representatives from the village are part of the team but they are often not yet engaged.
Quite often with the focus on the technical developments we short change the details of the implementation plan outside of the technical arena. This can happen in both large and small organizations but typically takes a different form in each. In large organizations an over-reliance on the fact that we have launched and supported products before makes us complacent in exploring the differences required of this particular product. Our commercialization plans often look very cookie cutter, when they need to be customized and when in fact the customization may be the key to success. In small companies it is simply a matter of not knowing what we don’t know and not knowing how to find out until we trip over it. The blissful ignorance that let us focus on the monumental technical achievement comes back to slap us in the face when we try to take it to market. In the case of the start-up, one may argue that this approach is justified and even necessary. Let’s not address that here but keep our focus on the large organization for now.
If You Neglect the Village You’ll Trip Over It
Why is it that we may not be able to just “turn the crank” within our large organization to deliver a new technical solution to the market? It may be that to satisfy customer needs the product needs to be customized at the factory, requiring the creation of a just-in-time manufacturing capability that didn’t previously exist. Rapid access to a new market for the product may require our commercial team to identify and partner with a third party to utilize existing distribution channels rather than taking the time to develop our own. The complexity of the product may require our service organization to adapt to supply significant customer hand-holding to ensure a proper installation and great out-of-the-box experience. The marketing team has to get especially creative because the product is so visionary that it is truly solving a significant problem which our customers have not yet recognized. Aggressive project timing may require many functions to change the way they interact on the team to be more engaged and responsive in identifying and resolving issues as they become relevant rather than addressing them through the timelines of the routine processes.
If it is new to the market or to the organization someone besides the design engineers, programmers or scientists is probably going to have to get creative to overcome issues unique to its successful commercialization. In many cases it will be some portion(s) of the delivery mechanism that makes it an innovation success. In a large company, ignoring the required contributions across the various functions early will make for a lot of bad feelings, delays and inefficiency later. Related to this, a dependence on the technical team for innovation leads to an unconscious expectation to avoid innovation getting outside of the technical team by constraining the technical solutions to only those that allow the rest of the organization to simply turn the crank. Although this is a clear inhibitor to innovation it can be a viable strategy for efficient and rapid new product launches, but only if explicitly addressed in the two early phases of the project. We can’t allow the technical team to design around one expectation while the organization is planning around another. This is a recipe for failure.
If you want to innovate efficiently, engage the full development team early and understand what is going to be required across all functions to succeed. Innovation is rarely the sole domain of the technical team. In fact, if you want all innovation to reside there you’ll almost have to force it by constraining technical development to design the “turn the crank” solution for the rest of the organization. Even with this low innovation bar you must engage the village early to achieve the benefits of the strategy. The best course of action for an innovative organization is to engage all of the functions early enough to get buy-in with the expectation that innovation can and should come from anywhere.
The photo was provided courtesy of the Old Stone House Museum and taken in Charleston, Vermont.
