Modelo Kano: Cómo Priorizar la Satisfacción del Cliente

El modelo Kano es el marco que separa las funcionalidades que los clientes dan por sentadas de aquellas que verdaderamente los entusiasman. Sin él, los equipos de producto y de procesos invierten presupuesto en mejoras que no mueven la aguja de satisfacción en absoluto.
¿Qué es el modelo Kano?
El modelo Kano es un marco de priorización de producto desarrollado por el profesor Noriaki Kano de la Universidad de Ciencias de Tokio en 1984. Relaciona las funcionalidades de un producto o servicio con su efecto en la satisfacción del cliente, ayudando a los equipos a decidir qué construir, mejorar o descartar.
La intuición de Kano era simple pero contraria a la lógica convencional: no todas las funcionalidades afectan la satisfacción de la misma manera. Algunas son expectativas básicas. Otras impulsan la satisfacción de forma lineal. Un tercer grupo deleita a los clientes precisamente porque no las esperaban. Su artículo de 1984, "Attractive Quality and Must-Be Quality", introdujo las categorías que los equipos de producto siguen usando hoy.
El modelo pide a los equipos que dejen de tratar todas las funcionalidades como prioridades iguales y, en cambio, clasifiquen cada una según cómo responden realmente los clientes ante su presencia o ausencia.
Datos clave
El profesor Noriaki Kano publicó el artículo fundacional "Attractive Quality and Must-Be Quality" en 1984, presentando el marco en la Universidad de Ciencias de Tokio. Sigue siendo uno de los trabajos más citados en la literatura de gestión de la calidad.
El 80% de las funcionalidades del software promedio rara vez o nunca se usan, según el informe CHAOS del Standish Group y la investigación State of Product Leadership de Pendo (2019). El modelo Kano es una de las principales herramientas que usan los equipos para eliminar este desperdicio.
El análisis Kano está integrado en los planes de estudio de ISO 9001 y Six Sigma en todo el mundo, lo que refleja su aceptación como herramienta estándar de planificación de calidad y no como un método académico de nicho.
Las 5 categorías del modelo Kano

Kano definió cinco maneras en que una funcionalidad puede relacionarse con la satisfacción del cliente. Tres son accionables para la mayoría de los equipos; las otras dos conviene conocerlas para evitarlas.
| Categoría | También llamada | Definición | Ejemplo | Qué ocurre con el tiempo |
|---|---|---|---|---|
| Must-Be | Básica, Umbral | Funcionalidades esperadas cuya ausencia genera insatisfacción, pero cuya presencia se da por sentada | Cinturones de seguridad en un auto; seguridad de inicio de sesión en una app | Se mantiene en Must-Be. Cumplirla es invisible; fallar en ella es catastrófico. |
| One-Dimensional | Rendimiento, Lineal | Cuanto más se provee, más satisfecho está el cliente; cuanto menos, más insatisfecho | Duración de batería en un teléfono; velocidad de carga en una plataforma | Se mantiene lineal. Cada mejora medible genera más satisfacción. |
| Attractive | Deleitadores, Entusiasmo | Funcionalidades inesperadas que crean deleite desproporcionado cuando están presentes, pero no causan insatisfacción cuando están ausentes | Mejora de equipaje de mano gratuita; una herramienta de borrador por IA que ningún competidor ofrece aún | Decae hacia One-Dimensional y luego hacia Must-Be a medida que los clientes comienzan a esperarla. |
| Indifferent | Neutral | Funcionalidades que al cliente no le importan, presentes o ausentes | Color de las paredes del cuarto de servidores; una configuración que nadie abre | Se mantiene Indifferent. Elimínelas o postérguelas. |
| Reverse | Negativa | Funcionalidades que algunos clientes desagradan activamente cuando están presentes | Pantallas de tutorial obligatorias; video con reproducción automática con sonido | Varía según el segmento. Identifique qué segmento objeta y para quién resulta Attractive. |
El dato estratégico más valioso de esta tabla es el patrón de decaimiento de las funcionalidades Attractive. El deleitador de hoy se convierte en la expectativa básica de mañana. Por eso empresas como Apple y Spotify lanzan algo nuevo cada ciclo: la curva del deleite siempre decae hacia Must-Be.
El gráfico del modelo Kano

