Communication Anti-Patterns in Platform Product Management
To avoid at all costs
This week's newsletter was supposed to be Part 1 of crafting Product Strategy in Platform. Still, last week's interview really inspired me because communication, more specifically, effective communication, came up a few times. So I decided to go completely off track and write about Communication Anti-Patterns in Platform Product Management.
I really believe communication is one of the critical skills to master as a Product Manager, especially a Platform Product Manager. In the words of Winston Churchill:
If you have an important point to make, don't try to be subtle or clever. Use a pile driver. Hit the point once. Then come back and hit it again. Then hit it a third time - a tremendous whack.
Fancy quotes aside, the point is very valid.
As a Platform PM (not the Churchill variety), one of the biggest challenges you will face is communication breakdowns with partners, such as the Engineers and the rest of the organisation.
There is so much content and training on effective comms that I won't add to it, but I will talk about a least approached subject, the anti-patterns.
But first, what are Communication Anti-Patterns?
In my own definition, communication anti-patterns are behaviors or patterns that block effective communication between individuals or teams. These patterns can arise for various reasons, such as different communication styles, language barriers, or lack of clarity. As a non-native English speaker, I think about this quite a lot.
Here are a few I came across so far:
Speaking in Technical Jargon
One of the most common communication anti-patterns in Platform Product Management is speaking in technical jargon. While it is easy for engineers to understand, non-technical stakeholders struggle to grasp the meaning behind the terminology, and they will lose interest quickly. So, don't do it. Don't be this person:
Source: Medium.com
Try this instead:
Know who your audience is and adapt the communication. Draft it a few times before. Ask for some feedback if you want.
Use clear and concise language that is easily understood.
Avoid using technical jargon or acronyms unless necessary. No K8s, ECR, EC2, ECS, and the rest.
Provide context to help non-technical stakeholders understand the meaning behind technical terms.
Use visual aids or diagrams to explain technical concepts when appropriate.
Focus on the Impact, not on the technical side. No one wants to know what AWS-managed services you are using, but what's the Impact of using those?
Working in Silos
Oh boy, how easy it is to do this and close yourself off in your Platform ivory tower. This usually happens when the team works independently without sharing information or collaborating with others. This is reflected in missed opportunities, duplicated efforts, and a need for more alignment between teams. More importantly, this will guarantee a lack of adoption of the internal product. Emphasis on lack.
Try this instead:
Foster a culture of collaboration and transparency within the teams.
Speak to your users all the time.
Encourage team members to share information and work together on projects. You shouldn't be the only one communicating with the Engineers.
Establish regular communication channels, sync, or async. Try not to fall into the just-one-more-meeting trap, either.
Ensure everyone has access to the same information and resources to avoid information silos. Yep, ensure your documentation is up to date and in a centralised place.
Lack of Clarity
This extends from your internal ways of working to strategy, OKRs, and roadmap; the list can get long. It usually occurs when vision, strategic objectives, plans, and requirements are not clearly defined or communicated. As a result, you end up with misalignment, frustration, and subpar work. Sorry, but it's true!
Try this instead:
Ensure your vision and strategy are clearly defined and communicated to all stakeholders. Get alignment on this by collaborating early with your stakeholders.
Work closely with the teams to ensure that everyone understands the requirements and that these are aligned with the product vision.
Establish a continuous feedback loop, especially on OKRs.
Provide regular updates to users and stakeholders to inform them of progress.
Over-communicate everything provides better clarity. Or so I think.
Lack of feedback or inconsistent feedback
Finally, the lack of feedback can be the nail in the coffin of communication. Again, I am slightly dramatic in sending the point across, but I have never witnessed good communication without a strong feedback loop.
This happens when you, the Product Manager, are not actively looking for feedback and assume that people know what you and the team are up to because you put it in a bi-weekly internal newsletter two weeks ago.
Try this instead:
Encourage feedback from teams and stakeholders by actively searching for it.
Set up a more formal feedback loop like surveys or one-on-one meetings, Slack-channels, Notion docs, etc.
Act on feedback received and communicate how it has been addressed. Sort of like, 'You said x, we did y'.
To conclude, Communication Anti-Patterns can significantly impact the effectiveness of your communication style. And it will impact the Product too.
By identifying and avoiding these anti-patterns, Platform Product Managers can build stronger stakeholder relationships, foster collaboration and alignment between teams, and drive innovation and growth for the internal product.
Don't be this person:
Source: Medium.com
See you next Friday!