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?
the product manager