Learning to say NO to adhoc feature requests as a product manager
Its rare that your boss asks you to build something and you respond with — I would not recommend building this now.
But the day you do this, you become a badass product manager — because you have finally developed a spine and learnt the art of saying NO.
So, let’s revisit one of those days from my life.
One afternoon, my boss messaged me and said — “Let’s build this feature*.”
*The feature was about automating one of the product workflows. Every time a customer had to use this workflow, they had to reach out to the support team and get it enabled manually.
My boss had a strong argument in favor of building the workflow.
The workflow was used by our biggest customer (contributing approximately 15% to our revenue), who now wanted to automate this workflow rather than rely on support.
But I didn’t yield immediately.
I borrowed some time and spent a few hours researching about the request.
This is what my research yielded.
1. The customer had just renewed. So, they were not a churn risk.
2. Developing the automation was not straightforward — It would require about 3 weeks of development and testing effort.
3. There were hardly 4–5 customers who were using the workflow. So automating the workflow was not expected to benefit many customers.
Based on this, I went to my boss and said those magical words.
I would recommend not to prioritize this feature.
We had a brief discussion and my boss agreed with my assessment.
And that’s how I became a badass PM by learning to say no and avoiding to build a feature that wouldn’t generate much business ROI.
Obviously, not all “don’t build this” recommendations are accepted so easily.
There will be times when the “don’t build this” recommendation will ignite furious debate. Your recommendation might be rejected. And, as they say at Amazon, you would have to disagree and commit.
But whether the recommendation is accepted or not is beside the point. What matters is — whether you debate ad-hoc feature requests or do you meekly submit.
Learning the art of saying no will help your team minimize distractions and ship faster.
Why might you be hesitant in saying NO to a feature request from the boss?
- You think your boss would get angry if you say no —Well, If the feature doesn’t do well they will get angry anyway. So, better risk their wrath early on.
- It’s a small request and we should just do it — That’s a terrible justification. If its a meaningful request, then do it by all means. But not because its a “small request”.
- Building the feature might be a good idea — That’s a lazy argument to wiggle out of a discussion. Spend some time gathering evidence before forming an opinion on whether the feature is a good idea or not.
Steps to deal with an ad-hoc feature request
1. Understand the rationale behind the request
- Don’t just focus on the “what”. Understand the “why” behind the request.
- Is the request directly coming from the customer or is it a “cool idea” from the boss?
- What makes your boss convinced that this should be built now?
- Does the request align with the company’s strategy and target customer segment?
2. Understand the possible solutions to the problem
Your boss doesn’t want a feature. They want to solve a problem. There could be simpler ways to solve the problem. Or there could be workarounds to partially solve the problem.
- Have you given a thought to the workarounds that could be implemented without much development effort?
- Have you explored solutions to this problem in the past? What was the conclusion?
3. Get a better understanding of the business impact and development effort involved
- Dig into past data to see if customers have asked for the feature or reported the underlying problem.
- Check with your support or sales team to know whether a similar feature has been asked in the past?
- Discuss with development team(s) on the complexity of building the feature.
If you do the above diligently, you will have sufficient details to frame an opinion about the urgency of the feature. Take a decision based on what you think is in the long-term interests of the company.
Finally, its time to go back with a recommendation to your boss.
Crafting the response
It’s not what you say. Its how you say it.
Use the evidence gathered to decide whether the feature should be build now or not.
If you are giving a “don’t do this” recommendation, avoid the following mistakes.
- Not giving solid evidence to back your claim — You can’t reason with the boss on the basis of opinions. They will always find a way to shoot you down. So, make sure you have a data backed or customer research backed opinion.
- Hurting the boss’ ego by making it personal — Nobody likes to hear a “No” for the work they assign.
- Use your words carefully — For eg. I use a phrase like “I would recommend not to prioritize it” to show who is in charge.
- Voice disagreement with the boss in private — If a request is made publicly and I am leaning towards rejecting it, I would engage in a private conversation with the boss and share my reasoning with them.
- Not highlight the opportunity cost of building the feature — If the boss is adamant on prioritising something, highlight what project(s) you will de-prioritize in order to fulfill the request. Leadership is often unaware that the development team is already packed with tasks and its a question of “whether this or that”.
Once you give a “don’t do this” recommendation, it will likely spark a spirited discussion. Don’t be afraid of that. State your points gracefully and respectfully. This way, whatever decision you arrive at, will be in the best interests of the company.
Remember: There may be many reasons to build a feature but “just because the boss said so” should never be one of them.