PD SPOTLIGHT                                    Product Development’s                                    Seven ‘Dirty’ Wor...
themselves as experts rather than knowledge      solutions. And somewhere in the middle, they       product never stops ev...
Upcoming SlideShare
Loading in …5

Product Development's Seven Dirty Words


Published on

Francis Gouillart provides his thoughts on the seven "dirty" words that he would like to ban from the language of product development

Published in: Business, Design
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Product Development's Seven Dirty Words

  1. 1. PD SPOTLIGHT Product Development’s Seven ‘Dirty’ Words Francis Gouillart, President, Experience Co-Creation (EEC) Partnership fgouillart@eccpartnership.com‘‘ With a few exceptions, engineers should not be functional experts. They should be solution brokers. By interacting with users of their products – possibly with S tand-up comedian George Carlin once had a famous 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 regulators, the firm’s manufacturing profes- sionals, the salespeople, or the citizens with a stake in what the company does. All of these people have experiences of the design, and all are protagonists in your product develop- ment 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, the intermediation of conveyed by a flow chart representing food, and sex lies the need for your new product development on a wall, disguising product in people’s Maslow’s hierarchy. So ’’ marketing – they should a cesspool of messy interactions as a neatly let’s just ask them and pretend their blank facilitate the creative flowing river. stares have deep interpretive meaning. In the classic company-centric view of Customers and other protagonists cannot formulation of problems. business, product development professionals express needs beyond what they have already follow a process. In reality, however, there experienced, and those are by definition is no such thing as a product development trivial. They cannot know what they have process. Product development is a series not been exposed to, so all they can tell you of interactions. To state the obvious, the is what they do and the experiences they difference between a process and an inter- receive – that is, do they like doing those action is that the latter flows in (at least) things or not? Fortunately, most of what your two directions. Therefore, one should not stakeholders do today does not involve your design product development processes, but company, so there is a lot of room to grow instead product development engagement new experiences by developing a company platforms inviting multiple constituencies to interaction. Your stakeholders spend a lot of participate in the design, with the product time trying to get noise out of one hand clap- development professionals acting as facilita- ping, so your company might as well provide tors of those interactions. the second hand. 2. CUSTOMER: some arbitrary 4. MARKET RESEARCH: an expert definition of the target population for a function designed to impede the free flow particular design, ignoring all the others of knowledge between protagonists and most likely to kill it long before it gets to product developers. that “customer.” The problem with market research data A favorite question of product develop- is that the cost of gathering data granular ment professionals is, “Who is the customer?” enough to be helpful to product developers is This is an unanswerable question. If prod- prohibitive, leading the approach to collapse uct development is a series of interactions, under its own weight. Also, whatever research the next question is “interactions between data exist are usually confined to thick reports whom?” At the minimum, these interactions or trapped in the minds of third-party “ex- involve suppliers of technologies, the product perts,” preventing the information from being development engineers, the firm’s marketing delivered efficiently to the point of design. professionals, and the company’s various Meanwhile, the problem with market re- customers. And that’s not even counting the search professionals is that they often view4 JUNE 2011 • VISIONS
  2. 2. themselves as experts rather than knowledge solutions. And somewhere in the middle, they product never stops evolving and is “alive.”brokers between the customer system and should intermediate, broker, cajole, and coax We just prefer to think of products as com-the product development community. Engi- all sides until a solution emerges. A solution plete because it’s easier that way. “Freezingneers should not delegate the formulation of occurs when some emerging formulation specs” is an apt representation of the fact thatproblems to market researchers, but instead of a problem meets an emerging technol- the concept goes back to the ice age.should challenge them to set up the knowl- ogy. The problem formulation requires anedge platforms that enable a direct dialogue in-depth understanding of protagonists 7. IDEA MANAGEMENT: a processfor them. Most market research experts will and their interactions for sure, but problem or software program that assumes there isresist and explain that people in the target formulation does not come solely from the such a thing as a self-contained idea thataudience don’t have PhDs in conjoint analysis protagonists. In fact, it nearly always involves can be formulated, packaged, and voted offlike they do. a creative reformulation of the problem by the island. a product development professional to meet The problem with the concept of “idea”5. ENGINEERING: an invocation of a solution he/she knows is available or can is that it constantly mutates. Ideas cannotexpertise used as a shield by product be developed. be “managed.” They can only be co-created.developers to resist opening up internal Voting an idea up or down is not as helpfulprocesses to others who know more than 6. PRODUCT SPECIFICATIONS: the as developing the idea, transforming it, givingthey do. art of converting fluffy qualitative data into it new meaning, or adding new players to the With a few exceptions, engineers should hard product data, all the while pretending group that shapes it. This is the challenge ofnot be functional experts. They should be that one rigorously follows the other when idea management software. Most use a staticsolution brokers. By interacting with users of the engineer is, in fact, quickly updating definition of an idea, which limits their useful-their products – possibly with the intermedia- last year’s design to meet the product ness to marginal cost reduction or operationaltion of marketing – they should facilitate the development deadline. improvement ideas, rather than encouragingcreative formulation of problems. By talking Nowadays, products are platforms. They the development of new insights. When ideawith suppliers and other technical experts, have multiple releases. And users design management becomes idea co-creation, wethey should enable the identification of them as much as engineers. In practice, the will finally start getting somewhere. V VISIONS • JUNE 2011 5