The most common advice to PMs is to “learn to say no” or “say no more than you say yes” or something similar.
Rarely does anyone talk about “how to say no”.
I would love to hear from you what are some of the things that have worked for you when you “say no” to your stakeholders.
A few things that work for me (in no particular order):
-
Always talk data. Show data/research that justifies the priority of things. What you are working on right now is more important than all other things. Have a good way to show that to others.
-
Don’t be an ass about it. Listen, understand the reason why the ask is important in their mind.
-
Ask a lot of really genuine questions. Ask why is it important, why now, what if we did this later. This
a. Helps you get more clarity
b. Pushes the stakeholder to objectively question their own ask
-
Communicate effectively. Sometimes, I feel that communicating the priorities, goals and the plan effectively is enough for the stakeholders to understand why you’re saying no to their ask.
15 Likes
Be transparent about what you are prioritizing and saying “Yes” to and why.
15 Likes
@KaranTrivedi, This is one of the few things I enjoy about SAFe, we have our prio set for a full quarter, and injecting work into that plan forces a conversation about what planned work will slip as a result of re-prio.
Frequently people assume Agile means you get to pivot the team daily based on the fire of the day. Having this extra step of rigidity has allowed my team to deliver big functional features close to estimate, which is all the C-level really measures us on as a dev team.
14 Likes
@YuriRoman, Safe is just waterfall with an agile haircut though
13 Likes
That is true, as I said, this is one of the few things I like about SAFe. When you have a ton of dependencies you can’t be truly agile but can be nimble with SAFe.
13 Likes
My experience is mixed
Like you said it’s nice that you have that additional safeguard of “we planned the whole next three months do you really want to disrupt that?” Also, good you get PI planning and the time to think about dependencies even though I think there’s too much gaming around team velocity etc. At my current place we do scrum but instituted feature planning in such a way it’s effectively bastardised safe
However, where we actually instituted safe, I was on a safe train with 12 concurrent feature teams and syncs alone would take hours of my time a week.
13 Likes
I have had the most success when numbers are involved.
Recently a senior stakeholder did a drive by to my tiny team with a “game changer idea”. I told her to come to our weekly prioritization meeting and flesh it out with us. She did, we got excited outlining it, and a lot of good conversation.
But the last step is scoring estimated impact against our north star (very similar to RICE). I had her estimate each variable and just accepted them face value. The result was her idea scored very low. So, we rescored it…aggressively. Still low. So we opened a higher scoring idea to check those assumptions… she agreed with them.
The meeting ended with her literally saying “yeah, I guess this isn’t worth doing” and later publicly backing our current best idea in-development.
12 Likes
@RobMartin, Can’t underestimate the value of having the stakeholder be the one who says “no” to their own idea…
11 Likes
One thing I’ve done to handle stakeholders who frequently dump piles of requests on our team is to make a separate little backlog to share it with them and spend time having them prioritize all their requests from top to bottom - or at least picking out the top few.
If one of them is valuable and worth the effort, I make it clear that we will focus our time on completing that work before moving on to something else. That way if a new request comes in, I can ask “is this more important than what we’re doing now?” If not, it just goes to the backlog. It also means that if I decide to prioritize none of their work, I only need to fight off the top few requests rather than having to prove that every request in their list is a lower priority.
Spoiler alert: after doing this exercise, the requests and questions slow down, and I only ever commit to working on a small number of them anyway. The key is to have them spend some of their time prioritizing the things they ask for too, rather than you are doing it all. Makes them second guess the value of some requests.
10 Likes
If it becomes a “re-prioritization” request, my first response would be that this likely implies skipping the line on an agreed upon order and that re-alignment is needed. then I ask what data/circumstance changed that warrants a reshuffle. if there’s valid data, good, we can react to change whenever possible. but since it’s basically a challenge to set priorities and should be treated seriously, but very deliberate not to establish new norms/side-processes.
For other requests outside any prioritization processes impact and urgency are good indicators. especially in b2b SaaS world, many such requests originate from a sales-client conversation that I haven’t been part of where a client said they want something, and the salesperson submits this. this is but one data point and impact assessment is done on whether it’s a request that fits to the product (and therefore a larger set of clients potentially) or a specific customer request that down the line makes us a “chop-shop” for our clients.
Since roadmaps or goals are usually hopefully universally, shared & transparent, I will have to assume that people are aware about what’s on our plate and when they raise something that is not reflected there, they better come with arguments & data to not waste anyone’s time
9 Likes
All excellent suggestions from the OP (@RohitKumar). For me, the big questions I always want to ask before saying no to anything come down to expected outcomes:
- How does this idea [improve, fix, enhance, strengthen] our [products, services, CX, market standing]?
- What do successful outcomes look like 3/6/9/12 months after release?
- In 3 years, are we still supporting this and if so, how? Will it still generate something positive?
- If we chose to build this, are you willing to be the champion of this and represent it to our customers and our board?
If a stakeholder cannot answer these questions in a cogent and meaningful way, you thank them and say that when they’ve got the answers, you’ll be more than happy to hear them out again. 80% of the time, it ends there. The other 20% is when you discover how diligent and strategic, they are.
7 Likes
100% true and very effective.
True story → sales leaders get nervous about championing the new feature or committing to the goals (in your point 2). Then, they believe that the PM has got it in control. Or they become better team players and help in enriching product roadmaps and business goals.
7 Likes
I like to say, “let us take this away and look at the level of effort” and then come back with a rough idea of time and effort but more importantly what would need to be reprioritized and the tradeoffs. If you come back showing that you’ve taken it under consideration and here are the reasons why it isn’t a good idea (percentage of user base impacted versus effort, other priorities shifted that are more important) you can get the stakeholder on your side. RICE is good for walking them through this
7 Likes
I’ve found myself saying two things very often:
“You request is a when, not if thing.” Oftentimes I get requests that are already considered. I’ve found this is a more accurate and friendly way to say “not right now”.
Related to above: I’ve found myself saying “order of operations” a lot. Ie… it doesn’t make sense to do X before Y. We are working on Y.
There are also a whole host of folks that love being the idea guys and then expecting me to execute it. I have to keep myself from being annoyed reactively here. I’m trying to get better at not saying “no”. But rather saying: “pitch me”. Put on a VC hat and listen.
98% of the time it’s a thought, without much ROI analysis.
But I mean. One effective tool I’ve experimented with is literally just ignoring the first request. If you need me to say yes to something, show me you care enough about it to ask me twice.
Be careful though… it’s hard. Because, at least for me, I genuinely appreciate the crowd sourced thoughts and ideas. I don’t want to scare off good ideas by becoming a “no man”.
Lastly, maybe I’m just odd. But there’s also just “don’t do it”. If you truly believe it shouldn’t be done and it’s sucking up your valued time… let it get escalated and squash it then.
Be ok with folks not liking it. Don’t expect them to be happy you said no. Don’t expect them to not complain. At the end of the day if you’re doing your job right, the business as a whole is better off. Over time more folks will naturally trust your judgement.
6 Likes
A clearly defined roadmap, carefully planned sprints, and a regular release cadence helps a lot. Being able to visually point out why something is a no becomes easy when you can show how it will impact other priorities. Sometimes, it’s acceptable to make the change or request happen. Other times, the answer is clear that their request or idea just isn’t in the cards, and it can be added to a running log of ideas for future consideration.
If the idea is plain stupid and doesn’t warrant consideration, it’s a different conversation.
5 Likes
This is all good advice. It’s a tough thing to do.
When I first started a few years ago, I would tell our clients or other stakeholders we simply do not have the resources to support that right now with everything else we have going on. Understandably, the founder of our company mentioned that we should probably not tell people we don’t have enough resources. There’s probably a better way to say it. without sounding like we are a tiny company.
While this may not apply to all industries, in the software industry, if you have a robust API, you can really push back on anybody that wants you to build some thing. You can always say “that’s a great idea why don’t you use our API to make that a reality and we can feature it as a success story for other API users.”
I would much rather add functionality to our API that can be used again and again then build out one thing for one person or one company.
The same founder hit the nail on the head when he said “we can’t write all of the software under the sun, but if we have a good enough API anyone can write any software they want utilizing our data structures and algorithms.”
4 Likes
@VladPodpoly, Despite having the API available I heard the part about “we don’t have internal resources to build this for the next X months, so we really need you to build it” from customers many times. they can’t or don’t want to deal with these kinds of projects themselves and expect you to make it, not realizing that it will dilute your product, but also detract from your focus and will take you also many weeks or months sometimes.
4 Likes
The trick in saying ‘no’ is to keep the engagement going, after all this is a highly engaged customer/user/stakeholder.
Usually, it’s best to first seek clarity about the request before saying no. A misunderstanding may be involved.
Typical reasons for saying no: feature already exists, bug, strategy misalignment, covered in another way or by partner.
Taken from Decline customer requests and politely say ‘no’
4 Likes
Ask why a few times and see if you can address their request in a lower lift way or a way that doesn’t involved product changes.
If what is being prioritized is also primarily to service this stakeholder, lay out the tradeoff and make them negotiate against themselves.
If the priority is in support of a different stakeholder and goal, reference the business or product strategy and explain why this priority takes precedence.
Try not to give too many reasons to say no and only give strong reasons, preferably 1. Giving too many reasons invites the stakeholder to pick the weakest one and go after it.
3 Likes
Lots of great advice here so I’ll be brief and just list my most frequently used strategy.
lists items currently being worked on “What would you like to take off the table?”
Frequently, I find, these requests are made in a vacuum wherein they are great. But we’re also the arbiters of opportunity cost, and a lot of value is derived from raising this awareness.
2 Likes