Why Obsessive Documentation is Key to Being a Great Product Manager

To be a great PM, you need technical prowess, deep customer context, and enough creativity and discipline to bring a new product idea to life.

But the highest-leverage skill that a product manager can develop has nothing to do with programming or design—it's the ability to write well.

As a PM, the main bottleneck in your effectiveness is how well you can communicate your thinking to the rest of your team.

Your job isn't to put out fires, micromanage every aspect of your product's development, or run stand-ups. Your job, as Ben Horowitz of Andreessen Horowitz puts it in “Good Product Manager/Bad Product Manager,” is to take the hard questions at the heart of your project and think through them in an exhaustive fashion, and then crisply and cleanly communicate your thinking to everyone else on your team. And for articulated, rigorous thinking, there is no better medium than words.

Written communication to engineering is superior because it is more consistent across an entire product team, it is more lasting, it raises accountability. —Ben Horowitz

Writing is key across every big product area that a PM has responsibility over at your typical startup:

• Vision: The act of explaining the “why” behind a project in written form forces product managers to make the hard decisions early and gives the rest of the team a clear North Star to orient their efforts around.
• Planning: Breaking down that vision into clear, well-articulated stories, goals, and sprints makes projects achievable and keeps them aligned with customer needs.
• Execution: PMs who can communicate in written form quickly and efficiently with designers, engineers, and others are the ones who most ably clear roadblocks, resolve disputes, and shepherd their ideas to completion.

In general, the better your ability to communicate your thinking in words as a product manager, the more your thinking will be accessible to others. That means less time and energy spent course-correcting or explaining yourself, and more time spent working on problems that matter.

A narrative PRD means a more complete product vision

Good product managers think through every aspect of their product and its context when they start a new project. They find out what kind of customers would want the company's product, and why. They figure out what the other companies in a space are doing and how they might do it better. When they don't know something, they seek information, and they test their assumptions and theories against that information.

Great PMs use the above to tell a story about the customer and their needs that galvanizes everyone on the product team to work toward the same cohesive goal.

The classic piece of PM documentation is the product requirements document (PRD). The PRD is there to set out exactly what a product should do for the end user—the “job” that it's going to be “hired” to perform:

• Product vision: A top-level summary. This explains the overarching vision and answers these questions — Who is the product for? Why are we building it? and What does it do?
• Points of contact: The product manager's information, as well as that of any relevant stakeholders.
• Resources: Any market research, competitor analysis, prototypes, and mock-ups the team can reference as they move forward with building the product.
• Timeline & Dependencies: A breakdown of how long it will take to complete the project, including specific deliverables. This will illustrate the time and work needed to take a product from idea to completion.
• Goals & success metrics: The specific problem a product will solve, and how the team can measure its success.
• Use cases: Specific examples of how the product will solve a problem for the customer—“As a user/customer, I want…”

PRDs have a tendency to spiral out of control and become massive, constantly-in-need-of-maintenance documents.

As a PM, your PRD doesn't need to be long. It does need to explain what your product is supposed to help people do; make crucial architectural decisions early on; and clarify—for everyone on the team—what their role is in making it happen.

In the excerpt below, from Bolt's PRD, close attention is paid to describing the exact market need the product is responding to—not “cheaper small-business staffing optimization” or “foot-traffic analytics,” but:

Small and medium business owners can optimize staffing and marketing costs if they can predict foot traffic and corresponding sales conversions. Currently-available tracking solutions are expensive and difficult to install.

Within a couple of sentences, this tells you who needs the product, why they need it, and what main opportunity Bolt is interested in. Crucially, it does not prescribe exactly how they should seize that opportunity.

Writing long-form keeps you honest. It makes you grapple with logical inconsistencies earlier and can uncover issues you hadn't seen while just mulling things over in your head. It also helps ensure that you think cohesively about who your customer is and what they actually need your product for, rather than just putting together a list of features you think should be included.

As Jeff Bezos says, “There is no way to write a six-page, narratively structured memo and not have clear thinking.”

And clear thinking does not always mean tidy, objective goals. Writing articulately about the vision behind your product means setting expectations for how the end result will feel and be used, not exactly what it will look like or how it'll work. A great example of this is the original requirements doc/outline behind Product Hunt.

In the intro, Ryan Hoover doesn't prescribe a format or look for his site—instead, he focuses on defining the sensibility that he wants Product Hunt to have:

It would be easy to say you wanted to build a Digg for product people or that you wanted to build a rankings-based aggregator for new products—and these would be more precise definitions of the product—but those descriptions don't get across the important thing behind the idea of Product Hunt: most importantly, the fact that it is, above all, a community.

You could build a thousand different types of products that would accomplish Product Hunt's stated goals, and they might all look different. If they followed this document, however, they would all achieve the right end result.

