Estimating the “value” of features is a waste of time. I was in a JAD session once where people argued about if the annoying beeping (audible on the conference line) was a smoke alarm or a fire alarm. Yes, you can get to an answer, but so what?! The important thing is to solve the problem.
Tag Archives: Kano analysis
Kano Analysis for Product Managers
Kano Analysis, while initially created to understand customer satisfaction with features, can be used by product managers to better understand customer problems. I gave a presentation last week for the Product Management View webinar series on Kano Analysis for product managers.
Read the rest of the article …
Dell Cell Phone Lacks Differentiation
No cell for Dell. According to Kaufman Bros. analyst Shaw Wu, carriers rejected prototypes from Dell because the “lack of differentiation.” As product managers, we know the importance of keeping up with the Joneses, but we also know the importance of including differentiated value in our product offerings.
Read the rest of the article …
Posted in Prioritization, Product Management, Requirements
Tagged cell phone, dell cell phone, dell phone, dell smart phone, kano, Kano analysis
11 Comments
Viral Product Management
*
Our previous article looked at the economics of a Freemium business model. One element that is key to making a strategy that involves “free” work financially is growing your user base. One way to get that growth is through a word-of-mouth marketing campaign. This article looks at different elements that characterize or affect the successfulness of a viral product – from a product management perspective.
Why Prioritization Matters
I am a big fan of boxes and arrows, but this time, Jeffrey Davidson found a great article by Dan Willis before I did, and told me about it. Thanks Jeffrey! The article is about how to deal with the what and how of requirements and design – and it provides some really sage advice. But what got my attention was the lack of prioritization of requirements in his example.
Differentiate Your Product – Circumvent Comparisons
Look Ma! Me Too! The temptation to compete against a checklist can be overwhelming. When we have a competitor who provides 100 of this or 200 of that, it might seem smart to offer 200 of this and 300 of that. We’ll be better off if we focus instead on creating the other thing. The best way to compete is to valuably differentiate our product, not outdo our competition.
More is better features are just that – more is better. But more of the same old thing is worth a whole lot less than some of something else.
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.
Posted in Prioritization, Product Management, Requirements
Tagged differentiated innovation, innovation, innovative requirements, kano, Kano analysis, managing data, prioritizing features, prioritizing requirements, requirements prioritization, software feature priority, software prioritization
4 Comments
Latest Articles
Comments on all Articles
