El tamaño del backlog es inversamente proporcional a la frecuencia de las conversaciones con los clientes

• Cuanto más frecuentemente hables con los clientes, más pequeño será el backlog
• Es importante reemplazar el tiempo de planificación con conversaciones con los clientes
• Cuantos más intermediarios haya entre los desarrolladores y los clientes, menos probable es que el producto satisfaga las necesidades del cliente
• Un backlog grande implica muchas suposiciones no validadas y una baja probabilidad de generar valor para el cliente

Enfócate en diseñar los componentes técnicos más que la interfaz de usuario

• No dediques demasiado tiempo al diseño de UI; es importante lanzar rápido una UI básica y mejorarla con el feedback de los clientes
• Hay que mantener baja la deuda técnica para poder hacer con rapidez los cambios que los clientes necesitan

La forma en que la gente cree que usa una app y cómo realmente la usa son distintas

• Es importante observar cómo los clientes usan la app
• Al observar directamente el comportamiento de los usuarios, puedes obtener insights que no se pueden detectar solo con métricas cuantitativas

Implementación de account spoofing

• Es importante invertir en una función de account spoofing para entender qué pantalla está viendo realmente un cliente específico
  • Account Spoofing: función que permite al administrador usar la app como si fuera un usuario específico de producción
• Esto permite diagnosticar problemas de forma efectiva y reducir la dependencia de datos de prueba

La importancia de la primera página

• Debes ofrecer de forma concisa la información más relevante al cliente cuando entra por primera vez a la app
• Intentar meter demasiada información en la primera página aumenta la carga cognitiva del usuario

El cliente es el marketer más importante

• El NPS (Net Promoter Score) es un buen indicador de si el cliente siente una afinidad lo bastante fuerte con el producto como para recomendarlo
• Puedes gastar en publicidad, pero empezar por clientes satisfechos es una estrategia de marketing efectiva

Un MVP no tiene sentido sin mejora iterativa

• Un MVP no debe convertirse simplemente en una excusa para ofrecer una experiencia de cliente de baja calidad por presión de fechas
• El MVP ayuda a decidir si se necesitan iteraciones adicionales y, de ser así, qué aspectos deben mejorarse

Opinión de GN⁺

• Lo más importante de este texto es la relevancia de desarrollar productos que reflejen las necesidades reales de los usuarios mediante conversaciones continuas con los clientes
• Se enfatiza la importancia de un diseño de UI flexible y de los componentes técnicos que permitan reflejar rápidamente el feedback del cliente
• Muestra que ir más allá del MVP, mejorar continuamente el producto y elevar la satisfacción del cliente puede conducir al éxito a largo plazo
• Este texto comparte lecciones aprendidas en la vida de startup y ofrece insights prácticos para fundadores y desarrolladores

[GN⁺]

Opinión de Hacker News

• Opinión sobre cómo organizar funciones/mejoras

  • Según la experiencia, la estrategia de convertir todas las ideas en tickets es ineficiente. Eso termina creando un "icebox" lleno de ideas que nunca se usarán.
  • Incluso cuando se necesita una idea del icebox para un acuerdo importante, muchas veces no se recuerda que ya existía y se crea un ticket nuevo.
  • Se prefieren tickets que sean viables a corto o mediano plazo, y las demás ideas se guardan por separado.
  • El equipo de ingeniería mantiene una lista de deuda técnica que quiere resolver, y el PM mantiene una lista de posibles mejoras por proyecto.
  • Para nuevas funciones/productos se redacta un PRD, pero no se convierte de inmediato en tickets.
  • Un backlog enorme que en su mayoría nunca se procesará es una señal de un PM débil que teme decir "no".

• Relación entre el tamaño del backlog y la rotación de PMs

  • El tamaño del backlog es inversamente proporcional a la rotación de PMs.
  • Para un PM con tiempo en el puesto, el backlog funciona como ayuda memoria de conversaciones pasadas sobre el producto.
  • Un PM nuevo ve el backlog, se confunde e intenta limpiar lo que no entiende.

• Postura en contra de mantener un backlog basado en clientes

  • Los equipos que mantienen backlog, en su mayoría, lo obtienen de los clientes.
  • "Encuentra una función que mejore la vida del cliente y conviértela en la siguiente función" no es algo tan simple.
  • ¿Qué haces cuando hay varios clientes y las funciones que mejorarían la vida de cada uno no están relacionadas entre sí y además son complejas?
  • Siempre hay que escuchar las solicitudes de los clientes, pero casi nunca se debe construir exactamente lo que piden.
  • Los clientes piden funciones que implican no solo una implementación de UX, sino también el problema y el proceso de trabajo actual que están usando.
  • Hay que identificar el problema de negocio y descartar las ideas de implementación de UX y las particularidades del proceso.
  • Hay que construir, de forma económica y con buen diseño de UX y consistencia, la funcionalidad mínima que resuelva el problema de negocio.

