Principles of Product - the Importance of the Written Word PLUS Guest Posting Opportunities
As a Product Manager, I want to hone the craft of writing, so that I can excel in my role day to day
The ability to write is mission-critical to success as a product manager.
Amazon takes this to an extreme, centralizing its work culture around the writing of 6-page memos. To pursue any business idea, a 6-page narrative-based memo must be written outlining the details of the plan. This is not shared ahead of time. For meetings where the proposal is discussed, physical copies of the memo are printed. The first 20 minutes of said meeting are a “study hour” where everyone reads the prepared memo. A discussion then occurs.
Writing is fundamental to Amazon’s culture. If you struggle to write there - you will fail as a product manager. Most likely, you will be looking for a new job within the year.
While other companies may not be as extreme - the principle remains true. You will limit your career potential in Product Management if you cannot communicate effectively with the written word.
Let’s examine why.
Where the written word is essential
User Stories, Emails, and Memos represent the written holy trinity of Product Management.
These three deliverables are the foundation of all interactions for anyone of any importance in tech. What they share in common is that they are structured, writing deliverables that can be shared quickly and easily amongst critical stakeholders.
Early in your career, they are the primary means of any interaction with executive leadership.
In my first product role, I got on the radar of our CPO due to my having written the user story related to a feature a client was thirsting for. To get up to speed, that CPO read through all my confluence docs. It’s no coincidence that CPO began to acknowledge me by name more publicly at the next team meeting we both attended…
Executives are busy They have to narrow their focus to address only big problems at hand. As such, when a new problem comes across their plate, they LOVE to dig into any historical documentation available. That’s your opportunity to get ahead.
Each of the holy trinity of writing serves a unique business purpose. Knowing when and how to execute each deliverable is how you level up as a Product Manager.
User Stories
The user story is the backbone of all product work, as it is the centralized location for all background and details regards a new functionality.
From a narrative perspective, someone reading a user story should come away with:
The Pain Point of the User
Historical Background of what those users are doing today
Reasoning on how the new featured spec’d out will solve that pain point.
It’s a traditional 3 act story structure, utilized to take the reader through the journey of understanding why a piece of functionality needs to exist. There’s a reason “Story” is in the name.
In the day-to-day of product life, writing the first draft of a user story is the most creative act you will engage in. It’s where one is forced to think through all the details and ramifications of the issue at hand.
I need long, uninterrupted time to think, write, and re-write a user story. It takes me multiple drafts to get the narrative clean. This document will then structure my collaborations with, engineer, design, and product leadership around the User-Story.
Executed correctly, I share this thoughtful, well-written user story documentation with whoever I plan to meet with to discuss the issue. Before each sprint, I review the document with my engineers to give better context about the work we’re doing.
These documents go on to live beyond you as a Product Manager. After you leave the company, individuals trying to understand the functionality of the past will search and read the relevant user stories. I’ve dug through documentation sometimes a decade old to understand what the hell is happening with a product. Write your user stories with care.
Another phenomenon to be aware of is the more you write, the easier it is to write in greater volume. There is a competitive advantage to be had in churning out more user stories per week than your peers.
Emails
I know what you are thinking. Of course emails are important! They’re the lifeblood of business!
In particular for Product Managers, however, emails take on a more critical role.
They build consensus.
Anyone of any importance in tech is incredibly busy. That makes it a struggle to get them into one room to discuss important work on a tight timeline.
Despite this scheduling impossibility - they will flip a sh!t if completely left out of big decisions.
The solution to getting buy-in on important decisions with tight timelines is email.
You, as a PM, need to write short and direct emails. In them, summarize the big decision, the consequences, and a direct, unambiguous call for action. The email here plays double duty as a tool of communication and a paper trail.
Say a big wig executive decides to ignore the problem until after a decision has been made. Your only defense is to point to an email chain they CC’d on discussing the issue. We asked your opinion multiple times! Here’s where we did so.
Ideally, you head this off, and call out in subsequent messages when the deadline is, and who needs to contribute their input. I may call out specific names if I need their opinion to move forward. If it’s critical enough, I’ll nudge them to respond in a slack message. (This is the courteous approach. It’s how executives and leaders work with one another.)
Well-constructed emails are a tool to get stakeholders bought in quickly and decision made fast.
They must be concise. The body of the email should never be more than 2 paragraphs. If more words are needed, include a link to separate documentation that provides additional context.
A well-written email makes clear the actions required to mark an issue resolved. I bold the most important call to action to make life easier for the email recipients.
In short, a well-written email is
Short! No more than 2 paragraphs
Enough background to understand the decision needing to be made
Clear, singular call to action for the recipient of the emails.
Memo
A memo is an extended documentation for ideas that are too big to be an email but do not directly map to a product/functionality. My company Google Docs for such deliverables as its standard formatting has powerful access control functionality.
For product managers, a memo is a tool for either big asks, or new proposed non-software processes.
I recently wrote a robust memo to ask for a new Associate PM resource to be green-lit for my team. The document was an exercise of persuasive writing to get the money guys on board with my resource ask.
While meetings around such topics are good and fun - meetings are fleeting. People make promises they can more easily back out of or ignore. Key points are easily forgotten when new problems materialize.
A Memo, however, exists indefinitely. It’s easily shared. When it comes to asking for more budget - it has a funnel of bureaucratic leadership is must pass through. Instead of having to persuade everyone from scratch each time, a well-written memo gets all the important ideas ready for distribution at a moment's notice.
Memos shift in structure depending on the content. They broadly include:
The central thesis of the memo - what is the acute business pain point being addressed?
A proposal on new action for the business to take
Details on how the proposal would work in practice
Background information, and supporting data for whatever is being discussed
A breakout of all granular elements relevant to the discussion at hand.
An outline of what success looks like
Multiple options for the next steps, if applicable
To Write Well, Write More
The single best way to improve as a writer is to write more words.
Persuasive writing is born by word vomiting onto a blank page, deleting the bad, and keeping the good. Writing more often results in a higher output of quality sentences.
Writing about a topic also has the effect of structuring your thinking. The act of crafting ideas into words is an act of refinement.
Writing the Pivot to Product Newsletter has made me a better Product Manager.
I’ve written 50+ articles on Product Management. Each article serves to clarify my perspective and approach to the different elements of the role.
Many of the articles written are in direct response to challenges I’ve faced in my day to day. I often solve my problems by writing about them.
Heading into 2024 - I want to offer the opportunity to write for an audience. Pivot 2 Product going forward will officially accept proposals for Guest Posts.
This is your chance to get your writing in front of an audience of thousands of smart, focused product thinkers actively building the future.
Another benefit? You’ll get to collaborate directly with me, bowtiedwhitebelt.
We’re open-minded at P2P. The main criteria for an article - does it bring value to the audience? Feel free to get creative.
Click below to make a formal submission: