There’s a sentiment I started to see in the agile development world that advocates for deleting old/stale items off a backlog completely. A good recent example is Jason Knight’s latest newsletter:

The backlog becomes a dumping ground for every single customer support query. Every account manager and every salesperson has something in there from conversations with customers and prospects. […]

It’s tempting to see “length of time in backlog” as some kind of vector for prioritisation, but it really isn’t. It’s quite the inverse, in fact. So let’s all try to get comfortable, embrace the idea of getting rid of old stuff in our backlogs, and give people a “no” rather than a “one day”.

I’m not trying to pick on Jason—his work is great and it’s another very good edition of his newsletter! I am just using it as an example that got me thinking about this a bit more deeply.

My take is that we should absolutely keep all customer feedback around in our backlogs, because that is continuous discovery data that would be a shame to lose. Instead, my proposal would be to normalize the backlog as a place to build organizational memory and a customer feedback knowledge base—not as a list of things that all have to get done.

Two tactics can help with this approach. First, a Now/Next/Later roadmap keeps the focus on the list of current priorities. The entire backlog doesn’t go into the “Later” column—only things that are currently prioritized to start within the next few months.

Second, have a standard process that the entire company (especially the customer success team) can use to collect user feedback and attach it to features. In our case that’s Productboard, and our success team can easily add and process customer feedback via a browser extension.

I guess our list of features in Productboard is technically our “backlog”, but it doesn’t cause us stress in terms of feeling like we need to work on everything that’s on there. However, as part of our planning cycle we can go through this list and figure out if anything is important enough to pull into the “Later” column of our roadmap. An added bonus: if/when we start to work on any of those features we have access to lots of customer data about each feature, and we can reach out to those customers to have more in-depth conversations with them about their needs.

So instead of deleting old issues off our backlogs, let’s rather remove the pressure and stigma around what backlogs are for (maybe we should rename it to “customer needs knowledge base”?). And then let’s use our actual roadmaps for the list of things we know we’re going to work on.