Lazy Engineers Love The Product Operating Model

“We are a team providing services, why should we care about this new Product Operating Model?” I hear versions of that question from shared services and operational teams. The hidden assumption is that product thinking only applies to customer-facing product teams. It does not.

Meet Yuval. Yuval is an engineer on the IT networking team. They are a shared services team responsible for the organization’s networks and for helping application teams get their applications working in production. It is 1995, PowerBuilder UI over SQL*Net accessing an Oracle Database is all the rage. The term DevNetOps is decades in the future, but the shape of the problem is already there.

Yuval and his colleagues are lazy in the useful engineering sense. They enjoy helping application teams once in a while, but it gets repetitive to drive to a remote branch and discover, again, that the new application is not tuned for the slow network between the branch and HQ.

The team comes up with an idea to improve the service: provide a simulated branch environment at HQ and offer application teams a way to test in the lab before release. That is already product thinking. The service team is looking at repeated customer pain, designing a reusable capability, and changing the work so future teams can learn earlier.

Time passes, and Idan, an even lazier colleague, sees the next improvement. The lab environment still requires work from the network engineering team. He builds a simulator that can run on the developer’s own PC. Idan just turned the networking engineering team into a platform team that enables developers to self-serve.

What is happening here? The team is providing an ongoing service while also improving the service. They are treating the service as a product. They are constantly asking how to create more value for the organization with less repeated coordination and less avoidable work.

Fast forward 30 years.

Shared services teams are still asking why a Product Operating Model applies to them. If you care about improving the services you provide, or if you are struggling to serve demand with limited capacity, you need to think about how to productize your services. What can you automate? What can you systemize and expose as self-service? Which opportunity would create the best outcome for the people you serve?

Once teams start to think this way, Product Thinking and the Product Operating Model become useful. Agility helps navigate the uncertainty of which self-service capabilities will be consumed and which will be rejected. Flow helps manage demand. Product ownership helps the team decide which service improvements matter most.

That does not mean every shared services or operational team should use agile/product ways of working for all of its work. Repeatable operational work may be managed better with flow and service-level thinking. But developmental or capability-improvement work is different. That is where product thinking earns its keep.

So if you provide a service, think about where product thinking can help you become the team people are relieved to work with.

Designing and evolving a product operating model is one of the most useful things a product leader can do. Explore Product Operating Model advisory or let’s talk.