Tenía una carpeta con el contexto del producto para que la IA dejara de inventarse cosas. Estrategia, decisiones, métricas, feedback, todo en markdown, metido en cada prompt. Dos semanas fue genial. Luego el equipo shipeó, la carpeta no se movió, y la IA empezó a responder con total seguridad sobre un producto que ya no existía.
Esa carpeta me enseñó algo que no quería aprender. Montar el cerebro es la mitad fácil. La pregunta que decide si algo de esto sobrevive al contacto con un equipo de verdad es la que yo no sabía responder: ¿quién lo mantiene al día?
La carpeta empieza a mentir en cuanto shipeas
Una carpeta de notas tiene una forma de fallar muy silenciosa. No se rompe. Se desfasa.
Escribes el PRD el lunes. El viernes el equipo ha shipeado tres cambios, dos de los cuales lo contradicen sin avisar. Nadie tocó el documento, porque actualizarlo no es tarea de nadie y es lata de todos. Así que ahora la IA lee un contexto que es verdad a medias, y te responde con seguridad sobre un producto que ya no existe.
Aquí hay dos dolores y has sentido los dos. La IA te da respuestas viejas, porque el contexto que lee se quedó atrás. Y tú te pasas las tardes actualizando docs, PRDs y estado del producto, porque en cuanto paras, tu propia documentación empieza a mentirte.
La reacción típica es montar un cerebro mejor. Mejores plantillas, convenciones más estrictas, una wiki más mona. Eso es optimizar el archivo. No ayuda, porque el problema nunca fue el archivo. El problema es que el archivo no tiene forma de enterarse de que el producto cambió.
El cerebro tiene que ser un grafo, no una carpeta
Una carpeta es un montón. Un montón no sabe qué se relaciona con qué. Cuando cambias una decisión, una carpeta no te puede decir qué historias de usuario acabas de invalidar, porque no sabe que estaban conectadas.
Así que el primer movimiento es dejar de guardar el contexto de producto como documentos y empezar a guardarlo como un grafo. Cada artefacto es un nodo: el PRD, cada épica, cada historia de usuario, cada criterio de aceptación, cada decision record, cada riesgo. Y los nodos se conectan con relaciones tipadas que significan algo: esta épica forma parte de ese PRD, este criterio valida esa historia, esta decisión reemplaza a aquella, esta tarea implementa ese criterio.
Suena a burocracia. Es lo contrario. En cuanto las relaciones son reales, el grafo responde preguntas que una carpeta no puede:
- Cambia una decisión y ves cada historia y criterio aguas abajo que toca.
- Reabre un riesgo y caminas hasta el trabajo que debía mitigarlo.
- Pregunta “por qué existe esto” y el grafo te lleva hacia arriba desde una línea de comportamiento hasta el objetivo que la pidió.
La jerarquía de producto deja de ser un cuento que cuentas en la daily y pasa a ser una estructura que la máquina puede recorrer. Esa es la diferencia entre documentación que mantienes y un cerebro que aguanta su propia forma.
El loop que un humano no puede llevar
Y ahora la parte que importa, la que la gente de la carpeta no termina de contar.
Cinco cosas deberían alimentar un cerebro de producto: entra feedback y se agrupa en oportunidades; tomas una decisión y queda registrada; se mueve una métrica y el cerebro la absorbe; haces discovery y se incorpora; y la grande, tu equipo shipea algo, y eso actualiza el estado del producto, las guías y reconcilia el PRD.
Cuatro las puedes hacer a mano si eres disciplinado. La quinta no. Y no porque seas vago. Porque el disparador está mal.
Cuando el loop se dispara con “el equipo shipeó”, con lo que se dispara en realidad es con alguien marcando una tarea como hecha. Y una tarea marcada como hecha es una opinión. El agente dijo que había terminado, el build se puso verde, la tarjeta se movió. Nada de eso significa que el código haga lo que pedía la historia. Un build en verde no es una feature correcta. Si tu cerebro de producto se actualiza cada vez que alguien marca done, se llena de mentiras con seguridad, y lo hace más rápido de lo que puedes cazarlas.
Así que el disparador tiene que cambiar. El cerebro debería actualizarse cuando el trabajo se verifica contra el criterio que lo definió, no cuando un humano canta victoria.
Ata el código a la decisión que lo pidió
Esta es la versión que llevo meses construyendo en lugar de una carpeta.
Cuando una pieza de trabajo termina, no se limita a cambiar de estado. El sistema va y busca la evidencia real en el repo, el código de verdad, los tests, la config, las ejecuciones, y enlaza esa evidencia con el artefacto que la exigía. No “este PR seguramente tiene que ver”, sino un enlace durable y tipado: este código satisface este criterio de aceptación, esta ejecución valida esta historia. Cada artefacto declara de antemano qué tipo de evidencia lo probaría, y terminar es producir esa evidencia, no afirmarla.
El efecto es que cada línea de código queda atada a la decisión de producto que la pidió. El grafo deja de ser una descripción del producto que vive al lado del código. Está cableado dentro del código. Cuando el trabajo cambia, el cerebro cambia, porque el enlace entre los dos es el mismo hecho, no dos hechos que tienes que mantener sincronizados.
Esto es el loop que un humano no puede llevar a mano, funcionando solo. El cerebro se mantiene verdadero no porque tú lo actualizaste, sino porque “verdadero” es lo que significa pasar la verificación.
El efecto secundario: por fin ves en qué se va tu tiempo
En cuanto el código queda atado a los artefactos de producto, cae algo gratis que no esperaba valorar tanto como lo valoro.
Puedes ver en qué se va de verdad tu tiempo y tu gasto, por producto, no por commits sueltos.
Cada unidad de trabajo de IA queda atribuida: qué rol la gastó, en qué proyecto, contra qué artefacto. No “quemamos un montón de tokens esta semana”, sino “esta épica costó esto, el trabajo de product owner costó aquello, esta feature fue tres veces más cara de dejar bien de lo que estimamos”. El coste y el esfuerzo suben por el mismo grafo que el trabajo, porque cuelgan de los mismos nodos.
Para un PM eso cambia la conversación. Dejas de discutir sobre actividad y empiezas a mirar dónde se concentra el esfuerzo contra los resultados. El grafo que mantiene tu contexto verdadero es el mismo que te dice cuánto costó de verdad tu roadmap.
Deja de optimizar el archivo
El cambio de mentalidad es pequeño y lo cambia todo. Deja de intentar montar un archivo mejor. El archivo nunca fue el punto.
Monta la estructura que conecta producto con código, y que el disparador sea la verificación, no un clic. Hazlo y el cerebro se mantiene solo, porque mantenerlo verdadero deja de ser una tarea que haces y pasa a ser una propiedad de cómo se hace el trabajo.
La carpeta era lo fácil, y nunca fue lo que importaba. Lo que de verdad necesitaba construir era el loop que evita que me mienta.
Por esto construyo PaellaDoc como lo construyo, y va pegado al resto del argumento: hacer producto no es productizar, y un build en verde no es una feature correcta.
¿Cómo evitas tú que el cerebro de tu producto se desfase? Cuéntamelo en el foro, quiero saber qué te funciona.