A Business Requirements Document is the foundation of any successful product launch. Here are the necessary steps that must be followed for the perfect BRD.
In every organization, the product team is the primary team that is responsible for preparing the business requirements document.
Yes, the product team should consult with a variety of stakeholders, preferably from both within and outside the immediate project team.
What Is A Business Requirements Document (BRD)?
A business requirements document or a product requirements document is a blueprint or a plan of action that needs to be followed for the successful development of a product or a service.
This blueprint takes time to develop, as it defines the high level requirements for its target audience.
That target audience is the product development team.
Business Requirements Document – Steps
The following steps are a must to prepare a detailed business requirements document.
- Interview Stakeholders
- Maintain A Version History
- Explain Things Visually
- Use Minimum Text
- Define In Scope
- Define Out Of Scope
- Prioritize Requirements
- Set Realistic Timelines (Keep A Buffer)
- Get Sign Off From Vertical Heads
BRD Preparation Steps – Detailed
Let us go through each step in detail.
Treat the preparation of the BRD as the very first step of a successful product life cycle (PLC).
Interview Stakeholders
This is the first step.
It goes without saying that this is one of the critical product management skills.
It is a must do for all product professionals to go and interview their clients.
Every Product Manager must make it a point to actually talk to actual or potential customers.
No future should ever be assumed to be of value.
Interviewing stakeholders, including internal teams like development and sales, is important to find the right feature mix for the product.
It is also important to keep communication channels open even after the interview phase is over.
Understand the importance of the continuous product feedback loop.
Maintain A Version History
It is good practice to keep a detailed account of when things were added to the BRD.
Equally important is to keep a track of when things were removed from the BRD.
Don’t assume that these changes were discussed over email and hence the record can be found over emails.
Everyone forgets about emails.
And questions about a BRD may come months or years down the line.
People who exchanged the original emails may no longer even be in the company.
Therefore, it is always important to maintain a version history.
Most product management tools for documentation have this feature in built.
Explain Things Visually
A picture speaks a thousan words.
That is not a joke by the way.
The primary audience for product requirements document is generally the development team.
And nobody, not just developers, likes reading long verbose paragraphs.
If you can explain it with a picture, go for it.
Use Minimum Text
This is in continuation of the be more visual point.
Sometimes, adding text is not only necessary, it is required.
But, be as straight forward and direct as possible.
Come straight to the point of the feature.
Don’t forget the KISS Principle.
Define In Scope
Far too many products fail because of unclear requirements.
What is the main responsibility of a Product Manager? Well for one, it is to define a crystal clear product roadmap and a manageable, achievable product backlog.
But, all of this begins with defining what is in scope.
It takes many iterations of the BRD to define which features are truly within the purview of the project.
There would be pushbacks.
But, managing these situations is the hallmark of a true leader.
Define Out Of Scope
An even more difficult job than defining what is in scope, is the job of defining what is out of scope.
People are for some reason okay with leaving things ambiguous.
Maybe it is the hope of achieving something vague that prevents people from defining the outer boundaries.
To clearly spell out what is out of the scope of the project is not for the faint hearted.
But, it is an unavoidable task.
Remember the skill of how to influence without authority.
The Product Manager must rise to the occasion and make the difficult decision of cutting out some features.
Many stakeholders may not be happy with these decisions, but the product comes first.
The art of taking such difficult decisions is also a part of the necessary skills for effective team management.
Prioritize Requirements
This may seem relatively simple, but it requires some sound diplomacy skills.
Yes, this task is not as hard as defining what is in scope and what is out of scope.
But, it would be a mistake to take this task lightly.
Use tools like Jira, Asana, Trello, etc. There are many product management tools available out there. The important thing is to actually choose a tool and start with the prioritization.
Check out the top differences between Asana and Trello.
It is also a great practice to represent priorities visually using the Kanban method.
Priorities are important no matter which agile methodology you pick, including the scrum.
Not defining priorities is a classic way to fall into the Waterfall trap!
Set Realistic Timelines (Keep A Buffer)
Always, always, always build in a buffer for your priorities.
Never forget Murphy’s Law.
If something can happen, it will happen.
There will be delays, technical issues, resource challenges, team attritions, priority changes, scope creeps, scalability problems, unclear requirements, etc.
That’s a part of the game.
Every product or project professional keeps a buffer in case things go south.
Make sure the following differences are clear –
Get Sign Off From Vertical Heads
I think this is a fairly obvious task.
If the product team has carefully balanced competing requirements, then getting a sign off from vertical heads should not be an issue.
It is important to get a sign off from various stakeholders like the technical lead, the product head, the QA head, the main business contact, the marketing lead, etc.
Remember, at the end of the day, everyone is part of the same team.
And everyone is in it together, to achieve the common goal of building a fantastic product.
Conclusion
As mentioned in the beginning, the business requirements document is the bedrock of a successful software development life cycle (SDLC).
And like everything else, building a great business requirements document doesn’t come overnight.
The skill of writing the perfect BRD requires practice.
Here are additional tips on writing a BRD.
Follow me on Twitter for all the latest updates.