Hay una escena que se repite en casi todos los equipos de producto digital que conozco. Alguien pregunta por qué una funcionalidad se comporta de cierta manera, o por qué hace dos años se tomó esa decisión de arquitectura, o cuál era la lógica de negocio detrás de ese flujo que hoy todos dan por obvio. Y la respuesta, casi siempre, es un silencio incómodo seguido de “creo que fue Jorge, pero ya no está en el equipo.”

El conocimiento del producto vive en las cabezas de las personas. Cuando las personas se van, el conocimiento se va con ellas.

Eso no es un problema de memoria. Es un problema de cultura.

Lo que vi funcionar en Silicon Valley

A mediados de los 2000 trabajé en un proyecto con una empresa que hoy se llama Adaptive Insights. En ese tiempo eran una startup haciendo software de planificación financiera — un producto complejo, con lógica de negocio profunda y usuarios exigentes. Hacían ágil, sí, pero tenían algo que pocas empresas tenían: un wiki en MediaWiki donde documentaban el producto de forma rigurosa y continua.

No eran diagramas UML ni especificaciones técnicas al estilo IBM. Era otra cosa: narrativas completas de cada feature, descripción del valor de negocio, mockups, el razonamiento detrás de cada decisión. Versión por versión, funcionalidad por funcionalidad. Y lo más importante — ese wiki era el centro de gravedad de todas las conversaciones del equipo. Cuando alguien tenía una duda, la respuesta estaba ahí. Cuando se tomaba una decisión, se actualizaba ahí. Cuando entraba alguien nuevo, se ponía al día ahí.

Era el SSoT — Single Source of Truth — pero no como concepto abstracto. Como práctica diaria.

Lo que vi en ese equipo no fue solo eficiencia. Vi una cultura donde pensar estaba documentado, donde el razonamiento colectivo tenía un lugar donde vivir y crecer. Vi un equipo que podía moverse rápido precisamente porque no tenía que reconstruir contexto en cada reunión.

Esa imagen mental la cargo hace veinte años. Y sigo sin poder transmitirla con argumentos — porque es el tipo de conocimiento que solo se entiende viviéndolo.

Por qué ese aprendizaje no se generalizó

El mundo ágil de los años siguientes fue absorbido por el delivery. Scrum, Kanban, sprints, velocidad, burndown charts. La conversación de la industria giró hacia cómo entregar software más rápido y con menos fricción. Y en ese contexto, documentar el producto se empezó a sentir como overhead — trabajo adicional que ralentizaba el flujo, burocracia disfrazada de buena práctica.

El resultado es conocido: Confluence lleno de páginas que nadie actualiza, Notion con estructuras bonitas y contenido desactualizado, Jira con tickets que describen el qué pero nunca el por qué.

La documentación pasó a ser una tarea post-mortem — algo que se hace después, cuando hay tiempo, que casi nunca hay.

El cuello de botella se desplazó

Algo cambió radicalmente en los últimos dos años, y muchos equipos todavía no han procesado las implicancias completas.

El costo de escribir código colapsó. Con GitHub Copilot, Cursor, y lo que viene con los modelos de próxima generación, un desarrollador competente puede producir en horas lo que antes tomaba semanas. Gartner proyecta que para 2027, el 70% del código en empresas nuevas será generado con asistencia de IA. McKinsey estima que la automatización del desarrollo podría acelerar los ciclos de entrega entre un 20% y un 45% en organizaciones que adopten estas herramientas de forma sistemática.

Si el delivery se acelera así, ¿dónde queda el riesgo dominante?

En construir lo incorrecto más rápido.

El cuello de botella se desplazó hacia el upstream — hacia el pensamiento previo al código. Hacia la claridad sobre qué se construye, para quién, con qué lógica de negocio, con qué hipótesis de valor. A esto se le llama shift left del proceso de creación de producto: el peso del trabajo se mueve hacia la izquierda en la línea del tiempo, hacia el descubrimiento, la estrategia, la narrativa.

Y ahí es donde el wiki deja de ser una práctica opcional de equipos ordenados para convertirse en infraestructura crítica.

Lo que Anthropic nos enseña sobre documentar en serio

Lo que Anthropic hace con el RSP es Knowledge Management en su forma más sofisticada — no como archivo, sino como infraestructura cognitiva colectiva.

En un video titulado Building Anthropic, los cofundadores de la empresa describen un documento que está en el centro de su cultura organizacional. Lo llaman el RSP — Responsible Scaling Policy. Son 23 páginas públicas que definen cómo Anthropic evalúa los riesgos de sus modelos de IA y qué salvaguardas deben existir antes de desplegar sistemas cada vez más poderosos.

Pero lo que lo hace notable no es el contenido. Es cómo fue construido y cómo funciona.

