We’re in this together . And I wholeheartedly agree- saying yes all the time seems to condition people to expect a yes from you (including your manager and everyone else).
Something I’ve tried experimenting with is letting unimportant requests.
We’re in this together . And I wholeheartedly agree- saying yes all the time seems to condition people to expect a yes from you (including your manager and everyone else).
Something I’ve tried experimenting with is letting unimportant requests.
Here are a few things you might want to read and follow carefully.
Understand and talk about the issue. Then say, let me slack you later about this. Having to respond in the moment will take the pressure off and help you craft a better answer later.
Present the bill. When you do share the estimate, don’t say no. Say it can be done at X time, this is the roadmap, this is where it fits. Then they can see the logic behind why it can’t be done sooner. If they want it sooner, say great. Let me setup time with X task owner, we can chat with them about pushing out their task so that we can do this instead.
They’re always going to push. That’s their job. You should be bringing as much reality to the situation as possible. Use wireframes and designs to do early validation. Get features designed and scoped. Break it down and estimate using your team’s velocity. Work with the team to get better at planning delivery. Work with stakeholders to validate assumptions up front. Communicate. Bring clarity.
Manage your backlog. Both for the company and yourself. When you get a request, try to get clarity on where it should fall in the order. Make it visual, like in JIRA, google sheets, etc.
Never set a timeline for delivery without firm verification from your tech lead… And even then consider adding a 3 week buffer. Done may mean from the development side and not account for testing.
Your strongest defense a good offence. Have a vision that inspires and excited people so that when they ask for these things you can go back to that vision and if it aligns dig into it and if not say not now or no. This vision needs to be broadly known and bought into for this to work.
Saying no is a staple of product management that will never go away. Remember, saying yes to one thing means saying no to 100 other things and it’s your job to be confident that you’re saying yes to the right things. Absolute worst case, data and math win arguments.
I hope these will help.
As others have said, you’re in charge of expectations. This mostly means making them feel heard (“okay, let’s align it on the roadmap against other priorities”), asking about compromises (if this goes in, what goes out?), backlogging items to be refined for a Definition of Ready (is it clear enough that it could be taken in by the team?), and ultimately finding polite ways to say no.
@MichaelYoffe, Thanks this is great feedback. I’ve learned the hard way you often need to tell your manager how to diagnose workload issues for them (getting dedicated resources for last second requests)- otherwise they’ll put their hands up and say some shit about why you NEED to get something done.
Thank you all for the great advices, Been a great help.
This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.