Your Exceptions Are Becoming the Business Model

A year after landing your biggest customers, your engineers are doing three jobs you never planned.

They run a separate copy of your product inside one customer’s cloud, updated only when that customer approves. They maintain a connection to another customer’s in-house system that no one else uses. They take turns on call at night, because a third customer was promised a one-hour response, day and night.

No one chose this. Each job started as a customer exception: one reasonable request, agreed to close a large deal.

That is where it goes wrong. You judge a request once, at signing, when the revenue is right in front of you. The cost comes later, and it keeps coming.

One question at that moment would have changed all three decisions: would you offer this to every customer?

Why the yes comes easily

Take the one-hour promise. At signing, it is one line in the contract. The deal is large, and a no could lose it. So you say yes.

But the promise has to be kept. Someone must be on call every night, ready to respond within the hour. That means a rota, extra pay or new hires. None of it is in the deal. It shows up months later in the engineering budget, and no one traces it back.

The other two work the same way. The copy in the customer’s cloud runs an older version, because each update needs the customer’s approval. The in-house connection breaks whenever the customer changes their system.

At signing, the revenue is large, certain and carries a customer’s name. The cost starts small, is spread across teams and carries no name at all. Research on customer profitability has long found that customers bringing similar revenue can differ widely in what they cost to serve (Shapiro et al., 1987; Kaplan & Narayanan, 2001). Against that, almost any request looks worth it.

The question fixes this. Asking would you offer this to every customer? turns one favour into a policy, and a policy’s cost is hard to ignore. Here, every customer means every customer you mean to serve, on standard terms. The question tests whether a request can be repeated. It does not require giving everything to everyone. There are only three answers.

Yes: build it into the product

The first answer is yes. If you would offer it to every customer, it is not a favour. It belongs in the product.

The in-house connection shows how. No other customer uses that system, so the request looks unique. The need behind it is not: every large customer has in-house systems and wants your product to work with them.

So build for the need, not the request. Make connecting a standard feature, with set-up tools the customer’s own team can use. Your engineers build and maintain it for everyone. Each new connection is then set-up work for the customer, not a project for you.

The difference is who does the work, and how often. A one-off connection is maintained by your engineers for one customer. A standard feature is maintained once, for every customer who uses it. One is an exception. The other is the product.

No, but it can run separately: sell it as a service

The second answer is no, but it can run separately, at a price.

The one-hour promise is this case. You would not offer it to every customer as standard. Most do not need it, and staffing every night for all of them would cost more than they pay you. But a few customers cannot work without it, and they will pay to have it.

So stop giving it away. Turn it into a named service, such as a premium support plan, with its own price. That price should cover the rota, the extra pay and the hires. Any customer who wants it can buy it on the same terms.

Frances Frei’s research on service businesses makes the same point: accommodating what customers ask for, done crudely, raises costs (Frei, 2006). A named, priced service is accommodation done deliberately.

Now the cost carries a name: the customer who pays for it. The engineers on call overnight are funded by the customers who asked for them, not by everyone else.

No, and it holds back the product: say no

The third answer is no, because it would hold back the product for everyone.

The copy in the customer’s cloud is this case. A separate copy is not the problem; many companies run dedicated set-ups well. This one runs in the customer’s account, on its own version, and each update waits for their approval. Every release now has to support that version too. The cost does not stay with the customer who asked. It slows the product for everyone.

So say no, and find the concern behind the request. It is usually where the data is kept, how it is isolated or who controls it. A dedicated region, or a dedicated instance you still run and update, often answers it.

For the customer you already said yes to, plan the exit. Agree a date, usually at renewal, to move them onto the standard product.

The same applies to experiments. A yes that tests a clear assumption, with a date to review it, can be worth making. The danger is letting it become permanent without a second decision.

A no may cost you one deal. A yes you cannot afford keeps costing you, one release at a time.

One question, three answers

Skip the question: the exceptions become the business model

Now suppose you never ask the question.

Each request stays exactly as it was agreed. The connection stays one-off. The support stays free. The copy stays in the customer’s cloud. Every new large deal adds another.

Slowly, the work changes shape. More of your engineers’ time goes to keeping promises to single customers, and less to the product everyone uses. Every release has to work with the cloud copy and the in-house connection, so each change takes longer and breaks more easily. Research on complexity finds these costs rise faster than the variety behind them, and past a point erode more profit than the variety earns (Gottfredson & Aspinall, 2005; Wilson & Perumal, 2009).

So you hire to keep up, and it rarely helps. In the efficiency equation, resources (R) are multiplied by adaptability (A): how quickly you can change without breaking what already works. Customer-specific commitments weaken A when every product change has to work around them. Hiring pays for the extra work but leaves those dependencies in place. The real test is whether you can keep your commitments and still change the product without renegotiating each one.

η=(Pₛ × I) + (R × A)eᵁ + N

Adaptability (A) multiplies resources (R). A commitment that every product change must work around lowers A, and extra hires cannot fix that. Standardising or declining removes the dependency. A priced service, run separately, contains it.

The Entrepreneurial Efficiency Equation (η) · Dr. Hafiz Muhammad Ali

That is how a product company becomes a services company without ever deciding to. No single yes did it. Together, they became the business model.

BEFORE THE NEXT YES

Five questions for every custom request

1. What is the need behind the request?

   Judge the need, not the wording. A request that looks unique often hides a need every customer shares.

2. Would you offer this to every customer?

   If yes, build it into the product.

3. If not, can it run as a separate, priced service?

   If yes, give it its own price and its own owner.

4. If not, what would it hold back?

   If it slows the product for everyone, say no and offer what the standard product can do.

5. What are you already doing by hand?

   List every customer exception in place today, and give each one of the three answers at its next renewal.

Saying yes was never the mistake. Skipping the question was. Ask it before every yes, and each request ends in the product, a price or a no.