Antes yo hacia una demo con IA, veia pantallas razonables y enseguida pensaba en backlog. Ese salto era demasiado rapido.
Ahora, cuando NxCode me deja revisar un MVP clickable, escribo un memo corto antes de darle tiempo de sprint al equipo. No es un PRD largo. Es una prueba para ver si el flujo ya merece trabajo de ingenieria.
Este es el esquema.
1. Un usuario y un disparador real
Escribo solo dos lineas:
- usuario principal
- evento que activa el flujo
Ejemplo:
- Usuario: responsable de operaciones de una agencia pequena
- Disparador: un lead queda calificado despues de la llamada inicial
2. La pantalla que demuestra valor
Me pregunto cual pantalla demuestra que el trabajo se esta resolviendo de verdad.
En este caso no es la portada. Es el tablero donde aparecen:
- responsable
- siguiente accion
- fecha limite
- estado
Si esa pantalla sigue pareciendo decorativa, el MVP aun no merece sprint.
3. Los datos que no pueden fallar
Solo anoto los campos que deben estar bien desde el primer dia:
- origen del lead
- prioridad
- responsable
- fecha limite
- nota corta del cliente
Asi evito modelar de mas demasiado pronto.
4. El caso limite que delata una demo
Siempre intento escribir una pregunta incomoda:
- que pasa si no hay responsable
- que pasa si falta la fecha
- que pasa si el item queda bloqueado
Si el flujo no aguanta una de esas preguntas, todavia es una demo.
5. Lo que saco del primer sprint
Aqui es donde el memo realmente ahorra tiempo:
- analytics
- notificaciones
- permisos complejos
- facturacion
- panel de admin
Recortar alcance antes del sprint suele valer mas que generar una pantalla extra.
6. La frase final de handoff
Termino con una frase concreta:
Construir tablero de intake, cambio manual de estado y siguiente accion; dejar permisos y reportes fuera del sprint uno.
Ese cierre obliga a decidir.
Estoy probando este flujo con NxCode porque me deja revisar un MVP real antes de abrir tareas:
La IA acelera la revision. El memo decide si el MVP merece ingenieria.