When your user and your customer are different people

A tenant lives in an apartment. They care about whether the hot water works, whether the walls are thin enough to hear every argument next door, whether the heating actually turns on in December. They care about the things you care about when you live somewhere.

The landlord owns the apartment. They care about the yield, the property value, the lease renewal rate. They care about the things you care about when you own something.

Both have a relationship with the building. But when the landlord decides to renovate, they're not fixing the plumbing for the current tenant's comfort. They're upgrading the kitchen so they can charge the next tenant more.

And if you've ever lived through a renovation you didn't ask for, contractors showing up at 8am, your hot water vanishing for a week, the hallway smelling like paint for a month, you know exactly what it feels like to be a user of a product that's being optimised for someone else. The building is changing around you. But not for you.

Most digital products work this way. The user lives in the product. They navigate it every day. They develop habits, preferences, workarounds. But the product is being renovated for someone else entirely. And until you understand who that someone else is, nothing about the product's decisions will make sense.

In most products, the person using it and the person the company is optimising for are not the same person. This isn't a bug. It's the business model.

1. Paying customers can be the product too

"If you're not paying, you're the product." Everyone knows this line. It's become the default explanation for why ad-supported platforms feel hostile. Social media, free email, free search: your attention is sold to advertisers. You are the inventory. Fine.

But the split goes much deeper than free-versus-paid.

Enterprise SaaS is the clearest example. The person using the CRM eight hours a day is not the person who bought it. The sales rep needs the tool to not waste their time. The VP of Sales who signed the contract needs reporting dashboards, forecasting accuracy, and a sense of control. These are different needs. They look similar in a pitch deck. They are not similar in daily use.

But when they conflict, the signature on the contract wins. Every single time. Not because anyone sat in a room and said "the user doesn't matter." But because the incentive structure already made that decision before the meeting started.

I watched this play out at a SaaS company I worked at. The product team had two options for a dashboard redesign. Option A was faster, cleaner, and users loved it in testing. Option B had more executive-facing analytics widgets. Option B shipped. Not because anyone disliked Option A. Because the renewal conversation happened with the VP, not the sales rep sitting in the product every day.

The product roadmap follows the signature on the contract. If that's not the person using your product, you've already chosen sides.

2. Your business model decides who your user is before your product team does

There are three dominant models in digital products, and each one defines "user" differently. It's worth seeing them side by side, because the pattern becomes obvious once you do.

Ad-supported products (social media, search, free tools): The user is the inventory. The advertiser is the customer. The product's job is to maximise time-on-platform so there's more inventory to sell. Every design decision that increases engagement is rational under this model, even if it comes at the user's expense. The outrage algorithm isn't a failure of values. It's a success of economics.

Enterprise SaaS (B2B, procurement-driven): The user is the operator. The buyer is the customer. The product's job is to make the buyer look smart for purchasing it. Features that impress in a quarterly review get prioritised over features that reduce the daily friction of the person actually clicking the buttons.

Platforms and marketplaces (ride-sharing, delivery, freelance): Neither side is the customer in the traditional sense. The platform optimises for the transaction itself. Drivers, riders, restaurants, couriers: all are inputs being optimised, not people being served. Everyone thinks the platform works for them. But the platform works for the platform.

It's like a football stadium. The fans came for the match. But the sightlines are optimised for camera angles, the breaks in play are timed for ad slots, and the premium seats face the broadcast cameras, not the pitch. The fans are the atmosphere. The broadcaster is the customer. The fans just don't know it, because they're too busy enjoying the game to notice who the building was actually designed for.

Your business model doesn't just determine how you make money. It determines who your product actually serves. Everything else is a story you tell yourself.

3. The ride-sharing test that tells you everything

Here's where this gets personal for anyone who builds products.

At a ride-sharing company I worked with, the product team ran an experiment that measurably improved driver satisfaction. Better route suggestions, fewer forced pickups, slightly more control over their shift. Drivers loved it. But rider conversion dipped by a small margin. The experiment was killed in the next sprint review.

The comment in the meeting was revealing: "We don't optimise for supply happiness. We optimise for transaction completion."

Nobody in that room was being cruel. The PM wasn't a villain. The data team wasn't heartless. The business model had already decided who mattered. The drivers were users. The transaction was the customer. And the experiment, no matter how good the outcomes were for drivers, was never going to survive a framework that didn't have a row for "supply happiness."

But this dynamic isn't exclusive to Big Tech. It's in your product too. The founder who builds for investors instead of users during fundraising season. The PM who ships the feature that demos well over the one that works well. The designer who optimises the signup flow for conversion rate, not user comprehension. The startup that redesigns its pricing page to maximise enterprise upsells while making the free tier progressively harder to find.

I've spent 20 years across startups and enterprises, from Adobe to Freshworks to early-stage companies with five people in a room, and in nearly every case, the user/customer split exists. The shape changes. The severity varies. But the split is always there. The only difference is whether the team has named it or not.

Nobody in the room is being cruel. The business model has already decided who matters.

4. User advocacy isn't about always choosing the user. It's about always knowing when you're not.

Here's the part where I'm supposed to tell you how to fix this. I can't. Not in the way you'd want.

The user/customer split isn't something you eliminate. Ad-supported products have advertisers. Enterprise products have buyers who aren't users. Platforms have transaction economics. That's reality. Pretending otherwise doesn't make you ethical. It makes you confused.

But you can be honest about where the split lives. And that honesty changes everything about how you build.

The best product teams I've worked with didn't pretend they were building for the user when they were building for the buyer. They made the trade-off visible. They said it out loud in the room: "This decision serves the buyer. Here's what we're giving up on the user side. Here's how we'll rebalance next quarter." No theatre. No pretending the quarterly analytics dashboard was really about "empowering" the sales rep.

That's not cynicism. That's clarity. And it's the difference between a product team that slowly loses its users' trust without understanding why, and one that makes hard trade-offs with its eyes open.

User advocacy isn't about always choosing the user. It's about always knowing when you're not. And saying so.

The tenant never stops caring about the plumbing. The landlord never stops caring about the yield.

The best products aren't the ones that pretend there's no split. They're the ones that know exactly where it lives and make the trade-off on purpose. Not by accident. Not by org chart. Not by pretending the tenant and the landlord want the same thing.

They never do.