How to immediately get better at writing product docs
Stop making common mistakes in your business-related writing.
Too many documents written by business people are weak. They ramble, bury key info in long explanations, don't tell a story, use flowery language (hello, ChatGPT), etc. We are all busy, no one wants to read your shit. Here is how to immediately get better at writing business documents:
1. Explain why the hell you’re writing this doc
Before you write a single word, answer this question: What decision or action am I trying to enable with this document?
Not “I’m documenting our findings.” Not “I’m sharing an update.” What specific outcome do you want? Do you need approval to kill a feature? Do you need the team to align on a strategy? Do you need stakeholders to understand why something failed so they stop asking about it?
I’ve lost count of how many times I’ve read a document and didn’t understand what the author intended. Do they need feedback? Should I approve it? Or what?
Bad: “Document our Q3 learnings”
Good: “Get VP approval to invest €35k per year in an OCR solution so that we can address 20% of NPS detractors”.
Bad: “Share user research findings”
Good: “Convince the team to pivot our onboarding approach because 68% of users are getting stuck at step 3”.
Once you know your purpose, write it at the very top of your doc. Literally write: “Purpose: Get approval to...” or “Purpose: Align the team on...”
2. Start with the end (the conclusion)
This is not a murder mystery novel. Don’t make people read to the end to find out what you think.
Your doc should start with your recommendation, decision, or key insight. Not on page 7. Not after three sections of background. At. The. Top.
Why? Because your audience is busy, and they need to know immediately if they should keep reading. A CEO scanning 20 docs before a meeting needs to know: “Is this a problem I need to solve now, or can I delegate/ignore it?” Your product lead reviewing your roadmap proposal needs to know: “What are you asking me to approve?”
When you front-load the conclusion, you also force yourself to clarify your thinking. If you can’t write a clear conclusion, you probably don’t have one yet. Which means you shouldn’t be writing the doc—you should be doing more discovery or analysis.
Example structure:
“We should kill feature X and invest those resources in feature Y instead. Feature X has 3% adoption after 6 months and costs us $50K/month in maintenance. Feature Y addresses our #1 customer pain point in support volume, and a recent survey with 100 customers showed that 67% of respondents consider churning because we lack it.”
Now the reader knows exactly what you want and why. They can decide immediately if they agree or need to read more details.
3. Real executive summaries actually are summaries (of the whole doc)
If I can find key info in your doc that wasn’t summarized in the executive summary, you are doing summaries wrong.
That doesn't mean all the details should be in the summary.
A real executive summary is a miniature version of your entire document. Every major section should appear in the summary. Every key insight should be there. Every important number should be there. Someone should be able to read just the executive summary and walk away with 80% of the value.
Here’s my trick: I write the exec summary at the very end, after I've finished the document and even had some quick feedback from close associates. Then I open the doc side-by-side in two windows. I write each section of my doc in the executive summary. One or two sentences per section. This forces me to clarify what each section actually contributes and if I have a story.
If you can’t summarize a section, that section probably doesn’t need to exist. Maybe it's an appendix? Or maybe it's part of a larger section.
Bad:
“This document analyzes our checkout flow performance and provides recommendations for improvement.”Good:
“Our checkout flow has a 42% drop-off rate at the payment step, costing us $200K in lost revenue monthly. User testing revealed that 89% of users don’t understand that we accept PayPal. We recommend adding PayPal as a visible option, which similar companies saw increase conversion by 15-20%. Implementation would take 2 weeks.”
4. Tell a story: Problem → Insights → Proposal
People understand stories. They don’t understand disconnected information dumps.
Your doc needs a narrative arc. You’re not just presenting facts—you’re taking the reader on a journey from “here’s the problem we’re facing” through “here’s what we learned” to “here’s what we should do about it.”
Problem: What are we trying to solve? Why does it matter? Quantify the impact.
“Our NPS dropped from 45 to 32 in Q2, driven by complaints about slow load times (mentioned in 78% of negative feedback).”
Insights: What did we discover when we investigated? What surprised us? What did we learn about our users, our product, our market? “
We traced the issue to the reporting feature, which makes 47 database calls every time it loads. Users who use reporting weekly are 3x more likely to churn.”
Proposal: Based on what we learned, here’s what we should do. Here are the trade-offs. Here’s why this is the right path forward.
“We should rebuild the reporting backend to use cached data. This will cost 6 engineering weeks but reduce load time from 8 seconds to under 1 second, directly addressing our top churn driver.”
This structure works because it mirrors how people naturally process information and make decisions. It also ensures you’ve done the work—if you can’t clearly articulate the problem or insights, you’re not ready to make a proposal.
5. Actually write it like a story (connect to the next step)
Related to the point above, but worth separating: your sections should flow together like chapters in a book, not feel like disconnected slides slapped together.
Each section should naturally lead to the next. The end of one section should set up why the next section matters.
Bad:
Section 1 ends: “Our signup conversion is 18%, significantly below the industry benchmark of 35%.”
Section 2 starts: “We interviewed 12 users.”Good transition:
Section 1 ends: “Our signup conversion is 18%, significantly below the industry benchmark of 35%. We needed to understand what’s blocking users.”
Section 2 starts: “We interviewed 12 users who started but didn’t complete the signup. Here’s what we learned...”
See how the second version connects the sections? The reader understands why you interviewed users—it’s the natural next step in solving the problem you identified.
6. Eliminate every single weasel word
Weasel words are words that should mean a quantity, but don't quantify. Words like “some,” “many,” “often,” “significant,” “substantial,” “improved,” “better.”
Every word that implies quantity must be quantified.
Don’t write “many users requested this feature.” Write “47 users requested this feature in the past quarter.”
Don’t write “performance significantly improved.” Write “load time decreased from 3.2 seconds to 1.1 seconds.”
Don’t write “we saw substantial growth.” Write “revenue grew 23% quarter-over-quarter.”
Why does this matter? Because weasel words let you hide from accountability and clarity. They let you say things that sound good without actually committing to a specific claim. They also make it impossible for readers to evaluate your argument.
If you write “many users complained,” your CEO might think you mean 1,000 users. Your eng lead might think you mean 10 users. When they find out it was actually 3 users, your credibility takes a hit.
Specificity builds trust. Vagueness erodes it.
Go through your doc and replace every weasel word with a number. If you don’t have the number, either go get it or acknowledge you don’t know: “We don’t have data on adoption rates yet, but based on support tickets and sales feedback, at least 15 enterprise customers have asked about this.”
7. Charts don't speak for themselves
When you add a chart with no explanation, what you are doing is making the reader squint and ask, “What should I conclude from this?” Then Slack pops up, and you have lost the reader.
Your chart needs two things:
A clear written insight that tells people what they’re supposed to see. Don’t make them interpret it. Tell them: “Revenue from enterprise customers has grown 3x faster than SMB revenue since we launched the admin dashboard in February.”
Visual highlights that draw attention to what matters. Highlight the relevant bars. Draw a circle around the inflection point. Add an arrow to the trend you want people to notice.
Think of your chart like you’re explaining it to someone over the phone. What would you tell them to look at? Write that down. Then make sure the chart visually emphasizes those same elements.
8. Run it through Grammarly (or any grammar checker) before you hit send
I don’t care how good a writer you think you are. You’re making typos. You’re writing run-on sentences. You’re using passive voice when active would be clearer. You’re just not seeing them because you’ve been staring at this doc for three hours.
Use a grammar checker.
As a non-native speaker, Grammarly saved my ass many times. But you obviously can choose whichever you think is best.
Caveat: don’t blindly accept every suggestion. Grammar checkers are tools, not gods. Sometimes they’ll flag something that’s actually fine, especially if you’re writing in a more casual or direct style (like this article). Use your judgment.
Also, one bonus tip: read your doc out loud before you send it. Seriously. You’ll catch awkward phrasing, missing words, and unclear sentences. If you can’t easily read a sentence out loud, it’s probably too complex. Simplify it.
If you found this article useful, please smash the “like” button. If you know any PMs who could benefit from it, share it with them. This is a tremendous help to me.