To manage your product backlog better, you can learn a lot of best practices from online shops, an area where a lot of digital and management innovation happens these days. 

The two disciplines have a lot in common:

Your development team has a backlog of features and requests. The online shop has a backlog of orders. 

They are both bombarded by requests from customers and other stakeholders, in their own ways. 

Sometimes the requests are straightforward and can be delivered fast. Other times the Product Owner decides it requires too much effort to deliver. In the same way in an online shop, the customers are sometimes interested in products that are out of stock, and the delivery time is difficult to forecast.

So if you are a Product Owner, or in any way work with product development backlogs, you are not alone. I’m going to share with you some important lessons from your cousins in online retailing. Lessons that will make it easier for you to manage your backlog. 

Let’s jump right in and look at a side-by-side comparison and direct lessons.

What you can learn from online retailers

Let’s walk through the step-by-step process a customer (sometimes that’s you) typically goes through when searching for a product and placing an order in the online shop. 

This table shows you the two paths each “requester” takes. Notice the similarities? In the last column, you see what lessons can be learned at each step. 

 

Online shop

Backlog management

Lessons for the PO or dev team

Problem identification

The customer has a problem that can be solved with a product

The stakeholder has a problem that can be solved with a product change or a new feature 

Educate stakeholders to think problem-oriented rather than solution-oriented

Information seeking

The customer tries to find out how to do something

The stakeholder seeks information on how to use the product to solve the problem, build a workaround, or fix a bug himself

Have the dev team keep up-to-date resources for internal and external stakeholders

Solution finding

A product is found that could solve the problem

The stakeholder finds the team who can help him or finds information on the product 

Make your dev team visible and easy to approach

Solution comparison

The customer compares different products to decide what he wants to buy

The stakeholder compares requesting a change or new feature,  with using an existing workaround

Have the PO educate the requester on the “cost” of implementing the request, both in terms of effort required and the need to deprioritize other activities 

Ordering / Requesting

The customer makes the purchase decision based on delivery time estimate, price, and quality

The stakeholder decides to ask for a new feature by estimating delivery time, the investment needed pre and post delivery, and the expected quality 

Make sure the PO can estimate and communicate the delivery time and onboarding cost for the new feature 

Order confirmation

The customer gets an order confirmation email

The stakeholder gets information that the request has been received and will be evaluated soon, and the requester will be kept up to date on progress

Make sure the PO can effectively communicate around how the decision is made on the request 

Delivery estimate

The customer is given an estimate on the re-stocking of the product 

The stakeholder is informed about where the request is on the team backlog, and when the team is likely to get to it 

Make sure the PO keeps the requester updated on the delivery estimate

Cancelation information

The customer may be informed that the order has been canceled due to delivery problems

The stakeholder may be informed that the backlog item has been canceled due to prioritization

Cancelations and rejections happen. Make sure to notify the requester early enough for them to find other options.

Options / customization / refinement

The customer is contacted about delivery customization (such as size, options, and configuration)

The stakeholder is interviewed about the item refinement and acceptance criteria

Involve stakeholders at least in the results of the refinement (as well as in any demos and prototypes)

Final shipping configuration

Images and product information is prepared for shipping

Details are documented of the still unreleased product

Share information to avoid surprises at delivery

Delivery date confirmation

The customer gets a confirmation and information on delivery 

The stakeholder gets information about acceptance of the request

Communicate in a formal way, to show that the acceptance is a significant, and not a “normal”, decision. 

Start planning the refinement of the request, focusing on assumptions you need to verify.

Delivery process begins

The customer gets a shipping notice and the courier accepts the delivery task

The stakeholder is informed that the feature will be taken into development on sprint X

Inform the stakeholder about implementation start. Invite them to a demo or to review a proto or spec. Ask for information that could impact implementation

Estimated final delivery date

The customer is notified about the estimated delivery date 

The stakeholder is notified that the feature is ready, can me demoed, and has a release schedule

Demo as soon as possible. Find out if anything needs to be changed before release.

Delivery confirmation

The customer is sent a delivery confirmation 

The stakeholder is informed that the release is available

Plan the delivery: Who needs to be informed, what needs to be documented, and how should you handle the market reaction to the new feature?

Satisfaction / Feedback

The customer is sent a satisfaction query

The stakeholder is contacted post release and asked if there are any problems introducing the feature

Make sure to follow up: Did the feature solve the original problem?

Remember to keep your stakeholders informed as if you were delivering an order

When you are a customer in an online shop, you expect the shop to keep you updated. But in all honesty, do you as a Product Owner remember to serve the stakeholders in the same manner? It is very easy to forget to share information in this way. This reduces trust and can lead to suboptimal solutions.

 

Read more about backlog management

 

The top 4 neglected activities you want to remember to do

Product Owners are usually good at handling some of the items in the table above. But some of the other ones are typically neglected. 

I want to make sure you’re “running a tight ship,” so I’m going to highlight some of the most neglected items that you should pay attention to.  

  • Following up 

Did the delivery solve the original problem satisfactorily? It is easy to lose track of what the original problem even was, and instead place all focus on the requested solution.

  • Including the originator in the item refinement process 

Generally, teams do not refine backlog items enough. But when they do, it is important to involve the requester or at least keep him informed of the results of the refinements.

  • Estimating delivery time

Your backlog is a living thing that changes constantly. Not only should the Product Owner estimate the delivery time as the request is made. He should also actively inform stakeholders of any updates on the delivery estimate.

  • Maintaining information about the product and the team

Often stakeholders in larger organizations do not have the slightest idea which team actually works on their request. A good development organization has knowledge bases where the stakeholders can learn and view both the product and the people who are building it.

In the end, it is about keeping your customers happy

If you have a Product Owner’s responsibilities, take a deep look at your own backlog management habits. Do you share enough information? Do you keep your stakeholders up to date on the progress of their “orders”? 

“Keep your customers happy” is the mental model of a typical online retailer. If you follow it, you can manage your backlog a lot better.  

Published: Nov 29, 2022

Software developmentAgileProduct management