Accountability Without Authority: Why the Product Operating Model Breaks in Service Businesses

If you’re running a product team at any business you’ve probably read or listened to Marty Cagan’s Transformed. Now you’re thinking outcome-based product management is how you fix your product org, and you’re not wrong. But, if you are building digital products in a services-based industry the “product operating model” needs adapting for how value actually gets created in your business, because it wasn’t designed for service companies.

There are two similar but also distinctly different types of digital product: businesses where the product is the service (such as Salesforce, Slack, and Notion), and those businesses where the product supports the service (such as Delta, Verizon, or Citibank). In SaaS, when the product team improves performance or adds features, customers immediately experience better service. Product teams have more direct influence over activation and retention because the product is the primary delivery mechanism. When changes ship, customers experience them directly.

Services work differently. Your digital product is part of how the service gets delivered to the customer (alongside the call center, the field technician, the retail location). Those customers interact with the service as a whole. They start on the app, call when they get stuck, get a callback, finish in email. You can’t measure product success without measuring service success because customers don’t distinguish between them.

This is what service design calls “frontstage” and “backstage”. What customers see (frontstage) sits on top of operational delivery systems (backstage) owned by other parts of the organization. The digital product is one touchpoint in a larger system of service delivery. When you give a digital product team direct accountability for business outcomes, you’re asking them to move metrics driven by levers that sit in other parts of the organization.

Accountability Without Authority

The product operating model tells you to give teams outcome accountability. In service businesses, that creates a structural problem because digital product teams are held accountable for results they can’t deliver by themselves.

At a telecom where I spent years on the product side, product teams consistently hit their adoption targets. Self-service usage went up year over year. The business outcomes those features were supposed to drive (reduced call volume, lower cost-to-serve) didn’t move the same way. The features worked, and the customers used them. And they still called, because the things they needed help with weren’t things self-service could solve.

Product teams can influence what they build. They can’t control what happens when the customer’s problem requires an operational response. When you hold the digital product accountable for outcomes that depend on operations, you’ve created a structural problem: accountability without the authority to deliver.

SaaS Metrics Are Only Half the Story

The investment community learned to value product metrics from product-led companies. Adoption, engagement, NPS for the digital experience (those became the proxy for company health). Service businesses adopt the same metrics because that’s what money recognizes.

Just look at job postings and you will see this disconnect is commonplace. A national logistics company hiring a Principal PM to own “end-to-end supply chain reliability and customer satisfaction” but the job is limited to building tracking dashboards, not driving change. An airline looking for a Senior PM with “customer retention and lifetime value” as the primary metric, but the job is focused on redesigning seat selection and buy flow, stopping well short of where the service is delivered (gate operations, flight crews, or service recovery). Accountability for business outcomes is expected but authority is only granted to the digital interface.

Making the Product Operating Model Work

So what changes? The product operating model assumes digital product teams can own outcomes end-to-end. In service businesses, they can’t. The structure needs to create shared accountability between product and the rest of the business. Other functions (operations, sales, support, marketing) have to act on what product builds. That means understanding upfront how digital adoption will change their work. I’ll use operations as the primary example, but the pattern applies wherever product depends on another function to realize business value.

Two-Step OKRs

Split the objective into two explicit steps with different owners.

Step 1 (Product owns): The digital outcome. Adoption, task completion, usage of the self-service feature. Product can genuinely influence these through what they build.

Step 2 (Operations owns, Product enables): The business outcome. Reduced call volume, shorter handle time, lower cost per transaction. These require operational change to realize.

Product can’t claim step 2 directly because they don’t control operations. Product can’t stop at step 1 and declare victory because adoption by itself isn’t business value. The win only happens if both steps hit. If Product hits Step 1 (adoption goes up) but Operations misses Step 2 (cost savings don’t materialize), the bet didn’t pay off. This prevents success theater where Product celebrates a launch that saved zero dollars.

The connection between steps is the bet. It forces the conversation upfront: “If we build this and customers adopt it, what will you do differently?” If operations can’t answer that question, the business outcome won’t move regardless of product success. This surfaces the dependency before you spend months building something that can’t deliver results without operational changes nobody committed to making.

Shared Scorecards

When the VP of Product and VP of Sales share metrics (both accountable for upgrade revenue, both accountable for customer lifetime value), the conversation changes. Product can’t declare victory on a self-service upgrade feature while sales reps steer customers away from it. Sales can’t keep comp structures that penalize self-service conversions. They have to figure it out together because the value of the customer relationship depends on both functions working together.

Cross-Functional Ownership

Someone needs explicit accountability for the outcome that depends on both. Alignment helps, but it needs to be paired with actual authority to make binding decisions when the two functions have conflicting incentives.

Imagine a bank trying to move wire transfers to the app. Product wants to remove the “Wire Transfer” option from the call center menu to force digital adoption (their metric is deflection). Support wants to keep the phone option because high-net-worth clients hate typing routing numbers on their phones (their metric is CSAT). Left alone, Product hides the number, and Support gets screamed at by the bank’s most valuable customers.

A service owner makes the tradeoff neither function would choose alone: force digital for transfers under $5,000, but explicitly route transfers over $50k to a human concierge. Product has to build the routing logic (adding scope). Support has to retrain agents to handle complex transfers only (changing workflow). Neither team optimized for their local metric. The service owner was accountable for reducing cost-to-serve while maintaining satisfaction, and that outcome required routing customers to the right channel for their transaction instead of forcing everyone through digital.

Before You Transform

Three questions leaders need to answer before empowering digital product teams with outcome-based accountability:

1. What outcomes can they actually influence through the systems and interfaces they control?
2. Who else needs to change their processes for those outcomes to move, and do they share accountability for the same results?
3. Is your organization structured for shared ownership across product and the rest of the business, with someone who has authority to arbitrate when coordinated tradeoffs are required?

Skip these questions and you end up in a new version of product management theater. The rituals get adopted (squads, sprints, empowered teams, outcome-based roadmaps). Leadership announces the transformation. Everything looks right. Months later, team productivity went up but business outcomes haven’t moved. Leadership blames the teams for not understanding the business.

The teams need the structure to support them. When teams have outcome accountability without authority over the operational factors that determine outcomes, they’re set up to fail. Both pieces have to work together.

The product operating model works. It just needs adapting for service businesses. That means building the structural connections between product and the rest of the organization before you empower teams with outcome accountability. Get that sequence wrong and you will have spent the money on transforming without closing the gap between what product builds and what the business actually needs.