For the last few weeks, I’ve explored what prioritization looks like in a variety of different scenarios. This week finished up that series with a look at how you can go about prioritizing a bunch of stakeholder requests.

This is a common scenario when you’ve already built software for your company (ie internal product) and you’re trying to optimize or maintain it.

A unique aspect for internal products is that most requests for changes come from other people inside your company who may, or may not actually directly use it.

This can present challenges because the stakeholder may have real authority, or significant influence, that could lead the product team to make different decisions than if they we just assessing the request.

The key to prioritizing stakeholder requests is to balance value, viability, feasibility, and usability. Even if your product does not directly impact customers, you need to consider any potential impact to them, along with how the requests impact the overall business.

Principles for prioritizing requests

To guide the discussion of prioritizing stakeholder requests, I thought it best to start with some important principles.

Requests are feedback, not a commitment. This one is relevant for all software, whether its products for your customers, or products for your company. In practice this means just because someone asked for a change to your product (regardless of who it is) does not mean that you have to deliver on that specific request.

This leads directly into the next principle.

Don’t take requests in the form of a solution at face value. Stakeholders are not always familiar with how software is made. They are only familiar with what they experience, so they’re inclined to provide feedback based on what they’ve observed your product doing and how they’d like it to behave. Those requests more often than not point to an underlying problem or desired outcome.

Filter, then sequence. For the sake of your sanity, if you have 150 requests, don’t try to sequence all 150. Filter through those requests to eliminate the ones you know you’re not going to do and to identify duplicates or similar requests.

Once you’ve done that and identified what your stakeholders are trying to accomplish, sequence those items.

Keep requests separate from your backlog. While this may seem like extra work, it’s a useful way to ensure you don’t immediately assume that you have to deliver exactly on every request. The act of creating backlog items based on one or multiple pieces of feedback is a mechanism to encourage filtering and analysis of the feedback you’re receiving.

Filter first for effective prioritization

There are a few ways to go about filtering through the requests to narrow down the number you have to sequence.

The simplest thing to do is identify outright duplicates. Are there multiple requests asking for the same, or nearly the same thing? Create a single backlog item to represent those duplicate requests.

Next, are there multiple requests that look different on the surface, but actually point to the same underlying issue? Combine those together and create a backlog item that represents the underlying outcome.

Once you’ve cleaned up your list of requests to unique items, now you can start applying some decision filters to cut down on the requests you need to do something about.

Is your product intended to support specific business processes? Favor requests that deal with those processes. That implies removing requests that move your product in a direction where it’s doing something it wasn’t intended to do.

Are you getting requests from people who don’t directly use the product or are impacted by it? Dig in deeper to understand what the requestor is trying to accomplish and whether it warrants making changes to your product.

As a result of all those filtering decisions, you should have a much more manageable set of backlog items that you can now sequence.

Sequence items with input from stakeholders

It’s tempting for your and your product team to sequence the resulting backlog items based on your interpretation of the relative importance of the items.

It’s also a good way to run into trouble later when you try to get support from your stakeholders for your decisions.

Get everyone together

A better approach is to involve your stakeholders in sequencing decisions, especially if your backlog is full of independent items from a variety of stakeholders.

Chris Sykes with Toptal suggested a workshop approach that brings stakeholders together to work through the backlog items you want to sequence. The one oversight in his description is he didn’t include developers and designers in the workshop. Their presence in the discussion is important so they can hear the context from the discussion and can weigh in on any feasibility and usability questions.

Buy a Feature

Once you have all the key players together, you’ll want a lightweight technique to facilitate the conversation. I’ve found Buy a Feature particularly helpful in this setting. This technique is one of Luke Hohmann’s Innovation Games that he originally described in his book by the same name.

The premise behind this technique is to get a sense of how much your stakeholders value features by giving them a list of backlog items and a budget and ask them to indicate how they would spend their allotted money to “buy” the backlog items they find most valuable.

You can either assign prices to the items or make it more of an auction approach where people indicate how much a particular item is worth to them.

The result “values” for each item is informative, but the discussions that go on as stakeholders make their purchase decisions are probably even more enlightening.

Grouping can be an alternative to sequencing

If sequencing feels too difficult or seems too controversial, you can try grouping first and then revisit sequencing the first group.

My preferred approach to grouping items Is Todd Little’s ABC approach.

If you want to take a grouping approach, this is a good way to do it, because it puts some guardrails around how many items can be in each group.

• Group A: MUST be completed in order to ship the product. You will change schedule if necessary to make this commitment.
• Group B: WISHED to be completed in order to ship the product, but may be dropped without consequence.
• Group C: NOT TARGETED to be completed prior to shipping, but might make it if time allows.

The powerful thing about this approach is you put a hard limit on how many items you include in Group A - 50% of what you can deliver in the allotted time.

Saying “No” in a productive way

For all those requests you decided not to do, you need to be able to say no in a productive way so that you can maintain effective working relationships with your stakeholders.

Alex Debecker shared five dimensions he uses to say no to a feature request:

• Strategic No: It doesn’t fit with product strategy (decision filters). If you don’t have a clear product strategy, this one will be tricky.
• Resources No: We don’t have capacity to do this right now. This is usually a “not yet.” It has to be backed up with the reasons why other things are coming first.
• Technical No: Too technically challenging, impossible to implement in current tech stack, violates legal or regulatory requirements
• Competitive No: We serve our customers, not base decisions based on what our competitors have.
• Usability No: Avoid requests that add complexity to a product just because it may drive new customers. Watch out for that long term impact.

Thanks for Reading

Thanks again for reading InsideProduct.

If you have any comments or questions about the newsletter, or there’s anything you’d like me to cover, just reply to this email.

Talk to you next week,

Kent J. McDonald Founder | KBP.Media