For a long time, my primary career as a product manager and my writing gig felt like two separate worlds. Left brain vs. right brain, logical analysis vs. creative intuition. However, the sharp divide has softened over time, and I see increasing overlap in the skill sets and activities between the two. I currently work in an environment that has both a strong engineering and a heavy writing culture. Great product ideas and strategies depend on a crisp, compelling narrative.
My last two jobs in particular have made me reflect on how creative writing makes me a better product manager. It’s an overlooked topic, but I’m convinced creative writers (of fiction or poetry) bring a strategic advantage to the craft of product management, even though the field has traditionally been stocked with engineers and technologists. For my PM friends, perhaps some of these thoughts will motivate you to take up the mighty pen. I find that most PMs are already good writers because they are clear communicators, and creative writing will stretch that ability in new ways. For my writing friends, perhaps you will consider that if you want to work in tech, there are options beyond content designers and technical writers, where you can flex the range of your creativity.
To address the elephant in the room: what even is a product manager? Ask five people, and you’ll probably get five different answers. Even if all five are PMs. At its core, a PM is responsible for identifying a user or customer need, crafting a product vision to fulfill that need, prioritizing it based on business goals, and driving a team to make that product a reality. Some have described PMs as a CEO of their product, as a conductor of an orchestra, or as a janitor who does whatever dirty work falls through the cracks so your team doesn’t have to. All feel accurate to me, depending on the day.
So, how does writing make me a better PM?
Writing cultivates empathy for others, including our product’s users. Creative writing gets me into the head of characters and teaches me how they think and react to different situations. I learn to create characters with motives and beliefs that are different from mine, while still making them believable people (I hope). It takes empathy, which I’m learning is not simply feeling for another person, but going a level deeper and understanding their worldview and what makes them tick, even if it’s vastly different from my own. Learn to walk a mile in their shoes, as some say.
Good PMs should have empathy in spades. It’s not just a quality that makes for a more pleasant colleague, but it’s critical for the job. In product interviews, one of the key things hiring managers look for is someone who can identify a real problem, who the target users are, and how to design a product for them. One of the classic questions is, “How would you design an alarm clock for a blind person?” I often won’t be the target user for a product, but I need to know what their unique needs are.
Good writing drives extreme clarity. One common problem in large product teams is misalignment. I say X, you agree to Y, thinking I said Y. Come time to launch, we’re in a hot mess. This is my favorite comic on the topic, and it’s comedy value is entirely based on how easily we fail to communicate well:
Clear and crisp verbal communication is important, but writing has an extra level of permanence. PMs are often writing Product Requirements Documents, which are the foundation of what designers and engineers use to build new features. We detail out exactly what the feature needs to do, and how it should behave in various corner cases. Good writing sucks out ambiguity.
Writing is a muscle that can be built in all different forms. For instance, poetry is meant to evoke certain emotions, or provoke thought, sometimes intentionally with ambiguity. I can’t do that with a Product Requirements Document, but flexing the muscle of writing in a different form strengthens writing in all its forms. It’s more tools in the toolbox, so I can flex between purposefully ambiguous to extremely precise.
Writers are curious, which helps us ask better questions. Writers probably have the most questionable search history as a result of researching strange things for stories (e.g. “how to hide a murder weapon” – I’m a mystery novelist, not a criminal, I swear!). We also have questions that Google can’t answer, and that’s partly why we write. My first novel, The Vermilion Riddle, is motivated by a series of questions I wanted to explore through the characters and plot.
PMs need to be good question-askers. We don’t write the code for features, and capable engineers are more than able to develop their own project plans and general requirements for how something should work. A PM really adds value through asking the right questions. Ask your data scientist: How often do users use feature A, to inform whether we want to build feature B? Ask your designer: How will this design scale for the next 10 features we might want to add to this interface? Ask your engineer: If we want to build this functionality into our other apps, can we build it in a reusable way that cuts development time in half? I’m dependent on my partners for these answers, but asking the right questions is often what drives the team to make smarter decisions.
Good writers craft a compelling narrative for their product. I really admire my cross-functional partners at work. I admire how designers have a passion for pixel perfect UI that’s intuitive and attractive. I admire how engineers have a relentless drive to solve hard technical problems, whether it’s scaling a platform to support 1000x what it started with, or making a gnarly product requirement a reality.
What value does the PM bring, then? All the “fluffy” stuff?
The PM is responsible for the narrative: articulating the vision for a product, the scale of the problem we are solving, and the users we are building for. Even a product that is objectively impactful loses its power to inspire a team if it’s simply presented as a set of functional requirements or uncontextualized numbers. Think of the hilarious hashtag #ExplainAFilmPlotBadly: One of my favorite films and books, Lord of the Rings, is described as “Group spends 9 hours returning jewelry.” Just like no one would want to watch that movie, no cross-functional team or leadership wants to champion a product that doesn’t have a compelling narrative. We’re made for stories, and that’s what people will remember, even when it comes to building software products.
Photo by Luke Chesser on Unsplash.
Pen and Fire 