Compendium of Sorrows series #1
“I agreed to a few customizations, and now my product is five products.”
Founders and CEOs experience this a couple of years into their growth trajectory, especially when the business is fast growing and high margin. Software companies are the archetype. Winning those first big customers and prestigious logos is hard. But once there is traction, it becomes ever more painful to serve those customers. The roadmap gets more complex, Work In Progress piles up, delivery time increases, and the organization feels less nimble than it used to be. Then the next deal is in play, and there is some pressure to agree to a few small tweaks. They make sense for the deal, and how bad can it be? But somewhere down the line it turns out that, added together, the tweaks aren’t so harmless after all. That is the customization conundrum.
This is a hard problem. I maintain an inventory of the “Compendium of Sorrows” faced by organizations who feel their commercial counterparties hold a few more cards than they do. Ranking all of them by impact, complexity, and required effort and lead time to address, this one scores an 18/20 “misery index”.
They love the product, almost… they just need a few tweaks to make it work for their specific workflow. You say yes because the deal is significant and you want to be seen as a true partner.
Each of your major clients has their own version of your product. Your roadmap has become their roadmap and whoever screams hardest gets priority.
Under a tight deadline, you agree to custom features rather than see the deal slip away. You tell yourself that you will make a profit on the work from reapplication to other customers.
This is not pain that is felt in Sales, and not at the time the deal is signed. Not that Sales is to blame—we’ll get to that. But deal making is where the problem originates, and where it needs to be addressed.
Customization costs show up in disguise and at three different points in time
Unmistakable as the organizational pain is, it’s still hard to pinpoint the nature of the problem—let alone quantify its cost. Excessive customization hurts performance in three ways, show up in measurable KPIs on different time horizons.
It manifests earliest, as soon as the customizations work their way into the product development roadmaps, in the pace of feature delivery with velocity slowing down. Every new feature has to be built or maintained for the standard product, and then built and maintained again for each customized version. Each of the client-specific features introduces dependencies elsewhere in the product. This gets worse as product breadth and complexity increase, inevitably slowing down development of the internal roadmap. Many a product manager knows this from experience; not that many know the mathematics and how shockingly bad the numbers behind the effect can get. (And I have yet to meet a single Finance person who gets this—more about that later.)
Here’s a representative number. Compared to a baseline of an engineering team working at 60% capacity utilization on a customization-free roadmap, adding 25% on client-specific features will extend delivery time to 2.7x as long. A team working with 40% slack is savvy and agile: start from only 30% slack, and what took your nimble operation 2 weeks will now take 3 months. Capacity utilization, slack, and the modeling behind these estimates is not the topic of this text: for brevity, there is an illustrative table below this article summarizing all three metrics for a hypothetical $10M business, with a few lines on where the methodologies come from, and a reference to the experts and sources to go read.
An increasing delivery time is not good, and the impact on your product doesn’t stop there. Customization dilutes the product’s design consistency, reducing its ease of use, and making it more labor-intensive to onboard and train. Clients receiving customized product are unlikely to stop at a one-off request: customization will breed the expectation they have a say in influencing your future roadmap. Even if you fend those off, the initial customization already affected your clients on standard product: they receive the standard features on your internal roadmap at a slower delivery rate. Your most demanding customers are the reason you risk falling behind on innovation and losing competitiveness with your least demanding ones.
Next number to take a hit is margin. Suppose you can charge the custom work at a 25% upmark over fully loaded engineering cost, a typical rate for a service business. Gene Godick of G-Squared CFO compares two software companies with $10M of revenue each. To the outside world they both look like a SaaS business, but one earns all of its revenue from subscriptions at an 80% gross margin, keeping $8.0M of gross profit. The other earns $7.5M from subscriptions and $2.5M from services at a 25% margin. That leaves $6.625M and the $1.375M gap is capital that can’t be invested in growth. Whether the customization work is booked as services revenue or eats up unbilled engineering time is not relevant. It reduces margin either way. This would be Finance’s way of expressing that distraction stifles growth.
Still further out in time, customization has a financial impact on fundraising and exits. Godick and Alyx Priestley write about investors disaggregating recurring and non-recurring revenue for valuation purposes, typically valuing services at 2-3 times revenue and a software business at 8-12 times. Checked against valuation authority Aswath Damodaran’s data, the assumptions are reasonable. The summary table shows a 19% valuation reduction from a 25% custom share.
To keep things in perspective: not all customization is bad. When product-market fit is not fully understood and established yet, customer input (including customization requests) is a way to discover what the product is. At a later stage, customization is still a sensible decision if the feature is something other customers will certainly want too, if the feature will anyway be on the roadmap in the next year or so, and if the lead customer pays for the work. Customization can increase customer stickiness if it integrates your product deeper in the client’s operations, reducing their ability to walk away from you and incentivizing them to sign a longer duration contract—a blessing if it is priced correctly, but a bigger burden if it isn’t. Still, if a customization is built as a separate version, given for free or justified by some vague future market, it does great harm even if that market turns out to exist.
Practitioners don’t need to know these numbers to experience the pain is real. But if everybody knows, how is it possible this keeps happening?
Why it happens, will keep happening, and why you just saying No will not work
The trouble is: all factors scream in favor of doing the customization, especially early in the product’s life. You want your customers to say which things make your product a better buy for them, and you want to say yes. Winning one significant deal pays for a lot of runway. You are eager to demonstrate how fast and flexible your team is. The commercial discussions aren’t adversarial but constructive: they have all the traits of collaboration and win-win value creation. Agreeing to the customization doesn’t even feel like making a concession. No chains bind harder than the ones you choose yourself.
The first one or two customizations are fine, but later on, even when the pain is already being felt, it is surprisingly hard to stop. Assessed individually, the next customization for the next deal will still make sense. The client’s motivations will be rational and reasonable. In internal reviews, the salesperson will tell you the customization has a big impact on the odds of winning the deal—probably correctly so. Sales will also point out that, if the work is sold at e.g. a 25% upmark over the fully-loaded cost of the engineering, the work is profitable. Also true. (A CFO I worked with had his own way of countering this argument. “Opening a hot dog stand in front of the office would also be profitable. But we’re not going to do that either.”) Even if Procurement negotiates away the customization service fee, it will still be net incremental cash-in from a new high margin deal. (And any Procurement person worth their salt will definitely try this. “We are not going to pay for you closing the gaps you have compared to your competitors,” they will say.) It’s the curse of high gross margin companies: looking at incremental revenue relative to incremental cost, it always makes sense to tack on one more deal.
The standard Finance toolbox doesn’t make it easy to decide when to say No. This is difficult to see, because the true costs are hard to quantify (especially the “cost of delay” impact of velocity loss, fundamentally the most important one), those costs are incurred long after the deal is closed, and at that point they will be hard to distinguish from normal operational costs in the internal financials. Putting in place a pragmatic decision process is possible, but falls in the category of simplicity on the other side of complexity.
The precise location where the problems arise. It’s not your Sales team.
To avoid the operational problems downstream, they need to be recognized and addressed at negotiation time. The Negotiation Pattern Language shows in detail where they originate.
Four patterns define this problem. Three dominant ones are Structure issues, the dimension governing negotiation architecture.
Issue Decomposition (5.1) covers how negotiation scope is broken down into separate issues. Each customization gets agreed on a standalone basis, while the shared product portfolio aggregates their impact. Because this aggregate product scope is not part of the negotiation’s issue list as a boundary, the customer’s requirement list ends up driving the conversation. Sales reports the request back, and processing the issue list and its consequences becomes internal improvisation (under compressed timelines, there is a Velocity (6.2) component at work).
Decision Criteria (5.2) governs what the commercial opportunity is judged against. No criteria are defined specifically for the customization decision gate, so the most visible number crowds everything out: the decision increasingly gravitates to deal size.
Reversibility (6.3) examines how costly it is to change course or undo a decision. A customization can be undone cheaply only until maintenance, upgrades or other product development work get stacked on top. Individually, each customization request looks reversible. Collectively, the architecture becomes irreversible. The customer can leave at the end of the contract, but you can’t unship.
Loss (3.2) is the experience of wanting to keep something you thought you had. Losing a significant deal feels worse the closer you get to winning it. Even if your head says a customer is unlikely to walk away over one refused change if they invested major time and effort evaluating your product, holding the line only gets more agonizing when you can almost touch the deal.
The Style column is nearly empty. The problem is not tension or aggression in the discussions, which more often than not are pleasant and exciting.
The way out—Prevent where you can, repair what you must
Simplifying is complicated, and getting harder the later you start. It’s possible, but prevention and repair require a sustained effort. The NPL fingerprint shows why it is not realistic to leave the solution entirely to the Sales VP: the problem is organization-wide as opposed to purely commercial, and solving it will cut against the grain of Sales’s incentive structure. This will be a significant CFO project, or you’ll want to install a (fractional) deal desk—which in the long run you should probably do anyway.
The main building blocks of prevention
> Define and organize a clear decision gate, make it clear enough to Sales, and/or alter their comp plan
Every customization request needs to pass three tests before customer commitment is even hinted at. (1) It was already on the 1-2 year roadmap horizon anyway; (2) a second (named, not hypothetical!) customer will also use it; (3) the customer pays for the development.
This evaluation is run by Product, and Sales has no vote. Since Sales is obviously affected, the decision rules need to be clear enough early enough, to avoid they spend time on dead end leads. Ideally the expected behavior is factored into the Sales comp structure. Reps need to be equipped with clear talking points – see below.
> Price customizations, and make them subject to non-negotiable contract terms
If the customization request passes the three tests, put a method in place to price it. Generally speaking, the service should cover the entire lifetime cost, and be compared with the change in the probability of winning the deal plus the learning value. The bar can be put higher or lower depending on how close a funding round or exit is. In any event, unless you are at peace with a future as a services business, the price will be significantly higher than fully loaded cost + 25%.
The customer’s reaction to the price is a genuine test of the extent they truly value the feature. Priced correctly, they may be OK paying for something you can implement as a configuration option on the main branch, but they probably will not be for a genuine customization. In the contract, preserve your right to offer the result to other customers. Large customers’ Procurement will not mention this, if they don’t actively oppose it. Procurement will definitely resist the non-recurring engineering fee. That can make an otherwise pleasant conversation uncomfortable, but it’s pain that needs to be taken and taken early. A price set too low sets a precedent and becomes the reference for any future request—and will only inspire more of them.
> Sales are briefed on the full magnitude and cost of customization, and get a clear product and financial message track to defend your position.
Good product collateral will help sales reps steer the customer to the standard offering: a major source of customer requests is a poor understanding of what the standard delivers. If the customer insists on customization, make sure reps don’t need to improvise an explanation how it is priced. Reps can only defend it with conviction, if they have first been thoroughly briefed on the financials and organizational repercussions themselves. If not, they too will believe the quoted service fees are outrageous.
Additional steps to repair
> Assess the current organizational impact
Estimate the share of engineering time spent on customization, the share of features used by more than one customer, and service revenue as percentage of total. Make the inventory of significant customizations you have in place.
> Freeze new versions, and start engineering structural solutions in
New customers go onto the standard product while the existing variations are dealt with. Each one is sorted by two questions. Do other customers want what this does? How much does its customer depend on it? The answers decide whether a variation is folded into the product as a configurable option, kept alive against a maintenance fee, or retired with notice and/or migration support. This, and the first repair step, are product management and platform architecture work.
> Renegotiate customer by customer
The outcome of the variation triage will define a renegotiation agenda. Start with a customer for whom the move is easy and useful: the initial renegotiated agreements will set the precedent for every subsequent one. Each offer gives the customer a reason to move: upgrades that only the standard product will have, continued support in exchange for a maintenance fee, or a migration path you co-invest in. Champions need special attention: equip them with an upgrade narrative such that they avoid embarrassment for the original choice and preserve their internal standing. Large customers usually come later: taking them first gives them more power to refuse and set a precedent for everyone else.
What it takes
Setting the policy is not the end. The pressure will return with every significant deal, so someone has to structurally enforce the policy. Managing the customization conundrum can fall on the founder, be a significant project for the CFO as objective gatekeeper, or be delegated to a (fractional) deal desk: measuring where the company stands, developing the criteria and the decision gate, pricing customizations, preparing the negotiation support material, and chairing reviews of significant proposals before they go out.
Summary Table
The theory behind the speed model and detailed decision criteria is based on Donald Reinertsen The Principles of Product Development Flow, and Kingman’s formula for how variability adds to queue delay.
Acknowledgements
Additional inspiration to better understand the problem found with gratitude in the writings of Alyx Priestley, Jason Lemkin, Gene Godick and Julia Bastian.
Contact
There is a more detailed Playbook on this topic, covering extensive diagnostics, a concrete quantified model to decide on individual deals, a sales message track, and objection handling and renegotiation playbook. It’s developed for a specific client but contact me if you are interested in it - perhaps it can be customized for you.