I write everything down. I take fervent notes, finish a notebook a month, furiously type on my laptop, and devour post it notes. At work and outside.
The trigger to start was that I hated doing it. I absolutely, vehemently hated it. My hatred for writing and my disregard for putting pen (or keystrokes) to paper were supported by my team at the time being small and agile. I used to make quick stories, and for any additional context that the team needed, I was a ping away. But as my portfolio of products grew and I started working on more strategic projects, my method of being always accessible started to fail me. I needed to document so my teams could keep working without me around.
Armed with the belief that consistency would lead to fondness, I started writing at least one page of something every day. It could be a product note, a JIRA story, or just a journal entry, but I had to do it consistently. And it helped - a lot! Over (a long, long) time I found myself enjoying writing. I was writing more and documenting more in my day job as a side effect of my writing habit.
I started to notice the benefits that I slowly grew to rely on. Here are some ways writing helps me:
Communicating at scale Every time I had an idea, I would talk to someone relevant about it. Then to someone else, then another, and before long I had talked to tens of people to go from idea to buy in. Writing liberated me from this chain of communication. A well written one pager travels farther and faster than endless 1:1 meetings. Writing further scales communication by creating more context with each feedback. Addressing FAQs that come up in comments becomes easier. Quickly revisiting decisions based on new information and communicating them rapidly to all stakeholders becomes much more realistic.
Reduced dependency Sound advice I once got from a colleague - a good product manager is one who makes themselves redundant to the team. Teams should be able to function without a Product Manager for as long as possible. Writing is my way of accomplishing this. Strong product specs, story boards, and goals ensure that everyone in a team knows what they must do. Writing has enabled me to reduce the frequency with which I need to plan and give direction to my team. If everything is documented clearly, what to do next is just a question of reading what's written and agreed upon, at least in the short term. Of course, bugs, product outages, and drastic changes in direction still need a PM's input, but those are far less frequent than day to day team rituals.
Mitigating execution risks Many of us, as soon as we have a path to a solution, assume that the problem is solved. We have the tendency of leaving out minor details from the solutions in our heads, often with the line "and then the rest is easy". The course of execution makes us realise that complications can arise when we least expect them. Writing forces me to see my blind spots. By asking for thought and structure, by writing from a reader's perspective, I think about gaps in my solution. I think about things that are clear to me but not to my reader. It forces me to let go of "and then the rest is easy" by asking to define what the rest is. Writing out my solutions early has made me change product decisions and avoid execution roadblocks so many times that I'm surprised I ever got by without it. I've managed to avoid making assumptions that would have cost a lot of time and energy to solve later. Mitigating execution risks helps consistent and on time delivery.
Eliminating unknown unknowns I've mentioned before that writing helps me scale communication. One peculiar advantage of scaling communication is minimising unknown unknowns. As a piece of writing is read and circulated, network effects kick in. Readers find it relevant for someone else, and they share. It reaches people I didn't consider sending it to. This helps identify dependencies that I wouldn't have other wise seen or bring new perspectives I wouldn't have considered otherwise. Often times when I've shared something I've written, others have reached out to me offering support, sharing their experience, or telling me about related things they were working on. This has avoided duplication, and more importantly, led to some great collaborations.
Writing for the sake of writing isn't that fruitful though. It must be done with the right intent. First, I write with the intent of sharing. Executives, my colleagues, developers, designers, everyone must understand the gist of the document, the goal it wishes to accomplish, as well as asks of them.
Second, I keep myself open to feedback and criticism. It's not uncommon for someone to challenge the data I present or the assumptions that I've made. This promotes a discussion in the comments section - something that me, my commenter, as well as all future readers gain from. This is also great because catching something that's wrong or difficult early saves everyone time and resource.
Do you write as a product builder? Does it help you? I'm thinking of sharing some of my frameworks for effective product writing next. If that's of interest, let me know!
If you'd like to be updated when I publish my writing frameworks, join my weekly mailing list here: https://www.founditblog.com/join
Very well written!
Would definitely be interested in your framework for effective product writing.
I definitely feel motivated to write more now.
However, writing PRDs is just very hectic.