As the organisation scaled, many operational problems fell between organisational boundaries.

Engineering owned systems. Product owned features. Customer Service owned customers. Operations owned delivery.

Yet many of the most important challenges sat between those functions.

Customer complaints required technical investigation. Product decisions required operational data. Reliability issues required coordination across multiple teams. Root causes were often difficult to identify because no single function had visibility across the entire customer journey.

The organisation did not need another specialist team. It needed a team capable of connecting the specialists.

The first challenges were giving it a name, and defining what it meant.

The more standard and intuitive team name we founds was Product Operations.

There was no pre-established blueprint, so it was created. No team had it, but this one needed it.

The function gradually evolved around a simple principle:

• If a problem affected the customer experience Product Operations team would take ownership of its resolution and preventing it in the future.

This led the team to develop the widest product and platform knowledge, operating across analytics, troubleshooting, incident coordination, business intelligence, process improvement and operational product ownership.

Rather than focusing on a single discipline, the function focused on product experience by reducing organisational friction and orchestrating needs and resources.

Building the team required a different hiring philosophy.

Technical expertise alone was not enough. The team needed people capable of dealing with uncertainty, moving between data analysis, operational investigations, stakeholder management and customer-facing challenges.

Over time the function grew into a multidisciplinary team combining analytical thinking, operational execution, systems understanding and a huge resiliency towards decision-making.

Knowledge sharing, mentoring and collaborative problem solving became core operating principles.

The objective was not to create individual experts, but to create a versatile team capable of understanding problems from multiple perspectives, consistently.

I had great opportunity to be led by great leaders, and learnt the lesson by experience: a leader helps others make the next step, with confidence, and influence them into thinking that next step is the best option.

The team grew in size, and responsibility, but cohesively. Everyone belonged and contributed to the team’s mission.

The function owned very little directly.

Most solutions still required Product, Engineering, or Leadership to take action.

Success therefore depended on influence rather than authority.

Weekly operational reviews, escalation frameworks, service ownership models and cross-functional investigations created shared understanding of priorities and responsibilities.

The goal was never additional bureaucracy. The goal was alignment.

As trust increased, the function became a neutral coordination layer capable of supporting teams solve problems collectively rather than defending their own domains.

Very soon, there was a clear behavioural change on every team.

Over time, Product Operations became a central capability and coordination layer supporting operational excellence across the organisation, the product and the platform.

• Teams gained clearer accountability.

• Investigations became faster.

• Decision-making became increasingly evidence-based.

• Customer-impacting issues were addressed through coordinated action rather than isolated efforts.

More importantly, the organisation developed a stronger culture of shared ownership.

The lasting outcome was not the processes, dashboards or governance structures.

It was the creation of a function and very strong team capable of connecting people, data and decisions across a complex organisation.