Requirement management is perhaps the most common task across the product management community. Fundamentally the role of a product manager has evolved and also revolves around ‘Requirement Management’. This task has been so common to the role of product management that many identify Product Managers as Requirement Managers. What customers need and what organizations develop should be aligned else there will a mismatch between demand and supply and this probably is the least possible expectation from a product manager, ‘supply what customers are looking for’.
A product manager can and should never go wrong with managing requirements. Irrespective of the technology, domain, organization or the country of work there are certain fundamentals which a product manager must always stick with or else be prepared for a nose dive.
Requirement management involves aspects of gathering, tracking and prioritizing requirements. Here are some simple yet powerful data points that a product manager should always record against a requirement:
- Source: Capture the source of the requirement, department, role and name with other relevant data. This is not just useful in larger organizations but also in smaller ones as it helps in tracing back the source in future for validation and sign-off purpose. Source could also be a market report, customer input and so on.
- Themes: Classify each requirement under one or more theme. Themes are great way to help product manager position individual releases. Some of the popular themes that I have come across are productivity, security, innovation, pain points, and scale. There are many more, however it is up to the product manager to figure out which one of these are more relevant to market and domain they are operating in.
- Market segment / Key customers: Was this primarily for enterprise customers or for retail segment? And who are key customers who are looking forward to such a feature along with potential increase in revenue or cost of losing a customer if feature is skipped. Is this required by one of the customers and if so should we invest in doing this and so on.
- Validity check time stamp: Requirements may have expiry date, something that is required today may become null and void few months down the time. While capturing requirements always keep take a note of expiry criteria, for example time, or a particular event (no point in doing this requirement after December) or it might be a good idea to link requirement to a compliance or government norms. Product manager should regularly re-visit requirements to figure out validity and changes.
- Impacted modules or sub-systems: It is very important to know what parts or modules or sub-systems will have changes for a given requirement. A user story is not complete unless changes at all the relevant places are done. Have this data captured helps in knowing the resource requirement and also skill set requirements. It will have critical inputs for point estimations and sprint planning if you follow agile methodology.
Efficiency and effectiveness of a Product Manager is highly influenced by the way requirements are managed and showcased to all stake holders. It is imperative that a product manager maintains a clear traceable and maintainable list of requirements. In case you are planing to use any software tool for managing requirements ensure that the tool allows you to add custom fields against at various levels.
@mathurabhay
related posts
