The American stand-up comedian George Carlin had a routine entitled 'Seven Dirty Words You Can't Say on TV.'
Here are seven dirty words I'd like to ban from the product development language:
1. process,
2. customer,
3. needs,
4. market research,
5. engineering,
6. product specifications and
7. idea management.
1. Process: the appearance of rigor conveyed by a flow chart representing product development on a wall, disguising a cesspool of messy interactions as a neatly flowing river.
In the classic company-centric view of business, product development people follow a process. In reality, there is no such thing as a product development process. Product development is a series of interactions. To state the obvious, the difference between a process and an interaction is that the latter flows in (at least) two directions. One should therefore not design product development processes, but product development engagement platforms inviting multiple constituencies to participate in the design, with the product development people acting as facilitators of those interactions.
2. Customer: some arbitrary definition of the target population for a particular design, ignoring all the others most likely to kill it long before it gets to that 'customer.'
The favorite question of product development people is: 'who is the customer'? This is an unanswerable question. If product development is a series of interactions, the next question is 'interactions between whom'? At the minimum, these interactions involve suppliers of technologies, the product development engineers themselves, the firm's marketing people, and the various customers that the company has. And that's not even counting the regulators, the firm's manufacturing people, the salespeople, or the citizens with a stake in what the company does. All of these people have an experience of the design, and all are protagonists in your product development story. If any of them does not like your story, you die. Trying to prioritize between them is like asking you to define which of your children should be prioritized.
3. Needs: somewhere between shelter, food and sex lies the need for your new product in people's Maslow's hierarchy. So let's just ask them and pretend their blank stares have deep interpretive meaning.
Customers and other protagonists cannot express needs beyond what they have already experienced, and those are by definition trivial. They cannot know what they have not been exposed to, so all they can tell you is what they do and the experience they receive ' i.e., do they like doing those things or not? Fortunately, most of what your stakeholders do today does not involve your company, so there is a lot of room to grow new experiences by developing a company interaction. Your stakeholders spend a lot of time trying to get noise out of one hand clapping, so your company might as well provide the second hand.
4. Market research: an expert function designed to impede the free flow of knowledge between protagonists and product developers.
The problem with market research data is that the cost of gathering data granular enough to be helpful to product developers is prohibitive, leading the approach to fall of its own weight. Also whatever research data exists is usually confined to thick reports or trapped in the minds of third-party 'experts,' preventing the information from being delivered efficiently to the point of design.
The problem with market research people is that they often view themselves as experts rather than knowledge brokers between the customer system and the product development community. Engineers should not delegate the formulation of problems to market research people, but should instead challenge them to set up the knowledge platforms that enable a direct dialogue for them. Most market research experts will resist and explain that the target audience doesn't have a PhD in conjoint analysis like they do.
5. Engineering: an invocation of expertise used as a shield by product developers to resist opening up internal processes to others who know more than they do.
With a few exceptions, engineers should not be functional experts. They should be solution brokers. By interacting with users of their products (possibly with the intermediation of marketing), they should facilitate the creative formulation of problems. By talking with suppliers and other technical people, they should enable the identification of solutions. And somewhere in the middle, they should intermediate, broker, cajole, and coax all sides until a solution emerges. A solution occurs when some emerging formulation of a problem meets an emerging technology.
The problem formulation requires an in-depth understanding of protagonists and their interactions for sure, but problem formulation does not solely come from the protagonists. In fact, it nearly always involves a creative reformulation of the problem by a product development person to meet a solution he/she knows is available or can be developed.
6. Product specifications: the art of converting fluffy qualitative data into hard product data, all the while pretending that one rigorously follows the other when the engineer is in fact quickly updating last year's design to meet the product development deadline.
Nowadays, products are platforms. They have multiple releases. And users design them as much as engineers. In practice, the product never stops evolving and is alive. We just prefer to think of products as complete because it's easier that way. 'Freezing specs' is an apt representation of the fact that the concept goes back to the ice age.
7. Idea management: a process or software program that assumes there is such a thing as a self-contained idea that can be formulated, packaged and voted off the island.
The problem with the concept of 'idea' is that it constantly mutates. Ideas cannot be 'managed.' They can only be co-created. Voting an idea up or down is not as helpful as developing the idea, transforming it, giving it new meaning, or adding new players to the group that shapes it. This is the challenge of idea management software.
Most of them use a static definition of an idea, which limits their usefulness to marginal cost-reduction or operational improvement ideas, rather than encouraging the development of new insights. When idea management becomes idea co-creation, we will finally start getting somewhere.
Submitted by Francis Gouillart, President and one of the two founders of the Experience Co-Creation Partnership (ECC Partnership), a consulting firm built to implement co-creative management processes and organizational capabilities with corporate clients around the world.Francis is co-author, with Venkat Ramaswamy, of The Power of Co-Creation: Build It with Them to Boost Growth, Productivity, and Profits.
Francis Gouillart is one of the keynotes at The Front End of Innovation, and will be presenting "Unlocking New Sources of Value to Drive Differentiation and Growth" and in the "Think Differently" track.