Organisational Purpose and the Kano model
If you work in product management, you should make yourself familiar with the Kano model.
Noriaki Kano, a Japanese researcher and consultant, published a paper in 1984 with a set of ideas and techniques that help us determine our customers’ (and prospects’) satisfaction with product features.
The resulting categories have been translated into English using various names (delighters/exciters, satisfiers, dissatisfiers, etc.), but all refer to the original articles written by Kano. You can read up more at https://foldingburritos.com/kano-model/
Using the understanding from this model, product persons classify features of a product as follows:
- Basic/Threshold
These are features that are indispensible. If they were not present, anyone using this feature would be immediately dissatisfied. Think of a hotel room that is lacking a bed. These are the „must-have“ features. - Performance
Sometimes a feature or capability exceeds expectations. Some basic functionality turns out to be very fast or intuitive, or looks very pleasant. These are Basic/Threshold features that come with improvements. A real-world example would be an extra-comfy bed in the hotel room, or that one discovers more power outlets than expected. - Excitements
Features that are completely unexpected, things that one wouldn’t normally associate with a given product or service are Excitements. Users would not think of asking for them when a product is described, but when they find them, they are delighted about it. Usually, this is a novelty factor („I would not have expected a cold brew coffeemaker in this hotel room, but I like it!“), and they will not always be the deciding argument for a purchase. But they are noteworthy and will ensure that the product or service is remembered well.
I’ve found this model quite useful when it comes to prioritizing tasks, or to figure out whether a product is „ready to ship“.
What makes teams tick?
For the past few months, I’ve been on a bender reading various books on how to best run a team or a company, how to be best manage people, or how to generally think about work. The current item in that stack of books is „Reinventing Organizations“, by Frédéric Laloux. I’ll not go into the details and my criticism of the book right now, but one thing that tickled me was the story of how a brass foundry stated that part of their purpose was to be be loved by their customers.
As a result, workers take delight in hand crafting little presents to put into the crates when shipping an order of gearbox parts.
And that brings me back to the Kano model, and that I think we should add one quality: Is it satisfying or exciting to make this Feature?
We see a lot of work in the FLOSS sector embodying this quality. Something gets made because the people working on it found it exciting. Either because they wanted to have the resulting functionality, or because building it is an interesting challenge, or because they could already envision the reaction of the users when they’ll find the hidden easter egg.
Trying to find out what features have this „exciting to make“ quality can be a tremendous boon for product people, and I will surely add this to my toolbox! Partly because you can now select for maximum team satisfaction, but also because you can recognise rabbit holes and nerdsniping before it happens and let the team know that a certain functionality might be cool to build, but isn’t helping in any of the other Kano qualities.
Schreibe einen Kommentar