Product Management Thinking Needs Translation for Service Businesses

I spent two weeks working with a company that provides advanced user and usability research services. Over the years they built a powerful platform that enables both their internal service teams doing research, and customers who license it for their own research needs.

But when we started talking about product management, I heard the same doubt that has plagued me through my own career. They had read articles online, attended local product meetups and conferences, looked for guidance from the larger product community. And the ideas they found made sense, but for some reason they weren’t lining up to their digital product. The examples came from companies like Spotify or Netflix or Slack, companies where the software itself generates revenue. At service companies, customers pay for the service. Software helps deliver that service.

Why Standard Product Metrics Don’t Apply

At an airline, the digital product team makes money when people buy tickets and fly. The product’s job is making travel booking work smoothly and giving customers ways to manage their trips themselves. A social feed where passengers share their travel photos or a gamification system with badges for app usage just creates work for the product and dev teams that don’t drive business value. A feature that cuts call center volume by 40% while customers are happier represents success measured through how efficiently the service operates.

How value flows through a services business works differently than a traditional software company. Digital products are built to help customers buy, use, and interact with the service. Every product decision involves real tradeoffs between two different but overlapping user groups. Service teams need tools that make their work faster, and customers need ways to solve problems themselves without waiting for help. The service teams and customers are both working with the same service transactions and data. When an agent helps someone change a flight and when that customer changes it themselves, they’re both accessing the same booking. The digital product has to make that service accessible from both perspectives.

Measuring value for digital products at a service company is different than pure software metrics. Impact shows up across the entire service operation, spread throughout multiple systems and touchpoints. A good product decision might reduce how much service team capacity you need, improve satisfaction scores, enable revenue growth through better service delivery, or decrease operational costs. In telecom, we measured success through how digital usage reduced support calls and cut costs. The product succeeded when it enabled both the service teams to deliver the service effectively, and customers to use the service they paid for effectively. Improvement was measured against important interaction points like paying a bill, submitting a ticket, or pulling reports of service performance over the last year for annual planning.

For example, at Charter we built online ticketing so customers could submit service issues through a portal. The intent was to deflect calls to the support team, but we discovered a different behavior. Customers created tickets then called anyway, because they wanted to discuss the details of the call but circumvent the up front conversation and ticket creation process. Basically, they wanted to get to the meat of the problem. Standard product metrics would have called this a failure, but instead we reduced the time both customer and agent spent getting to the actual issue resolution. Instead of deflecting the call completely, we enabled a better interaction between the customer and the business.

How Service Companies Build Digital Products

Digital products are developed in services companies in two ways.

Some service companies start developing software and internal tools built specifically to help the service team do their work better. After a while it’s easy to see that the same features and capabilities they built for the internal employee can be extended to customers so they can do some of those tasks themselves. The research services company worked this way. They built their platform for internal service teams first to improve how fast they could deliver research while keeping quality high, then made it available as a licensed platform so clients could access the same advanced capabilities for their own research needs.

Other services already have operational systems built for specific functions, but those systems were never designed to work together or provide digital capabilities or interfaces. In airlines, reservation systems handle booking, departure control systems manage check-in and boarding, and customer service systems track issues and interactions. Each system is purpose built and functions well for the job it does at the company. The digital product team then builds the layer that unifies customer experience across these operational systems without replacing them. Customers want to book a flight, change their seat, check in, and resolve issues through a single interface that understands their complete travel context. This means pulling data from multiple operational systems and presenting it in a way that makes sense while pushing customer actions back into the right systems.

These patterns only work when every investment serves both internal efficiency and customer self-service. Customers need visibility into the service they are paying for and self-service tools for interacting with that service. Service teams need all of the same information but for different workflows that help manage or adjust the service on behalf of the customer. The product succeeds when it enables both the service teams to deliver the service effectively, and customers to use the service they paid for.

Measure What Actually Drives Value

The doubt you’re feeling isn’t because you’re missing something about product management. It’s because every article, every book, every case study starts from “software generates revenue” and you’re working backward from there trying to make it fit.

Start from the service. When you’re planning your next feature, don’t ask “will this increase engagement?” Ask “will this reduce the service capacity we need while customers are happier?” Don’t measure success just through daily active users. Measure how customers and the business benefit from that usage. Track call deflection, service team efficiency, and customer satisfaction with the service they’re paying for.

You’re doing sophisticated work that most product managers never touch. Start measuring it that way