10 min left 0%

running effective meetings

Meetings are still how product managers get things done. We need to understand how people are thinking about problems, what decisions they're trying to make, what information they're missing — so we can fill in those gaps. But if someone sends you a blank calendar invite with no agenda, it is okay to decline.
Talvinder Singh, from a Pragmatic Leaders remote PM session

Every PM I have ever coached has the same complaint: too many meetings, not enough time for real work.

Here is the uncomfortable truth. For PMs, meetings are the real work. You do not write code. You do not push pixels. You make decisions happen between people who would otherwise talk past each other for weeks. The meeting is the instrument. The problem is not that you have meetings. The problem is that most of your meetings are badly run.

I have operated teams at Zopdev, trained over 10,000 PMs at Pragmatic Leaders, and watched hundreds of product teams across Indian startups and MNCs. The pattern is always the same. The PM who runs sharp meetings ships faster. The PM who tolerates bad meetings drowns.

The decision tree: meet or don’t meet

Before you send a calendar invite, answer one question: does this require real-time human interaction to make progress?

If you need to broadcast information, write it down. A Slack message, a Loom video, a Notion doc. If people need to be informed, inform them. Do not assemble six people in a room to read a status update aloud.

If you need input from one person, send them a direct message with your specific question. Do not create a meeting to ask Karthik whether the API is ready. Slack him.

If you need a decision that requires discussion between multiple people who disagree, that is a meeting. If you need a brainstorm where real-time riffing produces better outcomes than async comments, that is a meeting. If you need alignment on something emotionally charged — a pivot, a reorg, a launch delay — that is a meeting.

Everything else is a calendar invite that should have been a message.

// scene:

Tuesday afternoon. An engineering team's shared calendar shows five meetings between 2pm and 6pm.

Riya (PM): “I need 30 minutes to discuss the notification system rollout. Can we do 3pm?”

Arjun (Eng Lead): “I have a sync at 3, sprint review at 4, and a 'quick alignment' at 5 that has been running 45 minutes every week for three months.”

Riya (PM): “What happens in the alignment meeting?”

Arjun (Eng Lead): “Deepak reads out the project tracker. Then we say 'looks good.' Then someone asks an unrelated question and we spend 20 minutes on it.”

Riya (PM): “That is a status update, not a meeting. Tell Deepak to post the tracker in Slack every Monday. Cancel the meeting. We just freed up an hour for your team every week.”

Arjun (Eng Lead): “He has been running this meeting for a year. Nobody has ever questioned it.”

That is the problem. Nobody questions the meetings that should not exist.

// tension:

A meeting that nobody needs survives because nobody has the courage to kill it.

At Pragmatic Leaders, we operated with a principle: Work in the Open. We prided ourselves on the hours we saved from bureaucratic syncs and connects. The decision tree was simple — if you need a decision or a real-time discussion, meet. If you need to broadcast information, write it or record a Loom. If someone just needs to be informed or consulted, do that before or after the meeting. Do not drag them into the room so they can sit silently for 40 minutes.

This decision tree should become muscle memory. Every time you reach for the calendar, pause. Ask: can I achieve this with a message? If yes, write the message. If no, then run the meeting properly.

The anatomy of a meeting that works

A good meeting has five elements. Miss any one and the meeting degrades.

1. A stated outcome, not just an agenda.

An agenda says “discuss Q3 roadmap.” An outcome says “leave with a prioritized list of three initiatives for Q3 and owners assigned.” The difference matters. An agenda gives people permission to meander. An outcome gives them a finish line.

Before every meeting, write this in the calendar invite: “This meeting will be successful if we leave with ___.” If you cannot fill in that blank, you do not need the meeting.

2. The right people and only the right people.

Every person in the room should be either a decision-maker, someone whose input is required for the decision, or someone who will execute the outcome. If they are there to “stay in the loop,” send them the notes afterwards.

In Indian companies, I see meetings with 12 people where 3 do the talking and 9 check their phones. This is not collaboration. This is an audience. A PM at Google put it well in one of our sessions: one of the biggest blessings you can give your team is cancelling a meeting. Those people had that time blocked out and could have been doing actual work.

3. A shared agenda sent in advance.

The agenda goes in the calendar invite or a linked doc. Not in your head. Not in your notebook. In the invite, where everyone can see it and prepare. If you send someone a blank calendar invite with no agenda, they have every right to decline. I would.

