Product Mangers Need A Dictionary In Order To Make Money

Product Managers Need A Dictionary To Improve Communications And Make More Money
Product Managers Need A Dictionary To Improve Communications And Make More Money

One of my favorite lines from Steve Martin’s stand-up act goes like this “What’s up with those French? It seems like they have a different word for everything…”

Perhaps many of us Product Managers have some French blood in us because it sure seems like we often get accused of willy-nilly making up new acronyms on the fly. In all honesty, yes we do do this sometimes. However, there is a more subtle word problem that has been creeping around the edges of the product management world for a long time that nobody’s been brave enough to bring up: we have no idea what we are saying.

Ranjay Gulati, James Oldroyd, and Phanish Puranam are three researchers who have been studying this problem and they’ve made some interesting discoveries. Specifically, they’ve discovered that we all seem to THINK that we are talking about the same thing when in many cases we really aren’t.

As product mangers we have to interact with many different departments. In order to meet the needs of all of these internal customers, product managers are always creating new and different ways to present the product information that we have . However, since nobody talks to anyone else in the company, we’ve been creating a million different ways to present (and talk about) the same product data.

What’s been missing from the product manger’s bag of communication tricks is some sort of dictionary. We need to standardize how we talk about our product’s data and how we describe the results of the processing that we do on that data.

Over at Best Buy, Robert Willett who is their CIO said that when he first showed up they 400 to 500 different ways to measure things. What this meant is that measurements done for one customer could not be interpreted by another customer so they had to do the processing all over again.

Robert spent over 10 months and drove to a point where they had single definitions for everything. It was only after this type of process dictionary had been created that Best Buy started to get some value for all of its efforts. Getting value is how product managers can make more money and that will benefit us all.

Do you have a single set of definitions for the product information that you collect and the results that you produce? Have you ever had a situation where two individuals or departments were trying to compare two things about products but couldn’t because they didn’t use the same words? How have you tried to solve this problem? Leave me a comment and let me know what you are thinking.

3 thoughts on “Product Mangers Need A Dictionary In Order To Make Money”

  1. Excellent topic.

    There are two ways (that I have encountered working as a project debugger, consultant and Product Manager) that false consensus can arise in groups:

    1. Passive aggressive agreement in which participants pretend to agree for various social and psychological reasons (See discussion of the The Abilene Paradox here:

    2. What I call “Gratuitous Agreement” in which participants nod their heads at the same word, only to separate to begin work on their tasks with fundamentally different definitions of that one term in their heads. This isn’t dealt with, not because of dishonestly, but a shared assumption that syntactic agreement = semantic agreement. This isn’t necessarily a big deal, except when the term in question relates to the core approach and/or deliverable of a project!

    I’d be very interested in other causes false consensus that others can share.

    Shared lexicons, that force the multiple roles and tribes in a project to agree on precise term definitions can be tedious to construct, but often the very construction effort surfaces important misunderstandings and contending conceptualizations well before they can become dangerous.

    • Trevor: those are some very good points. One to add to your list is when you have two (or more) competing designs and although everyone agrees on where they want to get to, it’s the HOW that is not clear. Having two design teams working on their own approach as part of the same team can cause huge issues later on…

      • Jim,

        Excellent point regarding design conflicts. This particular problem is an entire study area of its own in software engineering and application development; too broad a subject to get into here. Suffice it to say that the earlier in a project there is conceptual alignment, the more positive the impact, but few project teams recognize the initial lexicon as having the risk management value that it has.


Leave a Comment