Words Matter
Ask what top skills are needed to be successful as a Product Manager and “effective communicator” frequently comes at or near the top. We can all agree that whether we are interviewing customers or iterating on design with the Product Team, effective communication is paramount.
Despite this, many Product Managers live in a world of jargon so ingrained we forget it is not a common language outside our bubble. Moreover, even if words are used repeatedly in our space, it does not mean we are all talking about the same thing.
Why is this important?
We use our jargon to succinctly communicate about a concept without having elaborate. This shorthand creates more efficient conversations and allows participants to spend more time discussing the novel parts of a topic.
When the words we use fail to mean the same thing between all those participants in a discussion it can undermine the content of our communication.
Let me share 4 examples.
-
MVP
-
Feature
-
User Experience
-
Outcome
Some surprising examples
MVP
It should be no surprise to anyone reading this article the Minimum Viable Product, aka MVP, makes my shortlist. Eric Reis coined the term in The Lean Startup. There, as well as on the podcast and event circuit, he speaks about MVP as being anything to create validated learning. It can even be a sign-up form for a service that does not yet exist to validate some degree of market demand.
Since that time, many use MVP very differently. For them, it is equivalent to an initial release, aka Version 1.0, of a product offering.
I have an opinion on which is correct, but it frankly does not matter. Neither does your opinion. What matters is that when communicating with others you have a shared understanding of the definition you are using.
If your CEO is expecting to have a market launch around your MVP, but your team was simply creating an interactive prototype with Figma, this is a communication problem that must be fixed.
Feature
This must be on the list by mistake, right? Everyone knows what a feature is. Actually, there are multiple definitions of features that get tossed around with hardly a moment of thought on what it means.
Product Marketers speak of features and benefits to the market. In this context, features are the key capabilities that are marketable. Hence, the old term ‘“minimally marketable feature”, which itself often needs clarification.
Now, if your organization practices Scaled Agile Framework (SAFe), you have a different definition provided to you.
Feature (SAFe): A Feature is a service that fulfills a stakeholder need. Each feature includes a benefit hypothesis and acceptance criteria, and is sized or split as necessary to be delivered by a single Agile Release Train (ART) in a Program Increment (PI).
Now, as a customer, I don’t care how long it took you to implement a feature. I don’t know what a Program Increment is. So Product Marketers, would look at this definition and see it has no bearing on what they are communicating to the market.
Elsewhere in the non-SAFe world, product teams generally assume they agree on what a feature is. Do a simple exercise where you ask an engineer and marketer to each define feature and see if there is a gap. This is a fundamental product management term used every day.
Don’t get me started on what the Data Scientists have done to the term. :/
User Experience
Sometimes, even the experts in their craft aren’t sure how a term they use should be defined. In a Tweet from a week ago, Samuel Hulick of the very informative UX site UserOnBoard.com posed a simple question. “If someone visits your software 12 times, would you say they had 12 different “user experiences”…
If someone visits your software 12 times, would you say that they have had 12 different "user experiences" or just one all-encompassing "user experience" in general?
— ? ? Samuel Hulick ? ? (@SamuelHulick) May 25, 2020
At times debates on terminology venture into the realm of philosophy. His question was awesome because it exposed a crack in the everyday thinking of product designers on just how they define UX.
Outcome
This one is simple. The “outcome” is the result of some action or inaction, right? Well, we recently got an updated definition from Josh Sieden in his book Outcomes over Output to be used specifically in the product development context.
Outcome: an outcome is a change in human behavior that drives business results
Now, all of the sudden, we have this special definition that requires impact on humans and a causal effect on business results. This definition is powerful but without reading the book you might be excused for being stuck in the generic definition which would impact how you communicate about outcomes with others.
Furthermore, if you are prone to reading management books you may have also read Andy Grove’s High Output Management. If you have, then you might be focused on measuring output over activities. Is Grove’s focus on managing output now outdated and displaced by Seiden’s urging to focus instead on outcomes?
No. Absolutely not. A better interpretation is to say that, when Grove spoke of output he was focused on the specific type of output that lead to desired business results. In some sense, I view his output as synonymous with Seiden’s outcomes.
That sure is confusing.
Now imagine you are a new CPO, a disciple of the Andy Grove school of management, and you are having your first all-hands meeting with your product organization. The focus of the discussion is around how you would like to gain greater insight into the output of your product teams. Without even knowing it, you just turned off all the Josh Seiden fans in the room because of using a “bad” term, while meaning exactly what they wanted to hear.
Words, and their shared definition, matter.
Concluding Advice
First, when you join a new organization, take the time to learn what the local definitions are for common product management words. Do not get on your soapbox to tell people they are using MVP wrong if it doesn’t align with something you just read or how it was used in your old company. Assume definitions are fluid over time and context. What matters is effective communication.
Second, if your current organization is more than a few people make sure there exists a readily accessible dictionary of local jargon. New hires and those from distinct departments can refer to.
Finally, when interacting with external audiences such as customers, partners, investors, analysts, and prospective employees do your best to strip away the jargon. When it feels necessary to use it, take the time to define your terms, and remove unnecessary friction in the process.
Similarly, when your external stakeholders use jargon, ask for clarification. Don’t ever assume that your customer means the same thing as you.