• Necesidad del PM de registrar requisitos de clientes

  • El PM necesita un lugar para registrar los requisitos de los clientes.
  • Si no hay una herramienta dedicada, esos requisitos suelen terminar como tickets de Jira.
  • Hay dos enfoques: ProductBoard y Jira Product Discovery.
  • ProductBoard sigue un enfoque tipo CRM: registra todas las interacciones con clientes y después las descompone en requisitos y deseos.
  • Jira Product Discovery empieza con ideas y exige descomponer de inmediato todo lo que se escucha de los clientes en una larga lista de requisitos y deseos.
  • La ventaja de Jira Product Discovery es que separa la lista de ideas del backlog de desarrollo, pero igual crea otra lista larga.
  • Si se quiere analizar la priorización del producto con base en conversaciones con clientes, ProductBoard es una mejor herramienta de product discovery.

• Importancia de un backlog refinado por feedback de clientes

  • Como se conversa con clientes casi todos los días, en el backlog hay funciones y mejoras informadas y refinadas directamente por el feedback de los clientes.
  • Siempre hay mucho por hacer, pero la diferencia está en si el backlog ha sido informado y refinado por feedback de clientes o no.

• Gestión del backlog mediante conversaciones cotidianas con clientes

  • Como persona técnica, hablar todos los días con clientes suena atractivo en teoría, pero hay algunos problemas.
  • Sesgo de recencia y costo de oportunidad: hay que seguir recolectando feedback sobre espacios de problemas en los que deliberadamente no se trabaja por prioridades más altas.
  • Desarrollo reactivo: si se omite registrar el feedback, se termina enfocando el trabajo en lo más reciente y más fácil de acceder, pasando por alto problemas más antiguos.
  • Base de conocimiento del equipo: si hay una sola persona responsable de recopilar feedback y proponer soluciones, el argumento del OP puede ser válido.
  • Si el equipo está involucrado, hace falta una base de datos compartida donde se puedan registrar y consultar puntos de datos de forma asíncrona.
  • El backlog puede crecer rápido, pero tratar con sistemas y personas complejas implica dificultades.
  • Para un equipo bien organizado, hace falta una buena gestión del backlog, incluyendo almacenar trabajo no relacionado, eliminar trabajo duplicado, priorizar con regularidad y aprovechar al máximo las herramientas.
  • Gestionar el backlog es más importante que la herramienta en sí, y puede hacer falta una "fachada" sobre el backlog que haga visibles los datos importantes y permita profundizar cuando sea necesario.

• Importancia de observar a los usuarios de la app

  • Es importante observar cómo los clientes usan la app.
  • Se pueden rastrear todas las métricas, pero ver a un usuario desplazarse buscando algo, presionar el botón de volver o intentar hacer clic en algo que no se puede clicar es una experiencia muy reveladora.
  • Ojalá todas las empresas, como Apple y Google, observaran usuarios varias veces al día.

• La inutilidad de los backlogs grandes

  • Un backlog grande contiene muchas suposiciones inciertas y tiene baja probabilidad de generar valor para el cliente.
  • Muchas veces se cometió el error de asumir que algo tenía valor, cuando en realidad a nadie le importaba.
  • Un backlog grande refleja una baja frecuencia de conversaciones con clientes, por lo que debe verse con mucho escepticismo.

• Advertencia sobre implementar account spoofing

  • El account spoofing es una forma fácil de probar problemas en producción, pero los equipos de soporte y desarrollo necesitan confiar en los datos de producción.
  • En algunas industrias, esto puede representar un problema grande para el cliente.
  • En la última startup donde se trabajó, los desarrolladores no tenían ningún acceso a los datos de producción.
  • Desde el punto de vista de seguridad, esto debería considerarse como último recurso, y es mejor trabajar asumiendo que no se podrá acceder a los datos del cliente.

• Estructura en árbol de la planificación de producto

  • La planificación de producto siempre debería tener una estructura de árbol.
  • El nodo superior son los objetivos de negocio; debajo están el producto, luego los problemas del cliente y debajo los elementos del backlog.
  • Tener demasiados elementos en el backlog puede significar que no se ha definido una estructura adecuada y que no existe una lista priorizada de objetivos de negocio.
  • "Hablar con clientes" sirve para entender los problemas del cliente, pero primero hay que conocer los objetivos de negocio. De lo contrario, se pierde tiempo recolectando feedback en áreas en las que de todos modos no se va a trabajar.