Your stakeholders don't read your PRDs

You wrote a thorough PRD. The problem is clearly stated, the impact is quantified, the approach is there. And still, someone asks you a question the doc already answers. Or a decision gets made as if the doc doesn’t exist.

It’s tempting to be annoyed. Why won’t people just read the doc?

But that framing hides the real issue. You’re treating “stakeholders” as one audience, and you’re expecting the PRD to do a job it was never going to do. Once you separate out who you actually mean, the complaint mostly falls apart.

The word gets used as if it describes one group of people who all owe your document the same attention. They don’t.

There are the people who ask you to add to or change your product. They might read a doc if it validates their request. They probably won’t read docs for other people’s requests.

There’s your senior product line - your line manager, group PM, head of product, CPO. These are the people where you need to defend your roadmap and show your workings.

There are the senior non-product people - the CEO and others - who care what you’re doing but have little time for the detail.

There are adjacent roles - your head of engineering, other PMs of teams connected to yours, client contacts.

And there’s your team. You could call them stakeholders, but they’re really the primary consumers of the doc.

Each of these groups has a different relationship with your PRD. Lumping them together is what makes “nobody reads it” feel true. Pull them apart and you can see who needs what.

I learned this quickly: clients probably won’t see your PRDs. They aren’t really the audience, and you shouldn’t expect to send a PRD to them, verbatim.

An external stakeholder isn’t privy to other people’s problems articulated as PRDs. Your internal prioritisation, the bets you’re weighing against each other, the trade-offs - that’s not their view to have. What a client needs from you is a version shaped for them, not a link to an internal working document.

So if you’re frustrated that a client “didn’t read the doc”, the doc was never for them in the first place.

For your team, the PRD actually is the thing they read - so this is where the writing has to be crisp.

They need a clear description of the problem. They need to see why it matters, backed by impact and metrics. And they need clear steps for where to focus their efforts on tackling it.

But your team don’t just receive the doc. They contribute to it. They can see it before it’s fully written - perhaps to help get stats, but especially to flesh out the technical approach. You might make a bet based on analysis alone: you know the problem is worth solving and you know it’s feasible, but you don’t yet know how it’ll be solved. So the PRD can be a work in progress. It doesn’t have to arrive finished to be useful.

Your line manager, GPM, head of product or whoever will want to see your workings. You need to be able to back up not only what the problem is, but why you decided to take a bet on it - and whether it landed. It might not. That’s the job too.

But the more senior you are, and honestly the more people come to trust you in your role, the more the guardrails come off. People trust you to do your thing. They can always read up on what you’re doing. They just aren’t going to read every PRD.

Your PRD is a detailed doc. What the non-product senior people need is an exec summary.

Put it at the top. This is what you want them to read if they have ten seconds and just want to know what it is you’re doing. They might read on. They might not.

More often, they’ll just ask you - in a meeting or a call, or unprompted, in a quick DM. They aren’t going to accept a link to a PRD and being told to go and read it. So even when the answer is sitting in the document, you have to be able to state it on the spot. Sometimes that means pretty much repeating what’s in the doc, out loud. Sometimes it means a slightly tailored answer that directly addresses what they’re asking.

The discipline underneath all of this: know your problems. Learn them. Don’t fall back on “go read the doc”.

If someone asks what a problem is and why you’re taking it on, you should be able to answer without reaching for anything. That’s what earns trust, and it’s what keeps people bought in.

But know your limits too. You should be able to summarise what a problem is about and how it’s going from memory. You don’t have to hold every number in your head. It’s fine to say “let me check the doc” to get the exact metrics, or to see how the build is progressing, and then read it back to the person asking. Knowing where the detail lives is different from not knowing your own work.

The PRD still matters. It’s your workings, your evidence, the record of the bet and whether it paid off. But writing it is where the work starts, not where it ends.

As annoying as it might seem that people won’t just read the doc, your senior stakeholders don’t have time.

It’s not their job to read your docs.

It’s up to you to rephrase, repeat and reword your problems in any way possible to get people on board, and to keep sharing what you’re doing and why.

That’s your job.

Product Notes is free and lands every week. Subscribe to get it in your inbox.