AI intro 8 - Documentación de producto con IA

Documento elaborado por una persona

Prosa normalizada a partir de la transcripción original de la llamada. Para la lección se utilizó únicamente el fragmento relevante sobre el trabajo con documentos de producto, Markdown, Codex, transcripciones y Neuronet.

Hay personas que ya escriben en formato Markdown, más adecuado para la IA: para tener la gran posibilidad de crear en su Codex o Claude Code bases de conocimiento para cada área de su producto, y para que los modelos de IA puedan leer esta base de conocimiento correctamente, buscar en los documentos y usarlos como contexto.

Y existe un enfoque más orientado al producto: Confluence, donde los documentos se escriben ante todo para las personas, para que las personas los lean. Es decir, Confluence lleva mucho tiempo utilizándose como una base de conocimiento humana, mientras que Markdown se está convirtiendo gradualmente en un formato conveniente para el trabajo AI Native.

Aquí es importante entender que antes ya probamos prácticamente todos los formatos de documentación de producto: MS Office, BaseCamp, Notion, Google Docs, Confluence, documentos con imágenes, documentos con flechas en las capturas de pantalla, vídeo, Loom, etcétera. En algún momento Loom se convirtió en la cima de la evolución: no solo escribes texto, sino que explicas y al mismo tiempo muestras en pantalla lo que está ocurriendo. En el formato Loom es sumamente conveniente hacer presentaciones de productos, grabar ideas, explicar tareas y crear instrucciones.

Pero Loom y Google Meet tienen un problema común: las personas hablaron, alguien vio la grabación, alguien no la vio, alguien entendió algo, alguien no lo entendió o lo olvidó, y después de pasar un rato agradable todos se dispersaron. Para un trabajo de producto eficaz, este enfoque no es suficiente. La conversación por sí sola no se convierte en conocimiento sostenible que todos los miembros del equipo puedan reutilizar en cualquier momento.

Paralelamente apareció la IA, y las personas aprendieron a generar documentos. Esto llevó a otro problema: AI slop. Se generan kilómetros de texto que nadie quiere leer. Incluso antes era difícil lograr que la gente leyera documentos grandes comunes, hechos por personas; ahora se ha vuelto aún peor: una persona ve un texto de AI slop, entiende desde el primer párrafo que fue generado por un modelo y no quiere leerlo ni gastar tiempo en ello. Resulta que la IA sabe producir texto, pero el trabajo de producto no mejora automáticamente por ello.

La cuestión en realidad es otra: cómo alimentar correctamente a la IA con documentos para que realmente ayude a llevar el trabajo de producto. Los documentos siguen siendo necesarios. Pero deben estar organizados de tal manera que el modelo de IA pueda buscar en ellos, responder, recopilar contexto y ayudar a las personas nuevas a incorporarse rápidamente al proyecto.

Mi experiencia sencilla es la siguiente: el trabajo de producto vive en Codex como una carpeta Product. Un principio muy importante: el proyecto en Codex debe estar vinculado a una carpeta real en el disco local. Es decir, creo en mi equipo una carpeta Codex, dentro de ella la carpeta Product, y luego en Codex creo un proyecto mediante existing folder e indico esta carpeta local. Se obtiene una conexión sencilla: el proyecto en Codex equivale a una carpeta en el disco local.

El siguiente paso, para sincronizar entre sí sus carpetas locales dentro del equipo, es crear una estructura Git en su proyecto Product y subir las actualizaciones a GitHub del equipo después de cada sesión de trabajo. Los demás miembros del equipo actualizan sus carpetas locales antes de comenzar a trabajar y hacen commits en el GitHub común al crear actualizaciones o nuevos documentos. Más o menos así trabajan los desarrolladores al actualizar código.

Después, la magia comienza con la organización de su carpeta Product por chats separados, que también se denominan agentes. Crean en su carpeta Product muchos chats para cada tema de producto que necesiten en el trabajo. No hay reglas aquí: pueden usar como tema los kickoffs con stakeholders, o los syncs con el equipo, o los syncs con otros equipos. Por ejemplo, tenemos un documento PRD. Creo un chat separado (agente) para el PRD y empiezo a colocar allí todos los materiales fuente relacionados con el trabajo de producto sobre el PRD. De este modo cargan toda la información fuente en este chat, y AI Codex ahora conoce todo lo necesario sobre el contexto del trabajo en sus documentos PRD.

