Escrito originalmente en francés. Traducido por IA — se ha preservado el sentido, no la prosa.
Una documentación siempre rezagada
Lo hemos vivido todos: aparece un bug, o hay que tratar una evolución funcional. El primer reflejo es consultar la documentación. Y, muy a menudo, ya no está actualizada.
En realidad, casi sabemos de antemano que no lo estará. El patrón es conocido: se produce una documentación, se entrega con la especificación, y luego empieza el desarrollo. Por el camino surgen preguntas, se toman decisiones, algunos puntos evolucionan, y los desarrolladores a veces toman decisiones sin volver sistemáticamente al product manager. Es normal. De lo contrario, el trabajo avanzaría al ritmo de una validación permanente. El resultado, en cambio, es siempre el mismo: la documentación y el código acaban divergiendo.
Esta divergencia también se debe a una restricción muy simple. En cada modificación, por menor que sea, nadie tiene realmente tiempo de ponerse a buscar la especificación correcta, la maqueta correcta, el documento de soporte correcto o el changelog correcto para actualizarlo todo. Trabajamos sobre un producto vivo, que evoluciona continuamente. En este contexto, mantener manualmente el conjunto de artefactos se vuelve rápidamente demasiado costoso en relación con el tiempo disponible.
Cuanto más pasa el tiempo, más se agrava el problema. Hoy en día, una funcionalidad ya no se concibe una vez para siempre: se ajusta, se enriquece, se corrige, a veces durante meses o años. En estas condiciones, es poco realista esperar mantener perfectamente sincronizados la especificación inicial, los intercambios del proyecto, el changelog, la documentación de soporte, la documentación comercial y las maquetas.
El código como fuente de verdad
El livrable real, en el fondo, es el código. Puede que no sea la fórmula oficial, pero es él quien describe el estado real del producto. El resto solo intenta seguirlo. En este sentido, la expresión "Code is Law" sigue siendo particularmente acertada: https://framablog.org/2010/05/22/code-is-law-lessig/
Durante mucho tiempo, esta situación era inevitable. La documentación en lenguaje natural constituía la menos mala de las soluciones, especialmente porque la mayoría de los product managers no trabajan directamente en el código. Hacía falta, por tanto, una capa intermedia, comprensible para todos, utilizable en reuniones, compartible con los equipos, y aprovechable sin competencia técnica particular.
Lo que cambia la IA
La IA cambia ahora esta ecuación. Cuando el código es suficientemente limpio y documentado, es posible convertirlo en una fuente aprovechable para reconstruir o actualizar otros livrables. Podemos, por ejemplo, partir del código real para actualizar una documentación de soporte tras una entrega, generar un changelog más fiable, o reconstituir una especificación funcional a partir del estado actual del producto en lugar de a partir de un documento antiguo.
El código ya no es únicamente el livrable final: se convierte en el elemento central, la fuente de verdad alrededor de la cual gravitan y se reconstruyen los demás artefactos del producto, en una lógica verdaderamente code centric.
La cuestión de la cultura técnica
Pero esto abre otra pregunta: ¿cómo puede un product manager sin perfil técnico sacar partido de esta posibilidad?
Las herramientas actuales son potentes, pero no se usan sin criterio. Pueden ayudar a producir rápido, a automatizar ciertas tareas y a generar bloques útiles. En cambio, en cuanto se toca la arquitectura, la coherencia global o la mantenibilidad, sus límites aparecen rápidamente. Sin un mínimo de cultura técnica, el riesgo es multiplicar pequeñas herramientas eficaces localmente pero mal articuladas entre sí. Se gana tiempo aquí o allá, y luego se pierde al hacer circular los datos, gestionar incoherencias, o mantener un conjunto que se ha vuelto difícil de entender.
El reto no es solo producir más rápido. Es producir dentro de un marco coherente. Es esa coherencia la que marca la diferencia entre una acumulación de herramientas y un verdadero sistema de trabajo.
Desde este punto de vista, probablemente ya existe una brecha de capacidad entre los PM con trayectoria técnica y los que no la tienen. No porque unos sean intrínsecamente mejores que los otros, sino porque los primeros disponen hoy de una palanca adicional: pueden intervenir más directamente sobre la materia misma del producto, es decir el código, y usarlo como base para generar, controlar o cuestionar otros artefactos.
Se podría objetar que los SaaS integrarán cada vez más agentes capaces de automatizar estas tareas. Es probable, y será un progreso real. Pero no creo que eso baste para borrar la diferencia. La mayoría de estas herramientas seguirán siendo especializadas.
Es precisamente ahí donde aparece el límite. Una herramienta como Zendesk podrá probablemente ayudar a producir una mejor documentación de soporte. Una herramienta como Figma seguirá siendo excelente para diseñar pantallas. Pero ninguna de las dos, por sí sola, tiene una visión completa del producto real tal como existe en el código, tal como evoluciona en los merge requests, y tal como debe entenderse en su contexto de negocio.
Hoy, con las herramientas adecuadas, puedo por ejemplo cruzar varios niveles de información: el código fuente, el historial de evoluciones, los merge requests, y las reglas de negocio que he acumulado como product manager. Esto permite no solo generar una documentación más precisa, sino también cuestionar lo que ya existe.
La misma lógica vale para el diseño. Hoy se dibuja una interfaz en Figma, y luego hay que desarrollarla. Pero si soy capaz de reconstruir un design system a partir del código real, de mantenerlo actualizado según las evoluciones del repositorio, y de añadir las convenciones de desarrollo del equipo, entonces la maqueta cambia de estatus. Ya no es solo una representación: puede empezar a convertirse en una primera base aprovechable por los desarrolladores front-end.
En otras palabras, la frontera entre diseño, implementación y documentación empieza a reducirse. No es solo una cuestión de productividad. Es una transformación más profunda: el código ya no es simplemente el resultado del trabajo, se convierte también en la materia prima a partir de la cual podemos reconstruir el resto.
Lo que va a cambiar el MCP
No pretendo que este modelo esté ya estabilizado. En unos meses, puede que esté en parte superado. El MCP, en particular, puede aún cambiar el equilibrio. Podemos imaginar mañana un ecosistema en el que cada SaaS tendría su propia capa de agentes, capaz de dialogar con otros sistemas. Figma podría, por ejemplo, recuperar contexto de un repositorio GitLab, leer las evoluciones recientes, entender los merge requests pertinentes, y alinear mejor el diseño con la realidad del producto. Todavía no estamos del todo ahí, pero la dirección empieza a verse.
Por eso el MCP me parece importante. De la misma manera que las API se volvieron indispensables cuando los SaaS dejaron de vivir en compartimentos estancos, los MCP podrían volverse esenciales a medida que los agentes se generalicen. Cada herramienta conservará su especialidad, pero el valor real vendrá de su capacidad para dialogar con las demás, recuperar contexto, y actuar en un ecosistema más amplio que su propio perímetro.
La mejor actitud, a estas alturas, es sin duda experimentar en serio. No para seguir un efecto de moda, sino para entender qué permite ya, concretamente, crear valor. Porque el cambio en curso no es solo tecnológico. Toca la naturaleza misma de los livrables del producto, su fuente de verdad, y el lugar del product manager en su producción.
Para saber más
Añadir una memoria de sesión como en OpenClaw En 8 días comprendí que el rol de Product Manager iba a cambiar por completo La calidad pertenece a quienes entregan La pregunta de producto debe partir del código fuente