Reconsidering the “no” (follow-up post)

It’s been over three years since I published a post about “saying no for the greater good”. The overall idea of the article is that you shouldn’t be afraid to say no – whether it’s to a specific feature, a project, or a prospect. Always keep the end goal in mind: delivering the best possible product and services to the right customers. I am, of course, not the only one who supports this view. In fact, a Google search for “saying no to a feature request” renders over a billion results (try it!). I thought it might be a good time to elaborate on the topic and point out why simply saying no might not be enough. 

Identify the reason for the no

Be honest with yourself and your team members. Is the reason for the “no” completely based on what’s best for the product and/or the customer, or could there be another underlying factor that influenced you, such as reluctance to push your team, personal preference, or risk averseness? I highly recommend keeping track of every no and capturing the reasons, so that you commit to an analysis of individual items and any patterns that might crystalize in the process. 

No, but…

There certainly doesn’t have to be a yes for every no. However, consider where you can say “no, but…” instead. We may not be in a position to agree to these contract terms, but we can compromise on a particular item that is important to the customer and let them have the last win. We don’t have the bandwidth to take on this particular project, but if you’re open, we can collaborate with a contractor. This particular feature is not feasible for us to implement, but we are considering this connector in order for our customers to use best of breed tools to achieve a particular objective. Your default should not be a “no” full stop. 

Consider the consequences of a no

As you weigh the pros and cons of a specific request, don’t forget to evaluate the potential consequences of saying no. Sure, you should ask yourself what the return on investment will be (“How many new opportunities will this bring?”), but also think about how a “no” might negatively impact you (“What will happen if we don’t do this?”). 

Adjust to the times

As a leader, you need to widen your scope of evaluating factors that inform your strategy. It’s not just things in your immediate periphery, such as your industry or technology trends, but you also have to look at broader factors such as the state of the economy, current and upcoming legislation, and yes, even a pandemic. In a climate where stress is high and budgets are tight, you may have to rethink some of the views you’ve had before, and adjust as needed. Where you would have said “no” before, a “yes”, “maybe”, or “no, but” might be more appropriate now. Always be agile. 

There is nothing wrong with saying “no” to a feature, a project, a contract term, a price, or even a customer. You have to be able to do it – and do it frequently. But do it for the right reasons. Always strive to find an alignment of what’s best for your customers and what’s best for your company. They are not opposing objectives. 

What about you? How have your thoughts on saying “no” evolved?