Design Ops: CX’s product operations hiding in plain sight

When design teams start optimising alignment, processes, and tooling across the whole product organisation, they are doing Product Ops. Most of them just never realised it.

Abstract illustration of Ops in action. Image by Rawpixel.Com

Product Operations has a clean definition. It is the function that *“frees up product teams to focus on strategy and execution by managing workflows, data, and systems”, *essential to scaling functions on four pillars: data management, process optimisation, tools management, and cross-functional alignment.

It does not say where Product Ops has to live.

Most organisations house it inside a product management function. A Product Ops lead sits alongside PMs, builds the operating model, and makes sure the product team can do its best work. That makes sense. But it is not the only way it works in practice for agile product-led organisations and not complex ones like Financial Instituitions (FIs).

When I look back at what I spent three years building inside a CX design function at a large financial institution, I was not doing Design Ops in the traditional sense. I was running a Product Ops function, with design as the context and a multi-disciplinary team of 60 as the organisation I was serving. Nobody called it that at the time. But the work maps perfectly.

This matters beyond semantics. If Design Ops practitioners do not claim this framing, they will keep being seen as the team that manages the design tool stack and runs the retrospectives. That undersells both the function and the people in it.

What the four pillars look like in CX, design-led function

Mapping what Design Ops does to the four pillars of ProductOps based on Atlassian’s Guide

1. Data management in a product function means building dashboards and metrics that give teams visibility into what is being built and how it is performing. In a design function, the equivalent is delivery analytics: real-time dashboards showing capacity, throughput, and effort across disciplines. When I rebuilt our Azure DevOps configuration to track design work properly, redefining story states, introducing a 0.5-day story point standard, and building a tagging taxonomy across business units, I was doing data management. Leaders could make decisions based on evidence rather than impression.
2. Process optimisation is about reducing duplication, removing blockers, and making it easier for teams to do their best work. For a design function, this means intake design, dependency management, and working agreement governance. Before we had a structured intake model, work came in through personal relationships and Slack messages. After we introduced the Dependency Request model, with structured templates, alignment meetings, and linked Epics in ADO, the quality of briefs improved, product owners engaged earlier, and the design team stopped losing time to poorly-formed requests.
3. Tools management is common ground for both Product Ops and Design Ops. For us, this went beyond licence tracking. We assessed and onboarded Figma Make under enterprise governance requirements, defined compliant usage guidelines, and built knowledge-sharing into how the tool was scaled through engagements and governance. That is tools management done as a strategic function, not an administrative one.
4. Cross-functional alignment is where Atlassian’s framing is most precise. They note that Product Ops “often owns the process for communicating product updates to stakeholders, ensuring consistent messaging about what’s being built, why it matters, and when it will ship.” We did exactly this through OneCXID, a structured operating model that gave product owners clarity on which CX discipline to engage and why, and gave leadership a shared language to articulate the full value of the function.

The scaling problem that makes Product Ops necessary

What starts as a small group collaborating informally *“become a tangled web of disconnected tools, duplicate processes, and misaligned priorities”* as teams grow.

This is not a product management problem. It is an organisational scaling problem. And it shows up just as clearly inside design functions.

Our CX function grew from 16 to 60 people across UIUX, content, research, and service design, because we scaled logically in our ways of working.

• Shared language for how work moved aligned with product and change delivery guidelines.
• Clear system for product owners to line up work with us each quarter.
• Framework for tagging and labelling type of work, with shared assibility to all teams.
• Clear real-time data for leadership to use when discussing stakeholders investment in team growth.

In reality, these four Product Ops pillars were built in a context where nobody expected to find them; a CX Team.

Why DesOps is well-placed to do this work

There is a reason that Product Ops struggles in some organisations, and the problems tend to be the same.

• Processes feel bureaucratic.
• Dashboards show numbers nobody acts on.
• Governance creates compliance rather than ownership.

These are design problems.

As the critical bridge between product teams and stakeholders, the balance between autonomy and consistency is the same tension that governs good design system work. It is the same tension at the heart of good service design. The ability to hold both is something Design Ops practitioners develop precisely because design work resists over-prescription.

When the intake and governance infrastructure was built for the group, I was not configuring a workflow tool. I was designing the experience from the perspective of a product owner who needed design support and this system must be scalable.

• The Dependency Request model was a service journey.
• The Confluence hub was an information architecture.
• The working agreement was a contract designed for people who did not want to read contracts.

That orientation, towards the human experience of a process rather than its mechanical efficiency, is what separates governance that people own from governance that people tolerate.

“Design Ops is already doing a great job in having a clear, unified approach to its planning and execution.”, Director, Transformation and Strategic Initiatives, 2025

DesOps = Inward-facing Des Ops + Product Ops Work

If you are running a Design Ops function today, ask yourself whether the work you are doing faces inward or outward.

DesOps does both. Outward facing work is what makes us Product Ops hiding in plain sight.

Inward-facing Design Ops improves how the design team operates: better onboarding, cleaner handoffs, a shared design system, consistent file naming. This is valuable. It is also the floor, not the ceiling.

Outward-facing Design Ops changes how the rest of the organisation engages with, relies on, and funds the design function.

• It builds the intake infrastructure.
• It generates the delivery data.
• It creates governance frameworks that other teams adopt.
• It makes the design function legible to the product organisation.

When three to five teams outside our CX function formally adopted our ADO operating model, that was not a Design Ops win. It was a Product Ops outcome. The function had become useful beyond its own boundary.

The function exists wherever someone is building the system that makes product delivery legible, governable, and fundable.

If this is you, regardless of what your title says, you are already running Product Ops.

Credits to Sean for the partnership in designing a unique position for our DesOps team.