¿Y qué materiales fuente tenemos con mayor frecuencia al comienzo? En primer lugar, Google Meet, es decir, las conversaciones de las reuniones de trabajo. Vino Shurick, realizó un kickoff, asignó una tarea. Después debatimos la tarea con el equipo, y aparecen varios Google Meet como fuente primaria. Información de muy alta calidad, porque procede de primera mano.

Si aparece un tema nuevo, por ejemplo PlayCanvas, creo un nuevo chat (agente) en la carpeta Product y escribo directamente: aquí haremos todo el trabajo de producto sobre PlayCanvas. Después de crearlo, asegúrense de renombrar el chat correctamente y de forma breve, para que quede claro en qué se trabaja allí. Es importante no simplemente almacenar archivos MD en Codex, sino crear un espacio de trabajo normal donde Codex entienda con qué tema estamos trabajando ahora.

Para transcribir Google Meet utilizo la mini-app Command Center. En Xsolla existe una cultura de mini-apps y prototipos de diseño: mediante Neuronet se puede hacer vibe coding de una automatización para su proceso interno. Uso Command Center precisamente para convertir Google Meet en transcripciones en el formato que necesito.

Antes el trabajo era diferente: había que grabar el kickoff, luego revisarlo uno mismo, estudiarlo a fondo, extraer lo importante y reunir un documento. Todavía trabajo manualmente con los kickoffs importantes de Shurick, porque la prioridad es alta, pero para decenas de llamadas cada semana el propio proceso de tratamiento ha cambiado. Ahora se puede tomar la transcripción de una reunión de una hora en formato MD, cargarla en el proyecto y chat de Codex necesarios, dar contexto al agente local y pedirle: dame un resumen solo respecto al tema que necesito. Si durante la reunión se discutieron muchas cosas y para mí solo es importante una parte, el agente ayuda a extraer rápidamente precisamente la parte relevante. Esto ahorra una enorme cantidad de tiempo. Todo funciona en tres clics: transcribimos, añadimos el archivo MD a Codex, dictamos un minuto de contexto y la tarea de procesamiento, obtenemos un resultado listo en un archivo MD o directamente en Confluence mediante Skill.

Para esto tengo conectado Google Calendar en Command Center. Puedo tomar reuniones, transcribirlas, convertirlas en Markdown y luego distribuirlas entre los agentes relevantes de la carpeta Codex del proyecto Product. Estos archivos MD se convierten en la capa fuente de información: no en un documento bonito por el documento en sí, sino en material que se puede cargar en el chat relevante del agente Codex, obtener un archivo MD procesado y ponerlo después en marcha: transferirlo a Neuronet, usarlo para formar PRD, decisiones de arquitectura, answers y otros artefactos de producto.

El objetivo importante aquí no es simplemente hacer muchos archivos Markdown de moda. El objetivo es que todo el equipo trabaje con la misma información. Y no solo el equipo, sino toda la empresa: dentro de la empresa hay muchas personas que pueden preguntar a Neuronet algo sobre Metasites. Si tomamos las mejores respuestas, PRD, decisiones de arquitectura, transcripciones, answers y le decimos a Neuronet: carga y actualiza toda la información sobre Metasites, entonces memoriza esta capa y posteriormente puede responder basándose en ella.

Como resultado, obtenemos una base de conocimiento informativa clara: documentos, decisiones de arquitectura, PRD, cuestionarios, answers, PRD adicionales y otros materiales. Esto es importante porque los stakeholders, la alta dirección, los socios, los desarrolladores de juegos y otros participantes del proceso hacen preguntas a Neuronet. Si alguien necesita averiguar algo, puede no escribir por privado a una de las personas de producto, sino preguntarle a Neuronet desde la base de IA común de la empresa.

