Requirements Tracking for Product Quality
How product leaders develop a point of view on release readiness
Smoothly running customer-focused product teams have constant pressure to deliver releases. There is value in helping the product team and stakeholders have a clear picture of the status of the release. A good way to communicate a picture of the release status is by tracking requirements through the lifecycle.
Requirements tracking is often overlooked in fast-paced environments. While there is widespread agreement that issues are harder to fix after a feature is released, taking a look at the requirements before release is frequently skipped. With tools like Jira that are aligned to the product lifecycle, program managers can pull a report on the status of the requirements. Plus there are multiple demos, test reports, and other validations of the release. It is hard to add another checkpoint before releasing!
Let's dive into requirements tracking with minimal overhead and disruption. While the pressure is high to deliver valuable features to customers, there are steps a product manager can take to efficiently track requirements:
Set up requirements for easy tracking
Monitor requirements through the product lifecycle
Summarize requirements before release
Set Up Requirements for Tracking
A hierarchy of requirements is key to easy downstream tracking. A requirements hierarchy is tied to your executive summary of your product iteration. Any subsequent tracking follows the hierarchy.
Suppose you are a product manager on a SaaS product that analyzes cloud spending for enterprises. Your next release has these themes:
New reports on cloud storage spending
Chargeback information for large customers
50% improvement in time to generate a spending report
Working with your product team, you set up the requirements like this:
You have set up the requirements aligned with the overall themes in the release. You use this hierarchy to review the detailed requirements with each team. As each team accepts a requirement, you can begin tracking what you have and risk areas. Additionally, as you review requirements, you stick to this hierarchy for any additions or changes.
Monitor For Changes
As the product team plans and develops the release, new information about what can and can't be done in the iteration emerges. The new information comes out of the following:
Design reviews
Planning based on available resources
New customer requests
Priority changes
You are responsible for initiating the change based on the emerging information. Don't wait for someone to ask you to change! A product leader drives the change.
Taking the example further, let's see what happens on the release:
Due to cloud API differences, the storage reports can only be developed for object storage
Your customers use mostly object storage - You move block and file storage reports to the backlog
Your IT team is tied up and can't implement their part of licensing
Your business case is unaffected since new customers need the chargebacks
Only one of the performance improvement use cases can be implemented
You decide to move the other use case to the backlog since you don't want to delay the rest of the content
Here is a summary of the changes you handle and communicate to your stakeholders:
Your requirements tracking hierarchy after these changes are as follows:
After collaborating on the changes, the product team continues developing the features. Each scrum team demonstrates its results. The final preparations for the release begin.
Summarize the Requirements Before Release
In the final push to hit the release date, no one is focused on the requirements. As a product leader, you need to summarize for yourself how the requirements have been implemented. Key reasons for you to prepare a summary of the requirements as delivered to the customers are:
To raise requirements issues before customers are exposed to the issues
To collaborate on release readiness
To communicate to customers about known issues
To evaluate the customer experience with the release
In the example case, here is what you find when you review the requirements:
A storage report has a mix of units being reported
Engineering changes the display to be consistent
The storage report takes longer to run than the performance required
Add this to the known issues in the documentation
Documentation is missing on how to configure the chargebacks
A secondary release of the documentation is planned post-release
Testing is not complete on the performance improvement
Notify stakeholders of the plan to test and the risks
As you review the requirements, you discuss your findings with the affected product team members. Since you are asking questions and interested in how the release works, each team is happy to collaborate on what you find in the review. The summary of the requirements after your review is below:
After the review and discussions, the product team feels good about the release. Additionally, you have an easy way to update your stakeholders on the release readiness.
Conclusion
As a product leader tracking requirements is important to the success of your product. Taking the time to do it right prevents issues from getting to your customers, keeps the product team aligned on plans, and validates cross-functional requirements well.
The steps to efficient requirements tracking are:
Make sure your requirements are easy to track
Keep an eye on your requirements throughout the lifecycle
Give a final check to your requirements before releasing to customers
Following these steps, product leaders work effectively with cross-functional teams to track requirements and develop successful products.
Interesting Links
Should Product Managers focus on Outcomes over Outputs? One of the main practices of being an outcome-focused Product Manager, is to keep caring about the product after launch. Many Product people say that after launch is when the real work begins, as you start analyzing usage data, gathering customer feedback, and thinking about iteration. From Carlos Villaumbrosia at Product School.
Tracking the Right Product Metrics A big part of a product manager's job is determining which metrics to pay attention to. Article by Ben Yoskovitz, author of Lean Analytics, in Pawel Huryn's newsletter.
Great post Amy - At my company, we don't have the proper tools in place to make this an easy process. Definitely seems like there's a benefit to make a push to get better tools which can support this type of story/metric thread tying.