PRDs (Product Requirements Documents) are the life-blood of many Product Managers and we are often judged by the quality of these important artifacts. Unfortunately, there is also a wide variation in how PMs approach writing them based on available time, subject matter expertise, style, and even written communication skills. For example, some PRDs are clear and easy-to-follow while others are a confusing mess. I've written well over 180 PRDs during my PM career and I’d be happy to share some tips that I’ve learned over the years that can help you write better PRDs, which will ultimately benefit your products and your users.
General PRD Writing Tips
Don’t make grand assumptions about your audience. Remember, your PRD’s audience could be Engineers, UX, Salespeople, stakeholders from other job functions like lawyers, and even other PMs who may have less context on the underlying domain or business challenge. Therefore, always provide detailed context/background and avoid jargon unless it's absolutely necessary to get your point(s) across.
A picture is worth way more than 1000 words. Whenever possible, use mock ups or diagrams to illustrate complex concepts or abstract ideas in your PRDs. This is critical because not everyone interprets information the same way you do and visualizations can describe objects, scenarios, and ideas much faster than mere words.
Use tables to organize information whenever possible. Besides being able to help structure critical information, tables are really useful in breaking up dense text, which can make it easier for the reader to focus on the most important details.
Pay attention to length: Let’s face it, most Engineers (and stakeholders in general) don’t like reading PRDs and this issue is exacerbated whenever a reviewer or collaborator is faced with reading a very long one. Therefore, you should try to keep your PRDs under a certain size. For example, PRDs for smaller and/or simpler features should be no more than 3-8 pages while PRDs for larger and more complex features should be capped at 10-18 pages. If your product or feature is unusually large and/or complex, try breaking up the PRD into discrete parts / documents (akin to chapters in a book) to make it easier to read and follow. Creating an "uber PRD" can sometimes give many disparate requirements a sense of cohesion provided you are able to keep the different documents or sections updated as changes are made. Finally, avoid adding unnecessary content at all costs. You’re writing a PRD, not a term paper and you don't get bonus points for adding filler. Documenting your requirements as succinctly as possible will help keep your PRDs a reasonable length.
Expect and embrace feedback. There will be times when writing a PRD feels like defending a PhD dissertation. Come prepared to justify your statements and be willing to take feedback and input gracefully. I’ve found that the best PRDs are actively discussed and debated during their gestation.
General Suggestions for PRD Structure and Organization
The following are suggestions for how to structure your PRDs that I have used. Feel free to include these elements when and where they make sense:
Background and business rationale: This is the justification section of the PRD. Always write a few paragraphs on the business or technical problem to provide important background context on why you're proposing the feature or product being defined. For example, what business issues or pain points are you trying to solve with your product or feature being proposed? As part of this section, use data to support your statements. For example, link to surveys, user / industry research, analysis, etc. This will add greater credibility to your PRD and psychologically, doing this will help align your stakeholders and reviewers to collaborate on finding the optimal solution to the problem(s) your PRD is trying to solve rather than questioning its purpose.
Glossary: This section is optional but it's useful to define key concepts and vocabulary as needed, which can be helpful if the area is deeply technical or assumes a lot of familiarity with domain specific verbiage.
Goals / non-goals: This section outlines the ultimate objective of the PRD. It should be documented as bullets that address strategic or tactical objectives and to head off scope concerns, etc. For example, “Goal: To make CRMs great again!”, “Non-goal: trying to replace product X with product Y.”
Document your Use Cases: Make sure you capture the key use cases that your PRD needs to address. Clearly indicate any assumptions you may make. At best, you capture a key requirement, at worst, they will be refuted by someone more knowledgeable. Be sure to include sections for different user journeys that state specific use cases followed by succinct bullets. And, where possible, leverage conceptual mocks and/or diagrams to help your stakeholders see what you mean visually.
Make your priorities clear: Often, Engineering can’t do everything you ideally want to accomplish in your PRD — at least not at first. Therefore, use priorities if there are many distinct or competing requirements and rank them by their criticality: For example, P0 for “must have”, P1 for “should have”, and P2 for “nice-to-have” items.
Leverage phasing: For products or features that are large and/or expected to have multiple generations, try to break up your requirements and the expected deliverables into discrete phases. For example, “Phase I” might be your MVP, “Phase II” is more robust and polished, and so on. Phasing your deliverables can go hand-in-hand with prioritization. Often, your most important requirements would be captured in your MVP, so your product supports the most critical features. This also helps you demonstrate to your stakeholders and customers that you will be delivering business value over time.
Avoid committing to exact dates: For many reasons, it can be extremely difficult to predict delivery dates for features — especially if your Engineering team has yet to scope them. Never, ever promise exact dates in your PRDs to better manage stakeholder expectations. Instead, try putting in non-specific dates on quarterly or yearly boundaries (ETA: Q2 2025, ETA: 1H 2026), so you and your team have some buffer for issues that will invariably come up during the development cycle.
Document potential dependencies: Use this section to capture features that may have some reliance on other teams, upstream services, or even pending company policies. It is important to flag these dependencies and identify potential blockers to better manage stakeholder expectations around timelines.
Document any special considerations and risks: Some products or features will need to address specific security, privacy, compliance, and/or legal concerns. Therefore, you should make sure you capture these items in your PRD to help ensure you can mitigate any of the potential risks or at the very least, have flagged them.
Capture UX workflows: It can be very helpful to illustrate different user workflows if the feature or product is user-facing. This is where diagrams and mock ups of various levels of fidelity can be really helpful.
Support accessibility: If the product or feature is user-facing, make sure you treat accessibility as a first-class citizen since many industries and markets now mandate ay11 compliance. Not doing this is bad for users and can open your product and/or company to potential liability.
Pose critical technical and/or implementation questions: Early drafts of PRDs may not have clear requirements for all functionality due to knowledge gaps. Therefore, it's completely reasonable to include list questions for reviewers and stakeholders alike to gather the necessary information. For example, asking direct questions to your Engineering team about technical limitations, lawyers about regulatory or compliance issues, etc.
Define your success metrics: It’s great to develop a new product or feature, but how do you measure its success or justify the ROI involved in building it? To that end, you should establish some metrics to measure your feature’s impact. In the vast majority of cases, this can be a list of items that describes what you’ll be measuring and why they'll be useful in gauging your progress and success.
Document your PRD changes: Change logs can be useful if your PRD is frequently updated. Be sure to include dates and 1-2 sentence summaries of what’s new or changed along with who made the changes or added the new content.
Stakeholder approvals: Make sure you have a place to capture reviewer and/or stakeholder sign offs to ensure there’s overall alignment on the PRD’s requirements. This creates a documented trail of team and/or organizational buy-in should someone question the specific requirements or scope later on.
