Don’t Let the Backlog Drive Your Product

You’ll find it in any mature piece of enterprise software. There’s a core concept (e.g. “this tool helps managers do performance reviews”) but surrounding that core are layers and layers of features. Some are inexplicable. Why do I need 50 currencies in the drop-down? Some seem to be for someone else. What is this “mark branch office as closed” button? And some get in the way, leaving you to jump through three or four extra hoops to just get to the thing you need. It’s messy and often frustrating.

When I look at any piece of software that’s been out for a few years, I picture this:

Sure it’s one big rock (or cliff) but if you look more closely, it’s the sum of all these layers. Each distinct layer tells a story about the elements at some point in time. When I click around a piece of software that’s been around for years, it’s like an archaeological dig. “Why would they do that?” “There’s no rational reason to make it work like this.” “Why are there fish skeletons in here with the human skeletons?”

There actually is. Or was. Most features can be traced back to a need that originated from somewhere at some point in time under some unique set of circumstances.

Stepping Back

The term “backlog” makes me anxious. It implies being behind. It also implies that what you’ve got today is an incomplete thing. You need to get through that backlog. It also implies–dangerously–that this is the true unrealized ideal for a product.

If you zoom in on a backlog you often find discrete features in the form of tickets or user stories. They originate from all sorts of places: 

• A key client wants a feature and their renewal is coming up. 
• Customer service is seeing a pattern and it’s time to address a particular issue.
• An executive has an idea and blasts that Sunday email. 
• Usage data is showing a pattern that can be improved.
• A competitor has that feature and it’s time to catch up.

They’re all credible sources of change (or at least consideration) for a product. When any piece of software makes it out into the world, inevitably feedback follows. The bigger the impact of the software, the louder and more varied the feedback. It’s actually a sign of success.

The difference between a serviceable and great product leader hinges on how that feedback informs the future of your product. 95% of the time, enterprise software (which is susceptible to the winds of big clients asking for random things), is little more than a bizarre pile of features, jammed in so you can check those boxes in Jira. The product’s roadmap is little more than all those features plotted out across time. 

A great product leader pauses and steps back. They are concerned about and defending the overall integrity of the product as a whole. Yes that request is reasonable, but how do I solve this problem without compromising the experience? Is there something more fundamental to address here? What’s really at issue?

It’s often hard to ask these questions and push back. They require time and understanding from your stakeholders. You don’t often get either. Instead, you’re pressured to “get the feature in.” Great product leaders hear that feedback and think holistically and creatively to solve those problems. 

Backlog-driven products are everywhere. They’re confounding and frustrating.  Stepping back from the backlog is true product advocacy. This will feel like friction between product leaders and stakeholders. It’s just the process. It’s how you get to great product. You have to wade through all that pushback and debate to get to something great. And in the end that’s what everyone is after: Great product.

Rich Ziade is president of Postlight, a full-service digital product studio in New York City dedicated to building great products. Email him at rich.ziade@postlight.com.