The product requirements document (PRD) is a central document used to align all stakeholders (product management, engineering, QA, designers, and leadership) on how we will solve a specific problem with the proposed solution.

When creating the PRD, provide just as much information as needed and nothing more. If the document is too long and complex, it will quickly become outdated, and readers will lose interest.In this latest iteration of the Unified Compliance PRD template, we changed the template to help raise visibility of how the proposed product (or feature set) adheres to Unified Compliance’s strategic plan including details on why this product proposal is important to Unified Compliance.

Describe the problem we are solving, the high-level approach, and goals so that before we get too far into the details, readers will have a good understand of where we are headed.

What problem are we trying to solve?

Start writing here:

Briefly describe the approach you’re taking to solve this problem. Provide enough information for the reader to imagine possible solution directions and get a rough sense of the scope of this proposal.

Start writing here:

What does success look like? What metrics do we measure today that we can we effect and why affect? What metrics should we absolutely add? Why it is important to affect those metrics?

The intent of this section is for the following:

Scope Definition: defines the scope of the proposed product (or features), including what will and will not be included helping manage expectations and focus development efforts.

Guideline for Development: provides detailed information on the product’s features, functionalities, user flow, and interface to guide the development team in building the productsection focusses on the details of the solution including what is in scope, what is out of scope and additional information to help in the product and engineering collaboration process.

Describe the product features that will bring value to customers and fulfill underserved need(s).

If we have them, link to:

• user journeys, process flow, or other diagrams related to the requirements.

• mockups, prototypes, or screenshots related to the requirements.

Link here:

If this project is a component to other areas or an update to an existing product, specifically call out where this product will interact with other areas.

Start writing here:

List any open questions that come to mind throughout the lifecycle of this initiative.

The intent of this section is for the following:

Technical Risk Mitigation: Identifies potential technical risks and propose mitigation strategies.

Launch Readiness: launch checklist including high-level go-to-market plan to ensure cross-departmental alignment.

mostly focused on getting the solution “out the door” and who else is affected outside the product and engineering teams.

If applicable, identifies potential technical risks and propose mitigation strategies.

Identify any relevant milestones that people should now know about. Will we “eat it” ourselves first? Will this require a beta? and what is the target launch date?

This section is a reminder to the product team to make sure all relevant stakeholders are involved as necessary.

List and link to any other reference sites, documents … that might be important to the reader including the business model canvas (BMC).

Start writing or linking here: