Escritura de PRDs y Feature Specs

El PRD Que Nadie Lee

🔄 Repaso rápido: En la lección anterior, exploramos la síntesis de user research e insights. Ahora construyamos sobre esa base.

Has escrito PRDs antes. Documentos largos y detallados que tomaron horas crear. ¿Después qué pasó? Ingeniería leyó por encima la primera página, te hizo un montón de preguntas que el PRD respondía (en la página 7), y construyó algo ligeramente diferente a lo que especificaste.

Al finalizar esta lección, escribirás PRDs que los equipos de ingeniería realmente usan — de forma rápida y eficiente con asistencia de IA.

El problema no es tu escritura. Es el formato. La mayoría de los PRDs están estructurados para el proceso de pensamiento del PM, no para el proceso de consumo del lector.

Un gran PRD hace tres cosas:

1. Le dice al equipo por qué esto importa (contexto y motivación)
2. Define cómo se ve el éxito (criterios claros)
3. Da suficiente detalle para decisiones de implementación sin sobre-prescribir cómo

La Estructura de PRD Que Funciona

1. Resumen (3 oraciones — qué y por qué)
2. Planteamiento del Problema (quién se afecta, cómo, evidencia)
3. Metas y Métricas de Éxito (resultados medibles)
4. User Stories (como [usuario], quiero [acción] para [beneficio])
5. Requerimientos (must-have vs. nice-to-have)
6. Acceptance Criteria (condiciones testeables para "listo")
7. Consideraciones de Diseño (requerimientos de UX, no soluciones)
8. Consideraciones Técnicas (restricciones, dependencias)
9. Fuera de Alcance (qué explícitamente NO estamos haciendo)
10. Preguntas Abiertas (qué falta decidir)
11. Timeline y Milestones

El insight clave: Las secciones 1-3 son para stakeholders y liderazgo. Las secciones 4-8 son para ingeniería y diseño. La sección 9 previene scope creep. La sección 10 muestra honestidad intelectual.

Generando Tu Primer Borrador

“Genera un PRD para el siguiente feature. Lo refinaré después de que lo redactes. CONTEXTO: Producto: [nombre y descripción], Usuario objetivo: [para quién es], Problema: [problema específico que resuelve], Evidencia: [cómo sabes que es un problema]. ENCAJE ESTRATÉGICO: Por qué ahora: [por qué estamos construyendo esto ahora], Cómo encaja en nuestro roadmap: [conexión con estrategia]. Restricción clave: [timeline, recursos, limitación técnica]. RESULTADO DESEADO: Métrica de éxito: [cómo mediremos si funcionó], Target: [número/porcentaje específico]. Genera un PRD completo con: Resumen, Planteamiento del Problema, Metas, User Stories (5-8), Requerimientos (must-have y nice-to-have), Acceptance Criteria, Consideraciones de Diseño y Técnicas, Fuera de Alcance, Preguntas Abiertas, Timeline. Sé específico y concreto. Evita requerimientos vagos como ‘debería ser rápido’ — usa criterios medibles.”

✅ Revisión rápida: ¿Cuáles son las tres cosas que un gran PRD debe lograr? Intenta recordarlas antes de seguir.

User Stories Que Realmente Comunican

Las user stories son frecuentemente la parte más débil de los PRDs. O son demasiado vagas (“Como usuario, quiero una mejor experiencia”) o demasiado prescriptivas (“Como usuario, quiero un botón azul en la esquina superior derecha”).

Fórmula: Como [tipo de usuario específico], quiero [acción específica] para [beneficio específico].

Mala: “Como usuario, quiero notificaciones.” Buena: “Como líder de proyecto, quiero recibir una notificación cuando un miembro del equipo completa un entregable, para poder revisarlo oportunamente y mantener el proyecto en calendario.”

Acceptance Criteria Que Previenen Discusiones

Acceptance criteria vagos causan retrabajo. “La búsqueda debería ser rápida” significa 100ms para ingeniería y 500ms para PM. “La búsqueda debería retornar resultados en menos de 200ms para el 95% de las queries” es inequívoco.

Usa el formato Given-When-Then:

Dado un usuario con permisos de edición
Cuando modifica un documento y hace clic en "Guardar"
Entonces los cambios se persisten en menos de 500ms
Y un toast de confirmación aparece por 3 segundos
Y el timestamp de última modificación se actualiza

Dado un usuario sin permisos de edición
Cuando intenta modificar un documento
Entonces los controles de edición están deshabilitados
Y un tooltip muestra "No tienes permisos para editar este documento"

La Sección “Fuera de Alcance”: Tu Mejor Amiga

La sección más subestimada del PRD. Sin ella, el alcance se arrastra. Con ella, tienes un punto de referencia para cada conversación de “pero, ¿y si…”

✅ Revisión rápida: ¿Por qué la sección “Fuera de Alcance” es tan valiosa? ¿Qué previene?

Adaptando PRDs para Diferentes Audiencias

Diferentes stakeholders necesitan diferentes vistas del mismo feature:

Ponlo en Práctica

Toma un feature que estés planeando actualmente. Usa el workflow:

1. Alimenta tu contexto en el prompt de generación de PRD
2. Refina el output con tu contexto estratégico y conocimiento del equipo
3. Corre un prompt de revisión de calidad
4. Crea las versiones adaptadas para tus stakeholders
5. Compara el resultado con PRDs que hayas escrito antes

Conclusiones Clave

• Los grandes PRDs definen qué y por qué, no cómo — dale a ingeniería contexto para tomar decisiones inteligentes de implementación
• La estructura que funciona: resumen, problema, metas, user stories, requerimientos, acceptance criteria, fuera de alcance
• La IA genera fuertes primeros borradores que refinas con contexto estratégico y conocimiento del equipo
• Las user stories deben capturar metas del usuario, no detalles de implementación
• Los acceptance criteria deben ser específicos y testeables: “menos de 200ms para el 95% de queries” no “debería ser rápido”
• Adapta el PRD para diferentes audiencias: ejecutivos necesitan estrategia, ingenieros necesitan specs, diseñadores necesitan contexto de usuario

En la Siguiente Lección

En la Lección 4: Priorización de Features y Roadmapping, usaremos frameworks y IA para priorizar features y construir roadmaps defendibles.