Writing PRDs and product requirements

8 min readOct 24, 2023

tl;dr — be clear about the problem you’re solving, users and use cases you’re targeting, and focus more on user needs wrt functionality.

Today’s goal is to share a better approach to writing PRDs and requirements.

I want to create products that make lives better. I’m listening to Night Changes by One Direction today.

What’s in a PRD?

So let’s bring this back to the goal: the goal of a PRD (aka product requirements document) is to help readers align on what the team should build and why. If this sounds familiar, it’s because I think that’s the purpose of the PM role, which I think is fitting since PRDs are one of the primary artifacts that PMs create.

It’s really important to remember that the PRD is just a vehicle for alignment. If your team can get aligned on the priorities, features, and work using just a digital backlog or a whiteboard with post-its, that’s perfectly fine too. In the traditional definition of a PRD, you’d have some business case for what you’re proposing, and then a list of “requirements” that the product must meet. A lot of PRDs will include many details around go-to-market, metrics, user and market research, risks & dependencies, as well as the user experience.

One thing to watch out for is what type of PRD you need. If you’re building a feature on top of an existing product, the level of detail and scope is significantly different than if you wrote the PRD for a top-level product. My advice: keep PRDs for products higher-level and focus on the opportunity and target users/use cases and high-level functionality; then link to mini-PRDs for complex features with more detailed requirements.

Remember, the PRD is just a vehicle for alignment. It’s something you write to have a clear narrative and the right amount of details so that your team understands what to build and why. In a similar way, a great story has a clear arc to it, and then you might have off-shoot side-stories that clarify parts of the world or other characters or certain events. You want to guide the reader so that they can understand, be excited by, and agree with the product or feature you envision, rather than get distracted by the side-stories.

What’s wrong with how we write PRDs today?

Let me know if you’ve run into any of these situations:

Every time your team makes a design/engineering/GTM/telemetry decision, you have to go back and update the PRD otherwise it becomes out of date.
Xfn partners end up in long comment threads debating specific details in the requirements, especially those that touch on engineering or design implementation.
The PRD gets so long that people start losing track of what’s going on and changing in them. Some people don’t even bother reading through the whole thing.

If this isn’t a problem for you, then you’re ahead of the game. :) Unfortunately, a lot of the PRDs that get written at tech companies end up being massive documents that quickly get out of date and are full of comment threads with people rabbit-holing on minutia.

Now, there’s technically nothing “wrong” about that. Having a highly comprehensive document with everything in it is perfectly reasonable if that works for your team and if it doesn’t create inefficiencies.

I felt like that wasn’t working for me, so I looked for a way to write PRDs and requirements so that they better stood the test of time, wouldn’t need updating so often, and were at the right level where we could agree on functionality without nitpicking about specifics.

A better way to write PRDs and requirements

I recommend splitting PRDs into two types: product proposals and feature proposals.

Here is the rough structure:

