The Five Kano Categories
Kano identified five categories of features, though the first three are the most commonly used in product practice. Must-be requirements, also called threshold features, are expected by users as a basic condition of the product. Their presence does not increase satisfaction, but their absence causes significant dissatisfaction. For a SaaS product, authentication, data security, and a working core workflow are must-be requirements. For an AI product, responses that do not contain obvious errors and a clear interface for submitting queries are must-be requirements. Performance requirements are linear: more is better, and less is worse in direct proportion. Load time is a classic example. Users are more satisfied when pages load in 0.5 seconds than in 1 second, and more satisfied at 1 second than at 2 seconds. For AI products, accuracy is often a performance attribute: higher accuracy produces proportionally higher satisfaction up to a threshold. Delighter features, also called excitement features, are not expected by users. When present, they produce disproportionate satisfaction. When absent, they cause no dissatisfaction because users did not know they were possible. AI features often start as delighters when a capability first becomes available to a product category, then migrate to performance or even must-be requirements as the category matures.
How to Run a Kano Survey
The Kano model includes a specific survey methodology for classifying features. For each potential feature, users are asked two questions: a functional question (how do you feel if this feature is present?) and a dysfunctional question (how do you feel if this feature is absent?). Each question has five answer options: I like it, I expect it, I am neutral, I can tolerate it, I dislike it. The combination of functional and dysfunctional answers maps to a Kano category using a classification matrix. If users say they like the feature when present and dislike it when absent, it is a performance feature. If they are neutral when present but dislike its absence, it is a must-be. If they like it when present but are neutral when absent, it is a delighter. Running this survey on 20-30 representative users provides enough data to classify features with reasonable confidence. The survey can be run before any product is built, making it valuable for MVP scope decisions when you have a list of potential features but limited development capacity.
Applying the Kano Model to AI Feature Prioritisation
For AI product teams, the Kano model provides a useful lens for several common decisions. What AI capabilities belong in the MVP versus later releases? Must-be requirements for an AI product include the ability to handle the core use case reliably, basic error handling that prevents confusing failure states, and response quality that clears the minimum threshold users need to find the feature useful. Performance requirements include accuracy, speed, and the breadth of inputs the AI can handle correctly. Delighters might include multimodal capabilities, proactive suggestions, or personalisation. Building must-be requirements to completion before investing in performance optimisation or delighter features is the right priority order. Adding delighter features while must-be requirements are incomplete creates a product that impresses in demos but frustrates in daily use, which is a common AI product failure mode. The Kano model also helps identify when a previously delightful AI feature has become a must-be: if competitors have shipped it and your target users now expect it, the satisfaction dynamics have shifted.
Kano Model for UK Regulated AI Products
For AI products in regulated UK sectors, certain features that might otherwise be considered optional become must-be requirements by regulatory obligation rather than user expectation. FCA consumer duty requirements mandate fair treatment and clear communication for financial services AI products. This makes features like AI output disclaimers, human review escalation paths, and complaints mechanisms must-be requirements regardless of user enthusiasm about them. GDPR and UK GDPR make user data access and deletion features must-be requirements even though users rarely list them as desired capabilities in surveys. EU AI Act transparency obligations for high-risk AI systems make disclosure mechanisms and audit logging must-be requirements for affected products. The Kano model is most useful when applied with awareness of these regulatory must-be requirements, because they cannot be treated as optional regardless of their Kano category from a pure user satisfaction perspective.
Kano Model vs Other Prioritisation Frameworks
The Kano model complements but does not replace other prioritisation frameworks. Value versus effort matrices assess features by the effort required to build them against the value they deliver. The Kano model adds a dimension the value-effort matrix misses: the shape of the satisfaction response. A feature with high effort and high linear value (performance attribute) may outrank a high-effort, high-delight feature (delighter) in a value-effort matrix even though the delighter produces disproportionate satisfaction when present. Jobs to Be Done (JTBD) provides a framework for understanding why users want features. Kano tells you how users will respond to those features once they have them. Used together, JTBD identifies the right problems to solve and Kano determines which solutions will generate the most satisfaction and which are simply expected. For MVP scoping, JTBD and Kano together are more powerful than either framework alone.
Using Kano at SpeedMVPs
SpeedMVPs uses Kano model thinking in discovery sprints to help clients scope their MVP correctly. The most common mistake we encounter is including performance features and delighters in an MVP scope while must-be requirements are not fully addressed. A product that has impressive AI capabilities but missing or unreliable must-be features will churn early users regardless of how exciting the delighter features are. During discovery, we work through the feature list with the Kano lens: what must be working reliably for a user to find the product usable at all, what makes it better proportionally, and what might surprise and delight users if present? This categorisation shapes the MVP scope: all must-be requirements and the highest-leverage performance requirements go into the MVP. Delighters are designated for the second iteration if validated learning from the MVP shows user demand for them. Projects from GBP 8,000, 2-3 week delivery from Hemel Hempstead.