Genera un Product Requirements Document completo y listo para desarrollo: desde el problema de negocio hasta los criterios de aceptación, edge cases, dependencias técnicas y métricas de éxito. Elimina la ambigüedad que genera retrabajo entre producto e ingeniería.
Cuándo usarlo: Al iniciar el desarrollo de una nueva feature, antes de la reunión de refinement con el equipo de ingeniería o cuando hay debate sobre el alcance de algo.
Herramienta recomendada: Claude
Actúa como un senior Product Manager con 10+ años de experiencia escribiendo especificaciones funcionales para equipos de ingeniería de alto rendimiento en empresas como Stripe, Linear o Figma. Feature a documentar: - Nombre de la feature: [NOMBRE] - Problema de negocio que resuelve: [DESCRIPCIÓN DEL PROBLEMA] - Usuario objetivo: [PERSONA / SEGMENTO] - Contexto y origen: [REQUEST DE CLIENTE / DATO DE USO / INICIATIVA ESTRATÉGICA] - Restricciones conocidas: [TÉCNICAS, DE TIEMPO, DE NEGOCIO] - Qué NO incluye esta iteración (out of scope): [LISTA] Genera el PRD completo: ## 1. EXECUTIVE SUMMARY (½ página) - Problema → Solución → Impacto esperado → Timeline ## 2. CONTEXTO Y MOTIVACIÓN - ¿Por qué ahora? Datos o evidencias que justifican la priorización - Jobs to Be Done que cubre - Impacto en métricas de negocio (revenue, retención, activación, etc.) ## 3. USER STORIES Formato: Como [usuario], quiero [acción], para [beneficio] - Historia principal (happy path) - Historias secundarias (variaciones del happy path) - Historias de error (qué pasa cuando falla) ## 4. REQUISITOS FUNCIONALES Tabla con: ID | Requisito | Prioridad (Must/Should/Could) | Notas ## 5. CRITERIOS DE ACEPTACIÓN Para cada historia, criterios en formato Gherkin: Dado [contexto] → Cuando [acción] → Entonces [resultado esperado] ## 6. EDGE CASES Y ESTADOS ESPECIALES Lista de situaciones no-estándar que el equipo de ingeniería debe manejar: - Estado vacío (empty state) - Límites del sistema (rate limits, max items, etc.) - Comportamiento offline / con mala conexión - Concurrencia (dos usuarios editando simultáneamente) - Migración de datos existentes (si aplica) ## 7. DEPENDENCIAS - Equipos o features que deben completarse antes - APIs de terceros o cambios de backend requeridos - Cambios en el diseño de base de datos ## 8. MÉTRICAS DE ÉXITO - Métrica primaria: [definición + cómo medirla + objetivo a 30/60/90 días] - Métricas secundarias (2-3) - Guardrail metrics (qué NO debe empeorar) ## 9. PLAN DE LANZAMIENTO - Estrategia de rollout (feature flag, % de usuarios, qué segmento primero) - Plan de comunicación interna y externa - Cómo vamos a medir el éxito en las primeras 48h