Tips for becoming better writers, and thus, better PMs

As PMs, one of the core requirements of your job is communication. In a lot of cases, this begins with writing clear documents and requirements. If you are not clear with your requirements, you could face a lot of problems later in the product development cycle, which can complicate things even further.

But it is hard. Cultures can vary from company to company and team to team, but the overarching goal is - create clarity within your team, and clearly mark what open questions you have. 

Some companies, like Amazon, heavily index on writing -- any new product has to start with a written document. 

There’s a famous online image that gives some great writing tips: 

5 tips to improve your writing instantly:

• Use active voice instead of passive voice: Instead of -- This is being done by team X, so we should collaborate with them, write Team X is doing this, so we should collaborate with them.
  ‍
• Show, don’t tell: This is a famous phrase used in the world of writing fiction. Instead of writing what your characters feel like, you write down what they do as a result of what they feel. Similarly, for PMs, use flow charts and diagrams, mockups (pen-and-paper are fine!).
  ‍
• Create templates that suit you: These could differ from team to team, but generally having a template that has sections you can fill in quickly helps to avoid any items you might otherwise miss. 
  --> But do remember that templates might not always work, and don’t be afraid to break the chain if you have a better way to explain things.

• Write, edit, repeat: Writing is not a one-and-done process. It is an incremental process. The most famous writers know the importance of shitty first drafts. Just like you would develop a product, refine your documents over time, adding and removing things over a period of time.  
  ‍
• Suit your message to the audience: Product docs are not the only thing you will write. You will write email threads, slack messages, etc. When communicating with the leadership, you want to give only the most important information, and ask for feedback / help. When communicating with your engineering team, you need to dig deep into the architecture. When talking to your sales team, you need to give them a clear idea of how each feature works.