The Art of Maintaining a Backlog

Among the many dilemmas, a startup usually has is proper backlog maintenance – as part of the long-term product management cycle.

The two obvious extremes are an empty backlog, where the development team does not know what’s going to happen to the application next month – or an overflowing backlog, where prioritization becomes a nightmare.

And believe me when I tell you, neither is good.

A backlog too small

Let’s start with the more intuitive (and quite evasive) option, where founders try to rigorously follow the lean methodology and keep the backlog as minuscule as possible – possibly limiting the horizon to a few weeks’ time.

Small means lean

The advantage is obvious – you follow your customers towards product-market fit. Scoping and wireframing and designing non-critical features you may never get to implement is wasting no time.

You could spend all that salvaged time on business development, for example. Or better yet – on additional customer feedback and acceleration of the product development cycle.

The flipside

Well, the main thing here is that it never works as intended. Leaving a small backlog basically locks one of the founders/visionaries stuck in the loop indefinitely. Otherwise, the rest of the product development team simply doesn’t know what to do.

Sometimes, a focus group would lead the product to a dead end, where you’d need to step back and rethink your strategy. Having discarded any backlog would leave you no leeway to think thoroughly – and zero ideas out of your just-abandoned scope.

And let’s not forget, having a short task list means that the product development team hasn’t met strategic engineering decisions; if you’re building a software product, that usually translates to technical debt.

A backlog too large

No doubt about it, this happens way more often. And as you might imagine, the issues one would encounter are quite the opposite.

In short, backlogs need to be prioritized rigorously and mercilessly – and that’s when conflicts tend to emerge.

Usually, the vision between stakeholders is aligned, but the stepping stones toward it aren’t – and discussions start heating up.

Occasionally, backlogs span to more than a year. At least half of those tasks won’t ever be completed. Either your environment would evolve or they would need to be fully rescoped. Or the whole business would pivot, rendering them useless.

Finding the middle ground

What we’ve realized over a multitude of projects is that optimal backlog size depends on three main factors – the product type (SaaS/enterprise), maturity stage (startup/established/mature) and the target industry dynamics (volatile/stable/conservative). Of course, there are secondary factors – cash burn rate, monthly active users (MAU), release cycle specifics and the number of stakeholders – but unless you are at an extreme with any of those, their influence would be insignificant.
A well-managed backlog would contain work for three to seven months. The more enterprise-oriented and mature a product gets, the longer your backlog needs to be, especially if operating within a stable, rarely disrupted industry.

Can we have at least one formula, please?

If product management was that much quantifiable, it would have been managed by machines. Or is it that because such a machine needs to go through imperfect human-based product management process? We may never find out, Neo.