The right amount of context
With your audience now firmly in mind, you want to get them from where they are to where you want them to be in as few words as possible. Say less. However, you need to give them just enough context for them to be able to make an informed decision. This is a delicate balance, but with some practice, it becomes second nature.
A few principles here:
- If an audience of a message all know something, you don't need to share that context.
- If none of the audience knows something and it's important to your message, share it.
- If some of the people know it and it's important to your message, give a short summary and link to somewhere they can acquire more context.
- If the context isn't important to your message, leave it out. If it can't be left out, drop a link somewhere else to avoid distracting from your message. If you can't link out, put it at the end.
You want to give them just enough context to be able to hop into the rest of the doc/meeting armed with the correct information to achieve your goal of the meeting or document.
A big temptation for people is to "show their work" by identifying how they acquired the information, where they got it, how much they know, etc. In general, I would say this is a mistake (in the lens of trying to achieve your doc/meeting's goal). You are better off just getting to the point. The exception here is sometimes it can be good to establish credibility. "I had to go work with another company's PMs to acquire this info" can show that you did good due diligence.
An example
Let's say we are undertaking a project to upgrade our infrastructure from being hosted on managed dynos Heroku (a platform as a service, like AWS Elastic Beanstalk, Azure App Service, or Google Cloud AppEngine) to being hosted on Kubernetes on Google Cloud. Let's say we have to have two meetings, one with the leaders of product management at our company and one with the engineering architects of our company.
Both of these meetings are going to need some context-sharing. But let's look at how these are going to be different.
For product leadership, we will have to explain a bit of what Heroku is, what Kubernetes is, why this difference is preferable, and then do a pretty in-depth dive on the risk since that's very likely what they don't understand and need to know. After all that context we can get into what you need from them, but without that context it would be a very confusing discussion for them.
For engineering leadership, we can likely skip the "what is PaaS and what is Kubernetes" discussion and head straight to our product goals for this migration, the technical details of what is required, and then jump straight into implementation details and challenges.
Reduce surface area
Say less. Focus your discussion on the topic you want to actually talk about and ruthlessly rip out unnecessary topics and facts.
Why? Think back to your last meeting, where it got totally derailed on a side discussion that had nothing to do with the original topic, and you ended the meeting without actually doing what the point of the meeting was. That is the reason you want to strip details out of your communications. You reduce the surface area for folks to pigeonhole on and miss the point of why you are having a discussion in the first place. This comes back to the "show your work" that people like to do but ultimately harms them. If you share unnecessary details, it can spark discussions that move away from what you are looking for.
Don't convince people who don't need convincing
Another common pitfall I see in technical communications is PMs convincing people, "We need to do this project because X," when the people in the room are already sold that the project needs to happen. If everyone already agrees that a project needs to move forward, don't waste time by making those points. In reality, you are working against yourself because by dwelling on the argument for doing something, you are necessarily highlighting the case against doing it too. By trying to convince people, you will frequently talk them out of it because you are highlighting a tension that they probably weren't thinking about. Say less.
You prepare for 100% so you can say 5%
This surprises many newer product managers, but a lot of the work you do will never be visible to anyone, and that is okay. When I was a software engineer, basically all of my work ended up visible to some degree, and if it wasn't, then I probably wasted my time. In product management, being fully prepared in discussions, meetings, and documents necessitates a lot of meetings, research, and other things for you to understand entire problem areas and discuss its finer details. That is okay. Be okay with knowing that you don't have to show everyone what you're doing all the time.
This isn't high school English class
When I wrote essays for my English class in high school, I had to have an introduction, exposition, and a good conclusion. I had to vary my sentence structure, use an emotive vocabulary, and delight my reader with my prose as much as my content.
Don't do that.
Technical communication is very different than writing novels and essays. Your job isn't to entertain. It isn't to show off your writing skills. It is to inform and convince. It is to be effective and efficient. Use direct voice. Don't worry about the technicalities of writing essays; get to the point and be effective. Short sentences directly describing what you are trying to say are generally best. You want to get from zero to your point as fast as is reasonably efficient and not much more. Anything else is a waste of time.
