Stakeholder asymmetries

Something I have observed in many places over many years is that asymmetries between stakeholders are very common. The most obvious example for a product owner is when you have a senior manager as stakeholder contacting you while at the same time you can have millions of daily users that rarely contact you. It's an easy and understandable mistake to prioritize the work from the senior manager that is chasing you frequently to get their feature rather than those things that you have collected data on for the last few months to benefit your users. Will you risk being criticized in a meeting for the sake of an analysis that has some vague value prediction?

There are many variations of this, an internal stakeholder might defer to another based on informal influence even though their ideas are more valuable. There are similar asymmetries between users as well, small groups of them might be very vocal and organized seeming very valuable when a much larger quiet group is really the ones where you should invest in solving problems.

Frequently stakeholders see only very little of the complexity of what they are asking for, which might look trivial, hence they feel that their request is a trivial request. While in reality the feature might be at odds with or require compromise on several other very important foundations of the product that only the product team is fully aware of.

Stakeholders are driven in different ways to evaluate their proposals for features and changes needed. Some rely on opinions and gathering information on what people think they know. There are also stakeholders that will do qualitative research before or dive into advanced analytics to make calculated and thought through suggestions. Some stakeholders engage with the product team to discuss an hypothesis that can be evaluated in an experiment. It is a lot easier and quicker to have an opinion than creating and evaluating a hypothesis, if a product team has multiple stakeholders they are at risk to be influenced by opinions simply due to the fact that there are more of them. To avoid this from happening the product team need to set the bar for what is needed to qualify for what is evaluated and for features to make it into production.

A very common trait with internal stakeholders is that they are frequently proxies for someone else. This makes it difficult to have good discussions, if they lack mandate to negotiate or feel pressured by someone else to get something implemented you trying to explain to the stakeholder might not be very efficient. The tiny feature might be a part of a bigger project that hasn't considered at depth how to make this work in your product and any stakeholder is likely in reality someone who is hoping get their project plan progressed as quickly and easily as possible.

An important consideration when trying to balance the product development is to avoid overly high priority on visible and attention seeking features. It is easy to be pressured to implement a highly visible feature that an internal stakeholder is "selling" to others in the organization as a feature that you product must have. The same people is likely not as interested in hearing about how you are improving accessibility for users with disabilities or making small improvements to security even if you passed the last audit. The big issue with this is that features often have some benefits to some users but are liked less by others and add to clutter or confusion whereas a quality improvement in accessibility or security is more likely to have additional benefits to the product overall.