En abril, escribí sobre lo que hizo que Prova se sintiera real: el motor de sprints, la facturación, las evaluaciones, el aburrido trabajo operativo que separa una demo de un producto.
Ese post era cierto cuando lo publiqué. La arquitectura sprint-first que describí — sprints redactados, revisiones por rúbrica, enrutamiento adaptativo, los caminos de Operator y Builder — estaba funcionando genuinamente. Era el motor correcto.
Lo que aún no sabía era que el currículo superpuesto encima seguía estando mal.
No mal de una forma que detectarías en una demo. Mal de la forma que solo aparece después de haber redactado cada rúbrica, trazado cada camino de usuario y formulado la pregunta que nadie me había obligado a hacer hasta mediados de mayo: ¿qué es exactamente lo que hace difícil que un chatbot gratuito replique esto?
Entre mediados de mayo y finales de junio, el currículo fue reconstruido dos veces. Cada vez, reemplacé algo de lo que previamente había estado convencido. Esto es de lo que se trató realmente cada reescritura.
La arquitectura de 3 carriles (26 de mayo – 1 de junio)
Para finales de mayo, el producto tenía un problema. Tenía 33 sprints, y tres audiencias muy diferentes — operadores rediseñando flujos de trabajo, builders tratando de entregar un primer slice útil, y líderes tratando de transformar equipos — compartiendo 7 de 9 sprints y llamando a los dos restantes un "carril". Eso era un menú, no una columna vertebral.
La amplitud no es un foso.
Así que construí lo que se sentía como la respuesta rigurosa: una arquitectura por capas con una base común Layer 0, luego tres carriles de audiencia (Operator, Builder, Leader) con sus propios sprints dedicados, todos provenientes de las 16 plantillas del curso y del corpus publicado. 38 unidades en 5 tipos de unidades. Concepto, ejercicio, sprint, proyecto, checkpoint — cada uno con semánticas de finalización distintas.
Sobre el papel, parecía un currículo real.
Lo que se rompió no fue ningún sprint individual. Fue la suposición estructural debajo de todo ello: que más carriles y más sprints hacían el producto más defendible.
No lo hacen.
El framework 7 Powers de Hamilton Helmer nombra esto explícitamente. El poder viene de barreras — ventajas estructurales que los competidores no pueden replicar solo con decidirlo. Añadir sprints a un camino no es una barrera. Es superficie operativa. Un chatbot genérico iguala la amplitud instantáneamente y sin fricción.
El modelo de 3 carriles añadió cobertura. No añadió profundidad. Había construido lo incorrecto, y no lo vi hasta que la arquitectura estuvo desplegada y cada sprint estuvo escrito.
Había redactado 24 nuevos sprints para el modelo de 3 carriles, provenientes de las plantillas del curso y del corpus publicado. La arquitectura parecía rigurosa sobre el papel. Estaba orgulloso de ella.
El sistema de carriles fue retirado la misma semana en que se desplegó.
La única regla (2 de junio – 22 de junio)
La segunda reescritura no comenzó con sprints. Comenzó con una pregunta estratégica.
Me senté y pregunté: si la única ventaja defendible de Prova es algo que una herramienta de IA horizontal no puede adoptar estructuralmente, ¿cuál sería esa ventaja?
La respuesta aterrizó en tres capas que se refuerzan mutuamente:
Profundidad vertical (la cuña). Un marketer que entrega un flujo de trabajo de campaña documentado con brief, con medición real y un umbral de decisión, según un estándar de nivel publicitario. Eso no es algo que un chatbot pueda producir desde un prompt.
Andamiaje (la activación). La mayoría de los marketers no saben qué preguntar. El producto debe encontrarlos en "creo que la IA podría ayudar con esto pero no sé por dónde empezar" y hacer el trabajo de acotar, secuenciar y establecer estándares.
Trabajo verificado, entregado según un estándar (la prueba). Cada sprint termina con una entrega revisada contra una rúbrica real. No "¿tiene buena pinta?". No "¿es gramaticalmente limpio?". Sino: ¿este artefacto resiste frente a lo que un operador de agencia o comprador de medios realmente usaría?
Desde esas tres capas, la arquitectura se simplificó drásticamente.
La estructura de 3 carriles fue reemplazada por una sola gramática en bucle: chequeo de realidad → brief → plan → ejecutar/construir → umbral de decisión → capstone.
Misma gramática para los tres caminos. Diferentes artefactos por camino. El operador ejecuta un piloto de flujo de trabajo de campaña. El builder entrega un slice de producto funcional. El líder construye un business case para stakeholders y un blueprint de modelo operativo.
La profundidad se añadió solo después del capstone: extensiones de agencia, extensiones de profundidad de producto, extensiones de cambio organizacional. Si un usuario quería más, se lo ganaba pasando primero por la columna vertebral.
La amplitud no desapareció. Fue degradada a módulos de desvío activados por evidencia — sprints cortos y asignados que solo aparecen cuando un revisor detecta una brecha que la columna vertebral redactada no puede abordar actualmente. La auditoría de infraestructura de datos. Las decisiones de stack de proveedores. El diagnóstico de apuestas mínimas. Siguen existiendo. Simplemente no son la ruta que tomas a menos que el producto tenga evidencia de que los necesitas.
El único commit que formalizó esto fue feat!: replace dual curriculum routing with unified path sequences el 11 de junio. El ! denota un cambio disruptivo. primary_path (operator, builder, leader) reemplazó a learning_track como el único eje de enrutamiento. Había un feature flag — DISABLE_BRIEF_DRIVEN_RESET_PATH — que aisló la transición hasta que el gate de QA fue superado. Siete sprints legacy fueron retirados de la secuenciación pero se mantuvieron visibles como historial.
El capstone se volvió estructural, no una funcionalidad. Es el mecanismo de coste de cambio. Una herramienta horizontal puede generar un paquete de sprint decente. No puede generar un portafolio de artefactos verificados, entregados, revisados contra estándares de nivel publicitario con un historial persistente de revisor.
Antes de redactar cualquier nuevo sprint o camino, pregunta: ¿cuál de los 7 Powers fortalece esto, y cuál es su barrera? Si la respuesta honesta es "añade cobertura" sin barrera, es superficie operativa que un chatbot ya cubre — no lo construyas.
— 5 de junio de 2026, documento de estrategia curricular de Prova
Esa regla mató la arquitectura de 3 carriles. Mató sprints que estaban bien escritos pero eran estructuralmente redundantes. Convirtió el capstone de una funcionalidad que estaba postergando en un requisito estructural. Y es la pregunta que debería haber estado haciendo desde marzo.
La diferencia entre abril y junio
El producto que lancé en abril tenía razón en el motor. El producto que cerré en junio tenía razón en la columna vertebral.
El motor — sprints redactados, revisiones por rúbrica, enrutamiento adaptativo, ciclo de vida de sprint compuesto — era necesario. Una arquitectura curricular sin un motor de sprints funcionando es solo un plan de estudios.
Pero un motor de sprints sin una columna vertebral defendible es solo una lista de funcionalidades que las herramientas gratuitas ya están igualando.
La diferencia entre los dos productos no fue más código. Fue una mejor pregunta. "¿Qué Power fortalece esto?" me obligó a matar cosas de las que estaba orgulloso, y a elevar cosas que había estado tratando como opcionales.
No estoy afirmando que la arquitectura de junio esté terminada. Los productos rara vez lo están. Pero si estás construyendo un producto de aprendizaje ahora mismo, vale la pena hacer la pregunta antes de escribir tu próximo sprint. Porque la amplitud es lo más fácil de añadir, y lo primero que una IA genérica va a comoditizar.
Contexto adicional: Prova es mi producto de coaching para marketers y profesionales de la publicidad, con un camino Operator para rediseño de flujos de trabajo y un camino Builder para entregar un primer slice útil. Está en prova.chandlernguyen.com. El framework 7 Powers proviene del libro 7 Powers: The Foundations of Business Strategy de Hamilton Helmer — este post referencia el framework pero no lo enseña; el libro es la fuente.
Si estás construyendo un producto estructurado sobre una capa de IA que se mueve rápido, tengo curiosidad genuina: ¿qué es eso en tu arquitectura que una herramienta gratuita no puede replicar solo añadiendo prompts?
Eso es todo de mi parte por ahora.
Un abrazo, Chandler