Escrito originalmente en francés. Traducido por IA — se ha preservado el sentido, no la prosa.
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 real de campo.
¿Podemos hacer esto?
¿Qué pasa 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 aquí el producto?
¿Podemos prometerle esto al cliente?
Algunas de estas preguntas son estratégicas. Exigen comprender el mercado, el cliente, el posicionamiento, la dirección que queremos tomar. En esos casos, hace falta un product manager. Hace falta un juicio. A veces hay que decir no, a veces arbitrar, a veces asumir una orientación.
Pero muchas preguntas no son de ese tipo.
Tratan sobre el comportamiento real del producto.
Una regla. Un límite. Una excepción. Una restricción. Un caso de uso. Una configuración. Una interacción entre dos funcionalidades.
Y ahí, en teoría, la respuesta debería ser simple.
El problema es que no siempre lo es.
El coste oculto de la pregunta de producto
Cuando la pregunta es precisa, no siempre basta con abrir la documentación.
Primero porque la documentación no siempre existe.
Luego porque a veces existe, pero no se sabe si sigue estando actualizada.
Por último porque la pregunta real trata a menudo de un caso límite que nadie ha documentado explícitamente.
Entonces se hace lo que hacen todos los PM, CSM, equipos de soporte o desarrolladores cuando tienen una duda: se prueba.
Se abre un entorno de prueba.
Se prepara un juego de datos.
Se reproduce el escenario.
Se comprueba si el producto bloquea, acepta, calcula, muestra, oculta, dispara, envía, rechaza.
Y ha pasado media hora.
A veces una hora.
A veces más.
Este tiempo no aparece en ningún sitio. No está en Jira. No está en el roadmap. No está en las estimaciones. Simplemente es absorbido por el funcionamiento normal de la organización.
Hay también otro coste, aún más invisible: el cambio de contexto.
La pregunta llega raramente en el momento adecuado. Llega porque un cliente espera. Porque un comercial está en una reunión. Porque un CSM prepara un punto. Porque el soporte debe responder antes de final del día.
Así que se interrumpe lo que se estaba haciendo. Se entra en un tema. Se prueba. Se responde. Y luego se intenta volver a lo de antes.
No es solo una pérdida de tiempo. Es una pérdida de continuidad intelectual.
Y es precisamente el tipo de tarea que la IA debería absorber.
El problema no es la pregunta. Es la fuente.
Se podría responder: basta con tener una mejor documentación.
En teoría, sí.
En la práctica, no.
Una documentación de producto casi siempre va por detrás del producto real. No es un problema de disciplina individual. No es solo porque alguien se olvidó de actualizar una página.
Es más estructural.
Una especificación describe una intención. Un PRD describe un objetivo, reglas esperadas, escenarios. Una maqueta describe una interfaz deseada. Pero entre esa intención y la producción, siempre pasa algo.
Se hacen compromisos.
Se ajustan detalles.
Aparecen casos límite.
Se toman decisiones durante el desarrollo.
Las restricciones técnicas obligan a modificar ligeramente el comportamiento.
Se producen intercambios en una pull request o una merge request.
Los arbitrajes no siempre suben a la documentación inicial.
Eso no es necesariamente grave. Es incluso bastante normal. Un producto vivo no se construye como un documento fijo.
Pero crea una consecuencia 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 de producto
La producción es la realidad.
No la especificación.
No el PRD.
No la página de Notion.
No el recuerdo del PM.
No la conversación de Slack de hace tres semanas.
Para saber cómo se comporta realmente el producto, hay que mirar lo que está entregado. Y lo que está entregado está soportado por el código fuente.
Dicho así, puede parecer brutal. Podría creerse que equivale a decir: "tira toda la documentación".
No es esa la idea.
La distinción correcta no es entre "código" y "documentación".
La distinción correcta es entre lo que explica y lo que describe.
Se conserva lo que explica.
Se regenera lo que describe.
Los contextos deben conservarse. Contienen las discusiones, las fuentes, los razonamientos, las ideas que permitieron llegar a 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 reemplaza a una anterior?
Es el papel de los Product Decision Records, los PDR. Ya he escrito sobre este tema: un PDR no describe una funcionalidad, traza una decisión de producto estructurante.
Ciertas restricciones también deben seguir siendo accesibles: restricciones contractuales, reglamentarias, documentos externos, compromisos específicos. No todo puede deducirse del código.
Pero la documentación que describe el comportamiento del producto debería, en la medida de lo posible, regenerarse desde el código.
Porque el código es la verdad del comportamiento implementado.
Lo que la IA hace posible
Hasta aquí, esta idea tenía un límite evidente.
El código es código.
No siempre es legible para el soporte. No siempre es legible para los comerciales. No siempre es legible para un directivo. Ni siquiera siempre es fácilmente legible para un PM, sobre todo si no tiene cultura técnica.
Durante mucho tiempo, hacía falta una capa intermedia. Especificaciones. Documentos de soporte. Páginas de producto. Changelogs. Tablas. Esquemas.
La IA cambia esta ecuación.
Puede convertirse en la interfaz entre una pregunta de negocio y el código fuente.
Un equipo de soporte puede preguntar: "¿Qué pasa si el cliente cancela este elemento después de la validación?"
Un CSM puede preguntar: "¿En qué condiciones se bloquea este workflow?"
Un comercial puede preguntar: "¿Podemos prometerle esta configuración a este prospecto?"
Un PM puede preguntar: "¿Dónde está implementada esta regla y qué casos no están cubiertos?"
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 una respuesta comprensible.
No una respuesta mágica.
Una respuesta anclada.
Una buena respuesta de producto debe mostrar sus pruebas
El punto clave está ahí.
Si la IA responde sin pruebas, se convierte en una nueva documentación aproximativa. Más rápida, más elegante, pero no necesariamente más fiable.
Hay que, pues, obligar a la IA a anclar su respuesta.
Cuando afirma que existe una regla, debe decir por qué.
No solo: "el producto funciona así".
Sino: "el producto funciona así porque tal función aplica esta regla, porque tal excepción bloquea este caso, porque tal merge request introdujo este comportamiento, porque tal test cubre este escenario".
Las pruebas no tienen que estar necesariamente en el centro de la respuesta. Para el soporte o los comerciales, pueden estar al final del documento. No todo el mundo necesita leer los detalles técnicos.
Pero deben existir.
Su presencia cambia el comportamiento de la IA. Ya no puede responder solo por verosimilitud. Debe vincular 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 que se apoya. Eso limita mucho las alucinaciones.
Para una pregunta de producto, es igual.
La prueba puede ser un archivo.
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, solo se desplaza el problema. Se reemplaza la memoria imperfecta del PM por la memoria probabilista de un modelo.
No es suficiente.
Hay que decir también lo que no se sabe
Una buena respuesta de producto no debe solo responder.
También debe decir dónde bloquea.
Es una directriz esencial.
La IA debe 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 observado en el código."
Es incómodo, pero es valioso.
Un humano serio hace lo mismo. Cuando no sabe, lo dice. Cuando tiene una duda, la señala. Cuando debe probar, prueba.
El objetivo no es hacer creer que la IA lo sabe todo.
El objetivo es reducir el coste de búsqueda, aumentando al mismo tiempo la trazabilidad.
No todos los públicos necesitan la misma lectura
Una pregunta de producto puede interesar a varios roles.
El soporte quiere a menudo una respuesta explotable frente al cliente.
El CSM quiere entender el uso y los impactos.
Los comerciales quieren saber qué pueden prometer, y qué valor destacar.
El PM quiere verificar la regla, el límite, la excepción.
La dirección puede querer entender el reto estratégico.
Podría imaginarse, pues, una respuesta diferente para cada público.
Pero no es necesariamente necesario.
Una misma respuesta puede estructurarse en varios ángulos. Una parte corta para responder 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 uno lee lo que necesita.
Y a veces es precisamente útil que un comercial vea un límite del producto o que un CSM comprenda el origen técnico de un comportamiento. Depende de la cultura de la empresa. Algunas organizaciones prefieren limitar la información. Otras ganan en 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 conectar un LLM a un repositorio de Git y esperar que todo funcione.
Varias herramientas son complementarias.
RAG permite recuperar los fragmentos correctos. A menudo es muy eficaz para hacer emerger las piezas relevantes en una gran masa documental o en un código voluminoso.
Pero RAG no siempre es suficiente. Recupera. No necesariamente navega.
Un grafo semántico puede ayudar a explorar los elementos cercanos: conceptos relacionados, módulos vecinos, reglas conectadas, eventos que desencadenan otros eventos.
El recorrido del sistema de archivos sigue siendo también indispensable. Cuando se ha identificado una zona, a veces hay que leer el directorio, abrir los archivos cercanos, entender la estructura local. Es menos elegante que una búsqueda vectorial, pero a menudo muy eficaz.
Git aporta otra dimensión: el tiempo.
El código actual dice lo que existe. El historial dice cómo se llegó ahí. Los commits, las pull requests o las merge requests pueden revelar la intención, las discusiones, los compromisos, 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 condicionalmente: si el flag está activado, entonces el comportamiento es este; si no, es diferente.
Si tiene acceso al entorno, puede ir más lejos: para este cliente preciso, en esta configuración precisa, el comportamiento activo es ese.
Este paso es importante. La pregunta de producto no siempre trata sobre el código abstracto. A veces trata sobre el producto tal como lo vive un cliente concreto.
La condición: un código que habla el lenguaje del negocio
Hay, sin embargo, una condición de base.
El código debe representar el negocio.
Si el código es un plato de espaguetis, si los conceptos de negocio están ocultos detrás de nombres técnicos, si las reglas están dispersas, si las excepciones no llevan el vocabulario del dominio, entonces la IA tendrá dificultades.
Pero eso no es un límite nuevo.
Un desarrollador humano también tendrá dificultades.
Un PM técnico también tendrá dificultades.
Un equipo que quiera hacer evolucionar el producto también tendrá dificultades.
Un código que no representa el negocio no es buen código. Impone permanentemente una traducción entre la necesidad de negocio y la mecánica del software. Cada evolución exige reconstruir mentalmente ese vínculo. Cada debug se vuelve más costoso. Cada regla es más difícil de encontrar.
Es exactamente por eso que enfoques como DDD existen desde hace mucho tiempo. La idea no nació con la IA.
La IA simplemente hace esta exigencia más visible.
Si se quiere interrogar el código como fuente de verdad de producto, el código debe hablar el lenguaje del producto.
Las entidades deben llevar los nombres del negocio.
Las acciones deben ser legibles.
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 cascada.
Los módulos deben tener una estructura predecible.
Una excepción como ElementoCanceladoNoModificable no es solo un mensaje de error. Es una regla de negocio escrita en código.
Es ese tipo de código el que se vuelve interrogable.
No porque la IA sea mágica.
Sino porque el negocio ya está presente en el contenido 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 se puede responder a una pregunta de producto desde el código, también se puede regenerar parte de la documentación de producto.
Se puede producir una FAQ de soporte.
Actualizar un artículo vivo sobre una funcionalidad.
Generar un changelog.
Reconstituir una especificación a partir del estado actual del producto.
Producir una documentación comercial más fiable sobre lo que puede o no prometerse.
La lógica es siempre la misma: no mantener manualmente artefactos que describen el comportamiento real si ese comportamiento puede reconstruirse desde la fuente de verdad.
Las especificaciones no desaparecen del todo.
Cambian de estatuto.
Antes de la producción, sirven para el diálogo.
Permiten discutir, explorar, encuadrar, decidir.
Después de la producción, ya no deben pretender ser la verdad duradera del producto.
Se vuelven regenerables.
No es una regla religiosa
Hay que mantener, evidentemente, algo de pragmatismo.
No todas las empresas pueden aplicar esto al milímetro.
Algunas tienen un historial documental pesado.
Algunas tienen un legacy difícil.
Algunas tienen restricciones reglamentarias fuertes.
Algunas no tienen todavía una cultura técnica suficiente.
Algunas tienen decisiones de producto mal trazadas.
Algunas no pueden exponer la misma información a todos los roles.
No se trata, pues, de decir: mañana por la mañana, elimina toda tu documentación.
Sería absurdo.
Se trata de cambiar el centro de gravedad.
Dejar de considerar la documentación descriptiva como la fuente de verdad.
Dejar de pedirle al PM que verifique manualmente, una y otra vez, lo que el producto ya hace.
Dejar de mantener manualmente artefactos que divergen mecánicamente.
Y empezar a construir un sistema donde el código, las decisiones, los contextos y las fuentes dialoguen.
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 más amplia.
Durante mucho tiempo, el sistema de información de la empresa ha estado compuesto por bases de datos, bases documentales, wikis, tickets, tablas, carpetas, documentos.
Se buscaba.
Se leía.
Se copiaba.
Se actualizaba.
Se olvidaba.
Con la IA, se puede empezar a hacer otra cosa.
Se puede dialogar con el sistema de información.
Se puede hacer una pregunta.
Se puede pedir una prueba.
Se puede explorar las ideas cercanas.
Se puede remontar el historial.
Se puede detectar una contradicción.
Se puede regenerar un artefacto.
La pregunta de producto es un buen punto de entrada porque es concreta. Cuesta tiempo todos los días. Interrumpe el trabajo. Revela la divergencia entre documentación y producción.
Pero detrás de ella, el tema es más profundo.
No se trata solo de ayudar al soporte a responder más rápido.
Se trata de hacer que la empresa sea interrogable desde sus verdaderas fuentes.
Y en el caso del producto, la verdadera fuente del comportamiento es el código.
Para saber más
Code centric Product Decision Record: documentar las decisiones de producto que estructuran la empresa Wiki IA: por qué construí una base de conocimiento mantenida por una IA