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

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 view
4 JUNE 2011 • VISIONS

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. “Freezing
neers should not delegate the formulation of occurs when some emerging formulation specs” is an apt representation of the fact that
problems 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 an
edge platforms that enable a direct dialogue in-depth understanding of protagonists 7. IDEA MANAGEMENT: a process
for them. Most market research experts will and their interactions for sure, but problem or software program that assumes there is
resist and explain that people in the target formulation does not come solely from the such a thing as a self-contained idea that
audience don’t have PhDs in conjoint analysis protagonists. In fact, it nearly always involves can be formulated, packaged, and voted off
like 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 cannot
expertise 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 helpful
processes to others who know more than 6. PRODUCT SPECIFICATIONS: the as developing the idea, transforming it, giving
they 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 of
not be functional experts. They should be that one rigorously follows the other when idea management software. Most use a static
solution 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 operational
tion of marketing – they should facilitate the development deadline. improvement ideas, rather than encouraging
creative formulation of problems. By talking Nowadays, products are platforms. They the development of new insights. When idea
with suppliers and other technical experts, have multiple releases. And users design management becomes idea co-creation, we
they should enable the identification of them as much as engineers. In practice, the will finally start getting somewhere. V
VISIONS • JUNE 2011 5