3 Agile-Friendly Ways to Say No to Feature Requests

3 Agile-Friendly Ways to Say No to Feature Requests

I recently interviewed a product manager from a well-established company. I was curious about how they handled feature requests and asked if there were ever times when the PO needed to say no to feature requests. I was floored with his reply: “No,” he said. “I prefer not to work at a company where we say no to requests.”

Sounds nice, right? Unfortunately, good product management means saying no frequently, and every agile team should know that regularly rejecting feature requests is an important part to creating a sustainable, effective product.

After all, one of the 12 principles of agile software says, “Simplicity--the art of maximizing the amount of work not done--is essential.”

To illustrate why saying no is actually a crucial aspect of agile best practices and to provide helpful ways to rationalize rejection, here are three common examples of when a good agile practitioner should reject a feature request.

Scenario 1: The Feature Request Serves Only the Loud Few

Your restaurant customers in Maine are asking for a system-wide alert any time there’s a lobster shortage. Everyone needs to know when it’s time to start hoarding lobster, right?

Well, if your product is serving the entire United States, most regions don’t have a lobster-heavy restaurant industry, and Maine only represents 0.42 percent of the country’s population. You might instead want to build a feature that serves both Maine and the rest of your customer base.

Ways to address:

  • Check with a larger sample size of customers
  • Check the value of the customers—are they customers you can’t afford to lose? Or users who signed up for a free trial and aren’t paying?
  • Check to see if the change could negatively impact customers who didn’t request it
  • Opportunity cost: Bust out the microeconomic theory. Are there other features in your backlog that could deliver more value to more customers?

The agile angle:

  • Simplicity is essential
  • Deliver more value with features that benefit more users, or more valuable users

Scenario 2: The Feature Request Does Not Scale

A feature request comes in that requires you to set up a new public API with a huge volume of constant API requests. Your servers can handle it for the first few pilot customers, but if you try to roll it out to all of your current customers, your API service will be overloaded with requests. Your colleague asks you to add more server resources and a dedicated team to support the API, but customers aren’t paying anything additional for this service. The feature request does not scale, and if no one is willing to pay for the feature, chances are it’s not adding enough value.

Ways to address:

  • Ask your team to envision or simulate rolling the feature out on a larger scale. If it succeeds, can you afford to sustain it?
  • Ask for proof of concept that shows the customer truly values the feature, i.e., they’re willing to pay for it or it’s needed to reduce customer attrition

The agile angle:

  • Agile processes promote sustainable development

Scenario 3: The Feature Request is in the Contract, So it Must be Done

Your client asked for a feature and is ready to pay you to build it, so you should definitely build it, right? Actually, the customer might not know that there’s a better solution that could save them time and cost, while also delivering additional value.

As the agile practitioner, it’s your responsibility to collaborate with the customer to inform them if you believe a feature will not deliver value to them or if there’s a faster, more valuable, or more sustainable way to satisfy their user story.

Ways to address:

  • Take a few minutes to see if there’s an obvious solution that’s stronger
  • Don’t stay silent, inform the customer of potentially better solutions and explain how it would deliver more value to them in a shorter period of time
  • If necessary, explain to them why adapting to a better solution is usually better than sticking to a weaker original plan

The agile angle:

  • Customer collaboration over contract negotiation is one of the four values of the Agile Manifesto
  • Responding to change over following a plan is another core value of agile
  • An agile-friendly customer should value collaboration and responding to change, especially if they’re internal to your team or company
  • Delivering more value on a shorter time scale is consistent with agile principles


Regularly reflecting on how to become more effective as a team is yet another agile principle we should all adhere to.

Think about your own pursuit of being an efficiently functioning agile team. Do you find yourself saying no to feature requests periodically? What are some of the most common cases for you, and how do you address them in a way that’s consistent with agile best practices?

Let me know in the comments below.


Ken Shen Robinson is a senior product manager at Praetorian Digital, where he leads product management for EdTech products that make our communities smarter and safer.

Learn More
comments powered by Disqus