Así logramos un gran objetivo: las 1600 personas obtienen acceso a la misma información. Antes de la IA, estos procesos a menudo funcionaban como el teléfono descompuesto: siete personas hablaron, decidieron algo y los demás no están al tanto. En los equipos grandes es un problema clásico. Cuanto más avanza la cadena de transmisión de información, mayor es la brecha entre quienes idearon el producto y quienes luego deben trabajar con él.

Los archivos Markdown, Codex y Neuronet ayudan a crear una capa de información fuente accesible para todos. Además, cualquier persona puede tomar un conjunto de estos archivos MD como Source of Truth, cargarlos en su propio Codex o Claude Code y encontrarse al 100% en el mismo contexto que el equipo principal de producto. Esto es especialmente importante para los nuevos participantes del proyecto: una persona puede instalar Codex, crear un proyecto, cargar allí los materiales y empezar a preguntar: qué está ocurriendo, qué decisiones ya se tomaron, dónde está la North Star, qué PRD existen, qué discusiones hubo en el kickoff.

Por eso intento almacenar toda la información sobre Metasites en Markdown. Esto es necesario no solo para los product managers, sino también para los desarrolladores. Los desarrolladores se resisten más a los nuevos procesos de IA, pero aun así es importante que incluso el desarrollador más alejado del producto entienda la North Star del proyecto y vea hacia dónde vamos. No solo tres personas de producto deben saber cuál es nuestra tarea y qué ideas hemos concebido; todo el equipo debe tener acceso a la visión general.

También cargo estos mismos archivos MD y pido a Neuronet que los memorice. De este modo resolvemos nuestros problemas de producto y, al mismo tiempo, difundimos su solución a toda la empresa. Obtenemos no simplemente un conjunto de documentos, sino una capa común AI-readable: las personas pueden leerla, se puede cargar en Codex, se pueden hacer preguntas sobre ella en Neuronet, y a partir de ella se pueden reunir PRD y otros documentos de trabajo.

AI intro 8 - Documentos de producto - Objetivos y respuestas

Source of Truth

Ahora viene un bloque importante: qué hacer después de añadir al chat o agente de Codex necesario el nombre del documento y cargar allí todos los materiales fuente. Los materiales fuente pueden ser archivos Markdown, documentos de Confluence, PRD antiguos, transcripciones, respuestas de debates y cualquier otro documento relacionado con este tema. Simplemente cargarlos no es suficiente. Después hay que establecer un objetivo.

Best Practice

El objetivo se formula de forma muy directa: busca, por favor, en Confluence las best practice para el documento que necesitamos. Por ejemplo, si queremos crear un PRD, un documento de arquitectura, una especificación de tarea para desarrollo u otro artefacto de producto, pedimos a Codex que encuentre las best practice corporativas específicamente para este tipo de documento. Codex busca qué requisitos existen, cómo se acostumbra a hacer este documento en la empresa, qué secciones son obligatorias, qué criterios de calidad existen, qué ejemplos ya existen.

Después de esto, Codex debe explicarnos cómo hacer correctamente este documento de acuerdo con los requisitos corporativos. Este es un paso importante, porque no queremos que la IA simplemente invente una estructura bonita de su cabeza. Necesitamos que el futuro documento se apoye en el formato corporativo real, en las best practice adoptadas y en la forma en que dichos documentos ya se redactan dentro de la empresa.

Template

El siguiente paso: establecemos un objetivo para la IA y decimos: crea, por favor, un template del documento que necesitamos que corresponda al máximo con las best practice. En este momento Codex ya sabe qué documento necesitamos, ha visto los materiales fuente y ha estudiado los requisitos corporativos. Por ello puede crear no una plantilla aleatoria, sino el template más preciso y de mayor calidad para el documento objetivo.

