JUSTANOTHERPM

The only email you need to read to become a better product manager

Every week, I spend 50+ hours researching an important product management topic.

I summarize the learning into a practical guide.

I share it in this newsletter.

    No spam. Unsubscribe any time.

    How to create comprehensive product requirement docs
    3 min read

    How to create comprehensive product requirement docs

    In the first article in this two-part series on PRDs, I answered the two questions: "What is a PRD" and "Why is it important?"

    In this article, I share a thorough guide to help you create comprehensive PRDs.

    The following list covers different sections that you should include in your PRD:

    The Purpose or Business Context or Problem Statement.

    As important as it is, this section is taken-for-granted and usually overlooked. One of the most important reasons to include this section is to ensure that every reader knows the rationale for the feature. A few things that I include in this section:

    • Data and Research. This could be user research or data that helped me decide this feature is worth building.
    • Impact on revenue (or other business-critical metrics).
    • Links to other documents, research, announcements. I link to any other evidence or investigation that helped me decide in favour of this feature.
    • Sample: "Repeat user logins have dropped in the last two months. Attached user research shows that the drop could be due to the current login flow."

    The User Persona.

    Most products have multiple types of users (aka user personas.) Be sure to specify the user persona(s) that you are focusing on for this feature. I keep this section simple and include a basic description of the persona. I also refer to historic PRDs and talk to other PMs in the team to understand the right amount of detail to include in this section.

    Functional Requirements.

    • Always cover the entire user flow, not a part of it, in this section.
    • If you are new to creating PRDs for your team, be as detailed as possible. If you have been writing PRDs for some time, you should already know the level of detail that works best. Use this knowledge to decide the right level of detail.
    • Every requirement should be 100% unambiguous. Do not leave anything to interpretation. Include diagrams and high fidelity mocks, wherever applicable. Think of all the scenarios the user will encounter while interacting with the new feature. Add details for each scenario.
    • Always include all the "happy" and "unhappy" flows. 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."

    Non Functional Requirements (NFR).

    These are obscure requirements that are easy to miss, especially if you are unfamiliar with the product or the user. An NFR for a login flow could be: "The response time for the backend call that checks the validity of the input should not exceed one second."

    Testing Plan and Acceptance Criteria.

    The structure of this section depends on the way your team and process is setup. If there is a stand-alone testing process involved, please include business test cases. If there is no independent testing process, please include the acceptance criteria. The intent is to document the criteria that will help decide if the launch is go or no-go. Sample business test case: "Please test clicking on submit button with the incorrect username." Sample acceptance criteria: "The submit button should validate the username and show the relevant error message if the username is incorrect."

    Release Plan.

    In this section, include release (go-live) date(s). If there are multiple launch stages like alpha, internal beta, external beta, etc., include dates for each.

    Open questions.

    If some questions or sections need further clarity, document them in a different section at the end. Readers should know that you have thought of those questions and are working on resolving them.

    Future Plans (optional).

    Most features that I work on have a long-ish plan. I like to include a section, that lists the features, improvements or enhancements that I plan to launch in the future. If, for the enhancements, the timeline is vague or the confidence of launching is low, I omit this section.

    Version Control (optional)

    If the PRD has multiple versions with feedback and approvals, I include a separate section for version control.

    I want to conclude this post with a quote from Marty Cagan which summarized why every PM should know how to create comprehensive PRDs.

    If the PRD is done well, it still might not be a successful product, but it is certain that if the PRD is not done well, it is nearly impossible for a good product to result.