Goal Mapping

A product backlog is a queue of work. And queues aren’t something we should aspire to, rather we should have the smallest queue (or no queue) so we can get our products out quickly.

Some thoughts on backlogs from Gabrielle.

I’m getting this blog out but it is unedited and sans pictures. I’ll get to it next week and add some examples.

I feel like a traitor to the revolution, but backlogs are really getting to me. A product backlog is a queue of work. And queues aren’t something we should aspire to, rather we should have the smallest queue (or no queue) so we can get our products out quickly.

A queue means we waste time managing it. A queue means we are always behind. Queues are boring.

And who ever thought that a list is a good way to represent the complexities of product design? Instead we build tactical products that are either launched as one big batch at the end, or cut up to fit into nice two week iterations which doesn’t exactly help the usability. Features are tacked on until they look like the Frankenstein of products, or ‘frankenbuilds’.

To help with this, user (or customer) journey maps were used to model out the users flow of activities. I’ve seen various forms that take present state and future state views.

Another derivation of this is Jeff Pattons Story Mapping. This is a very useful tool and far better than any linear backlogs I’ve seen. I’ve been using this approach for years and in some situations still find it pretty helpful, especially for building new products and wanting to lay ideas out collaboratively to understand the journey maps.

There were challenges however. The people working on big infrastructure, complex products and services said it didn’t work well. It also became hard to manage large products. It also still lead to building a lot of features, something I always want to negate to build the least output to deliver the most outcome.

Traditional requirements gathering and backlog creation activities such as user story writing and user journey mapping can lead to a lot of features generated that then need to be cut bac. In many traditional requirements gathering, a list of work items is gathered in one hit so stakeholders are incentivized to add as many items as they can as it is their only chance.

In Agile teams, user story workshops have stakeholders lay out the stories they need and cluster them into ‘epics’ (a large story) or ‘themes’ (a collection of stories).

Both of these approaches are what is called ‘divergent’. Think of this as a process to generate a lot of ideas. The problem with divergent approaches is that you then have to move into a convergent state, or cutting things back to reach a logical solution. Don’t get me wrong, there is a place for this sort of thinking when you want to come up with a lot of options quickly, however continuing this practice into backlog item creation can often generate more waste in extra features and time spent.

As soon as backlog items are generated they take on a life of their own and become somebody’s baby to nurture and defend. And nobody wants to get rid of their baby so guess what happens? Yes they live on. Usually in a large backlog that then has to be continually maintained which means more time and distraction for the product manager.

Another issue is that simply coming up with a lot of ideas creates disconnects between the outcomes, and the user flows that are generated. Teams jump from having a cohesive model that helped us see where value can be created quickly, to falling back into old traps of creating a big pile of features. Then there are the logistical issues. Creating large user journey maps means a lot of wallspace, and in many organizations, it’s not something you can keep maintained so then teams try to move to a virtual journey map. Then you are back to tools and lose the cohesion and collaboration that is the main benefit of this approach.

An alternative approach that I started through necessity back in 2004 was something I’ve called Goal Mapping. Yes, another mapping technique but the name seems to have stuck so I will continue to use it.

Instead of coming up with all of the features and laying them out, we instead built the goals first and reverse engineered the steps to find the smallest amount of work and shortest path to reach the goal. The idea is to find the shortest path and least amount of work to hit the outcome.

This keeps teams focused on what matters whereas the story writing or story mapping techniques actually encourage people to come up with multiple combinations and possibilities which can add more noise and complexity to our product – and don’t actually help us get to our goal as quickly as we can.

There is a happy medium when story maps are working well and that is by creating story maps that are goal oriented and for changing interaction design flows, this can work very well.

How to lay out a goal map

Take the Target Outcome: ‘Increase the number of check out conversions’.

Define the users goal and outcome: ‘Read a book – quickly’ (and be clear what ‘quick’ means e.g. ‘under one week or under one minute’.

From the users perspective, they are satisfied when they have the book in their hands. This means they need the least amount of steps and complexity to find and receive the book.

So instead of saying ‘come up with all the things a user does to buy a book’, start at the end.

Goal: Find and receive book

Now put in the steps to do this. To get this product out quickly, there have be a simple keyword search so they can search on the title or author or even category. We then present the search results and the user can select the book and if a repeat user, make it one-step-buy option. Of course people will start to say ‘but we need to see reviews, add to a wishlist etc’. Ok sure, we can do that but let’s start with the simplest thing that can work and get that out, then we can test out which options people use the most frequently (or look for when testing it) and build those features next. Don’t add all the options up front as your stakeholders will desire them. Add them as needed and try to prototype and test that they are actually used as opposed to being theoretical request.

Creating goal sets

Once you have laid out the core path to reach your goal, we can deliver it, or run an experiment and test that it will return the value you desire. We might create a prototype and test it with some users to pickup any glaring usability hurdles. Or we might split test it with a small portion of our actual users and measure the viability against our current users. This moves us from chaotic product and service management to a more disciplined process based on facts, not forecasts.

The common question back at this point is ‘but our system needs to be really big and complicated and if we add features on after the fact, we will destroy the design’. So design for change. Build with change in mind and create a flexible architecture that allows you to add new layers to your user flow. Create releases that batch together features that are usable, don’t add one at a time each week, which will really annoy your users.

Amazon has constantly iterated based on the data they capture and have refined, added and removed features. Start with the minimal usable product or service that you can and test features before you add them. See if the value they return is worth continuing the investment, otherwise invest elsewhere.