The Backlog is Overloaded - The Product POV

Jira backlogs have become dumping grounds and unusable, there's scope to build a dedicated product there

April 7, 2022

(meme src)

If this meme hits hard then you know. Otherwise, I don't think this blog post is for you. Also whilst the meme is targeted towards developers I will be taking the Product Manager POV.

I believe that one of the biggest issues with how we work in software today is that we conflate tracking an issue, feature request or bug with planned work in backlog/roadmap and use the same tool to manage two very different processes.

From my experience and talking to others this problem is more acutely felt in B2B companies. In high volume user B2C companies there is enough data and realtime feedback loops that you don't need to reply on this backlog information for making prioritisation decisions.

If we take an extreme example, imagine you're working at 10 year old B2B SaaS company doing $100M ARR. It is highly unlikely that any new feature request would out prioritise the immediate roadmap. So someone creates a ticket and the vast majority of the time it sits in the backlog.

However, we're not set up to track the importance of this issue overtime. Tools such as Jira and GitHub Issues allow anyone to comment on the issue. So over time the workforce will add comments such as which customers are being impacted. But trying to aggregate this across all tickets is very manual task involving a spreadsheet. Trying to combine it with realtime data in Salesforce or Product metrics is very time consuming. So most of us don't and therefore we don't have a good understanding of what some of the biggest problems facing the product are.

Regular pruning sessions and re prioritisation will mean that some of these tickets do get worked on but the backlog will only grow as the product develops in new directions and new tickets will be added meaning that the backlog grows larger and larger and so the problem compounds.

The problem is that we're freely adding these tickets to the backlog in the first place. Instead we should have a separate process for tracking problems where we can aggregate the information and query it. This should be used as one of the inputs of the prioritisation and from there the tickets are then added to the backlog.

The reason I think this is such a big issue is that this process heavily influences what we build next. In sales lead B2B companies the "squeaky wheel gets the grease" problem means that the roadmap is biased towards the largest size deals; when the reality could be a larger subset of customers with a small issue has a bigger impact. The opposite can occur in a design lead company and so on.

The reason we started 42problems.com is we've experienced so much of this pain and believe that we can make better decisions when we track problems independently of panned work.

Hugh Hopkins
CEO
Share this post