Managing a Product Backlog

A product backlog should fade from highly detailed descriptions of work to be done by a team through mockups that are being improved by showing them to customers into less detailed ideas and areas for further investigation.

Top section: Happening

These are things that are going to happen. The idea should already be well understood, and the primary work is on polishing these items, for example by running a backlog story checklist over them.

Middle section: Evolve mockups

You are reasonably confident that the items here valuable to customers, and the task is to evolve mockups of the feature with customers. It is important to give these things time to be worked on and improved. You'll have ideas, bounce them off customers, collect feedback, think about it then try another approach. Apart from time, the other thing you need for these is ideas and people who are interested in them. That is the purpose of the next third section of the backlog:

Bottom section

This section is for thoughts and ideas that you have, but which may or may not become part of the product. Research might involve sending out a survey to existing customers about some idea, or keeping track of incoming requests. It is important to not only record how many people are interested in an idea to gauge overall interest, but also build a pool of people to talk to when refining an idea.

People do not respond to emails like 'Please help us research \<PRODUCTNAME>', but they are much more interested when your email is basically 'I'm going to pay engineers to add the specific feature you requested to the product you use every day. I collect people's email addresses and comments in a Word document per feature. Keeping comments in people's own words is important too.

It is worth noting that ideas may well start in here as problems people have, rather than explicit solutions to those problems. Eventually you'll have to solve the problem, but there is no need to rush toward a solution.