Este template debe revisarse manualmente. Hay que ver si se adapta a su tarea: si es grande o pequeño, demasiado amplio o demasiado estrecho, si tiene suficientes secciones, si no está sobrecargado. Si necesitan un documento corto, el template debe acortarse. Pueden decir directamente: haz este template más compacto, necesitamos un documento de trabajo corto. Si necesitan un documento lo más detallado posible, por ejemplo para una especificación de tarea para desarrollo, por el contrario, hay que pedir que amplíe el template: añadir más secciones, más detalles, más criterios de preparación, más espacio para riesgos, dependencias y preguntas abiertas.

En este paso ajustan el template objetivo a su tarea. No es una operación mecánica. Aquí la persona de producto debe mirar y sentir: este template realmente ayudará a reunir el documento necesario o lleva en una dirección equivocada. Codex puede proponer una buena base, pero son ustedes quienes deciden qué nivel de detalle se necesita.

Questionnaire

Cuando la información fuente está cargada, se han estudiado las best practice y los requisitos corporativos, y el template está formado y ajustado, hay que decirle a Codex la frase más importante: ahora compara, por favor, este template y toda la información fuente y verifica qué información nos falta para completar el template de forma completa y con la máxima calidad.

Después hay que pedir: para la información faltante, crea, por favor, un questionnaire, es decir, un cuestionario con el número necesario de preguntas. Codex debe tomar el template objetivo, tomar todos los materiales fuente, comparar una cosa con otra y entender dónde hay vacíos. ¿Qué secciones aún no podemos completar? ¿Qué decisiones no están registradas? ¿Qué assumptions no están claras? ¿Dónde faltan el objetivo de negocio, el escenario de usuario, las limitaciones técnicas, las métricas, los riesgos, las dependencias, los acceptance criteria?

En este paso hay que tener cuidado. Codex puede crear un cuestionario de 200 preguntas, y será extremadamente difícil trabajar con un documento así. En mi opinión, el número óptimo de preguntas para una buena elaboración de un producto o documento es aproximadamente 40-80. Es suficiente para reflexionar bien y extraer la información faltante, pero sin convertir el proceso en un cuestionario infinito.

Como resultado, Codex crea un archivo MD separado con preguntas. No es simplemente una lista de preguntas curiosas. Es una lista de qué información le falta para alcanzar el objetivo: completar un template concreto basándose en información fuente concreta. Ese questionnaire se convierte en un puente entre las fuentes en bruto y un documento final de calidad.

Answers

El siguiente paso: arrojamos este archivo MD con el questionnaire a Codex y decimos: ahora pregúntame según este cuestionario, cada pregunta una por una, y registra los resultados en el archivo answers. Y aquí comienza la parte más valiosa del trabajo de producto.

En primer lugar, el trabajo de producto se vuelve vocal. Codex hace la pregunta 1, ustedes responden por voz. Luego la pregunta 2, responden. Luego la pregunta 3, responden. Se puede responder individualmente o completar el cuestionario junto con el equipo. No es necesario sentarse de inmediato a escribir un documento perfecto. Simplemente responden lo que piensan sobre las preguntas planteadas por el cuestionario.

En segundo lugar, el trabajo de producto se vuelve mucho más preciso. Esto ya no es AI-slop, no es una larga tela de texto generada, sino su información de producto desde la fuente primaria: del equipo de producto, del propietario del área, de las personas que realmente entienden qué está ocurriendo. Codex no inventa el producto por ustedes. Ayuda a preguntar correctamente, recopilar y estructurar lo que ustedes saben.

Este es un cambio de vida máximo para el trabajo de producto, porque ahora no necesitan escribir documentos "desde una hoja en blanco", lo cual siempre fue increíblemente difícil y laborioso. Y no necesitan generar AI slop desconectado del contexto de su producto. Ustedes mismos, de primera mano, crean contenido con su voz basándose en sus conocimientos, pensamientos e ideas.

En el proceso de responder hay que vigilar la calidad de las preguntas. Con el tiempo empezarán a sentir si las preguntas son buenas o no. Si las preguntas se repiten, son demasiado uniformes, demasiado abstractas o no ayudan a pensar, no pasa nada. Pueden decir de inmediato a Codex: estas preguntas son demasiado uniformes, haz las preguntas más precisas, más orientadas al producto, más variadas, sobre la esencia de este tema u otro. El cuestionario se puede ajustar sobre la marcha, y después de eso las siguientes preguntas serán cada vez más precisas.

