Technical Writing Tips

i built this prompt to make me proficient in any technical topic. it's been a godsend. it includes technical depth, but translates every piece of jargon into plain english with a real world example. feel free to steal it: 🧠 Deep Research Prompt Template (Extensible Version) Objective: Create a comprehensive research report on [INSERT TOPIC HERE]. The goal is to build a deep conceptual understanding of the topic — from its theoretical foundations to its real-world applications — so that I can use this as a launchpad for further exploration. Audience: A non-technical but intellectually fluent reader. I’m comfortable following complex discussions, but I’m not formally trained in this technical domain. Tone & Style: - Write in a clear, structured, and explanatory style. - Include technical depth, but translate every piece of jargon into plain English. - After each complex term, formula, or mechanism, provide: a) A plain-language translation (explain it like you’re teaching an intelligent layperson). b) A real-world, tangible example or analogy that makes the idea concrete. Content Requirements: 1) Foundations Section - Define the core principles, vocabulary, and historical context behind [TOPIC]. - Explain why this field exists, what problems it solves, and who pioneered it. - Use simple examples to show the basic mechanics at play. 2) Core Concepts & Mechanics Section - Dive into the key theories, processes, or frameworks that make up the topic. - Introduce any math, algorithms, or scientific models central to the field. - For each technical concept, pair the explanation with: a) A plain-language breakdown. b) A real-world illustration (e.g., from everyday life, business, nature, or technology). 3) Applications & Implications Section - Show how [TOPIC] is applied in real-world systems, industries, or technologies. - Include notable case studies or examples that demonstrate its impact. - Explain why understanding these concepts matters — what it enables or changes. 4) Integration & Broader Context Section - Connect this field to adjacent domains (e.g., how it interacts with math, physics, biology, economics, etc.). - If relevant, trace how the theory translates into practice (e.g., from code → circuits → behavior). - Highlight open questions or ongoing research frontiers. 5) Formatting & Accessibility Guidelines - Use clear headings, subheadings, and summaries at the end of major sections. - Define jargon inline, not in a glossary. - Use metaphors, analogies, or thought experiments liberally. - If helpful, include short “mental models” or “rules of thumb” to aid intuitive understanding. Output Goal: A research-style explainer (typically 3,000–5,000 words) that is educational, accessible, and intellectually rigorous — something that helps a curious but non-specialist reader gain a working, conceptual mastery of [TOPIC].

Found this 1980 ad about writing clearly. 65 years later, it's still the best writing advice I've ever seen: 1) Know exactly what you want to say before you start Most people start writing and figure it out as they go. That's why most writing sucks. Thompson says outline first, write second. Revolutionary concept, apparently. 2) Start where your readers are, not where you are Don't assume people know what you know. Meet them at their level of understanding, then bring them along. Most "experts" write for other experts and wonder why nobody gets it. 3) Use familiar word combinations Thompson's example: A scientist wrote "The biota exhibited a one hundred percent mortality response." Translation: "All the fish died." Stop trying to sound smart. Start trying to be clear. 4) Arrange your points logically Put the most important stuff first. Then the next most important. Then the least important. Seems obvious, but most people do it backwards. 5) Use "first-degree" words Thompson says some words bring immediate images to mind. Others need to be "translated" through first-degree words before you see them. "Precipitation" => "Rain" "Utilize" => "Use" "Facilitate" => "Help" 6) Cut the jargon Thompson warns against words and phrases "known only to people with specific knowledge or interests." If your mom wouldn't understand it, rewrite it. 7) Think like your reader, not like yourself Thompson asks: "Do they detract from clarity?" Most writers ask: "Do I sound professional?" Wrong question. TAKEAWAY: This ad is from 1960. The internet didn't exist. Social media wasn't even a concept. But the principles of clear communication haven't changed. Most people still can't write clearly because they're trying to impress instead of express.

