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 commonly used: as a requirements list that doesn’t change much. Instead of being rigid and fixed, the product backlog should be dynamic. It should evolve based on customer and user feedback thereby facilitating the discovery of the right product features, as this blog posts explains.
At the beginning of a new product development project, there are many unknowns, and we often do not understand what the product 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 better understand how we can best solve the customers’ problem, and what the product should really look like and do.
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 product vision in mind. Ask yourself if the feedback is helpful turn the vision into a great product – assuming that your vision 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 customers and users.
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.
Keep the majority of your backlog items sketchy and coarse-grained. A great way to do this is to employ my product backlog board and to capture ideas as epics. Identify the epics that exhibit risk and uncertainty, and select the ones you want to test with the next product increment. Then derive small stories from the epics 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 of a new product can be correctly determined upfront. We stand a better chance of success by using early and frequent feedback from customers and users to validate our ideas. As Ken Blanchard says: “Feedback is the breakfast of champions.”