Is it important? Is it urgent? According to Product Manager Kabele Cook, these are the two dimensions by which stakeholder requests are measured.
Working alongside her teammates at Rho, she knows how to identify these two crucial elements. In doing so, Cook’s team is able to decide where to best allocate their time and talents.
Of course, deciding the status of requests is only half of the battle when it comes to stakeholder management. According to Cook, product managers must occasionally turn down requests if they’re urgent yet unimportant.
FRICTIONLESS FIRMWIDE FINANCE
Cook and her peers were once forced to delegate a request to another team in order to tackle a problem that was affecting the platform’s users. “Ultimately, we were able to solve a bigger and more pressing issue that only my team was able to handle,” Cook said.
While managing several stakeholders can be difficult, she said product managers can do one simple thing to keep themselves on track: “Write everything down.”
Built In NYC caught up with Cook to garner her insights on prioritizing requests, knowing when to say “no” and balancing the needs of various stakeholders.
How do you decide which stakeholder requests should be prioritized?
I use the Eisenhower Matrix to prioritize requests from all stakeholders. Requests always have two dimensions: importance and urgency. When a request is important, it requires a specific skill set and time, while urgent requests have hard deadlines and consequences if not fulfilled.
If a request is both important and urgent, then just do it. If it’s unimportant yet urgent, then delegate it. Feel empowered to lean on your partners. A request that is important yet not urgent requires special attention, as it can easily slip through the cracks and have long-term consequences if it goes unaddressed. When a request is unimportant and not urgent, just say no.
Describe a time when you had to say “no” to a stakeholder.
My teammates and I were building internal underwriting tools that took in application information, decided the data and then sent its decision to our users via DocuSign. Our DocuSign defect rate was high, leading to painful user experiences. Since my team was the only one that could fix this long-standing issue, when I was asked to help the application team on a separate issue — automating the collection of a new type of document in our application — I recognized that this request was urgent yet not as important as the DocuSign issue. So I delegated the application team’s request to our customer support partners as a manual workaround. I knew that if we took on this request, it would take longer for us to find a solution for our DocuSign issue.
A request that is important yet not urgent requires special attention, as it can easily slip through the cracks and have long-term consequences if it goes unaddressed.”
What other tips would you offer to a product manager who is struggling to balance the needs of multiple stakeholders?
Documenting requests and their relative priority offers a couple of advantages. Firstly, it forces you to prioritize what is in front of you. Secondly, it becomes a powerful artifact you can easily share with stakeholders to offer them transparency and context into where their needs fall and why.
