Casi todos los días, en Slack, me llega la pregunta de producto.

No una pregunta abstracta. No una gran reflexión sobre la visión a cinco años. Una pregunta de campo, de las de verdad.

¿Podemos hacer esto?

¿Qué ocurre si el cliente configura el producto así?

¿Cuál es el límite?

¿Se aplica esta regla también en este caso?

¿Por qué bloquea el producto aquí?

¿Podemos prometerle esto al cliente?

Algunas de estas preguntas son estratégicas. Exigen entender el mercado, al cliente, el posicionamiento, la dirección que queremos tomar. En esos casos hace falta un product manager. Hace falta criterio. A veces hay que decir que no, a veces arbitrar, a veces asumir una orientación.

Pero muchas preguntas no son de ese orden.

Hablan del comportamiento real del producto.

Una regla. Un límite. Una excepción. Una restricción. Un caso de uso. Una configuración. La interacción entre dos funcionalidades.

Y ahí, en teoría, responder debería ser sencillo.

El problema es que no siempre lo es.

El coste oculto de la pregunta de producto

Cuando la pregunta hila fino, no siempre basta con abrir la documentación.

Primero, porque la documentación no siempre existe.

Después, porque a veces sí existe, pero no sabes si sigue estando al día.

Y por último, porque la pregunta de verdad suele apuntar a un caso límite que nadie ha documentado de forma explícita.

Así que haces lo que hacemos todos —PM, CSM, soporte, desarrollo— cuando tenemos una duda: probar.

Abres un entorno de test.

Preparas un juego de datos.

Reproduces el escenario.

Compruebas si el producto bloquea, acepta, calcula, muestra, oculta, dispara, envía o rechaza.

Y se te ha ido media hora.

A veces una hora.

A veces más.

Ese tiempo no aparece en ninguna parte. No está en Jira. No está en la roadmap. No está en las estimaciones. Sencillamente lo absorbe el funcionamiento normal de la organización.

Y hay otro coste, todavía más invisible: el cambio de contexto.

La pregunta casi nunca llega en buen momento. Llega porque un cliente está esperando. Porque un comercial está en una reunión. Porque un CSM está preparando un seguimiento. Porque soporte tiene que contestar antes de que acabe el día.

Así que interrumpes lo que estabas haciendo. Entras en el tema. Pruebas. Respondes. Y luego intentas volver a donde estabas.

No es solo una pérdida de tiempo. Es una pérdida de continuidad intelectual.

Y es justo el tipo de tarea que la IA debería absorber.

El problema no es la pregunta. Es la fuente.

Se podría contestar que basta con tener mejor documentación.

En teoría, sí.

En la práctica, no.

Una documentación de producto va casi siempre por detrás del producto real. No es un problema de disciplina individual. No es solo que alguien haya olvidado actualizar una página.

Es algo más estructural.

Una especificación describe una intención. Un PRD describe un objetivo, unas reglas esperadas, unos escenarios. Una maqueta describe la interfaz deseada. Pero entre esa intención y la producción siempre pasa algo.

Se hacen concesiones.

Se ajustan detalles.

Aparecen casos límite.

Se toman decisiones durante el desarrollo.

Hay restricciones técnicas que obligan a modificar ligeramente el comportamiento.

Hay conversaciones dentro de una pull request o de una merge request.

Y hay arbitrajes que no siempre llegan de vuelta a la documentación inicial.

Nada de esto es necesariamente grave. Hasta es bastante normal. Un producto vivo no se construye como un documento congelado.

Pero tiene una consecuencia muy simple: la especificación no es la verdad del producto.

Es una aproximación útil en un momento dado.

La verdad es lo que está en ejecución.

Y lo que está en ejecución es el código.

El código como fuente de verdad del producto

La producción es la realidad.

No la especificación.

No el PRD.

No la página de Notion.

No lo que el PM recuerda.

No la conversación de Slack de hace tres semanas.

Para saber cómo se comporta el producto de verdad hay que mirar lo que está desplegado. Y lo que está desplegado lo sostiene el código fuente.

