Saying no

When working as a leader, and espeically in roles where you handle priorities (such as product management roles), one must be able to say no requests, while at the same time being emptathic to what’s being asked. There are many great ideas out there, but we cannot do them all at once. So, let’s say you get a big request that your team does not have the bandwith to jump on. How do you respond?

What you don’t want to do, is straight out say no. That’s too hard, and won’t come across as empathetic. We rather want to build a story about what we are building or doing , and how that might benefit the organization. My first steps when asked to deliver on something, I usually do this:

1. Show our goals: What are we currently trying to achieve.
2. Show the roadmap: Here’s our goals, and the activities layed out to fulfill those goals. Show what we’re doing, and/or ask what they believe must be removed.
3. Show what you’ve delivered: I move goals and acitivites to a page where I note down when we delivered on it. I use it to show what we have spent our time on over the last months.

This is the beginning of a story around what we are aiming to do, and what we did to go there. Can the requester see their request fit into that story?

Last but not least, I show what can be done to improve the chances of being prioritised. In my experience, stakeholders are willing to invest more in your team or area, but they are unaware of the option. Showing that option, how they can help us get bandwidth to address their issue, is a great approach. But, I would not open with it. If you open with it, the response is usually something along the lines of “but what about your current funding?”