Anyone have any successful strategies for giving people pushback or saying no to requests?

Becoming a product manager FAQs
,
1

Has anyone found any strategies which worked well in giving people pushback or declining their requests (not product feature requests but requests from sales, marketing).

I started off with one product. I was able to manage it all effectively enough, until they have now given me a second product. But with so many requests to talk to customers and review documents I never have free time to be proactive. I noticed the other PM’s almost never respond to emails, slacks, Jira tickets etc. I feel kind of unethical about doing that myself. But I’m constantly bombarded by requests from Software Engineering (Software development updates, Patch updates, Deployment Updates, Testing updates, documentation updates, + typical Scrum calls), Sales (Calls with customers, reviewing proposals, Looking at SKU’s, Roadmap calls, problem calls), Marketing (reviewing documentation, campaign planning, working on use cases, roadmap, standard customer decks), and leadership. Individually it’s not a problem, but when all of that each and every week I’m never proactive.

What I have tried was instead of telling people no. I would tell them when I can get to their requests, then they start to fight and argue. Which actually takes more time than doing the work. The same happens if I tell them, it’s not my highest priority.

I tried telling someone I’m only working on my OKR’s this quarter and they dropped the issue. If I just ignore them, they leave me alone. I’m not sure any of those strategies help build strong relationships with those people or teams. I figure there has to be a better strategy. Any tips are greatly appreciated.

I tried to edit it clarify I was looking for strategies around managing the general chaos - and not product enhancement requests that’s not a challenge. Sorry for the confusion.

11 Likes
2

Ask for business justification.

  1. How does this impact business OKRs?
  2. How does this impact the business financially?
  3. What are the associated costs of not doing this? Not doing it by X date?

Based on those you should be able to stack rank projects/asks and once groomed you can put into a rough deployment calendar of when they can expect it to be picked up and in production.

11 Likes
3

@MariaWilson, Yeah, assuming you mean requests for features/changes to be developed (not just requests for you to contribute to something personally with your time and attention), I agree this is a good strategy.

Every internal stakeholder has in mind the thing they would like built because it will help make their job easier or boost their own KPIs, and the thing they’re asking for may not even be the best way to address the valid problem/opportunity they’re focused on. In some cases, they (perhaps accidentally) are making a truly selfish request, where it will help them somehow but not at all be valuable to the business as a whole — given the cost of development and opportunity cost (more valuable things you put off while you make their thing).

And generally, there are requests coming down through your own leadership — which may be based on cross-org alignment they’re driving with their peers in other functions, business units, etc. So, your immediate group of stakeholders are asking you to ignore broader, cross-cutting priorities of the business to do their pet feature request.

I’ve found great success (in a large enterprise environment) by saying/writing something like this in response to feature requests from stakeholders:

“Thanks for suggesting this! I’d love to work with you to try to build a business case to get this onto the roadmap. We’ve already got our roadmap filled in for the next N months/quarters, but there’s certainly possibility to make tradeoffs, if the business case is strong enough to displace existing commitments. We’ll just need to be able to quantify the value of this work, so we can show how why it’s more important than other planned work. Do you have a sense of how we can quantify the value in terms of increased revenue, increased customer retention, lower customer acquisition costs, savings in labor costs, etc.? And where we can find data to build a model to arrive at that $ value?”

Essentially, “I want to help you on this and appreciate you, but we’re BOTH going to have to do work to justify this. And the ball is now in your court.”

This was my go-to response for a few years at a past company, to out-of-band feature requests (i.e., coming from some stakeholder and wasn’t obviously important to prioritize, given the product direction at the time). The most common outcome was that I never heard from them again about that request.

Doesn’t mean they’re bad people, but I found that people commonly wanted to rub the magic lamp and get three wishes, rather than actually do work to make a case for something that is actually high value to the company. This is a way to filter out such requests without burning any good will with the stakeholder.

10 Likes
4

As someone from the other side I can tell you that I’m able to pull a business case out of nothing to justify my request. Same for sales who will always have the key or door opening customer that is worth any work.

10 Likes
5

Thanks for the counterpoint. And honestly, I appreciate when someone is able to make a case like you’re describing. My goal isn’t to get out of doing valuable work, just to filter out the noise of the (often many) folks who are thinking locally about what will help them, without considering the global context that I need to consider to make the product as valuable for the customer and the business as I can. And I want to quickly calibrate their expectations to understand that I’m not arbitrarily saying yes/no based on how I feel or who I like — just trying to do right by our entire business and our customers/users.

Whenever someone comes back to me with what you described, then I’m happy to engage and discuss the validity of the model they’re using, the assumptions they’re making — and figure out how we can refine for further validate them, if needed. Then well informed tradeoff decisions can be made.

