A note for new subscribers: This post is part of a series on my notes on technology product management (this is what I do for a living). You might notice that these posts often link to older posts in the series on LinkedIn even though they are all available on this blog. That is intended for folks who only want to follow future product management related posts. Finally, for all those of you who don’t build tech products for a living, I believe many of these notes have broader applicability. And I hope you find that to be the case as well…
A quick overview of what we’ve covered on “Notes on Product Management” so far –
- Overall: The IC PM Role, The 4 key skills, Remote + Pandemic PM, 5 Decision Making frameworks/heuristics, Problem finding/solving with executives, Managing psychology
- Skill #1 – Problem finding: Most important skill, Problem statement and hypothesis, Building Strategy, Validating problem statements and hypotheses, Exploration OKRs
- Skill #2 – Selling: Sales and Marketing, Writing for executive audiences, Product executive relationships, Learning to sell
- Skill #3 – Problem Solving: Roadmap, Product specs, Solving for Usability, Solving for Feasibility, PM<>Eng collaboration, Ramps and launch checklist
- Skill #4 – Building effective teams: Knowing thyself, Your manager, Product team culture, 5 habits – high velocity product teams, Effective 1:1s, Kick Offs
- Managing your career: Getting in – I, Getting in – II
A quick recap on the 2 dysfunctions of a team
In the last post, I shared the 2 most common dysfunctions of a product team –
(1) Absence of shared context. Everyone in the product team is paid to make decisions. It is impossible to make good decisions when you are missing context. A simple test – can everyone on the team confidently articulate the problem statement, our desired solution, and the key data points that give us conviction?
(2) A lack of deep trust and care. If people in the team don’t trust others to make the right decisions, we’re going to frequently find ourselves in decision making bottlenecks. A simple test – would your Eng/Design/Data/Marketing partners trust you to make the right calls on their behalf? Would you do the same?
After laying these out, I shared 2 powerful tools to deal with these dysfunctions –
(1) Start the collaboration with an effective Kick off (previous post)
(2) Run effective weekly/bi-weekly update meetings (this post)
Kick Offs help us start our teams/initiatives off with positive momentum as they ensure we start our collaboration with shared context and an understanding of each other – which provides the foundations for trust. However, the power of a great kick off doesn’t last forever. An effective weekly or bi-weekly team meeting helps us keep the momentum going.
Let’s start with getting 2 things out of the way –
- Who attends? For most IC PMs, it is helpful to invite everyone who is on the product team. This will typically include your cross-functional partners, any partner PMs, and all the engineering ICs. For senior IC PMs (typically late SPMs or PPMs) who are leading multiple connected initiatives and x-functional teams, it may not be possible to involve every engineering IC on a weekly or bi-weekly cadence. So, it might make sense to split the meetings into a monthly with all ICs and weekly/bi-weekly with the x-functional leads.
- How often? Can be monthly or bi-weekly or weekly depending on how well you use the time/shipping cadence of your team. There’s no “right” answer. Similar note on length – they can last anywhere between 30 mins – 1 hour. I’ve personally found 45′ to be a sweet spot.
With that out of the way, let’s move to the elements of an effective weekly meeting.
The 4 elements of an effective weekly meeting
After years of experimenting with weekly meetings, my formula for a weekly meeting has 4 elements. Of course, we all operate in different contexts, cultures, and with different working styles. So, while some of the principles will hold, your mileage with specific tactics will vary:
(1) Clarify the purpose – for ourselves and others
Derived from the 2 dysfunctions of the team, effective bi-weekly/weekly meetings focus primarily on shared context and tackle deep trust and care as an ancillary benefit.
The reason for this is that trust is a complicated beast and isn’t one we can tackle explicitly every meeting. Here’s why:
- The best definition I’ve heard for trust is: “Trust is choosing to make something important to you vulnerable to the actions of someone else.”
- We choose to trust folks when we know and understand them. That trust means we assume good intentions every time they act. That is why taking the time to get to know people while sharing what you’re all about is critical. When people understand us, they begin to trust us – or choose to make something important to us vulnerable to their actions – and vice versa. This is where kick-offs and introductory 1:1s (see post) help.
- The trust that is built in us grows when the team sees consistency over time. This is the role effective weekly meetings play. Trust is thus the by-product of a good product.
(2) Keep a consistent agenda that ladders up to this purpose
This is definitely the area where your mileage may vary significantly. I’ve come to appreciate the value of consistently building an agenda with the following pieces:
(a) [Optional] Start with some form of kudos/recognition. These are useful because they help highlight individual work while also naturally helping everyone understand key milestones/wins. The only caveat here is that the effectiveness of this depends on the size of the team. It doesn’t work as an agenda item when the team is too small or too large. I don’t have a rule of thumb for what constitutes “too small” or “too large” – so, it is one of those things you’ll learn after you try it over 3-4 meetings.
(b) [Required] Share any context/updates from leadership or the broader org: If there is anything that impacts the team – e.g., a new strategic priority, an org change from a partner team, an important meeting, etc. – take the time to share this with the team so everyone has the context. If these were sent via email, it helps to share that with the group in advance as well in case there are any questions.
(c) [Required] Go through key product changes and/or lessons learnt. This is the most important part of the meeting. It helps build shared context and ensures we’re operating well. There are a few things that help here:
- Go through every key product change in sufficient details – this includes giving the team context on the problem we’re solving, walking through designs and hypotheses, and sharing any results. This helps others connect the dots and follow up where there are questions/disconnects.
- Share insights from research/customer calls/user data, etc. Again, it helps folks connect the dots.
- Finally, the insights/discussion from this meeting should go into the team’s weekly update and/or executive update. This ensures everyone is on the same page on what is being communicated.
(d) [Required] Understand impact or changes to key metrics/results. The products we ship are in the service of making a positive impact to users, customers, and the business – we measure this impact with key metrics/results. So, it is imperative that we spend time on a weekly basis talking about key metrics/results. In case of new teams where these metrics aren’t baked yet, it helps to have a clear ETA for when these metrics will be ready. In the meantime, individual experiment metrics can work.
(e) [Optional] Leave time for “special topics” – discussions on key documents or decisions: This may not be a standing agenda item but it is helpful to carve out time for readouts on key experiments, strategy or design changes, and/or go-to-market updates.
(3) Showcase urgency by standing up and by facilitating written discussions
“Showcase urgency” is easier said than done. 2 things that I’d recommend –
(a) Stand up (i.e., physically): There’s something about standing up that helps us become more intentional about our time and bring a sense of urgency to the meeting.
(b) Facilitate written discussions (instead of “round-the-rooms”): Whenever you have a topic to discuss, default to written discussions.
What is a written discussion? It involves sharing a prompt with the group and having everyone share their point-of-view on a shared spreadsheet. Then, you go through the spreadsheet live, aggregate themes, and drive discussion around those themes. Here’s an example spreadsheet.
These discussions are more effective (you have an open discussion on themes in everyone’s POV and get to the best answer), efficient (you hear all POVs without going around the room), and equitable (the discussion is focused on ideas vs. who is most willing to speak up).
(4) Collect feedback/iterate
Every quarter, dedicate 15′ in your meeting to facilitate a written discussion about the meeting itself. Ask folks for 1 thing they appreciate and 1 thing they’d like to change about the meeting. Asking for 1 thing forces prioritization and any themes you notice in the feedback will be very valuable.
A big part of running “effective meetings” for any group is to keep evolving them as the nature of work and camaraderie on the team evolves. Change is the only constant.
2 thoughts on “Running effective team meetings (feat. written discussions)”
Comments are closed.