Estructura el documento de requisitos con el problema, las decisiones tomadas, los casos límite y lo que queda fuera, de forma que diseño y desarrollo puedan empezar sin diez rondas de aclaraciones.
Cuándo usarlo: Escribir un PRD completo con problema, alcance explícito, casos límite decididos y supuestos marcados para que el equipo empiece sin aclaraciones
Herramienta recomendada: Claude
Actúa como product manager senior que escribe documentos que el equipo lee de verdad. Quiero un PRD que responda de antemano las preguntas que siempre llegan por chat tres días después de empezar. ## Contexto que necesito 1. El problema: quién lo tiene, con qué frecuencia y qué hace hoy para resolverlo. 2. Evidencia disponible: datos de uso, tickets, entrevistas, peticiones. 3. Objetivo de negocio y métrica que debería moverse. 4. Restricciones conocidas: técnicas, legales, de plazo, de equipo. 5. Qué has decidido ya y qué está abierto de verdad. ## Estructura del documento ### 1. Problema (media página, sin solución dentro) Quién, cuándo, con qué frecuencia, qué coste tiene hoy. Con la evidencia citada. Si la evidencia es una petición de un cliente grande, dilo tal cual: es una razón legítima, pero es distinta de un patrón observado. ### 2. Por qué ahora Qué cambia si lo hacemos este trimestre en lugar del siguiente. Sin esta sección, cualquier cosa parece prioritaria. ### 3. Resultado esperado Métrica principal, valor actual, valor objetivo y plazo de evaluación. Más las métricas de control que no deben empeorar. Un objetivo sin métrica de control es una invitación a optimizar una cosa rompiendo otra. ### 4. Alcance Dos listas explícitas: **dentro** y **fuera**. La lista de fuera es la que evita la mitad de las discusiones, y hay que escribirla aunque parezca obvia. ### 5. Comportamiento esperado Los recorridos principales, paso a paso, en presente y en lenguaje de usuario. Para cada uno: qué ve, qué hace, qué ocurre, qué pasa si falla. ### 6. Casos límite y estados Tabla con: sin datos, un solo elemento, muchísimos elementos, sin permisos, sin conexión, operación duplicada, valores extremos, texto muy largo, usuario que no ha completado un paso previo. Y la decisión para cada uno. **Este apartado es el que distingue un PRD útil de una idea escrita**: cada hueco aquí se convierte en una decisión improvisada de quien implemente. ### 7. Decisiones tomadas y descartadas Qué se decidió, qué alternativas se valoraron y por qué se descartaron. Evita que la discusión vuelva cada dos semanas. ### 8. Preguntas abiertas Con responsable y fecha. Ninguna pregunta abierta sin dueño. ### 9. Lanzamiento Cómo se despliega (a quién primero), qué se mide, cuándo se revisa y en qué condiciones se revierte. ## Lo que quiero que hagas además - Señálame las contradicciones o los huecos de la información que te he dado, en lugar de rellenarlos. - Marca cada afirmación del documento como «dato», «supuesto» o «decisión». Los supuestos son los que hay que validar antes de construir. - Propón la versión mínima que aprende lo mismo con menos trabajo. ## Entregables 1. El PRD completo con los nueve apartados. 2. Lista de supuestos que conviene validar antes de empezar, y cómo validarlos rápido. 3. Preguntas que le harán al equipo y que el documento ya responde (para comprobar que está completo). 4. La versión mínima alternativa, con lo que se sacrifica.