El gráfico Kano representa la satisfacción del cliente en el eje vertical (de "Muy insatisfecho" en la parte inferior a "Muy satisfecho" en la parte superior) y el grado de implementación (o funcionalidad) en el eje horizontal (de "No implementado / Ausente" a la izquierda a "Totalmente implementado / Presente" a la derecha).
Tres curvas recorren este espacio:
Curva Must-Be. Comienza en la esquina inferior izquierda y se aplana hacia una satisfacción neutral a la derecha. Una implementación completa apenas la hace notar al cliente. La ausencia hace caer bruscamente la satisfacción. La curva nunca asciende al territorio del deleite.
Curva One-Dimensional. Una diagonal que va desde la esquina inferior izquierda (ausente = insatisfecho) hasta la superior derecha (totalmente presente = muy satisfecho). Es el intercambio lineal: se invierte más y se obtiene más satisfacción a cambio. Las decisiones de presupuesto para funcionalidades de Rendimiento son directas.
Curva Attractive. Comienza en territorio neutral a la izquierda (ausente, pero nadie lo espera) y sube abruptamente hacia la derecha (presente = alto deleite). La característica clave: la mitad izquierda de la curva se sitúa en la línea cero, no por debajo. No ofrecer un Deleitador no perjudica. Ofrecerlo sorprende y conquista clientes.
La categoría Indifferent aparece como una línea plana en el punto cero (neutral) a lo largo de todo el gráfico. La categoría Reverse es el espejo de One-Dimensional, que va de la esquina superior izquierda a la inferior derecha.
Leer el gráfico en conjunto indica dónde invertir. Las funcionalidades por encima de la diagonal con bajo costo de implementación son Deleitadoras y vale la pena lanzarlas rápido. Las que están por debajo de la diagonal con alto costo son Must-Bes que conviene atender con calidad mínima viable, sin sobreinvertir.
Cómo realizar un análisis Kano
Realizar un análisis Kano requiere cuatro pasos. Es más estructurado que una encuesta de clientes típica, porque a cada funcionalidad se le pregunta dos veces: una de forma positiva y otra de forma negativa.
Paso 1: Seleccionar las funcionalidades a evaluar
Elija entre 10 y 20 funcionalidades o mejoras específicas. Los ítems vagos ("mejor rendimiento") producen resultados ruidosos. Los ítems concretos ("carga de página en menos de 1 segundo") producen categorizaciones limpias. Extraiga candidatos de su backlog, tickets de soporte al cliente, listas de funcionalidades de la competencia o los debates sobre el roadmap del equipo.
Paso 2: Redactar pares de preguntas funcionales y disfuncionales
Cada funcionalidad recibe exactamente dos preguntas:
- Pregunta funcional: "¿Cómo se sentiría si esta funcionalidad estuviera presente?"
- Pregunta disfuncional: "¿Cómo se sentiría si esta funcionalidad estuviera ausente (o se eliminara)?"
Ambas preguntas usan las mismas cinco opciones de respuesta:
- Me gustaría
- Lo espero (lo doy por sentado)
- Soy neutral
- Lo toleraría
- Me disgustaría
Redacte cada par en lenguaje sencillo. Evite las dobles negaciones. Pruébelo con dos o tres colegas antes de enviarlo. Una redacción deficiente de las preguntas es la mayor fuente de datos Kano incorrectos.
Paso 3: Encuestar a los clientes y categorizar las respuestas
Recopile respuestas de una muestra representativa (de 30 a 100 encuestados es lo habitual; más para funcionalidades de alto impacto). Luego cruce las respuestas funcional y disfuncional de cada encuestado usando la Tabla de Evaluación Kano:
| Respuesta funcional | Respuesta disfuncional | Categoría |
|---|---|---|
| Me gustaría | Me disgustaría | One-Dimensional |
| Me gustaría | Neutral / Lo toleraría | Attractive |
| Me gustaría | Lo espero | Attractive |
| Lo espero | Me disgustaría | Must-Be |
| Neutral | Me disgustaría | Must-Be |
| Neutral | Neutral | Indifferent |
| Me gustaría | Me gustaría | Cuestionable (revise la pregunta) |
| Me disgustaría | Me gustaría | Reverse |
Agregue las categorías entre todos los encuestados. La categoría más frecuente para una funcionalidad es su clasificación Kano. Cuando una funcionalidad se divide casi por igual entre dos categorías, suele ser una señal de oportunidad de segmentación: diferentes tipos de clientes la valoran de manera distinta.
Paso 4: Priorizar el roadmap
Aplique esta lógica:
- Funcionalidades Must-Be no cubiertas: Resuélvalas primero. Son el mínimo esperado. Fallar aquí daña la confianza, independientemente de sus Deleitadoras.
- Funcionalidades One-Dimensional con brecha de rendimiento: Invierta proporcionalmente. Estas mueven la satisfacción directamente, por lo que el cálculo del ROI es claro.
- Funcionalidades Attractive que la competencia no ofrece: Lánzalas rápido. La ventana del deleite se cierra a medida que el mercado se normaliza.
- Funcionalidades Indifferent: Elimínelas o postérguelas. Redirige ese presupuesto hacia las anteriores.
- Funcionalidades Reverse que afectan a un segmento clave: Elimínelas o hágalas opcionales.
Combine la priorización Kano con sus marcos existentes. La priorización MoSCoW funciona bien junto a Kano: Must-Be se corresponde con "Must Have", One-Dimensional con "Should Have", Attractive con "Could Have" e Indifferent con "Won't Have".
Ejemplo del modelo Kano

