I used to think the job of a PM was to figure out what to build. That's what the job descriptions say. That's what the interview questions test. The whole framing is about product sense and strategy and user insight. Those things matter. They're maybe 20% of the job. The other 80% is making sure information flows correctly between people who need it.
Not communication in the soft-skills sense. Communication in the operational sense: the right information reaching the right people at the right time, in a form they can actually use to make decisions. When this works, it's invisible. When it breaks, everything slows down and you spend your days in meetings that shouldn't need to exist.
The spec that generates ten questions
The clearest signal that your written communication is failing is when a spec generates a lot of questions in the planning meeting. Not clarifying questions about edge cases - questions about what the feature is supposed to do. That means the spec didn't communicate the intent clearly enough for engineers to start building.
I've written specs that generated ten questions in planning. I've also written specs that generated zero questions and still produced the wrong thing, because the engineers made reasonable assumptions that I hadn't thought to address. Both are failures of the same kind: I had information in my head that didn't make it into the document.
The discipline I've developed is to write specs from the perspective of someone who has none of my context. What would they misunderstand? What would they assume that I haven't stated? What are the failure cases I haven't addressed? This sounds obvious but it's genuinely hard to do, because the context you have feels so obvious that it doesn't occur to you to write it down.
A concrete example: I once wrote a spec for an order status sync feature that said "update order status when it changes." The engineer built a polling job that checked for status changes every five minutes. I meant a webhook handler that updated status within seconds of the logistics provider firing an event. Both implementations "update order status when it changes." The difference is 5 minutes versus 5 seconds, which is the difference between a customer seeing their order shipped before they call support and after. I hadn't written down the latency requirement because it seemed obvious. It wasn't obvious from the spec.
The information broker problem
The PM sits at the intersection of engineering, design, business, and users. Information flows through you, which means information bottlenecks at you. When you're slow to communicate something, or you communicate it to the wrong people, or you communicate it in a form that doesn't translate across the context gap, the downstream effects compound.
The most common failure I see is information that exists in one part of the organization not reaching another part that needs it. Engineering knows that a particular API has a rate limit that will become a problem at 10x current traffic. Business is planning a marketing campaign that will drive 10x traffic. These two facts need to be in the same room before the campaign launches, not after. The PM is the person who should know both facts and should be the one to put them together.
At Uzum, the scale makes this more acute. We have multiple engineering teams, a large ops organization, business stakeholders, and a support team that's handling thousands of tickets a day. A change to how order statuses are displayed in the app affects all of them differently. Engineering needs to know the data model requirements. Ops needs to know what the new statuses mean for their workflows. Support needs to know what to tell customers who ask about the new states. If I communicate the change to engineering and forget about ops and support, the feature ships and the support team is fielding questions they can't answer.
When a feature ships and the support team can't answer customer questions about it, that's a PM communication failure, not a support failure. Every stakeholder group needs the information in a form they can actually use.
Async first, meetings second
Most PM communication should happen asynchronously. A well-written update in Slack or a decision document in Notion reaches everyone at once, creates a record, and doesn't require coordinating schedules. A meeting to share information that could have been a document is a tax on everyone's time.
The meetings that are worth having are the ones where you need real-time back-and-forth to resolve something - a disagreement about priorities, a technical tradeoff where you need to hear the engineering perspective before you can make a decision, a stakeholder alignment where you need to read the room. Those meetings are valuable. The meeting where you're explaining the situation for the first time to people who should have known it already is a failure of async communication.
I've gotten better at this by paying attention to what happens after I send something. If a Slack message generates a thread of clarifying questions, the message wasn't clear enough. If a decision document comes back with comments that suggest people misunderstood the decision, the document didn't communicate the reasoning well enough. The feedback loop is immediate if you're paying attention to it.
The thing nobody tells you
The unglamorous truth about PM communication is that most of it is maintenance work. Keeping people informed of things they already know are happening but need updates on. Repeating context that you've shared before because people forget or weren't paying attention the first time. Writing the same thing in three different formats because different stakeholders consume information differently.
This is not the job description. It's not what you talk about in interviews. But it's what separates PMs who make their teams faster from PMs who slow them down. The team that's well-informed makes better decisions faster. The team that's constantly waiting for clarity, or discovering surprises, or building things that turn out to be wrong - that team is slower, and the PM is usually the reason why.