Is the Product Requirement Document the king of documents?

Our last post was about the term Requirement. What are those, and why are they important? Software is a living thing, and most of its life cycle must be documented. Requirements are crucial parts of that cycle and they must be documented.

Where do those requirements go? What is the next step for them? Do they have a life of their own? Those requirements were the client’s idea, its baby, and something that the client wanted to nurture and place. Most of them, the clients, didn’t know that they even existed.

The Product Manager elicited requirements from the client and they are on the way to a specific document with powerful meaning for different departments included in software development. Here is the dawn of a requirements new life.

And, where do requirements go?

Requirements are going to the PRD.

At the point where requirements need to be documented, the Software Product Manager writes product requirements. This work may be in various formats such as Product Requirement Document or wireframes, but for developers, they are the most suitable in User stories form.

A Product Requirement Document is a document written by the Product Manager intended for the team, as well as for the stakeholders. This specific document is made of objectives, use cases, key deliverables, and wireframes.

Holistically looking, this document should give answers to the three major questions:

1. Why should we build a product/feature? (It will be referred to only as a product further in the text)
2. What should the product do? 
3. How do we measure the success of that product?

If those questions remain unanswered, the team will have many assumptions that will bring uncertainty about future products. This sentence is already showing the purpose of PRD, and there is why we need PRD. The product needs this type of document to:  

1. Be aligned with the client,
2. Give context to developers,
3. Give context to designers.

It can either define the entire product, MVP of the product, a specific version of the product, or just a minor feature that the client wants to develop or release.

Why does the Project Manager write PRD?

PRD is for sharing an understanding of the product’s purpose across the team and is also a place for efficient collaboration across the team.

The engineering team, UX research teams, and design teams work together, so they have to balance functional concerns with the design team’s focus on usability. Working in tandem can have a more holistic approach to the problem-solving that their clients are asking for. Following PRD guidelines written by professionals who understand different fields well (for example technical and business aspects), they will blend function with user experience research.

That leads the project closer toward efficient collaboration of building an end-all experience from start to finish so customers stay satisfied. It is said that it is written primarily for the Product Manager and here is an actual link between the Product Manager and PRD:

PM’s responsibility regarding PRD (after it is established) is mostly to keep this document alive and updated. That means adding recent updates in two columns:

1. date of update,

2. brief description of the update.

The reason for this activity is that for anything to happen, it must be documented, and everyone involved has to be informed because everyone will agree that a few developers or other teams or positions that are included in the project can read minds. By putting ideas into documents and reviewing with stakeholders, PM is getting a wide and clear picture of what needs to be delivered.

But that is not everything that happens between PRD and PM.

How does PRD support the team?

PRD helps PM with:

- fully thinking through the end-to-end experience of a product should be (we can observe this document as not only a show-to document but a document which helps PM with deep analysis of clients’ ideas). This is the way PM will figure out dependencies, Internal systems, resources, or even teams that may be needed or impacted when building out your product.

- must have vs. nice to have and to prioritize essential components for MVP

- shared understanding: listing ideas in a document allows PMs to validate their assumptions.

But PRD carries benefits not only for the Product Manager:

• From this document, engineers will create a technical specification also called a spec which describes how each user story in the PRD will be implemented and they will also create an architectural design document
• The product design team will create wireframes and mockups as needed
• And QA will write out a test plan to ensure that every use case in PRD is working as expected and document any bugs or defects that occur.

Requirements are a living document. They change as project goals shift and new information becomes available, so every Sprint update makes them stronger than before. And this is for projects and companies that follow Agile methodology.

What Should a Product manager have to have in mind in mind while creating PRD?

When writing PRD, a few things that PM should have in mind are the following clauses:

1. The goal is to focus on the problem, not the solution because PRD has to be what the product should do, not how,
2. The Product Manager has to be concise in writing the PRD. No more than a few pages. Not too long. Of course, it depends upon how big and complex our project is, and how you handle the formation of topics and subtopics,
3. The PRD is an ongoing document, always up to date. It evolves as the team iterates,
4. Getting feedback from your stakeholders is valuable,
5. The PM will know if he wrote good PRD if rule number five is applied. It states that if you take 5 random team members and ask them about the product purpose, timeline, and features based on the PRD, they should be able to give you roughly a similar answer.

The fifth item is overall and it shows clarity across the team about the product that we have to deliver. It ensures that everyone has a clear understanding of what the product should do and why we are building it.

What’s an example of a Product Requirements Document?

Before diving into writing PRD these are possible tools for work, tools that can be and mostly are, used to help PM to create PRD:

Common writing tools:

• Word
• Google docs
• Figma
• Balsamiq

Every company probably has its own PRD template. That means that the company has consistent and structured documents that allow everyone to contribute.

Clearly, Agile methodology-transparency.

Is there one Requirements document template that rules them all?

No.

The process for creating requirements documentation is not a size that suits all. There are many different templates and approaches depending on what internal and external stakeholders you have, as well as the technology involved in your company's workflow.

And yes. The core set of key information in any Requirements template is always present. And regardless of if it's being compiled using a methodology or terminology, this single fact remains true for everyone.

With that, let’s look at the core information set that every Requirements document should contain.

1. Introduction: Background, customer...define project specifics. It will bring more value to the document included in the high-level direction at the top of the page

2. Purpose of document

• Participants: Who is involved? Include the product owner, team, stakeholders
• Status: What’s the current state of the project? On target, at risk, delayed, deferred, etc.
• Target release: When is it projected to ship?

3. Goals:Straight to the point 

4. Background and strategic fit: Why are we doing this? How does this fit with the overall company objectives?

5. Objectives:Specific, actionable targets that need to be achieved. Example: “The main objective of voice call feature is to allow the users to initiate voice calls within private chats to add a more interactive approach to conversation. “

Functional objectives:

Non-functional: An example could be (again, it depends on the stage where the documentation is applied or specific feature or whole project) reliability, usability, performance, security, supportability, interfaces...

6. Use cases: The idea of this section is to capture the actions that will be performed by each one of the users within the product, explain them and explain the main objective - The Why? Description of how the user interacts with the product. Written in the format: “As a... I want to...so that I can...

Example:

7. User Stories: List or link to the user stories involved. Also link to customer interviews, and include screenshots of what you’ve seen. Provide enough detail to make a complete story, and include success metrics.

8. Key Deliverables: Key deliverables are anything that is produced or provided as a result of a process. It is tied to a specific date which is expected by a certain time. Within PRD, Key Deliverables contain the columns:

9. Wireframes

• An early blueprint
• A basic visual representation of a product
• The key aspect of a wireframe is: simplicity

• Understanding the idea of what needs to be developed
• Demonstrating ideas to the clients and acknowledging their feedback
• Communicating with developers
• User interaction and possible design

10. Assumptions, risks, issues, dependence: Contain a List of the technical, business, or user assumptions it might happen.

11. Questions:As the team understands the problems to solve, they often have questions. Create a table of “things we need to decide or research” to track these items.