When Frustrated, Write a Requirement
When Frustrated, Write a Requirement
Three steps to quash your frustration
Have you had one of those frustrating days when your product team is raising a lot of issues? Did you get ambushed by key stakeholders? Is your daily to-do list growing because your team has so many product questions? These challenges plague product leaders on new and established products.
After being frustrated you can take a few steps to get ahead of the issues:
Turn the product issues into requirements
Add the new requirements into your backlog
Respond back to each team that raised an issue
These steps help move the clutter out of your way and gets the issues to the right people for resolution. Let's discuss how to take these steps and put your frustrations to rest.
Turn Product Issues into Requirements
In the rush to release products, product teams often skip secondary priorities. Sometimes the secondary priorities turn out to be really important. Or customers use your product in unexpected ways. In these cases, product leaders like you get many issues escalated about your product. It is tempting to absorb these issues and research the issues later. However, you need to wrap up requirements on the next release and these new issues are too ambiguous to add to the next release.
In this case, write what you know about the issue, get screen shots, and collect documentation about the issue in the form of a requirement.
Example of Turning Product Issues into Requirements
For example, suppose you've recently launched a new software product. You and your stakeholders agreed the product could be released even though some test cases weren't executed yet. The product team believed the testing would finish before any customers used the new product. Since the software product has already been delivered, your service delivery team had no opportunity to exercise the product. Now the service delivery team is raising issues that they don't have product experience and they have no internal documentation on troubleshooting the product.
You write the following requirements:
Process for the service delivery team to escalate to the engineering team
Internal documentation covering standard configurations and troubleshooting guidelines
Process and budget for the service delivery team to test in parallel to engineering
With these requirements documented, you can focus on getting the next release started.
Follow up on the New Requirements
Prioritize the new requirements as you would any other new requirement. Let your team know that you are handling the issues as new requirements. The amount and type of feedback on this handling will give you good information about prioritizing these new requirements. You can also better refine the requirements as you get comments on the requirements.
In the above example, suppose both the delivery team and account teams are upset that no one is working on the issues yet. This gives you a good opportunity to quantify the benefit of the requirements. You learn that 4 customers had a poor experience resolving an issue because the support team didn't know how to troubleshoot a problem. You note the support case numbers, the size of each account and the amount of time it took to resolve the problem. With this information, the escalation process is set up and initial documentation is delivered. The service delivery team has budget and dependencies on testing the next release before customer delivery.
Conclusion
Writing requirements is more productive than getting frustrated. If you don't feel authorized to write a requirement, then your product management team will appreciate your written requirements. Writing a requirement frees up your time to focus on current work while collecting details on the benefits of the requirement. Next time you get a bunch of frustrating product issues, write a requirement.