The dev backlog is one of those terms that’s been around forever, and it’s not going anywhere any time soon. Unless AI truly revolutionises development resourcing, the dev backlog will continue to hang over product and optimisation teams alike.
But maybe it’s time we rethink what we mean by it. The term itself often carries a negative tone, suggesting that developers are slow or inefficient. In reality, the backlog usually exists because developers are overworked, the volume of tickets is simply too high, and there aren’t enough people to handle the business requirements.
Whatever the cause, the result is the same. There’s always a “backlog”. There are always other tickets, projects and priorities competing for limited development time. For anybody trying to get a ticket prioritised it can feel like an uphill battle.
A product manager can help by maintaining a clear prioritisation framework, but no one is immune to the person who shouts the loudest eventually. With that we often see optimisation work often struggling to make the cut. We frequently hear from teams that CRO and experimentation tickets get stuck because the dev stream is already full of other critical work anything from accessibility updates, redesigns, new payment integrations, or compliance-driven projects.
Depending on the platform, even small front-end tweaks can require significant development effort and cost. So how do we navigate this more effectively?
Why Optimisation Deserves a Place in the Roadmap
Agile frameworks have transformed the way product teams work. Experimentation and CRO are of course agile too. They involve rapid iteration, small-scale changes and measurable learning.
If an optimisation delivers a statistically valid improvement it deserves to be prioritised alongside other roadmap items. The problem is that these changes often seem too small to compete with major development projects. That mindset needs to shift.
Optimisation isn’t just “nice to have.” It’s a proven mechanism for growth. These wins compound over time, and failing to implement them means leaving measurable value on the table.
Optimisation Can Help Reduce the Backlog, Not Add to It
While optimisation often gets viewed as more work for developers, it can actually help alleviate the backlog when product and experimentation teams work closely together.
Good communication and collaboration between the two teams mean that experimentation can take on some of the weight from the product backlog. Tickets and requests that have been prioritised with little or no supporting data are perfect candidates for testing. Experimentation teams can validate these ideas, measure their impact, and feed results back to product and wider stakeholders.
This approach not only helps inform what deserves a place in the backlog but also provides clarity on why certain tickets aren’t being prioritised. When testing provides data-led insights, teams can make more confident decisions about what’s worth developing. In turn, this reduces wasted effort and ensures that development time is used efficiently.
Making Space for Optimisation in Development Streams
So how do we make optimisation a permanent, prioritised part of the roadmap? There are a few core things that can be done:
- Empower optimisation teams to support prioritisation.
The Optimisation team will understand the numbers of their experiences. They know which changes will deliver impact, and will be able to provide metrics that support development stream prioritisation. - Collaboration across the business
Working alongside the wider business (the finance team especially) to turn your estimated forecasts and improvements into core business KPIs such as profit or customer satisfaction. Can help provide weight to hard coding and experience, this is especially relevant when you’re working with third party development agencies and costs are attributed easily to every piece of work. - Reserve a dedicated development budget for optimisation.
This is one of my favourite ways of working in a previous role. By setting aside a specific portion of budget purely for hard coding winning experiences, you give your team flexibility. Some months, you may not use it. In others, it allows you to move quickly, uplifting developer resource, on proven opportunities without disrupting the core roadmap. I appreciate this wouldn’t work or even get over the line at all businesses, but we found this highly effective.
If All Else Fails, and Tickets are still stuck…
Let’s be real, there will be times that this will happen. Complex projects that require all developer resource and focus, or no additional capacity to scale up. The backlog will build up.
If this is the case, maybe it’s time to change your experimentation strategy slightly. Let’s not pile on more experiences on this backlog unless your certain that you’ll get a successful result over the line.
Maybe instead it’s time to lean on the capability of your testing tool. All testing tools offer capabilities for a level or personalisation that, in the majority of cases, many never make sense to card code. Consider exploring personalisation or segmented offerings that can be deployed with little to no development resource, but can allow you to continue to reap the rewards of your Optimisation programme.
The Bottom Line
The dev backlog isn’t going anywhere. But how we work with it can evolve. Rather than seeing it as an obstacle, teams should treat it as a shared challenge that requires better integration between product and optimisation.
By planning for optimisation from the outset, allocating resources, and creating a clear communication flow between teams, businesses can make smarter decisions and move faster. Experimentation shouldn’t just compete with the dev backlog, it should help refine it, prioritise it, and ultimately make it work better for everyone.
