Blog
Por qué se siguen cuestionando tus decisiones sobre el producto

Un equipo de producto pasa dos semanas evaluando si desarrollar una aplicación móvil nativa o una aplicación web progresiva (PWA). Investigan las opciones, consultan a ingeniería sobre la viabilidad, analizan los datos de los usuarios y deciden adoptar el enfoque de PWA basándose en un conjunto específico de limitaciones. La decisión se discute en varios hilos de Slack, se debate en una reunión y se confirma en un mensaje de seguimiento. Comienza la implementación.
Tres meses después, se incorpora un nuevo vicepresidente. Pregunta: "¿Por qué estamos haciendo una PWA en lugar de una aplicación nativa?" Nadie puede presentar el razonamiento rápidamente. Los hilos de Slack se han desplazado y perdido de vista. La reunión no se grabó. El mensaje de seguimiento está enterrado en un canal con miles de mensajes. Así que la discusión comienza de nuevo. Se presentan los mismos argumentos. Se realiza el mismo análisis. Se llega a la misma conclusión, dos semanas después, habiendo consumido tiempo de las mismas personas (menos las que se han ido) más el nuevo vicepresidente que provocó la reapertura.
Este patrón de re-litigio es una de las ineficiencias más comunes y costosas en las organizaciones de producto. Hace perder tiempo, frustra al equipo y retrasa el trabajo que depende de que la decisión se mantenga firme.
Por qué ocurre
Las decisiones suelen ser buenas. El razonamiento suele ser sólido. El problema es que el razonamiento no se conservó de una forma que sea localizable cuando la pregunta vuelve a surgir.
Las decisiones de producto se toman normalmente mediante una combinación de discusiones en Slack, reuniones y conversaciones informales. Cada canal captura una parte del razonamiento, y ninguno de ellos preserva la imagen completa de una forma persistente y en la que se puedan realizar búsquedas. La decisión queda distribuida en tres hilos de Slack, dos reuniones y un documento de Google que se compartió pero que nunca se archivó en ningún sitio accesible.
Cuando alguien pregunta "¿por qué decidimos esto?", el equipo no puede dar la respuesta rápidamente porque armarla requiere buscar en múltiples canales, reconstruir la cronología y recordar qué discusión tuvo lugar y dónde. La fricción para encontrar el razonamiento es lo suficientemente alta como para que a menudo sea más fácil volver a discutir que investigar.
Los registros de decisiones como solución
Un registro de decisiones que capture cada decisión de producto significativa con su razonamiento, alternativas y limitaciones evita el re-litigio al hacer que la respuesta sea localizable al instante.
El formato es sencillo: cuál era la pregunta, qué opciones se consideraron, qué se decidió, por qué y qué tendría que cambiar para que la decisión se volviera a examinar. Cuando el nuevo vicepresidente pregunta "¿por qué una PWA en lugar de una nativa?", el equipo le remite al registro de decisiones. El vicepresidente lee el razonamiento, entiende las limitaciones y, o bien acepta la decisión, o bien plantea una nueva consideración que el equipo original no tenía. De cualquier manera, la discusión que habría consumido dos semanas se reduce a una lectura de quince minutos.
El reto consiste en crear registros de decisiones de forma constante, que es donde la documentación autoescrita resulta de gran valor. Cuando el sistema captura el hilo de Slack donde se debatió la decisión de la PWA y la reunión donde se confirmó, y genera un registro de decisiones estructurado a partir de esas fuentes, el registro se crea sin que nadie tenga que escribir un documento aparte. La decisión se tomó dentro del flujo de trabajo normal del equipo. La documentación se generó a partir de ese flujo de trabajo.
El beneficio compuesto
Los registros de decisiones se vuelven más valiosos a medida que se acumulan. Al cabo de seis meses, el equipo dispone de un archivo de decisiones y de sus razonamientos en el que se pueden realizar búsquedas. Después de un año, disponen de un registro completo de cómo evolucionó el producto y por qué. Los nuevos miembros del equipo pueden leer el historial de decisiones para comprender no solo qué es el producto, sino cómo ha llegado a ser así, que es el contexto que les impide proponer cambios que vuelvan a abrir temas ya resueltos.
El registro de decisiones también mejora la calidad de la toma de decisiones con el tiempo, porque crea una responsabilidad sobre el razonamiento. Una decisión que está documentada con su justificación puede evaluarse retrospectivamente: ¿era sólido el razonamiento? ¿Eran correctas las limitaciones? ¿Tomaríamos la misma decisión hoy? Este tipo de práctica reflexiva es imposible cuando las decisiones y sus razonamientos se pierden a las pocas semanas de haberse tomado.
Preguntas frecuentes
¿Qué se considera una decisión "significativa" que merece la pena registrar? Cualquier decisión que afecte a la dirección del producto, la arquitectura, la priorización o el alcance, y sobre la que preveas que alguien preguntará más adelante. Si es probable que un nuevo miembro del equipo pregunte "¿por qué se hace de esta manera?", el razonamiento debe documentarse. Las decisiones de implementación del día a día no necesitan registros.
¿No ralentiza esto la toma de decisiones? Cuando los registros de decisiones se generan automáticamente a partir de las discusiones existentes, no hay un coste de tiempo adicional. El equipo toma las decisiones de la misma manera que siempre lo ha hecho (Slack, reuniones, documentos). El registro se realiza de manera secundaria.
¿Qué ocurre con las decisiones que deben volver a examinarse porque las circunstancias han cambiado? El registro de la decisión debe incluir "qué tendría que cambiar para que esto se vuelva a examinar". Cuando se cumplen esas condiciones, es oportuno reabrir la decisión y el registro proporciona el punto de partida. Esto es diferente de volver a litigar, que consiste en reabrir una decisión sin información nueva.
Lecturas relacionadas: Cómo crear una base de conocimientos de producto, Tu código está documentado pero tus decisiones no, Deuda de documentación. Páginas relacionadas: Registro de decisiones, Documentos autoescritos, Para gestores de producto.
Otras entradas de blog:

The Creative's Cold Start Problem

How to Stop Losing Momentum Between Study Sessions

Your Future Self Can't Read Your Mind

The Hemingway Bridge: Stop Working So You Can Start Again

Your ERP Has the Answers. Nobody Can Find Them.

The Usability Layer Your Business Systems Are Missing

Notas manuscritas vs. digitales: No deberías tener que elegir

Por qué tus notas a mano no se pueden buscar (y qué hacer al respecto)