Libnova grew the way strong technical companies grow: organically, driven by engineering and deep domain expertise, without a formal product function between the customers and the code. That works until it doesn't. By acquisition, two problems had built up.
Product decisions had no clear owner, no shared vision, no repeatable way of working. No product managers in the modern sense, no competency model, no goals framework. Priorities were set case by case.
The software had been shaped client by client. Fine with a handful of bespoke customers, a real constraint when the plan is to scale as SaaS, where every new client adds cost instead of leverage.
The docs-as-code pipeline takes what the team already produces, merged code and the Jira tickets tied to each release, and drafts documentation in two registers. It lands in Confluence as clean Markdown. A person reviews and approves before anything external ships.
Rather than a PM pulling numbers into a status update each cycle, the Claude Code dashboards assemble reporting and insights from the underlying sources, so the team reads and decides instead of collecting and formatting.
It is easy to point AI at a company and generate a mountain of docs no one reads. We built for the opposite: anchored to what teams actually reference, judged by whether it gets consumed rather than by how much exists.
Platformisation carries the real risk. You cannot move a client onto a more scalable deployment at the cost of the guarantees that make the product worth buying. So repeatable deployment had to match the reliability of the bespoke setups it replaced, never trade reliability for speed.
The same discipline applied to the AI tooling: generated documentation was reviewed by a person before it reached a customer, and automation was trusted only where its output could be checked against a source of truth.
AI-forward, but not AI-unsupervised. The trustworthy version was the only one allowed to ship.
The deeper platform work is still underway and the value compounds after the function is established, so the honest measure here is the direction of travel rather than any single metric.
From an informal, engineering-led setup to a real product org: vision, PMs on a competency model, structured teams, OKR-driven work.
From a manual task that got skipped to an automated by-product of each release, generated from code and Jira.
From hand-compiled updates to dashboards assembled automatically, so the team reads and decides.
Meaningfully more structured and AI-legible, the groundwork for everything that follows, with the platform direction set and moving.
Establish the function and operating model, then hand a working organization to permanent leadership, the natural next step as our engagement winds down.
Platformisation continues from the foundation now in place: from bespoke installations to repeatable, reliable deployment so the business can scale.
The AI-forward systems, once embedded, keep paying off without needing us in the room, which is the point of building them properly.
We design and build websites, web applications and automation systems for B2B companies, and we take on product leadership where a company needs the function built rather than just advised on. On this engagement our role was the fractional CPO: the product organization, the operating model, and the AI-forward systems underneath it.