TBM 8/52: The Problem With “Internal Customers”

In this post I argue that the concept of an “internal customer” is flawed, and that a better distinction is “partner”. To get there I’ll draw on “customer-facing products” for inspiration.

Most B2B SaaS companies are actually B2B2B or B2B2C SaaS. They look like this:

They need to understand how their customer's businesses work, which will likely entail understanding their customer's customers. If they focus only on solving the problems their customers describe, they might make their customers happy, but they may not help them make money (which will hamper renewals and expansion).

This dynamic is especially tricky in an emerging technology or market landscape. When new products challenge existing ways of working, they often find themselves in the change-management business. They aren't just selling a product but a new way of working.

Why does this impact "internal products".

Internal product teams are in the same boat—with an added twist. It looks like this:

Internal products help “internal customers” deliver products and services to help external customers. Four steps! But “internal customers”: 

1. Don’t always know what they need. 

2. May know what they need to accomplish but are (hopefully) relying on the internal product team to figure out how. The internal product team is an expert in something.

Back to our example with B2B2B SaaS, an internal product team will likely need to have a perspective on the product/service AND the customers out in the world to develop that strategy.

Here's a basic diagram from when I was a search product manager. Confusingly it is the opposite direction of the diagrams above—the end user is on the left, and the “internal product” is on the right—but you get the idea.

What's important here is that there are some generic aspects to search. But to provide valuable services, it was necessary to know what the humans out in the world needed to accomplish—both our external customers (the agents) and their customers (the humans out in the world needing help and support). With that knowledge, we could support our “internal customers”.

It would be easy to think about the entity services in isolation—as standalone services disconnected from their eventual use-cases—but that detaches us from real customer value.

This is why I very much dislike the concept of an “internal customer”. 

Yes, customer-centricity is valuable. Yes, it is essential to consider the needs of your internal partners. Yes, it is important to imagine that they can "shop elsewhere" for what your internal product offers. Yes, you should apply all sorts of product and design practices to deliver excellent internal products. All of those things are true.

But in most cases they aren't your customers (in some companies, money does change hands, but that is an exception)! They are your partner in the company's quest to help external customers. Partners collaborate and don't lob requests. Partners trust each other's expertise. The power dynamic is different between partners.

You never want to encounter an internal product team that sits back and says, "well, we delivered the use cases they asked for," when those use cases didn't provide eventual value to external customers and the company. Or a team that says, "we have five 9s on the service we promised, and all of our operational metrics are amazing; job well done!"—when NONE of the “internal customers” were ultimately successfully delivering value externally.

Internal teams must embed with their partners, especially with emergent use cases. They shouldn't rely on tickets tossed over the wall. Sure, when things calm down and the use cases have stabilized, there can be more distance. But initially, it is a startup situation with high-touch partner collaboration.

The progression might look like this.

Only in latter stages can we distance the internal product team from the external reality, and even then we rely on the internal partner to share context. We can do this when the use-case is much more stable and understood.

It is about this point where someone says something like:

I insist that internal teams use the word “customer”! I want the teams to care. I want them to remember that their internal customer can opt out and go somewhere else. I want them to feel the pressure of having a real customer, instead of them writing things off because their users are internal.

I get the sentiment, but I remind them that businesses fire customers all the time. “Can you fire your customers?” I ask. Can you 86 them?

Um….

At least in the companies I talk to, it is a lot more common for “shared” teams (e.g., platform teams, enabling teams, etc.) to be passionate about helping, yet overwhelmed, and struggling for support.

Hence why I think “partner” is far better than “internal customer” OR “stakeholder”.