How Ineffective Meetings Drive Product Managers Crazy (and What to Do About It)

1. When "communication" turns into "squabbling", who still wants to talk?

Recent experiences show that dealing with endless, draining meetings is exhausting. The problem isn’t communication itself—I've organized product communities and negotiated with investors—but the forced participation in pointless discussions that waste time.

In large companies, decision chains become bloated, involving many people and endless approvals, while the actual product impact is ignored. Meetings often serve process compliance or personal control rather than product success.

2. Plain‑language analysis: Why does corporate communication always go off‑track?

Four main reasons:

Liability > Responsibility : In startups people focus on getting things done; in big firms many aim to avoid blame. Adding more attendees and minutes creates a paper trail to deflect responsibility later.

Performance > Execution : Some attend meetings to showcase presence, not to solve problems. Speaking up is visible; quietly delivering results is not.

Process > Outcome : Companies treat the process as the goal—multiple rounds of approval, mandatory reports—regardless of whether the process improves the product or user experience.

Power > Truth : Final decisions often come from the highest‑ranking person, not the most knowledgeable. Teams start guessing what leadership wants instead of seeking the real answer.

3. From "speak freely" to "hold back": A product manager’s transformation

When I first started, I prepared thoroughly for every review and voiced concerns directly. Over time I faced repeated push‑backs:

"This requirement doesn’t match user habits" → "It’s a directive from leadership".

"The schedule is too tight and will hurt quality" → "Business can’t wait".

"We should start with data analysis" → "No time, just ship it".

Eventually I learned to be "smart":

Before a meeting, find out who is hosting, the leader’s attitude, and participants’ positions.

During the meeting, read the room—if the boss frowns, shift the topic; if a colleague signals, stop speaking.

Start remarks with a disclaimer: "This may be immature, just my shallow view…".

Leave conclusions open‑ended: "This solution works, but only if we have time…".

This shift turned me from a "product‑building" person into a "meeting‑master".

4. My "stay‑clear" guide: Doing the right thing in a squabbling environment

Changing the whole environment is hard, but you can avoid being assimilated:

Distinguish "mandatory performance" from "worthwhile battle" Classify meetings:

A‑type (core battles) : Directly affect product direction, user satisfaction, or key metrics. Give them 100% effort.

B‑type (necessary processes) : Routine reports, syncs, reviews. Complete the required actions.

C‑type (pure performance) : No clear goal or decision power, just “let everyone know”. Attend minimally or skip.

Build a "offline consensus, online formality" mechanism Never push critical decisions in a large meeting. Follow three steps:

Privately discuss with key stakeholders to reach basic agreement.

Hold a small‑group discussion to resolve major disagreements.

Use the big meeting only to tick the procedural box and quickly approve.

Use user data as your sword When arguments become "I think" vs "you think", bring concrete evidence:

"In the past week, 23 users reported the same issue."

"A/B test shows solution B improves conversion by 15%."

"Customer‑service complaints for this problem rose 300%."

Reserve "creator time" for yourself Schedule uninterrupted deep‑work:

10 am–12 pm: No messages, no calls, focus on core tasks.

Evenings: Write code, write articles, work on personal projects.

Remember: Who are you working for? Your salary comes from the company, but your career is yours. Reduce meeting time by 50% and double direct user interaction.

5. Final note: Protect your "product‑heart"

After a long meeting about responsibility division, I wrote: "Users won’t love us because we clarified responsibilities; they’ll love us because the product works." I decided to cut meeting time in half and double user‑communication activities:

Talk to one real user daily.

Analyze a complete user journey weekly.

Do an in‑depth competitor review monthly.

Result: Better understanding of users makes proposals more persuasive, which in turn reduces the number of meetings needed. Instead of guessing leadership’s preferences in a conference room, go straight to the users for answers. Our primary duty is to build great products, not to run perfect meetings.