Permit yourself to say NO without feeling guilty.
I have been leading the maintenance project of a product, which is out in the market for last 15+ years and counting its retirement days by end of this year, so it’s really on the last phase of its life. For the last 3 years, during its sunset phase, there have been numerous requests for new functionality support, new process request to redesigning requests, and I had the job to say “No”. Day in, day out.
Those requests came from the customers, customer’s customer, different stakeholders and sometimes from the design teams.
The art of telling “No” has taught me a few interesting tips.
Just for clear demarkation, note that my “No” is pertinent to new functionality requests/ideas only. Any production bugs are handled as quality issues, where I am the first one to say “Yes”.
A typical scenario
Let’s start with a typical example. So when a customer/stakeholder requested for a new feature you typically answer with five great words ( read like your favourite sentence) as -
We will look into it.
You feel happy and satisfied to have pushed out the problem.
You thought the customer will go off, he/she will never ask you about the update. However, what your customer heard is -
I am working to get this delivered to you.
That’s where, my reader, the first discrepancy starts. After a few months, you forget about it and your customer is expecting it to come. Eventually, it ends with misunderstanding and frustration.
So what’s wrong in this whole scheme of things? Let me explain with the aid of my fav “three-word” framework,i.e. Transparency, Inspection and Adaptation.
When any stakeholders provide the new requirement for functionality or even ideas, first understood the problem clearly. Ask for more explanation /details/ clarity until you understood the primary pain point(or the reason behind) for the idea. Allow the customer to explain the problem to you. As much as it is important for you to understand the problem, it is also equally important to allow the stakeholder to share the problem. As my junior says “Sharing is caring”.
It is also important for you to listen to the problem clearly via active listening. Listening with all your senses, listening to understand with an open mind, and not with an intention to just respond.
First try to summarize the problem, re-summarize the problem in your own words and then repeat it back to the stakeholder. This will make the stakeholder happy that they have successfully expressed the need to you, you have acknowledged the problem and you have given the idea ( and the person) enough importance to consider it for evaluation.
Next comes the important part to evaluate the idea/requirement —
- Evaluate the request as it can be of any type, like function request, process change request or better efficiency request.
- You need to look into the cost, effectiveness, efficiency, rationality along with product roadmap, strategy and business needs.
- You can also map this with organization alignment, and look at project/products goals and objectives.
All data points may or may not be readily available and would need further deep dives.
- Further, you need to evaluate the re-priority if this idea is to be implemented then what needs to be given up.
- Check with the design teams for the technical debts which it’ll create in future.
For all outputs, if you need to jot down the points, then do it and start making your response ready with key justifications.
Now is your time to act to respond to your stakeholder to summarize the situation with your analysis and explain your decision as “No”.
You need to be as humble yet firm. While being appreciative of the idea and acknowledge that you would love to get more ideas in future, you need to present the “No” now without fluffing around.
If possible, you can propose any viable workaround or an alternative option which can benefit the requester.
Don’t take unnecessary time to communicate. The more delay you make, the expectation is going to increase on the other side.
While communicating the decision, you try to avoid the usage of the word “I” and stay clear from showing that you are making the decision.
Try to avoid lines like “I decided that this idea is…” or “ I don’t see this idea going forward…”
Instead, you need to communicate based on XYZ reasons coming from the evaluation phase.
Hence, you can use lines like “ XYX reason are indicating towards a decision to reject…” or “ ABC data shows that the alternative idea is more beneficial than yours ….”
“No” to a hundred other good ideas
Coming back to my product on sunset mode, there have been thousands ( not hundreds!) of good ideas which were proposed, but just that those came at the wrong time where product strategy/cost/project goals were in opposite direction.
In summary, whether saying “it’s outside my sphere of influence…” or providing enough justification to protect priority, your judgment on saying “No” will depend on explanations to your stakeholders in a timely fashion.
Let me remind the great words of Steve Jobs where he said -
“People think focus means saying yes to the thing you’ve got to focus on. But that’s not what it means at all. It means saying no to the hundred other good ideas that there are. You have to pick carefully.”