PRD de negocio

# PRD de Negocio — [Nombre del proyecto]

> Audiencia: tomadores de decisión, equipo comercial, stakeholders no técnicos.
> Sale de partir el PRD inicial en dos, con el prototipo ya aprobado (F3.4). Los IDs de
> requisito y métrica (`RF-1`, `MET-1`) **se conservan**: el prototipo traza a ellos.
> Este PRD (Product Requirements Document) debe pasar la validación de F3.4 antes de que el proyecto avance.
>
> **Frontera:** aquí va el **por qué y para quién**. El comportamiento detallado —estados,
> validaciones, mensajes, permisos, casos límite— vive en las specs, nunca aquí (ver
> `../methodology/workflow.md` → *Las capas de la definición*).

## 1. El problema

[Qué problema existe, a quién le duele, y qué pasa hoy cuando ocurre. Concreto, sin tecnología.]

## 2. Usuarios objetivo

| Usuario | Contexto | Qué necesita |
|---|---|---|
| [Tipo de usuario 1] | [Su situación] | [Lo que el producto le resuelve] |
| [Tipo de usuario 2] | | |

## 3. La solución propuesta

[Qué hace el producto, en lenguaje de negocio. Qué cambia en la vida del usuario cuando existe.]

> Es la sección por la que se cuela el comportamiento. Si al describirla aparece un *"cuando pasa
> X, el sistema hace Y"*, eso es una spec: se escribe una sola vez, allá, citando el `RF-*`
> correspondiente.

## 4. Métricas de éxito

[Cómo sabremos que el PMV (Producto Mínimo Viable) funcionó. Métricas medibles con su valor objetivo.]

- [Métrica 1]: [objetivo]
- [Métrica 2]: [objetivo]

## 5. Alcance del PMV

### Incluido

- [Funcionalidad esencial 1]
- [Funcionalidad esencial 2]

### Explícitamente fuera de alcance

> Esta sección es obligatoria. Lo que no se escribe aquí se discute después, cuando ya es caro.

- [Lo que NO se va a construir en el PMV y por qué]

### Hitos

> *Solo si el proyecto se entrega en más de un bloque contratado por separado
> (`../methodology/hitos.md`); si no, borrar esta subsección.* El mapa viene del Documento de
> Entendimiento y aquí es contrato: cada requisito declara su hito (`RF-4 · H-1`) y el hito
> entregado se marca con su alcance real, no con el prometido.

| Hito | Promesa | Requisitos | Deja fuera | Estado |
|---|---|---|---|---|
| `H-1` | [Qué puede hacer el usuario al terminarlo] | `RF-1`, `RF-4` | [Lo que se pospone, y a qué hito] | ☐ En curso / ☑ Entregado (fecha) |
| `H-2` | | | | ☐ Pendiente |

## 6. Restricciones de negocio

[Presupuesto, plazos, regulación, dependencias de terceros, acuerdos existentes.]

## 7. Descubribilidad pública

> Decisión de negocio que activa o elimina el estándar SEO (Search Engine Optimization)/GEO (Generative Engine Optimization)
> (`../methodology/standards.md` §8). Por defecto, **No**.

¿El producto necesita ser **encontrado o citado fuera de su propio acceso** (buscadores,
asistentes de IA, agentes)? **Sí / No.** Si **sí**, indicar alcance: SEO para humanos,
visibilidad en IA (GEO/AEO —Answer Engine Optimization—), `llms.txt` para agentes, o combinación.

## 8. IA dentro del producto

> Decisión de negocio que activa o elimina el estándar de **evals y guardrails**
> (`../methodology/standards.md` §10). Por defecto, **No**. No se pregunta si el producto **se
> construye** con IA —eso es toda la metodología—, sino si **la lleva dentro**.

¿Alguna funcionalidad del producto se apoya en un modelo (lenguaje, visión, recomendación) cuya
salida el usuario ve o usa? **Sí / No.** Si **sí**, indicar cuáles y qué decide el modelo: es lo
que define el alcance de los evals y de los guardrails.

## 9. Riesgos

| Riesgo | Impacto | Mitigación |
|---|---|---|
| | | |

---

## Checklist de validación (F3.4)

- [ ] El problema está claramente definido
- [ ] Los usuarios objetivo están identificados
- [ ] Las métricas de éxito están establecidas y son medibles
- [ ] Los casos fuera de alcance están explicitados
- [ ] Descubribilidad pública decidida (sí/no)
- [ ] IA dentro del producto decidida (sí/no) — activa o elimina §10
- [ ] **Aprobación humana explícita**: ____________ (fecha y quién)