Written by on

Writing Product Requirements Documents (PRDs) is part of my everyday job at Trip.com. Writing them in a comprehensive way while not being overly verbose is key to ensuring my peers will actually read through and understand them. Over time, I've found myself re-using the same components again and again. Read on to find out what those are.

This article is not supposed to argue the exact definition of a PRD, I assume the common sense approach that it's a requirements document that specifies scope, reason and desired output.

Also one word about agile methodologies (e.g. Scrum): In a Scrum context, documentation is usually kept to a minimum and PRDs do not exist as such. However, they are not totally disconnected. Transporting into Scrum, I see a PRD as combining an Epic (which communicates the big picture) with the Epic's user stories.

Now here's what I found useful when writing PRDs:

  1. Start with a story -- Introduce the PRD with a story that explains the situation, problems and goals in a narrative form. This helps the reader emphasize with the user and provides an initial intuition about why the feature outlined in the PRD is important.

  2. Introduce the big picture: What, Why, Who, How

    • What is it? --> Summary of the most important functional and non-functional aspects and requirements
    • Why do it? --> Provide insights based on data as to why this PRD is necessary and urgent. If possible, provide both quantitative and qualitative angles. Include business and commercial needs. Include technical considerations that motivate this PRD.
    • Who is it for? --> Outline what's the target user (or customer) group for the PRD. Briefly explain why those users and not others.
    • How is it done? --> List system design and interface dependencies here. The goal is to educate the reader about the technical ecosystem. Do not describe how the UX team is supposed to do their job, or how exactly the development team should implement it.

  3. Don't forget the market - Include your analysis how key competitors are solving similar problems and weigh in as to why their solution is good or not.

  4. Split the PRD into digestible pieces. Depending on what kind of software development methodology you are using, chances are high that you'll need to create user stories or similar artifacts later on. Make sure to make it easy to split the overall product requirements into individual pieces.

  5. Follow a consistent structure for each requirement inside the PRD. At this point the explanations should be very focused and specific, not as general as in the introduction. I've found this general structure useful:

    • Requirement Intro
    • Motivation & Problem Description
    • Functional Requirements
    • Non-functional Requirements
    • Interaction Processes
    • Interface, integration and technical considerations and constraints
    • Acceptance Criteria

  6. Don't tell UX, UI, Development and Testing teams how to do their job. Your focus should be on explaining the goals, from user, customer and business perspective and the resulting requirements to the product. Don't bias into a direction just because you personally favor it. The "How is it done?" part in the intro is only to give the reader an idea of the technical ecosystem this PRD lives in.

  7. Make sure acceptance criteria are water-tight. In the best case, acceptance criteria should directly be used to construct test cases. They should cover both functional and non-functional aspects. Each criteria should be specific and easy to validate.

  8. Don't slack on the non-functional requirements. Typical non-functional requirements are performance, security and scalability. But usability is also a non-functional requirement. Make sure to line out how you want users to feel when using the product.

  9. Draw a fence - As important as lining out what's included is describing what's out of scope. Argument why you leave certain features out of scope. Otherwise you open yourself up to discussions about why a certain feature is not included or why you included requirements from business unit A but not business unit B.

  10. Don't set deadlines. I realize that this might be controversial. But I believe that a PRD should be focused on the product and not the delivery timeline. That doesn't mean that e.g. development team utilization or customer expectations don't influence the PRD. It's just that the PRD shouldn't dictate the "when".

Finally, here's a Google Doc that I use myself as: PRD Template