Tag Archives: prioritization
Being a Product Manager and an Agile enthusiast, I spend a lot of time and energy working on prioritization. It is both an art and a science to make sure that you and your team are working on the most important thing. The first in this blog series on prioritization answered the question “Should we do this at all?” and the second shared different tools to help with prioritization, specifically MoSCoW and the Risk-Value Relationship. In this blog, we will tackle the Kano model, which holds a special place in my Agile story. I first learned about it when I was doing research for our Agile textbook. It then found its way into Businessolver and was a part of the story regarding how we addressed our Product Roadmap. Very cool.
Kano Model Explained
First introduced in the 1980s by Professor Noriaki Kano, it is a great tool for Product Managers to use when assessing different kinds of value. The vertical axis represents satisfaction. The higher you are, the more satisfied you are – one might say ‘delighted’ to put it into Businessolver terms. The horizontal axis represents how well something is done.
Looking at the grey line first, these are basic needs – the ‘must haves.’ Thinking in terms of a hotel experience, we expect there to be hot water. Hot water is table stakes for a hotel experience. If you don’t have hot water, meaning the establishment didn’t do it well, then you are highly dissatisfied. However, if the hotel did have hot water, meaning they performed that function very well, it does not delight you. It is expected, so when done well, it doesn’t even register in your mind.
The blue line represents performance needs. This could be the check-in process at the hotel. It has the opportunity to dissatisfy – if the lines were long, the desk clerk inefficient or your room wasn’t ready – those circumstances could be very disappointing. Conversely if they recognize you when you walk in and you are greeted with speed and efficiency, then you might be pleasantly surprised, heading towards delighted.
As introduced in the first blog, prioritization is difficult. The first and most important question is “should we do this at all?” Once you determine that an effort is worth doing, we have to figure out where it falls relative to the other things in the queue. There are a number of tools that we can use in this effort.
The first tool in our arsenal is from Dynamic System Development Method (DSDM) and it is an acronym for Must have, Should have, Could have, Want. The technical definition for each category is as follows:
Must have: all features classified in this group must be implemented, and if they are not delivered, the system would simply not work.
Should have: features of this priority are important but can be omitted if time or resources constraints appear.
Could have: these features enhance the system with greater functionality, but the timeliness of their delivery is not critical.
Want to have: these features serve only a limited group of users and do not drive the same amount of business value as the preceding items.
To put MoSCoW in action, we pull a reference from our book, Introduction to Agile Methods. In this example, we are looking at the payment methods that could be offered on a new eCommerce site.
Must have: ability to accept Mastercard and Visa
Should have: add American Express and Discover
Could have: add ACH payments for transactions directly through banking institutions
Want to have: add gift cards
By understanding where each feature falls relative to the MoSCoW parameters, the prioritization is much easier.
As a Product Manager and an Agile Enthusiast, I have lots of conversations about prioritization. It is really tricky. Well, that’s not always true. If you really only have one thing to work on, then I guess it’s easy. For the rest of us that live in the real world, we have to balance multiple number one initiatives in a way that will deliver the most value to the business. This is a first in a blog series about Prioritization.
The First Question
The very first question that should always be asked when considering something for prioritization is – Should we do this at all? People are too often moving too fast and trying to be responsive to the point that sometimes we stop thinking. One of my mentors had a saying: “This is top of mind, not top of list.” I love that. I first heard this when he called me after just having talked to an important client about a feature they wanted. He was excited and it was a good idea. I asked him if he felt like we should reshuffle our priorities and execute on this newly introduced concept. He paused and took a moment to really think through my question. And then he responded with the now often quoted “Top of mind, not top of list.” That is a fantastic barometer to keep in mind when you have a flash of brillance. It might just be a flash and you need to stick to your existing priority list. Bright, shiny objects can come into view, but they do not always warranted our immediate attention.