The difference between a good design doc and a great one is usually clarity. Technical writing should be crisp and to the point. So, it is always better to treat every sentence like it has a cost. After writing, cut aggressively. Remove extra words. Then check if a line can go. Sometimes even a full paragraph is unnecessary. One thing I always do is to start the doc with the conclusion; this way, the reader/reviewer knows where we are heading. This is contrary to how most engineers write docs - listing every approach first and only concluding at the end. That slows readers down. I avoid this because long explanations make people lose track; most readers want the conclusion quickly. So, always start with the answer and why it matters. Then add details and alternatives below for those who want depth. A habit that helps is a quick editing pass like this: - Remove filler words and repeated ideas. - Break long sentences into smaller ones. - Prefer bullets when listing options or steps. - Check if the first section clearly states the outcome. - Add a link or short explanation where a reader may pause. Empathy matters more than most people realize. Try to read your document as someone new to the topic. Ask yourself what might confuse them. Add the missing context. Add the helpful link. Let the ideas evolve naturally from problem to solution. This skill develops over time. Use simple language and fewer buzzwords. The goal is to communicate, not impress. Simple documents get read more. More readers means better alignment and better visibility for the work. Finally, always provide enough context. A short setup about the problem, constraints, and prior decisions goes a long way. It helps readers understand why the decision exists, and, of course, it prevents unnecessary back and forth later. Hope this helps.

Reviewers agreed my research was rigorous. Then they rejected the paper anyway. The science wasn't the problem. It usually isn't to be honest. But the structure was. Here's what I learned after publishing 300+ papers: Many rejected papers fail for this single reason: Reviewers never make it mentally past paragraph 3. They found nothing that grabbed them. Sorry, but they couldn't find your story or weren't interested in it. I've watched this happen nonstop as an Associate Chair. Solid methodology. Meaningful results. Genuine contribution. But still not passing the bar. None of the data you collected matters if you can't hold your readers attention past the first few sentences. Think of your paper as a pile of LEGO bricks. Raw data? That's the chaotic heap on the floor. Every kid dumps the box out. Every researcher collects findings. Yet nobody ever got famous by just playing around with LEGOs. (Sadly.) But here's where papers really perish for good: Most academics stop at SORTED. Great, you got your themes colour-coded, buddy, but you still gotta build the house. The papers that get cited for decades? They build the house. Brick by brick. Thinking. SORTED → ARRANGED → PRESENTED → EXPLAINED (W/ STORY) That's the journey your reader needs. From chaos to meaning. I now structure every paper as a 5-act story: Act 1: Introduction Create a curiosity gap. Make reviewers think: "Hey, I've never thought about that." Act 2: Literature Review Set the scene. Show how everyone's been circling a problem like sharks that your work now fills. Act 3: Methods Build trust. Write like Betty Crocker. Put down a recipe another researcher can follow. Act 4: Results Deliver surprise. Lead with your most counterintuitive finding. Yes, you can report results in a meaningful sequence. Act 5: Discussion Provide meaning. Connect your data to the bigger picture. Explain the: "So what?" One test I use for every section: → Why would a smart reader keep going? If you can't answer that, rewrite the transition. I spent years treating structure as an afterthought. The science came first. The writing came last. That's backwards. Rigour and readability aren't opposites. The papers that get read for a decade usually have both. Playing with LEGO bricks is fun and all, but have you ever built a house? Save this for your next data session. One tactical system per week. 13k+ researchers. Zero fluff. → https://lnkd.in/e4HfhmrH

My holy grail writing tips for instantly better copy: Make it active → Start with a verb ❌ "Our products support childhood development" ✅ "Watch your toddler discover new textures" Write with precision → be specific ❌ "Loved by parents everywhere" ✅ "Part of 50,000+ bedtimes" Keep it short → ruthlessly edit ❌ "Our solution gives parents the ability to monitor their baby's sleep patterns and get detailed insights" ✅ "See exactly when your baby stirs" Use "you" not "we" → center your customer ❌ "We create safe, non-toxic products for families" ✅ "Keep your kids safe from harsh chemicals" Read it out loud → if it sounds weird, rewrite it Would you actually say "transform meal planning" to someone? No, you wouldn't (unless you're a chatgpt reading this). You'd say "figure out dinner with no meltdowns"

