Treat your operating model as a product

I ran a product and technology-led capability in an agency for around a decade, and the way it worked changed continuously over that time. Our first design sprints, in 2016, were the first example. What followed was a deliberate effort to introduce product thinking, and from 2021 the capability was recognisably product-led. A similar pattern then repeated across product, engineering and design in different areas and dimensions: foundational areas like composable architecture and design systems, the way we put team shapes and proposals together, adoption of frameworks and approaches like continuous discovery and automation.

Each change started somewhere small, as a small bet or an experiment, and became the default. We didn't design a model and launch it in one moment. We evolved it gradually, shipped different versions of it, took the lessons and went on to the next iteration.

In short, and with a sprinkling of hindsight, we treated our ways of working (process and culture) and the team (structure and skills) – the operating model – like a product.

Why this is (more) important now

What's different now is AI, because of the speed with which it's changing things and because it's a disruption of creation and cognition rather than of a channel. At the moment nobody can see the full shape of what AI does to work and how it gets done. In that kind of uncertainty you have no choice but to redesign the operating model; the question is how. Redesign done in thin slices, with the feedback arriving before the true cost does, beats a big bang or a-to-b approach.

Designed once, lived with

Too often I see an operating model treated as structure. You diagnose, you design, you announce, and then everyone lives with it until it's visibly wrong enough to do again. In my mind I compare this to the infrequently released products of the old world: a monolith, very often built in silos, lacking anyone who actually owns it as a product. The feedback loop is slow or broken, so the only signal you ever get is decay and a downward trend. It can also be a political problem, where the redesign is more about the narrative and perception of how the business is run than about outcomes and impact.