Como resultado, obtienen un archivo answers muy sólido. En esencia, es la fuente primaria de información sobre el producto. Es información de primera mano del equipo de producto. Ese archivo se puede utilizar como source of truth del proyecto: cargarlo en Neuronet, entregarlo a las personas nuevas, añadirlo a Codex, utilizarlo como base para futuros documentos.

Solo después de esto pasamos al documento final. El comando final suena así: completa el template basándote en nuestros answers y en toda la información fuente. Ahora Codex no trabaja en el vacío. Tiene las best practice corporativas, el template objetivo, los materiales fuente y las respuestas del equipo de producto a las preguntas que cierran las brechas de información.

Precisamente por eso el documento final ya no resulta ser AI-slop, sino un documento de calidad en esencia. Está reunido a partir de información real, verificado mediante preguntas, estructurado según el template correcto y corresponde al formato que necesita la empresa. Es un nivel de trabajo fundamentalmente diferente en comparación con pedir "escribe un PRD" en un chat vacío.

Después de la generación, el documento final debe revisarse. Hay que aplicar un skill o una pasada separada para sustituir erratas, especialmente en los términos, porque en los documentos de producto a menudo se estropean los nombres, los términos internos, los nombres de productos y las formulaciones técnicas. Después hay que leer el documento uno mismo.

Cuando aprendan a realizar bien este proceso, los documentos finales resultarán muy precisos y podrán revisarse bastante rápido. Pero en los primeros pasos es mejor corregir cuidadosamente. Así empezarán a sentir dónde la IA no transfiere con suficiente calidad sus pensamientos e ideas, dónde suaviza un detalle importante, dónde interpreta una respuesta de forma incorrecta, dónde hay que corregir el prompt para crear o completar el template.

Recomiendo encarecidamente utilizar este mecanismo. Ayuda a que todos estén en la misma página. Y no solo las tres personas de producto que debatieron el producto en la reunión, sino todo el equipo del proyecto y toda la empresa. Obtenemos una forma común de convertir conversaciones y fuentes dispersas en documentos de calidad, answers, source of truth y una capa común de conocimiento sobre el producto.

AI intro 8 - Documentos de producto - workflow

Si formulamos el workflow práctico, se ve así.

Primero creamos una carpeta local del proyecto y la conectamos en Codex mediante existing folder. Es importante que el proyecto de Codex esté vinculado a una estructura de archivos real y no viva en algún lugar abstracto.

Luego creamos dentro del proyecto agentes temáticos —chats—: PRD, decisiones de arquitectura, answers, fuentes, kickoff, áreas de producto separadas. Los nombres deben ser comprensibles, porque esta estructura funcionará como un mapa del proyecto.

Después reunimos las fuentes primarias: kicoffs. transcripciones de Google Meet, Loom, notas, documentos antiguos, materiales de Confluence, enlaces, respuestas de debates. Se pueden colocar en carpetas temáticas o simplemente añadirlos como adjuntos en el chat o agente correcto de Codex. En esta etapa no hay que intentar crear inmediatamente un documento final perfecto. Es importante reunir la capa completa de información fuente.

A continuación convertimos las llamadas y reuniones en Markdown. Para ello se puede usar Command Center u otra mini-app para transcripción. Lo principal es que el resultado sea textual, esté ubicado en la carpeta del proyecto y sea accesible para Codex.

Luego pedimos a Codex que encuentre las best practice corporativas para el documento objetivo: PRD, documento de arquitectura, especificación de tarea, estrategia o cualquier otro formato. Codex debe entender cómo se acostumbra a hacer ese documento dentro de la empresa.

Después pedimos a Codex que cree un template del documento objetivo según las best practice encontradas. Revisamos el template manualmente y lo ajustamos: lo hacemos más corto si se necesita un documento compacto, o más detallado si se necesita una especificación de tarea profunda.