Dicho así puede sonar brutal. Podría parecer que estoy diciendo: "tirad toda la documentación".

No es esa la idea.

La distinción correcta no está entre "código" y "documentación".

La distinción correcta está entre lo que explica y lo que describe.

Lo que explica se conserva.

Lo que describe se regenera.

Los Contextos deben conservarse. Contienen las conversaciones, las fuentes, los razonamientos, las ideas que llevaron hasta una elección. Son bloques reutilizables.

Las decisiones deben conservarse. Cuando una empresa elige una dirección, hay que guardar el porqué. ¿Por qué esta elección? ¿Qué alternativas se descartaron? ¿Por qué esta decisión sustituye a una anterior?

Ese es el papel de los Product Decision Records, los PDR. Ya he escrito sobre ello: un PDR no describe una funcionalidad, deja rastro de una decisión de producto estructurante.

Hay restricciones que también deben seguir accesibles: contractuales, regulatorias, documentos externos, compromisos concretos. No todo se puede deducir del código.

Pero la documentación que describe el comportamiento del producto debería regenerarse desde el código siempre que sea posible.

Porque el código es la verdad del comportamiento implementado.

Lo que la IA hace posible

Hasta ahora, esta idea chocaba con un límite evidente.

El código es código.

No siempre resulta legible para soporte. No siempre lo leen los comerciales. No siempre lo lee un C-level. Ni siquiera lo lee siempre con facilidad un PM, sobre todo si no tiene cultura técnica.

Durante mucho tiempo hizo falta, por tanto, una capa intermedia. Especificaciones. Documentos de soporte. Páginas de producto. Changelogs. Tablas. Esquemas.

La IA cambia esa ecuación.

Puede convertirse en la interfaz entre una pregunta de negocio y el código fuente.

Alguien de soporte puede preguntar: "¿Qué ocurre si el cliente cancela este elemento después de validarlo?"

Un CSM puede preguntar: "¿En qué condiciones se bloquea este flujo?"

Un comercial puede preguntar: "¿Podemos prometerle esta configuración a este cliente potencial?"

Un PM puede preguntar: "¿Dónde está implementada esta regla y qué casos se quedan fuera?"

Y la IA puede ir a buscar en el código, en el historial de Git, en las merge requests, en los feature flags, en los contextos de negocio, y producir después una respuesta comprensible.

No una respuesta mágica.

Una respuesta anclada.

Una buena respuesta de producto debe enseñar sus pruebas

El punto clave está ahí.

Si la IA responde sin pruebas, se convierte en una nueva documentación aproximada. Más rápida, más elegante, pero no necesariamente más fiable.

Hay que obligarla, entonces, a anclar su respuesta.

Cuando afirme que una regla existe, tiene que decir por qué.

No solo: "el producto funciona así".

Sino: "el producto funciona así porque esta función aplica esta regla, porque esta excepción bloquea este caso, porque esta merge request introdujo este comportamiento, porque este test cubre este escenario".

Las pruebas no tienen por qué ocupar el centro de la respuesta. Para soporte o para los comerciales pueden ir al final del documento. No todo el mundo necesita leer el detalle técnico.

Pero tienen que existir.

Su presencia cambia el comportamiento de la IA. Ya no puede responder solo por verosimilitud. Tiene que enganchar sus afirmaciones a elementos factuales.

Es la misma lógica que en un análisis de texto. Si le pido a una IA que analice un corpus, prefiero que me dé, para cada conclusión, la frase o el párrafo en el que se apoya. Eso reduce muchísimo las alucinaciones.

Con una pregunta de producto pasa lo mismo.

La prueba puede ser un fichero.

Una función.

Una excepción.

Un test.

Un commit.

Una merge request.

Una pull request.

Un feature flag.

Una decisión de producto.

Una fuente de negocio.

Sin eso, lo único que hacemos es mover el problema de sitio. Sustituimos la memoria imperfecta del PM por la memoria probabilística de un modelo.

Y no basta.

También hay que decir lo que no se sabe

Una buena respuesta de producto no debe limitarse a responder.

Tiene que decir además dónde se atasca.

Es una directriz esencial.

