Clients vs. Customers: Why Internal Products Fail

A product lead in Malaysia told me his company wanted him to build "data products."

He'd been promoted from data engineering into a product role at a consultancy. His directive was to create repeatable solutions for real estate developers, something the firm could sell to multiple clients instead of rebuilding from scratch every time.

Good idea. Wrong assumption about how it would actually work.

Two business models that look the same but aren't

His company was a services firm. Consultancies make money by saying yes. Every time a client asks for something custom, the firm bills for it. That's the revenue model. More requests, more revenue.

Products work the opposite way. You build one thing that covers 80% of what many customers need. And you say no to the other 20%. That discipline is what makes the economics work.

I use two different words for these because they create two different relationships.

Clients get everything they want. Customers get the main thing they need.

His firm called it a product. But the partners would always sell it like a service, saying yes to every client request, customizing every implementation. Because that's how the business model rewards them.

So his "product" would never actually be a product. It would be a template with heavy customization per client. Knowing that upfront changes everything about how you plan, price, and staff.

The licensing revenue trap

This is where most consultancy product efforts die.

The math always looks good on the whiteboard. Build the solution for Client A at a million dollars. Charge them $100,000, subsidize the rest, because you'll sell the same thing to Clients B, C, and D.

Then Client B shows up with different needs. The custom work still costs $500,000. You charge $100,000 again.

You keep telling yourself the next one will be cheaper. It never is. Because every new client has requirements that don't fit the template, and the firm's sales team has been trained to say yes to all of them.

You end up with a portfolio of custom projects priced like products. The economics never catch up.

I asked Jackson if his firm had ever successfully built a reusable product before. I asked because I already knew the answer. This model is common in consulting. The execution almost always fails.

I've seen this pattern a dozen times. It hasn't worked once.

Why the product PM always loses this fight

The consultant-turned-product-PM faces a structural problem. The firm's incentive system works against them at every step.

Partners are compensated on billings. Custom work bills more than product implementations. So when a partner is in the room with a client and the client asks for something outside the product scope, the partner says yes. Because that's how partners get paid.

The sales team sells the way they've always sold: by promising flexibility. "Of course we can customize that." It's how they win deals. And every customization erodes the product's reusability.

Finance evaluates the product investment against the first few implementations and sees negative ROI. The breakeven was supposed to come from repeat sales. But repeat sales keep requiring custom work. So the product never reaches breakeven, and eventually someone questions the investment.

None of these people are wrong. They're all doing what the system rewards them for doing. The PM is the only person in the room with a different objective, and they have the least organizational power.

Three things that actually work

I told Jackson three things.

First, price every engagement at 100% of the actual work. Don't discount the first client hoping you'll recoup it later. If it costs a million dollars to build, charge a million dollars. When you subsidize early, you're betting against your own business model.

This is hard to sell internally because the investment pitch was probably "build it once, sell it cheaper many times." But the data says the "sell it cheaper" part doesn't happen. So charge full price, deliver excellent work, and let the reusable parts emerge naturally from actual implementations.

Second, push the licensing conversation as far into the future as possible. The partners will be attracted to it. Tell them you need a few implementations to learn what's actually reusable versus what's always custom. Buy yourself time with honesty.

Most product efforts in consultancies fail because they promise licensing economics before the product is mature enough to deliver them. Three implementations is not a product. It's three projects with shared code. You need at least five or six before you can credibly identify the 80% that's truly reusable.

Third, focus on case studies, not licensing rights. Get permission upfront to document the business results. Not "we deployed a solution." Document "their sales team increased revenue by X% over Y months."

Peer credibility sells the next deal. Real estate developers in Malaysia will buy from a firm that's already helped a company like theirs succeed. Features don't close those deals. Stories about outcomes do.

You probably don't work at a consultancy. This still applies.

Most product teams have their own version of this trap. You ship features because the internal system rewards shipping. More releases, more velocity, more Jira tickets closed. Nobody asks whether the customer made more money because of what you shipped.

PMs who say yes to every stakeholder request are running a consulting firm inside a product org. They're serving clients, not customers. Every custom feature, every one-off dashboard, every "can you just add this?" is the same dynamic. Saying yes creates short-term goodwill and long-term product bloat.

The question that separates PMs who get promoted from PMs who get managed out: how does your customer make money, and how does what you're building help them make more of it?

Your job is to figure out which 80% matters most. And protect it from the 20% that wants to turn your product back into a services shop.

How to tell the difference in real time

Next time someone asks you to build something, ask yourself: am I being asked to serve a client or a customer?

Client requests tend to come from a single stakeholder asking for something nobody else has requested. The customization only applies to one use case. And scope grows with each conversation. "Can you just add this for us?" is the telltale phrase.

Customer requests look different. They show up as patterns across multiple users or accounts. The problems are confirmed by usage data, not just feature requests. The needs fit the product's core value proposition. And you can define and contain the scope.

When you catch yourself saying yes to a client request, pause. Ask: if I build this, does it make the product better for all customers? Or does it make one stakeholder happy at the expense of product coherence?

Next time you write a product brief, feature spec, or roadmap item, try adding one section at the top: "How this helps our customer make money (or save money, or reduce risk)."

If you can't fill it in, that's the gap. Close it before someone asks you to.

Keep reading: The multi-customer challenge gets even more complex in B2B2C product strategy. The underlying skill that helps you prioritize across personas is business acumen: knowing how each customer type connects to how the company makes money.

Want to see where you fall? Take the free 5-minute PM Diagnostic.