Writing a PRD
Read on my website / Read time: 3 minutes
If you're like me, you're a busy person.
That's why I like simple approaches.
When I had to learn how to write a Product Requirements Document (PRD), I downloaded all these complicated, detailed templates that had all these "fill in the blank" sections that were meant to be helpful, but only ended up overwhelming me.
And the worst part was after spending days writing it, no one would read it!
However, as one product manager recently wrote to me:
"As you've said, starting with some long PRD often makes no sense. However, there is a need to provide some form of requirements documentation. What do you do in these cases?"
The real problem isn't really so much the right template, filling out all the sections, or the size of the document. Ultimately what matters is a joint understanding among Product Management, Design, and Engineering of the opportunity we're pursuing, what's needed to solve for it, and what we'll get if we do.
What we want to do is bring them along. If we make our R&D friends a part of the process, then, even if the document gets bigger over time, no one will complain.
It's harder to absorb a big document that's been thumped on your desk than one that you've been a part of creating.
How I create PRDs now:
So, years ago, I abandoned all the bloated templates and "best practices". Here's how I do it now:
1. Crack open your favorite documentation app - Word, PPT, G-Doc, Notion, Jira, some PM tool, whatever.
2. Give it a title. Any will suffice for now. You can always change it later.
3. Write who the target customer is.
Pro tip for enterprise B2B: State the target buyer and the target user. E.g., in healthcare, it may be ">$1B NPR hospital systems" and "Director of <department>".
4. Write (a) what their problem is or what job they're trying to accomplish, (b) difficulties they're facing, and (c) why it's important for them to solve it or get the job done.
Even if you don't have perfect info, write down your hypothesis, assumptions, and any questions you have. You'll test these out as your next step.
Link any references, if you have them - analysis, research, customer interview recordings, etc. If you don't yet, don't sweat it. You can add them over time.
5. Write down any initial solution ideas.
Don't need technical or even functional level reqs. Just jot down some initial ideas you may have or shared by others. Even a crude napkin style sketch of a screen or workflow. Note any assumptions you're making.
If you don't have any solution ideas just yet, it's ok, leave blank and come back to it later.
6. Write down your thoughts on the value to the business for doing this.
Fulfill a strategy? Move a metric? Realize an OKR? Retain a key customer account? Provide some other form of ROI?
f you don't know for sure, write down your assumptions and hypothesis. Even if you don't have concrete numbers just yet. You'll flesh this out over time.
7. Share with trusted colleagues for additional input.
This simple act makes them feel a part of the process, allows you to benefit from others' wisdom, fosters collaboration, builds supporters, and creates trust.
And there you go. You've got the beginnings of a decent PRD. Easy peasy.
It could be half a page, 1 page, or 5 pages at this point. The length isn't important. You can add fancy fonts and formatting later, if that's really necessary.
From here, you'll go out and get your questions answered, test your assumptions, and flesh out the requirements iteratively as you learn more. This could be everything from further customer discovery, additional research and analysis, financial modeling, etc. As you learn more, share your learnings and updated perspective, update the doc, and test any new assumptions and questions. Repeat until you and the team feel like you've got enough to go on.
Naturally, even starting the PRD is dependent on having some customer insight in the first place - you talked to a customer, analyzed some data, or got a request from someone, and had some inspiration. Excellent. Crack open your favorite tool, take 20-30 mins, get it out of your head and on to digital paper. And you're off to the races.
Product Management is only as complicated as we make it.
