Lutz Mueller

Lutz Mueller

I help companies to bring their products to market faster through agile product development.

By teaching and applying agile development methods and techniques, I enable my customers to develop products in shorter development cycles with faster customer feedback.

Together we implement product metrics to validate business hypotheses and develop products that customers really want.

By creating a continuous improvement environment with supportive metrics, my clients get a robust feedback mechanism to increase flow, decrease latency, and build a learning culture.


By the end of this article, you can decline requests from stakeholders to keep your backlog clean and manageable. Your stakeholders will understand why you reject their requests without being annoyed or pissed off. That will strengthen your role as a Product Owner, and you gain respect and trust.

How to Decline a Stakeholder’s Request Without Pissing Them Off

By Lutz Mueller

By the end of this article, you can decline requests from stakeholders to keep your backlog clean and manageable. Your stakeholders will understand why you reject their requests without being annoyed or pissed off. That will strengthen your role as a Product Owner, and you gain respect and trust.

Why You Sometimes Have to Turn Down Requests

Do you get a lot of requests from your stakeholders and customers? A new idea here, which could increase the ROI of your product, a must-have feature there to stand out from the competition, or maybe a change request to existing functionality.

As a Product Owner, you get a lot of requests from your stakeholders. Sometimes you don’t have the time to discuss those requests with your stakeholders, so you add new items to your Product Backlog (mostly as titles only) to satisfy your stakeholders and get rid of them for now.

Your product backlog is growing quite fast, and you are looking at a backlog of a few hundred items. Maintaining such a vast backlog takes a lot of time. But this is not the only problem you have: Since an item is on the backlog, the customer/stakeholder expectations are that they will be implemented in the future. That’s their logical fallacy, but hard to debunk.

Which Requests Should You Decline?

When you decline a request, your stakeholders or customers are not amused. Maybe they are disappointed, angry, and frustrated. That’s normal. That’s part of the business.

If you want to gain your stakeholder’s trust and respect, you need to have clear criteria for adding an item to your backlog and when not. That helps you survive political discussions, and you do not make yourself vulnerable as a Product Owner.

I recommend declining requests for features which

  • do not match the product’s vision
  • do not support your next strategic step
  • do not support achieving OKRs (if you use OKRs)
  • are not necessary for the next 3-6 month

A product backlog is an ordered list of requirements for any changes to be MADE to the product.

Three to six months is a time frame you can predict relatively reliable on what to develop and what not.

The further a feature is in the future, the more difficult it is to be sure you will create this feature, as things can change quickly. If so, you need to adjust your roadmap and next steps for your product.

Imagine you added a feature to get rid of the stakeholder because you are very occupied. If you need to adjust your roadmap and next steps and the team will not develop the requested feature, you will have a hard time convincing the stakeholder that it is necessary to cancel their request.

Remember: Once you added a request to your backlog, stakeholders expect them to be implemented in the future.

Take This Into Account Before Declining

Before declining a request, try to take the view of the stakeholder:

  • Why is he/she requesting a feature?
  • What motivates him/her to ask for the feature?

The most important question before declining a request to yourself is: “Do I have all the information to decide to decline the request?”

Sometimes stakeholders have a more detailed view and insights about a new feature than you have—no problem with that. Suppose you feel you do not have enough insights, set up a short meeting with the stakeholder to gain insights and knowledge about your product’s possible future change.

Finally, before talking to the stakeholder and communicating your decision, you need to identify: Is it a “no”, or is it a “no, not now”.

How to Say No to a Stakeholder’s Request

You got a request, collected all the necessary data, thought about it, and finally, you are convinced to reject the request. The worst thing you could do is reject the request without giving a context: “We can not do this feature. It is not a priority”. Boom, that’s rude. Why?

Try to take the stakeholder’s view: Maybe the stakeholder invested a lot of time to provide all the data to convince you to add this feature to your Product Backlog. How would the stakeholder feel? How would the stakeholder behave in the future?

Instead, take the time to talk to the stakeholder. Stakeholders, like every person, want to be heard.

First, express appreciation and thank the stakeholder for the interest in improving the product. If possible, offer an alternative that will produce the same outcome but with a different approach. Usually, stakeholders are interested in specific results, f.e. getting new users, reducing churn, etc. If you can explain how you will achieve the desired outcome with a different approach or feature, they will agree on your rejection more easily.

“No, Not Now”

If you reject the request for now, but not for the future, give the request back to the stakeholder and tell them when they can come back to you. You hand the responsibility for this request back to the stakeholder. Don’t create a ticket in your backlog for this request. If this request is still vital in the future, the stakeholder will come back to you with this request.


Saying “no” to somebody is not easy. You know you will disappoint someone. Maybe this person will express their disappointment with facial expressions and gestures. Some people will get angry; some will take it personally.

There is nothing you can do about it. That’s part of the game. But there is something you can do to strengthen your role as Product Owner:

Offer one strong reason why you decline a request. Just one reason. If you offer various reasons, some stakeholders will pick the weakest reason and argue against this reason. Support your strong reason by market data, user behavior, and other product-related data. Please don’t make it personal.

How to Communicate

The way you communicate the rejection is the key to cooperation on an equal footing with the stakeholder. Avoid using “I”, instead use “we” language:

Don’t: “I don’t think we should focus on that feature now.”

Do: “Our research told us that…”

Combined with a strong reason, “we” language will help you as a Product Owner to convince the stakeholder that rejecting a given feature is the correct choice.

What, if a Stakeholder Still Insists on a Feature

Sometimes you will face a situation where all the tips and tricks above will not work. You may have a stakeholder who still insists on a feature.

As your backlog should only contain items for a given time frame (read here why), f.e. 3-6 months, you can only accept a request by removing an existing item from your backlog. Ask the stakeholder which other features you should remove to have the capacity to develop the requested feature.

If you have features from different stakeholders in your backlog and have a hard time convincing a stakeholder not to develop a requested feature, try to get them all on the table and discuss the implications and consequences of a given request.



© 2020 by Lutz Mueller

All Rights Reserved

This article was originally published at


About Best Agile Articles Project

Best Agile Articles is a collaborative project of the Agile community to bring you the best of the best publications each year. Our goal in publishing these yearly editions is to cull through the many articles that are published each year and provide you with a curated set of high-quality articles that capture the latest knowledge and experience of the agile community in one compact volume.
Our purpose is twofold. First, we understand that it’s hard to figure out where to go when looking for ideas and answers. There are thousands of blogs, videos, books and other resources available at the click of a mouse. But that can be a lot to sort through. So, we thought we could be of some help. Second, we wanted to bring some visibility to many people who are doing outstanding work in this field and are providing helpful resources. We hope that this publication will help them connect to you, the ones they are writing for.
Our intention is that this publication is to be by the agile community as a service to the agile community and for the agile community. With that in mind, we pulled together a great group of volunteers to help get this work into your hands.

The articles in this volume were selected by:
• A diverse Volunteer Committee of sixteen people with expertise in a variety of areas related to agile.
• The agile community. A call for article nominations went out in early 2020 and several dozen 2019 articles were nominated by the community.

The articles themselves cover a wide variety of topics including organizational structure, culture, and agile leadership. There is something for almost everyone here. All editions of the Best Agile Articles publication are available on Amazon and free to download on the Best Agile Article site.
We are thankful for the great participation by the agile community at large. If you would like to participate in delivering this publication in future years, we would welcome hearing from you.

Subscribe To Our Newsletter

Get notified about new blog posts, classes, discounts, and more!