Convertir Feedback de Usuarios en Solicitudes de Producto Priorizadas

¡Hola! En la lección anterior diseñaste un plan de recuperación para un bloqueo de permisos detectado durante el piloto de un agente que clasifica incidencias. El error se reprodujo en una cuenta concreta; eso justifica corregir su acceso, pero no demuestra que todas las personas con bajo uso tengan el mismo problema.

Ahora toca una tarea distinta: llevar lo aprendido al equipo de Producto. Un comentario como «el agente no me ayuda» puede señalar un fallo, una dificultad de uso o una expectativa que todavía no entendemos. Aprenderás a convertir esas señales en solicitudes que Producto pueda comparar, investigar y priorizar sin confundir una opinión aislada con una necesidad general. La lección está pensada para unos 40 minutos, incluidos los recursos.

1. Antes de pedir una función, describe el problema

Quien utiliza una herramienta conoce de primera mano la dificultad que encuentra, pero no tiene por qué conocer la mejor solución técnica. Si alguien pide «un botón para saltar la revisión», la necesidad podría ser reducir tiempo; eliminar la revisión, en cambio, podría comprometer la calidad de las clasificaciones. La primera tarea de quien gestiona la adopción es averiguar qué intentaba hacer esa persona, qué ocurrió y qué consecuencia tuvo.

En este fragmento de Dan Olsen on How to Prioritize Customer Needs, Olsen distingue entre la necesidad del usuario y la solución propuesta. Después muestra una forma de pensar en oportunidades: atender tanto a la importancia de una necesidad como a lo bien que se satisface hoy. No hace falta adoptar su método de investigación completo; fíjate en las preguntas que impiden saltar demasiado pronto a una funcionalidad.

En el piloto, «U04 necesita otra sesión de formación» sería una solución prematura: se reprodujo un error de permisos al consultar una fuente. Lo observado permite restaurar el acceso correcto mediante soporte. En paralelo, plantea una pregunta para Producto: ¿la forma de habilitar cuentas permite declararlas listas antes de comprobar que pueden realizar su tarea? Aún no sabemos si hay un defecto general del producto, un fallo de configuración local o una excepción. La solicitud debe conservar esa incertidumbre.

2. Reúne señales sin mezclar hechos, interpretaciones y peticiones

El feedback llega por tickets, conversaciones, encuestas y datos de uso. La imagen siguiente representa ese trabajo de ordenación: las fuentes dispersas aparecen a la izquierda; a la derecha se distinguen solicitudes, validaciones, patrones y tendencias. Ordenar no equivale a validar: varias menciones de un mismo incidente no son necesariamente varios problemas independientes.

La guía Customer Feedback: A Guide for Product Teams, de Atlassian, propone agrupar el feedback por características comparables —como segmento, área del producto e impacto— y contrastar fuentes antes de priorizar. Lee las partes indicadas pensando en tu papel de enlace entre usuarios, soporte y Producto, no en una herramienta concreta para registrar solicitudes.

Una regla práctica es conservar tres capas en cada registro:

• Hecho o testimonio: «Al intentar consultar la fuente de incidencias con esta cuenta, apareció un error de permisos». Anota fecha, tarea, rol y fuente del dato; no incluyas datos personales ni contenido sensible de incidencias si no son necesarios.
• Interpretación: «Es posible que la comprobación de acceso durante el alta sea insuficiente». Sigue siendo una hipótesis hasta investigar otras altas y la configuración.
• Petición de investigación o cambio: «Comprobar si las cuentas pueden marcarse como habilitadas sin superar una prueba de acceso a las fuentes requeridas y, si ocurre, valorar una salvaguarda».

Esto también evita inflar la frecuencia. Tres tickets sobre el mismo intento de U04 son tres registros de soporte, pero un caso afectado confirmado. Si aparecen casos de otras personas, se agrupan bajo el mismo tema solo después de verificar que comparten el obstáculo. Mientras tanto, soporte puede resolver el incidente individual sin esperar a que Producto decida si cambia el proceso de alta.

3. Entrega a Producto una solicitud que permita decidir

Una buena solicitud no es «añadid esta función, es urgente». Explica el problema, a quién afecta, qué sabemos y qué falta por comprobar. Para la posible mejora del alta del agente, una ficha breve podría quedar así:

