4. Five tips for product managers to have better meetings
How to run better meetings and stop wasting everyone's time in ones that aren't
Welcome! I’m Vincent and this is a Product Manager’s Notebook, a series of notes for people who are interested in sharing and learning the art of product management and career development. You can read my archive here.
If you appreciate reading this post, please consider liking and subscribing.
An audio version of this article is available courtesy of NotebookLM.
Product managers are in meetings all the time and the expectation is often that we lead the conversation. When you’ve been in a meeting that doesn’t go well, you find yourself thinking:
"Why have I/we been asked to be here?" 🙄
"Well, that's half an hour of my life I'm not getting back." 😤
"Seriously, we spoke so much and I have no idea what the next steps are meant to be." 😑
Sound familiar? Time is valuable, especially when you add up the hourly wage per attendee, and retrospectively, mistakes are usually made because of avoidable pitfalls. So how can we make sure that we make the most out of our meetings?
The Checklist
PMs have many different types of meetings, but I think they can generally be divided into:
Internal meetings, such as problem ideation, project kick-offs, agile ceremonies, influencing/motivating people, and business presentations.
External client meetings or user interviews
Both have very different requirements. Today, the focus is on the first, ie internal meetings, where the PM is expected to take the lead.
Here are a series of five questions to check off for a successful meeting based on lessons I’ve learned from my own and others’ mistakes.
Communication: Should this meeting be an email or vice versa?
Outcome: Does this meeting have a clear purpose?
Understanding: Does everyone have the right context?
Agreement: Is everyone on the same page?
Follow Up: Does everyone know what they’re doing next?
Bonus: Meeting etiquette
Let’s get into it.
1. Should this meeting be an email, or vice versa?
Occasionally the meme is true: the meeting could have been an email. At other times, the email should absolutely have been a meeting.
When should you have a meeting?
You’re trying to bring different groups together, and things like tone of voice gets lost in email. Misunderstandings can easily build up. Meeting for 15-30mins is much more efficient than the email loops and delays that otherwise follow.
You need someone’s expertise to ideate on a problem. Ideas are always best hashed out together face to face, whether virtually or in person.
You’re working on a high priority item and need to agree a path forward, build and maintain momentum to delivery. If you care about this issue and you need others’ attention, a regular meeting is needed.
When should you not have a meeting?
You have a single question to ask, which can be efficiently answered in an email.
Meeting invite: Cost for X?
“Hi Commercials team, can I catch up to clarify how we charge for X? Thanks”
Response: Declined. The answer is $0.03 per hit. You can check here for our rate card or chat to Z who is very familiar with this product.”
You’ve not done/finished your research on the problem you’re trying to solve and you’re trying to bring in other stakeholders.
PM 1: “Hi! I’ve brought us together to figure out how to solve for this problem someone has reported.”
PM 2: “I see. How many people have been reporting this?”
PM 1: “Just one so far, but they were quite angry so there could be a lot more.”
PM 2 (clarifying): “Have there actually been more?”
PM 1 (uh oh): “…Not yet.”
PM 2 (getting a bit annoyed): “So what makes you think we need to do work to solve this now?”
PM 1 (feels defensive): “Maybe it isn’t?”
PM 2 (decided that this is probably a waste of time): “…It feels to me like you need to do a bit more research before we start talking about solutions.”
As a PM, it’s your responsibility to be able to communicate the problem you’re trying to solve and why others should care about it eg impact on the customers/product/business.
It’s a lower priority item and should not be focused on for this week. Ask yourself: is the outcome of this meeting required for this week or are there higher priority items which require input or progress? Remember that your meetings are a reflection of your prioritisation skills, whether good or bad.
You might not even have a clear outcome yet for the meeting, which leads us to…
2. Does this meeting have a clear purpose?
What is the outcome you want from the meeting? Having this in mind allows you to set the pace to focus on the intended outcome and put a pause on divergent conversations. Examples include:
Get consensus/input on a decision? If so, it is critical that you have a view on the topic, or else you risk being a middle person. I’ve seen many PMs (including myself) do this and what generally happens is that you have many meetings and nothing gets decided.
Influence or generate a call to action ie someone to say or do something?
Ask yourself: What do they care about and why would they want to listen to you? What is the story you’re trying to tell?
Practical tip: Once you know what the target outcome is, I find it useful to put this in the subject of the appointment and/or the appointment notes.
Appointment: Enterprise metering for alt datasets
Meeting notes:
“Hi,
I’d like to understand the current usage metering architecture for alternative data to start understanding what would be required to translate this for an Enterprise use case as we are seeing rising demand from customers.
Please let me know if this time works or another is more suitable.
Thanks”
Being explicit about the outcome helps to focus attention for everyone involved.
3. Does everyone have the right context?
If this is a significant project, you should prepare a central document that stakeholders can access and comment on, focusing on the business context and key details of problem you’re trying to solve.
Practical tip: Google Docs works perfectly well here but you can become the bottleneck for access. Confluence also works perfectly fine - do what the rest of your org does.
Simplify, simplify, simplify. Some PMs like to dive straight into the technical detail, which can often be a distraction and sometimes come off as a display of knowledge. I get that you know the name of your no-SQL data table but do others in the meeting need to know? A deep understanding of the topic allows you to bring the right level of detail depending on who you’re talking to.
Visuals > Text: I’m a very visual person and I’ve always found that drawings help to get to shared understanding. That goes for user flow, system architecture and mock ups.
Practical Tip: Miro is my favourite visualisation tool at the moment, although Balsamiq, Canva or Figma are a much better fit for wireframing/mock ups, depending on the level of fidelity required.
4. Is everyone on the same page?
It is critical to get common understanding while you’re DURING the meeting, not after. Otherwise, you risk everyone walking away with different understanding of what was said and agreed.
Trying to get common ground after the call is like trying to get someone’s feedback on a meal after they’ve left a restaurant. They might respond, but they probably have other engagements that compete for their attention.
Practical tip: If you’re virtual, share your screen during the call to make changes and confirm with everyone there that they agree on what’s being discussed. If you’re in person, grab a piece of paper or a whiteboard if that’s to hand. Participation focuses the mind.
PM: “Let me quickly pull up the flowchart I created to see if I understand you correctly. Are you saying that number 7 requests 8, which checks our caching system 9?”
Engineer: “Actually, no. This entire section of 7-10 needs to be moved to the side as a separate response-request paradigm that gets used regardless of the type of request being made.”
PM: “Great, one sec - let me update that. (Makes change) Is this what you mean, or do you want to make the change?”
Engineer: “Let me add something. (Adds tweak) Now it looks right.”
5. Does everyone know what they’re doing next?
Follow up within 24 hours to avoid losing momentum or hard-won attention, and stakeholders moving on from your ask.
Practical tip: Write notes while you’re on the call, either on a a Google Doc or a personal chatroom which creates an archive of your notes. Make it easy for yourself to search and reference.
Be succinct. No-one has time for you to recap the minutes of the meeting. Keep the email short if you want people to read it and summarise the salient points discussed.
Use numbered lists for action items and assign ownership to each task, as well as expectations on when this will be actioned/delivered.
Thanks all for your time today.
Summary:
We identified that cause for the reported bug is either A or B
Depending on which one it is, we need to do either C or D
Next steps:
Rob will retrace the user’s requests to confirm if A or B is the main problem
If it’s A, Rob and Vikram will test and confirm if rolling back our previous release will unblock the user and assess what the long-term solution needs to be for us to scale
We’ll speak again on Friday to confirm findings and assess long-term solution.
Thanks,
General rule of thumb: The more senior the person/the more important the meeting, the higher you prioritise the follow up. People remember those who don’t follow up and it can be a stain that permanently marks your record.Bonus: Meeting Etiquette
If you’re working with colleagues in other timezones, be considerate about the meeting time. Unless it’s urgent, avoid the last hour of the week - do you really want to be that person holding someone back from their weekend with a Friday 5.30pm meeting? Most things can wait till Monday.
Don’t double/triple-book someone, or at least ask before doing so in case their existing meetings are flexible. It’s guaranteed to p*** someone off when simple due diligence could’ve prevented this. Your meeting is likely to just be ignored.
Be direct and get to the point - Depending on who’s in the room, you can skip the preamble and introduction to the problem/discussion and get straight to the topic at hand. Clarifying questions can be asked if anything’s unclear, or you can check if anyone needs clarification at the beginning of the call.
You can end the meeting early if you decide it’s appropriate. Time is valuable for everyone, so it’s okay to end the meeting early when you’re done or the meeting is no longer productive eg you don’t have the right people on the call, or more research is required. Just because the call is scheduled for 30 minutes, doesn’t mean you have to take the full slot.
Be protective of your calendar: do not schedule regular meetings that don’t have the need - remember: your own time is valuable too.
Summary
Having a productive meeting is a lot of work behind the scenes. As a PM, you will decide how to run your meetings based on your organisation, work culture, politics etc. Having at least thought about the key questions will help to prime you for success.
Communication: Should this meeting be an email or vice versa?
Outcome: Does this meeting have a clear purpose?
Understanding: Does everyone has the right context?
Agreement: Is everyone on the same page?
Follow Up: Does everyone know what they’re doing next?
I hope this has been useful for you to improve the ways you run better meetings - good luck!