Product Management
The Hidden Cost of Custom Customer Features
Freshness Warning
This blog post is over 4 years old. It's possible that the information you read below isn't current and the links no longer work.
7 Dec 2020
The CEO sends you an email. "Skyhook Industries wants to know if we can add some features so they can use us for their water treatment division. They’re one of the largest customers of our highway construction management product. Can we add their water treatment features and keep them happy?"
You reply that the product team saw this request already and learned that none of your other construction customers would find the feature useful. The company had no plans to start selling to the water treatment industry. The feature would be used by Skyhook and only Skyhook. You had told the customer that you would not be adding the requested feature.
The CEO comes back to you later. Skyhook’s management is willing to pay your company $50,000 to develop the feature. It’s not complicated to build, so a junior developer could build it. $50k is half a junior developer’s salary, and it certainly won’t take them 6 months to build. Sounds like pure profit and you make a top customer happy.
This is a common story at software companies all over. A customer wants a pet feature. Something no one else will ever use, something that doesn’t fit your product vision. Usually, this is a very large customer and you’re afraid they’ll leave if you don’t say yes. Sometimes this is a smaller customer that’s promising to become a huge one if only you could do this one thing. Sometimes they’re not a customer at all but promise to buy the product if you take care of their special need. Often, the customer is willing to pay you to build it.
Sounds like a win all the way around. But it’s not.
Don’t do it. The cost of building and maintaining the one-off feature will greatly exceed anything you might charge that customer. You’ll charge them for the initial investment. You might overcharge them a whole lot because you know there will be ongoing maintenance costs. You won’t charge them enough.
That one custom feature will need more maintenance than anyone expects. You will need to test every new capability that you develop both with this new feature and without it. It’s an exponential growth to your testing. You don’t test N times. You test N^2 times. Add a second one-off feature to the product and the exponent grows. Now you’re testing N^3 times.
The ongoing development cost isn’t limited to making sure the product doesn’t have bugs with this feature. The cost of designing and developing new features goes up. You have to ensure that each new thing you build works in the right way with this custom feature. Take for example a custom report filter you added for a customer. The customer will expect that this report filter continues to work on their existing reports. That’s testing. They’ll also expect that the custom filter works on every new report you add to the system over time. You’ve added extra overhead to everything that the custom feature could conceivably touch.
Your special, super-important customer will become the customer with the most outages and quality problems. It’s a truism in software development that most issues happen in the least-traveled part of your codebase. At some point in your product lifecycle, you’ll miss a test. You’ll forget to update a server with the custom code. You will make a feature change that you didn’t realize affected the custom feature.
Besides increased development costs and pitfalls, your support and documentation efforts will cost more. You’ll need to produce docs both with and without the feature. Train your support staff on not only the feature, but how it interacts or alters the rest of the product, and how to identify when that feature exists. When you inevitably build a new capability that doesn’t interact with the custom feature in the way the customer expects it would, support will hear about it.
Every choice you make in the product has trade-offs. The presence of a capability can limit your future choices. It can paint you into design corners. Having a one-off makes that harder. The thing that’s limiting your choices isn’t even used by most customers. Changing or removing it is impossible because the customer paid for it.
There are soft costs associated with one-offs, too. Now that you’ve done it once for them, it’s easier for the customer to ask for more, and harder for you to say no. You can’t ever uncross that line with that customer.
An unexpected soft cost is the drain on employee morale that comes with the politics of having "special" customers. You’ll hear your team talking about these customers with negative tones. "We can’t build it that way because 'Acme.'" "Why is that test failing? Acme."
Your customer or sales team will get creative. "What if we build it as a custom module that’s only installed for them and they own the code and are responsible for all updates, and they do all testing?" Sounds reasonable. Then Bond, Inc. asks for and gets their own custom module. You find you can’t have Skyhook’s module running at the same time as Bond’s, so now you need to test the product with Skyhook and Bond both there. Skyhook says it’s not their responsibility to make sure Bond works. And Bond says the same thing about Skyhook. Who is going to pay for that test?
The costs to create and maintain a one-off feature are far more than the development time required to initially build the feature. Even those that anticipate the ongoing maintenance costs underestimate the extent of those costs. It is not unusual to spend fifty times as much over the customer lifetime as you spent to build the feature. And the irony is that you did the work to make the customer happy but you destroyed whatever goodwill you had with the customer instead.