6 Steps to Master Request Management
Product driven organizations should always have a route for users to submit requests for specific improvements to the product. These requests are the source of key insights into the problems which the user community faces. Though no individual request should be taken as a representation of the community’s sentiment, careful analysis of the underlying patterns across all requests can yield deep insights into what the community values. The Product Owner oversees this process to ensure that requests are collected in such a way that they can be made actionable, in both the sense of fulfilling valuable requests and analyzing the collection to get an impression of the community’s problems and the opportunities the Product Team has to provide value.
Specifics of the tasks that go into this oversight process will vary from team to team, but proper oversight is critical to ensuring that the Product Team can maximize the value they deliver to their user community. Because of this, great Product Owners need to be masters of the six core steps that go along with the request process.
- Make sure the request makes sense: This seems like an obvious one. The request needs to make sense to anyone who is going to come into contact with it. If it is poorly written, vague, doesn’t present the problem, or just doesn’t make sense, contact the requester. Work with them to rewrite the request. This shows the requester not only that you care about their feedback but that you genuinely want to deliver on what they are asking.
- Make sure the request is not a duplicate: You do not want duplicate requests cluttering the Product Team’s backlog. However, duplicate requests are excellent evidence that a request has value to the community at large. Multiple users running into the same problem, coming to the same conclusion, and having enough passion about the issue to submit a request is a good indicator that there is an opportunity there for the Product Team to provide value. Great Product Owners will track these duplicates in other ways, like Votes towards an existing request.
- Ensure a rough estimation of value is given: Make sure that the requester is providing the “why”. (Why is this so important? What value would you gain from this feature? What costs will you avoid? How many hours of your time will this save?) Understanding the “why”, gets you closer to understanding how the community is really using your product and the opportunities you have to truly deliver value to them.
- Provide a rough estimation of effort: This comes from the Product Team. It does not always fall on the Product Owner to give, but it is an important element of a request to acquire at this stage. Effort plays a big role in the prioritization process for fulfilling valuable requests. If you can capture even a rough estimate early on, it will help you tremendously in the long run. I normally provide an estimate to each request in the number of Sprints I believe it would take a single Developer to complete the project. This is usually a sufficient level of granularity to last until a request becomes prioritized highly enough to have a Developer give a true estimate.
- Capture the metadata: Capture the attributes about the request that will allow you to start seeing the patterns. (What area of the product does this request affect? Who is the audience? In what portion of the user’s process flow does it fall?) The key data points will vary from product to product but the value in the emergent patterns does not. Discovering, for example, that seventy five percent of all requests are affecting the onboarding process of your product gives you a clear message that you have an opportunity to improve in that area and drive better acquisition of users.
- Analyze the request for alternative solutions: This is an important early step to combat the all too frequent occurrence of a requester submitting a problem that can be easily solved without development, or which the product already solves and the requester is just unaware of the solution. It may not be possible to dive deep enough into the request at this step to fully suss out all alternative solutions, so just perform a preliminary thought experiment to see if there are any alternative solutions you could suggest to the requester’s problem.
Product Owners who can consistently focus on executing these six steps are well on their way to mastery of the request management process. It all comes down to capturing the right information and really thinking through each request that is submitted. If a Product Owner can oversee this process and ensure that requests are collected in this way, they can fulfil valuable requests and analyze the collection to get an impression of the community’s problems and the opportunities the Product Team has to provide value.
