Product managers: I think we suck at talking to each other.
I write that tongue-in-cheek, of course – but not without a grain of honesty.
As product managers – people who pride ourselves on our communication skills, if not our ability to herd cross-functional cats towards a common goal – we do seem sometimes to struggle to align with each other on objectives, or roadmaps, or even discovery. Most product managers I know feel connected to their squad (the designer and engineers on their cross-functional team) yet markedly siloed from their product peers. Many product meetings and 1-1s primarily inform and aim to reduce the risk of conflict; they rarely enable collaboration.
What's more, this difficulty – or at least the way it tends to manifest – is somewhat new, not so much a relic of old-school product management as a consequence of moving away from it.
A decade ago, top-down management secured cross-team communication because (in many organizations) it dictated it: a product leader set the course, and product managers followed it, often co-developing features. (In my first product role, each of the wider team's product managers had to review and approve other teams' feature specs before development began to ensure continuity. While this practice helpfully increased transparency, its extended range of decision-makers feels almost unthinkable in a world that prizes the autonomy of vertical teams.)
Since then, we've moved more or less completely towards autonomous squads – a move that, I'll add explicitly, has been primarily for the better: smaller, independent teams can fail faster, learn more quickly, and have a more significant impact.
Yet, I think the erosion of top-down management styles has also diluted, in many organizations, the cross-team context-sharing it required. It's almost as if product leadership in many organizations overcompensated and decided not to establish any cross-team context out of fear of dictating too much. Individual teams, meanwhile, are often encouraged to "be autonomous" and define their quarterly objectives; they're far less often encouraged to ensure continuity with other teams or an overall strategy.
Nor does it help that vulnerability is still discouraged among product managers (despite the growing importance of empathy and high emotional intelligence to the role!). Meetings that aim to inform rather than to drive collaboration discourage saying, for example, "I'm stuck. How would you tackle this problem?"
What typically results are a few antipatterns:
There's no overall product strategy. Instead, each vertical squad has its own strategy. Because these squads are autonomous and often conduct research, they ship good work; but that work doesn't align with other teams, and the broader product team misses out on more impactful opportunities. Even worse, because prioritization doesn't happen cross-team, work rarely gets deprioritized – and sometimes it should. Team A may need Team B to help with a more impactful initiative for the company, but if no one ensures that Team B understands its importance, it may get pushed to next quarter or next year to accommodate Team B's timelines.
The burden of cross-team context-sharing falls on Design. If you've ever heard about something another team is working on from your designer, you know what I mean. Embedded Design teams – perhaps in part because they’ve evolved from a shared function – commonly work cross-team to ensure that new features' visual and experiential aspects align. Unfortunately, product managers frequently take Design's role as cross-team "glue" for granted.
Product managers don't get the career development they want (or even need). We learn not only by having great mentors and working in environments that facilitate our success but also by encountering different ways of solving problems. Siloed teams prohibit us from seeing how our peers solve challenges and learning through their experiences and ours. (To be fair, sharing wins happens often – but it’s seeing the process, not just the result, that matters.)
To some extent, Product Operations – as a relatively nascent discipline – aims to solve some of these gaps and enable strong context-sharing among squads. But the newness of the function means that not every company has a Product Operations role or that facilitating cross-team communication will be its primary function (as opposed to, say, establishing metrics and working with Customer Success). In any case, the emergence of Product Operations is arguably evidence that many teams struggle to build cross-team context effectively.
So how do we suck less at talking to each other? Easy: we go back to the Dark Ages.
(As a former medievalist, I resent this meme.)
In all seriousness, I do think there are some more immediate, practical "mindset" changes in the way we approach cross-team meetings that can help:
Think at the organizational level, not just the team level. When working cross-team, identify common or shared goals that, when partnered on, might drive an outsize impact. If resourcing conflicts arise, try to reframe the problem by determining which option most benefits the overall company, not just an individual team. If necessary, direct some of those “organizational level” questions up the management chain.
Share challenges, not just plans and wins. People respond more passively when they think you're telling them something versus when they understand you're asking for help. Ask your peers for advice on a problem when you're stuck. Chances are you'll not only get unstuck, but you'll also learn about other teams' challenges and contexts in a way that will organically increase collaboration and cross-team knowledge. (Not to mention, your designer will thank you for carrying some of that weight.)
There are also longer-term processes that can help increase transparency but aren't necessarily quick wins:
Hold feedback sessions. Establishing periodic or ad hoc feedback sessions for an initiative or feature can be a lightweight version of the spec review I experienced in my first role. The difference is that your team remains the decision-maker – no one needs to “approve” you pursuing that path – but at least you open yourself up to constructive criticism before development. I've found that this is particularly helpful if you call out open questions or unsolved challenges. Many times I’ve reduced the scope of work, partnered with another team, and streamlined discovery just by being curious and asking for feedback.
Initiate a writing culture. I'm a big fan of writing cultures – I think it's something Amazon got incredibly right. In this context, a writing culture can look like sending out a weekly or biweekly update to your peers or sharing a short one- to two-pager (essentially a written version of the feedback session above). Writing out your ideas and asking for input can be doubly helpful because it additionally encourages you to process your thinking before sharing it with others. The risk is that not everyone is a fan of writing cultures, so you may need to encourage others to get them onboard.
Define and socialize an overall product strategy. (Hey, I said not necessarily a quick win!) If you're responsible for multiple teams or manage product managers, it is your responsibility to make sure your teams have the strategic context they need. That means encouraging cross-team context-sharing and ensure that teams' respective strategies align. Not everyone agrees on this point, preferring to let teams develop their own strategy. But it’s less about reducing an individual squad’s autonomy than it is about enabling transparency and cooperation among squads, and empowering them to achieve an outsize impact.
Driving cross-team context sharing – talking to each other as product managers – is, unfortunately, lacking in many organizations. But being mindful of opportunities to build cross-team trust and context can lead to a more holistic product, a healthier organization, and better career growth for individual product managers.
If you enjoyed this post, consider subscribing. (Come for the product talk, stay for the memes.)
Came to this from When there's no strategy after you shared it on Reddit. This one also resonates so much.
Certain fellow PMs assume I'm a terrible communicator vs. other PMs & other groups I work with laud me often, in large part for the mindsets we've taken in working together; the ones who operate siloed or grew up in wholly-autonomous product vibes feel like we talk past each other, the ones who primarily want to collaborate and/or are better at cross-team strategy in the first place think we're in sync & appreciate spitballing with me for advice.
A sadder point that I also really feel, "vulnerability is still discouraged among product managers."
I think I have accidentally made some of my peers think I'm incompetent by being particularly willing to ask 'How would you tackle this problem?,' especially because there are times I feign being the one who wants opinions--sometimes it's merely a question someone else was only brave enough to ask just-me. And I'll give my advice, but who's to say my advice is the best? Some things are ripe for discussion!