The Questions I Ask Before Writing a PRD
The questions I use to clarify a product problem, test assumptions, and prepare a PRD before writing requirements.
Before I write a PRD, I try to get clear on a few questions. If I can't answer them, those gaps become my task list.
What problem are we solving?
It's easy to start with the requested feature instead of the problem behind it and the KPI we expect it to affect.
Someone asks for a new field, button, report, or workflow. The request may be reasonable, but I still want to know what they're trying to accomplish. There may be another way to solve it. The request may address only one part of the problem, or the business impact may not be large enough to warrant the work.
I think a PRD should be detailed enough to get the team's input on the proposed solution. It shouldn't tell the team, "This is how it needs to be done."
Who experiences the problem?
"The business" or "the customer" is too broad. I need to be specific.
Which person or team runs into the problem? What are they doing when it happens? How often does it occur? What do they do today to work around it?
Then I get to the questions that help determine whether this is the right thing to take on.
If we do nothing, will the negative impact grow? If we act, what positive impact could we create? Internally, that might mean time saved, costs reduced, or revenue gained. Externally, it might mean a higher NPS or better CVR.
What evidence do we have?
Evidence doesn't have to mean formal research. It could come from customer conversations, support requests, usage data, repeated workarounds, or observations from the people doing the work. I'm a fan of Tango for documenting internal processes and workarounds.
I try to separate what we know from what we assume. I like making the assumptions visible in the PRD. That gives us something to validate and makes it easier to understand why we made a decision.
What decision does this document need to support?
Some PRDs try to capture everything. I find it more useful to decide what conversation the PRD needs to create.
Are we deciding whether the problem is worth solving? Are we comparing approaches? Are we trying to understand scope? Are we ready for engineering to begin?
If I'm personally unclear about the decision, the meeting around the PRD will probably be unclear too.
What could make this unsuccessful?
Shipping isn't the same as solving the problem.
A feature can work as designed and still fail because people don't understand it, the surrounding workflow doesn't change, or we misunderstood the original problem.
Even a solution that makes it to production and is exactly "what the doctor ordered" doesn't always move the metrics. If it isn't moving them, we may have misunderstood the actual problem. It's worth asking both, "What if this doesn't land?" and "What could happen or change that would keep it from landing?"
What am I missing?
I've started spending more time refining how I prepare to write a PRD.
Sometimes I give ChatGPT the problem, the audience, the constraints, and my current approach. Then I ask it to challenge my assumptions, suggest who I should talk to, or give me general tips.
Most responses feel about 60% there. The other 40% is bad, irrelevant, or outdated. Still, I usually get at least one question I hadn't considered, and that can improve the PRD or prepare me for the meeting around it.
It feels like a decent sounding board for ideas.
What am I missing in my PRD prep process?
I find that a PRD becomes easier to write once these questions have answers. When they don't, I probably need to do more discovery, not more writing.