Luego pedimos a Codex que compare el template con toda la información fuente y determine qué información falta. Sobre la base de estas brechas, Codex crea un questionnaire: un archivo MD separado con preguntas. Es óptimo mantener el cuestionario aproximadamente en el rango de 40-80 preguntas, para que sea suficientemente profundo pero siga siendo manejable.

Después pedimos a Codex que haga las preguntas del questionnaire de una en una y registre las respuestas en answers. En esta etapa proporcionamos por voz o texto información de producto procedente de la fuente primaria, y Codex la reúne cuidadosamente en un archivo estructurado.

Después de esto pedimos a Codex que complete el template basándose en answers y toda la información fuente. Así se obtiene un documento final basado en fuentes reales, requisitos corporativos y respuestas del equipo, no en una generación vacía.

Al final revisamos el documento: lo corregimos, aplicamos una pasada de erratas y términos, comprobamos si las ideas fueron transferidas correctamente. Si vemos que la IA en algún lugar no entendió la idea con suficiente precisión, corregimos el prompt o volvemos a answers.

Y, por último, cargamos la capa seleccionada y normalizada en Neuronet u otra base de conocimiento de IA común, para que no solo el autor del documento, sino todo el equipo pueda preguntar y obtener respuestas de una única fuente de verdad.

AI intro 8 - Documentos de producto - Markdowns

Ahora, por separado, sobre la estructura de almacenamiento de documentos de producto. Creamos una nueva estructura según principios AI-first. Todas las fuentes de los documentos deben estar en Markdown. Esto es importante porque Markdown se lee igual de bien por personas, Codex, Claude Code, Neuronet y otras herramientas de IA. Para una lectura manual conveniente de Markdown se puede usar Obsidian self-hosted o Sublime Text. Lo principal es que los documentos sigan siendo archivos de texto simples que se pueden almacenar en el repositorio, hacer commit, leer, buscar y cargar en IA.

Para trabajar con dichos documentos, cada participante puede crear un proyecto en su Codex o Claude Code y sincronizarse con este repositorio. Se puede hacer commit, pero hay una regla importante: no editar documentos ya creados previamente sin una razón y un acuerdo por separado. Si se necesita un nuevo documento de producto, no reescribimos el antiguo, sino que creamos un archivo nuevo con una indicación de la nueva versión. Esto preserva el historial, permite entender de dónde procede la información y no rompe los artefactos ya fijados.

La estructura de carpetas se organiza según el rol de los documentos. El nivel superior divide los materiales en source of truth, secondary documents, calls y luego carpetas de documentos de producto concretos que actualmente son relevantes y se están preparando. Es decir, la información primaria más valiosa está separada, los materiales secundarios están separados, las llamadas están separadas y las carpetas de trabajo para PRD concretos, ADR, estrategias, especificaciones de tareas y otros documentos también están separadas.

Dentro de las carpetas de trabajo se aplica una regla lingüística simple: los archivos en inglés están en la raíz, los archivos en ruso están en la carpeta RU. Esto ayuda a no mezclar versiones, encontrar más rápido el archivo necesario y no multiplicar el caos en los nombres. Si el documento se prepara en dos idiomas desde el principio, la estructura debe admitir de inmediato esta separación.

Ahora todos los documentos no se escriben desde una hoja en blanco. Los formamos mediante el proceso ya descrito: damos a Codex o Claude Code la solicitud y los documentos fuente, preguntamos por un best practice template para el documento necesario, cargamos todos los archivos MD relevantes, pedimos determinar qué información falta y formar un questionnaire. Si el questionnaire resulta demasiado grande, por ejemplo de más de 100 preguntas, hay que ajustarlo. Normalmente bastan aproximadamente 50 preguntas, a veces 40-80 si el documento es amplio.

A continuación, el questionnaire se carga en Claude Code o Codex en modo "pregunta — acepta respuestas por voz". Respondemos todas las preguntas del documento. Si nosotros mismos no sabemos qué responder, el cuestionario se puede enviar al propietario del conocimiento o al equipo de producto. En nuestro contexto podría ser, por ejemplo, @d.dolgov: así es incluso mejor, porque las respuestas proceden de la fuente primaria, en lugar de ser completadas por el modelo.

