KANO Requirement Prioritization

Problem

When many feature requests enter review, the hard part is rarely “no ideas.” It is choosing where to invest first: which features must be solid, which only need to pass, which can create surprise, and which should be cut. This skill turns “importance of requirements” into traceable reasoning within a shared KANO framework.

How it works

It accepts requirement statements or product opportunities from JTBD, VOC, or upstream analysis. If the input is fuzzy, it first normalizes each item into a testable requirement format.

Then it classifies each requirement into:

• Must-be: absence causes strong dissatisfaction, but presence does not add delight.
• One-dimensional: user satisfaction grows with better execution.
• Attractive: unexpected value that can drive differentiation.
• Indifferent: users are mostly unaffected either way.
• Reverse: providing the feature may create dissatisfaction.

It also estimates Better and Worse coefficients and positions each requirement in a four-quadrant view. The output includes a classification table, strategy table, priority ordering, and a short set of conclusions.

Boundaries

The skill is best for qualitative reasoning and strategy, such as roadmap discussion or feature triage. Without real survey or behavior data, the Better-Worse values are expert estimates and should be labeled as such. Large-scale statistical evaluation still requires dedicated data collection.