Feature requests – Simple advice in 3 scenarios & 5 best practices

Anyone responsible for a product knows the situation. Stakeholders constantly knocking on the door with feature requests along the lines of “Can we please add Feature X to the product. It is important because of reasons. Please add it yesterday. Thanks.” While the feature could be valuable, other stakeholders also have their wishes, customers give us feedback, and the developers have ideas. In short, there is generally enough to do already without the additional feature request.

So, how can you deal with these requests? 

That’s the question I want to answer today. I want to first set the stage and present three different scenarios, two extremes with their specific advice on how to deal with stakeholder requests and the real world scenario. Finally, I will share five best practices for the real world that are (almost) always applicable in dealing with stakeholder requests. 

Email address:

Leave this field empty if you're human:

Three scenarios with varying degrees of empowerment

How to deal with specific feature requests from (powerful) stakeholders depends significantly on the amount of autonomy allowed. It depends on the degree of empowerment given to the team. The three levels are:

• A fully empowered product team
• The delivery or feature team
• Somewhere in between the two

Let’s start with the ideal world. 

The ideal world – a fully empowered product team

In the words of Marty Cagan “empowered teams solve hard problems in ways their customers love, yet work for their business.” In this situation leadership provides context and a desired outcome. It is the team’s job to solve the problem as it sees fit. 

This is the target state described in many successful product development books. If you are in the small and lucky minority working within an empowered team (congrats!), there is not really much specific advice I can give in dealing with feature requests. You won’t get many. The team is empowered to come up with the features themselves. 

You will, though, naturally find the need to use a system for (continuous) product discovery (e.g. Opportunity Solution Tree or User Story Mapping). The team needs to identify the most value creating features by uncovering and addressing user and customer problems. Product discovery is thus the key to building a sustainably successful product. Regularly talking to users and feature or assumption testing are absolutely necessary to make sure you build the right product. 

To be very clear, you still need to involve stakeholders. Cagan’s sentence ends with “work for the business”, after all. An effective way to do that is by regularly inviting them to reviews where you share what the team built and learned. It’s also often a good idea to involve stakeholders in ideation sessions. 

Overall, the empowered team is best for the long term success of the product, for motivation, employee retention, and the happiness of the team. It is very rare, though. 

The worst case – the delivery or feature team

The other extreme is probably more common, a team that is not empowered at all. The team does not – or is not allowed to –  conduct product discovery. Instead, it builds features that are defined by others, usually by the leaders of the organization. In this case you are part of a delivery or feature team. 

This doesn’t necessarily mean that the product can’t be a success. The features that others prescribe can still be the correct ones. More often than not, they aren’t and the team spends precious resources on things that don’t really move the needle. 

In this situation the team generally gets one attempt at solving the user problem with one predefined feature. There is no experimentation or iteratively improving the solution. Even if this one feature works, it is usually not the best solution for satisfying a given user need. Moreover, by treating the team as mercenaries, the company is surely not maximizing the (creative) value the team could bring, particularly from the engineers. 

If you are in this situation, I always advise in pushing towards an empowered product team. This is a long and arduous process requiring explanations upon explanations and lots of negotiating. It is a culture shift. This is effort well spent, though. It will pay dividends down the road. 

Fixed priorities and quarterly planning can help make it work

Until you get there, the important thing for getting the most out of the situation is agreeing on clear priorities. In the world of feature or delivery teams, leaders often base the decisions on what to build on their intuition. Depending on personality type (or the quality of coffee that day 😉), this means priorities can fluctuate (a lot). You need to freeze them as much as possible. 

What has worked pretty well for me in this situation is quarterly planning. Essentially, we would request a fixed list of priorities of what the leaders wanted in the upcoming quarter, conduct some high-level estimation of the features, and produce a time based roadmap with estimated dates. We would show the proposed timeline to leadership and then have another revision. 

Finally, we would execute the features, accepting a deviation of priorities only in extraordinary circumstances. Compared to the empowered team, this is far from ideal, but it works. 

Overestimation in case nothing else helps

If you are feeling really bold, there is one more tactic to apply: overestimation. Simply add (lots) of buffers to the estimations. Then, use the extra time to focus on what is actually important. 

This is NOT a great way to conduct business and will likely not end well in the long run (!). Thus, I generally don’t advise in overestimating.

In specific situations where you don’t agree with the prescribed features and stakeholders are not receptive to discussing them, it can help to reduce frustration and allow for some autonomy.

The real world – somewhere in between

The vast majority of teams, I would argue, fall somewhere in the middle of the two extremes presented above. The teams are somewhat empowered, they have a product outcome they need to achieve, but leaders still request specific features from time to time.

