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.
By loading the tweet, you agree to Twitter’s privacy policy.
Learn more
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.
“No”
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.
