Why you should learn to write to be a great Product Manager
As a Product Manager, you solve problems. Often, these problems exist as vaguely stated questions. What is the right next version for product X? How do we monetize product Y? Is there an opportunity for us in market Z? You need to convert these abstract questions into living and breathing products that your customers will love. The process of doing so often requires diving deep into the problem space, and understanding the customer pain points. You then need to develop ideas on how to solve these pain points, and hone in on one idea that enables you to do so in a differentiated way. Next, you need to persuade your leadership and stakeholders on your idea, and start handcrafting the customer experience with your designers and engineers. Finally, you need to compel your customers to try your product.
This is a creative process. It is more art than it is science. What this creative process of product management requires is critical thinking and clear communication. There is just one tool that facilitates both critical thinking and clear communication at the same time.
It is writing.
If you are a good writer, you are by default both a good thinker and a good communicator. And therefore, the shortest path to being a great Product Manager, is to become a good writer. I know this through my own experience.
How writing shaped my product management journey
In 2012, I started as a fresher at Amazon. I joined on a team chartered with launching Amazon in India. I was the least experienced on the team. I was intimidated by the people around me, by the ways of the corporate, and by the magnitude of the task ahead of us. I was anxious to find some way to prove myself worthy. I did not find it, but my director did. He decided that I would write all strategy documents for him. It is well known that documents written in narrative form enable the decision making mechanism at Amazon. So writing these documents was crucial to the organization, and it would be a learning exercise for me.
My first task was to write the business case for launching Amazon’s own package delivery network in India. It would cost tens of millions of dollars, and needed an SVP approval. It was a daunting first document to write. After a few days of staring at a blank Word document, I made the first good move in my writing journey. I asked for a reference document—one that had dealt with a similar topic, one that would show me what good writing looks like. Once I received it, I copied whatever seemed good in that document, adapting it to my topic. The result was not great, but I now had something that I could start showing others. I shared it with as many people as were willing to provide feedback. And I received a lot of feedback. At first, it was overwhelming. But as I worked through each piece of feedback, I saw the document was getting better. When it was finally reviewed by the SVP, the meeting went fine, and the plan was partially approved. But more importantly, I had learnt two key lessons on writing—to blatantly copy what is good, and to get as much feedback as possible to iteratively improve the writing.
For the next two years, I wrote documents of all kinds. Three year plans, new business proposals, requirements documents, retrospectives, forward looking plans, and more. In a few months, my confidence began to grow. I realized that I now knew more about the business than most others on the team. I also started to understand the decision making process at an executive level. I could see how the documents I wrote were shaping the way we ran the business. My role turned into a function, and soon I was leading the program management office for my organization.
I have since been able to steer my career at Amazon from program management to product management to now leading product and engineering teams. My career was founded on the practice of writing, which enabled a discipline of critical thinking and clear communication, an ability to deal with a high degree of ambiguity and separate the signal from the noise, which in turn has led to a fascinating journey through product management.
How writing helps product management
Provides clarity: As a Product Manager, you often need to dive deep into data to draw insights, scour the internet for research, or survey customers to understand their needs. These activities generate a ton of unorganized information. Writing gives you the moment to step back, and think through all the information you have gathered, and ask important questions. Was your instinct or hypothesis right, or did it get invalidated? In either case, what does it mean for the idea you’re working on? What next step do you need to take? Good product management often boils down to asking the right next question, answering it, and doing that on repeat. Writing facilitates this process. Often, writing will lead you to talk yourself out of an idea, or set you off to explore a different, better idea.
A few years back, I had launched a tool for small-sized sellers to ship their customer orders. I was convinced that the next step for this product was to start serving sellers of all sizes, and shipments of all sizes. I started writing a document to make this proposal. But as I read what I was writing, I noticed that I was making certain assumptions, and I started questioning those assumptions. Writing does this for you. It makes you pause, and question your thinking. It enables you to self-brainstorm. As I dug deeper on the assumptions, I realized that my initial thesis was wrong. But a specific feature I had written about in my draft document sparked another idea. I realized that specific components of the tool could be extended to new customer segments and use cases, instead of the entire tool itself. I pivoted the document to make this revised proposal, which was approved and became a program.
When you write down your thoughts, it enables you to question them, look at them from different angles, make connections between different thoughts, and crystallize them. You will now be able to transmit this clarity to others—your design team, engineering team, leadership, and even your customers.
Creates a level playing field: When a written artifact gets passed around, it brings everyone on the same page. It equalizes information across all stakeholders. Engineers, engineering managers, designers, design leads—all have the same understanding of why you are building what you are building. Once this happens, everyone is able to contribute to the product development process.
Once, a Product Manager on my team wrote a proposal to improve our claims review process. When the engineer read this proposal, and understood the problem we were trying to solve, they came back with an idea to not just improve the process, but to completely automate it within the targeted timeline. The Product Manager collaborated with the engineer, and rewrote the product proposal to incorporate the engineer’s idea. And we executed on it. This was a big win for our customers, and a much better outcome than the Product Manager had initially envisioned.
A key part of the Product Manager’s job is to ensure ideas flow in from all directions, and writing enables this by leveling the playing field.
Enables better decision making: As a Product Manager, you are required to make several decisions about the product you are building. Good decision making requires methodical thinking. You need to come up with a list of viable options. You need to understand all the factors that will influence your decision. You then need to think through the pros and cons of each option against the decision factors. Once these are in place, you need to weigh the pros and cons, and apply judgement.
Let’s take a classic example. A decision point that Product Mangers often encounter is whether to build or buy the capability required to launch the product. There could be a few different ways to build in-house, and a few different providers from whom to buy. This is the list of viable options. Building in-house may cost less, but may take more time. It may provide you more control on the customer experience, but may require you to carry an additional operational load on your systems. So there you have some decision factors—cost, time, customer experience, and operational load. And you are already starting to see some pros and cons of your options. You go through the process, and determine all the pros and cons of each option against each decision factor. You then have to weigh your decision factors given your current situation. For instance, the pros and cons of various options might net out in a way that building in-house is your best long-term option. But your current business realities may make buying more attractive in the short-term. So you may have to decide to buy in the short-term, while leaving the door open for in-house development down the line.
What I just described is a fairly complex thought exercise that is very hard for most people to do verbally, or in their minds. There are too many moving parts to keep track of, and they all influence each other in ways that you might not appreciate intuitively. But when you capture all of this on paper, you gain greater control on the variables. They transform from elusive thoughts to tangible arguments that will start driving your decision making. Writing down your viable options, the decision factors, and their pros and cons will invariably lead to a better decision. At the very least, it will provide a future reference point for why you made that decision.
What you should write as a Product Manager
That Product Managers write product specifications (requirements documents, user stories etc.) is well-known, and a standard expectation. Product specifications answer how the product should work. There is enough material on how to write good product specifications, so I will not spend time on it. But there are important strategic questions that need to be answered on either side of writing product specifications. One is, what should we build and why. The other is, how should we take the thing we built to market. Let's take a closer look at each of these.
What to build and why: To effectively answer this question, you need to answer each of the following questions. Who is your customer and what is their pain-point? How do you propose to solve this pain-point? What are the current alternatives customers have to what you are recommending? Why will customers choose your product over these alternatives? Why you (your team or organization or business) are well placed to build this product? These questions intersect in nuanced ways. As your answering the fourth question, for example, you might want to revisit your answer to the second question. Writing your answers down enables you to not only be thorough in your thinking, but also be flexible and move your ideas around, turn them and look at them from different angles, and build a strategy that is robust. If you are able to answer each of these questions to your own satisfaction, it is very likely that your product idea has legs. This should give you the conviction to convince your leadership and stakeholders to invest in your idea. If successful, you now have a strong foundation upon which to build your product specifications.
How to take the thing we built to market: At this point, you have gone through the stages of writing your product specifications, and iterating on it with your design and engineering teams. Your engineering team is nearing development completion. You now need to be thinking about the following questions. Which customers should first adopt your product? How will you create awareness of the product with these customers? What mechanisms do you have to collect feedback from these customers? How will you know that your product is successful? Often, Product Managers get so absorbed in launching the product, that they do not think deeply enough about what they will do after the launch. This leads to a situation where the product is out there, but the Product Manager does not know how it is doing. Spending the time before launch to write down the plan for how you will take the product to market, and how you will measure how it is doing, will increase the chances of success for the product.
I have focused this section on building a new product. Many times, Product Managers iterate and improve existing products. The above framework applies to new features in an existing product as much as it does for new products, albeit at a smaller scale. But there is one more question that Product Managers need to ask while iterating on an existing product: what is my product roadmap. This question breaks down into more questions. What is your backlog of features? How do you prioritize them, and why? What will your product look like three, six, twelve months from now? Writing down your answers to these questions will ensure you take a long term view on your product, and make short term prioritization decisions to drive toward your long term state.
What it takes to write well
There are enough books about the style of writing that focus on form and syntax. These are useful, and you should refer to them as needed. But what I want to do here is share three of my learnings about the approach to writing that have helped me become a better writer.
Be aware of the curse of knowledge: While writing, we often assume that our readers know a lot more about the topic than they actually do. This happens because the more we get to know something, the less we remember how hard it was to learn. The writer finds it difficult to imagine what it is like for someone to not know something that they know. This is the main cause of writing that is incomprehensible. Overcoming it requires some cognitive toil for the writer. Here are a few ideas.
Avoid the use of jargon, abbreviations, and technical terms. Pare these down to their essentials, and explain them with simple words. Imagine you were talking to a professional peer who comes from a different industry or function than yours.
Show a draft of your writing to people that are similar to your intended audience, and get feedback. Alternatively, revisit your own writing after a few days, when you are detached enough from it. Go through a few revisions of your draft in this way.
Start from what your readers already know. Save the new for last. People learn by integrating new information into their existing knowledge. When a fact is thrown at them out of the blue, they will need to hang on to it until they find the relevant background to embed it in. They don't like this. Instead, start with the background which they are familiar with. And then bring in the new.
Show, don't tell: To understand something, people need to see the sights, and feel the motions. The way in which thoughts occur to a writer is rarely the same way in which they can be absorbed by a reader. For example, what an experimenter might describe as "testing conditions" is better understood by their readers as "a quiet room". When you focus on showing something to your reader, versus telling something to them, you transform the act of writing to acts of talking and seeing, which comes naturally to us. A tactic that helps achieve this in writing is to provide examples. Consider this description of a certain Product X.
Product X enables customers to connect with their loved ones instantly. No ringing or answering calls. It's all hands-free.
You might think you sort of understand what Product X is. Consider this follow-up to the previous statement.
Monica, an ardent user of Product X, uses it every day to check in on her bedridden grandmother. “It feels like being by her bedside,” Monica says, “and I can be there any time I want to.”
The anecdote starts to cement the understanding of Product X. An example always help anchor the point you are trying to make in a real-life context that your readers will relate to.
Omit needless words: You would have heard some version of the quote, "If I had more time, I would have written a shorter letter." A variation of that, but just as apt, is, "You wouldn’t believe how much it costs to look this cheap.” Every time you add a word to your sentence, you are imposing two cognitive demands on your reader: to understand the word, and to fit it into the context of the sentence to make sense of the whole. This double demand is a major justification for omitting needless words. We unknowingly introduce fluff into our sentences, which we can remove through iteration. For example, "There is competition between groups for resources" works just fine as, "Groups compete for resources." There is a trade-off between clarity and brevity. You do not want to sacrifice clarity for the sake of brevity. You need to find the pithiest way of delivering full clarity on your topic.
So, where to begin
If you already are a Product Manager, think about what your product needs most. Is it a new product that needs to be defined from scratch? Is it under development and needs a go-to-market plan? Is it an existing product that needs a roadmap? Based on where in its life stage your product is, use the questions we discussed in the “What you should write as a Product Manager” section, and write down your answers to those questions. You may want to add more questions, or modify the ones we discussed, as may be needed for your product. Get feedback from your stakeholders on what you write, and iterate based on that feedback. This should give you a taste for the benefits of writing we discussed earlier, and will hopefully encourage you to do more of it.
If you are an aspiring Product Manager, pick the topic that is top of mind for you in your current function. It could be an important decision you need to make, your roadmap for the next year, or an idea you have been wanting to work on. See what questions we discussed above might apply to your situation, and start writing down your answers. You will start noticing how writing enables an internal Q&A in your mind, and propels your thinking forward.
I believe in the broad applicability of product management as a discipline to solve problems in business, and beyond business. I also believe in writing as a tool for better thinking and communicating, not just in the context of product management, but in general. I have been fortunate to explore the intersection of these two broad disciplines, and to learn and grow through this exploration. I wish the same for more Product Managers.