Considere un producto SaaS B2B de gestión de proyectos que evalúa el roadmap del próximo trimestre. El equipo encuestó a 60 clientes sobre ocho posibles funcionalidades:
| Funcionalidad | Categoría Kano | Justificación | Prioridad |
|---|---|---|---|
| Disponibilidad superior al 99.9% | Must-Be | Los clientes lo esperan; la inactividad genera churn de inmediato | Resolver primero si existe brecha |
| Mayor velocidad de carga de tareas | One-Dimensional | Cada segundo ahorrado aumenta la satisfacción; cada segundo adicional perjudica | Invertir proporcionalmente |
| Resúmenes de reuniones generados por IA | Attractive | Ningún competidor lo ofrece; los clientes que lo probaron en beta lo amaron | Lanzar rápido |
| Vista de diagrama de Gantt | One-Dimensional | Mayor visibilidad del cronograma = más satisfacción para usuarios de gestión de proyectos | Invertir proporcionalmente |
| Más de 40 temas de color | Indifferent | La encuesta mostró 78% neutral o indiferente | Postergar |
| Single sign-on (SSO) | Must-Be | Los clientes enterprise lo requieren por cumplimiento; su ausencia bloquea ventas | Resolver primero |
| Integración con Slack | One-Dimensional | Más integraciones = mayor engagement en este segmento | Invertir proporcionalmente |
| Música de fondo ambiental | Reverse | El 35% la desagradó activamente; el 60% fue indiferente | Eliminar del roadmap |
El resultado: el equipo descartó por completo las funcionalidades de temas de color y música, marcó el SSO como innegociable para la expansión enterprise y avanzó rápido el resumen de reuniones por IA como diferenciador competitivo antes de que los rivales lo lancen.
Este tipo de evidencia estructurada reemplaza los debates basados en opiniones que ralentizan la mayoría de las revisiones de roadmap. También le da al equipo una respuesta sólida cuando los directivos preguntan por qué una funcionalidad no está en el próximo sprint.
Beneficios y limitaciones
Dónde el modelo Kano aporta valor real:
- Incorpora datos del cliente en la priorización en lugar de depender de la intuición interna
- Separa "agradable de tener" de "mínimo esperado" con claridad
- Identifica oportunidades de diferenciación competitiva antes que los rivales
- Reduce el exceso de funcionalidades al detectar categorías Indifferent
- Aplica a múltiples industrias: producto, diseño de servicios, gestión de procesos, experiencia del cliente
Donde los equipos encuentran fricción:
- El diseño de la encuesta es más difícil de lo que parece; una redacción deficiente sesga todos los resultados
- Los resultados son una fotografía del momento. Las funcionalidades decaen de Attractive a Must-Be con el tiempo, por lo que el análisis debe repetirse anualmente o tras cambios importantes de mercado
- Las muestras pequeñas producen categorizaciones poco fiables, especialmente para funcionalidades que se dividen entre categorías
- No ordena las funcionalidades dentro de la misma categoría; aún necesita una segunda herramienta (matriz esfuerzo/impacto, value proposition canvas) para secuenciarlas
- Los clientes a menudo no pueden expresar qué los deleitaría, solo lo que ya esperan
El modelo Kano funciona mejor cuando se combina con otros métodos de calidad y priorización. Los equipos que utilizan Six Sigma usan Kano en la fase de Definición para establecer los requisitos Críticos para la Calidad (CTQ). Los programas de Total Quality Management lo usan para alinear los proyectos de mejora con el valor real para el cliente. Los equipos de value stream mapping lo usan para decidir qué pasos de un proceso vale la pena optimizar y cuáles eliminar.
Preguntas frecuentes
¿Quién creó el modelo Kano y cuándo? El profesor Noriaki Kano de la Universidad de Ciencias de Tokio desarrolló el modelo. Su artículo de 1984, "Attractive Quality and Must-Be Quality", introdujo el marco en la literatura de gestión de la calidad. Kano partió de investigaciones sobre satisfacción del cliente de la década de 1970, pero su enfoque de categorización y graficación se convirtió en el estándar que los profesionales de la calidad de todo el mundo siguen hoy.
¿Cuáles son las 5 categorías del modelo Kano? Las cinco categorías son Must-Be (Básica), One-Dimensional (Rendimiento), Attractive (Deleitadores), Indifferent e Inverse. Las funcionalidades Must-Be se esperan y se dan por sentadas. Las One-Dimensional escalan la satisfacción linealmente con la inversión. Las Attractive sorprenden y deleitan. Las Indifferent no mueven la satisfacción en ningún sentido. Las Reverse son activamente desagradadas por algunos segmentos de clientes cuando están presentes.
¿Cuál es la diferencia entre una pregunta funcional y una disfuncional? Una pregunta funcional indaga cómo se sentiría un cliente si una funcionalidad estuviera presente. Una pregunta disfuncional pregunta cómo se sentiría si estuviera ausente. Ambas son necesarias para categorizar correctamente una funcionalidad. Un encuestado que responde "Me gustaría" ante la presencia y "Me disgustaría" ante la ausencia ofrece un resultado One-Dimensional. Un encuestado que responde "Me gustaría" ante la presencia pero es "neutral" ante la ausencia ofrece un resultado Attractive. El emparejamiento es lo que hace que el análisis Kano sea más preciso que una única calificación de satisfacción.
¿Las funcionalidades Attractive permanecen así para siempre? No. Este es uno de los hallazgos más importantes e infrautilizados del modelo. Las funcionalidades Attractive decaen con el tiempo. Pasan de Attractive a One-Dimensional (a medida que los clientes empiezan a esperarlas) y eventualmente a Must-Be (cuando se convierten en el mínimo esperado en el mercado). Las pantallas táctiles de los primeros smartphones eran Attractive en 2007; para 2012 ya eran Must-Be. Los resúmenes de contenido generados por IA son Attractive para muchas herramientas SaaS hoy; no lo seguirán siendo. La implicación: lance los Deleitadoras rápido y siga encuestando a los clientes para rastrear el decaimiento.
¿Cómo se compara el modelo Kano con la priorización MoSCoW? Ambos marcos ayudan a los equipos a decidir qué construir. La priorización MoSCoW clasifica las funcionalidades en Must Have, Should Have, Could Have y Won't Have, basándose en el juicio del equipo y las restricciones del proyecto. Kano clasifica las funcionalidades según los datos medidos de la respuesta del cliente. Son complementarios: Kano le dice cómo se sienten los clientes; MoSCoW le ayuda a tomar la decisión de entrega considerando el tiempo y el presupuesto. Muchos equipos de producto realizan primero el análisis Kano para informar sus decisiones MoSCoW.
El modelo Kano no le dice qué tan rápido lanzar ni cuánto gastar. Pero sí le indica qué dirección importa a los clientes, y esa es la pregunta que la mayoría de los debates sobre roadmaps nunca responde con datos reales. Comience con una encuesta pequeña, categorice los diez primeros ítems de su backlog y es probable que encuentre dos o tres funcionalidades que el equipo ha debatido y que resultan ser Indifferent para las personas que realmente usan el producto.

Senior Operations & Growth Strategist
On this page
- ¿Qué es el modelo Kano?
- Datos clave
- Las 5 categorías del modelo Kano
- El gráfico del modelo Kano
- Cómo realizar un análisis Kano
- Paso 1: Seleccionar las funcionalidades a evaluar
- Paso 2: Redactar pares de preguntas funcionales y disfuncionales
- Paso 3: Encuestar a los clientes y categorizar las respuestas
- Paso 4: Priorizar el roadmap
- Ejemplo del modelo Kano
- Beneficios y limitaciones
- Preguntas frecuentes