Kano analysis was created by Professor Noriaki Kano in the 1980s and is used to optimise a product by categorising its features by perceived customer value. In a simplified form, a product’s features can be split into three types:
- Essentials – those product features are essential for the customer to even consider buying it.
- Linears – those product features that are linearly valuable, ie those where doubling an element of the feature is perceived as being twice as desirable.
- Delighters – those product features that delight a customer – usually only a small number being necessary.
For example, considering a hotel room as a product, an Essential feature would be cleanliness; a Linear feature would be room size and a Delighter may be free wireless internet (wi-fi) access. Interestingly, over time, Delighters become Essentials – as customers’ tastes become more sophisticated, through advances in technology and competitive pressures increase. For example, in the 1950s, a car-heater would be a Delighter, whereas today it is an Essential.
Kano analysis is useful in product development. Potential customers are asked questions on possible features and careful analysis distinguishes between the three feature types. All the Essential features must be included; the Linears are optimised to a cost/technology limit and a few Delighters included. It would be unlikely to be cost-beneficial to include all the Delighters – competitor analysis is important here.
There are interesting analogies between Kano analysis and the prioritisation of system requirements. One of the most common methods is via the MoSCoW method, so called because requirements are categorised into one of four:
- Must have – features that are needed, in the next version, otherwise the project is not worth continuing.
- Should have – features that needed, but not necessarily in the next version, as short-term workarounds can be used.
- Could have – features that needed be delivered but this is more likely to be in a later version as longer-term workarounds can be used.
- Won’t have – features that are not being considered for next version; these features may be re-prioritised when planning for subsequent versions.
Consider the example of a portable music device. An Essential (Must have) requirement would be that it has to play music. A Linear may be the weight of the device; the lighter the better. A certain weight is a Must have; half that weight may be a Should Have.
The interesting category is the Delighter. How would you categorise a Delighter in requirements terminology? The problem is that different people are delighted by different features. It is unlikely that it would be feasible to implement all of them, so most will end up in the Won’t Have category – at least for the initial delivery.
This is where the product description is so important, as it gives a steer as to the relative priority. If, in our example, the product description is “a portable music device”, then a Delighter, such as Bluetooth capability may be categorised as a Could Have, as music could be transferred onto the device by other means. On the other hand, if the product description is “a portable music device to enable social networking”, then Bluetooth may be categorised as a Must Have.
So much for products, what about systems engineering projects? In this case, a “project description” is worth formulating at the start. This is a phrase that is agreed by the project stakeholders which encapsulates the project’s aim in less than ten words, stated in terms of the project’s main beneficiaries. Having agreed the project description with the sponsor, the senior stakeholders can make a judgement on the priority of the Delighters.