The Customization Curve

A few months ago, I was talking to a startup about how individual customers wanted them to do different things. They felt trapped, because, on the one hand, they were intentionally doing things that didn’t scale. On the other, they found that meeting the varied expectations of their customers meant that they were not moving towards a coherent product and that their time to do anything other than customize their product had evaporated.

This is a natural tension for early stage companies that is surprisingly hard to get away from. I think that’s partly because the way we talk about making users happy is too black and white. There is no single thing you can build that will make all users happy, and it’s rare to hit on the exact thing that makes any users happy out of the gate. Instead, founders have to run a continuous optimization of what they can build and support against what users want.

I think about this optimization as operating along three variables: cost of customization, happiness generated, and cost to support that customization. The goal is to find a level of customization that makes as many customers as possible happy while not incurring support costs – through personnel or burn – that would kill your company. This curve is always going to be slightly different, but looks something like this:

This is hardest to figure out at the early stages of physical services businesses. Those companies generally experience the widest range of customer satisfaction because they cannot fully control the delivery of the service. This leads to very angry customers who demand expensive changes. When a company doesn’t have a lot of customers, any angry customer feels like the end of the world, which leads founders to try to make all of these users happy, which then creates unsustainable processes and product customizations. The harder thing to do is figure out which customizations you could make, weighted by the increase in happiness of the users you actually want.1

Pure software businesses have to run the same decision process, but they tend to have more control over the what gets built, and they operate within a narrower band of likely cost. When thinking through how to weigh changes and cost, this is a hierarchy you can use:

System critical bugs should always be fixed. These are not customizations.

Customizations that are software features are easier to build than customizations involving people processes.

If you have to build a people process, build one that can be replaced with software later

Customizations that require you to build new people processes are ok if those processes can later be turned into software.

Customizations that require hiring people who can’t be switched to new roles rapidly are dangerous.

Customizations that require large upfront capex are generally a bad idea.

Customizations that require people and capex are almost never a good idea without a lot of thought and without trying alternatives first.

Enterprise clients will often pay for the development and support of custom features. Ask them about this.

Founders will always make mistakes when deciding what to build to make users happy. That’s usually ok, and is part of how founders learn what their users actually want and what their product should be.

The biggest danger is committing to large costs that are hard to remove. Doing this will force a company down a path to failure or an extreme pivot. This isn’t all that different from ramping up burn, but it’s actually more dangerous because founders think they’re doing the right thing all along. “Look!” they say “I’m making users happy!” They don’t think of the cost, and one day wake up that they have happy users who are dooming the company.2 That’s hard to come back from because the emotional weight of disappointing happy customers is a powerful bit of inertia. The only way to avoid that fate is to recognize that your goal is to make many users happy, not just the few you happen to have today.

Notes1. This is important. If you get people using your service, you will invariably get customers or users who you don’t actually want. This might because they’re abusive. It might be because they don’t want to pay you. It’s ok to decide not to serve these users, but make sure that you’re not either ignoring your real user base because you have misguided expectations, or being a jerk.↩2. The road to hell is paved with good intentions and all that.↩