Nombre del módulo

Traducción de la plantilla. Autoritativo: ../../modules/TEMPLATE-prd.md.

​

Para quién es

Las personas del tenant (quién lo configura, quién lo opera a diario, quién lee sus reportes) y la persona member (el cliente final del tenant). Nombrar el trabajo que cada una está contratando a este módulo para hacer.

​

El problema hoy

Qué hacen esas personas en cambio hoy, y qué les cuesta. Referenciar evidencia real — el benchmark, una observación del design partner, una regulación — no supuestos.

​

Qué hace (normativo)

Las capacidades, a la altura de “un tenant puede…”. Cada línea debería mapear a uno o más feature specs después; si una línea no tiene un FS plausible, es marketing y no alcance.

​

Lo que NO hace (normativo)

Qué no hace deliberadamente este módulo, en v1 y posiblemente nunca. Incluir las cosas adyacentes tentadoras y decir a dónde pertenecen realmente. Es la sección más valiosa de un PRD.

​

Éxito

Cómo sabremos que funcionó, como números con fecha. Adopción, uso, latencia o ingresos — el que refleje genuinamente el valor. Criterios de éxito vagos producen módulos vagos.

​

Modelo comercial

Qué métricas mide este módulo, cómo afecta la base facturable, qué capacidades se gatean por plan o se venden como add-on, y toda implicancia de pricing que condicione el diseño.

​

Fases

​

Cumplimiento y riesgo

Datos personales tocados, implicancias de consentimiento y retención, y las obligaciones concretas bajo la Ley 21.719 / LGPD que crea este módulo. Qué tendríamos que hacer si mañana un titular pidiera ser suprimido.

​

Dependencias

Otros módulos, puertos o vendors que este módulo necesita, y qué se rompe si no están disponibles.

​

Preguntas abiertas

Cada una con quién decide y para cuándo.

​

Changelog