writing for impact
Writing is about doing a lot of research, going and meeting a lot of team members. Sometimes I have written something and I want to gain alignment with someone even before I put it out there. 30 to 40 percent of your time as a PM — it keeps changing — but 30 to 40 percent of your time, you are writing.
Most PMs think writing is a secondary skill. Something you do after the real work — the research, the analysis, the strategy sessions. You sit down, type up the results, and hit send.
This is backwards. Writing is the work. The document is not a report of what you decided. The document is how the decision gets made. If you write a sloppy email, the decision stalls. If you write a vague Slack message, you get ten follow-up questions. If you write a PRD that nobody reads past page two, the engineering team builds what they assumed you meant.
Across eight years of PM training, the single highest-impact skill improvement for most of them was not prioritization frameworks or user research methods. It was learning to write a clear sentence.
Why PM writing is different
You are not writing literature. You are not writing marketing copy. You are writing to get things done — to move a decision, unblock a team, align stakeholders, or document a commitment. Every word that does not serve one of those purposes is a word that dilutes your message.
PM writing has three constraints that most writing does not:
Your reader does not want to read it. Your VP has 47 unread emails. Your engineering lead has three PRDs open in tabs they will never look at again. Your Slack message competes with 200 others that day. You are not earning attention with a clever opening line. You are earning it by being useful in the first sentence.
Multiple audiences read the same thing. A PRD is read by engineers (who want technical specifics), designers (who want user flows), QA (who want edge cases), and leadership (who want business impact). A weekly status update goes to your skip-level, your peers, and your direct reports. You cannot write for one audience without confusing another — unless you structure deliberately.
Your writing becomes a contract. When you write “we will ship bulk upload by March 15,” that is not a plan. It is a promise. When you write “the scope includes X and Y but not Z,” that is not a description. It is a boundary. Sloppy writing creates sloppy commitments that blow up six weeks later when someone says “but you said…”
The one rule that fixes 80% of bad PM writing
Lead with the point.
Not the context. Not the background. Not the journey of how you got here. The point.
Monday morning. A PM sends a project update email to leadership and the cross-functional team.
Version 1 — the email that gets skimmed and forgotten:
PM (email): “Hi team, as you know we have been working on the checkout redesign for the past three sprints. We conducted 23 user interviews, ran two A/B tests, and worked through three design iterations with the UX team. The results have been encouraging and I wanted to share an update on where things stand. Based on our analysis of the funnel data and qualitative feedback, we have identified several opportunities for improvement...”
The reader's brain checked out at 'as you know.' Now version 2 — the email that drives action:
PM (email): “Checkout redesign ships Wednesday. One open item needs a decision by tomorrow: do we include the guest checkout option in v1 or defer to v2? My recommendation: include it. Guest checkout accounts for 34% of first-time purchases. Deferring it costs us roughly 8L/week in drop-off revenue. Details and data below.”
Same project. Same information. Version 2 gets a reply in 20 minutes. Version 1 gets a 'thanks for the update' three days later.
The first email describes work. The second email drives a decision.
The reason most PMs write version 1 is not laziness. It is insecurity. They want to show their work before stating the conclusion because they are worried the conclusion will be challenged. So they build a defensive wall of context around it.
The problem is that nobody climbs the wall. They glance at the first two sentences, decide there is no action needed, and move on. Your brilliant recommendation is on paragraph four and nobody gets there.
Lead with the point. Defend it afterwards. If the reader disagrees, they will scroll down for your reasoning. If they agree, you just saved everyone fifteen minutes.
Writing for the three channels that matter
Documents (PRDs, one-pagers, strategy docs)
A document is a thinking tool first and a communication tool second. The act of writing a clear document forces you to resolve ambiguity in your own thinking. If you cannot explain the scope in writing, you do not understand the scope.
Structure every document the same way:
-
What are we doing and why. Two sentences. Not a paragraph. If you need more than two sentences to explain what you are building and why, you have not finished thinking.
-
What does success look like. The metrics, the outcomes, the user behavior change you expect. This is the contract your team will hold you to.
-
What are we not doing. This section prevents 80% of scope creep. List the adjacent things someone might assume are included. Make it explicit that they are not.
-
The details. User stories, technical requirements, edge cases, timelines. This is where the document earns its length. Everything above it should fit on one screen.
At Amazon, PMs spend 30 to 40 percent of their time writing. They write PR/FAQs — a one-page press release from the future plus five pages of FAQs — before a single line of code is written. The press release forces you to articulate the customer benefit in plain language. The FAQs force you to answer the hard questions before the room asks them. You do not need to adopt Amazon’s format. But you should steal the discipline: write before you build, and write as if the reader is skeptical.
The changelog move is small but high-impact. Every document revision should have a three-line summary of what changed at the top. Your teammates should not have to play spot-the-difference on a 14-page PRD. Respect their time and they will actually read your documents.
Emails
An email has exactly one job: to get the reader to do something or know something. If you are not clear on which one it is, do not send the email.
The anatomy of a PM email that works:
Subject line = the ask. Not “Q3 Checkout Update” but “Decision needed: guest checkout in v1 or v2?” If your email requires action, the subject line should say so. If it is purely informational, the subject line should say that too: “FYI: checkout ships Wednesday, no action needed.”
First sentence = the point. “I need your sign-off on the v1 scope by Thursday EOD.” Not “As we discussed in last week’s meeting, the checkout project has been progressing well and I wanted to follow up on a few outstanding items.”
Body = only what the reader needs to decide. Two to three supporting points. Not a narrative. Not a timeline of events. Not every data point you have. The two or three pieces of information that make the decision obvious.
Last sentence = the specific ask with a deadline. “Please reply with your approval or concerns by Thursday 5pm IST so we can lock the sprint on Friday.” Not “let me know your thoughts” which is an invitation to procrastinate.
In India specifically, I see PMs write emails that are too deferential to be useful. “It would be great if we could perhaps discuss this at your earliest convenience” means nothing. “I need 15 minutes with you before Thursday to finalize the scope” means something. Politeness is not verbosity. You can be direct and respectful at the same time.
Slack messages
Slack is where good communication goes to die. The medium rewards speed over clarity. You fire off a quick message, someone misreads it, you clarify, they clarify, and twenty messages later you have spent more time than a five-minute conversation would have taken.
Rules for Slack that I enforce with every PM I coach:
One message, not five. Do not send “Hey” followed by “Quick question” followed by “About the notifications feature” followed by the actual question. Write the whole thing in one message. Your teammate should not have to watch you type for 90 seconds.
Thread everything. If a conversation is longer than two messages, it belongs in a thread. The main channel is a timeline. Threads are conversations. When you reply in-channel to a message from three hours ago, you break the timeline for everyone else.
Use structure, not prose. Slack is not email. Use bullets, bold the key terms, and break it into scannable chunks. A three-line Slack message with bold headers communicates faster than a five-line paragraph.
State the format of the response you need. “Approval/rejection by EOD” or “Pick A or B” or “Flag if this conflicts with anything on your plate.” The more specific the response format, the faster you get a reply.
The editing discipline
The Amazon PMs I have spoken to have a saying: the writing is in the editing. You do not write a good document on the first pass. You write a rough document, then you edit it three or four times until it is sharp.
Most PMs skip editing entirely. They write, they proofread for typos, and they send. Proofreading is not editing. Editing is cutting. It is taking a paragraph and asking: does every sentence earn its place? Can this section be half the length and say the same thing?
Pull up the last document, email, or Slack message you wrote that was longer than five sentences.
- Copy it into a new document.
- Cut it to half the word count. Do not summarize — cut. Remove sentences that repeat what another sentence already says. Remove qualifiers (“I think,” “perhaps,” “it seems like”). Remove throat-clearing (“As discussed,” “Just wanted to follow up,” “I hope this email finds you well”).
- Read both versions. Which one is clearer? In almost every case, the shorter version communicates more, not less.
- Now look at the sentences you cut. How many of them were written for you (to show your work, to hedge, to sound thorough) versus for the reader (to help them decide or act)?
The gap between those two purposes is where most PM writing goes wrong.
Three specific editing moves that make PM writing sharper:
Kill the passive voice. “It was decided that the feature would be deprioritized” — by whom? “We deprioritized the feature because retention data did not support it.” Active voice assigns ownership. In product teams, ambiguous ownership kills velocity.
Replace adjectives with numbers. “Significant improvement in conversion” means nothing. “Conversion improved from 2.1% to 3.4%” means everything. If you do not have the number, say so — “conversion improved but we do not have exact figures yet” is more honest than hiding behind “significant.”
Delete every sentence that starts with “I think.” Either you believe it and can defend it — in which case state it as a position — or you are hedging because you are not sure — in which case do more work before writing. “I think we should prioritize retention” is weak. “We should prioritize retention. Here is why.” is strong.
Writing across cultures in Indian tech
This deserves a direct conversation because I see the same patterns across almost every Indian tech company where I have coached PMs.
The deference trap. Many PMs write to seniors as if they are requesting permission to have an opinion. “I was just thinking that maybe we could consider looking at the retention numbers?” This is not politeness. This is abdication. Your VP hired you to have a point of view. “Retention dropped 12% this month. I want to shift the next sprint from growth to retention. Here is the data.” That is what they need from you.
The CC culture. In many Indian organizations, adding six people to CC is a defensive move — if something goes wrong, you can prove everyone was informed. The problem: when everyone is on the email, nobody owns the response. If your email has more than three people in the To field, you probably do not have a clear ask. Who specifically needs to do what?
Hindi-English code-switching in Slack. Many Indian product teams naturally switch between Hindi and English in Slack. This is fine for casual conversation. For anything that is a decision or a commitment, write in whichever language the official documentation uses. You do not want a scope commitment buried in a Hinglish Slack thread that half the team cannot search for later.
Test yourself
You are a PM at an e-commerce company in Bangalore. Your team was supposed to launch a new search feature on Monday. On Friday evening, the QA lead finds a critical bug — search results are returning incorrect prices for 15% of products. The fix will take 3-4 days. You need to communicate the delay to: your VP (who announced the Monday launch to the board), the marketing team (who has a campaign scheduled), and your engineering team (who has been working weekends to hit the deadline). You open your laptop to write the emails.
You start with the email to your VP. She is in a dinner meeting and will read this on her phone. What do you write?
your path
You need to write a one-pager recommending that Flipkart discontinue its Flipkart Health+ product. Three stakeholders must approve it: the CFO (data-focused), the Chief People Officer (worried about the team), and the CEO (strategic framing). All three will read the same document.
The call: Do you write one document that tries to address all three, or three separate memos?
You need to write a one-pager recommending that Flipkart discontinue its Flipkart Health+ product. Three stakeholders must approve it: the CFO (data-focused), the Chief People Officer (worried about the team), and the CEO (strategic framing). All three will read the same document.
The call: Do you write one document that tries to address all three, or three separate memos?
Where to go next
- Apply the structure to product specs: Writing PRDs — the document where your writing quality has the highest stakes
- Communicate upward with confidence: Presenting to Leadership — when your writing becomes a presentation
- Understand who you are writing for: Working with Engineering — the audience that reads your documents most critically
- Build the analytical backbone: Metrics and KPIs — you cannot write with impact if you do not have data to anchor your arguments