Like many of you, I’m constantly playing with how to run and scale effective communication across multiple product managers, cross-functional teams, and a broader organization. Here’s a quick take on some of my current approaches.
Across PMs
I typically run a weekly hour-long meeting for all PMs. The agenda typically looks like this: 20 min on goals/OKRs, 30 minutes on going deeper into one or two topics, 10 min on housekeeping/other. During times of greater stress, I’ll often start with a color exercise where people just state whether they, personally, are green/yellow/red and a short explanation about why.
Goals/OKRs
Once we’re past any kickoff elements to the meeting, we have 15 minutes of silence where everyone reads through an updated, running goals slide deck. Each PM is responsible for their own slide(s) in this deck [click here for an example template]. I use the OKR quadrant from Christina Wodtke’s book Radical Focus for two reasons: it tracks forward-looking confidence and it tracks possible negative side effects. I also like each PM to keep a running, lightweight visual roadmap along with an OKR quadrant slide.
Each PM is expected to create a new, updated version of their slide for the current week, and this must be done before the meeting. The team scans through each others’ slides and asks questions inline in the doc. Putting most Q&A activity into the doc itself keeps the meeting moving and pushes 1:1 conversations offline.
The last 5 minutes of the OKR review (20 min in total) should be reserved only for those updates and answers that are essential that everyone hears.
Note 1: Let’s be honest, most orgs do OKRs badly, but whatever you call it and however you approach it, teams need goals and should track forward-looking confidence in hitting those goals.
Note 2: depending on your culture, you might find it useful to open up your running OKR doc to others (or everyone) in the organization in a read-only manner. You can only do this if you are confident that your PMs will stay completely honest on their slides and not engage in theater/spin. Frankly, most people won’t pay close attention.
Note 3: The above can scale to about 8 or 10 PMs at max. Beyond that, you’ll need to split into separate groups and run this at two levels: across the groups and across the group leaders.
Speaker Section
The next 30 minute slot is reserved for one or two (at max) speakers. It might be a PM who wants to share something they learned, workshop a challenge, or give a demo. I like to bring in guest speakers from data science, finance, marketing, customer support, etc. Sometimes these are CxOs, sometimes experts in other areas at the same level as the PMs, and sometimes experts from outside the org.
Across Product Teams
I explicitly ask PMs to make sure their teams understand what is going on in the other teams and seeing the big picture. If you have a stand-up of stand-ups, engineering leads/managers can help with this, but PMs should make sure it is happening.
When two or more teams have a lot of interdependencies, it’s essential for the eng-prod-design leaders of those teams to run intensive check-ins at least once a week. This cannot be left to documentation (things change too fast), email or Slack. In this scenario, a project manager can also be really helpful.
Across the Organization
I’m an unabashed fan of internal blogs. Frankly, I’ve had such success using them that I’m shocked more companies don’t do this. I find them far more effective than email or wikis (where information goes to die in obscurity).
Don’t let tooling stop you here. If an internal blog is too hard to spin up, create a running Google Doc, or just use email updates (trouble is, update emails often get lost if they aren’t read right away).
I insist that every PM update the company on their activities at least once every 6 weeks, if not 4. This can be about their goals, progress, wins, challenges, etc.
As a product leader, I try to write something every other week if not every week. Getting PMs to keep to their publishing cadence can take some pushing, but one thing is universal: every PM who has ever worked for me has agreed that being forced to write about their team’s work for the organization has required them to think about it harder and understand it better. It’s like the old adage — if you really want to understand something, try teaching it.
I also like running open demo sessions. At Meetup, we took over a Wednesday lunch every other week to share what was going on in engineering, product, design and data science. Anyone in the company could attend. No one was required. We tried to mix up who did the presenting (not always the PM!) as well as the level of “done” of what was presented. I’m a huge fan of being transparent and “rough draft culture” so sometimes designs could be quite raw. Sometimes it could get fairly technical, although we asked our technical presenters to translate things for the “lay” audience.
We had a couple of volunteers from the eng-prod-design org who did a good job keeping it organized, keeping sure we had a full docket, and moderating the sessions to keep things moving crisply.
Lastly, like many orgs, we would do periodic roadmap update presentations to the broader company.
Of course, none of this will prevent people from saying to you, “I don’t know what product is working on.” That’s because people are caught up in their own fire drills. Don’t let that discourage you. As every new CEO learns the hard way when trying to communicate strategy: repetition and perseverance are as important as clarity when it comes to communication.
Final Notes
The above isn’t to say “this is how it should be done” but to share ideas of how it can be done in case you want to take them and make them your own. What isn’t in the above is how to build coherence, relationships, and fun across the PM organization since so much PM energy gets directed towards their cross-functional teams. This is rightly so, but it’s worth working on bonding, mutual support, and cross-pollination within the PM team as well.
Top image: Jason Leung on Unsplash