A good test of a product manager is for someone outside the product team to ask 5 different people in engineering, QA, and doc what their product is supposed to do and why and get the same answer. —Ben Horowitz and David Weiden, Good Product Manager/Bad Product Manager

Context-driven user stories make sure customer needs are met

One of the most important—if not the most important—job for a product manager is to define clearly and in as much detail as is necessary what the product should do, how fast it should be, etc… Written communication is superior because it is more consistent across an entire product team, it is more lasting, it raises accountability. —Ben Horowitz and David Weiden, Good Product Manager/Bad Product Manager

Bringing a product to life isn't just building a roadmap and then cranking out a bunch of features. As a PM, your highest-leverage activity is thinking about exactly what each feature needs to help your customer accomplish and then distilling that into the clearest possible form for your team.

It may take longer to write an airtight user story that sets your delivery team up for success—one that more or less makes it impossible for them to build the wrong thing—but you save an exponentially greater amount of time in the execution phase. PMs who skimp on this save time in the short term but pay it back later.

The problem is that “Build a feature that does x” is simply a lossy medium of communication because it doesn't account for the customer context behind the request.

When you simply ask your delivery team to build a list of features, you're inevitably going to get slippage between what you envision and what they envision.

Obsessive documentation is what will make sure your team is building the product a customer needs.

This is why the user story is such a common tool among product managers. Instead of simply mapping out the functionalities a new feature needs, you organize everything by user need:

As a x (persona), I want to y (action), so that z (result)

These kinds of narrative feature requests don't prescribe a form. They keep the work your team is doing in line with the larger vision.* *They embed the user's need in the task itself, so when the delivery team is done building the feature, they have an easy way to check whether or not it's accomplishing what it's supposed to accomplish.

This gives everyone—engineers, salespeople, marketers, and customer support—immediate understanding of what truly needs to be built.

But even the simple user story can benefit from better, deeper articulation.

The user story vs. the job story, from Intercom.

Intercom's concept of the “job story” is a more detailed and more context-driven implementation of the user story. Instead of tracking who wants to do a particular action and why, the job story asks you to track:

• the situation someone is in when they do a particular action,
• their motivation for doing that action, and
• what they expect to see or get when they're done.

The job story is intended, in part, to solve a problem with the way user stories are structured: the difficulty of disentangling your idea of the user from your implementation of the feature. If a user story-driven feature doesn't get used or it tests poorly, it's hard to know if it was your implementation or your understanding of your user's desired action that was the culprit. It's possible that the action you thought was important wasn't really important at all.

When you organize by job story, on the other hand, you produce a more context-rich task that takes into account only the factors crucial for getting the right end result: what someone is doing, what they want to be able to do, and what the outcome should look like.

Written communication keeps people accountable and projects moving

A bad product manager hoards their knowledge and needs to take time explaining their decisions to the team. This kills product momentum—individuals end up spending their time talking to the PM instead of getting work done, and the PM spends all of their time fighting fires rather than doing the work that matters.

A core piece of any great PM's job is to ensure that every member of their team has ongoing, unfettered access to a plethora of information about the product they're building: FAQs, marketing collateral, style guides, customer interviews, market research, presentations, and so on.

When your engineers and designers and marketers have both clear deadlines and full access to all of the data and information they need to complete their jobs, your projects can move along at a much faster pace.

When a product manager is obsessive about internal documentation, and maintains this information on a regular basis, it also keeps the whole team accountable.

The product manager is accountable to the VP or the CEO because their vision of the product and their ideas about how it should be executed are written down in public view.

The engineering, design, and other team leads are accountable because the vision for their team's contribution to the project is similarly outlined.

Everyone knows the standards they and others are expected to meet, increasing team knowledge and keeping everyone headed in the right direction.

Lastly, as projects progress, new information always creates the need to change the plan. Whether it's from market research, customer interviews, or changing business goals, being able to illustrate the reasoning behind any updates to the PRD helps ensure that the team understands the “why” behind these changes.

A great PM's job is as much about updating the PRD as it is about creating the initial version—Ben Horowitz advises PMs to make changes to theirs on a daily or, at minimum, a weekly basis. As teams come with new questions, competitors change their approach, or technical obstacles crop up, you need to account for these in the PRD and ensure that the state of that “living document” doesn't lag behind reality. When a PRD begins to lag behind, team members stop taking it seriously and are less likely to consult it the next time they have a question.

Writing is your product team's secret sauce

All teams have to reckon with the problem of managing information, but product teams face a special type of challenge when it comes to managing their collective understanding of their task.

Products live and die on their cohesiveness. It's not assembling widgets—it's about many different units orchestrating the delivery of one united customer experience.

Writing your plans and thoughts out—and being meticulous about what you say and how you say it—is the most powerful lever that you have as a PM for making sure that a cohesive experience is what your product delivers when it's done.