What I mean by treating it as a product (a thread I've talked about before) is applying systems thinking and product thinking to how the function works. It's something with users. It's something you do discovery on. It releases in versions, ideally often, and it gets iterated on in a feedback loop. Treated that way, an operating model puts behaviour ahead of structure. Product's habit of cross-discipline collaboration is valuable for the speed of iteration on its own, but I think the deeper effect is that outcomes end up jointly owned rather than each discipline or unit owning its outputs in its own area.

I'd argue certain capabilities have always needed this more than others, and the ones facing change or disruption are the obvious cases. For me that's the story of digital, technology and product capabilities over the last two decades, though the observation applies just as well to startups and product-led companies in general, and it's something I've noticed with AI adoption too: engineering and product teams tend to adapt faster because short feedback loops and empowered teams are already how they work.

What we actually did

To illustrate this, I'm using my own experience of operating model as product during my time running the Products & Platforms capability at Digitas (mostly pre-mainstream-AI). It's a deliberately long-running example, but the same lessons can be applied for much shorter runs too. The fuller account of what that capability became is in Evolving Products & Platforms, along with the chronology. I also want to stress it was done as a team, with some very notable champions and deep subject matter experts.

The headline change was introducing product into the agency, and the key approach was something inspired by product trios: disciplines jointly owning an outcome rather than sequentially owning their own outputs. It replaced an approach where strategy and client service led and work flowed down the line, which suited campaigns and production, but got expensive once the deliverable was a product or experience that was continually iterated.

It wasn't one clean plan. There was an overarching goal, and absolutely an ambition and an appetite to change to go with it, but inside that it was small things: short-term experiments, some of which spread and some of which didn't. Most of the time, while it was actually happening, I explained it to the team as continuous improvement, which gives the game away a little. It was continuous improvement rather than a big bang, and a very deliberate culture of it.

If I'm honest, we never reached the full ambition for a product-led operating model, and this was never trios as a startup would recognise them. The implicit constraints of an agency-client relationship were harder to crack than I expected: someone else holds the roadmap, the risk and the money. There's a lot of room inside that constraint, but no pretending it's absent.

Users, discovery, iterations

The product framing is an abstraction, but the mechanics were real, so here they are.

The users were our teams first and clients second. Discovery was listening to the experts who knew their areas well, and looking for unmet needs: where work snagged, the same hand-off going wrong, the same decision waiting on the same person, the same conversation happening three times in three disciplines. That was true of clients as much as of us.

An iteration was partly the shape of the team on an engagement, and partly the way we worked together inside it. That was everything from the shape of a product trio, and then different versions of it because most were in-between states, through to things that were more technique, skill and framework: design systems, microservices, continuous discovery. Very often it wasn't inventing anything. It was incubating the best ideas from outside, bringing them in and evolving our own practice with them. A lot of it came down to principles over process.

It's a big unit of iteration. You get one when an engagement starts or changes, and then you wait months to learn anything. The count across a decade is small compared with any software product and large compared with a reorg cycle. "In production" was a useful test: people worked that way by default when nobody was watching.

Three interrelated ways of thinking ran through it: systems thinking, design thinking and product thinking.

Systems thinking meant thinking about the whole capability across disciplines rather than each discipline separately and then seeing how things came together. It's the difference between connected leadership and integrated leadership: not connecting disciplines but integrating them around outcomes over outputs. It also meant recognising that an improvement mattered beyond any one initiative or client, and making the investment or running the experiment for a long-term benefit, which is a very different horizon from the one an agency usually works to. Donella Meadows' point about leverage is the underlying reason: moving boxes is low leverage; changing the rules and who gets to self-organise is high leverage.

Design thinking meant the team was the user. We ran workshops to define the future of the capability and wrote playbooks that were consciously about the roles people would play in it, and the early design sprints we ran on internal work were, in effect, prototypes of the operating model before we took it to clients. From a leadership point of view it meant thinking about people's development with the same continuous-improvement attitude, which didn't always mean good news for everybody, but was about the greatest net positive for people overall. It meant championing and advocating for individuals, encouraging closer connections between teams, and caring for the culture. For me, thinking about the user was thinking about how we built trust, how people came to feel safe, and how they knew someone had their back. That was needed top-down and bottom-up. The aim was to create the conditions for people to do the best work of their careers.

Product thinking meant outcomes over outputs. Delegate, give people responsibility and accountability for something whole, whether that was an improvement initiative or a client relationship, and encourage them to come with their own ideas rather than treating delivery as a checkbox. Sometimes that absolutely meant putting process in, for more rigour about getting to the outcome, but it was always in service of the outcome and never of the process. The clearest example was the move from project-management attitudes to delivery management: delivery taking ownership of the deliverables rather than managing the team that produced them. We used product trios not because trios are a good process but because they got better outcomes. The same test applied to everything we adopted from outside, whether alpha, beta, live and growth, continuous discovery, design sprints, automated visual testing or a tool like Figma early on.

If you take a typical description of the product operating model and swap "product" for "how we work", every sentence still holds.

The version that cost something

The examples so far are about a capability. The operating model also changed inside engagements, and one in particular is where the thesis got tested.

A mobile programme for a large client shifted over roughly two years from a UK-based team to a distributed one across the UK and India, and at the same time from outsourced to in-house. The visible part was the changing team shape and casting; it was the model underneath that mattered. None of it followed the traditional agency path. What I think was important is that the team helped design that transition, knowing the model was shifting, and took responsibility for the outcome, well aware that the destination reduced their own role. That takes a great deal of trust. Joint ownership of an outcome is easy to agree to when the outcome is growth, and means something more when it isn't.

It didn't work completely. I honestly believe the speed and quality would have been higher had the work stayed outsourced and in the UK, but the reality was that it didn't fit the cost envelope. Harder to see at the time, and easier to articulate with hindsight, was that the core product already existed and was well into its growth period, so in a lot of ways the value had moved from building to harvesting. With a commercial hat on, I think that was the right trade against the constraint. It's probably not the design I would have chosen freely.

A second engagement worked the other way round: short opportunity and proposition sprints, linked to design sprints, helping to deepen strategy and turn product articulation around in weeks rather than quarters, with a small team and a different way of working from the one we usually had with a client. It required ambition and trust on both sides. It got to some strong ideas fast, and some of them were made and released. What was harder was sustaining those ideas in operation afterwards. Partly that was the client's own model, built for experience- and marketing-led execution rather than products, plus the challenge of pushing anything new through a large organisation. Partly it was on us: we never got to a strong enough business case and business model, in part because we didn't have access to the right data, which is one of the standing challenges of working as an outsourced professional-services supplier.

The variable was a person

Experience says that in hard change the biggest difference is almost always a person. I underestimated this badly at the start. I thought I was changing ways of working. I was mostly finding, backing and protecting champions, which makes trust and safety the actual work, and it's what Amy Edmondson has been describing since 1999 as psychological safety. Where there was someone in that position the change took. Where there wasn't, it stalled, because it is people that carry change, lowering the friction and taking the risk out of it.

The same two engagements mentioned above show this. On the mobile programme, the client-side lead moved from project-manager behaviour to product-manager behaviour. She backed our team, worked closely with our mobile lead, and more impressively changed how she worked herself, inside a large and fairly traditional organisation that gave her no particular reason to. She had an internal advocate of her own. That mattered too.

On the proposition work, it was our own product lead, who insisted on keeping things lean and acted as the guardian of that way of working, pushing both the team and the client when either drifted, while building a strong enough relationship with the client that the pushing was welcome.

None of that happens without sponsorship and good leadership, and that was my part: creating the environment in which those two could do what they did, and sustaining the relationships that made it possible. It was also important for me to be a close collaborator in the work itself, especially when we were doing something new or for the riskiest assumptions. That was perhaps the biggest lesson for me as an individual. The overall responsibility was to be a steward of the system, to create and nurture it, while also advocating and creating opportunities for the people in it. I think I was at my best when I did that by also being actively involved in the continuous improvement and in the work that seeded it.

Doing it in an agency was hard

I've described this carefully, and with some anonymisation, as a story, but I'm not going to pretend it was easy. Every situation, context and environment has its own difficulties. Doing it inside a digital agency was hard because there was a trade-off between changing to a product-led model and short term revenue and margin considerations, as well as perceived risk and wider prioritisation. It was also pushing against a traditional agency structure and way of working that was well established.

Moreover, I found that the client work that came in tended to set the ceiling. Being honest, some clients weren't ready. Some engagements were straightforwardly delivery, where frankly we'd been brought in as extra capacity, and product ceremony would have been theatre. There was internal resistance too, some of it conscious and a lot of it not. Most of that was driven by changing what people were accountable for, and to a lesser extent by not yet understanding a product mindset. As a leader I have to take responsibility for elements of both. It's the difference between doing this in the real world and doing it in a textbook.

Equally, some things sat on the plus side of the column. Internal work could often move faster than client work, which made it a good place to be wrong cheaply and fail fast, and I deliberately extended that attitude to initiatives like design systems and composable architecture: do it on one project, then it becomes the default, then it's something we pro-actively take to clients. Anyone with a product mindset will recognise that as running a set of experiments.

Candidly, a lot of this is a clearer narrative in retrospect than it was at the time. I'd describe it as instinctive product thinking, and instinctive systems thinking, because that was my strongest background, but it wouldn't have happened without some fantastic product thinkers in the team, and it went hand in hand with introducing product as a discipline. I really don't think it would have been possible otherwise. And it was adopted across all the disciplines, not just product, which comes back to the overriding lesson: creating the environment, the trust and the safety, that lets people do their best work.

On numbers, and with the caveat that some of this is judgement: teams got around 20% smaller for similar work, and the mix of disciplines changed, with product notably up. What I'd highlight is that smaller teams, or in some cases similar-sized ones, got better at getting the right thing done. Team and client sentiment improved, and so did satisfaction scores and the complexity of what we were delivering. Interestingly, being on time became less of a measure, because the traditional agency thing of a fixed scope to be delivered started to dissolve into partnerships about the right product or experience against the reality of business timelines. That wasn't true of every engagement, and the irony is that it was where timelines mattered less that I'm fairly sure we delivered value faster.

The thing I find most remarkable, looking back, is that some of the clients who worked directly with us this way became the biggest advocates for it, and for the reliability and quality of what came out. The caveat is that we didn't always do a good enough job of communicating that to their stakeholders, the next level up, who weren't in the detail and couldn't feel the difference. That applied internally as much as externally, and it's something I should have taken more responsibility for, so it's something I'd want to do better in future. It comes back to people remembering how you made them feel, and that feeling is strongest in the people doing the work day to day.

No ideal end state

None of this was really about the frameworks, despite them being the visible part and relatively easy to articulate. What really changed was people holding themselves responsible for an outcome together, rather than for their own input or output, and that change is slower, human-led, and impossible to install by decree.

That's also why it never finished. Every time we learned something the target moved, and there was always something to improve. As with product, there was always the next thing to iterate on, a bit of feedback to act on, an ambition to go further. At first it was a bit distressing to be so far from the ideal; it started to feel like a Sisyphean task, or a mountain with too many false peaks. Yet I came to treat the distance to the ideal as the condition you operate in rather than a shortfall, and I want to be clear that was pragmatic and realistic rather than resigned. You have to keep the desire to get better, and you have to accept that you're doing it inside an agency's economics, priorities and incentives, or any other organisation's (though the critic inside me wishes I'd been more rebellious at times). If the end state is stable, design it and launch it. If it isn't, the only model that survives is one you iterate.

Why do it this way

Do it this way because the uncertainty in how work gets done rewards a flexible, iterative approach. There is, of course, an undercurrent to this argument, which is that AI is already changing your operating model whether you have a view on it or not.

The commentary here is arguably ahead of the evidence, but most of us can feel it happening, and the evidence is arriving. Dell'Acqua, Mollick and colleagues' field experiment at P&G (776 professionals on real product-innovation tasks, "The Cybernetic Teammate", 2025) found individuals with AI matching the performance of teams without it, and found the usual split between R&D and commercial thinking dissolving: people produced balanced solutions regardless of their function.

A year on, BCG's September 2026 study of fifty-odd firms furthest ahead with AI found that in more than half of them leadership now sets the direction while individuals and teams own the outcomes, with decision rights pushed down and tied to how reversible a decision is rather than to seniority.

Deloitte's description of what early adopters are finding, from the same year, is the other half of the picture: bolting autonomous agents onto an operating model designed for human workers is, in their phrase, like fitting a jet engine to a bicycle.

It was the same argument I heard in almost every business session at SXSW London in June: redesign the work before you bolt the technology on. Read that alongside the benchmark evidence I wrote about last time, where the length of task an agent can finish on its own has been doubling roughly every four to six months since 2023, and the shape of the problem is clear. AI-driven compression is responsible for reshaping teams and shifting constraints. Sequential hand-offs by discipline are active constraints for an AI-native team, while human judgement and joint ownership of an outcome become even more important.

I made a related argument in Loops within loops: product work has always run on feedback loops, and AI changes their economics. Loops become a mix of humans and machines (e.g. Product Idea Pack), which compresses them, but it also lets you afford more of them, running in parallel, across disciplines that used to wait for each other. An operating model that can only change through a reorg cycle can't keep up with a team whose loops are getting shorter and more numerous every quarter. It really is a case of iterate or be iterated upon.

The human element

A huge part of this has nothing to do with AI. After ten years of evolving teams, I still think people are the thing that matters most in a change of any kind. What's more I'd say that people are genuinely more fearful of AI-driven change than anything I worked through in the last decade, which makes trust and safety even more important.

It's also about leadership done the right way and a systems view that looks at the whole rather than individual parts. The best teams I've worked with had that collective view and an internal ambition, almost a contract, towards outcomes. Both of these are at the heart of a product thinking mindset and operating model as a product.

As a leader you have to commit to that visibly, so people know you're in the change with them and that you've got their back, and you have to be committed to listening and adjusting, because nothing is ever completely fixed. That takes active listening. It takes empathy. It takes an ambition to be better and to bring that out in other people. It's more or less how I arrived at high standards and high humanity as a way of describing what I try to do: the standards are why you keep iterating, and the humanity is why anyone lets you.