In the first part of this article, I provided some high level steps to get you from an idea to a user-centered Product Vision supported by personas.

In this final part, I’ll touch on one of the tools you can use to build on those artifacts and get an initial version of the Product Backlog.

Now, irrespective of how you are going to deliver this product or service, you will need two vital foundation elements to make sure you build the right thing, and build the thing in the right way.

“The first is a business value model. What are the goals you are trying to achieve from this product or service? You should have a pretty good idea of these from the work you did in defining the Product Vision.”

The second element is a list of the critical success factors that will determine if you have met those goals. In short, how are you going to measure if you are delivering the value you want, and how are you going to ensure that you are not wasting time and money over-engineering this to a point beyond what is actually needed? Agile organisations and teams are focused on delivering “just good enough, for now”, and no more.

A simplistic example might be to have a goal for the next car you are going to buy of “carrying my immediate family”. Initially, that might be just you and your partner. You only need two seats. But over time, your family may well grow, and you’ll need more seats. But you don’t need them right now.

The element of time, and the order in which the product or service may evolve over time is missing from the Product Vision. So we move to use the next Product definition tool in our toolbox – The Product Roadmap.

Again, I’ll refer you to the excellent resources made available by Roman Pichler. His Go Product Roadmap is an excellent tool, although of course other roadmap formats are available. The Go Product Roadmap was published late in 2013 by Roman, and I have recommended it to clients ever since.

I won’t go into the details of how to work with the roadmap, as Roman does an excellent job of that.

So I’ll skip forward in time to a point when you have completed your roadmap. I suggest you read through the presentation and explanatory material on Roman’s site before going further.

Now with your roadmap completed, you have versions of your product or service identified, each with a target completion date, goals, a high level list of features and the metrics you will use to track if you have met the goal for that version. It will look something like this

Now if you look at the features, goals and metrics across the different versions of the roadmap, and rotate them by 90 degrees, you might end up with something like this.

Let’s review what we expect to see in a Product Backlog, at a very basic level.

1.A Prioritised list of features.
2. Each feature should have an associated business value that aligns with
the overall business value model.
3.Each feature should have measurable success factors associated with it to
ensure we deliver to the right levels of quality – “Just good enough for
now, and no more”.

You have created a very high level Product Backlog!

Going through the steps in part one and two of this article will give you a simple framework to get you to this initial Product Backlog. It can be considered the Launchpad for the project.

Be aware though, that there will be a lot more work that will be done on reviewing and refining the backlog throughout the life of your project to make this brilliant idea into a successful product or service.

I wish you all the luck in the world.