More on prioritisation…
Previously, we covered how Product Managers and Product Owners can practically apply the “4-quadrant” idea to prioritise product backlog items. Sorting features into the 4 quadrants is a very general way to think of prioritisation.
Today, I want to introduce a few other useful and practical ways to frame the relative priority of features. Each requires a different mindset and when used collectively, they allow you to consider features from different perspectives. Looking at features from different angles in this way can help when you are faced with tricky prioritisation decisions and tradeoffs.
The Kano Model
Often Product Managers are faced with a choice of improving existing features or building entirely new features, and because the nature of these options is so different, it can be difficult to figure out how to prioritise one over the other. A useful way to frame these kinds of decisions is to think through how likely it is that a feature will satisfy customers. You can then weigh this up against the expected cost to implement the feature, and decide which features make economic sense.
The most commonly used example of this approach is the Kano Model, created in 1984 by Noriaki Kano of the Tokyo University of Science and still used widely by organisations of many types. The idea is to plot the relative positions of features on a chart with customer satisfaction on one axis and level of functionality on the other. The potential for customer satisfaction by functionality can be determined by market research techniques like surveying customers, subject matter experts, and/or internal stakeholders or by leveraging satisfaction scoring results from previously implemented features. Exactly how you determine customer satisfaction scores is up to you – the point is to end up with meaningful relative scores of the features you need to prioritise.
Performance features
Performance features are the most important features to customers; the ones that make your product useful and unique. For these features, customer satisfaction is directly proportional to how well your product performs them.
They are well-known (eg. for an enterprise product, they would appear in RFQ and RFP documents), they are readily measurable (it is easy to compare how well different product provide these features, relative to each other), and satisfaction is easy to relate to the level of functionality.
Examples of performance features are battery life in a mobile phone or picture quality in a television. The more a customer gets of these features, the more satisfied they are. Performance features are sometimes referred to as one-dimensional features.
Performance features are those where the more a customer gets, the more satisfied they are.
Basic features
Next, basic features are the “must haves” in your product; the features your customers take for granted. For the product provider, there is only down-side for these features. If your product does them poorly, customers are dissatisfied, but if your product does them well, customers just remain neutral. Think of providing these as the minimum price for your product to enter the market.
Basic features are taken for granted. They are not always explicitly stated, but if they are missing, the customer will actively express their dissatisfaction.
Basic features are the features customers take for granted.
From a prioritisation point of view, the two important things here are (i) incremental investment in basic features yields large improvements in customer satisfaction, but (ii) no matter how good the functionality is, it won’t lead to positive customer satisfaction. In other words, once you have “good enough” basic functionality, it’s usually wasteful to invest more in it.
Excitement features
Excitement features are features customers didn’t expect, but which delight them. In fact, the customers probably hadn’t even thought of them until they saw or used your product. They don’t cause dissatisfaction if missing, because without your product the customer would never have even known about them.
It is worth noting that delight decays over time. As products (and competitor products) mature, features that were once considered excitement features tend to become basic needs. To ensure customers remain satisfied, it is necessary to keep delivering new excitement features that delight.
A great example of an excitement feature is the inclusion of a digital camera in early smartphones. Customers were not expecting it, but it was something that made them go “wow!”. At the time, it was most definitely an excitement feature. More than a decade later, however, we all just expect any smartphone to have an integrated camera, so today it is considered a basic feature.
Excitement features are the ones that delight customers.
From the shape of the satisfaction/functionality curve, you can see that excitement features are where you will get a lot of “bang for your buck”. Delivering any level of functionality in this category improves customer satisfaction, and usually more functionality rapidly moves the customer satisfaction needle.
Indifferent features
Indifferent features are those that the customer simply doesn’t care about. Customer satisfaction remains unchanged whether these features are in the product or not.
Indifferent features are those customers don’t really care about.
From the location of these features on the chart, you can see that these types of features are best avoided. They are usually a waste of money. No matter how good your “indifferent” functionality is, it’s not going to increase customer satisfaction.
Reverse features
Reverse features are those that not only cause dissatisfaction: the customer would be more satisfied if the features were not there. In other words, these features annoy customers. You want to avoid these features entirely.
Reverse features are the features that actively annoy customers and lead to dissatisfaction with your product.
Using the Kano categories to prioritise
The aim is to create a product with an optimal mix of the first three categories: performance, basic, and excitement features. And to avoid indifferent and reverse features.
In order to come up with relative scores for proposed features, for each feature you need to determine or predict how customers would feel – in terms of satisfaction with your product – if they did have the feature, and also if they did not have the feature.
One way to do this is to consider a matrix of customer reactions to both having and not having a feature, as shown below (see Reference – this was first documented in a 1993 paper in a quality management journal).
It can take a while to get your head around this matrix. To help, here are some examples.
· If a customer dislikes a feature being absent but likes it being present, then that feature is a performance feature: the better you implement that feature, the more satisfied the customer will be.
· If a customer expects a feature to be absent, but dislikes it being present, then that feature is a reverse feature: the customer will be more satisfied if the feature is absent.
· If a customer likes a feature to be present but doesn’t care (or can live with) it being absent, then it is an excitement feature that could potentially delight the customer.
[Note that the table and the ideas behind it are not new. In fact, this has been around for decades. A table like this was introduced by Fred Pouliot in a 1993 paper “Kano’s Methods for Understanding Customer-Defined Quality” in the Center for Quality of Management Journal.]
Practical tips
Here are some practical tips for using the Kano Model to help figure out the relative priority of features.
Use for features with tangible customer benefits
A product backlog inevitably includes many types of initiatives. The Kano Model is only useful for evaluating the relative priorities of product initiatives that provide tangible benefits for customers. For example, you can use it for a potential new module that solves a novel problem. But you cannot use it for a design refresh or technical debt repayment.
Select customer segments carefully
Most products are targeted at multiple customer segments, each with different needs and therefore, different responses to the product. Keep this in mind when selecting customers to survey for a Kano Model analysis. As an example, small businesses using an accounting package are probably less interested than enterprise customers in a feature that can match purchase order numbers to invoice numbers.
Customer maturity can influence results
A more mature customer, with more sophisticated processes and better trained staff, will be more aware of features available in competitor products. For example, a heavy equipment OEM will likely be more familiar with maintenance scheduling features in competitor products than a newly established construction site.
Phrase questions around customer benefit (as opposed to your proposed solution)
As with any type of survey, the way you phrase questions can influence the answers you get. Because the Kano Model is used for features with tangible customer benefits (see above), a good approach is to phrase the question in terms of the customer benefits, rather than describing the solution. For example, “If you could review and approve multiple purchase orders, how would you feel?” is a better question than “If you had a multi-edit grid-style screen that showed purchase orders where you could click on individual orders to approve them, how would you feel?”.
“Relative importance” can help break deadlocks
You can ask customers to rank the proposed features in order of importance. This can help decide between features that end up with the same Kano Model score. If enough customers find one feature more important than another – despite expressing the same preference for having/not having both features – then you can be confident the one ranked as more important should be higher priority.
Test questions before customers see them
Just as you would with changes to the product itself, share your questions internally to verify they make sense, before releasing them beyond the walls of your organisation.
Must, Should, Could, Won’t (MoSCoW)
The second approach is to sort features into 4 groups: Must have, Should have, Could have, Won’t have (sometimes referred to as MoSCoW). You can then consider the capacity you have for implementing features and work backwards to decide which features of each category to add to your plans.
A useful way to apply this technique is to decide on how much effort you are willing to allocate to each of the first three categories and use this to turn your prioritised list into a time-based plan.
In the example below, the decision has been made to allocate at most 60% of available effort to “Must have” items, and then fill the remaining time with “Should have” and “Could have” items.
The principle here is consistent with agile methods, in that the aim is to prioritise items by reduced benefit, as opposed to increased cost. In other words, assume that schedule/cost is fixed, and scope can change, as opposed to the waterfall approach where scope is fixed, and cost/schedule can change.
We set out with the intent that a worst-case outcome delivers the “Must have” items, the expected outcome delivers the “Must have” and “Should have” items, and a best case outcome delivers everything (“Must have” + “Should have” + “Could have” items).
The capital redeployment equation
Another approach is to consider the return on investment (ROI) of features, even after you have started working on them. The fact you have started implementing a feature does not mean you need to finish it. There are times when it is a wise business decision to abandon a feature.
It might sound simple, but it is worth spelling it out: when the future cost of a product initiative is higher than the future value of that initiative, it’s time for the initiative to end.
To determine an initiative’s end, you need the following metrics:
● The value (V) of the remaining product backlog items
● The expected cost (EC) of the work to complete the remaining backlog items
● The opportunity cost (OC) of completing the remaining backlog items (in other words, the value of having the team work on some other initiative instead)
When V < EC + OC you are better off stopping the initiative and redeploying the resources away from the less valuable product initiative to more valuable initiatives. There might also be some costs to switch and not complete the initiative that is in progress, so you need to also consider those costs.
It is good to keep this “capital redeployment equation” in mind when considering prioritisation. Failure to do so can lead to inefficient use of resources and throwing good money after bad.
Summary
A key aspect of the product management role is prioritising what to build, and in what order. There are always competing demands, and there is always too much to do with too few resources. Prioritisation decisions can make or break the success of products and entire technology companies.
As with so many disciplines, in the uncertain world of technology products and business, continually adjusting your perspective and approach as new evidence comes to light is a sign of maturity.
And whilst this article is not an exhaustive coverage of all ways to approach prioritisation, hopefully it has at least prompted you to reconsider prioritisation to help ensure you consider more than one angle. Doing so not only improves the chances of getting these decisions right; it also gives you a way to explain your logic to key stakeholders, and a way to learn from those times when you didn’t make the optimal choice.
