Las decisiones de producto sin documentar generan deuda de contexto: el equipo debate una y otra vez sobre lo mismo, y los nuevos PMs no entienden por qué el producto está como está. Aprende a registrar decisiones, hipótesis y aprendizajes de manera que el equipo tenga siempre el contexto completo. Acelera la toma de decisiones futuras y reduce conflictos.
Cuándo usarlo: Documentar decisiones de producto para reducir deuda de contexto
Herramienta recomendada: Claude
Actúa como Product Manager senior con experiencia en organizaciones de producto maduras. Ayúdame a diseñar una base de conocimiento de decisiones de producto (Product Decision Log) que permita al equipo tomar mejores decisiones más rápido y onboardear nuevos PMs sin pérdida de contexto. **El problema** Cada vez que entra un nuevo miembro al equipo de producto, hay semanas de preguntas repetidas: "¿por qué no usamos X enfoque?", "¿qué pasó con aquella funcionalidad que se eliminó?", "¿cómo decidimos que el precio sería así?". Las decisiones existen en correos, conversaciones de Slack o en la memoria de las personas. Quiero cambiar eso. **Entregables que necesito** 1. **Plantilla de PRD enriquecido con contexto de decisión**: toma un PRD estándar y añade secciones específicas para capturar: hipótesis de negocio detrás de la feature, alternativas descartadas y por qué, métricas de éxito predefinidas, criterios de pivote o cancelación, y registro de decisiones tomadas durante el desarrollo con su justificación. 2. **Product Decision Record (PDR)**: diseña una plantilla ligera para documentar decisiones de producto importantes que no ameritan un PRD completo. Incluye: pregunta de decisión, contexto, opciones evaluadas, evidencia utilizada, decisión tomada, responsable, fecha y fecha de revisión prevista. 3. **Repositorio de hipótesis validadas e invalidadas**: propón una estructura para mantener un registro de todas las hipótesis que el equipo ha testado. Incluye: hipótesis, experimento realizado, resultado, conclusión y implicaciones para el producto. 4. **Guía de onboarding para PMs nuevos**: escribe un plan de inmersión de 4 semanas usando la base de conocimiento. Qué documentos leer en qué orden, con quién reunirse, qué preguntas hacer y cómo empezar a contribuir al repositorio desde la primera semana. 5. **Proceso de mantenimiento**: define con qué frecuencia se revisa la base de conocimiento, quién es responsable de qué sección, cómo se archivan decisiones obsoletas y cómo se enlaza el repositorio con el roadmap y los tickets de desarrollo. 6. **Ejemplo completo**: simula un PDR real para la decisión de eliminar un plan de precios freemium de un producto SaaS. Rellena todos los campos con argumentos, datos inventados pero realistas, y la decisión final justificada. **Formato de salida** Encabezados claros para cada entregable. Plantillas en formato copiable. El ejemplo debe ser suficientemente detallado para usarse como referencia.