Building a product operating model that lasts
Inside a global financial-data company, the group responsible for platform stability and monitoring worked like a project shop: plenty of motion, little of it reaching customers. We reorganized 18 teams into a product operating model with embedded design and evidence-based practice, and watched product waste fall from roughly 90% to under 5% in 16 months, an 18x reduction.
There is a difference between doing the work and delivering value, and a capable engineering organization can stay busy indefinitely while very little of that effort changes anything for a customer. That was the starting point at the Firm. The group responsible for platform stability and monitoring was organized around projects and silos, and by our analysis roughly 90% of its product effort was waste: motion that never reached a validated customer outcome. Design sat apart from engineering. Decisions were made by opinion rather than evidence.
We reorganized the group into a product operating model, an 18-team structure we ran like a set of startup pods, across three clear verticals: incident detection and analysis, global triage and support, and systems telemetry. Then we changed how the teams actually worked.
Design moved inside engineering. UI/UX practitioners joined the teams directly and brought user testing, interviews, rapid prototyping, and validation through post-release feedback loops, so the question “did this help anyone?” got answered with data instead of assumed.
As Product Owner, we set the product strategy and roadmap, owned the business requirements, the budget, and the client relationship, and blended LeSS, Nexus, and SAFe rather than forcing a single framework onto a problem that didn’t fit one. Evidence-based practice became the default: A/B testing behind feature flags, MoSCoW prioritization, value-stream analysis to find where customer value actually got stuck, and lead- and cycle-time measurement to keep improving the path from idea to delivery.
We set OKRs and KPIs with senior leaders and built a business-intelligence data warehouse and dashboards underneath them, so the unified product backlog was fed by measurement rather than guesswork. And we made the change durable with a coaching network of more than 15 agilists, a mentorship program, white papers, and training courses, because an operating model that depends on one team in the room doesn’t survive that team leaving.
What the shift produced
| Dimension | Before | After |
|---|---|---|
| Product waste | ~90% | <5% within 16 months |
| Operating model | Project silos | 18 product pods, three verticals |
| Design | Separate from engineering | Embedded in every team |
| Prioritization | Opinion-based | Evidence-based (A/B, MoSCoW, value streams) |
The model held because the culture underneath it changed, not just the org chart. Coaching, mentorship, and communities of practice were what kept it standing after we stepped back.
The reorganization is what people noticed first, but it isn’t what made the difference. Our four-principle approach put education and a real continuous-improvement culture alongside the new structure, which is why the gains held. The teams didn’t just adopt a new framework. They learned to be a product organization rather than perform the rituals of one.