Kill Your Product Backlog
2 August 2020 ‧ 5 min read
Familiar product management scenes: a salesperson raises a feature request, gets the response: “good idea, we'll put that on our backlog”. A hackathon happens, lots of good ideas duct-taped together in a couple of days; the product team dutifully collects and documents the ideas. A product team brainstorms improvement ideas, lots of sticky notes on the wall; some get prioritized to be built right away, the rest gets put on the backlog. Fast forward 6 months: none of these ideas on the backlog have been build. Another 6 months: still nothing. The people who raised the ideas get disillusioned, frustrated.
Scenes like the above happen in a lot of companies. People working in the product development organization want to solicit input and ideas, they want the rest of the company to be able to contribute. However, the way that the process unfolds often achieves the opposite: stakeholders get excited to contribute at first but then lose faith when they see that their contributions weren't taken up.
The product teams also don't really benefit in the scenario. They end up not only with unhappy stakeholders but also with humongous backlogs with hundreds of items. There's really no good way to manage a backlog of that size anymore. Backlog grooming sessions take hours, and discussions about prioritizing ideas to build next turn in circles since there are way too many options to consider.
What to do instead, then?
The first step is to stop collecting and documenting all feature ideas. When an idea gets raised, discuss it in the team. Does this fit our strategic priorities right now? Is this higher value than other things that we are working on right now? Is this something we would want to build in the very near future (e.g., 6 weeks or this quarter)? Do we have something else on the backlog that we would deprioritize in favor of this idea? Only if the answer to all of these questions is “yes”, put the idea on the backlog (and remove something else you've deprioritized). Otherwise, tell the stakeholder “no, this doesn't fit our strategic priorities right now.”
Of course, it's hard to tell stakeholders “no”. But it's the honest thing to do. It avoids disillusionment later on. Moreover, it allows having a discussion about those strategic priorities. If the stakeholder is unhappy with the decision, you can now discuss the strategy and why their idea doesn't fit at the current point in time, instead of debating the merits of an individual product idea. In most cases, these discussions will simply lead to the stakeholder better understanding the current product strategy. In cases where the stakeholder convinces the product team that an adjustment to the strategy is warranted, that's a great outcome too—now the organization has learned something and is better aligned on the strategy.
But won't great ideas get lost if you don't keep them? I believe that fundamentally, any product organization will always have more ideas than time to execute on them. Hardly any team is ever in the position where they have no ideas anymore and are wondering what on earth they should build next. I am of the opinion that products almost never fail because the team had too few ideas, but often because they pursued too many at the same time. Also, great ideas have a habit of coming up again and again anyway, so you don't really have to write them down to remember them. All of this means that there's not really a need to keep a backlog of all of these ideas.
In fact, I think that putting the ideas in a backlog can even be detrimental. Having a long idea backlog can make the team simply pick the next idea from the backlog whenever they are looking for the next thing to build. At first glance, that sounds like a good idea, too, as long as the backlog is prioritized by value. However, often that will mean that the product becomes a bit of a random collection of good ideas, instead of a product that clearly follows a vision and is great at the few things it does. It is a much better approach to establish a vision and strategy, identify the biggest problems to solve on the path to achieving that vision, conduct focused discovery of solutions for those problems, and double down on those solutions that work.
All of this doesn't mean you shouldn't be open to inputs and feature ideas. In fact, you should encourage them. The best feature ideas are those that are directly related to strategic focus areas and problems you are currently working on.
If a feature idea gets raised that is related to an area that a product team is currently working on, then the idea and the stakeholder contact should get forwarded to the product team for consideration and collaboration.
If an idea gets raised that is related to a theme on the product roadmap, then this is the one time I would agree to documenting the idea in the context of an idea collection to be picked up when that theme gets prioritized. It is even more important, though, to write down the name of the stakeholder who raised the idea, in order to involve them when the theme gets picked up. And, of course, the stakeholder should still be told “we cannot work on your idea since it's outside our strategic priorities. We will come talk to you if and when we start working on an area that your idea fits in.”
Much bigger impact than handling incoming feature requests comes from actively soliciting ideas from stakeholders during product discovery, though. Stakeholders outside the product team with an interest in and perspective of the problem should be invited to take part in the discovery process for any new problem area early on. This way, they can contribute their expertise around the problem but also their solution ideas. This could be in the form of a temporary membership on the product team, or as part of a process like a Design Sprint.
Involving stakeholders in product discovery has several benefits: firstly, teams that have diverse perspectives of the problem will find better solutions. Product team members tend to think more alike than a team that also involves for example sales and customer support. Secondly, being able to both contribute ideas and “seeing how the sausage gets made” generates stronger buy-in to the product direction. Stakeholders are much more likely to agree with product decisions that were taken if they were involved in the decision making process, regardless of whether the decision taken in the end was the one they initially preferred.
Communicating clearly that features outside of the current strategic focus areas can't be prioritized keeps the product teams focused and helps align the entire organization on the strategy. Directly soliciting stakeholder input and collaboration in the product discovery process ensures their voices are heard, improves product quality, and deepens buy-in to the product direction.
When stakeholders understand that the product teams need to focus on the strategic priorities and not random features, and when they regularly get asked for expertise and ideas as part of the discovery process, they will be less likely to demand “random” features to be built and get frustrated if they don't get their wishes.
Since ideas are “dime a dozen”, and focused execution is what really matters, you should kill your long product backlog of feature ideas, and only put items on the backlog that you intend to build in the next 6 weeks or so. It makes the backlog more manageable, increases focus, and reduces stakeholder frustration in the longer term.
All in all, I believe that following the ideas outlined in this article leads to a better product, a more effective overall organization, and less frustration both in the product development organization and with stakeholders.
I hope you found this article useful. If you did, feel free to follow me on Twitter where I share thoughts and articles on product management and leadership.