Besides constantly pushing for more empowerment, the way to go here is agreeing on an outcome, leaving some buffer for specific requests. These requests need to be included strategically, either when it is really needed to unlock a potential customer or when you need to make a stakeholder happy. 

Nevertheless, the overall key is focusing on the current product goal, finishing one thing before starting the next. Five things help in this situation.

5 best practices for dealing with stakeholder requests in the real world

In this real world where the team is somewhat empowered but still gets feature requests from Stakeholders, I have found five best practices to be very effective in making sure everyone is happy and the product is successful. 

• Involve stakeholders in ideation
• Actively seek out feedback
• Maintain a separate idea storage in product discovery
• Learn to say No, a lot
• Don’t be afraid to delete things

Involve stakeholders in ideation

The main reason stakeholders want to prescribe features is a lack of trust. They are worried that the scarce resources of the team are spent on the wrong things. They believe their understanding of the business is better, enabling them to make better decisions.

The way to gain trust and consequently more empowerment for the team, is to involve the leaders in the process. This way they a) see how the team works and influence how the scarce resources are spent and b) satisfy their ego in shaping the product. 

As already mentioned above, a good way to involve stakeholders is to have them take part in brainstorming sessions. It doesn’t matter if this is part of an official process (e.g. the ideation part in continuous discovery) or simply whenever the team has an ad-hoc session to discuss solutions. 

This way, the stakeholders can add their features to the list of solutions. Over time, most teams will show that they aren’t completely clueless and stakeholders will gradually want to be less involved.  

Actively seek out feedback

Additionally, it’s always a good idea to actively seek out feedback. In the case of Scrum, the obvious place for that is the sprint review. Depending on the circumstance, it can also make sense to have a separate session where the team regularly seeks an active exchange with stakeholders. 

As an example, my experience has been positive in having a dedicated monthly session with the colleagues from sales. I would invite for an hour. The first 30 minutes, I gave an update on what we built and what the next steps are. I always showed the roadmap in this first part. The second half was more or less open for specific questions, feedback, or requests.

With this update, they always knew what was happening and felt that they could give input as well. Of course, the requests that come in these meetings need to be stored somewhere.

Maintain a separate idea storage in product discovery

You will always receive ideas that may be good but – for various reasons – you will not implement in the near/mid-term future. Maybe they don’t fit the outcome you are currently addressing or maybe you don’t want to crowd your backlog. You need some sort of storage where you can place these features ideas.

There are several ways to do this. The most frequently used is probably directly adding the ideas to the backlog of whatever software you are already using to manage tasks (e.g. Jira, Redmine, Teams…). I generally don’t recommend this as it quickly leads to an overflowing backlog.

You can also maintain a simple list of “wishes and known issues” using tools like Notion, Confluence, Coda, Excel, Google Docs etc.. For the visual folks, you can create an idea storage section in whiteboard tools like Miro, Mural, or Lucidspark.

Also, roadmapping tools like Roadmunk and Productboard generally include some sort of way to store ideas. They often have built-in ways to evaluate (e.g. R.I.C.E.) and prioritize ideas before considering them for implementation.

The tool really isn’t all that important. To me, it is important, though, to separate the backlog of things to build in the near/mid-term future from the ideas that the team may or may not implement.

Learn to say No, a lot

Regardless of the idea storage, regardless of how well you involve stakeholders, regardless of how empowered the team is, the fact of the matter remains: there will always be more things to build, than there is team capacity available. 

Anyone responsible for a product, will need to say No to stakeholders, a lot. I am not going to go into details here, as I have already written about the topic. Just this much: Get comfortable with it and learn how to do it effectively. 

Don’t be afraid to delete things

Finally, regularly delete ideas. Trust me, if you haven’t yet implemented the story that you created two years ago, you likely won’t do it in the next two years either. You might as well delete it.

We humans seem to be wired in such a way that we are often scared of the finality of deleting things. We are idea hoarders. There is no need to be that way. If the topic was truly important, someone will definitely bring it up again. Regularly purging the backlog or idea storage ensures that the team keeps focus. 

Keeping focus 

This might be what it comes down to in the end: keeping focus. It is probably the theme of all the advice I gave above. Feature requests by stakeholders aren’t a bad thing, in and of itself. The distraction from the truly important topics that comes with these requests is what leads to issues. Multitasking doesn’t work, neither for individuals, nor for teams. 

Navigating stakeholder requests while maintaining product focus is a delicate art. Involve stakeholders in ideation and gather feedback to build trust and unity. Prioritize strategically, say “No” when needed, and keep your eye on the mission to ensure every feature propels you towards success.

Coverphoto by workchronicles.com