Escrito originalmente en francés. Traducido por IA — se ha preservado el sentido, no la prosa.
Ciertas decisiones de producto aparecen en todos lados.
Aparecen en el comité de roadmap. Aparecen con los comerciales. Aparecen en soporte. Aparecen en las especificaciones. Aparecen en los tickets. Aparecen con cada nuevo gran cliente, con cada nueva oportunidad, con cada caso límite un poco visible.
¿Hay que priorizar al cliente o al proveedor en un marketplace?
¿Hay que traducir el producto a todos los idiomas que piden los prospects?
¿Hay que aceptar una excepción para un segmento que podría generar mucho?
¿Hay que abrir un alcance si el producto aún no puede asumirlo correctamente?
Estas preguntas no son features. No son tickets. No son detalles de ejecución. Son decisiones estructurantes.
Y cuando no están claramente documentadas, la empresa las retoma sin parar.
A veces con las mismas personas. A veces con otras. A veces con menos contexto. A veces bajo presión comercial. A veces con urgencia. A veces con una memoria parcial de lo que ya se había arbitrado.
El problema no es solo la pérdida de tiempo. El problema es la pérdida de coherencia.
Una decisión de producto importante no puede depender de la memoria oral de quienes estaban en la reunión.
Ese es precisamente el rol de un Product Decision Record.
La inspiración: los ADR en el lado técnico
Los equipos técnicos ya conocen una práctica similar: los ADR, Architecture Decision Records.
Un ADR es un documento breve que traza una decisión de arquitectura. Explica el contexto, las opciones consideradas, la decisión adoptada y sus consecuencias.
La utilidad es simple: varios meses o varios años después, alguien puede entender por qué se tomó una decisión técnica.
Tomemos un ejemplo.
Una aplicación sufre un aumento de carga. Hay más clientes. Las consultas crecen. Los ralentizamientos se vuelven frecuentes. El equipo decide entonces implementar una tecnología de cola de mensajes para procesar ciertos mensajes de forma asíncrona.
Esta elección no es una feature.
Durante un mes, los desarrolladores quizás trabajarán en un proyecto puramente técnico. Tendrán que formarse. Tendrán que modificar parte de la arquitectura. No entregarán de inmediato un valor de negocio visible para el usuario final.
Pero esta decisión puede eliminar un cuello de botella mayor. Puede permitir absorber diez, veinte o treinta veces la carga actual añadiendo servidores. También puede liberar al equipo comercial, que podrá vender nuevos accesos de clientes sin temer que la aplicación se congele.
Un ADR permite documentar esta decisión.
¿Por qué se tomó? ¿Qué opciones se descartaron? ¿Qué consecuencias se aceptan? ¿Qué permite? ¿Qué restringe?
El Product Decision Record retoma esta lógica, pero en el lado del producto.
Un PDR no es una decisión de feature
Un Product Decision Record documenta una decisión de producto estructurante.
No una oportunidad.
No una tarjeta de Jira.
No una especificación.
No una feature.
Un PDR traza una regla de decisión que la empresa asume y que guiará varios productos, equipos o situaciones futuras.
No dice: "aquí está la funcionalidad a construir".
Dice más bien: "en este tipo de situación, aquí está la regla que aplicamos".
Es una diferencia importante.
Si se usan los PDR para documentar cada arbitraje local, la herramienta se convierte en burocracia. Pierde su fuerza. Un buen PDR debe referirse a una decisión lo suficientemente estructurante como para evitar decenas de rediscusiones.
Su valor viene de su escasez.
Una empresa no debería producir cincuenta PDR por trimestre. Unos pocos al año son suficientes. Cinco, diez, quince, veinte como máximo según el tamaño y la complejidad de la organización.
Un PDR debe ser lo bastante importante para tenerse en mente, o encontrarse rápidamente cuando una pregunta vuelve a aparecer.
Ejemplo: marketplace, ¿cliente o proveedor?
En un marketplace existe una tensión estructural.
Cuando aparece un conflicto, ¿hay que priorizar al cliente o al proveedor?
Se puede intentar hacer ambas cosas. Se puede buscar un compromiso cada vez. Se puede tratar cada caso como una excepción. Pero en muchas situaciones hay que elegir.
Si la empresa no documenta esta decisión, cada equipo corre el riesgo de interpretarla a su manera.
Soporte querrá preservar la relación con el cliente.
El equipo de partnerships querrá proteger a los proveedores.
El producto querrá evitar complicar las reglas.
Los comerciales empujarán la opción que ayude a la cuenta más estratégica del momento.
Y con cada conflicto, la misma pregunta volverá.
Un PDR permite fijar una línea directriz:
En caso de conflicto, priorizamos al cliente.
Esta decisión no describe una feature. No describe siquiera un flujo de trabajo preciso. Pero influirá en decenas de decisiones: reglas de reembolso, políticas de litigio, mensajes de soporte, prioridades de producto, arbitrajes operacionales, comunicación con el cliente.
Ese es exactamente el nivel adecuado para un PDR.
Documenta una decisión transversal.
Hace explícita la elección.
Permite a los equipos avanzar sin reabrir el debate en cada caso límite.
Ejemplo: los idiomas en un SaaS
Tomemos otro caso, muy frecuente en las empresas SaaS.
Los equipos comerciales quieren vender en varios países. Un prospect alemán pide una interfaz en alemán. Un prospect español pide español. Un gran cliente italiano pide italiano. Cada oportunidad parece interesante.
Pero en el lado del producto, traducir una aplicación no consiste solo en reemplazar texto.
Hay que traducir la interfaz. Mantener las traducciones. Probar las pantallas. Adaptar la documentación. Formar al soporte. Gestionar los emails. Verificar los mensajes automáticos. Seguir los cambios. Evitar que algunos idiomas se conviertan en versiones degradadas del producto.
Sin una decisión clara, cada nuevo prospect puede reabrir el tema.
Un PDR puede fijar la regla.
# PDR 004 — Idiomas soportados por defecto
## Estado
Validado
## Decisión
El producto se soporta por defecto en francés y en inglés. Cualquier otro idioma requiere un umbral mínimo de facturación anual firmada.
## Contexto
Los equipos comerciales encuentran oportunidades en varios países. Cada idioma añade un coste de traducción, mantenimiento, soporte, documentación y calidad de producto.
## Alternativas consideradas
- Traducir todos los idiomas solicitados: demasiado costoso y difícil de mantener.
- Soportar solo el francés: demasiado limitante para el desarrollo comercial.
- Soportar francés e inglés por defecto, y abrir otros idiomas bajo condición.
## Decisión adoptada
Francés e inglés se soportan por defecto. Los demás idiomas se abren solo si los contratos firmados superan un umbral definido.
## Consecuencias
- Mejor control de la calidad.
- Menos promesas comerciales difíciles de cumplir.
- Algunas oportunidades comerciales serán rechazadas o diferidas.
## Condiciones de reevaluación
La decisión se reevaluará si la IA reduce fuertemente el coste de traducción manteniendo un nivel de calidad aceptable, o si un nuevo segmento estratégico impone un idioma.
Este PDR no cierra definitivamente el tema.
Da una regla actual.
Permite a los comerciales saber qué pueden vender. Permite al producto rechazar solicitudes sin repetir toda la argumentación. Permite a la dirección entender el coste real de una apertura lingüística.
Y contiene una condición de reevaluación.
Si la IA hace posibles traducciones fiables a bajo coste, la decisión puede cambiar. Si un nuevo segmento estratégico impone un idioma, la decisión puede cambiar. Si varios contratos firmados justifican la inversión, la decisión puede cambiar.
Pero si cambia, no se reescribe el PDR anterior.
Se crea uno nuevo.
Lo que merece un PDR
No todas las decisiones de producto merecen un PDR.
Ese es incluso el punto más importante.
Un PDR debe seguir siendo escaso. Si no, se convierte en una forma de documentación adicional que nadie lee.
Una decisión probablemente merece un PDR si es transversal, estructurante, duradera, costosa de revertir, susceptible de ser rediscutida, útil para varios equipos, y lo bastante importante para influir en varias decisiones futuras.
Por el contrario, una decisión probablemente no merece un PDR si es local, puntual, vinculada a una sola feature, ya cubierta por una regla existente, sin consecuencias duraderas, o demasiado obvia para ser rediscutida.
El test es simple:
Si la decisión no va a evitar ninguna rediscusión futura, probablemente no necesita un PDR.
Un PDR no está ahí para documentar todo lo que decide el Product Manager.
Está ahí para documentar las elecciones que estructuran el marco en el que los Product Managers, los comerciales, el soporte, las operaciones y a veces la dirección tomarán después sus decisiones locales.
Un formato breve, estructurado, suficiente
Un PDR debe seguir siendo breve.
El formato sirve para evitar olvidos, no para producir un expediente burocrático.
Un template útil puede parecerse a esto:
# PDR <número> — <título>
## Estado
Propuesto | Validado | Reemplazado por PDR <número> | Abandonado
## Fecha
YYYY-MM-DD
## Decisión
Una frase clara.
## Contexto
Por qué esta decisión es necesaria ahora.
## Alternativas consideradas
- Opción A: ...
- Opción B: ...
- Opción C: ...
## Decisión adoptada
Lo que la empresa elige.
## Razones de la elección
- ...
- ...
## Consecuencias
### Positivas
- ...
### Negativas
- ...
### Riesgos
- ...
## Condiciones de reevaluación
Lo que podría justificar un nuevo PDR.
## Decisores y personas consultadas
- Decisor:
- Consultados:
## Referencias
- ...
El contenido exacto puede variar.
Pero lo esencial debe estar siempre presente: el contexto, la decisión, las alternativas, las razones de la elección, las consecuencias, los decisores, y lo que podría hacer evolucionar la decisión.
El PDR no debe convertirse en un PRD.
No debe describir toda la ejecución.
Debe documentar el porqué.
No se reescribe la historia
Un PDR validado no se borra.
No se reescribe para ocultar un cambio de posición.
Si hay que cambiar la decisión, se crea un nuevo PDR que reemplaza al anterior.
Eso es esencial.
El PDR no está ahí para demostrar que la empresa siempre tuvo razón. Está ahí para entender por qué decidió lo que decidió en un momento dado.
En el ejemplo de los idiomas, el primer PDR puede decir: francés e inglés únicamente por defecto, otros idiomas bajo condición de facturación firmada.
Dos años después, la IA puede cambiar el coste de traducción. La calidad puede volverse suficiente. El soporte puede equiparse mejor. El producto puede decidir que los idiomas secundarios se traducirán automáticamente, con revisión humana en los recorridos críticos.
Eso no es una contradicción.
Es una nueva decisión en un nuevo contexto.
El PDR anterior sigue siendo útil, porque explica por qué la empresa había inicialmente rechazado traducir en todos los idiomas. El nuevo PDR explica por qué ese rechazo ya no es adecuado.
Esta trazabilidad evita la amnesia de producto.
También evita los procesos internos absurdos: "¿Por qué no hicimos eso antes?" Quizás porque antes, el coste, la calidad, los recursos y el contexto comercial no permitían hacerlo correctamente.
PDR, PRD, roadmap, backlog: no mezclarlos
Un PDR no es un PRD.
Un PRD describe lo que se quiere construir.
Un PDR explica por qué la empresa ha elegido una regla de decisión.
Una roadmap muestra lo que la empresa hace, prepara, contempla o rechaza en un horizonte dado.
Un backlog organiza el trabajo ejecutable, o próximamente ejecutable.
Un ticket descompone una acción operacional.
El PDR está en el origen.
Puede influir en una roadmap. Puede condicionar un PRD. Puede explicar por qué ciertos tickets existen o no existen. Pero no los reemplaza.
Es precisamente porque se mantiene en ese nivel que resulta útil.
Si un PDR desciende demasiado, se convierte en una especificación disfrazada.
Si una roadmap intenta jugar el rol de un PDR, mezcla comunicación y regla de decisión.
Si un ticket lleva una decisión estructurante, la vuelve invisible para el resto de la empresa.
Cada herramienta debe mantenerse en su nivel.
El PDR no es burocracia
Es fácil usar mal los PDR.
Se pueden crear demasiados. Hacerlos demasiado largos. Convertirlos en actas. Usarlos para cubrirse las espaldas. Hacerlos validar por demasiada gente. Escribirlos a posteriori para justificar una decisión ya impuesta.
En ese caso, sí, el PDR se convierte en burocracia.
Pero ese no es su uso normal.
Un buen PDR elimina burocracia.
Evita repetir cincuenta veces la misma explicación.
Evita reabrir el mismo arbitraje con cada gran prospect.
Evita depender de la memoria de una persona.
Evita que los equipos naveguen entre reglas implícitas, excepciones no dichas y decisiones contradictorias.
La documentación no es el problema.
La mala documentación es el problema.
Un PDR breve, escaso, claro e inmutable no sobrecarga la organización. Le da una columna vertebral decisional.
Conclusión
Una empresa de producto no solo carece de prioridades.
A menudo carece de memoria sobre sus decisiones.
Sabe lo que ha hecho, pero no siempre recuerda por qué lo hizo. Recuerda una conclusión, pero no el contexto. Aplica una regla localmente, luego la olvida en otro lugar. Reabre una discusión porque nadie encuentra el arbitraje inicial.
El Product Decision Record sirve para evitar eso.
Transforma una decisión implícita en una regla explícita.
Documenta las elecciones de producto que estructuran la empresa.
Permite decir: "Ya hemos zanjado este tema. Aquí está el porqué. Aquí están las consecuencias que aceptamos. Aquí están las condiciones que podrían hacernos cambiar."
Un buen PDR no añade una capa de documentación.
Elimina decenas de discusiones inútiles.
Para saber más
Por qué las organizaciones prefieren las decisiones blandas El PM como arquitecto del Contexto Las herramientas de coherencia organizacional La pregunta de producto debe partir del código fuente