Product backlog keeping you up at night? Throw it away.

What would you say if I told you that your product backlog is hindering your product and engineering teams from building the software your customers actually want? What if I said that by eliminating your backlog entirely and beginning each development cycle with a blank page you will reap tremendous benefits?

It turns out, the majority of the time and energy spent in your backlog is wasteful and a hindrance to building the right solutions. Meanwhile, you could be fostering hyper-productive relationships amongst teams and they’d possess even more autonomy. I’ll tell you why I believe this to be so.

Over the years, the word “backlog” has become an apprehensive word for me. Our backlog, like most backlogs, became an ever-growing, never-ending dumping ground of projects. Sure, the things we were actually doing were in the backlog, but so was every other product feature, UI update, or infrastructure change that we considered for even a moment.

Our backlogs were massive and we were afraid to let go of this tremendous list. The thinking and work had already been done on those projects so it seemed like a waste to dispose of it. We worked on the assumption that one day, in an ideal future, we could return to the pre-populated list of great ideas we had and the team could get to work. We believed that capturing this information in a backlog would better equip the team that took on the project so they could hit the ground running. We were wrong.

Some businesses operate with a backlog that’s detailed and clean and only contains well-researched and valuable projects. That backlog is constantly evaluated to ensure the items on the list are still the most essential things to be worked on. If this sounds like your business then you’re doing it right and this article is not for you.

As for the rest of us, the organizations that are guilty of using backlogs as a multi-purpose dumping ground, how did they get to be this way?

Throughout this article, I’ll discuss how the backlog can easily become a source of apprehensive turbulence and what measures you can take to guarantee that doesn’t happen. Let's look at four potential ways that your backlog might be harming your business:

• Backlogs don’t keep up with your users' needs
• Maintaining backlogs is a time sink
• Backlogs are demotivational
• Backlogs stifle creativity and take your eye off the ball

Backlogs don’t keep up with your users' needs

The majority of product organizations have a product owner whose responsibilities include maintaining your backlog. When leveraging SCRUM specifically, a Product Owner is tasked with this maintenance job, but they’re seldom given the authority or have the confidence to remove content from the backlog.

This is our first issue. If there is no one maintaining and regularly reviewing the present value of each item in it, your backlog devolves into an exhaustive, unmanageable record of wishes. If a backlog is to work, then each idea must receive continuous review to ensure it still provides value to your users. You may be tempted to chip away at your backlog by addressing some of your oldest issues first, but how can you be sure your customers today still face those same problems?

Clayton Christensen said it best with his well-known milkshake example:

‍“People don’t simply buy products or services, they ‘hire’ them to make progress in specific circumstances.“

‍Appreciating the job for which your users “hire” you will only help your product and engineering teams more accurately develop products that align with what users are trying to fulfill. This is the most important aspect of building software — ensuring that you’re solving your users’ most pressing issues and helping them achieve their goals while having the best possible user experience. Maybe, you thought at one point your users needed a Gmail login, but over time that value may change and so should the projects you're working on.

Building for the sake of building is not the way to grow your business. As a product professional you know this, but there’s a significant difference between understanding and acting.

Maintaining backlogs is a time sink

In our case, backlog grooming efforts went too far into the weeds — we were spending too much time defining, detailing, and priming each problem in the backlog. Our engineers thought of the exhaustive level of detail as protection in the form of a written contract and the product team considered it a guarantee that they wouldn’t be surprised by what was built. The desire for alignment and accountability is valid and while this leads to predictability in delivery, we were spending a lot of time catering to insecurity rather than moving the business forward.

The backlog had become the focus rather than the product itself.

Defining the issues, the value, estimation of the relative effort, refinement, and continuous reordering transforms backlog maintenance into a full time job. Then, once you’ve poured that much effort into meticulously defining a task, the sunk cost fallacy takes hold and the idea will never get removed from the backlog. Though it seems like a necessary evil — maintaining and enriching the data of your backlog — it can be exceedingly counterproductive.

Backlogs are demotivational

Psychologically, backlogs represent a hoarder’s mentality. The “I’ll hang onto this in case I need it someday” reasoning. You’ve likely worked hours upon hours to fine tune the details of every item in your backlog and it seems like an efficient way to decide what to work on. However, before long you’re looking at a comprehensive list of things that you know you’ll never get through and this wears on the mind. Human beings by trait like the notion that work can be completed, so the constant keeping of a record of unanswered problems is toxic.

Backlogs stifle creativity and take your eye off the ball

What’s easier to do, start working on something that’s right here and ready to go, or, answer the critical question “what’s the most important thing we can do to move our business forward?” The easy answer is obviously to work off the backlog and start working on something that’s right in front of you. Though with the easy choice comes the severe risk of not prioritizing discovering how best to grow the product, which thwarts innovation.

Consider starting with a blank sheet of paper. This will force you to focus on the most important topic you should be tackling. Take into account your user feedback, your business and product goals, and current trends to help enhance your decision. Rather than looking at a list of what may have been the best-suited problem months or even years ago, you’ll be looking at today’s biggest opportunities.

Choosing from a list of pre-populated ideas inhibits the creative process. Sitting down as a team and taking all the current factors into account will allow you to build the features your users and team will be most excited about.

We threw out our backlog

We saw firsthand all the above issues arise and made the conscious decision to break up with our backlog. With a little help from our new product development methodology, we were able to do this rather seamlessly.

Eliminating our backlog by leveraging Shape Up

In our move to Shape Up, we started with a blank page, which was remarkably refreshing. It’s like that feeling when you take a new job — sure, you’re anxious about it, it can be stress-inducing, but isn’t it nice to forget about the things you worried about at your previous job?

The idea of “starting fresh” was an enticing feeling that allowed us to re-emphasize our focus on ensuring we’re not doing what’s only convenient, but what’s valuable. Eliminating the backlog and having this fresh start is one of the scarier things that Shape Up proposes, but it’s one of the most helpful.

Armed with this understanding that we’re not building an institutional repository of potential projects and that any planning we do right now might never see the light of day again, we’re very aware of how much effort we invest in planning any particular solution. Once we come to the conclusion that it’s not one of the best things to do right now, we put it aside. There are no more pet projects. We operate on evidence and when we don’t have evidence, we either find it or move on to something else.

If something is important enough, it will come up again and be re-pitched, but we're not digging through a repository to surface these. It's a direct result of a need that arose through user feedback. This has been one of the most powerful shifts we’ve made, by only working off evidence-based problems our teams now have a more prominent voice in these product decisions. They have the ability to share real customer feedback and so our users are more fulfilled with the software we’re building projects. As a result, our customer-facing teams feel enabled and confident that what they say actually makes a difference and the organization as a whole is confident that what we’re building is solving the most current, pressing issues that our users have.

We thought that a backlog was a safety net. It was not. Taking away that safety net has made us a more focused, more effective product team. If you find yourself working off that convenient list of projects rather than focusing on today’s most pressing issues, try ditching your backlog...or reach out to us! We’re all ears when it comes to different ideas (we’re a product feedback company, after all), and if we can help soothe some fears, well that makes us happy too.