---

title: 'Pointers on writing the perfect PRD doc' publishedAt: '2021-10-14' summary: 'PRD or the Product Requirements Document is a living document that helps different stakeholders understand and align on the status and purpose of the product....' category: '#Product Management'

PRD or the Product Requirements Document is a living document that helps different stakeholders understand and align on the status and purpose of the product.

Good PMs keep the PRD up-to-date on a daily/weekly basis. A PRD is never complete. It evolves as the team iterates.

Four Core Sections in a PRD

1. Define the product vision and purpose
2. Describe the product features
3. Outline the release criterion
4. Identify risks/constraints and set a schedule

1. Define the product vision and purpose

• Discuss user problems not solutions

• Write the problem statement

• Try to quantify the impact. Add a goal/focus metric.

  • An example of a good problem statement looks like this:
    • “Repeat user orders have dropped by XX% in the last Y months. We see that logins from repeat users have also dropped at the same rate.
    • Based on the user study we did last week, we seem to believe that the current login flow is the main issue.”

• Identify the target demographic and user persona

• Identify the various use cases for the target demographic

• Focus on Why?, Who cares?, and So What?

2. Describe the product features

• List down high-level product objectives
• Map features to product objectives
• Provide as much detail as possible to avoid ambiguity
• Adding process diagrams mocks, and extra data/research
• Add happy and unhappy flows
  • Sample of a happy flow — “User clicks on submit. If the information is correct, redirect the user to the home page.”
  • Unhappy flow: “User clicks on submit. If the information is incorrect, show the relevant error message.”
• Add Non Functional requirements
  • Obscure requirements that are easy to miss
  • e.g.The response time for the backend call that checks the validity of the input should not exceed XXX milliseconds.
• Add wireframes and designs

3. Outline the acceptance and launch criterion

• Establish the criteria for an acceptable version of the product that can be released
• Think of this as a checklist. If even one, if the item is not checked the feature, cannot be shipped.
• Areas to outline release criteria:
  • Functionality: What are the absolute mandatory functions?
  • Usability: User stories that the release needs to fulfil.
    • Build a list of Business and Technical test cases
      • e.g: Business test case: “Click on submit button with the incorrect username.”
      • Acceptance criteria: “Clicking on the submit button with the incorrect username should show the relevant error message.”
  • Reliability: What is the max acceptable failure rate?
  • Performance: How fast it must be? Response times? etc.
  • Supportability: Is it testable, serviceable, installable, and configurable?

4.Identify risks/constraints and set a schedule

• Identify potential risks and constraints
• Build a rough timeline based on all the information
• Add a section highlighting Frequently Asked Questions
• Add a release plan highlighting activities and relevant stakeholders
  • Format for release plan: Item/Data/Owner
  • Examples:
    • Testing Done/8th October/PM
    • QA Approval/15th October/QA Manager

Sample PRD docs

Product Hunt’s PRD Doc

Redbus’s PRD doc for the “Add Insurance” feature

Done! 💪

References:

How to Write a Painless Product Requirements Document

Product Requirements Document (PRD): A Guide for Product Managers

How to write the perfect PRD (Product Requirements Document)