Problem/Opportunity
Exactly what it sounds like. Be as crisp and clear as possible on what user or business problem(s) you’re solving, and for product proposals, why this is a valuable opportunity for the team to pursue. Note: “User can’t use <my solution>” is not a problem statement. Problems are rarely a lack of <xyz feature/functionality>, instead look deeper into what issues are caused when that feature is missing.
Target users & use cases
Always focus on the user. This will help bring your proposal together in line with the go-to-market plans later, because ideally the way you built the product and the way you position it in the market should match. If you built the product targeting small business owners and their support use cases, then you should probably GTM with that same targeting. This also helps the team focus on prioritization. Make sure you’re on the same page about what users and use cases mean.
[optional] Current journeys/Landscape
This is about giving the reader context on what users are doing today, or for product proposals: how other products in the landscape are solving this problem. This often helps visualize why the problem is painful, or show what other solutions have been tried, which can be useful as a reference for your proposed solution. Usually I provide a quick summary, and then link to materials that can give more depth to it (e.g. a step-by-step flow showing how painful the current user journey is, or competitive analysis).
Proposed solution/Elevator pitch
Give a standard 2- or 3-liner elevator pitch for the proposed solution. Write it in plain english as much as possible so that an average reader could understand it. When writing for a product proposal, I also like to include the top 3 MVP value props that the product offers to users (helps focus on user value), and including a quick diagram of a proposed conceptual model for users (helps readers wrap their head around the product).
Goals/Measurable outcomes
Keep this short, literally 2–3 bullets, no more. Ideally these should be measurable outcomes in terms of what success or non-failure looks like.
MVP/Functional requirements
This could be a whole post in itself, but I highly recommend focusing on required functionality and save the rest for a linked doc in the appendix. Focus on the MVP, because if you go further than that, the list of requirements can go on forever and scare the team. What is the “min-viable” set of functionality needed so that your target users can adopt the product? If you’re focused on product-led growth, then you’ll need to factor in self-service education in there. Here’s some quick tidbits on writing requirements:
— DO focus on functionality: “First-time user must accept privacy policy to use the product.”
— DO include telemetry: “Product team can monitor and visualize user engagement.”
— DO link to appropriate UX or sketches. It’ll help the reader quickly visualize rough solutions or implementation, to understand how something could take shape.
— DO include priorities: “[P0] User can delete their account.” Make sure P0s are truly required for MVP adoption, P1s are high-value important additions for a min-delightful product, and P2s are nice-to-have.
— DO bucket requirements by use case or user journey. This may be controversial, but I’ve found that it really works. Anchor on the most important use case/journey you’d solve for first (see UX concepts), this helps you deliver a cohesive e2e experience and ties UXR together into your PRD. If this still gets too long, bucket into phases/milestones.
— DO consider all the critical user journeys (CUJs) for the user/object lifecycle. The easy part is thinking about how a user creates or uses something in your product. Don’t forget to also consider first-time experiences, how a user comes back and maintains/updates things, and how they eventually retire objects, or navigate large lists of them, or transition off the product.
— DON’T use more than 3 phases/milestones. By the time your team actually gets to the third phase/milestone, things will have changed, you’ll have learned new requirements. You’ll probably need a new doc anyway.
— DON’T include performance metrics: “Must have 99.99% uptime”, or “Page should load within 500ms” unless you have concrete evidence that your users/customers actually require this to adopt. Usually this is not truly the case, and is something you can improve on after the MVP.
— DON’T include design or technical details: “First-time user can see a welcome modal dialog with a blue ‘Continue’ button if there’s no entry in the database.”
— DON’T write a PRD if you don’t have clarity on user needs. Instead, write a strategy doc or “1-pager” that explains the opportunity you want to explore and the hypotheses you’re trying to prove, and go do UXR and prototyping. Writing a PRD requires you to know the user requirements, otherwise you’re just misleading your team.
Appendix (links to other docs)
Here you can link to other materials that people will ask for. This can include docs that document important product or design decisions. It can include more detailed UX, or more product specification. It can also include go-to-market details, proposed pricing strategy, a pre-mortem, a hypothetical press announcement, etc. I recommend putting these in the appendix because most of these don’t matter if you can’t get aligned on the problem and user needs, and whether the solution provides real value and addresses those needs.

On average, when I use this structure and push for brevity, my PRDs are able to sit ~6–8 pages. I think both full on product proposals and more detailed feature proposals can work with this structure.

What’s neat [IMO] is that most of the information in the PRD structure should stand the test of time and require minimal updating as you go through design & execution, with the exception of the priorities and the appendix. User problems, use cases, landscape, goals, and functional requirements (which should map to user needs) — if written correctly, they don’t change on a whim, although some things may get reprioritized.

Here are links to the templates:
— Product PRD Template
— Feature PRD Template

Do you have real-life examples of this?

Of course. Here are some actual examples (but removed sensitive information), that you can reference for how this works. I won’t say they’re perfect, but you can see them in action. Again, ultimately they helped my team and I align on WHAT to build and WHY we’re doing it, so that was enough.

Note: I replaced real project names and email addresses with <OurApp> and <email> respectively. I picked these since they give a diverse range in complexity and scope.

If you have other great examples you liked, please share along! I’m always interested in refining and honing the PM craft. :) Hopefully some of this may be helpful so that we PMs can spend more time building products and less time writing documents.