An example I recall that differs from what you described, where someone made a request for a change that had no real justification, was at an e-commerce company I worked for. Someone from the Gift Card Ops team wanted work done to enable a special, new kind of gift-card promotional campaign in their specific geographic business unit (one of several geographies the platform supported). The folks asking for it wanted it because it was going to move the needle for their KPIs (purely around the gift card program), but it paled in comparison to the global features my team was already planning for the next year — which would drive much higher revenue lift or keep us compliant with regulatory changes (i.e. allow us to keep operating our business). It wasn’t like it was a waste of time, but the opportunity cost of doing what they wanted would have been way too high.

If that gift card team had done what you described, I would have worked with them to evaluate the ROI of their request and explain how it stacked up against the existing roadmap. But I think they realized immediately that it wasn’t even worth trying to make a measured case for it, because it had no chance of moving the needle for the global performance of the product.

10 Likes
6

Thank you for the detailed answer. I think your example makes clear, that you also have some organizational power to really own the roadmap. In my experience PMs often lack organizational power, even though their job description includes roadmap ownership on paper. It’s not respected. And it’s exactly because they lack organizational power that often makes them puppets of jumping management / sales / commercial request as these teams often have push through powers. You can fight these, but it will burn PMs out and also will definitely result in bad deliverables. As said, I’m from one of these dept and experienced this in various companies. I rarely exploited these powers, but to be fair, I did this as well. I fill out all your user story requests, business impact forms, business case spreadsheets or whatever a PM puts up as a barrier. If they lack organizational power, it will end up on the roadmap no matter what. I know that this is reality for a lot of PM. As management member I always voted for senior titles and high organizational ranks for critical product roles to really enable them to own product responsibilities and not waste their time fighting stupid request and simply say no.

10 Likes
7

Yeah, makes sense. There are so many dimensions of context that can differ for a PM (company size, market, business model, org culture, team structure, etc.), that it can be a radically different job from one to the next. It makes answering these kinds of questions tricky.

I see a lot of posts on here that are like “at my job, it works like this, which is really dumb, right???” My answer is usually something like, “Yeah, that is indeed dumb, but you probably need to either make peace with it or find a different job.” It’s hard to change things in a large org, even if you’re at the top. Let alone from an IC role with no formal authority.

Even in my example, the roadmap I was defending (of which I don’t recall any details), it was probably mostly work that was handed down from the VP level. I didn’t love that, but it was the reality.

9 Likes
8

Adding to this great answer: This works best when the business as a whole has clear goals. If every business unit is not aligned to OKRs or whatever acronym, then everyone is going to be justified in believing their agenda is the priority. Having a clear vision and strategy based on business objectives, as a product team, makes push back easier: they can only justify use of resources that will accomplish the initiatives in your strategy, whether applicable to short, medium or long term goals.

8 Likes
9

Are you asking how to deal with feature requests from stakeholders, or how to get through the day when a hundred people are bothering you?

I also look at their calendars and they have 1-2 hours of meetings/calls a day where I have 5-7 hours back-to-back. I noticed the other PM’s almost never respond to emails, slacks, Jira tickets etc. I feel kind of unethical about doing that myself.

  • Block out 3 hours/day on your calendar for heads down work. During those three hours, close your slack and email windows. This is your time for your focus work
  • Keep email closed most of the day, and/or turn off notifications. Check email 3 times per day - before your first meeting, midday, and end of day. No more than 15ish minutes at a time. If an email response is going to take a while, flag it, and return to it during your focus time.
  • Schedule weekly/biweekly stakeholder sync meetings, and timebox discussions to that time period.

What I have tried was instead of telling people no. I would tell them when I can get to their requests, then they start to fight and argue. Which actually takes more time than doing the work. The same happens if I tell them, it’s not my highest priority. I tried telling someone I’m only working on my OKR’s this quarter and they dropped the issue. If I just ignore them, they leave me alone. I’m not sure any of those strategies help build strong relationships with those people or team’s I figure there has to be a better alternative.

Here’s what I do:

  • Instead of trying to give an answer, ask people questions: “Interesting idea, what do you think value will be?” “do you think this could increase sales?” “Have you talked to many customers about this yet? What did they say?” “We’re planning on working on Feature X soon - do you think this request is more important than X?” If you ask the right questions, they’ll come to same conclusion eventually (or, even better, present evidence that might change your mind!).
  • Present them with your roadmap, ask them if they agree on priorities, or how they would do things differently.
  • If they come to you with something that’s not related to your area, listen to them, then direct them to the right person. “Oh, this is an interesting idea. It’s not in the scope of my product, but it sounds similar to something Sally is working on - let me introduce you to her.”
7 Likes
10

@DhirajMehta, I love this answer.

Also, OP should train people on how to interact with OP.

my strategies:

Generally, I mostly refuse to answer any questions except 1-1 stuff in slack. Slack is poison and the product is bad. Anything in channels is ephemeral.