Communication isn't what you say. It's what everyone hears. And not just what they hear passively. But what action your words inspire in them. If you're leading a team, remember: • 90% of your team didn't hear you the first time • 50% didn't hear you the third time • 10% never will Clear communication requires repetition. When you're sick of saying it, they start to hear it. Here's the pattern the best communicators follow: 1. Create Systems Don't rely on one-off conversations. Build processes that reinforce the message consistently. Different formats for different learners. 2. Embrace Repetition Clarity requires persistence, not perfection. Say it again. Then say it differently. Then say it again. 3. Verify Understanding Check what was heard, not what was said. Ask: "What did you take away from that?" Create feedback loops that close the gap. Here's how the world's best leaders put these patterns into practice: Satya Nadella's "Model-Coach-Care" ↳ Shows the way personally first ↳ Coaches others through the change ↳ Demonstrates genuine care for outcomes "Don't be a Know-It-All. Be a Learn-It-All." Ray Dalio's "Radical Transparency" ↳ Records every meeting at Bridgewater ↳ Makes them available to all employees ↳ Uses real-time feedback tools "Lead discussions by being assertive AND open-minded. At the same time." Andy Grove's "Disagree and Commit" ↳ Encouraged vigorous debate before decisions ↳ Required full alignment after decisions ↳ Made dissent safe, but execution non-negotiable "Let chaos reign, then rein in chaos." Steve Jobs's "Three-Story Rule" ↳ Every product launch told three stories maximum ↳ Repeated the same core message relentlessly ↳ Made complex ideas simple and memorable "Simple can be harder than complex." Reed Hastings's "Context Over Control" ↳ Netflix's culture deck shared widely for transparency ↳ Attracts the right people before they even apply ↳ Replaces rules with shared understanding "Don't tolerate brilliant jerks. The cost to teamwork is too high." The best leaders aren't the best speakers. They're the best at being understood. And they never stop until they are. 🔔 Follow Dave Kline for more leadership insights. ♻️ Share to help other leaders communicate with impact.

Users don't suck, but the information provided to them can. If your IFU reads like a legal contract, people won’t read it. Why? Because they’re confusing. Too wordy. Too complex. Too scattered. A great IFU should feel like having a clear-headed expert guiding you step by step. The user needs to know what to do, how to do it, and when to do it. Here's 20 recommendations/writing rules to improve your IFU↴ 1. Write procedures in short, identifiable steps, and in the correct order. 2. Before listing steps, tell the reader how many steps are in the procedure. 3. Limit each step to no more than three logically connected actions. 4. Make instructions for each action clear and definite. 5. Tell the user what to expect from an action. 6. Discuss common use errors and provide information to prevent and correct them. 7. Each step should fit on one page. 8. Avoid referring the user to another place in the manual (no cross-referencing). 9. Use as few words as possible to present an idea or describe an action. 10. Use no more than one clause in a sentence. 11. Write in a natural, conversational way. Avoid overly formal language. 12. Express ideas of similar content in similar form. 13. Users should be able to read instructions aloud easily. Avoid unnecessary parentheses. 14. Use the same term consistently for devices and their parts. 15. Use specific terms instead of vague descriptions. 16. Use active verbs rather than passive voice. 17. Use action verbs instead of nouns formed from verbs. 18. Avoid abbreviations or acronyms unless necessary. Define them when first used and stay consistent. 19. Use lay language instead of technical jargon, especially for medical devices intended for laypersons. 20. Define technical terms the first time they appear and keep definitions simple. Prioritize the user while ensuring MDR/IVDR compliance.

