Product Requirement Document – Ironman

Overview: –

As we’ve seen in the last two chapters, we’ve presented our product and also had a look at what goes into a product backlog. Now it’s time to finally draft the Product Requirement Document for our product.

So in today’s chapter, we will understand in depth about a product requirement document while having a pragmatic take in doing so by taking a look at the PRD for Ironman. Let’s start

Recap: –

Product Requirement Document (PRD): –

A Product Requirement Document (PRD) is a document that focuses on defining the requirements of a particular product by encapsulating the : –

• Product’s Purpose
• Features going in
• Functionality
• Behavior

Similar to a BRD, a PRD serves as a guiding document for business stakeholders & engineering teams to build the product, launch & market it.

One important need of the PRD is to create a shared understanding amongst all stakeholders of the project. Hence, once a PM creates a PRD, it needs to be shared across all stakeholders to seek input and feedback. This leads towards having increased collaboration between the teams involved and hence a PRD undergoes multiple revisions before it is put to use for the project in development.

Then, once all the stakeholders are aligned and the PRD is approved, it provides everyone with a clear direction during the course of development.

Here’s a template that provides all the fields needed in a PRD along with their definition

Now, let’s look at each section in the PRD

Objectives: –

In the objectives section, a Product Manager needs to give a brief explanation for how the product and the project supports the organization’s larger goals and credo. The objectives section should answer the question, “Why this product should exist in the first place?”

Here’s a snippet from the PRD of Ironman

Goals and Success Matrix: –

The Scrum Org defines Goal as,

The future state of the product which can serve as a target for scrum team to plan against.

scrum.org

What is means is that, the goal a product manager articulates should be a state of product he/she envisions to have which can be planned to be achieved in smaller increments by the team.

But how would one know whether or not the goal is achieved?

The success metrics helps PMs and organizations to gauge accomplishment of the goal.

The success metrics are the metrics against which the goals will be measured.

Usually, the goal and success metrics are mapped through a table in PRD. Here’s how,

Assumptions: –

Although a Product Manager drafts the PRD, PMs usually engage with a number of stakeholders such as engineers, testers, product leaders, consultants while designing the product. During the course of doing so, a PM can only assume a state or environment for how the product will be operated and used in. Hence, the assumptions section is a place where the Product Manager can articulate the assumptions made while designing the product

Milestones: –

Milestones are often interchangeably used as roadmaps or release plans and although it is not a good practice, PMs and organizations often use them for their convenience accordingly.

But in general, milestones are checkpoints of interval by which Product Managers give a view by when a particular product , its features or important updates will be delivered.

The milestones in the first PRD presentation reflect what the Product Management teams expects in terms of delivery and by when they target to release the product or feature.

But it is not the final plan, the milestone plan is updated based on engineering assessment of the functional requirement and then further in a sense of granularity to the point of team’s capacity, their observed velocity and even leave plans and holidays.

In the next chapter, I will thoroughly discuss and teach everything needed for release planning.

Here’s an example,

Requirements

In a PRD, the requirements table should reflect just a brief view of product backlog. It should simply contain a list of epics & corelating user stories.

Example,

Wireframes: –

A very important section, wireframes is where a PM needs to add mock ups or a prototype of the actual product, giving a sense to the stakeholders how the product will look like.

A. Home Page

B. Select Clothes Page

C. Checkout Page

Open Questions: –

Since the PRD aims to build a shared understanding amongst the team, once a PM presents the PRD in the first round of discussion, the PM gets bombarded with questions. Some he answers, some remain open only to be answered during the course of development and converstations.

The open questions section articulates such questions

Out of Scope: –

The most important section in the PRD which helps both the product and project management team to plan better and deliver everything that is planned, the out of scope section lists down all the features, technical changes that would not be covered as a part of this particular instance of release.

This section helps reduce and almost eliminate scope creeps while also serving as a guiding point for Product Managers and Project Managers to rationalize come there be a situation to increase the scope of work during the course of delivering a milestone.

PRD of Ironman: –

Here’s the first draft of Ironman’s PRD which we will be updating during the course of learning product management and eventually building the product.

Takeaways: –

In the chapter, we learnt what goes into a PRD, the rationale behind it and a reference from our product, ironman.

In the coming chapters, we will discuss everything around planning in terms of releasing the product. Be it roadmap, release plan etc.