The agenda lets people decide whether they need to attend. If the three topics do not involve me, I can skip and read the notes. But if you send a vague “sync up on the product,” I have no way to assess that.

4. Active facilitation during the meeting.

Kick off by stating the agenda and the outcome you are aiming for. Keep the conversation on track. When someone goes on a tangent, say “that is important, let us take it offline and stay focused on the decision we need today.” When two people are debating something the room cannot resolve, timebox it: “we have heard both sides. Let us get the data and revisit Thursday.”

The PM is the facilitator, not the presenter. Your job is not to talk the most. Your job is to make sure the right conversation happens and a decision comes out the other end.

5. Notes, action items, and a follow-up within the hour.

Every meeting produces exactly one output: a shared record of what was decided and who is doing what by when. If a meeting does not produce this, it was a conversation, not a meeting.

Take notes during the meeting. Assign action items with names and deadlines — not “the team will look into this” but “Priya will run the query and share results by Thursday EOD.” Share the notes within an hour while the context is fresh. Oversharing is better than not.

// thread: #product-core — Ten minutes after a 25-minute meeting that produced three clear action items
Riya (PM) Notes from the notification rollout meeting just posted. TL;DR: (1) We ship push notifications to 10% on Monday. Arjun owns the feature flag. (2) We defer in-app notifications to next sprint. (3) Deepak will set up the alert dashboard by Friday. Full notes in the doc link.
Arjun (Eng Lead) Confirmed. Feature flag is already in staging. 1
Deepak (Backend) Dashboard by Friday. Will need read access to the prod metrics DB — Arjun, can you raise the ticket?
Arjun (Eng Lead) Done. You should have access by EOD.
Priya (QA) I was not in the meeting but these notes tell me exactly what I need to test. Thanks for the write-up. 2
Riya (PM) That is the point. If you can follow along from the notes, the meeting worked.

Notice what happened. Priya was not in the meeting but knows exactly what to do. That is the test. If someone who missed the meeting can read the notes and be fully caught up, you ran it well. If they need to ask three follow-up questions, you did not.

The meetings a PM actually needs

Not all meetings are created equal. Here are the ones that earn their spot on your calendar:

Sprint planning and backlog grooming. These are working sessions, not status updates. The PM brings the priorities. Engineering brings the estimates and trade-offs. You leave with a committed sprint. If your sprint planning is a ceremony where everyone nods and nothing gets debated, it is broken.

Weekly 1:1 with your engineering lead. This is the most important meeting on your calendar. It is where you align on priorities, surface blockers, discuss upcoming asks, and build the trust that makes everything else work. Never cancel this one.

Design reviews. You are there to represent the user and the business constraints. Not to critique typography. Give designers the problem and the constraints. Let them solve it. When you review, judge it against the user outcome, not your personal taste.

Stakeholder check-ins. These are the meetings where sales, marketing, and customer success tell you what they are hearing. Keep them short. Come with specific questions, not an open-ended “any updates?” Come with: “Are customers still complaining about bulk upload? Has the new export feature changed the conversation?”

Retrospectives. Not optional. Not a feel-good exercise. The retro is where the team gets honest about what is not working. If people are not saying uncomfortable things, the retro is performative. Create safety by going first: share something you personally could have done better.

Everything else, audit ruthlessly. Look at your calendar right now. How many recurring meetings do you attend where you sit silently, contribute nothing, and learn nothing you could not have read in a Slack message? Cancel them. If anyone objects, ask them what specific contribution you make in that meeting. If they cannot answer, you have your proof.

When async beats sync

Async communication is not a lesser form of meeting. For many purposes, it is better.

Status updates. Never synchronous. Post in Slack or your project tool. A standup that requires 8 people to join a call at 9:30am every day so each person can say “I worked on X yesterday and will work on Y today” is a waste of everyone’s time. At AngelList, the product team posts written updates before the meeting. Participants read what is relevant to them. The meeting, when it happens, is only for discussion of blockers — and some weeks it does not happen at all.

Feedback on documents. Send the doc. Give people a deadline for async comments. Many people think better in writing than they do in real-time conversation. A design review where everyone reads the spec for the first time in the meeting wastes 15 minutes of shared attention on something that should have been individual prep.

