Una empresa que creció a base de ingeniería, sin función de producto.
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. Cuando llegó la compra, se habían acumulado dos problemas.
Estructural
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.
Técnico y comercial
El software se había ido adaptando cliente a cliente. Con un puñado de clientes a medida es manejable, pero frena de verdad cuando el plan es escalar como SaaS: cada cliente nuevo suma coste en vez de escala.
Dos cosas a la vez: una organización de producto, y una forma de dirigirla orientada a la IA.
El andamiaje que necesita una empresa SaaS en crecimiento
- ◆Contratamos product managers y construimos un modelo de competencias que define qué significa hacerlo bien
- ◆Fijamos una visión de producto clara y estructuramos los equipos y sus formas de trabajar
- ◆Pusimos en marcha un marco de objetivos y OKR de producto, orientados a resultados y no a actividad
Hacer legible para la IA el conocimiento de la empresa, y luego eliminar el trabajo manual
- ◆Estructuramos el conocimiento del código, los clientes y el soporte para que personas e IA puedan usarlo
- ◆Un pipeline que genera documentación a partir del código y de Jira, por cada release
- ◆Informes internos y paneles de producto creados con Claude Code y ensamblados automáticamente
Documentación como subproducto del trabajo que ya se hace.
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.
Los informes funcionan igual
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 originales, y el equipo se dedica a leer y decidir en vez de recopilar y maquetar.
Una restricción deliberada
Es fácil soltar la IA en una empresa y generar una montaña de documentos que nadie lee. Hicimos lo contrario: partir de lo que los equipos consultan de verdad y medirlo por si se lee, no por cuánto se produce.
La integridad lo es todo. No podía retroceder.
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 por las que merece la pena comprar el producto. Por eso el despliegue repetible tenía que ser tan fiable como las instalaciones a medida a las que sustituía, sin sacrificar 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.
- ✓Alineación con OAIS (ISO 14721)
- ✓Comprobación de fijeza e integridad
- ✓Copias georredundantes y autorreparables
- ✓Cumplimiento de estándares
Orientado a la IA, pero no IA sin supervisión. La versión de fiar era la única que se permitía lanzar.
Una colaboración fundacional, contada por lo que ya funciona.
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.
El modelo fraccional está pensado para concluir.
Establecer la función y el modelo operativo, y luego dejar la organización, ya en marcha, en manos de 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 que tengamos que estar cerca, y para eso se construyen 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.