Libnova creció como crecen las buenas empresas técnicas: de forma orgánica, impulsada por la ingeniería y un profundo conocimiento del dominio, sin una función de producto formal entre los clientes y el código. Eso funciona hasta que deja de hacerlo. Para cuando llegó la adquisición, se habían acumulado dos problemas.
Las decisiones de producto no tenían un responsable claro, ni una visión compartida, ni una forma repetible de trabajar. Sin product managers en el sentido moderno, sin modelo de competencias, sin marco de objetivos. Las prioridades se fijaban caso por caso.
El software se había moldeado cliente a cliente. Manejable con un puñado de clientes a medida, pero una restricción real cuando el plan es escalar como SaaS, donde cada nuevo cliente añade coste en vez de escala.
El pipeline de docs-as-code toma lo que el equipo ya produce, el código fusionado y los tickets de Jira ligados a cada release, y redacta documentación en dos registros. Llega a Confluence como Markdown limpio. Una persona revisa y aprueba antes de que salga nada externo.
En vez de que un PM recopile cifras en un informe de estado cada ciclo, los paneles de Claude Code ensamblan informes y conclusiones a partir de las fuentes subyacentes, así el equipo lee y decide en vez de recopilar y dar formato.
Es fácil soltar la IA en una empresa y generar una montaña de documentos que nadie lee. Construimos lo contrario: anclado a lo que los equipos consultan de verdad, juzgado por si se consume en vez de por cuánto existe.
La plataformización es donde está el riesgo real. No puedes mover a un cliente a un despliegue más escalable a costa de las garantías que hacen que valga la pena comprar el producto. Así que el despliegue repetible tenía que igualar la fiabilidad de las instalaciones a medida que reemplazaba, nunca cambiar fiabilidad por velocidad.
La misma disciplina se aplicó a las herramientas de IA: la documentación generada la revisaba una persona antes de llegar a un cliente, y solo se confiaba en la automatización donde su resultado podía contrastarse con una fuente de verdad.
Orientado a la IA, pero no IA sin supervisión. La versión de fiar era la única que se permitía lanzar.
El trabajo de plataforma más profundo sigue en marcha y el valor se acumula una vez establecida la función, así que la medida honesta aquí es el rumbo y no una sola métrica.
De una estructura informal liderada por ingeniería a una organización de producto de verdad: visión, PMs sobre un modelo de competencias, equipos estructurados, trabajo guiado por OKR.
De una tarea manual que se saltaba a un subproducto automático de cada release, generado a partir del código y de Jira.
De informes recopilados a mano a paneles ensamblados automáticamente, así el equipo lee y decide.
Notablemente más estructurado y legible para la IA, la base para todo lo que sigue, con la dirección de la plataforma fijada y en marcha.
Establecer la función y el modelo operativo, y luego entregar una organización que funciona a un liderazgo permanente, el siguiente paso natural a medida que nuestra colaboración concluye.
La plataformización continúa desde la base ya asentada: de instalaciones a medida a un despliegue repetible y fiable para que el negocio pueda escalar.
Los sistemas orientados a la IA, una vez integrados, siguen dando fruto sin necesitarnos cerca, que es el objetivo de construirlos bien.
Diseñamos y construimos webs, aplicaciones web y sistemas de automatización para empresas B2B, y asumimos el liderazgo de producto cuando una empresa necesita que se le construya la función y no solo que se le asesore. En esta colaboración nuestro papel fue el de CPO fraccional: la organización de producto, el modelo operativo y los sistemas orientados a la IA que hay debajo.