The previous chapter was all about the principles of good communication. Let's take these principles and apply them specifically to technical writing.
If you have never taken technical writing, it is wildly different than what most folks learn in high school to prepare them for the SAT or the ACT. Technical writing is all about "How do I communicate my point effectively and efficiently?" and not about entertaining the user or making them think deeper or anything like that.
A lot of being a PM is writing. I dare say it is most of it. You write a lot of emails, meeting agendas, product specs, tech specs, requests, etc. Being a good writer is a superpower of a good PM. Being a bad writer is an anchor.
I will say that I don't necessarily like writing. I don't hate it either, but it's not like I get in front of my MacBook and get giddy. Hell, I'm writing this right now, and I'm not buzzing with excitement (you weren't expecting this to get meta, were you? I wasn't.)
But being a good writer is such a lever for change in organizations. It is the best tool you own to influence people and organizations to do what you want them to do. A well-crafted memo or email can have viral effects as people pass it around. A good slide deck can move companies. I've seen and done both.
So let's recap the last section through the lens of technical writing.
Who is reading your email / memo / slide deck?
Before you start writing anything, have a good think about who is going to be reading your document. Keep in mind that it is not just who you are sending the doc to, but who they might show it to as well. A good example is that I recently wrote a team charter doc to codify who my team is and what they do. Initially, the doc was written to get my team all aligned on what we were working towards, but that doc lives longer than that: it informs new engineers joining the team what the team does; it informs leadership how the team sees itself; it informs sister teams how to engage with my team. I needed to write that doc with all of those potential readers in mind. It, therefore, needed to address the concerns of all of those readers as well as offer enough context-setting information to get any reader in the correct mindset to understand the team charter. It didn't need to convince the reader that our product was superior; it wasn't external facing, and any reader would already be bought into the organizational vision.
Some docs are just written to share quickly; no need to overthink it. Just make sure you are always focusing on who the reader is. Otherwise, you can tend to wander and either over or under share, both of which hurt your objective.
Say less
We went over it before because it ties into writing for your audience, but less is more when it comes to writing docs. Ruthlessly cut unnecessary sections from docs. When a small percentage of your readers need additional context, link to additional docs with the necessary context or add appendixes. Do whatever you can to keep your doc laser-focused on delivering your message.
A good question to ask yourself is, "How much time do I anticipate people will take to read this doc?" I will state that rarely a reader will take more than five minutes to read a doc. One to two is a pretty engaged reader. Five minutes is a highly engaged reader. For anything more, it means that the doc is directly pertinent to the reader e.g. a designer reading a product spec to be able to design the interface. So whatever you write, plan to get your point across in that time or less, whatever you planned for the reader to spend. Use that time wisely.
