De 25.000 comentarios a un backlog

Uso y resultados

• 25.000+comentarios (evidencias) de los últimos dos años, agrupados en 136 issues.
• 300 → 20–30issues que, al definir bien qué es un issue único, resultaron ser solo entre 20 y 30.
• 1persona, de principio a fin: producto, diseño, front-end y back-end, en unos tres meses.

Por qué lo emprendí

Antes no se gestionaba el feedback de los clientes: no se trataba de ninguna manera y no llegaba a los equipos de producto. Ese era el problema y el origen de todo. Lo primero era que los Product Owners recibieran cada semana información sobre problemas, quejas y opiniones de usuarios reales, que se pudiera traducir en acciones planificables para los equipos de My Sunrise, la app, Rewards, roaming o la eShop.

Sin datos medibles, el producto se construía por la intuición de los Product Owners. Yo tenía dos hipótesis. La primera, que un diseñador de producto puede crear algo funcional de principio a fin, y que los equipos pueden construir sus propias herramientas especializadas con poco presupuesto. La segunda, que la herramienta fuera realmente útil: que permitiera construir los backlogs de producto sobre la realidad y no sobre intuición.

Qué construí

Voice of Customer es la herramienta que muestra los problemas activos de los usuarios, para tomar decisiones y planificar el roadmap. Lo construí yo solo, de principio a fin, y lo puse en producción en Hostinger con Supabase. Los datos son opiniones públicas, porque se trataba de probar la viabilidad de la idea: la comunidad de Sunrise, Reddit, las tiendas de apps y X. No recoge ningún nombre ni dato personal: solo los issues.

El proceso, cada semana

La clave del proceso es que se repite sola cada lunes y que cada paso tiene un responsable claro: los agentes preparan, las personas deciden.

Quién lo usa y para qué

Una vez limpios y ordenados, los issues se suben a la plataforma, donde el Product Owner, el Business Analyst y el diseñador UX acceden a la información de cada uno, organizada por volumen y cantidad. El Product Owner no tiene que hacer nada más que decidir.

Decisiones clave

Decisión 01

Definir primero qué es un issue

Situación

Los comentarios mezclan opiniones sueltas con problemas reales, y un mismo mensaje puede describir varios. En la primera prueba, el sistema contaba como distintos los que eran el mismo: de 300 issues abiertos se pasó a 20 o 30 únicos.

Alternativas

Clasificar cada comentario tal cual, o dejar que el modelo decida solo qué es un problema.

Decisión y por qué

Definir qué es un issue y entrenar a los agentes, a mano y con más de 300 casos, para decidir si un mensaje lo es, cuántos describe y cuándo dos son el mismo.

Efecto

De 300 issues a 20–30 únicos, y fuera las opiniones sin un problema real.

Decisión 02

Una taxonomía de negocio y una ontología facetada

Situación

Un issue se puede mirar desde muchos puntos de vista: dónde se genera, por qué, quién lo debe resolver, cuándo. Una lista de etiquetas planas no sirve a equipos tan distintos como My Sunrise, la app, Rewards, roaming o la eShop.

Alternativas

Etiquetas libres, o un único árbol de categorías.

Decisión y por qué

Mapear la taxonomía del negocio y clasificar cada issue con una ontología de seis facetas. La última, quién lo arregla, se deriva por regla y no se clasifica nunca a mano.

Efecto

Cada equipo ve lo suyo, y cambiar al responsable de un tema no obliga a reetiquetar nada. Lo que el agente no sabe clasificar se corrige a mano.

1. 01Qué pasaEl síntoma: por ejemplo, bloqueado, no puede continuar.
2. 02Sobre quéEl producto o el hardware: por ejemplo, un modelo de móvil.
3. 03Haciendo quéLa etapa del recorrido: por ejemplo, la activación.
4. 04Dónde intentó resolverloMy Sunrise, línea de atención, chatbot o tienda.
5. 05Por qué pasaLa causa raíz, si era evitable y a quién se atribuye.
6. 06Quién lo arreglaSe deriva por regla, a partir del tema y el hardware. Nunca a mano.

Decisión 03

El agente limpia y clasifica; la persona decide

Situación

Los Product Owners decidían por intuición, sin datos reales y medibles, y el feedback no les llegaba. La tentación con IA es que también decida.

Alternativas

Que el agente también priorice y decida qué se hace.

Decisión y por qué

El agente solo limpia y clasifica; todo lo revisan agentes entrenados, con contexto de negocio y una taxonomía específica. El Product Owner decide y planifica. Lo que redacta la IA aparece marcado como sin revisar hasta que alguien lo acepta, lo edita o lo descarta.

Efecto

El Product Owner decide con información real, planifica por volumen y urgencia y crea el ticket sin salir de la herramienta.

Cómo lo probé

Lo probó el equipo de producto de la app, con un feedback muy positivo, sobre todo porque se construye a partir de necesidades reales y no de decisiones de negocio que a veces no se pueden demostrar. La primera prueba fue mal: la clasificación fallaba el 95 % de las veces. Hubo que trabajar la taxonomía y entrenar a los agentes, a mano y con más de 300 issues, para que entendieran qué es realmente un issue y lo clasificaran bien, y para que supieran qué es un issue único. Después de ese trabajo, todo se revisa con agentes entrenados.

Qué funcionó y qué no

• Funcionó: la clasificación, una vez entrenados los agentes y afinada la taxonomía. Lo más complicado fue pulir el modelo de clasificación y la priorización.
• Funcionó: la hipótesis. Un diseñador de producto puede crear algo funcional de principio a fin, con poco presupuesto, y el resultado es útil para construir backlogs con datos reales.
• Sigue sin resolver: el proyecto está en pausa por una reorganización interna, así que no ha pasado de piloto.

Qué sigue

La idea era incorporar los datos de las llamadas, que son los que más volumen generan. Para eso habría que pasar de piloto a proyecto real y transcribir las llamadas para analizarlas. También quería sumar el feedback de la investigación: cuestionarios, tests de usuario y entrevistas, que son otra fuente de feedback.