Photo courtesy of Pexels

The Product Backlog as a Learning Tool

Published on 12th January 2012

Leverage the power of customer feedback, and use your product backlog as a learning tool. Discover the right product features and take advantage of emerging requirements by integrating customer a feedback into the backlog early and frequently.

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.”

Post a Comment or Ask a Question

7 Comments

  • Avi says:

    Hi Roman – How different should technical stories be from user stories? User stories should have problem statement, persona, acceptance criteria. But what about technical stories? This could be another post.

    • Roman Pichler Roman Pichler says:

      Thanks for your comment Avi. Personally, I am not a great fan of technical stories. I prefer to use a modelling language like UML to describe requirements for a technical product like an internal software platform, as I find natural language too ambiguous for the job. Hope this helps!

  • Magali Janvier says:

    Hi Roman,
    We also do some offline qualitative research and interview users regularly (phone, email…) – we then combine the lot. It’s also important to track feature usage… Good post idea!

  • Magali Janvier says:

    Hi Roman,

    I regularly read your blog and my eye caught the image of this post. We have an image on the Planbox home page that looks almost the same!

    I totally agree that user feedback needs to be regularly integrated to the backlog and that it greatly helps in defining priorities. At Planbox, we get back to all the users that submit feedback – big our small.

    We were finding it hard to keep track of all our user feedback so we developed a widget through which users submit feedback so we can then wither create a story from that feedback or add it to an existing story.

    What’s also important is to communicate with the users who have submitted the feedback. To let them know they have been heard and have helped.

    Mag

    • Roman Pichler Roman Pichler says:

      Hi Mag, Thanks a lot for sharing your approach to gather and manage user feedback at Planbox! It’s great to hear that you value feedback and act upon it. My preference is to combine qualitative and quantitative techniques, for instance, interviewing users and measuring which features they actually engage with. This makes me think I should write about the different approaches and their strength and weaknesses in a future post. Thank you!

  • Yi Lv says:

    Hi, Roman:

    Glad to see your post on emphasizing the emergent property of good product backlog. Static backlog is a clear smell. I happened to write on the same topic recently, http://blog.odd-e.com/yilv/2012/01/we-dont-have-emergent-requirements.html

    Thank you!
    Yi

Leave a Reply

Your email address will not be published. Required fields are marked *

Sign up for great new content from Roman

Hear about his latest product management work including new articles, videos, podcast episodes, and more.