Tactfully Rejecting Feature Requests: The Art of Saying a “Positive No”

Manage your stakeholder’s with ease with this simple checklist

---

Photo by Daniel Bradley on Unsplash

We’ve all seen this: a backlog composed of at least 2 to 3 months of commitments, and a seemingly endless supply of issues and requests coming in from internal and external stakeholders.

You then receive one or more “urgent” or “high priority” issues from your CEO, Sales, or Leadership team, asking for you to stretch your capacity one more time to take on some new item of work.

How can product professionals respond to the ebb and flow of incoming work items and feature requests? We know that the key is to say “no”, but how do we do this in a compelling yet respectful way?

Offered below is a few steps you can take to quickly understand whether to accept or reject incoming requests, as well as a method for communicating a “Positive No” that is both respectful and solution-oriented.

---

Importance and impact of “yes” versus “no”

According to William L. Ury, adviser, conflict mediator, Fellow of the Harvard Negotiation Project, and co-founder of the Harvard Program on Negotiation, any “yes” answers should be preserved for only the critical of circumstances, and any “no” answers should be positive in nature.

Ury learned the above from negotiation scenarios, such as war events in the Middle East, the Balkans, and the former Soviet Union. He states:

“No” is the key to defining your strategic focus. Every important “Yes”, therefore, may require a thousand No’s — William L. Ury

In Ury’s book, The Power of a Positive No: How to Say No and Still Get to Yes, he suggests that all humans naturally say “no” in three main ways:

1. Accommodation — We say “Yes” when we want to say “No”. This usually comes when we value the relationship of the other party well above the importance of our own interests.

2. Attack — We say “no”, but we do it poorly, often due to valuing our own interests above the importance of the relationship with the other party. Sometimes we are fearful of the request and overreact.

3. Avoidance — We say nothing at all because we are afraid of offending the other party hoping the problem will go away, and it rarely does.

When reflecting on my professional and personal relationships where requests needed to be fulfilled, I can definitely see myself performing a combination of the three above. We often change from one to another, depending on the situation.

Ury suggests that we construct a “Positive No” when we have to say no. But how does one know whether the answer is yes or no to a feature request? This comes down to your business and product objectives, the alignment of the request to these objectives, and the level of data or confidence we have in the validity of the idea or request. Let’s take each of these in turn:

---

Step 1. Revisit shared business and product objectives

Photo by Isaac Smith on Unsplash

Company objectives typically cascade down from the leadership team to the rest of your Product organisation in the form of strategy, vision and roadmap. I wrote about this previously in the article: Creating your first product roadmap.

Whether you use Key Performance Indicators (KPIs) or the Objectives/Key Results (OKRs), goals should typically be derived from a set of common or shared objectives. If they aren’t, then your organisation’s goal-setting approach probably should be revisited.

For the case where strategic priorities need to change drastically due to major events or externalities, pandemics included, one may argue that your objectives need to change.

For example, instead of focussing primarily on high cost-to-acquire user growth, perhaps you now need to focus on user retention instead. A shift in strategic objectives and priorities is fine, but care should be taken to ensure the business isn’t being attracted towards the shiny object / next feature fallacy.

Given that any management decision, inclusive of Product Management, should align with your shared company objectives, any idea that isn’t aligned with these is far easier to reject. However, when you are faced with many requests that do align with your strategic objectives, what should a product manager do? The answer to this lies in data and evidence and hypothesis testing.

---

Step 2. Check for supporting data and evidence

A feature request should have some underlying reason or logic behind it. Given that product Managers tend to work on hypothesis-based discovery, it is our responsibility to validate or nullify the hypothesis (i.e., that some problem should be solved using proposed XYZ solution) using the data available.

Let’s suppose a feature request has come externally from a customer, or internally from sales or customer success teams. A product manager’s natural line of thought should be:

• What problem is being solved? What data or evidence exists to show that this is the correct problem worth solving?

• What value is being delivered? What data or evidence suggests that we will bring value to our customers?

• Why this and why now?

If your stakeholders are unable to produce the data needed to validate the problem, you have more justification for saying “no”.

Photo By DragonImages on Envato Elements

There are a few ways you can frame your data and logic to validate your problem and value statements, based primarily off the three commonly understood types of logical reasoning:

Deductive reasoning

Using a given set of facts or data to deduce other facts from; this can be used to prove that the new facts are true. For example:

Major premise: The refunds page contains too many steps
Minor premise: When UIs have too many steps, users are extremely dissatisfied
Conclusion: The refunds page is causing extreme customer dissatisfaction

Inductive reasoning

Looking for a pattern or a trend and then generalizing it. When you generalize and extrapolate the information, you don’t know for sure if this trend will continue, but you assume it will. For example:

“From a survey we conducted to 1,000 existing users, 83% of respondents found it difficult to find a customer record on our portals. Therefore, all of users seem to find it difficult to find a customer record on our portals”

Abductive reasoning

In abductive reasoning, it is presumed that the most plausible conclusion is also the correct one. Similar to inductive reasoning, this method combines guessing, data and observations to infer some premise or conclusion.

For example:

Major premise: Our competitor’s checkout page has many fields to fill out before you can successfully complete a purchase transaction.
Minor premise: Checkout pages with fewer than 4 fields on final payment page results in 80% conversion.
Conclusion: The competitor’s checkout page must have very low conversion rates. If we create a simpler checkout page, we can convince the prospective customer to adopt our ‘higher conversion’ solution instead.

Irrespective of the type of reasoning used, jot down your data points so that in your next backlog review, you can refer to them in your evaluation of whether to say “yes” or “no”.

---

Step 3. Take action based on Evidence vs Alignment

Now that you have an understanding of the amount of evidence justifying the idea, and have revisited your shared objectives, you can do a quick assessment as to where the feature request lies before taking appropriate action.

Introducing the Evidence vs Alignment matrix, which suggests that you perform one of four distinct actions:

1. Negotiate — when you have a high degree of evidence and high alignment

2. Investigate — when you have a low degree of evidence and high alignment

3. Educate — when you have a high degree of evidence and low alignment

4. Reject — when you have a low degree of evidence and low alignment

Of the two criteria of alignment vs evidence, strategic alignment is by far the more important characteristic to make your decision. Consider potentially saying “yes” when there’s high alignment, regardless of the evidence available or presented, and consider saying a “Positive No” should there be low alignment.

A 2x2 matrix to help you decide whether to potentially say “yes” or a “positive no” — Illustration by me

1. Negotiate (high evidence, high alignment)