This post is a part of a series discussing Agile Product Management responsibilities. Click here to start from the beginning.
Agile teams meet their requirements and complete user stories as and when relevant backlog items come up. This means that Agile product managers must release the correct data at the correct time and only to the correct people, with recognition of the appropriate technical mastery to complete each task.
Agile product managers should be able to switch gears at a moment’s notice, moving easily from the minutiae of technical details to overall strategic issues, as the situation requires. A Product Manager has the vital responsibility of determining market requirements and properly communicating them to development teams.
To this end, the established method is to employ a Market / Business Requirements Document (MRD or BRD). However, we must update our traditional preconceptions of an MRD/BRD if it is to meet the demands of an Agile product team. This means that we must identify and overcome the following traditional barriers to good MRD/BRD writing:
- MRD/BRDs can be difficult to write with the correct level of detail. When a Product Manager writes too much, the document becomes bloated and is, more often than not, ignored. However, should the Product Manager write too little, he runs the risk of glossing over or entirely neglecting important product information. To combat these perils, a Product Manager may end up doing both; reducing content but increasing length (a.k.a. writing too much about too little).
- MRD/BRDs must also address many different levels of technical comprehension. Without focus, every reader of a traditional MRD/BRD ignores, or even skips out, entire sections they feel are irrelevant. This means that finance, sales, operations, and development personnel all have their own sections in the traditional MRD/BRD but are expected to comprehend the whole document.
- MRD/BRDs can also be poorly maintained, getting out of step with their own goals: high-level market requirements remain more or less unchanged, but detailed feature specifications have to be frequently re-examined.
- MRD/BRDs could also suffer from being created, but not consumed. Normally, there is a lot of focus on the creation of an MRD/BRD for a new project, but continuous editing and review is less of a priority. Product managers have to go through the motions of making an MRD/ BRD, fully expecting that whole sections of their work will be discarded or ignored by various departments.
Now that we’ve gotten the barriers out of the way, my next post will explain how to create a good MRD/BRD.