Why do so many communicators lose their audience? Often, it’s because we try to share everything. When communicating a complex project, whether it’s a new product feature, a design sprint, or a strategic pivot, we often see broadcasting ideas into the world as our goal. We want to show every wireframe, every debated nuance, and every data point we collected along the way. But our brains are not wired to absorb a stream of disconnected information. When we overwhelm our audience, we increase their cognitive load and quickly lose their attention. Our goal should be to make sure our audience understands. The antidote is structure. Structure acts as a psychological roadmap. It guides both the speaker and the listener through a clear, reasoned journey. On the Think Fast Talk Smart: The Podcast, I often talk about the importance of packaging ideas so they are easy to follow and easy to remember. One framework I often recommend for complex projects is what I call the 5P structure. It helps presenters walk their audience through a clear progression of ideas so the story behind the work is easy to understand. 1) Problem: Define the issue at hand 2) Process: Shaping your thinking 3) Proposal: Outlining the solution 4) Proof: Sharing the potential impact 5) Progress: Pointing forward Instead of overwhelming people with information, the structure guides them through the challenge you were solving, how you approached it, what you designed, the evidence behind it, and what comes next. When people can clearly follow the story, they are far more likely to trust the idea and help move it forward.

Speaking Tech and Human: Why Every Team Needs a Communication Chameleon Ever been in a meeting where it feels like everyone's speaking a different language? Not in the literal sense, but in that "tech jargon vs. human speak" kind of way. It happens all the time, especially in cross-functional teams. Engineers, with our love of acronyms and complex terminology, can sometimes leave non-technical folks feeling lost in the weeds. I recently witnessed this firsthand. Picture a late-night meeting about an upcoming AI launch. The tension is high, the deadline is looming, and suddenly, someone asks a seemingly simple question: "So, what exactly is an IDE?" The engineer on the call launches into a detailed explanation, complete with references to command-line interfaces. It's like trying to explain astrophysics to someone who just learned the alphabet. This is where we TPMs (or anyone with a knack for both tech and "human speak") come in. We're the interpreters, the bridge-builders, ensuring everyone's on the same page. In that late-night meeting, I jumped in with a simple explanation: "An IDE is basically the tool where developers write and test their code. It's like a word processor for software." Problem solved! The question-asker got the gist, the engineer learned a valuable lesson about audience-focused communication, and we all got a little closer to hitting that launch button. Key takeaways for clearer tech communication: - Know your audience: Tailor your explanations to the listener's technical understanding. - Focus on the "why": Explain the impact and benefits, not just the technical details. - Keep it simple: Avoid jargon and acronyms whenever possible. - Use analogies (when appropriate): Relate complex concepts to everyday experiences. Effective communication isn't about showing off your technical expertise, it's about building a shared understanding and achieving goals together. And in a world where tech is increasingly intertwined with every aspect of our lives, the ability to translate "tech-speak" into "human-speak" is more important than ever. Have you ever witnessed a "lost in translation" moment in tech? Share your stories in the comments! 👇 #TPMlife #TechLeadership #Google #LifeAtGoogle

I've been an editor for 7 years now. And here’s a truth bomb: 99% of editing advice online is generic. “Check grammar.” “Shorten sentences.” “Take a break.” Yes, but can we dig deeper? Today, I'm revealing the most underrated, unspoken editing hacks. No gatekeeping here: → Zoom Out to 50%: Sounds weird? Try it. Reducing text size makes formatting issues obvious. You’ll spot uneven line lengths and clunky layouts instantly. → Voice Note Test: Record yourself reading your draft aloud. Listen back without reading along. Awkward wording stands out painfully clear. → 'So What?' Technique: After every paragraph, ask “So what?” If there's no clear purpose—rephrase or remove. Keeps writing tight, engaging, purposeful. → One-Screen Rule: Keep each subheading's content fitting one screen. Scrolling mid-section causes reader fatigue. Break it down—short and crisp is key. → Color-Code Edits: Highlight different issues with different colors: 1) Pink for weak words (really, very, stuff). 2) Blue for unclear ideas. 3) Yellow for repetitive points. Visual cues speed up final revisions drastically. → Find-and-Replace for Punctuation: Search your commas, semicolons, dashes. Do you overuse them? Replace some with periods to punch up readability. → The Font Swap: Change your font temporarily. Your brain sees text as 'new' content. Mistakes and awkward phrasings jump right out. → Reverse Outline: Summarize each paragraph in 3-4 words. Is there logical flow? If not, rearrange or rework ruthlessly. Editing is surgery (don't question me). These hacks transform good content into remarkable content. But hey, I'm always learning. What's your top editing secret nobody talks about? Share it below 👇