Decisions with clear options. If you have three options, the trade-offs are documented, and you need a thumbs-up from two people, that is a Slack thread. “Option A, B, or C. Trade-offs in the linked doc. I recommend B. Please vote by Thursday.” Done. No meeting needed.

Cross-timezone collaboration. If half your team is in Bangalore and half is in San Francisco, every synchronous meeting costs someone their morning or their evening. Default to async. Write thorough notes. Record Looms for anything visual. Reserve synchronous time for the conversations that truly need it.

// exercise: · 20 min
The calendar audit

Open your calendar for last week. For every meeting you attended:

  1. Write down the stated purpose of the meeting.
  2. Write down the actual outcome — the decision made, the action items assigned, or the alignment reached.
  3. For each meeting where the outcome is blank or vague (“good discussion”), ask: could this have been async?
  4. Count how many hours you spent in meetings that should not have existed.

Most PMs discover they can reclaim 5-8 hours per week by converting status meetings to Slack posts, declining meetings where they add no value, and shortening meetings that run long because nobody facilitates.

Now pick two recurring meetings. Propose an async alternative to the organizer this week. Track whether the work quality changes.

Running meetings in the Indian context

Three patterns I see in Indian tech companies that PMs should actively push back on:

The hierarchy problem. In many Indian organizations, the most senior person in the room does most of the talking. Junior team members stay quiet even when they disagree or have critical information. As the PM, you are the facilitator. It is your job to create space: “Sneha, you have been closest to the user data on this. What are you seeing?” Do not wait for people to volunteer. Call on them by name. The best insights often come from the person who is not speaking.

The meeting-as-proof-of-work problem. In some Indian tech cultures, being in meetings signals importance. A PM with a packed calendar looks busy and therefore productive. This is backwards. A PM with a packed calendar has no time to think, write, or do the deep work that produces good product decisions. Protect your calendar. Block focus time. Treat it as non-negotiable. A Google PM we hosted said she ruthlessly prioritizes: “I don’t go to all the meetings I am invited to. I block time on my calendar and I am pretty stringent about it.”

The recurring meeting that nobody kills. Someone set up a weekly alignment two years ago. The original purpose is forgotten. People attend out of habit. The meeting produces nothing. But nobody cancels it because cancelling feels confrontational. Cancel it. Send a message: “I am replacing this meeting with a weekly async update in Slack. If we need to discuss anything, I will schedule a focused 20-minute session.” You will be surprised how few people object.

Test yourself

// interactive:
The meeting that won't die

You are a PM at a B2B SaaS company in Hyderabad. Your team has a weekly 'product sync' every Wednesday at 3pm. It was created eight months ago when the team was launching a major feature. The feature launched four months ago. The meeting still happens. Attendance: you, two engineers, a designer, a QA lead, your engineering manager, and sometimes a sales rep who joins for 5 minutes then leaves. The meeting regularly runs 50 minutes. You have noticed that the first 20 minutes is a status update, the next 15 is a tangent about something unrelated, and the last 15 minutes is the only part where a real discussion happens. Your engineering manager, Suresh, originally created the meeting.

It is Monday. You are looking at your Wednesday calendar and dreading the product sync again. What do you do?

// learn the judgment

You are running a weekly sprint review at Razorpay with 12 people in the room. Fifteen minutes in, the head of engineering and a senior designer are in a heated debate about whether a particular interaction is technically feasible. The meeting has 25 minutes left and 4 agenda items unaddressed.

The call: Do you let the debate run, or cut it?

// practice for score

You are running a weekly sprint review at Razorpay with 12 people in the room. Fifteen minutes in, the head of engineering and a senior designer are in a heated debate about whether a particular interaction is technically feasible. The meeting has 25 minutes left and 4 agenda items unaddressed.

The call: Do you let the debate run, or cut it?

0 chars (min 80)

Where to go next

  • Sharpen how you communicate in writing: Writing for Impact — the async alternative to most meetings starts with writing well
  • Present effectively when you do meet leadership: Presenting to Leadership — the high-stakes version of meeting facilitation
  • Understand the execution rhythm: Sprint Planning — the most important recurring meeting a PM runs
  • Work better with your engineering counterpart: Working with Engineering — the relationship that makes or breaks your meetings
running effective meetings 0%
10 min left