Después de las respuestas damos el comando de formar el documento necesario según el best practice template, la base de datos agregada y answers. Aquí, por datos agregados se entiende toda la información reunida: MD fuente, Confluence, transcripciones, source of truth, secondary documents, answers y aclaraciones adicionales.

Si el documento resultante no gusta, es normal. Por ejemplo, desarrollo puede revisar un ADR y decir que el formato o la composición del documento no son adecuados. En ese caso no hay que empezar desde cero. Se puede reescribir el formato o la composición del documento utilizando los answers.md ya preparados del Narrative Leader u otra fuente primaria. Answers es una base valiosa; no se debe desechar solo porque la primera versión del documento final resultó fallida.

Si en el proceso de reescritura se añade información nueva, aclaraciones o decisiones, debe quedar un artefacto separado o handoff en Markdown sobre ello. Este archivo debe hacerse commit en la carpeta de este documento en GitHub. Por ejemplo, si se trata de un ADR, dicho handoff debe estar ubicado en la carpeta ADR. Esta regla nos protege de perder el contexto: cualquier dato nuevo debe permanecer en las fuentes, y no solo disolverse en el texto final.

Si se necesitan preguntas con aclaraciones para el equipo de producto, se pueden formar de inmediato en otro cuestionario en Markdown. Con este enfoque las respuestas serán rápidas, porque a las personas les resulta más fácil responder preguntas concretas que leer un documento grande y buscar por sí mismas dónde se requiere una aclaración.

También es útil consultar la carpeta común Source of Truth, donde se encuentra la información más valiosa sobre el producto. Antes de crear un documento nuevo se pueden cargar en Codex o Claude Code no solo los materiales actuales, sino también los cuestionarios y answers anteriores. Si Source of Truth ya contiene 80, 120 o 200 preguntas y respuestas con información de máxima precisión procedente de primera mano, se trata de un enorme contexto que no se puede ignorar.

Todos los documentos de Source of Truth se duplican adicionalmente en Confluence, en el espacio Metas/Metasdev, y luego se cargan en Neuronet y Slack. Ahora esto se puede hacer manualmente; más adelante, esta sincronización se puede automatizar. El sentido es que el repositorio Markdown se convierte en una fuente AI-readable y una base de trabajo, mientras que Confluence sigue siendo el lugar habitual de lectura y navegación para las personas.

Si se sigue este orden durante varias iteraciones de producto consecutivas, tendremos una capa importante de información de producto siempre disponible desde la fuente primaria. Es información sin teléfono descompuesto, disponible para todo el equipo en todas las áreas. Y esto ya es en sí mismo un resultado muy sólido: no solo escribimos documentos, sino que construimos memoria de producto que se puede leer, ampliar, reutilizar y cargar en IA.

El principio principal: los documentos Markdown no se crean por Markdown en sí. Son necesarios para convertir conversaciones, reuniones y decisiones dispersas en una capa común de conocimiento con la que puedan trabajar personas e IA. Codex en este proceso es una herramienta de trabajo para el trabajo de producto local: lee la carpeta, ayuda a estructurar las fuentes, reunir documentos, extraer la parte relevante de una discusión y mantener el contexto del proyecto.

Neuronet, en este esquema, se convierte en una forma de difundir más ampliamente la información ya preparada: a la empresa, socios, desarrolladores, managers y todos los que deben entender qué está ocurriendo. Si se realiza correctamente este proceso, reducimos la brecha entre quienes idearon el producto y quienes luego deben crearlo, venderlo, mantenerlo o explicarlo.

Precisamente por eso trabajamos con archivos MD, Codex y Neuronet no como con un juguete de moda, sino como con infraestructura de memoria de producto. Una conversación por sí sola desaparece. No todos verán un Loom por sí solo. Nadie leerá por sí solo un gran documento de IA. Pero una capa de información fuente bien organizada en Markdown se puede leer, buscar, cargar en Codex, actualizar en Neuronet y usar como una base viva para el trabajo de producto.