La IA tiene que poder escribir:

"No he encontrado ningún test que cubra este caso."

"El código muestra dos comportamientos posibles según el estado del feature flag."

"No puedo determinar el comportamiento exacto para este cliente sin acceder a su configuración."

"El PDR indica una regla, pero el código parece implementar otra cosa."

"La documentación de soporte actual contradice el comportamiento que se observa en el código."

Es incómodo, pero es valioso.

Una persona seria hace exactamente lo mismo. Cuando no sabe, lo dice. Cuando tiene una duda, la señala. Cuando hay que probar, prueba.

El objetivo no es hacer creer que la IA lo sabe todo.

El objetivo es reducir el coste de buscar y, a la vez, aumentar la trazabilidad.

No todos los públicos necesitan la misma lectura

Una pregunta de producto puede interesar a varios equipos.

Soporte suele querer una respuesta que pueda usar delante del cliente.

El CSM quiere entender el uso y los impactos.

Los comerciales quieren saber qué pueden prometer y qué valor poner por delante.

El PM quiere verificar la regla, el límite, la excepción.

La dirección puede querer entender lo que está en juego a nivel estratégico.

Podríamos imaginar, entonces, una respuesta distinta para cada público.

Pero no hace falta necesariamente.

Una misma respuesta puede estructurarse en varios ángulos. Una parte corta que responda a la pregunta. Una parte de soporte. Una parte de uso. Una parte de valor. Una parte de límites. Una parte de pruebas.

Cada cual lee lo que necesita.

Y a veces viene bien justamente eso: que un comercial vea un límite del producto, o que un CSM entienda el origen técnico de un comportamiento. Depende de la cultura de la empresa. Hay organizaciones que prefieren restringir la información. Otras ganan madurez compartiéndola.

No es una cuestión puramente técnica.

Es una cuestión de cultura.

Los bloques necesarios

Técnicamente, no basta con enchufar un LLM a un repositorio Git y esperar que todo funcione.

Hay varias herramientas que se complementan.

El RAG permite recuperar los fragmentos adecuados. Suele ser muy eficaz para hacer emerger las piezas pertinentes dentro de una gran masa documental o de un código voluminoso.

Pero el RAG no siempre basta. Recupera. No necesariamente viaja.

Un grafo semántico puede ayudar a explorar los elementos cercanos: conceptos relacionados, módulos vecinos, reglas conectadas, eventos que disparan otros eventos.

Recorrer el filesystem también sigue siendo imprescindible. Cuando ya has identificado una zona, a veces hay que leer el directorio, abrir los ficheros de al lado, entender la estructura local. Es menos elegante que una búsqueda vectorial, pero a menudo funciona muy bien.

Git aporta otra dimensión: el tiempo.

El código actual dice lo que existe. El historial dice cómo se llegó hasta ahí. Los commits, las pull requests o las merge requests pueden revelar la intención, las conversaciones, las concesiones, las correcciones.

Los feature flags añaden otro matiz. El código puede contener varios comportamientos posibles. El comportamiento real depende entonces del estado del flag.

Si la IA no tiene acceso a ese estado, debe responder de forma condicional: si el flag está activado, el comportamiento es este; si no, es otro.

Si tiene acceso al entorno, puede ir más lejos: para este cliente concreto, en esta configuración concreta, el comportamiento activo es este.

Este paso es importante. La pregunta de producto no siempre habla del código en abstracto. A veces habla del producto tal y como lo vive un cliente concreto.

La condición: un código que hable de negocio

Hay, eso sí, una condición de partida.

El código tiene que representar el negocio.

Si el código es un plato de espaguetis, si los conceptos de negocio están escondidos detrás de nombres técnicos, si las reglas andan dispersas, si las excepciones no llevan el vocabulario del dominio, la IA lo tendrá difícil.

Pero eso no es un límite nuevo.

Un desarrollador humano también lo tendrá difícil.

Un PM técnico también lo tendrá difícil.

Un equipo que quiera hacer evolucionar el producto también lo tendrá difícil.

