translation of the original work, I found I was right.
Before describing the simple Kano Method, the authors spend a fair bit of time on the concept of subjective and objective quality. Using good references and a long narrative, they trace quality discussions back to 300 B.C.-really, I'm not kidding. They summarize by saying:
"Discussions of quality have revolved around the two aspects of subjectivity and objectivity since the time of Aristotle. Embedded in this objective-subjective split is the idea that objective quality pertains to the 'conformance to requirements' while subjective quality pertains to the 'satisfaction of users.'"
If you've ever released bug-free software that people hate or software with bugs that people love, you know what I'm talking about. Lately I think more about the aspects of the software that would lead me or anyone using software to believe the quality is high. Where the Kano Method attempts to give a bit of a heuristic for identifying subjective aspects of quality, it's just a simple heuristic. The main point-and mine, in this column-is to consider subjective quality on an equal level with objective quality.
Feature Polluted, Quality Starved
A product manager friend once grumbled to me about a problem he commonly has. When introducing a new feature into his product, he'll initially introduce a simple version of it. When he goes back to improve it, his stakeholders will stop him and say, "We've already done that feature! We've got all these other features to implement before we go back to that one." He'll reply, "But that feature is crap"-to which his stakeholder will say, "But, it's been tested thoroughly. It works fine."
You can see from this story that my less-than-tactful friend has a desire to improve the subjective quality of the feature, while his stakeholders are focusing on the objective quality. In addition, they're guilty of some bad behavior I often see in product management: feature pollution. And sadly in these sorts of products, while the feature count may be high and the bug count low, the subjective quality is often low as well. Customers often don't like the product, and an unenlightened product management's response often is to add more features at customers' request. This is what Alan Cooper calls a " customer-driven death spiral ."
In software development, more features is often considered better. Since we're consumed with the quantity of features, we often forget the quality of the software as a whole unit.
Use Product Report-Carding to Evaluate Subjective Quality
A while back I wrote an article about managing feature scale , but what I was talking about was the feature's subjective quality. Well, that and building stupid variations of product features that cost too much to build and don't really improve customer satisfaction.
In the process of teaching others iterative development, I explain that a feature is never really done. We can always add a bit more to it or change it to improve the feature's subjective quality. Once, when I was explaining this during a class, someone piped up and said, "We do that! And we use a letter-grade system to evaluate how good it is! We'll give our features a grade-say, a D in an early iteration. As time goes by and we add more, we'll up the grade. We shoot for an A."
Ever since hearing this disruptively simple solution, I've been creating report cards for my product. Give this a try on your product:
- In a small group, brainstorm the major features of your product.
- Independently for each feature write your "grade" for the quality of the feature. Answer the