”I will add it to the backlog” – The Product Owner’s biggest lie

Anyone who has worked as Product Owner will know the words in the title. It is the easiest way to respond to incoming requests.

But it is also the biggest lie you can say as a Product Owner. The main danger of this statement is that, if you use it regularly, it no longer means what you think it means.

Requesting is easier than delivering

Backlogs work best with strict control of what gets added to them. The simple fact is that it is always much easier to request something than to deliver. The inflow of requests and ideas for the product backlog must be critically considered.

"People think focus means saying yes to the thing you've got to focus on. But that's not what it means at all. It means saying no to the hundred other good ideas that there are. You have to pick carefully. I'm actually as proud of the things we haven't done as the things I have done. Innovation is saying no to 1,000 things." - Steve Jobs

The job of the Product Owner is to investigate, consider and approve or reject any requests or ideas that the team could execute. The target is to find the optimum use of the team’s time and resources that achieves maximum value in the long term.

Don’t forget - the Product Owner has the rejection power!

If you as a Product Owner start habitually saying “I will add it to the backlog”, you risk forgetting to use your “No” power. And the backlog starts to grow.

The problems with a large backlog

When your backlog starts piling up, you will start facing new types of problems:

• The team is less motivated to refine and work on a large backlog
• Managing the backlog takes more time for you as a Product Owner
• It is harder to forecast when something is ready
• As things snowball, saying no becomes even more difficult

Why it is so easy to say “I will add it to the backlog”

The real reason the phrase is used often, is to get the requester out of the way. The Product Owner wants to continue working on whatever she was working on before she was interrupted. The statement does not mean the same thing for the Product Owner and the person who made the request.

The Product Owner thinks: “Another request logged down. I will look at it later.”

The requester thinks: “Great! She responded well to my request! I probably will get my request handled in the next couple of weeks!”

What went wrong in this scenario?

• There is very little idea about the customer need or value of the item. The Product Owner was too busy to focus, discuss and interview the requester.
• The item was logged in a rush, and the Product Owner did not review it with the requester. There is a risk that the item was written down wrongly or in a way that isn’t easy to understand later.
• There is a conflict of understanding. The requester thought you took the request seriously and will probably start work on it soon. The Product Owner, on the other hand, didn’t see it as any kind of commitment. This conflict will reduce the trust level.
• The backlog just got slightly bigger. Repeat the scenario a hundred times and you will have a backlog that is large and difficult to manage. The Product Owner gets ever busier, and falls ever deeper into the rabbit hole.

How to fix the “I-will-add-it-to-the-backlog” problem

As should be clear by now, it would be better to avoid the “I-will-add-it-to-the-backlog” response. And the good news is that there is plenty you can do. So here is a list of steps to take to avoid this unwieldy situation:

• Develop a habit of “Stop and listen” whenever somebody comes with a request. Put down what you are working on, and focus on the need and value of the thing that is requested. If you do not want to be interrupted, use “do not disturb” signals.
  When interacting with the requester, focus on understanding the problem. Most people come to you with a request for a solution. Do not accept this. Make it a rule that if they want you to do something, you need to understand the problem. Use the five-whys method if that helps.
• Is the request tied to a certain timeline? For example, if it cannot be met within six months, the value is lost.
• Discuss with the requester how realistic it is to deliver a solution. Show the requester the current backlog. Try to engage tradeoff negotiation mode - “if we do this, all these things need to be postponed”.
• Explore with the requester if there are current or potential workarounds for solving the problem. Likely there is a current behavior that someone is doing when they encounter this problem. Document this to the request.
• Explore if solving the problem has other potential benefits elsewhere.
• Outline the assumptions and uncertainties that are related to the problem.
• Make a best possible guess on the complexity and effort of solving the problem.

Bonus tip: Use wishlists

In summary: decisive action is better than a messy backlog

Using “I will add it to the backlog” easily leads to a messy backlog that slows down the team refinement work. It also reduces trust within the organization and can lead to conflicts.

Do not take this “easy road”. Strive for a more structured approach and decisiveness already when receiving backlog requests.