"Focus on doing a few things really well. Spreading your efforts across too many projects prevents any of them from succeeding."--Steve Johnson, product management evangelist (yes, I’m quoting myself) [Tweet this]
I was in an airport after a conference and watched a fellow passenger groom his backlog. He was old school; he had his stories on index cards. And he was flipping through them, moving some around, making notes on others. Finally, when my curiosity got the best of me, I asked, “Are you grooming your backlog?”
He was surprised I had a clue about what he was doing. We had a nice long discussion about his job, his role in the product team, and his difficulties in knowing how to feed the team with user stories.
The big issue: knowing what to give them next.
Prioritization is a critical skill for product management.Prioritization is a critical skill used for many of the items in your product playbook. The basic tenet of prioritization is to make a list of all the things you want to accomplish and order the list based on value.
We don’t want the product team cherry-picking the list for easy stuff or fun stuff. We always want them working on the most important thing. And we don’t want product managers and product owners just guessing; we want to know that this is more important than that.
It’d be ideal if we can hard facts to work from, like the results of a survey or perhaps the “jelly beans and fishbowl” approach described in my ebook,"On Roadmaps and Roadmapping." But absent hard facts, we ought to be able to use our judgment and simple prioritization scheme.
Here’s one approach…
For every idea (epic, story, feature, whatever you call it), assign three values:
- Value to us
- Importance to our market
- Dissatisfaction with current solution
“Value to us” describes how the idea will increase your organization’s revenues or decrease its costs. For example, a sizzle feature for the sales team probably won’t increase customer satisfaction but it might increase sales—or at least inspire the sale team. As for saving costs, adding a logging feature for customer support won’t likely increase customer satisfaction either but it gives a powerful tool to the support team—it will help them discover what really happened and reduce the time and cost of the support call. Another item that falls into this category is architecture. If you’ve heard about technical debt, you know maintaining a software product becomes increasingly difficult over time so you have to rewrite sections of code periodically to make it easier to maintain.
“Importance to our market” provides an assessment of the impact of the problem or the value of our proposed solution. Obviously we want to focus on the items that are most important to clients.
But wait! Do they have an alternative? “Dissatisfaction with current solution” specifies how satisfied customers are with the status quo. Are they happy or unhappy with it? For example, one company created a product that substantially increased productivity. With their product, clients could reduce admin staff by one person. But the cost of the product was about the same as the salary of the admin person so customers determined that the existing solution (an admin) was acceptable. Their “dissatisfaction” was low.
Many customers have existing solutions to their problems. Your product has to overcome their resistance to change by being much better than the status quo. How many people use Excel as a database? Or retype data from a report into Excel so they can do some calculations. It’s tedious but it gets results.
Or for that matter, how many times do I have to key a phone number into my phone that I’m reading from my computer? You’d think by now I could pair the two and click something on the computer to transfer it to my phone.
Or how often must I type a meeting id and password into my phone’s dialer from the info in my phone’s calendar? Sure, I have a solution—do it manually—but when compared to an automated method, I’m very dissatisfied.
So you’ve specified amounts for value to us, value to them, and dissatisfaction. Multiply these together to determine business priority.
Now ask your technical team to consider “Effort to deliver.” Some items are bigger than others. Some are small; some are huge! Don Reinersten’s concept of “Weighted Shortest Job First” says, all things being equal, you should work on the smallest thing first. That way, you get value the soonest. So for effort to deliver, take into account the effort of each item including size, complexity, need for skills beyond the team.
Since you’re unlikely to have hard data for any of these values, use a relative system. This more than that. This is more valuable that that but less that the other thing.
The formula to use is:
(Value to us) × (Importance to our market) × (Dissatisfaction with current solution) ÷ (Effort to deliver)
You can use this prioritization scheme with low, medium, and high or 1 through 5 or use a Fibonacci system. You can use the scheme with roadmap items, products, features, epics, and stories. For that matter, you can use it for promotional items as part of an agile marketing plan.
Are you grooming your backlog by shuffling? Or are you using a system?