El tamaño del backlog es inversamente proporcional a la frecuencia con la que hablamos con clientes
Una afirmación de que “el tamaño de tu backlog es inversamente proporcional a la frecuencia con la que hablas con clientes” provoca un amplio debate sobre la práctica de la gestión de producto. Muchos argumentan que los backlogs sobredimensionados suelen ser señal de una priorización débil, miedo a decir que no y de volcar cada idea en tickets, mientras que otros señalan que las conversaciones frecuentes con clientes pueden en realidad hacer crecer el backlog, pero afinan más las prioridades. Los participantes exploran estrategias como separar el feedback bruto del trabajo accionable, podar o limitar en el tiempo los tickets de forma agresiva y apoyarse en las aportaciones de ventas y soporte para centrarse en problemas reales de los clientes en lugar de en un saco de peticiones de funcionalidades.
Tamaño del backlog vs. hablar con clientes
- Muchos no están de acuerdo en que el tamaño del backlog sea inversamente proporcional al contacto con clientes.
- Algunos dicen: las conversaciones frecuentes con clientes generan más solicitudes y elementos en el backlog; el beneficio es una priorización más inteligente, no una lista más pequeña.
- Otros sostienen: los backlogs grandes suelen ser “cementerios” obsoletos de suposiciones; hablar con clientes con frecuencia expone trabajo de mayor valor y hace que los tickets antiguos sean obviamente obsoletos.
- Consenso: la relación depende mucho del contexto (startup en etapa temprana vs. producto maduro, tipo de producto, disciplina del equipo).
¿Qué debería ir en un backlog?
- Una corriente: el backlog solo debería contener trabajo accionable a un plazo razonablemente corto; las ideas a largo plazo pertenecen en documentos más ligeros o herramientas separadas.
- Otra corriente: mantener un único sistema consultable; usar etiquetas, tipos de incidencia, estados (p. ej., “parked”) y cierre automático para gestionar la escala.
- Algunos tratan explícitamente el backlog como una herramienta diplomática de “sí, lo escribimos”; otros llaman a esto disfunción cultural y subrayan que el trabajo del PM es decir “no” con claridad.
- Varios recomiendan flujos separados:
- Feedback bruto / problemas de clientes.
- Descubrimiento de producto / árboles de oportunidades.
- Tickets de entrega para el trabajo que realmente va a hacerse.
Aporte de clientes vs. solicitudes de funciones
- Tema fuerte: los clientes deberían informarte sobre problemas, no dictar la UI ni las soluciones.
- Riesgos señalados: construir de forma reactiva cada solicitud conduce a productos incoherentes, llenos de opciones.
- Recomendación: sintetizar múltiples solicitudes en problemas de raíz y diseñar soluciones mínimas y generales alineadas con la visión del producto y los objetivos de negocio.
Herramientas y procesos
- Enfoques mencionados: Jira + Product Discovery, Productboard, agregadores especializados de feedback, rastreadores públicos de incidencias de GitHub, notas personales.
- Técnicas de higiene del backlog: depuración regular, caducidad de incidencias antiguas, límites de WIP, backlogs de equipo de “solo iteraciones cortas”, dimensionamiento tipo t‑shirt o por valor/coste, marcos de priorización (p. ej., RICE, opportunity‑solution trees).
Factores organizativos y culturales
- Los backlogs grandes y poco saludables suelen estar relacionados con: organizaciones de producto débiles, rotación de PMs, miedo a decir que no y entrada descontrolada de aportes de ventas/soporte.
- Varios comentarios destacan que ventas, soporte y CS son fuentes ricas de información estructurada sobre clientes.
- Observar a usuarios reales (y a veces hacerse pasar por cuentas) se considera invaluable para UX, pero la suplantación plantea serias preocupaciones de seguridad, privacidad y cumplimiento en algunos dominios, lo que requiere una fuerte auditoría y controles.