Four tips for product managers to write better product requirement documents (PRDs)

Product requirement documents (PRDs) are important, but there are certain tips and tricks to ensure they reach maximum value!

What are PRDs?

Tech documents aren’t always fun to write — whether it’s technical documentation, pull requests, release notes, technical specifications (known in product as “specs”), and of course, PRDs. People can get various terms that describe tech documents mixed up, and begin using words like “requirement docs” interchangeably without realization of potential differentiation. For example, “spec” (what my team at Microsoft called them) was used as an umbrella term that could have been a PRD, but also could have been a more technical/architectural document owned by an engineer rather than a product manager.

PRDs — for those unaware — are the standard document that PMs draft up for their engineering and/or cross-functional teams to understand the what, why, and how for a certain feature idea. Normally, the format follows something similar to this:

1. Introduction

2. Problem

3. Use Cases & Pain Points

4. Market/Customers

5. Solutions(s) & Trade-offs

6. Assumptions & Dependencies

It seems clear to me that PMs own this responsibility of writing solid documents that track key problems, use cases, solutions, and technical trade-offs. But on the flip side, product managers risk being scoffed at for writing what may seem to be “useless” requirement documents that are all theory and serve no practical support in any actual “building.”

If you’re a PM, you may have encountered situations where you wrote a strong PRD, but once you handed it over to your engineering peers, it was scrolled over at best, and visits to your page drop off after the first day. So what can we do as PMs to write stronger PRDs and deliver more value to our engineering counterparts (and thus to the product)?

Here are four tips/suggestions on managing PRDs to increase their value for your cross-functional & engineering teams!

1. Adapt your requirement documents to fit your team’s process or system.

It’s not always the right thing to force your engineering team to adopt your style of requirement documents for sake of product development. Instead, it can be wise to adapt your docs to your team’s system. Follow the best way your team can work efficiently. For example, I write “epics” for my team instead of typical requirement docs that outline everything for a new feature. Epics are loosely known as a large body of work that can be broken down into smaller tasks or user stories.

While these higher-level epics define the “what” and the “why,” the engineers break them down into tasks (also known as user stories) that define the “how.”

In other words, I’m responsible for writing documents that describe an introduction to the problem, the user persona who’s impacted, and what the solution should look like from a product perspective. One example could be a new machine learning (ML) sentiment analysis model that could draw conclusions to user feedback that would otherwise take hours to analyze. In my epic, I would introduce the problem first and the context/background behind it. Then, I would state who the market is (in this case, the target market are other internal product managers who need to analyze user feedback). And finally, I would go into a solution (or a list of solutions with trade-offs) and describe what the product ROI (return on investment) would be, which justifies why we should build it.

Tailor for your own team, but make it fit your team’s system. This also introduces my next suggestion.

2. Think about who will read your document before going too deep.

There’s a certain nuance to this topic: often times, PMs will spend too long writing a document (important or not) when only one or two people end up reading it, or they’ve written for the wrong audience.

I’ve read many other requirement docs that go into extensive detail about the mission, vision, ROI, use cases, and technical solutions, but at the end of the day, if not everyone is aligned, then your time could’ve been better allocated to other activities, such as tackling execution work.

If you’re heavily engaged with your team, there’s a higher chance people will read your document(s). But if you encounter one of the following:

a) Your team is more driven by engineering leadership instead of product.

b) You’re simply not as engaged with your engineers.

c) Your engineers don’t hold trust in your product/technical ability.

Then obviously you’ll have to find alternative ways to write your documents. In general, people should take PRDs seriously; it’s good practice for most companies trying to become more product-focused. However, PMs still have to think about their audience — if you know your document will only reach one or two eyeballs, then keep it tailored and less general. If you know many will read it, then it’s safer to keep your wording concise and to the point. If you know no one may read it, then try to find other ways to contribute, such as writing shortened PRDs within an engineer’s ticket on a scrum/kanban board instead.

As the saying goes — write smart, not hard.

3. Ask your team for feedback on documents where possible.

Especially if you’re a relatively new PM in your team — it’s vital to communicate to everyone that you need feedback in order to tailor your documents appropriately.

Everyone has different expectations and requirements. Being a strong PM means understanding what your engineers think of your work, and making adjustments where necessary. Demonstrate open-mindedness by being receptive to critical feedback, and adapt or apply the necessary improvements where you can. It earns your team’s trust better that way too.

Feedback to your writing and strategy is how you as a PM will grow and learn, and thus your product itself will improve.

4. Prioritize your relationship with the engineering manager first over writing the perfect document.

I can’t stress this enough, but before I explain, let me establish the broader theme: product management is 90% stakeholder management. I’m sure anyone who’s held the position will agree.

Even companies with strong product cultures will suffer from this — it’s natural and expected. PMs need to manage the expectations of every stakeholder they work with, both internal and external. The engineering manager or director whom they work closely with is one of, if not the most, important people to prioritize a strong relationship with. If you had to choose between spending more time doing work that helped your engineering manager vs. writing the perfect PRD (assuming only a select few would read it), then I’d vouch to do the former. Your engineering manager’s time is incredibly precious — arguably more than your own.

There are many nuanced moments where if the PM and engineering manager don’t align, then everything breaks down. A PM can spend an entire day writing the perfect PRD for a new million dollar idea, but if the engineering manager doesn’t support or trust them, then that PRD is like a new shiny yet empty boat — fancy but with no one to sail it.

Establish a good relationship with your engineering manger by respecting their time, considering engineering trade-offs, showing your product logic, and of course, demonstrating your willingness to learn and admit mistakes.

About Me

My name is Kasey, AKA J.X. Fu (pen name). I’m passionate about writing, technology, AI, gaming, and storytelling 😁.

Follow me on Medium for more passion, product, gaming, productivity, and job-hunting tips! Check out my website and my Linktree, and add me on LinkedIn or Twitter, telling me you saw my articles!