Ciclo de feedback

Modelo de Kano: prioriza según lo que sienten tus clientes

6 min de lectura

El modelo de Kano es una forma de ordenar funciones según cómo reaccionan los clientes cuando las tienen y cuando les faltan, en lugar de según cuánta gente las pidió. Lo propuso Noriaki Kano en 1984 y coloca cada función en uno de cinco grupos: obligatoria, de rendimiento, atractiva (de deleite), indiferente e inversa. Para un equipo con un montón de solicitudes de funciones, lo útil es que explica por qué una solicitud con decenas de votos puede no aportar nada a la satisfacción, mientras que una que nadie votó puede cambiar cómo se habla del producto.

CategoríaReacción del cliente si existeReacción del cliente si faltaSolicitud típica
ObligatoriaNinguna, se da por hechaFuerte insatisfacciónRestablecer contraseña, exportar datos
RendimientoLa satisfacción crece con más cantidadLa satisfacción cae con menosVelocidad, almacenamiento, límites
AtractivaDeleiteNinguna, nadie la esperabaUna automatización pensada con cuidado
IndiferenteNingunaNingunaUn ajuste que pocos tocan
InversaMolestiaAlivioUn tour forzado o un paso extra

¿Cuáles son las categorías del modelo de Kano?

Las funciones obligatorias son las que los clientes dan por hechas. Nadie las elogia y todos notan cuándo fallan. Las funciones de rendimiento son aquellas en las que más es mejor en línea recta, como informes más rápidos o límites más altos. Las funciones atractivas son inesperadas, así que su ausencia no cuesta nada y su presencia genera un entusiasmo real. Las funciones indiferentes no mueven nada en ningún sentido, y las inversas hacen más felices a algunos clientes cuando se quitan.

La categoría es una propiedad de una función para un grupo de clientes en un momento dado, por eso la misma función puede caer en grupos distintos según el segmento.

¿Cómo se hace una encuesta de Kano?

Haz dos preguntas sobre cada función. La pregunta funcional pregunta cómo se sentiría el cliente si el producto tuviera la función. La pregunta disfuncional pregunta cómo se sentiría si no la tuviera. Ambas usan las mismas cinco respuestas: me gusta, lo espero, me es indiferente, puedo vivir con ello, no me gusta.

Combina las dos respuestas con la tabla de evaluación estándar para clasificar cómo ve cada encuestado cada función:

Funcional \ DisfuncionalMe gustaLo esperoIndiferentePuedo vivir con elloNo me gusta
Me gustaQAAAO
Lo esperoRIIIM
IndiferenteRIIIM
Puedo vivir con elloRIIIM
No me gustaRRRRQ

M es obligatoria (must-be), O es de rendimiento (unidimensional), A es atractiva, I es indiferente, R es inversa y Q es una respuesta dudosa que se contradice a sí misma. Cuenta las letras entre los encuestados para cada función y toma la más frecuente como su categoría. Cuando dos categorías están cerca, informa de ambas, porque un reparto 40/38 indica que el segmento está dividido y que ninguna respuesta ganó.

¿Qué solicitudes de funciones merecen entrar en una encuesta de Kano?

Solo las que de verdad considerarías construir y no puedes ordenar por intuición. Entre cinco y quince funciones es una longitud de encuesta razonable, y cada una necesita una descripción de una frase que un cliente pueda imaginar sin una maqueta. Saca los candidatos de tu backlog rastreado después de agrupar duplicados, porque diez solicitudes de lo mismo deben llegar a la encuesta como una sola función. El paso de agrupación se explica en seguimiento de solicitudes de funciones.

Deja fuera las correcciones de errores y todo lo ya prometido por contrato. Una encuesta no puede decirte si debes arreglar un fallo.

¿A quién hay que encuestar?

A quienes ya usan el producto, separados por los segmentos que te importan. Una encuesta enviada a toda tu lista tiende a producir el promedio de varios grupos distintos, y el promedio esconde el hallazgo. Usuarios gratuitos y de pago, cuentas nuevas y veteranas, equipos pequeños y grandes suelen colocar la misma función en categorías diferentes. Mantén los resultados de cada segmento por separado y decide para qué segmento es la próxima release.