Dario Amodei, como CEO, dedicó personalmente entre el 10 y el 20% de su tiempo al RSP durante tres meses — escribiendo múltiples drafts desde cero. Uno de sus cofundadores dedicó el 50% de su tiempo a desarrollarlo en el mismo período. El documento pasó por iteraciones extensas, incorporando feedback externo en cada versión. Tom Brown, también cofundador, ha dicho que “de la misma manera que Estados Unidos trata la Constitución como el documento sagrado”, el RSP tiene ese mismo estatus dentro de Anthropic.

El RSP no es un manual de políticas que vive en un cajón. Anthropic encontró que tener una política claramente articulada sobre sus riesgos críticos fue extremadamente valiosa — les proporcionó un marco estructurado para clarificar prioridades organizacionales y enmarcar discusiones sobre timelines, recursos, modelos de amenaza y tradeoffs difíciles. Que los empleados sintieran ownership sobre el documento y pudieran proponer mejoras resultó inmensamente útil, con equipos diversos aportando perspectivas que los fundadores solos no habrían alcanzado.

En otras palabras: el documento es la infraestructura donde la organización piensa sobre sí misma. Es lo que habilita conversaciones de alta calidad que de otro modo no ocurrirían. Es lo que alinea a cientos de personas tomando decisiones difíciles sin necesidad de que todos estén en la misma sala.

Eso es exactamente lo que un wiki de producto bien construido hace por un equipo de desarrollo.

Documentar es pensar, no reportar

El error conceptual más frecuente que veo es tratar la documentación como un acto de registro — algo que se hace después de pensar, para dejar constancia. Bajo ese frame, documentar es overhead. Es burocracia.

El frame correcto es el opuesto: documentar es el acto de pensar. Es la forma en que el pensamiento colectivo se hace visible, se puede cuestionar, se puede iterar. Igual que cuando escribes un memo y en el tercer párrafo te das cuenta de que tu argumento tiene un hueco — el acto de escribir genera el pensamiento, no solo lo registra.

La investigación de McKinsey sobre organizaciones intensivas en conocimiento muestra consistentemente que los equipos de mayor desempeño no son los que tienen más talento — son los que hacen circular el conocimiento de forma efectiva. Documentar la estrategia y el razonamiento de producto es uno de los pocos mecanismos que hace posible esa circulación a través del tiempo, no solo del espacio.

La disciplina que construye equipos, no solo productos

Hay un beneficio que raramente se menciona en las conversaciones sobre documentación: el wiki no solo describe el producto — desarrolla al equipo.

Cuando un equipo practica de forma consistente articular el valor de negocio de cada feature antes de construirla, cuando aprende a escribir narrativas que conectan la funcionalidad con el problema del usuario, cuando desarrolla el hábito de actualizar el razonamiento a medida que aprende — ese equipo está desarrollando una capacidad estratégica que es transferible. No solo para ese producto, sino para cualquier producto que enfrente después.

Forrester ha documentado que las organizaciones con prácticas maduras de gestión del conocimiento muestran tiempos de onboarding hasta un 50% menores y tasas de retención de decisiones críticas significativamente más altas durante rotaciones de equipo. No es un dato menor cuando el mercado de talento digital sigue siendo competitivo.

El escenario que se viene

Piensa en el horizonte de dos o tres años. Los desarrolladores de tu equipo ya no serán ingenieros de software en el sentido tradicional — serán ingenieros de producto, capaces de hacer el end-to-end de una funcionalidad completa usando IA como palanca. Un solo perfil bien posicionado podrá diseñar, construir, testear y desplegar lo que hoy requiere cuatro o cinco personas.

En ese escenario, ¿qué diferencia un producto bien construido de uno que simplemente fue generado rápido?

La calidad del pensamiento que está detrás. La claridad de la narrativa de valor. La profundidad del entendimiento del problema.

Y todo eso necesita un lugar donde vivir. Un lugar donde acumularse, iterarse, cuestionarse. Un lugar que no sea la cabeza de las personas que mañana pueden no estar.

El wiki estratégico no es la herramienta del pasado. Es la infraestructura del equipo de producto que quiere operar en serio en la era de la IA.

La pregunta incómoda

Tu equipo tiene un Notion, un Confluence, o algún equivalente. La pregunta no es si existe la herramienta.

La pregunta es: ¿podría alguien entender completamente la lógica de negocio de tu producto más importante leyendo lo que está documentado ahí hoy?

Si la respuesta honesta es no — y en la mayoría de los equipos lo es — el problema no es la herramienta. Es el frame con que tu organización entiende qué es documentar y para qué sirve.

En Itera estamos trabajando con equipos de producto en este tránsito ahora mismo — desde la mecánica del delivery ágil hacia la disciplina del pensamiento estratégico documentado. No como una práctica adicional, sino como el cambio de paradigma que hace posible todo lo demás.

¿Tu equipo ya está pensando en esto?