Tactfully Rejecting Feature Requests
By: Andrew Quan
Tags: Strategy, Business, Decision Making, Product Management, Customer Service

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:

Negotiate — when you have a high degree of evidence and high alignment Investigate — when you have a low degree of evidence and high alignment Educate — when you have a high degree of evidence and low alignment 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)

In the scenario where there is a high degree of evidence (and confidence behind this evidence) and a high degree of alignment, you should start negotiating with your stakeholders to describe the trade-offs of accepting the request, particularly if you accept it into your backlog immediately.

Statements such as “We believe that (this request) is also as important as the other items in our backlog, but we cannot do both at the same time” come to mind. Product managers can also introduce prioritisation methods to decide whether to accept the request now or delay it to another time.

This quadrant is essentially a “yes, but…” answer to express the trade-offs. It could be argued that in no other quadrant would you ever say “yes” to the incoming feature request.

2. Investigate (high alignment, low evidence)

In the scenario that there is a low degree of evidence, but a high amount of alignment with your strategic objectives, product managers can hold off accepting the request until more data is gathered. This is so that you can collectively gain more confidence that the problem or solution proposed is worth accepting.

Product managers can act collaboratively in this scenario: we can identify various hypotheses we should be testing, with some low-cost methods or experiments to test them. Based on the data collected, we can then investigate further before reviewing the idea again in the next backlog grooming session.

3. Educate (low alignment, high evidence)

In this scenario, we have a potential candidate for a “Positive No”. Here, there is a low alignment to your strategic priorities, but a high degree of evidence; hence, product managers must focus on educating their stakeholders on existing priorities and why. Education can be in various ways, such as:

Constantly communicating reasons, purpose, and priorities of existing initiatives;

Product artefacts such as manifestos, product roadmaps, and product vision boards that explain objectives and the ‘why’; or

Formal or informal presentations showcasing new and upcoming features, outlining the context, background and the “why” certain features are being released

The act of educating needs to be tactful and respectful. For a team member to not be in alignment with some specific business objective should be uncommon. If this persists (e.g., they do not budge nor commit to a shared objective held by other team members), you may have to resolve your differences through involving your leaders who can manage any dissenting views on your behalf.

Before saying no, read through the “Reject” scenario below, before applying your Positive No (aka the “Yes-No-Yes” method) described later in the article.

4. Reject (low evidence and low alignment)

In the scenario that a feature request has low evidence and low alignment, it is an easy decision. Simply reject the feature request, but still apply a “positive no” mindset, explained below.