Los PRDs largos son ruido: cómo comunicar sin perder el equipo

Te pasa esto: escribiste un PRD de 47 páginas, perfecto, detallado, con todos los casos edge. Lo mandaste al equipo hace tres semanas. Hoy en la daily alguien pregunta "¿y esto cómo funciona cuando el usuario no tiene email?"

Está en la página 34, párrafo 6.

Nadie leyó tu PRD. Y tenés razón en estar frustrado, pero también tenés que entender por qué pasa.

Por qué los PRDs largos fracasan

Los equipos de desarrollo no son bibliotecarios. Son personas que necesitan información específica en momentos específicos para tomar decisiones específicas.

Cuando escribís un documento de 40 páginas:

• El dev que está codificando la validación de email necesita saber qué pasa si el campo está vacío. No necesita leer sobre el flujo de onboarding.
• La diseñadora trabajando en el modal de confirmación quiere entender qué estados mostrar. No le importa la estrategia de go-to-market.
• El QA testeando edge cases busca scenarios específicos. No va a leer 15 páginas de contexto de negocio.

El problema no es que tu equipo sea vago. El problema es que estás dando toda la información a todos todo el tiempo.

Alternativa 1: User stories granulares

En lugar de un documento monolítico, escribí user stories que se puedan consumir de a una.

Como usuario que se registra sin email
Quiero poder usar mi número de teléfono
Para acceder a la plataforma sin crear una cuenta de email

Criterios de aceptación:
- El campo email es opcional si hay número de teléfono
- Se envía SMS de verificación en lugar de email
- El flujo de recuperación de contraseña usa SMS
- Si después quiere agregar email, puede hacerlo desde perfil

Definition of Done:
- Funciona en mobile y desktop
- Tiene tests automatizados
- Copy revisado por contenido

Cada story tiene la información necesaria para esa funcionalidad específica. El dev que la agarra sabe exactamente qué hacer.

Alternativa 2: Flujos visuales + contexto just-in-time

Los diagramas de flujo comunican mejor que los párrafos. Pero no pongas TODO el flujo en un solo diagrama.

Hacé esto:

1. Flujo principal: el happy path en un diagrama simple
2. Flujos secundarios: cada variación en su propio diagrama
3. Documentación contextual: links desde cada paso del flujo a la info específica

Por ejemplo, en el paso "Validar email" del diagrama, un link te lleva a:

• Regex de validación
• Mensajes de error
• Casos especiales (emails corporativos, dominios bloqueados)
• Analytics a trackear

La información está ahí cuando la necesitás, no cuando no.

Alternativa 3: Wiki estructurada por dominio

En lugar de un documento por feature, organizá la información por dominios:

Autenticación

• Registro (email, teléfono, social)
• Login (casos normales y edge)
• Recuperación de contraseña
• Validaciones y errores

Perfil de usuario

• Datos obligatorios vs opcionales
• Edición de información
• Cambio de email/teléfono
• Eliminación de cuenta

Cada página tiene:

• Overview: qué hace este dominio
• Flujos: cómo interactúa con otros dominios
• APIs: endpoints y contratos
• Reglas de negocio: validaciones y lógica
• Testing: casos importantes a cubrir

Cómo implementar el cambio sin romper todo

No tires tu PRD actual a la basura mañana. Hacé la transición gradual:

1. Extraé las user stories más importantes del PRD existente
2. Creá una página de wiki por cada dominio principal
3. En la próxima reunión de planning, usá las stories granulares en lugar del documento largo
4. Pedí feedback específico: "¿Tenés toda la info que necesitás para esta story?"
5. Iterá según lo que funciona para tu equipo

Lo más importante: no fuerces un formato que no se adapta a cómo trabaja tu equipo.

Midiendo si funciona

Sabés que tu nueva forma de comunicar requerimientos funciona cuando:

• Las preguntas en daily son sobre decisiones técnicas, no sobre "qué tengo que hacer"
• Los devs pueden estimar stories sin pedirte aclaraciones
• QA encuentra bugs de lógica, no de "no entendí el requerimiento"
• Las discusiones de planning son sobre cómo implementar, no sobre qué implementar

Si seguís recibiendo las mismas preguntas básicas, el problema no es que no leyeron. Es que la información no está donde la necesitan, cuando la necesitan.

Preguntas frecuentes

¿Y si mi stakeholder quiere ver "todo el documento"?

Mostrále el valor del output: features entregadas más rápido, menos bugs, equipo más autónomo. Si insiste en el documento largo, hacelo pero usá las herramientas más ágiles para el trabajo diario.

¿Cómo manejo cambios de requerimientos?

Con documentos granulares es más fácil. Cambiás la story específica, actualizás el wiki del dominio afectado, comunicás el cambio al equipo. No tenés que reescribir 40 páginas.

¿No se pierde la visión general?

La visión general va en otro lado: en tu product strategy, en las OKRs, en las presentaciones de roadmap. Los PRDs no son el lugar para contar la historia completa del producto.