Product managers spend a lot of time in meetings. 

The "productivity" email I get from Microsoft, based on my Outlook and Teams activity, tells me that I interact with 50-60 people a month, and spend around 25% of my time in meetings.

That's a lot of time sitting around talking, but it's fine to do if the talking has a purpose and you are gaining value from it.

So if you're new to product management, what meetings can you expect to be part of, how do you contribute, and what value will you gain from attending?

Daily Stand-ups

As the name indicates, these are daily meetings and are chance for the team to get together and for individuals to highlight their progress, indicate what they're going to be working on next, and flag up any issues that might impeded their progress.

These are sometimes called huddles, daily scrum, or morning rollcall.

They're short sessions (maybe only 30-60 seconds per team member) and should stay focused.  If something needs a more in depth discussion then it gets discussed outside of the stand-up.

From a PM perspective, your job is to highlight anything that you've been working on that is going to impact the team (for example, you've had a conversation with a stakeholder and a requirement has changed and action is needed), and also you can be there to help clear any of the impediments that the team faced (for example, they're developing a feature and a scenario that hadn't been considered is found and guidance is needed on how to proceed).

Backlog Refinement

Otherwise known as Backlog Grooming or Feature Review, this is a periodic session with the focus on the team reviewing the upcoming new product features to prepare them for being worked on.

This involves the Product Manager discussing the feature, highlighting the goal of the feature and how it is intended to work.  The team then has opportunity to ask questions, raise concerns, suggest approaches, and it is also an opportunity to put an effort estimate on the feature (in time, story points, or t-shirt sizes depending on your preference).

From a PM perspective, your job is to get across the purpose of the feature so that the team can understand what it is that they would be delivering with this work.  You will be responding to questions and adjusting the feature description / user story as feedback dictates. By the end of the session you'll have better formed features, with a clear indication of how long it 'might' take to deliver, which will support in prioritization and planning.

Sprint Reviews

If your organization operates Scrum, then you'll be a participant in the sprint review; the ceremony at the end of a sprint that allows the team (and associated stakeholders) to inspect the outcomes of the sprint activity.

The Product Manager's involvement does vary depending on the organization, and I've seen it where the PM leads the discussion by demonstrating the features that have been delivered, whilst in other organizations the developers demonstrate their own work.

This session is a great opportunity for the PM to see the progress that is being made, as well as understand what else needs to be done, and plan for future activities.  By the end of the session you'll have clear idea of what was achieved and where we need to go forwards.

Sprint Retrospectives

Often included as part of the sprint review, a retrospective is a session at the end of a sprint that looks at what went well during the sprint and where are there areas for improvement.

Essential for improvement in self-managing teams, I loved a retrospective session.  For PMs and all other team members you have the opportunity to raise issues and concerns related to things that caused problems for the team during the sprint cycle.

This could be anything from changing requirements, to inefficient systems or application downtime.  Lack of knowledge, to under estimation and unclear user stories.  Whatever it is there's a chance for the team to take corrective action with the aim of avoiding repeated issues and improving output.

Stakeholder feedback sessions

Some people would say that stakeholder feedback sessions are the most important meeting for a product manager to attend, however, without involvement in some of the other sessions in this post, you'll have great understanding of needs but a reduced ability at delivering features that meet the needs.

And you'll notice that I'm referring to the people you meet as 'stakeholders' and not specifically as customers or users.  The PM has a responsibility to all people with a vested interest in your product and its operation, not just the people who are end users of it.  This might involve speaking to finance teams about payment options, customer support teams about frequent issues, marketing teams about upcoming promotions, or legal teams for compliance issues.

As a PM your goal be to meet these groups at regular periods to ensure you're aware of their needs so that you can plan your roadmap and associated backlog.  The more you know about what all your stakeholders need, the more you're able to see common themes and plan accordingly.

Product Advisory Boards

Many organizations don't operate with a product advisory board, but in certain circumstances I've found them to be essential for longer term planning.

They're a selection of your stakeholders that you go to on a regular basis in order to understand the bigger challenges that they're facing in their lives, not just the issues that they have with your product.

For example, if your product is all about showing where traffic jams are, your standard stakeholder feedback focuses on the ease of sign up, the frequency of the traffic data updates, the clarity of the messaging.  For advisory group feedback you're thinking bigger.  You need to understand what other things drivers are looking to avoid, or why they’re traveling in the first place, or whether they’re open to alternative forms of transport.  

Understanding these bigger questions allows you to seek out new product opportunities that are complementary to your current product.

PMs go in to these meetings with the sole purpose of understanding more about the day-to-day challenges faced by the stakeholders they deal with. 

Strategic Briefings

The final meeting type in our list is essential for the product manager to understand where to focus their efforts.

Without a clear understanding of the strategic direction of the organization it is virtually impossible for the PM to deliver real value for the business.

Does the organization need to focus on reducing costs in the next quarter?  Is new customer acquisition the key metric?  Do we need to reduce a growing churn rate?

Whatever the organizational strategic goal is will impact how a PM spends their time.  If the goal is on reducing cost, then the backlog should be prioritized with activities that aim to reduce costs, not that might increase them.

If you as a PM don't know what the business wants to achieve you won't know what to prioritize.  If you're organization doesn't share this information then push to get it, because it will make your role infinitely more effective if you know what to do and why.