Creating A Business Requirement Document
When defining what product management is, we focus a lot on the Venn diagram that portrays how we are an intersection between business, tech and design.
What a lot of people don't say is that a product manager must document sh**. Bruh everything that deals with business, tech and design has to be documented by a PM. You literally have to document because you have to communicate and you have to make it super clear to the recipient which can be a c-executive, designer, marketer, developer(usually the hardest) or a client which you are consulting for.
As a product manager(PM), you basically need to be familiar with templates and different types of documents. But one thing to keep in mind is that we document to communicate. So no matter what you do, no matter the template always think about the person reviving the doc.
About 2 months ago, I got a gig as a product management consultant and my task was to conduct research and create a SAAS product in the education sector. I was supposed to come up with a research brief, BRD, PRD and Hi-FI wireframes. That was the first time, I had to be the lead product manager(more like only product manager) and so you can imagine that I felt some form of anxiety but that story is for another day.
Let’s get to it!
So a Business Requirement Document is basically a doc that contains and communicates business needs, requirements and system functionalities or specifications for a product that serves a business. Think about it as a source of truth for detailing the scope of a product or how you intend to serve a business with a product or service.
In this article, I’d be looking at BRDs for product development and in some way, the BRD can also double as a proposal to stakeholders on how you intend to solve a different problem or change a current process.
How It Started
So, BRDs are a powerful tool for business analysts whenever they need to venture into a new project. That project might be a process, service or product. BRDs also became a popular tool with project managers, they detail businesses needs and solutions and they have become popular amongst product managers especially those in the B2B space. In this article, I am going to walk you through the essentials of a Business Requirement Document.
What Should Be In A BRD?
- The Table Of Content:
A BRD is a very comprehensive document and can go from 5-100 pages and even more, having a table of content is essential for the reader to easily navigate the document.
The table of content should contain all the major sections, headers, subheaders and pages on the BRD. If the BRD gets too long then the reader can actually navigate to the part that they need.
2. The Intro
A BRD should contain an introduction. In this case, you should introduce the concept or product you are working on and depending on what your employer needs to know to ease into the document, you can actually add anything else that suits them like research notes, project scope, product scope, development methodology, business cases, etc.
3. Business Process Overview:
A BRD should be able to evaluate current processes and describe the current one and how exactly it surpasses them. As a PM, your job is to solve problems and this part of this BRD highlights whether or not you are doing that. You do this by simply highlighting how a potential, existing or hypothetical client currently solves a problem. You can use mind maps, swimlane diagrams or journey maps to get this done. The next step is to draw up our own process in comparison to the initial process drawn for the client. The next step is to come up with an evaluation on whether the solution is viable and explain that in the doc.
4. System Requirements:
At this stage, you want to talk about all the functional and non-functional requirements that will make up the system. Functional requirements are specifications in the product or process you are building that directly affects the product usage. Non-Functional requirements can be seen as those system specifications that the user or customer does not interact with, they exist but the customer does not know that they do. Functional Requirements can be the doorknob and non-functional requirements can be the alloy or metal used to create the doorknob.
5. Dependencies and Constraints:
In this section of the document, you might want to look at possible dependencies and by that, I mean what part of the system might affect other aspects and their level of priority based on how critical they are. For example, in developing an employee management system, the employee’s info and profile will be the heart of the system as it determines how the other parts of the system are expected to function.
Constraints are things that might prevent the solution from getting developed or anything that limits the scope of developments, it can be things like money, access to technology and even team capability. It’s helpful to highlight how you intend to go above these constraints or if there is a need to go above them at all.
Before You Get Started:
Before you row your oars, you should not just jump into a BRD because like a lot of things in the world of product, nothing is entirely set in stone(your industry and teammates matter). A number of processes have to be catered for before you jump straight to business.
- Talk to your employer:
Ensure you try to understand the needs and goals of the person that has paid you to start the process of a BRD. When my client reached out to me, after conducting comprehensive research, I came up with a table of content and I ensured that it was approved, the client actually noted a few things to add to the document.
2. Speak to other stakeholders:
In this case, you will need to engage stakeholders in-house especially those that will be working with it. What you need to get from them is their thoughts on the product or concepts and details that would affect or aid their development or execution.
3, Do further research:
Even after getting conversations going, you may want to do further research and find out if there is anything you need to add or subtract, FInd out how that might impact the BRD and then get moving.
Wrap It Up, I’m Tired!
It’s important that you do not get too anxious about getting everything on a template perfectly or try to get too excited about having the best BRD based on the number of pages or the font you use or the software you use.
A BRD is meant to guide the team and create a thought process around the development of a product, project or process.It highlights the scope and solutions at the most basic level.
To make your journey easy, I am going to share a template here.
As said before, it’s not set in stone so please feel free to add to it, subtract from it or discard it(I’m playing oh).
Just do your best work!
