Kill the Product Backlog

Sometimes nothing can be a real cool hand - Paul Newman in Cool Hand Luke

Like many startups, at Sefaira we are organized with the goal of reducing the lead-time from feature conception to feature delivery. This forces us to constantly evaluate our product development process & tools, with a clear goal in mind. Amongst many virtues that underpin this goal (measured as time to production), is the idea that shorter lead-time allows the product team to be more reactive and nimble (yes, Agile) to customer needs.

Typically (i.e. not in product discovery mode), product managers understand customer needs, create user stories & use cases, discuss them with the development team to help the team understand the problem, followed by estimation and scoping discussions. Following this, the features are broken in multiple customer facing releases. Good product managers identify data they’d look for before building features, i.e. good old hypotheses driven iterations. New features are often balanced with improvements, bug fixes as well as technical improvements, and prioritized by the product manager.

To manage all this seeming chaos, &  queue up work, some product teams lean on creating and maintaining backlogs. This is a great idea – the product manager logs & maintains all disparate items, sorts and sifts through the backlog working closely with other stakeholders, and lines up work for the development team, and good development teams crank out code and deliver features. If the business wants to know what’s coming up, the product manager leans on the backlog, which is supposed to be a reflection of the product outlook 2-3 months out. This is comforting, sturdy and has the signs of a well-oiled machine. So where’s the problem?

There are 3 key problems here.

Backlogs substitute judgment

Good product managers are always on the lookout for new information to influence product direction. This is intended to influence features to build, bugs to fix, areas to invest in, etc. As new information appears, the product manager with a well-organized backlog goes ahead and prioritizes work in the backlog based on this information. This is where the problem starts. 

The backlog was created when the said new information wasn’t available. While this seems reasonable, what is really happening is that the product manager is using new information to confirm existing work queue. This makes an agile team less reactive to customer needs! What should have happened is that the new information, in concert with P+L goals of product & product vision be used to create new work – as often as necessary. This is discomforting, difficult and keeps me up at night. And if I am uncomfortable, I know that I am exercising judgment. I work with stakeholders to queue up work every sprint based on product outlook (more on this below) and latest information.

Backlogs are cognitive black holes

Once a backlog exists, maintaining it, defending it and justifying it takes up significant cognitive effort. It also becomes a basis for defending product decisions. One of the frequent responses to new requests is “It’s in the backlog”, and this is interpreted as “We got it”. Backlog gradually ends up becoming one of the measures of competence and organization of a product team. It is not hard to see why this is an easy trap to fall into. Backlogs also sap significant cognitive resources – resources that could be brought to bear in gathering & organizing new information with intent to act in immediate future.

Backlogs are poor predictors of product outlook

When asked what we are going to build for our customers in the next 2-3 months, backlogs seem to be the natural place to go look for answers. After all, backlogs are a manifestation of product roadmap and priorities. But if you think deeper about it, product outlook should be based on most recent information that the product team has. Product backlogs by definition are historic. Therein lies the dissonance between product outlook & product backlog. I think product managers should update and maintain product outlook very actively (once every 2 weeks), and update all stakeholders regularly.

Now that I have made the case for killing the backlog, there is a natural question that arises. How do I make sure nothing falls through the cracks? The answer here is simple – stuff will fall through the cracks, and that’s okay! Any fast moving development team (where code is in a good state & movable) can move quickly to pick up items that fall through cracks and deliver it quickly. Its better to have things falling through cracks and have someone notice, than overbuilding or building based on historic information ala the backlog.

Till then, I leave you with this great scene from one of my favorite films “Cool Hand Luke”.