Un código que no representa el negocio no es buen código. Impone de forma permanente una traducción entre la necesidad de negocio y la mecánica del software. Cada evolución obliga a reconstruir mentalmente ese vínculo. Cada depuración sale más cara. Cada regla cuesta más encontrar.

Por eso mismo existen desde hace mucho enfoques como el DDD. La idea no nació con la IA.

La IA se limita a hacer esa exigencia más visible.

Si queremos interrogar el código como fuente de verdad del producto, el código tiene que hablar el lenguaje del producto.

Las entidades deben llevar los nombres del negocio.

Las acciones deben leerse sin esfuerzo.

Los eventos deben contar lo que ha ocurrido.

Las excepciones deben expresar reglas, no solo errores técnicos.

Las políticas deben hacer visibles las reacciones en cadena.

Los módulos deben tener una estructura previsible.

Una excepción como ElementAnnuléNonModifiable no es solo un mensaje de error. Es una regla de negocio escrita en código.

Ese es el tipo de código que se vuelve interrogable.

No porque la IA sea mágica.

Porque el negocio ya está presente en la materia que lee.

De la respuesta puntual a la documentación regenerada

Responder a una pregunta de Slack es el primer caso de uso.

Pero no es el único.

Si podemos responder a una pregunta de producto desde el código, también podemos regenerar una parte de la documentación de producto.

Podemos producir una FAQ de soporte.

Actualizar un artículo vivo sobre una funcionalidad.

Generar un changelog.

Reconstruir una especificación a partir del estado actual del producto.

Producir una documentación comercial más fiable sobre lo que se puede prometer y lo que no.

La lógica es siempre la misma: no mantener a mano artefactos que describen el comportamiento real si ese comportamiento puede reconstruirse desde la fuente de verdad.

Las especificaciones no desaparecen del todo.

Cambian de estatus.

Antes de la producción sirven para dialogar.

Permiten discutir, explorar, acotar, decidir.

Después de la producción ya no deben presentarse como la verdad duradera del producto.

Pasan a ser regenerables.

Esto no es una regla religiosa

Conviene, evidentemente, guardar algo de pragmatismo.

No todas las empresas pueden aplicar esto al milímetro.

Algunas arrastran un histórico documental pesado.

Algunas tienen un legacy difícil.

Algunas tienen restricciones regulatorias fuertes.

Algunas todavía no tienen suficiente cultura técnica.

Algunas tienen decisiones de producto mal registradas.

Algunas no pueden exponer la misma información a todos los equipos.

Así que no se trata de decir: mañana por la mañana, borrad toda vuestra documentación.

Sería absurdo.

Se trata de desplazar el centro de gravedad.

Dejar de considerar la documentación descriptiva como la fuente de verdad.

Dejar de pedirle al PM que verifique a mano, una y otra vez, lo que el producto ya hace.

Dejar de mantener a mano artefactos que divergen de forma mecánica.

Y empezar a construir un sistema donde el código, las decisiones, los Contextos y las fuentes dialoguen entre sí.

Algo más que un método de producto

En el fondo, la pregunta de producto no es más que un caso particular.

Revela una transformación mucho más amplia.

Durante mucho tiempo, el sistema de información de la empresa estuvo hecho de bases de datos, bases documentales, wikis, tickets, tablas, dosieres y documentos.

Buscábamos.

Leíamos.

Copiábamos.

Actualizábamos.

Olvidábamos.

Con la IA podemos empezar a hacer otra cosa.

Podemos dialogar con el sistema de información.

Podemos hacer una pregunta.

Podemos pedir una prueba.

Podemos explorar las ideas cercanas.

Podemos remontar el historial.

Podemos detectar una contradicción.

Podemos regenerar un artefacto.

La pregunta de producto es una buena puerta de entrada porque es concreta. Cuesta tiempo todos los días. Interrumpe el trabajo. Deja al descubierto la divergencia entre la documentación y la producción.

Pero detrás de ella el tema es más profundo.

No se trata solo de ayudar a soporte a responder más rápido.

Se trata de hacer que la empresa sea interrogable desde sus fuentes de verdad.

Y en el caso del producto, la fuente real del comportamiento es el código.