How to defend your backlog

The door at the far end of your working area opens and Jack makes a beeline for your desk. Not in an “all hands on deck” kind of way, but with a purposeful and determined air about him. It’s probably something to do with that latest feature request, you think to yourself.

Two weeks ago one of your sales teams escalated feature “X” to you. They say their customer deal is in the bag if only we implement this one feature. It’s a big feature, this feature “X”. It’s also a big deal that this sales team is after.

You can probably already guess what the problem is. Feature “X” will consume almost half of your resources for the next quarter with the result that many other features will slide down the backlog. Your R&D unit has already caught wind of it and they’re pressuring you to start changing priorities “yesterday”.

So there you are, once again in the center of what you expect will quickly become a whirlwind of escalations. Your backlog has been carefully crafted over the past months into a well balanced and well groomed condition and it has taken an enormous amount of effort to get it like that.

Jack’s at your desk now. He starts off with a quick good morning but gets straight to the point. He brings up Feature “X” and tells you that he wants to know when we will be able to implement it. Jack is from your product area and works as a financial controller. It’s February and he wants to see some big deals locked in as soon as possible . Putting Feature “X” on the roadmap would help win this customer.

You know that this will seriously damage a majority of other customer deals you are likely to see in the coming year. Feature “X” pushes so many other table-stakes features out in time that you know you will not be able to compete sufficiently on other deals.

This is a good point to take a step back and analyse quickly what is happening. You have different motivations for different people with different variations of what is really the same goal (get customers and revenue). Their motivations will be guided by how they think the goal can be achieved. In the case of the financial controller, Jack, it depends on his level of comfort with the technology and the market space. The sales team may only care about the deal at hand, particularly if they are a customer attached sales team – and they might not be interested in your reasoning as to why you can’t meet their request.

As a product manager you will have to handle these situations in a diplomatic manner when they arise, but the real secret is that handling this situation best is actually done ahead of time.

Essentially this means ensuring that the product strategy is well conceived and that you have spent time not only communicating it but ensuring that it is well understood by key stakeholders. Jack wouldn’t ask you to change your backlog if he knew that it would mean losing a lot of other business in the future. If the backlog and roadmap was well linked to the strategy as well as the addressable market and revenue potential then the answer would be obvious.

In essense this means doing a few things, which I will list here:

• Spend time on your product strategy and make sure it is well formulated
• Make sure your product strategy includes links between addressable market/target customer groups and features or feature sets. This establishes a clear link between product roadmaps and revenues.
• Ensure your product strategy is as easy to understand as possible (within reason) and that you communicate it in the right places. If you think people don’t understand it you need to spend more time on it. You want to build a sense of common purpose with your strategy and that means everyone needs to be on board.
• When doing backlog management, whenever you make a change ensure you can relate it back to a target market or revenue target. Doing this will enable you to optimise your R&D spend for maximum revenue, but remember you need to have the revenue to feature mapping work done first.

If you do the above, then it will help to ensure you keep a high quality backlog that is easy to explain and defend. It can be helpful to break your features into feature areas to make the work easier, but it is important to keep good documentation and to put it in a format useful for explaining to others. Keep a monthly or quarterly update of this.

Assuming you have done the above, then the conversation should go quite easily with Jack, or better yet, Jack probably wouldn’t have even come to your desk.