Three 2x2 matrices to help you prioritise your product backlog
All of life’s hardest problems can be boiled down to a good two by two framework.
Kim Scott, ‘How to be a Kick Ass Boss’
So, you need to work out what feature to build next or even if it’s worth building at all. Fear not, there’s a 2 x 2 matrix for that (well, actually there’s lots of 2 x 2 matrices for that). The 2 x 2 matrix is hugely appealing to business and product leaders because (a) they’re simple to understand and (b) they offers a framework for decision making that weeds out pet projects and low value ideas. Once you’ve mapped potential features and projects against a couple of axes (you know, like the plural of axis, not the thing you chop wood/zombie necks with) you’ll be prioritising that roadmap like a pro.
1. Risk/Return Matrix
This matrix helps you identify the order in which you should complete projects, following the principle that it is most useful to take on high risk, high value projects first. Removing risk is critical because, whether it’s trying out a new pricing model or adopting a new technology the impact of it going wrong or negatively impacting other projects is higher than it is for other tasks. You can also see this as the risk associated with not doing something. If you’re considering a feature that customers are crying out for but which a competitor already provides the risk of not implementing it may be high (it may not be of course, that’s why you need to understand this in the context of your business).
The ‘return’ axis on this matrix is sometimes (often) labelled value, which is probably more flexible but isn’t quite as memorable as the alliterative risk/return. Either way you need to define what you mean by return or value. It might be sales, customer retention or even regulatory compliance, but it’s essential that you know what’s valuable to your business right now and also what the likely return on the projects you are prioritising will be.
Once you’ve mapped all your features on to the matrix you’ll quickly see which ones you should focus your attention on. Work your way round the matrix anti-clockwise from the top right quadrant. Pay close attention to anything that ends up in the bottom right quadrant. These are the things that you should NOT be doing. Why on earth would you take on a low return, high risk project?
2. How many/How often matrix
The road to hell is signposted, ‘Just this once, for just this customer’.
(I have no idea where I heard this quote. Joel Spolsky maybe?)
This seems so obvious and yet it’s often overlooked. Before you build something, have you actually thought about how often it will be used and by who? Would you rather sink your time and energy into something that’s used by 70% of your customers every day or something that one customer uses once a year? Now, before you say ‘but this is our biggest client and they really need this’ think about product focus and product sustainability. Is that customer always going to be around? Are you going to lose that customer if you don’t build this feature? Will you start to lose other customers whose requirements you can’t meet because you’re building this client’s pet feature?
One anti-pattern to avoid here is assuming that the ‘how many’ always needs to apply to your existing customer base. If you have good evidence that adding feature x will add more customers who will then use that feature on a regular basis then by all means mark this feature high on the ‘how many/how often’ matrix.
As with the risk/return model you’ll end up with some items that sit in the quadrant of doom. The ‘rarely used’/‘one customer’ corner is a sad and, hopefully, lonely place. There might be a really, really good reason to do something that’s in that corner (like maybe you need the cash from a client to pay the bills this month) but, in general, you want to be shooting for features that sit in all the time/everyone corner. Don’t forget about the ‘everyone’/‘rarely’ corner though — it will likely include essentials like ’resetting a password’ that are rarely used but have a benefit to your entire customer base (or your long suffering customer service team). You want to ensure a good mix of these coming through the pipeline.
3. The Kano model
I imagine that you now have an exciting list of valuable, risky features that will be used all the time by all your users. But how to decide which one to work on next? How do you decide whether improving the responsiveness of your app is more important than adding fingerprint recognition? Or whether you should spend time developing offline support rather than social logins. The Kano model offers an excellent way of categorising your features by type so that you can deliver a balanced set of features that doesn’t miss the essentials. And it is more exciting than the previous two matrices because it features not one, not two, but three arrows.
The principle behind the Kano model is fairly straightforward. Features can be categorised as must-haves, linear or exciters (sometimes called must-be, performance and attractive respectively) depending on the level of customer satisfaction that they generate relative to their level of implementation. Must-haves are those features that the product, y’know, must have. Like the ability to send an email from your email client. Linear features are those which make customers more satisfied the more fully they are implemented. Maybe added productivity tools in your email client. They don’t have to be there but the more of them there are and the better they’re implemented the more satisfied customers will be. Finally, exciters are those features that go above and beyond, generating huge customer satisfaction even if they’re not fully implemented or make up only a relatively small part of the product. Returning to our email client this might be something like Gmail’s auto-complete or ‘canned’ responses.
And to think, all of this was invented by an international arms dealer with a laser for an eye…
You can map your features on the matrix using your gut or reach out to your customers to try and identify what type of feature you’re looking at. If you’re interested in how to do this scientifically I can’t recommend the Folding Burritos article on how to implement Kano highly enough. Mike Cohn’s canonical Agile Estimating and Planning also covers this approach in detail.
If you’re iterating on top of an existing product it’s quite useful to map everything ‘as is’ and see what happens to customer satisfaction as you implement features further. Needless to say, if you have a load of barely implemented ‘must haves’ on your list you should probably start implementing those. Also worth noting is that what was once an exciter may not be anymore. A remote control for a TV was once pretty exciting, now it’s a must have (though recent mobile apps for controlling TVs are an interesting example of a must-have being reinvented as an exciter).
There are many other prioritisation techniques out there. ‘Buy a feature’ is particularly good fun (sadly it doesn’t fit neatly in to the arbitrary confines of my 2x2 matrix theme) but hopefully these give you a good starting point. Which others do you use? Have you had any successes (or failures) with these?
If you’d like to use the matrix images please feel free. If you want something higher-res I’m happy to send you the Sketch file.
