Lesson 3 – Requirement Elicitation

Overview: –

To “effectively” communicate an organization’s vision though a product or client’s needs, a Product Manager requires to encapsulate these details through artefacts that present the solution (a product, a feature or an increment) to all stakeholders involved in the project. To achieve this, a Product Manager uses two artefacts in particular, namely : –

1. A Business Requirement Document (BRD)
2. A Product Requirement Document (PRD)

In this chapter, we will discuss in detail about how requirements can be documented in these documents. Additionally, I’ll also share templates for them so that you can practice writing each of these documents and also use them if needed in your projects.

Further, we’ll also discuss around a couple of questions one can have around both the documents, such as : –

Q1. What are/is the differentiating factors/components for a BRD to be a service specific document?

Q2. Do product based companies use BRDs? If yes, when and how?

Business Requirement Document (BRD): –

A Business Requirement Document (BRD) is a detailed document that outlines high level business goals, objectives & needs thereby serving as a foundation for any project.

It is a document that helps bridge the gap between Product Leadership, Business Stakeholders, Clients and development team by clearly communicating the scope of the project/product at a high level. Hence a BRD is created at the very initial stages of the project.

A BRD primarily aims to focus on defining the business problems, identifying opportunities to improve & set the overall scope for the project.

Key Components of a BRD: –

A. Project Scope: –

The BRD should clearly communicate the scope i.e. define the boundaries & objectives of the project. This helps avoid scope change and also manage and account for change requests during the course of the project.

B. Stakeholder Requirements: –

Since BRDs are widely used in service based organizations, it is important to list down all the requirements “asked to build” by stakeholders. These stakeholders can typically be Product Leaders in Product Orgs or Clients in case of service based orgs. A BRD should clearly outline the expectations and needs of these business stakeholders.

C. Functional Requirement: –

The most important component of a BRD is the Functional Requirements. This is the part where a Product Manager needs to crisply define “what solution” will be built for the requirements. This solution will be crafted out after rigorous requirement gathering and product brainstorming a PM would have typically performed before. This section of the BRD should strictly focus on describing the features and functionalities needed to meet the business objectives.

D. Constraints & Assumptions: –

Since a BRD needs to also needs to provide complete transparency with all stakeholders involved in the project, there needs to be a section where a PM needs to articulate the identified limitations and assumptions that have a potential to impact the project.

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

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

Discussion: –

A. What are/is the differentiating factors/components for a BRD to be a service specific document?

It is “Stakeholder Requirements”. Since PRDs are developed by a PM after being directed by leadership in a product organization, its creation is driven more from the organization’s vision which is directly transpired towards the teams responsible for building the product. But when it comes to service based organizations, the ask is more inclined to shoulder for delivering a set output that will impact the client organization and its clients.

Therefore, usually a Business Analyst drafts a BRD after performing the requirement gathering cycle using techniques we saw in our previous chapter . Here, it becomes important to document all the requirements that the client had communicated and finalized which is not the case with PRD since everyone in the hierarchy is involved in delivering the PRD.

B. Do Product Organizations draft BRDs? If yes, when & how?

Yes, product organizations do draft and use BRDs. The situations can be different but one of the most common case where they need to draft BRD is when they whitelabel and sell their product to another organization to use it. Meaning, the product based firm operates under the “Software as a Service” (SaaS) business model. Here, in order to calibrate and configure the product according to the need of the client, the PM needs to first understand the requirements of the clients, evaluate if their product provides these functionalities for the requirements & then articulate them in the BRD.

In cases where the client asks for a functionality is was never built for the product, the PM needs to explicitly mention this particular requirement under “Stakeholder Requirements” and build it if asked for adamantly.

Takeaways: –

In this chapter we have learnt what goes into creating two important documents used for documenting requirements. In the coming chapters, we will move ahead and be more pragmatic by doing the following: –

1. Create a presentation for a use case we have identified
2. Using the templates provided, we will create BRD and PRD for the use case
3. Follow this up by starting a series on Product Backlog Management