El Product Manager: PRD y User Stories
El Product Manager: Scope Gatekeeper
El Product Manager (PM) es el segundo agente en el flujo de BMAD. Su rol principal es transformar la vision abstracta del Product Brief en requisitos concretos y medibles. En BMAD se le llama Scope Gatekeeper porque su trabajo es definir con precision que entra en el producto y que no.
Mientras el Analyst soñaba con posibilidades, el PM las aterriza en realidad.
Como cargar el agente PM
En tu IDE agentico, activas el agente PM referenciando su persona:
@bmad-core/personas/product-manager.mdEl PM recibe como input el Product Brief generado por el Analyst y lo procesa para generar el PRD.
Que es un PRD en BMAD
El PRD (Product Requirements Document) es el artefacto central de esta fase. No es un documento de 50 paginas: es un archivo Markdown estructurado que contiene:
- Requisitos funcionales numerados
- Requisitos no funcionales
- Definicion del MVP
- Epics de alto nivel
- User stories con criterios de aceptacion
Todo versionado en Git, todo trazable.
PRD del Kanban: Requisitos Funcionales
El PM analiza el Product Brief del Kanban y genera requisitos numerados con IDs unicos:
| ID | Requisito | Prioridad |
|---|---|---|
| FR-01 | Registro e inicio de sesion con email/password | Alta |
| FR-02 | CRUD de tableros (crear, leer, actualizar, eliminar) | Alta |
| FR-03 | Cada tablero tiene columnas predeterminadas: To Do, In Progress, Done | Alta |
| FR-04 | CRUD de tarjetas con titulo, descripcion, prioridad y asignado | Alta |
| FR-05 | Mover tarjetas entre columnas mediante drag & drop | Alta |
| FR-06 | Filtrar tarjetas por prioridad o asignado | Media |
| FR-07 | Invitar usuarios a un tablero por email | Media |
| FR-08 | Historial de movimientos de tarjetas entre columnas | Baja |
Cada requisito tiene un ID unico que se referencia en todo el proyecto. Cuando el Developer implemente una feature, sabra exactamente que FR esta cubriendo.
Requisitos No Funcionales
Los NFR definen las restricciones de calidad del sistema:
| ID | Requisito | Metrica |
|---|---|---|
| NFR-01 | Tiempo de carga inicial menor a 2 segundos | Lighthouse Performance > 90 |
| NFR-02 | Passwords hasheados con bcrypt, tokens JWT con expiracion | OWASP Top 10 |
| NFR-03 | UI navegable por teclado, contraste WCAG AA | axe-core sin errores criticos |
| NFR-04 | API responde en menos de 200ms para operaciones CRUD | p95 latency |
Definicion del MVP
El PM traza una linea clara entre lo que entra y lo que no entra en la primera version:
Dentro del MVP:
- FR-01 a FR-05 (auth, CRUD tableros, CRUD tarjetas, drag & drop)
- NFR-01 a NFR-04
- Un solo tipo de usuario (sin roles admin/miembro)
Fuera del MVP:
- FR-06 (filtros) → v1.1
- FR-07 (invitaciones) → v1.1
- FR-08 (historial) → v1.2
- Notificaciones en tiempo real → v2.0
- App movil → v2.0
Esta decision es critica. Sin un MVP definido, el proyecto crece sin control. El PM actua como guardian: si un requisito no esta en el MVP, no se implementa en esta iteracion.
Epics
Los Epics agrupan funcionalidades relacionadas. Son contenedores logicos que luego se descomponen en stories:
| ID | Epic | Requisitos Asociados |
|---|---|---|
| EP-01 | Autenticacion y Usuarios | FR-01 |
| EP-02 | Gestion de Tableros | FR-02, FR-03 |
| EP-03 | Gestion de Tarjetas | FR-04 |
| EP-04 | Interaccion y UX | FR-05 |
Cada Epic es independiente pero tiene dependencias de orden: EP-01 debe completarse antes que EP-02, porque sin usuarios no hay tableros.
User Stories en formato Gherkin
El PM escribe user stories con criterios de aceptacion verificables usando el formato Given/When/Then:
US-01: Registro de usuario
Como usuario nuevo
Quiero registrarme con email y password
Para acceder a mis tableros personales
Given que estoy en la pagina de registro
When ingreso un email valido y un password de 8+ caracteres
Then se crea mi cuenta y soy redirigido al dashboard
Given que intento registrarme con un email ya existente
When envio el formulario
Then veo un mensaje de error "Email ya registrado"US-02: Crear tablero
Como usuario autenticado
Quiero crear un nuevo tablero con nombre
Para organizar mis tareas
Given que estoy en el dashboard
When hago clic en "Nuevo Tablero" e ingreso un nombre
Then se crea el tablero con columnas To Do, In Progress y DoneUS-03: Crear tarjeta
Como usuario autenticado
Quiero crear tarjetas dentro de una columna
Para registrar tareas pendientes
Given que estoy viendo un tablero
When hago clic en "Agregar Tarjeta" en la columna To Do
And completo titulo y descripcion
Then la tarjeta aparece en la columna To DoUS-04: Mover tarjeta con drag & drop
Como usuario autenticado
Quiero arrastrar tarjetas entre columnas
Para actualizar el estado de mis tareas
Given que tengo una tarjeta en "To Do"
When la arrastro a "In Progress"
Then la tarjeta se mueve a "In Progress"
And la posicion se persiste en la base de datosUS-05: Asignar prioridad a tarjeta
Como usuario autenticado
Quiero asignar prioridad (alta, media, baja) a una tarjeta
Para identificar las tareas mas urgentes
Given que estoy editando una tarjeta
When selecciono prioridad "Alta"
Then la tarjeta muestra un indicador visual de prioridad altaUS-06: Login de usuario
Como usuario registrado
Quiero iniciar sesion con mis credenciales
Para acceder a mis tableros
Given que estoy en la pagina de login
When ingreso email y password correctos
Then recibo un token JWT y soy redirigido al dashboard
Given que ingreso credenciales incorrectas
When envio el formulario
Then veo "Credenciales invalidas" sin revelar cual campo falloComo el PM evita el scope creep
El PM en BMAD tiene guardrails especificos:
- Todo requisito necesita un ID: si no tiene FR-XX o NFR-XX, no existe
- Todo requisito se clasifica como MVP o post-MVP: no hay zonas grises
- Las user stories referencian requisitos: US-01 implementa FR-01
- Si algo nuevo aparece durante desarrollo, debe pasar por el PM antes de implementarse
Este rigor evita el clasico problema de “ya que estamos, agreguemos esto”. Cada adicion pasa por el filtro del PM.
Revision humana del PRD
BMAD no es automatico al 100%. Despues de que el PM genera el PRD, tu como humano debes revisar:
- ¿Los requisitos funcionales cubren lo que necesitas?
- ¿Las prioridades son correctas?
- ¿El MVP tiene el alcance adecuado? (ni demasiado grande ni demasiado pequeño)
- ¿Las user stories son verificables?
- ¿Falta algun flujo critico?
Puedes pedirle al PM que ajuste, agregue o elimine requisitos. El agente iterara hasta que el PRD tenga tu aprobacion.
Solo cuando el humano aprueba el PRD, el siguiente agente (Architect) puede comenzar su trabajo.
Artefacto generado
Al finalizar esta fase, tienes en tu repositorio:
docs/
prd.md ← Requisitos funcionales y no funcionales
epics.md ← Epics con dependencias
user-stories/
US-01-registro.md
US-02-crear-tablero.md
US-03-crear-tarjeta.md
...Todo trazable, todo versionado, todo listo para el Architect.