Writing is the most important and most undertrained PM skill. A PM who writes clearly can align an engineering team with a one-page spec, persuade a VP with a two-paragraph email, and set product direction with a three-page strategy doc. PMs who write poorly create confusion, misalignment, and rework regardless of how good their ideas are.
Amazon's six-pager memo format is not a quirky cultural artifact. It is a product decision architecture disguised as a writing exercise. Jeff Bezos banned PowerPoint from senior meetings because slides hide sloppy thinking behind bullet points and animations. A six-page narrative memo forces the author to think through their logic completely, because you cannot hide behind a bullet point in a paragraph.
This insight applies to every PM, not just the ones at Amazon. Writing is how PMs think, decide, influence, and align. A PM who writes well can persuade a VP in a two-paragraph email, align an engineering team with a one-page spec, and set product direction with a three-page strategy doc. A PM who writes poorly creates confusion, misalignment, and rework. No matter how good their ideas are.
And most PMs write poorly. Not because they lack intelligence or domain expertise, but because nobody taught them that writing is a core PM skill. MBA programs teach frameworks and case studies. PM bootcamps teach user stories and OKRs. Almost nobody teaches PMs how to write a clear, persuasive paragraph.
The gap is visible everywhere. In PRDs that take 45 minutes to read when 10 would suffice. In strategy docs that use 5 pages to make a point that needs 2. In Slack messages so long and unfocused that nobody reads past the third line. Every minute your reader spends deciphering your writing is a minute they are not spending on the work you need them to do.
Why Does Writing Matter More Than Meetings?
A meeting reaches the people in the room, at the time it happens. A well-written document reaches anyone in the organization, at any time they need it.
Consider the math: you spend an hour writing a strategy doc that 15 people read in 10 minutes each. That is 1 hour of your time for 2.5 hours of organizational alignment. A meeting to cover the same content takes 1 hour of 15 people's time. That is 15 hours consumed. The document is also searchable, shareable, and referencable. The meeting exists only in the imperfect memories of the attendees.
Product managers who default to meetings for alignment are spending 15x more organizational time than they need to.
Beyond efficiency, writing forces clarity. You can say something vague in a meeting and nobody stops you. You cannot write something vague without seeing it on screen and (hopefully) recognizing that it is vague. The act of putting thoughts into sentences reveals gaps in logic, unresolved questions, and unstated assumptions.
The Four Writing Types That Matter
1. The Product Requirements Document
The PRD is the PM's primary written artifact. It is also the most abused. Many PRDs are either too long (20 pages nobody reads) or too short (a user story with no context).
What a good PRD contains:
- Problem statement (2-3 paragraphs). Who has this problem? How do we know? What happens if we do not solve it? This should cite specific evidence. Customer interview quotes, usage data, support ticket volume.
- Success criteria (3-5 bullet points). How will we know this worked? Specific metrics with targets and timeframes. "Activation rate increases from 28% to 35% within 60 days of launch."
- Solution description (1-2 pages). What are we building? How does it work from the user's perspective? Include wireframes or mockups if they exist, but the text should stand alone.
- What we are not building. Explicitly list the adjacent features or enhancements you considered and declined. This prevents scope creep and shows that you made deliberate trade-offs.
- Open questions. What do you not know yet? What needs to be resolved during implementation?
Writing tip for PRDs: Start with the problem, not the solution. If your PRD jumps straight to "we are building X," you have skipped the most important part. An engineer who understands the problem will build a better solution than one who only understands the spec.
2. The Stakeholder Email
PMs send dozens of emails a week to people who have more authority and less time than they do. Most of these emails are too long, buried in context, or unclear about what they are asking for.
The structure that works:
- Subject line: Action required + topic. "Decision needed: Q2 priority trade-off" not "Quick question" or "Follow-up."
- First sentence: The ask. "I need your input on whether we should prioritize Feature A or Feature B for Q2." Do not bury the ask in paragraph three.
- Supporting context: 2-3 sentences maximum. The essential background. Not the full history. Just enough to make the ask understandable.
- Options with your recommendation. "Option A does X, Option B does Y. I recommend A because [reason]."
- Deadline. "I need a decision by Thursday to keep the engineering timeline on track."
Total length: 100-150 words. If it is longer, it should be a document, not an email.
The executive email is where most PMs lose their audience. A VP with 200 unread emails will skip anything that requires scrolling. Front-load the ask, keep it brief, and make the action clear. You can always attach a longer doc for context, but the email itself should be a summary, not a chapter. This skill is central to managing up as a PM. Your writing is often your primary tool for influencing leadership decisions.
3. The Strategy Document
A strategy doc defines where you are going and why. It is the most impactful writing a PM does because it shapes months of work for multiple teams.
What a good strategy doc contains:
- Current state (1 page). Where are we today? Key metrics, competitive position, user feedback themes. Facts, not opinions.
- The insight (1-2 paragraphs). What have we learned that changes how we should think about the problem? This is the core of the strategy. It should be specific and non-obvious.
- The bet (1 page). What are we going to do about it? What are we betting on? What assumptions underlie the bet? What would prove us wrong?
- What we will not do (half page). The trade-offs. What are we explicitly choosing not to pursue?
- How we will know it is working (half page). Leading indicators we will watch in the first 30 days. Lagging indicators we expect to see in 90 days.
Writing tip for strategy: The insight section is everything. A product strategy doc without a clear insight is just a plan. The insight is the answer to "what do we believe that others do not?" or "what has changed that makes a different approach necessary?" If you cannot articulate the insight in two sentences, you do not have a strategy yet.
4. Slack Messages
Slack is where most PM communication happens, and it is where most PM communication breaks down. The format encourages rapid, casual messaging that works for quick questions but fails for anything that requires shared understanding.
Rules for PM Slack communication:
- Use threads. Never post a multi-paragraph message in a channel without threading the details. The top-level message should be a one-sentence summary.
- Front-load the point. "We are pausing the billing migration until the data integrity issue is resolved" not "So I was looking at the billing migration work and noticed some issues with the data pipeline and talked to the engineering team about it and..."
- Distinguish updates from asks. Start updates with "FYI:" and asks with "Input needed:" or "Decision needed:". People scan Slack quickly. Signal what kind of response you need.
- Do not negotiate in Slack. If a Slack thread requires more than 5 messages to resolve, move it to a 10-minute call or a short document. Slack is terrible for nuanced discussion because it lacks the bandwidth of voice and the precision of long-form writing.
Three Techniques for Better PM Writing
Technique 1: Write, Then Cut in Half
First drafts are always too long. Write everything you want to say, then cut 50% of the words. You will be surprised at how much is filler, repetition, or throat-clearing.
A practical test: remove the first paragraph of any document you write. If the document still makes sense, the first paragraph was throat-clearing. Most documents start with context the reader already has. Start with the new information.
Technique 2: One Idea Per Paragraph
Each paragraph should make one point. If you find yourself writing paragraphs with multiple ideas connected by "also" and "in addition," split them. Short paragraphs are easier to scan, easier to critique, and easier to reference.
Apply this to specs, emails, and strategy docs alike. The paragraph is the atomic unit of written communication. Keep it pure.
Technique 3: Use Concrete Language
Vague writing creates vague understanding. Replace abstract words with specific ones.
- Vague: "Improve the user experience of the settings page."
- Concrete: "Reduce the time to change notification preferences from 4 clicks to 1 click."
- Vague: "Work with marketing on the launch."
- Concrete: "Send marketing the feature brief by Tuesday so they can draft the announcement email by Friday."
Every time you write a sentence, ask: "Could someone read this and do something different than what I intend?" If yes, make it more specific.
Common PM Writing Mistakes
Here are the patterns I see most often in PM documents:
The throat-clearing introduction. "As we think about our product direction for Q2, it is important to consider the various factors that influence our decision-making, including customer feedback, competitive dynamics, and internal resource constraints." That sentence says nothing. Delete it. Start with the point.
The passive voice hedge. "It was decided that the feature would be deprioritized." Who decided? Why? Passive voice hides accountability. "I deprioritized the feature because usage data showed 3% adoption after 90 days" is clearer, more honest, and more useful. Active voice forces ownership, which is uncomfortable but necessary.
The buzzword paragraph. "We need to build a scalable, best-in-class solution that enables our customers to optimize their workflow and drive meaningful outcomes." What does this mean? Nothing specific. Replace every buzzword with a concrete description of what the user can do.
The wall of text. A 400-word paragraph in a PRD is not a paragraph. It is a chapter. Nobody reads it. Break it into 3-4 focused paragraphs with headers. Use bullet points for lists. Use bold for key phrases. Format is part of writing.
The buried decision. "After considering options A, B, and C, and weighing the trade-offs, and talking to customers, and analyzing the data, I recommend Option B." The reader has to parse 80 words of preamble before reaching the point. Lead with the recommendation: "I recommend Option B. Here is why."
How Can PMs Improve Their Writing?
Read good PM writing. Lenny Rachitsky's newsletter, Shreyas Doshi's Twitter threads, and Julie Zhuo's essays are examples of PMs who write with clarity and specificity. Notice how they structure arguments, use evidence, and keep paragraphs short.
Write every day. Not blog posts. Working documents. PRDs, strategy memos, stakeholder updates. The goal is volume and iteration. Your 100th PRD will be noticeably better than your 10th.
Ask for feedback on your writing, not just your ideas. When you share a doc for review, ask: "Was anything unclear? Did any section feel too long? Where did you have to re-read?" This feedback is more actionable than "looks good." The stakeholder management guide covers how to structure these feedback conversations with different audiences.
Edit other people's writing. The fastest way to see common mistakes is to read someone else's first draft. You will spot the vague language, the buried asks, and the missing context that you might not see in your own work.
Use a writing checklist. Before sending any document, run through these questions: Does the first sentence state the main point? Is every paragraph about one idea? Could someone act on this without asking me a follow-up question? Is there anything I can cut without losing meaning?
The Compound Effect
Here is the thing about PM writing: it compounds. Every clear PRD reduces questions and rework during implementation. Every concise email saves executive attention for your real asks. Every precise Slack message prevents the 30-minute clarification thread.
Over a year, a PM who writes well ships faster, aligns teams more efficiently, and builds more trust with leadership than one who writes poorly. The ideas might be identical. The writing is the difference between those ideas being understood and acted upon, or being ignored and forgotten.
There is a reason Amazon, Stripe, and GitLab all have writing-centric cultures. These are companies known for clear thinking and decisive execution. That is not a coincidence. Writing forces the thinking. The thinking drives the execution. The execution produces the results.
Every hour you invest in improving your writing pays dividends for years. A PM who writes clearly at 30 will write even more clearly at 40 because the skill compounds with practice. The PM who never invests in writing will spend their career being misunderstood, no matter how good their ideas are.
Writing is not the work that comes before the real work. For a PM, writing is the real work.