The Learning Backlog
What Agile L&D Teams Can Learn from Product
You can usually spot an overwhelmed L&D team by the to-do list.
Half-built courses, five “priority one” requests, a manager demanding something yesterday, and an inbox full of “can you just” emails. Everyone’s busy. But no one’s quite sure whether the busy-ness is actually delivering value, or if the work being done is just the work that shouted the loudest.
This is where product teams often have a slight advantage. They don’t just take requests and make things; they manage a backlog. And while we may not be building apps or shipping code, L&D teams can learn a great deal from how product teams handle competing priorities, messy input, and constant change.
What is a backlog?
In product development, a backlog is a dynamic list of potential features, fixes, and improvements. It’s not just a task list, it’s a tool for managing value.
It allows teams to:
Capture everything they might need to do
Prioritise based on impact, effort, and alignment
Make trade-offs visible and intentional
Keep track of what’s waiting, without trying to do it all at once
Crucially, the backlog is not a graveyard for things you never want to look at again. Nor is it a dumping ground for vaguely defined hopes. It’s a place to deliberately defer the things that matter, while focusing on what matters most right now.
Why L&D needs one
In most organisations, L&D demand outstrips supply. There’s always one more team that needs training, one more compliance course to update, one more “We need something on resilience” email.
Without a clear way to assess and prioritise requests, L&D ends up either firefighting or defaulting to whoever shouts loudest.
A backlog changes that.
It doesn’t stop the requests, but it gives you a place to put them, assess them, and compare them. It lets you have honest conversations about trade-offs. And, over time, it can shift the perception of L&D from service desk to strategic partner.
Done well, a backlog is a visible sign that you’re making decisions, not just reacting.
What goes in an L&D backlog?
Here’s where it gets interesting. A learning backlog shouldn’t just be a list of content requests.
It should include:
Known performance problems
Opportunities for enablement or support
Emerging business needs
Ideas that need exploring (often called spikes)
Solutions that need testing
Experiments, pilots, and things that aren’t quite ready yet
This is your thinking space, not just your production queue. If something is worth doing eventually, it’s worth capturing now. If something is urgent but unclear, it’s worth parking until you can define it properly. And, if something is neither urgent nor valuable? Well, the backlog is a very polite place to let it fade.
How to manage it
You don’t need a new tool to start. A shared spreadsheet will do. The trick is in the discipline:
Define clear criteria: What makes something backlog-worthy? Who decides?
Prioritise openly: Use a simple model, value vs effort, risk vs urgency, and revisit regularly.
Review frequently: Weekly or fortnightly check-ins help you keep it alive and honest.
Make it visible: Let stakeholders see what’s on the list. Transparency is part of the value.
Borrowing from agile methodology, you might even break it into categories: things to analyse, things to test, things to build. And, most importantly, things to say no to.
Making it strategic
The real power of a backlog comes when it aligns with business goals. Rather than reacting to every request equally, you can ask:
Which of these items contributes most to our organisational priorities?
What can we delay without real consequence?
Where do we need more information before deciding?
This is where your backlog stops being admin and starts being influential. You’re not just taking orders, you’re building a case for value, one item at a time.
And, if you’re working with an experimentation mindset (which, if you’re reading this, I hope you are), the backlog becomes your living list of discovery and validation opportunities. It’s your testing ground.
Thoughts for the road
A backlog won’t solve all your problems. It won’t stop the flood of requests. It won’t make prioritisation easy. And it certainly won’t stop someone from wandering over and asking for “just a quick slide deck by Friday.”
But it will help you think clearly, act deliberately, and show your value more visibly.
Because in a world where everything feels urgent, the ability to say, “Yes, and here’s where that fits,” is quietly powerful. And unlike most inboxes, a backlog can help you get ahead, not just keep up.
Bibliography
Banfield, R., Lombardo, C. T., & Wax, T. (2015). Product Leadership: How Top Product Managers Launch Awesome Products and Build Successful Teams. O’Reilly Media.
Maurya, A. (2012). Running Lean: Iterate from Plan A to a Plan That Works. O’Reilly Media.
Patton, J. (2014). User Story Mapping: Discover the Whole Story, Build the Right Product. O’Reilly Media.