Escrito originalmente en francés. Traducido por IA — se ha preservado el sentido, no la prosa.
Cuando se empieza a centralizar el feedback de clientes en una herramienta como Productboard, Harvestr, Dovetail o un sistema propio, una pregunta surge enseguida: ¿cómo clasificar bien un feedback que no habla siempre de lo mismo?
Algunos verbatims son muy concretos:
- un irritante en una pantalla;
- una solicitud sobre una feature;
- un comportamiento de producto considerado deficiente.
Otros son mucho más amplios:
- una necesidad transversal;
- un job to be done;
- una restricción de negocio;
- un reto business.
Es aquí donde suelen empezar las dificultades. El problema no es solo "ordenar mejor" el feedback. El problema es que un modelo de clasificación único no basta.
La trampa de clasificar en un solo eje
Muchos equipos clasifican su feedback según una sola lógica:
- por feature;
- por problema;
- por tema;
- por reto;
- por tipo de cliente.
El problema es que esta lógica funciona bien para una parte del feedback, pero se vuelve inestable para todo el resto.
Un enfoque centrado únicamente en las features es práctico para las fricciones locales, pero reduce demasiado rápido el feedback a fragmentos de producto. Se pierde entonces la lógica de negocio, la necesidad transversal o el objetivo business subyacente.
A la inversa, un enfoque centrado únicamente en los retos mantiene perspectiva, pero se vuelve impreciso en cuanto hay que tratar un problema concreto sobre un recorrido, una pantalla o una interacción.
En otras palabras:
- un modelo demasiado local carece de perspectiva;
- un modelo demasiado global carece de precisión.
La verdadera necesidad: cubrir todo el alcance sin complicarlo
El desafío no es añadir siempre más categorías.
Hay que encontrar un marco que sea:
- sencillo de entender;
- rápido de usar;
- suficientemente robusto;
- capaz de cubrir feedback que va desde lo muy estratégico a lo muy táctico.
Ahí está toda la dificultad.
Con pocas clasificaciones, se mezclan cosas que no están en el mismo nivel. Con demasiadas clasificaciones, el sistema se vuelve engorroso de usar, y por tanto mal adoptado.
El buen modelo no es el más "elegante" en teoría. Es el que un equipo puede usar realmente a largo plazo.
El marco que elijo: 4 clasificaciones
El modelo que elijo se apoya en 4 clasificaciones:
- Reto de negocio
- Caso de uso / JTBD
- Capacidad de producto
- Punto de fricción local
La idea es simple: clasificar un feedback según el nivel en que se expresa.
1. Reto de negocio
Hablamos de reto de negocio cuando el cliente expresa:
- un objetivo comercial;
- una restricción organizativa;
- una prioridad operativa;
- un riesgo;
- una ambición de transformación.
Ejemplos:
- armonizar las prácticas entre varios equipos;
- reducir un riesgo de conformidad;
- mejorar la gestión;
- absorber el crecimiento sin contratar más.
En este nivel, el cliente no habla todavía de una feature o un uso concreto. Habla de lo que importa para su actividad.
2. Caso de uso / JTBD
Hablamos de caso de uso / JTBD cuando el cliente describe lo que quiere lograr en su trabajo.
Estamos aquí en el nivel de la acción de negocio:
- calificar un incidente;
- hacer seguimiento de un tratamiento;
- comparar varias entidades;
- recuperar contexto antes de actuar;
- coordinar varias personas.
Este nivel es especialmente útil porque ayuda a entender el trabajo real sin cerrar demasiado pronto el análisis en una solución.
3. Capacidad de producto
Hablamos de capacidad de producto cuando el cliente expresa lo que el producto debería permitir hacer.
Por ejemplo:
- configurar alertas;
- gestionar permisos de acceso;
- consolidar un historial;
- automatizar una asignación;
- conectar varios objetos o eventos entre sí.
Ya no estamos en el nivel del objetivo de negocio, pero tampoco en el de una fricción local. Estamos en el nivel de la capacidad esperada del producto.
4. Punto de fricción local
Hablamos de punto de fricción local cuando el feedback se refiere a algo concreto del producto:
- una pantalla;
- una feature;
- un filtro;
- un botón;
- un formulario;
- un comportamiento inesperado.
Ejemplos:
- el filtro se reinicia;
- el botón de exportación es difícil de encontrar;
- hay que volver a introducir un campo;
- un formulario es demasiado largo.
Es el nivel más táctico, pero sigue siendo indispensable. Un buen sistema de insights no debe perder esta granularidad.
La regla sencilla para clasificar bien un feedback
Para evitar las dudas, sigo una regla de clasificación muy simple.
¿El cliente habla de un objetivo comercial o de una restricción organizativa? → Reto de negocio
¿Habla de lo que quiere lograr en su trabajo? → Caso de uso / JTBD
¿Habla de lo que el producto debería permitir hacer? → Capacidad de producto
¿Habla de una pantalla, una feature, un comportamiento o una fricción concreta? → Punto de fricción local
Esta regla tiene un mérito esencial: evita clasificar según el tema aparente, y empuja a clasificar según el nivel real de la señal.
Por qué este marco me parece el compromiso adecuado
Este modelo de 4 clasificaciones me parece más sólido que un enfoque centrado únicamente en las features.
¿Por qué? Porque un feedback de cliente no habla siempre de una feature. También puede hablar de:
- una necesidad transversal;
- un problema de workflow;
- una restricción organizativa;
- un reto de gestión;
- una expectativa más estratégica.
A la inversa, este marco me parece también más útil que un enfoque centrado únicamente en los retos.
¿Por qué? Porque un buen sistema de gestión de insights también debe permitir recuperar lo concreto:
- lo que bloquea en el producto;
- lo que falta;
- lo que merece una mejora local;
- lo que puede alimentar directamente discovery, diseño o backlog.
Este marco mantiene por tanto mejor el equilibrio entre altura de miras y explotabilidad operativa.
Conclusión
Clasificar todo el feedback de clientes en un solo eje no es suficiente. Funciona mientras el feedback es homogéneo. Pero en cuanto se quiere cubrir a la vez retos de negocio, casos de uso, capacidades esperadas y fricciones muy locales, el modelo se vuelve demasiado pobre.
El marco de 4 clasificaciones que elijo ofrece un mejor compromiso:
- Reto de negocio
- Caso de uso / JTBD
- Capacidad de producto
- Punto de fricción local
Sigue siendo sencillo, cubre todo el alcance útil, y puede usarse en una herramienta real sin volverse un sistema complicado.
Es este modelo el que voy a poner en práctica en mi propio proyecto de Insight Manager. El objetivo no es solo ordenar mejor los verbatims. El objetivo es conectar mejor la voz del cliente con las decisiones de producto, con un sistema suficientemente ligero para ser usado, y suficientemente estructurado para seguir siendo útil a largo plazo.
Para saber más
El PM como arquitecto del Contexto El segundo cerebro es un callejón sin salida para el product management