Este post, es una traduccion del post escrito originalmente en foldingburritos.com por Daniel Zacarias
Una de las decisiones principales a la hora de agregar, demorar o sacar features del roadmap es qué elementos priorizar. Si bien un Product Owner conoce el camino del producto de comienzo a fin, en determinadas oportunidades deberá tomar decisiones drásticas dados los recursos limitados (y el impacto en el usuario) para escoger los features correctos, y si bien el equipo liderando tiene una buena idea sobre la dirección del producto, es siempre óptimo tener data que respalde nuestras decisiones.
Preguntas que siempre saldrán dentro del equipo de PM o UX son:
¿Cómo mido la satisfacción?
¿Cómo escojo que construir?
¿Cómo cruzamos el umbral de satisfacción y entramos en el área de “delight”?
Cuando sucede eso - el backlog crece y crece y no sabemos cómo avanzar - se puede echar mano a una serie de herramientas que todos tenemos en el toolbox. Hoy me centraré en una que particularmente me gusta mucho: el modelo Kano, creado por el ingeniero japonés, Noriaki Kano.
EL MODELO KANO
En 1984, el consultor Noriaki Kano, escribió un paper con ideas y técnicas que ayudan a determinar qué construir para nuestros clientes y prospectos.
Estas ideas son conocidas como el Modelo Kano y se basan en los siguientes principios:
La satisfacción de nuestros clientes en relación a los features de mi producto guarda relación con el nivel de funcionalidad que esos features entregan (que tan bien implementados están)
Los features se clasifican en 4 categorias:
Atractivo
Performance
Indiferente
Esencial
Puedes determinar cómo se siente un usuario respecto a un feature con un cuestionario
SATISFACCIÓN VS FUNCIONALIDAD
Todo comienza con nuestra meta: satisfacer al usuario. Kano aquí, propone una tabla que va desde la completa satisfacción a la completa frustración.
Satisfaction
Ahora, para satisfacer al cliente se requiere un esfuerzo de nuestra parte. Eso es lo que llamamos funcionalidad o implementación, y para nosotros significa que tan bien implementado esta el feature y cuantas horas hombres nos llevará realizarlo.
Functionality
Este vértice (funcionalidad) corre de manera horizontal.
Cuando cruzamos funcionalidad con satisfacción, armamos un eje que nos servirá de plataforma para colocar las 4 categorías de que mencionamos con anterioridad.
LAS 4 CATEGORIAS
Atractivo: Hay features que cuando se agregan, dejan una impresión positiva. Estos features los llamados atractivos, delighters o exciters. Por ejemplo, la primera vez que usamos un iPhone, no esperábamos una pantalla interactiva tan simple de usar ¡nos encanto! Lo mismo cuando usamos Google Maps o Google Docs por primera vez, amor a primera vista.
Es importante que para un feature entre aquí - en el cuadrante de atractivo- no debemos reinventar la rueda, sólo vale un “me gusto eso” para deleitar a nuestro usuario.Este feature dispara el nivel percibido de satisfacción y alegría en los usuarios. Sin embargo, así como lo implementamos, debemos saber hasta dónde llegar para no “sobre usarlo” (a falta de mejor palabra).
Performance: Algunos features funcionan con una lógica bastante simple: “mientras más le demos al usuario, más feliz estará”.
Tendemos a llamar estos features “lineales”, dada esta relación proporcional entre funcionalidad y satisfacción. Performance, también es definido como un atributo unidimensional.
Por ejemplo, al comprar un auto, un atributo de performance son los kilometros por litro de gasolina. Otros ejemplos -donde más es mejor- son la velocidad de conexión a internet, la batería de tu laptop o la capacidad de Google Drive para almacenar tus documentos.
Como se ve en el gráfico, la dinámica es simple: mientras más performance agreguemos, más contentos estarán los usuarios. Asi mismo, es importante tener en mente que mientras más performance agregamos, más recursos consumimos (horas hombre)
Indiferente: Esto features son necesarios, pero no influyen mayormente. En lo personal me generan conflicto ¿para que estan si no importan? Y si importan ¿por qué no son esenciales?
Al final, estos features caen al centro del axis y como Product Managers, no debiéramos invertir mucho tiempo en ellos.
Esencial: Otros features son simplemente “esperados” o esenciales. Si el producto no los tiene será considerado como deficiente o malo. Estos features son llamados esenciales o “básicos”
El punto con estos features es que los necesitamos, pero esto no hará a nuestro usuario más feliz. Simplemente no estarán insatisfechos.
La curva de satisfacción se comporta de la siguiente manera: Cada esfuerzo en esta área se agradece (por parte del usuario) pero nunca lo deslumbra y por ende, nunca llegamos al cuadrante positivo. La buena noticia es que una vez que cumples esta expectativa con un buen feature, puedes pasar a otras cosas.
LA CAÍDA NATURAL DE LA SATISFACCIÓN
Ahora que entendemos las categorías del modelo Kano, debemos agregar otro elemento: las categorías no son estáticas, cambian con el tiempo.
Lo que le gusta a nuestros usuarios hoy, no necesariamente será lo que les gusta mañana. Con el paso del tiempo, features atractivos con el paso del tiempo, se transforman en performance y luego en escenciales.
Si volvemos a pensar en el ejemplo de iPhone o Google Maps, la sorpresa que nos dieron hace 10 años no es la misma que nos producen ahora. Lo que nos produce placer en el pasado, es hoy un feature que “damos por hecho”. Sólo lo notamos si ya no está.
El desencanto se da por diversas razones, incluyendo la evolución de la tecnología, la aparición de nuevos competidores o el hecho de que probablemente todos incluyen los mismos features.
Es importante cerrar este punto comprendiendo que el modelo nos da una imagen del ahora , sin embargo no sabemos a ciencia cierta dónde ni cómo evolucionará el producto.
LAS PREGUNTAS QUE REVELAN PERCEPCIONES DEL CLIENTE
Hasta ahora, hemos cubierto los dos primeros elementos del modelo Kano: las dimensiones del análisis y cómo estas se conectan con las categorías de los features.
A fin de descubrir las percepciones del cliente en relación a los features, debemos realizar un cuestionario. El cuestionario se compone de dos preguntas:
La primera le pregunta al usuario cómo se sienten si tiene acceso al feature
La segunda, pregunta cómo se sienten si no tiene acceso al feature
A la primera pregunta le decimos “funcional” y a la segunda “disfuncional” (o si le preguntamos a Jan Moorman, positivo o negativo). Estas no son preguntas abiertas, debemos enmarcarlas con opiniones claras y concretas:
Me gusta
Lo espero
Soy neutral
Puedo aguantarlo
No me gusta
Una vez que le hemos preguntado a nuestros usuarios esto y hemos registrado las respuestas, es hora de categorizarlas.
TABLA DE EVALUACIÓN
Una de las cosas que me gustan del modelo Kano es que se encarga de la relevancia de tener o no, ciertas funcionalidades. Esto demuestra hasta qué punto el usuario quiere, necesita o no le importa un feature.
Hacemos esto usando una tabla, resumiendo las respuestas a las preguntas en columnas y celdas que resumen las respuestas funcionales y disfuncionales. Cada set de respuestas ingresa a una de las categorías previamente indicadas y otro set de categorías que ahora cubriremos.
DOS NUEVAS CATEGORÍAS
Dado el hecho que estamos preguntando lo mismo desde distintos ángulos, podremos darnos cuenta si:
Alguien no ha entendido completamente las preguntas que le hemos hecho
Lo que hemos propuesto, es exactamente lo opuesto a lo que el usuario quiere
Estas no son categorías Kano, son sólo artefactos de nuestro cuestionario (sin embargo, muy útiles)
Si alguien dice que “no le gusta” un feature esencial y “le gusta” un feature disfuncional, podemos pensar que el usuario no tiene real interes en lo que estamos construyendo (o quizás quiere lo opuesto). A esta nueva categoría le decimos “reverse”. Si la mayoria de tus usuarios te dicen que uno de los features propuestos son “reverse”, puedes cambiar la pregunta de funcional a disfuncional y evaluar los resultados bajo esa premisa.
Cuando encuentras conflicto en las respuestas a preguntas funcionales y disfuncionales (me gusta y me gusta) a ambas preguntas, tienes una respuesta “cuestionable”. Para esto, Freud Pouliot sugirió que las celdas 2,2 y 4,4 de la tabla de evaluación Kano sean cambiadas a la categoría de “cuestionable”, lo cual quiere decir que hay algo mal con lo que estas preguntando.
UNA (LIGERA) MODIFICACIÓN A LA TABLA
Debemos intentar interiorizar cómo cada categoría deriva de un par de respuestas, para entender mejor el modelo y evitar referenciar la tabla cada vez.
Ya hemos cubierto como las preguntas “cuestionables” forman una diagonal en la tabla de evaluación, exceptuando la celda del centro (“no me importa” o don't care).
Los features de performance son los más lógicos para ubicar. Esos son aquellos que el usuario le gusta tener y le molesta no tener. Esta reacción extrema se traduce en una relación lineal donde “más es mejor” entre ambas dimensiones.
Los features esenciales son los casos que van quedando cuando un usuario se molesta por no tener esos features. Los usuarios van de “tolerar” a “esperar tener” un feature.
Los features atractivos aparecen cuando un usuario disfruta tener un feature que no esperaba. Esta es otra manera de decir que lo que estamos proponiendo es a la vez nuevo y atractivo.
Luego tenemos features que llamamos “indiferentes”. Estos aparecen cuando el usuario dice ser neutral cuando responde a las preguntas funcionales o disfuncionales. Aquí, las respuestas caen en las celdas del medio (no pertenecen a las categorías mencionadas anteriormente).
Finalmente, tenemos preguntas “reverse” posicionadas a lo largo de ambos ejes cuando las respuestas son “le gusta no tener el feature” o “le molesta tener el feature”. Puedes ver qué categoría cae dentro de reverse, cuando inviertes los valores funcional / disfuncional. Ahora podrás saber si este reverse es de performance, escencial o atractivo.
USANDO EL MODELO KANO
Ahora que entendemos como funciona el modelo Kano, veamos qué significa aplicarlo con muchos usuarios y features.
Nuestro objetivo como product manager y UX es determinar cuales features nos acercan a generar usuarios más felices. Cuando tengamos esa información, debemos priorizar que construir. Estos detalles son claves ahora que hemos llegado hasta aquí.
Esta sección se basa en el feedback de múltiples profesionales e investigadores que usan el modelo hace años, sus experiencias y aprendizajes.
Escogiendo los features y usuarios para el análisis
Obteniendo la mejor data de los usuarios
ANALIZANDO LOS RESULTADOS
PASO 1: ESCOGE TUS USUARIOS Y FEATURES
Lo primero es escoger el alcance de tu analisis, en terminos de usuarios y features.
ESCOGIENDO LOS FEATURES
Los features que escoges estudiar debieran ser aquellos que el usuario considere beneficiosos. Tu backlog podría contener un número de ítemes que pudieses incluir “ botón de pago”, “sistema de reporte” o un “update de UX”. Todos han de quedar fuera del análisis Kano.
Aquí estamos midiendo satisfacción del usuario entre features externos, sin embargo los productos son mucho más que eso. Si necesitas data para apoyar o no avanzar un feature solicitado por tus stakeholders, el modelo Kano no aplica.
Así mismo, intenta limitar el número de features en tu encuesta para que los usuarios mantengan la atención y compromiso.
ESCOGIENDO A TUS USUARIOS
Cuando escoges a tus usuarios (o prospectos) para participar de tu estudio, debes considerar elementos demográficos o la “persona” a la cual pertenecen. De lo contrario tu data estará diseminada por todo el mapa.
Tus usuarios/prospectos probablemente no son homogéneos y lo que piensan de tus features tampoco lo será. Pero si los agrupas en patrones o elementos en común, puedes disminuir el ruido de tu análisis.
Jan Moorman detectó la importancia de agrupar a sus usuarios cuando comenzó a presentar features para un nuevo producto a un grupo de usuarios potenciales. Un feature “core” del producto ya estaba presente y “se supone” que los usuarios ya lo conocían debido a que estaba entre los features que ofrecían los competidores. Sin embargo, un subgrupo de los usuarios consideraban el feature como “Atractivo” mientras que otro grupo lo consideraba “esencial”. Jan se dio cuenta más tarde que las percepciones de los usuarios cambiaban debido a su conocimiento del mercado. Cuando procedió a segmentar a los usuarios bajo ese perfil (early adopters o non adopters) los resultados de cada feature fueron mucho más claros.
Hay muchas formas de segmentar usuarios y es ahí donde debes escoger la que hace sentido para tus usuarios. Si estás trabajando en un SaaS para B2B y estás considerando un feature que permite asociar invoices con órdenes de compra, el atractivo para una startup es diametralmente distinto a lo que una multinacional pudiese buscar.
Debieses mantener esto en mente cuando seleccionas los usuarios para tu estudio (porque conoces los features que tu audiencia quiere) o para después, cuando analices los resultados de la encuesta.
PASO 2: OBTENIENDO (LA MEJOR) DATA DE TUS USUARIOS.
El cuestionario y la forma en que presentas los resultados es el único input del estudio Kano. Por ende, debieses asegurar que esta área sea tan efectiva como sea posible.
ESCRIBE PREGUNTAS CLARAS
Es crítico que hagas tus preguntas tan claras y precisas como sea posible. Cada pregunta debe cubrir un feature en si misma. Si el feature es muy complejo y requiere múltiples pasos y subprocesos, entonces debieses dividir la pregunta en sub-preguntas.
Tus preguntas deben ser hechas en términos de beneficios para el usuario, no en términos de lo que el producto hará. Por ejemplo, preguntar “si puedes mejorar el aspecto de una imagen automáticamente ¿como te sentirias?” es mucho mejor que decir “si tuvieses MagicFix ¿como te sentirias?”
Ten cuidado con preguntas que sea muy polarizadas. Me refiero a si la pregunta disfuncional no es necesariamente opuesta a la pregunta funcional. Solo representa la ausencia de la función. Aquí un ejemplo de una app para editar vídeos, considerando el tiempo que le toma optimizar el render.
Pregunta funcional:
“Si exportar cualquier video te llevase menos de 10 segundos ¿como te sentirias?”
Pregunta funcional incorrecta:
“Si exportar cualquier video te llevase más de 10 segundos ¿como te sentirias?”
Pregunta disfuncional:
“Si exportar algunos videos te llevase más de 10 segundos ¿como te sentirias?”
Mejor que escribir de los features es poder mostrar lo que hacen.
Cada vez que sea posible, intenta mostrar el feature en acción y luego pregúntale al usuarios cómo se sentiría si lo tuviese o no.
Podemos describir los beneficios de un feature y luego mostrar un prototipo e interactuar con los wireframes en vez de describirlos con una pregunta. Al tener una “explicación” visual, ayudamos al usuario a tener una comprensión más acabada de lo que le estamos proponiendo.
Si decides incluir la pregunta en el cuestionario, debieses utilizar respuestas estándar inmediatamente después que el usuario interactúe con el prototipo del feature. Tal y como si fuese un texto descriptivo. Esto ayudará al usuario a tener una imagen viva del feature y no confundirse con otros features que podrías presentarle durante la misma sesión.
Presta atención a la manera de enunciar las respuestas y el nivel de comprensión de tu usuario.
Algunas personas se sienten confundidas por el orden de las respuestas en el cuestionario Kano.
Por lo general, no entienden porque “me gusta como esta” aparezca antes de “es algo esencial”, ya que -para ellos- es un enunciado con menos fuerza.
La lógica para presentar las respuestas de esta manera es un rango que va desde el “placer” a evitar “la molestia”. A continuación se sugieren alternativas para tus usuarios:
Me gusta como esta
Es algo esencial. Cuento con ellos
Soy neutral
No me gusta, pero lo puedo tolerar
No me gusta y no lo acepto
O esta alternativa, del equipo de Robert Blauth
Esto seria muy util
Este es un requisito básico
Esto no me afecta
Esto presenta un inconveniente menor
Esto es un gran problema
El aprendizaje aquí es que debemos prestar atención al rango de opciones que presentamos al usuario y dejarle en claro cuál es nuestra meta con el cuestionario. Es siempre recomendable por tanto, seleccionar cuidadosamente los rangos de respuestas para que las preguntas no sean confusas y pasar al menos 5 minutos con el usuario antes de hacer el cuestionario para clarificar cualquier tipo de duda.
PREGÚNTALE AL USUARIO SOBRE LA IMPORTANCIA DE UN FEATURE.
Un importante elemento de la metodología Kano, es incluir una pregunta más después de funcional/disfuncional. Esta pregunta se centra en cuán importante un feature es para el usuario.
Tener esta información es de vital importancia a la hora de priorizar features y saber como abordar el roadmap. Esta pregunta busca entender qué features harán que tu usuario escoja tu producto por sobre la competencia.
La forma de enunciar la pregunta podría ser “¿Que tan importa es o sería si tuvieses <feature>? Por ejemplo: ¿Qué tan importante sería si pudieses exportar todos tus videos en menos de 10 segundos?
Las respuestas deben tener una escala que vaya de 1 a 9. De no importante a extremadamente importante.
PON A PRUEBA TU CUESTIONARIO
De ser posible, práctica el cuestionario con algunos de tus colegas antes de presentarlo a tus usuarios. De haber cualquier tipo de confusión interna, es altamente probable que el usuario no entenderá lo que estamos tratando de comunicar.
PASO 3: ANALIZA LOS RESULTADOS.
Ahora hemos llegado finalmente al paso que originó nuestro estudio.Luego de tabular y procesar los resultados debiéramos estar en condiciones de ordenar los features de acuerdo a su prioridad.
Hay dos tipos de nivel de análisis al que podemos echar mano: discreto y continuo. Estos términos son arbitrarios y buscan estandarizar el proceso. Ambos hacen referencia a conceptos matemáticos y guardan relación con la manera de mapear las respuestas de los participantes del estudio Kano.
Cada enfoque es útil, dependiendo del tipo de insights que buscas obtener.
ANALISIS DISCRETO
La manera más sencilla de trabajar los resultados del modelo Kano es:
Dividimos a los encuestados por grupo demográfico / tipo de persona que los define.
Categorizamos las respuestas de cada “persona” usando la tabla de evaluación
Ordenamos el total de respuestas en cada categoría, dependiendo del feature (y el grupo demográfico)
Cada categoría de feature tendrá la respuesta con mas votos
En caso de que dos features tengan el mismo puntaje, usa la siguiente escala: Esencial > Performance > Atractivo > Indiferente
Si le has solicitado a los usuarios que hagan un ranking de lo que les importa a ellos (deberías hacerlo) haz un promedio por cada feature.
Debieses terminar con also asi:
Si ves múltiples resultados sin una categoría clara, podrían haber perfiles de usuarios ocultos que no estas tomando en cuenta. En este caso, deberías volver a consultar las respuestas de los usuarios y buscar patrones. Trata de buscar similitudes para armar grupos demográficos que quizás no habías detectado.
De los resultados en la tabla, puedes ubicar los features de acuerdo a su importancia. Tras eso, la regla general es la de priorizar todos los features esenciales, luego agregar tantos features de performance como sea posible y finalmente, incluir los features de atractivo.
Este tipo de análisis es idóneo para tener una primera capa de compresión y es útil en muchos contextos donde no se necesita un enfoque más riguroso (ejemplo, a fin de probar ideas de diseño o hacer un draft de tu roadmap)
ANALISIS CONTINUO
Aunque el análisis discreto es idóneo para que comencemos y tengamos una idea general de los resultados, el enfoque tiene varios problemas:
Perdemos mucha información en el camino. Primero, pasamos de 25 combinaciones de respuestas por persona a una de seis categorías. Luego, las respuestas de todos los usuarios siguen siendo reducidas a una sola categoría por feature.
No logramos entender cómo la data va cambiando
Respuestas cualitativas tienen el mismo peso que respuestas cuantitativas. Piensa en un “Atractivo” con un disfuncional de “lo espero” vs “puedo aceptarlo”
CALIFICANDO LAS RESPUESTAS
Primero que todo, cada respuesta es llevada a un valor numérico dentro de la escala de potencial de satisfacción, la cual va de -2 a 4. Mientras mayor el número, mayor la forma en que la respuesta refleja cuanto desea un usuario el feature. La importancia también puede evaluarse entre 1 y 9.
Funcional: -2 (no me gusta), -1 (lo tolero), 0 (neutral), 2 (esencial), 4 (me gusta)
Disfuncional: -2(me gusta), -1 (esencial), 0 (neutral), 1 (lo tolero), 2 (no me gusta)
Importancia: 1 (no importante para nada),....., 9 (extremadamente importante)
Quizás podrías pensar que la escala disfuncional podría ser atípica y confusa. Pues no. Un resultado alto (positivo) significa un nivel de satisfacción mayor. En el caso de las respuestas disfuncionales, que al usuario no le guste algo, significa que el usuario no le gusta que el producto NO tenga cierto feature. Por ende, su satisfacción será mayor si el feature está presente; es por eso que el resultado sera alto.
La razón para la escala asimétrica (comenzando en -2 en vez de -4) es que las categorías que obtienes de las respuestas en la escala negativa (Reverso y Cuestionable) son más débiles de las respuestas que obtienes en el espectro positivo (esencial y performance). Ademas, DuMouchel decidió enfatizar este lado de la escala.
Estos resultados llevaron a la categorización de nuestros features en un plano bi-dimensional.
Con este método, no hay necesidad para seguir usando la tabla de evaluación estándar.
Nuestro foco debiera estar en el cuadrante positivo. Fuera de él, encontramos respuestas más débiles, así como categorizaciones como Cuestionable y Revertido. Si un feature termina como Revertido, siempre puedes utilizar el truco de definirlo como lo opuesto e - intercambiando el score funcional y disfuncional - el feature quedara en otra categoría Kano; es válido igualmente sacar aquellas respuestas del estudio.
UN APUNTE: COEFICIENTES DE SATISFACCIÓN Y DISGUSTO
Si te pones a revisar bibliografía de Kano, probablemente encontrarás referencias a Satisfacción y Disgusto. Con la metodologia DuMouchel, tenemos una mejor alternativa. Pero dada todas las veces a las que se le hace mención, al menos haremos una breve introducción.
Mike Timko propone usar los rangos “Mejor” y “Peor” los cuales reflejan, en términos numéricos, como cambiaría la satisfacción o disgusto del usuario en caso que un feature esté presente o no. Si bien no usa esos nombres para describirlos en el documento original (satisfaccion y disgusto), asi se les conoce. Al considerar el número total de respuestas en cada categoría, se calculan usando la siguiente fórmula:
Aunque producen un resultado numérico y son útiles para hacer comparaciones, estos coeficientes tienen múltiples problemas a las que Timko hacía referencia en su artículo. El punto es que el análisis tiene el mismo problema que presenta el análisis discreto: estos números son resultado de usar solo una categoría Kano para cada respuesta. Esta falta de información lleva a cambios más altos de lo debido con la data y les da a todas las respuestas la misma relevancia, sin importar que tanta importancia tienen para el usuario.
Los resultados Funcionales y Disfuncionales que estamos calculando usando el método DuMuchel, apuntan en la misma dirección, pero no presentan los mismos problemas, por eso les estamos dando más importancia.
CATEGORIZANDO LOS FEATURES
Si tuviésemos números para cada posible respuesta, significa que podremos trabajar con promedios. Aqui esta lo que debemos calcular para cada feature.
El promedio de todas las respuestas para los valores para las categorías “Funcional”, “Disfuncional” e “Importancia”
La Standard Deviation para los resultados “Funcional”, “Disfuncional” e “Importancia”
Cuando tomamos los resultados de los features Funcional y Disfuncional, podemos colocarlos en el cuadrante que presentamos al comienzo, de la siguiente manera:
Estamos por supuesto, tomando promedios y lo que ocultan, es la posibilidad de grandes cambios en nuestra data. Por eso es necesario agregar la Standard Deviation a nuestro gráfico en la forma de “barra de error”, para que tengamos la noción de que tan cerca o lejos de target están nuestras categorizaciones. Algo que se vea asi:
La capa final para agregar es el score de Importancia. Podemos visualizar esta dimensión adicional convirtiendo los puntos de referencia en burbujas, con tamaños proporcionales respecto a su importancia. De esta manera, podemos comparar con mucha facilidad features con un posicionamiento similar.
La prioritization general presentada en la seccion de analisis discreto aún mantiene el mismo rango: Esencial > Performance > Atractivo > Indiferente. Esto se traslada de muy buena forma de manera visual:
Para pequeñas muestras, otra forma (y quizás mejor) de visualizar es a través de una lista ranqueada. Usa tres columnas para calificar los features, usando este orden (de mayor a menor): potencial para “dissatisfaction”, potencial para “satisfacción” e “importancia”. En nuestro caso, las primeras dos columnas son los resultados Disfuncional y Funcional respectivamente.
Aqui como se veria.
Nota los ultimos dos renglones. ¿Que harias en esta situación? Tienes un feature que es indiferente (pero de hecho, muy cerca de esencial), con un gran impacto en disatisfaccion que el otro. El otro aumenta tremendamente la satisfacción y se presenta como algo esencial para los usuarios. Hay casos que deben priorizarse antes que otros. Como puedes ver, siguiendo el orden de un ranking ciegamente no resuelve cada dilema que enfrentamos; aun necesitamos tomar decisiones duras, experimentar, medir e iterar de ser necesario.
Si has llegado hasta aquí, espero que esto te haya hecho sentido y aclarado dudas. Pronto publicare la forma practica de poner el modelo Kano en practica.
