“That’s not what I asked for!”

As a product manager, have words ever gotten you down? Or, more
precisely, has the lack of shared meaning of words used by the team -
even ostensibly shared words – appeared unexpectedly and disastrously
like an iceberg in the mist?

At the most recent Product
Management Educational Conference (PMEC),
Paula and I facilitated a session on the importance of a common team
vocabulary, and the dire consequences of not establishing one upfront
for every project.

Why is it so common for projects to
proceed without establishing shared meaning first? The answer is
two-fold: The upstream effort is not insignificant, and comprehending
the consequences isn’t straightforward. At the start, downstream
consequences are difficult to forecast and are easy to put out of mind.
At the end, it is difficult to evaluate impacts of unshared meaning in
retrospect.

Why is it worth it to confront unshared
meaning within a project even if the challenge is easy to deflect and
the risks are not easily quantifiable? We should deal with this because
the dangers are real and we know it. Even without quantitative tools,
anyone who has spent any time working on challenging projects with
multidisciplinary teams has direct experience of unshared meaning. In
your past projects, think of the cumulative effect of every avoidable
misunderstanding, of every requirement missed, of every heated debate
that burned up hours when in fact agreement had already been achieved,
and ask yourself how much of this unconstructive controversy boiled down
to a simple difference of definition?

Better
statisticians than me may have developed ways to measure
the quantitative cost of misunderstandings in the workplace, but my direct experiences offer up more than enough  compelling examples to convince me. I imagine yours do as well. What would you
imagine the cumulative dollar cost might be, even if not all projects fail completely?

Certainly the exercises we asked our session
participants to undertake were object lessons in just how elusive shared
meaning is when specialists attempt to work together. I found it
fascinating to overhear the teams struggle, albeit with some success, at
quickly generating shared definitions for a series of innocent looking
terms: “Product Management”, “Customer”, “Successful Product”, “Timely”,
and “Freedom”. (Admittedly, that last one was a wildcard!).

Along
with anecdotes from our work histories, the exercise highlighted
why a systematic approach to achieving shared meaning at the beginning
of projects is not easy but is so valuable.

Am I simply talking about
putting together a glossary for the project? That’s part of it, but
there’s more. What I am suggesting is that once the team is defined, we
very deliberately and explicitly recognize the root causes of unshared
meaning as a team, admit where our team is vulnerable, and share in the
solution.

At the end of the session exercises, Paula
and I shared a brief, but rich, guide to establishing a Team Rosetta
Stone. The overall process includes:

  • Identify
    Need
  • Build Draft
  • Provide Access
  • Utilize
    Consistently
  • Review and Revise

For much more
detail, help yourself to a copy of the handout.

Of course, this process can’t stand alone; it needs to be
integrated with your project’s life-cycle.

Does this
challenge ring true for you? Do you have any horror stories to share?
What solutions have you employed to achieve and maintain shared meaning
and avoid unconstructive controversy to the benefit of your products?

Trevor
Rotzien

the product manager

Categories: Anthropology, Product Management

Comments are closed.