Qué NO hace el producto — el scope del MVP
Definir qué NO hace el MVP es más importante que definir qué sí hace. Cualquier founder puede listar 50 features que quisiera. Solo el que tiene claridad lista las 45 que no va a construir en el MVP. El scope se define por lo que se recorta.
MVP = producto core + lista explícita y consciente de recortes.
El documento de "qué no"
En tu spec del producto, una sección se llama "Fuera de scope del MVP". Lista explícita de qué queda fuera, con razón corta. Ejemplo:
- SSO: fuera. Razón: los primeros 20 clientes del ICP usan auth básica sin problema.
- Multi-tenant: fuera. Razón: primeros 10 son single-tenant; multi-tenant se agrega cuando el 11º lo pida.
- Mobile app: fuera. Razón: el ICP trabaja en desktop para este workflow; mobile es v2.
- API pública: fuera. Razón: 0 clientes pidieron integración custom.
Por qué la razón importa
Sin razón, los "fuera de scope" se convierten en "pendientes por construir", y el equipo los mete en sprint 2. Con razón, cada vez que alguien propone regresarlo, la razón se revisa: ¿cambió? Si no, sigue fuera.
El agente necesita saber lo que NO
Al leer el spec, el agente puede sugerir agregar features "lógicas" (ej. agregar roles si hay auth). Si tu spec no lista explícitamente qué está fuera, el agente termina implementando más de lo que querías. Recortes explícitos = scope defensible.
Escribe tu lista de "fuera de scope v1" ahora, con razón corta para cada uno. Si son menos de 5 items, probablemente tu scope está inflado.
- MVP = core + lista explícita de recortes.
- Cada "fuera de scope" lleva razón. Sin razón, regresa en sprint 2.
- El agente necesita saber lo que NO está en scope para no sobre-implementar.