Kill the backlog

Note: throughout this post, when I refer to backlog, I mean backlog in the general sense of the word, not strictly the process behind a purist Scrum backlog, so interpret it also a product backburner. I'll probably dedicate a whole other post on why I think small companies should avoid a purist approach to agile or Scrum.

In the industry of creating products – whether you're a startup or a big company – we get wrapped up too much in the solution, in the product, and in creating the perfect product with the perfect process. The reality is that the user will never care about any of this. The user will care about something that fixes their problem.

I've received lots of questions from peers recently about backlogs and processes in general, and my advice is uniform and based on experience: kill the backlog. Kill it with fire. Kill it fast.

Let's be honest with each other. The backlog is, by definition, an accumulation of lower-priority items. If those tasks were high priority, they would've been done, completed, and released. Every time you hear "we'll add it to the backlog", remember you're saving trash in your storage unit. Unless you're a 50-year-old company with products under maintenance, you should never have a backlog. Marie Kondo sheds tears in COBOL every time you stash another task in the backlog.

If something matters to your users, just build it

If it sounds simple, it's because it is. If it doesn't, don't. The only thing that matters in the nth iteration of your product is the current state of your product, and whether it fits your user's needs. If you do that, and ship fast, and ship good, backlogs become stale, hopeless dreams of someone from the past that didn't know what your product would look like 3 months ago.

What about "improvements"? Let's talk about improvements. Depending on your type of product, improvements may not only contribute to retention but also growth. At Silo we experienced this ourselves: word of mouth is powerful when you work in vertical SaaS and you need to always continue improving your product. The power of a happy user is stronger than most sales teams, and it's always great when an existing customer is an ambassador free of charge. The cost of not doing so is users rightfully spreading contempt for your product in the community.

So where do you put improvements if not in a backlog? Put them on a proper track of work, with allocated resources, with iterations, documentation, and constant user feedback. Improvements in a backlog won't get done, again, unless you're a large-scale organization with discipline and someone on product operations that is pushing it to be done, pruning them continuously. It's possible that by the time those improvements are ready to be completed, they're no longer relevant. Your customer success team gets pissed, and rightfully so since they get yelled at way before you do. Well, apply some intentionality to it. IF improving your product is a key element of your strategy, then have a team with a roadmap horizon of no more than a month continuously works on those improvements, and talk to users at every step of the process – everyone in the team, including engineers.

Continuous user feedback and final remarks

The solution here is to never have a situation where you'd need to "stash" something unimportant because you're busy building what really matters. The only way to do this is to get user feedback early and often. The only way for this to work is for everyone in a product development team to be exposed to users: PMs, designers, engineers – lead or not — , need to have direct contact with users and prospects. It's the only way to have enough context. If you do this well, they'll weed out bad tasks themselves because they understand what needs to be accomplished.

Otherwise, the danger is your team using backlogs to roadmap. I've seen this at every company I've been to. It's easy. You don't need to talk to users to just pull ideas out of the stale compost bag and start throwing black banana peels into the board until something sticks.

If this little post seems to have some stream of consciousness it's because it does. This is something I've seen too often. Backlogs are the death of small and medium size software companies. If something matters – and the only deciding factor here is the user –,  apply intentionality to it, build it, and ship it fast. Why fast? Because the faster you ship, the faster you learn, and the sooner you build what your user needs.

Backlogs are bureaucracy. Backlogs are lists of has-been-never-done tasks. Say no to hoarding. Kill it with fire.