Usa a las personas que escribieron las solicitudes como audiencia inicial y añade una muestra aleatoria de usuarios activos, para que la encuesta no sea solo la minoría más vocal. Cómo redactar y enviar la petición está en cómo pedir feedback a los clientes.

¿Cómo conviertes los resultados de Kano en un orden de prioridad?

Construye en este orden: primero las carencias obligatorias, luego las funciones de rendimiento en las que vas por detrás de las alternativas con las que tus clientes te comparan, después una o dos funciones atractivas por release, y las indiferentes e inversas al final o nunca. El orden se deduce de lo que cada categoría hace a la satisfacción. Cerrar una carencia obligatoria elimina un motivo para irse, el trabajo de rendimiento eleva la satisfacción de forma constante, y una función atractiva es de donde sale la diferenciación.

Kano dice qué tipo de valor aporta una función y no dice cuánto cuesta. Combina la categoría con una estimación de esfuerzo antes de ponerla en un plan. Un método de puntuación como el de puntuación RICE cubre el lado del coste, y los dos funcionan bien juntos: Kano elige la lista corta y RICE la ordena. La decisión más amplia está en cómo priorizar solicitudes de funciones.

¿Las funciones cambian de categoría con el tiempo?

Sí, y es lo más útil que hay que recordar del modelo. Las funciones atractivas derivan hacia el rendimiento y luego hacia lo obligatorio a medida que la competencia las copia y los clientes se acostumbran. La autenticación en dos pasos fue en su día una sorpresa agradable y hoy es una expectativa en el software empresarial. El resultado de una encuesta es una instantánea, así que repítela para cualquier categoría en la que estés apostando pasado un año, o cuando un competidor lance algo parecido.

Avisa a los clientes cuando lances una función de deleite. Una función de la categoría atractiva solo deleita a quien se entera de ella, así que el anuncio forma parte de la función. Cerrar ese ciclo es el tema de cómo escribir el anuncio de una función nueva.

¿Cuáles son los límites del modelo de Kano?

Mide sentimientos declarados, no comportamiento, así que puede sobrevalorar cosas que la gente dice querer. Necesita suficientes encuestados por segmento para ver un patrón, y unas pocas decenas suelen ser el mínimo práctico. Además evalúa las funciones una por una y no dice nada de cómo interactúan. Trata el resultado como una prueba sólida para una conversación sobre la roadmap, y colócalo junto a los datos de uso y de ingresos. Para convertir la lista ordenada en un plan, mira cómo crear una roadmap de producto.

FAQ

¿Qué es el modelo de Kano en palabras sencillas? Es un método que clasifica las funciones en grupos según cómo se sienten los clientes cuando la función existe y cuando falta. Los grupos son obligatoria, de rendimiento, atractiva, indiferente e inversa, y cada uno apunta a una prioridad de construcción distinta.

¿Cuánta gente hace falta para una encuesta de Kano? No hay un número fijo, pero cada segmento que quieras leer por separado necesita suficientes respuestas para mostrar una categoría claramente mayoritaria. Unas pocas decenas por segmento es un mínimo práctico habitual, y un resultado dividido con menos respuestas debe leerse como no resuelto.

¿Es mejor el modelo de Kano que RICE? Responden a preguntas distintas. Kano clasifica el tipo de valor que una función da a los clientes, y RICE ordena el trabajo por alcance, impacto, confianza y esfuerzo. Muchos equipos usan Kano para armar la lista corta y un método de puntuación para ordenarla.

¿Con qué frecuencia conviene repetir un análisis de Kano? Cada año en productos estables, y antes si un competidor lanza una función parecida. Las funciones de deleite se convierten en expectativas con el tiempo, así que un resultado antiguo puede llevarte hacia una función que ya no diferencia.


Las afirmaciones técnicas de este artículo no se han revisado de forma independiente. Si algo está mal, avísanos y lo corregiremos.

Relacionado en changeloop: Documentación para desarrolladores, Herramientas de changelog comparadas

changeloop
El equipo que crea un changelog que cierra el círculo. Tus usuarios lo piden, tu equipo lo publica y quien lo pidió se entera.