Tema: acceso a fuentes necesarias durante la activación.
Segmento y tarea: personal de oficina que clasifica incidencias con el agente y debe consultar una fuente autorizada.
Problema observado: en el caso ficticio de U04, la cuenta figuraba como habilitada, pero una prueba reprodujo un error de permisos al consultar la fuente. No hay evidencia de que afecte a otras cuentas.
Consecuencia: esa persona no puede completar la tarea elegible con el agente hasta que se corrija el acceso; el alcance sobre el uso del grupo sigue siendo desconocido.
Evidencia enlazada: registro de la prueba y ticket de soporte, con los datos necesarios para reproducir el fallo y sin información sensible innecesaria.
Solicitud a Producto: investigar si el flujo de alta detecta este estado y valorar una comprobación de acceso antes de declarar la cuenta lista. No se prescribe todavía una interfaz o implementación.
Validación pendiente: revisar otras altas, distinguir configuración de defecto de producto y estimar cuántas personas podrían verse afectadas.
Estado y responsable: incidente individual en soporte; investigación de la posible mejora asignada a Producto.

La ficha permite comparar solicitudes porque responde siempre a preguntas semejantes. También permite actualizarla: si la investigación muestra que fue un permiso concedido incorrectamente en un único cliente, quizá corresponda mejorar el procedimiento de altas, no modificar el software. Si revela que el producto presenta como «lista» una cuenta incapaz de ejecutar su tarea, habrá una base más sólida para una mejora.

Para problemas de IA, añade el efecto sobre el trabajo y sus salvaguardas. Una salida incorrecta que una persona puede detectar y corregir no equivale a una salida incorrecta que se incorpora automáticamente a una decisión. Un posible riesgo de privacidad, acceso indebido o daño grave necesita escalado inmediato por el circuito correspondiente: no debe esperar su turno porque obtenga pocos puntos en una clasificación de funcionalidades.

4. Prioriza por impacto y evidencia, no por volumen de mensajes

La frecuencia importa, pero no basta. Un fallo que impide completar una tarea a una sola persona puede requerir atención antes que muchas preferencias estéticas. Para comparar mejoras candidatas, Producto puede considerar alcance, gravedad, encaje con objetivos, confianza en la evidencia y esfuerzo estimado.

El marco RICE hace explícitos cuatro de esos juicios: alcance (Reach), impacto por persona (Impact), confianza en las estimaciones (Confidence) y esfuerzo (Effort). La lectura siguiente explica las escalas originales y advierte que el resultado no debe convertirse en una regla automática.

La puntuación se calcula así:

Para ver qué sí y qué no permite concluir, comparemos dos estimaciones didácticas, no datos nuevos del piloto. Ambas usan personas potencialmente afectadas por trimestre; el esfuerzo, en meses-persona. Producto y el equipo técnico tendrían que revisar esas estimaciones antes de usarlas en una decisión real.

En A, el error está demostrado para una cuenta, pero desconocemos su alcance general y el esfuerzo real de prevenirlo: de ahí la confianza limitada. En B, ni siquiera sabemos si dos personas necesitan el botón o si otra forma de reutilizar el resultado resolvería mejor la necesidad. Su siguiente paso sensato es validar el problema, no encargar el desarrollo. La cifra «2» no se convierte en evidencia por aparecer en una tabla.

A quedaría antes que B para investigación en este ejemplo, pero la puntuación no prueba que haya que construir A ni autoriza a retrasar la reparación individual de permisos. Si se detecta acceso indebido o un riesgo grave, se activa el escalado de seguridad con independencia de RICE. Si una estimación cambia al contrastarla con usuarios o con el equipo técnico, se recalcula y se deja constancia de por qué cambió.

5. Cierra el circuito con una decisión trazable

Canalizar feedback no termina al enviar una ficha. Quien gestiona la adopción debe poder informar a las personas afectadas sin prometer una funcionalidad que Producto no ha aprobado. Un circuito sencillo deja registrada una de estas decisiones: resolver en soporte, investigar, incorporar a la planificación, aplazar con motivo o descartar con motivo. La fecha de revisión y la persona responsable evitan que «pendiente» signifique «olvidado».

En el caso de U04, la comunicación inmediata es sobre el acceso: si se corrigió, si la tarea vuelve a funcionar y cómo comunicar otro fallo. La respuesta sobre el producto es distinta: «Estamos comprobando si el proceso de alta puede detectar antes este tipo de bloqueo; todavía no hay una mejora comprometida». Esa distinción protege la confianza de los usuarios y permite que Producto decida con información verificable.

Cierre

Para transformar feedback en decisiones, conserva el problema original, separa hechos de hipótesis y registra cada solicitud con segmento, tarea, consecuencia, evidencia y siguiente paso. Compara candidatas con el mismo horizonte y criterios explícitos; usa una puntuación como ayuda para razonar, nunca como sustituto de la investigación, la seguridad o el juicio sobre el valor.

En la próxima lección reunirás resultados, acciones correctivas y oportunidades de expansión en una revisión ejecutiva de 90 días. Las solicitudes de Producto bien documentadas te permitirán explicar no solo qué han pedido los usuarios, sino qué decisiones están justificadas por la evidencia.