The Product Backlog as a Learning Tool

Ideas and Requirements

When I teach product owners, one of the questions I ask is: “What qualities should the product backlog fulfil?” More often than not, a key property is missed: emergence. This corresponds to my experience of how backlogs are often used: as a requirements list that doesn’t change much. Instead of being rigid and fixed, the product backlog should be flexible and dynamic. It should evolve based on customer and user feedback thereby facilitating the discovery of the right product feature.

At the beginning of a product development project, there are usually many unknowns, and we often do not understand what a brand-new product or a new version should look like and do in detail. Our initial thoughts about the product resemble more ideas than hard-and-fast requirements. We should therefore treat the items of an initial product backlog as assumptions that have to be validated and refined using the feedback from customers and users. This allows us to understand how we can best solve the customers’ problem, and what the product should really look like and do.

---

Learning from Customer Feedback

To turn your backlog into a learning tool, expose product increments early and regularly to customers and users, for instance by demoing the increment or by releasing it. Then evaluate the feedback you receive, and decide which changes are required, as the following diagram illustrates:

When evaluating feedback, avoid two common mistakes: clinging on to your ideas and ignoring what your customers and users tell you, and saying yes to every piece of feedback, any new idea, or feature request.

Analyse the feedback carefully with your vision and product strategy in mind. Ask yourself if the feedback is helpful turn the vision into a great product–assuming that your product strategy is valid. If the answer is yes, incorporate the insights gained. Remove or change existing product backlog items, and add new ones. Your product will consequently evolve through on-going dialogue with users and customers.

---

Enabling Change

Adjusting a large, detailed product backlog usually takes too much time and is error-prone. Focussing your backlog and keeping the majority of its items coarse-grained helps you achieve the necessary conciseness.

If you are developing a brand new product, you may want to restrict the backlog scope to creating a first product increment that allows you to gather customer feedback (aka minimal viable product or MVP). Then use the feedback to decide if and how to proceed. Use the product roadmap to paint a bigger picture of how the product is likely to evolve.

Keep the majority of your backlog items sketchy and coarse-grained, particularly as long as your product is changing. A great way to do this is to employ my Product Canvas and to capture ideas as epics and user journeys. Identify the biggest risks, and select the epics and journeys you want to test with the next product increment. Then derive small stories and make them high priority.

Viewing the product backlog as a learning tool facilitates the development of successful products. But it requires overcoming the misconception that the requirements can be correctly determined upfront when we develop a new product or make bigger changes to an existing one. We stand a better chance of success by using early and frequent feedback from users and customers to validate our ideas and make the right product decisions. As Ken Blanchard says: “Feedback is the breakfast of champions.”