Capability Building · EST. 2011 · APAC

Four adopter groups. Two divisions. 3x productivity — no added headcount.

The Situation

The department engaged ZXM to design a Product Operating Model (POM) for IT — a model that would govern how software, hardware, data, and cloud teams managed their products across two major divisions. The engagement spanned four early-adopter groups, covering diverse product contexts, from general application development to AWS PROTECTED cloud infrastructure.

The POM needed to be more than a document. It needed to scale — from small specialist teams to large cross-functional programs — and adapt to the radically different operating realities of each group. ZXM was commissioned to produce, test, and iterate the model within 12 weeks.

What the diagnostic found

ZXM began drafting the POM and conducting structured design workshops in parallel with four early-adopter groups. The goal was not to validate a predetermined model. It was to map how each group actually worked — what decisions were made, by whom, and how accountability for product outcomes was currently distributed.

Three structural conditions emerged consistently across the groups.

Core concepts of product ownership were nominally assigned but not functionally supported — teams lacked the decision rights and prioritisation mechanisms to act on them.
The demand intake model was project-oriented: work arrived as requirements rather than problem statements, which prevented value-based sequencing.
The current operating model had no feedback mechanism — there was no structured loop from team delivery back to strategic investment decisions.

These were not problems of individual capability. They were conditions of the operating design.

What changed

ZXM used a multi-agent AI system (MAS) with strong governance controls to accelerate the aggregation of current industry best practices, drafting, peer review for consistency and alignment, iteration of feedback, and version control for the POM — compressing a three- to nine-month engagement into eight weeks of initial production. A further four weeks were dedicated to structured feedback cycles with each adopter group, testing the model against their specific context.

Hands-on workshops were run across the two divisions. Each session served two purposes: to elicit contextual feedback on how the model needed to flex, and to verify that the model was genuinely scalable — that a single framework could govern software teams and hardware teams, small specialist groups and large product lines, without requiring significant customisation.

The AWS PROTECTED cloud group operated in a severely resource-constrained environment. The model was adapted to surface how existing headcount could be better directed — shifting the question from how to acquire more resources to how to govern what was already there.

What held

The AWS PROTECTED cloud team increased productivity threefold. In a resource-constrained environment where additional headcount was not an option, the model created the governance conditions for the same team to achieve substantially more.

The POM has been deployed across both divisions. The early adopter workshops validated scalability — the model operates effectively across software, hardware, data, and cloud product contexts without requiring bespoke redesign for each. The feedback cycle from each group has been built into the ongoing iteration cadence, so the model will continue to evolve as adoption matures.

A product operating model that cannot adapt to context will fail at the first divisional boundary. This one held because the adaptive surface was designed in, not added as an afterthought.