Product Operating Model for Shared Services Teams

The handoff point between development and operations is a common source of frustration, delays, and rework for everyone. Business Operations / Shared Services teams are surprised; their operational considerations are much harder to address when they come when the solution is already built, and everyone is hoping to celebrate and move on. Reducing this friction requires involving operations early, making dependencies visible, and optimizing end-to-end flow metrics. Late-stage handoffs are a predictable source of rework and delay.

(Note: One specific example is GTM (Go to Market) activities. GTM Teams simply LOVE it when they’re brought in after they have zero opportunity to shape the product. This is a classic question in the relationship between Product and Marketing. There’s more to say about this specific example, but the principles we outline here are a good start)

The DevOps approach was created to help streamline and improve this handoff/interface. While developed in the context of Technology Operations, the principles apply to any sort of operational work: 

• Understand how work flows through development to operations. Notice bottlenecks and patterns, and start thinking about how to create a leaner, more streamlined flow of value. This can be achieved by managing work such as Features through an end-to-end Kanban system that includes the operational steps needed before business as usual.

• Move beyond “us vs them” to a culture of shared responsibility for innovation flow, business uptime, quality, and related outcomes. Shared KPIs, more frequent interactions, and more frequent delivery all help.

• Automate to enable faster flow and feedback. The goal in the Product Operating Model is to deliver frequently, learn, and steer continuously. Delivering frequently burdens business operations if there’s a heavy manual transaction cost in the delivery process. Automation along the path to operating capabilities and products in production is a key enabler.

• Measure flow, quality, and value - The Product Operating Model depends on evidence to inspect and adapt. Track flow, quality, and outcome impact. The right mix helps teams improve reliability while still evolving services toward higher strategic value.

• Recovery - reduce risk & preserve value - finally, strong ability to recover from mistakes through fast turn around of fixes, enables moving faster and making changes more frequently. 

To dive deeper - check out SAFe’s CALMR approach and Gene Kim’s Three Ways

Again, all these principles were created in technical operations but can map nicely to business operations. Specific questions to consider: 

• What’s the appropriate way to model business operations readiness work in the Kanban systems ARTs use to manage the flow of Features?

• What’s the best way to engage business operations representatives in the work of the Development Value Streams/ARTs?

  • During activities such as PI Planning where the upcoming quarter is planned and dependency on partners such as business operations can be considered and taken into account? 
  • To weigh in on refining a Feature into Stories? 
  • Capture business readiness acceptance criteria as part of the non-functional aspects of the Features/Stories? 
  • Join Planning Sprints where business readiness interaction is needed? 
  • Review Sprints to provide feedback and steer from an operational perspective? 

• What are the biggest challenges for more frequently delivering through to the business? What are some manual steps that could be automated or simplified or otherwise improved to reduce the overhead and enable higher frequency? 

• What do we need to measure to enable and streamline ongoing business operations? Mainly to reduce the risk of accepting changes more often? 

• How can we streamline recovery from business operational issues - mainly resulting from new deliveries but not limited to that context. 

Another question that often surfaces is whether it makes sense to use the Agile ways of working of the Product Operating Model in business operations. There’s a big difference between developing services/products and running/operating them. Developing products is almost always a probabilistic endeavor, rife with uncertainty and discovery. Agile/Adaptive ways of working are designed to help derisk and maximize outcomes in this context. This is a core part of the Product Operating Model (also known as Agile Product Operating Model). 

Running/operating services could be both probabilistic and deterministic. Sometimes even in the same type of work. Take cybersecurity for example. Much of cybersecurity operational work is deterministic - routine vulnerability scanning, configuring security products for new users / services, System patch management. 

There are spurts of probabilistic work with higher uncertainty - think threat hunting, incident impact assessment or zero-day vulnerability management. 

Let’s take another example - legal operations. Drafting/reviewing standard contracts, regulatory reporting compliance are a few examples of deterministic operational work. Handing a regulatory investigation, assessing legal risk exposure for a new product/capability, evaluating compliance in emerging regulations (e.g. cryptocurrency) are some examples with more uncertainty. 

Why is this important? Deterministic work can be managed using a “factory”, output-focused flow approach. There’s still value in understanding and improving flow, shaping demand to available capacity, reducing juggling, delays, and rework. But there’s not as much of a need for empiricism and the tight feedback loops provided by agile ways of working. 

Don’t rush to copy-paste ways of working from product development to operational work. Shared services teams don’t always need to adopt Scrum to work in a product operating model. Choose ways of working based on uncertainty and flow characteristics. Some teams benefit most from Kanban and flow management, not sprint mechanics.

The first question an operations team should ask themselves is what’s the balance between probabilistic and deterministic work and use that to determine whether it makes sense for them to fully use agile ways of working such as Scrum Sprints, or to focus on understanding and improving flow using, for example, a Kanban approach to work management. 

Even deterministic teams benefit from an inspection and adaptation loop for their working methods. Techniques such as a cadence of retrospectives work well to help teams improve their processes, teamwork, and overall outcomes. 

Inspecting and adapting their work can also result in ideas for innovating business operations capabilities. What can we do with these ideas? 

If they require product capabilities, Introduce them into the intake process for the Development Value Streams and have representatives of business operations support/guide their development as stakeholders, or even join the team working on them to help hands-on in the trenches. 

If they don’t require product capabilities, Apply the Product Operating Model within business operations by creating a mini-development value stream/team. Product Ownership prioritizes a backlog of ideas and explores/develops/deploys these ideas into the operation. 

Some questions operations teams can ask: 

How can we productize our services? What can we automate? What can we systemize and expose as self-service? 

There might be many opportunities – which of them is most valuable? What would create the best outcomes for the people you are serving? What would let you serve more people more effectively? 

Once teams start to think this way – Many aspects of Product Thinking and a Product Operating Model suddenly become useful. Agility becomes a helpful way to navigate the uncertainty of which self-service capabilities will be consumed and which will be rejected…

Even in this mode btw, the team would probably work on a mix of “run the business” operational work and “developing the business” improvement work. Be careful where and how you apply ways of working to support these two very different work styles.

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