If I were a PMM, I wouldn’t start with how the messaging sounds. I’d start with what each team knows about the product. And I’d do it because I know what usually happens.
Team members learn about a new capability. Maybe through a meeting. An email. A Slack thread. A passing conversation with someone from Product.
They get the gist of it. Enough to move forward and …
But they’ve missed something about this new capability. A core distinction. A limitation. A logic layer that didn’t land.
So instead of asking … ‘Did I understand this correctly?’ They keep reinforcing what they think they understand.
And they’re 92% right about the new capability. But the 8% they’ve missed? This lives everywhere.
In every explanation they share. In every sentence they write.
And that’s something you, as a PMM, can detect. Not by assessing whether messaging ‘sounds right.’ But by listening to what they reveal about what they know.
Here’s what I mean …
Teams using different words to explain the same capability? The underlying concept didn’t land in a shared way.
A simple capability question leads to a long explanation? Your teammates didn’t internalize a clear model of how it works.
The capability story changes depending on who tells it? Each teammate built the narrative from their own perspective.
Teammates explain the same capability the same way in every context? They rely on memorized phrasing, instead of adjusting understanding.
Different teams communicate different capability attributes & outcomes? Each one fills the knowledge gap with assumptions, not product reality.
And this is where messaging issues often start. In how well team members understand the product. And this is where I’d start if I were a PMM.
Instead of focusing on messaging, I’d ask …
And then …
I’d work internally to identify & bridge product knowledge gaps ...
So messaging isn’t built on assumptions but on shared understanding.