Second, almost all emails/slacks/jira stuff is subject to a minimum 4 hour response time, particularly when I feel like the question has been answered elsewhere. That gives requesters the opportunity to figure stuff out themselves. I’m also intentionally borderline rude (well, polite once) when the question could have been self-service answered. The simple fact is there’s like 50-ish people I interact with regularly and one of me. So I don’t answer the question and instead point people to where the question was already answered. This, of course, doesn’t work if you don’t do a good job writing prds/docs in google/epics/etc.

Anything I respond to is done in a public space (for me, mostly google docs or the epics. Occasionally on individual tickets but I find those mostly ephemeral as well). If one person has the question, more will.

+1000 on blocking out deep work hours (put that on your calendar, auto-decline and/or ignore people who book over), and be unavailable except for real emergencies. Who can call your cell.

Also, with leadership, OP can bluntly ask when they need X by, and if it’s soon, say why wasn’t I asked earlier. This may not win friends, but it will make OP highly effective. In the long run, good management will prioritize effective people (with some, uh, choppiness between here and there =P ).

The theme is to train people out of expecting they can run to OP and get last second or low effort questions easily and rapidly answered, while remaining available for professionally-acting coworkers.

6 Likes
11

There are a lot of great suggestions here. thanks for taking some time to add your thoughts. I agree with you 100% on prioritization, I’m good with focusing on only the most important things, that is when I can focus and not get distracted :). I think I have a hard time ignoring email and slack, honestly that’s probably half of my problem. I have a second monitor with them both on there. I’ll have to scrap that. I appreciate your insights!

5 Likes
12

Yeah, my goal was to get through the day with 100 people bugging you. Rejecting people’s product ideas is actually pretty painless believe it or not. But people throwing a ton of calls on my calendar back-to-back now that I have two products takes all my cycles. I like your suggestions of blocking time and no email and slack. I think there is a natural tendency to feel like we are ‘online’ and everyone then ends up taking our cycles. It was pretty manageable until my workload doubled. Blocking off my calendar is a great call out. Thanks for your feedback I appreciate it!

5 Likes
13

Welcome to the club. Work will always gravitate to people who are reliable, get things done and accept additional responsibilities.

The unresponsiveness of your PM colleagues might be their strategy to not get overwhelmed with too much work.

Personally, as I value responsiveness and reliability, the only thing which helped me somewhat is distributing more task among the team and blocking part of my calendar to limit the amount of meeting invites I get. And sometimes I just bluntly say no.

5 Likes
14

@YuriRoman, I think that’s a great point that people tend to engage people who are helpful and avoid people who aren’t. Which explains why they are less busy :slight_smile: I just hate the idea of going silent on people, but I guess it’s a strategy for the least important tasks.

I like the blocking off calendar. I do that and it helps prevent people from just sticking things on my calendar some.

4 Likes
15

What has worked for me is to create a space for all those requests and share it with the team (sales, marketing, CS, engineering).

For example, in my last experience, I created a spreadsheet with many columns where everyone could add ideas/request for the product. The spreadsheet had columns like:

  • Name of idea/request
  • Petitioner’s name
  • Explanation about how the idea/request should works
  • Problem that idea/request solve
  • Number of customer who will be impacted
  • Amount ($) that idea/request will bring us
  • Cost to build it (this was filled by product-dev team)

Every time people reached me with a request, I asked them to fill in the spreadsheet with the details, and every Thursday I had a regular weekly meeting with the team(sales, marketing, CS, engineering) to review the different ideas/requests that were added during the week. Each member shared the details of the idea/request added.

My goal was to provide them with information about the number of requests, the cost, and the potential impact on the business.

In the end, this was an exercise of ideas management because a lot of ideas were useful in the future and people felt they had a space to express their ideas. For me, this was great because I got back time and was able to synchronize my OKRs and the requests.

3 Likes
16

@MichaelYoffe, I’ve tried this approach and found it can be challenging when people’s ideas are not actually implemented in a time scale that they believe is reasonable eg if an idea gets put off for 2 years, the person might lose trust and faith even if you are justified. After all, things are changing all the time. How do you manage that?

2 Likes
17

The key is understand and explain why an idea gets put off for a long term. Maybe we don’t have enough supporting evidence or the requestor doesn’t know how to justify it.

In both cases, the ideal is to have a 1-on-1 with the requestor to listen to him and help to justify his ideas better. And the most important thing is to remind him of the common ground (the business outcome).

This is not a competition of ideas; the most important thing is to achieve the outcome, regardless of whether it is possible by his idea, the PM’s, or anyone else’s.

1 Like
18

This is the way. I have a Product Opportunity Assessment that I ask the requestor to fill out with business justification backed by data. 50% of the time they just move on. If they ask later, I ask for the POA. If it’s a really good idea or a request from a higher up, I will fill out the POA myself and add it to the backlog for evaluation.