Pragmatic Marketing has published an article on Kano Analysis. The article was written by Scott Sehlhorst and represents a merging of two of the posts (1 2) at Tyner Blain that focus on Kano Analysis.
Goldilocks and the Three Products
Michael on High-Tech Product Management and Marketing has a fantastic “wish I wrote that” post about the importance of having the right number of features. He has several references, the best of which is Kathy Sierra’s Featuritis vs. the Happy User Peak post from June 2005. The two posts combined provide great insight into why having too many features is bad, while acknowledging that too few is just as bad. In this post we will look at what we can do to apply these insights and also change the rules some, making our software more desireable than our competition.
Epicenter software design – 37signals applies Kano
Jason at 37signals has started a discussion about feature prioritization with his recent post. He describes the epicenter of software as the most important, must-have feature. He argues that this feature should always be the one that is built first, since without it you don’t have an application. This is the same approach we reccommended in our recent post about prioritizing requirements with Kano analysis. The epicenter, while critically important, isn’t sufficient to drive success for the software.
Prioritizing Software Requirements – Kano Take Two
In our previous post on Kano requirements classification, we introduced the concepts and showed how to apply them. One of our readers commented privately that we didn’t show how to use the techniques for prioritization. We’ll do that in this post.
Prioritizing Software Requirements With Kano Analysis
We’ve talked before about three ways to prioritize software requirements. We’ve also talked about incorporating risk analysis into ROI calculations for requirements. In this post we will look at how Kano analysis can be applied to prioritizing requirements.