
The Customization Curve - janober
https://blog.ycombinator.com/the-customization-curve/
======
3pt14159
The graph looks wrong, no? Doesn't the independant variable typically go on
the x axis? The sustainable cost line intersects the graph randomly. If you
swap the labels of the graph then it kinda makes sense, only I disagree with
the shape of the curve in that case. A little customization goes a long way.
The curve shouldn't decrease until the midpoint.

~~~
paulddraper
The graph is written as "giving how happy I want my customer base to be, how
much customization will I need?"

And IDK why the middle is lower than the left side.

~~~
oconnor0
No customization presents a simple tool that, hopefully, just works and can be
accepted with its flaws and limitations. Once customization starts being added
in, it's easier to see annoyances and "why isn't this feature present".

~~~
cellularmitosis
Not sure why this got down voted -- no expectation of customization does seem
to lower the threshold of satisfaction. Yours seems a solid explanation.

------
curun1r
Being overburdened with customizations can be an indication of failure in the
product management team/processes. Customer problems are rarely as unique as
they believe them to be. Great product managers will hear the request but find
the underlying need behind the request and build a solution to address that
need rather than just writing up the customer request and passing it to the
engineering team. It's over-quoted, but Ford's line about his customers asking
for faster horses is apropos. Hear the need behind the request and
intelligently address that and you'll arrive at a coherent product rather than
a collection of one-off features.

------
nicodjimenez
One of the dangers of Paul Graham's now famous startup advice "do things that
don't scale" is when you no longer are on a path to a scalable product or
service. The whole point of a product company is to achieve scale, this should
not be forgotten. Customization is fine, it's when your attention is split
across different types of users that you can get into trouble.

------
anovikov
I even witnessed a company who started with a product and then went down the
road of customization, 15 years later arriving to a point where they are a
custom development shop using all the same product simply as form of
advertisement (proof that they are competent). Just by continuously taking the
offers of enterprise clients to customize their product to their needs - it
quickly turned out that it made a lot more money than selling the product.
Then, these clients started to hire them to do unrelated things, and recommend
to other clients to do unrelated things as well.

Their last license sold was about 5 years ago.

But probably making more money than they ever planned to make with the product
(the product was planned as a lifestyle business, not a startup - say they
never tried to look for any funding).

------
bluetwo
The graph really should be U-shaped.

There is a bit of manufacturing philosophy that I find relevant here.

You can build an efficient factory that makes a large number of identical
widgets at a price competitors can't beat, or you can make a factory that
makes small batches of custom order widgets at prices competitors can't beat.

However, when you try to build a factory that does both well, you'll end up
with a price point that is no longer competitive.

In software, it is very similar. You can stick to a model, or you can spend
your time customizing, but if you try to do both you'll end up with an
unmanageable code base. This will eventually lead to rising costs and a lost
competitive edge.

~~~
keithnz
I think the graph is trying to describe an idea rather than be a reflection of
reality, they do mention it will look different in specific cases. Though, I
think as you point out, the graph could look drastically different for certain
kinds of businesses.

------
katastic
That graph is so bad people are going to discuss it more than the article
itself.

~~~
cratermoon
It's a Bezos chart.

~~~
tw1010
What is this a reference to?

~~~
B1FF_PSUVM
A quick search suggests a trivial conspiracy ...

[https://twitter.com/jsnell/status/481863414180896769](https://twitter.com/jsnell/status/481863414180896769)

------
tyingq
Not sure what to think about this because it's difficult to characterize
"customization". Most software has some amount of toggles, options, and so
forth. And some have things like plugins or built-in scripting. What counts as
"customization" and what doesn't?

Is chromium too customized for example? There's lots of toggles, options,
command lines switches and a whole web extension subsystem.

------
makesense
Rotated the graph!

[https://i.imgur.com/a7ds0fr.png](https://i.imgur.com/a7ds0fr.png)

------
nighthawk454
The graph shows customization required as a function of happiness.

Low happiness --> low customization

Medium happiness --> minimal customization

Infinite happiness --> infinite customization

High happiness --> moderate customization

With the interesting bit being the balancing act around "moderate
customization", "high happiness", and "sustainable amount of work".

------
skmurphy
"2\. Customizations that are software features are easier to build than
customizations involving people processes."

I am not sure this is true at all for any scale of organization. It's
certainly much easier to prototype a service and provide it to a customer than
modify and release code for just one customer.

------
FLUX-YOU
Just build a plugin/extension system.

Then you have a base product you market to new customers and a developing
marketplace of plugins which you can likely sell for a lot if your product is
focused well enough.

~~~
GlennS
I really don't thing this is a good answer by itself. For a start it's taking
a punt.

Before deciding to build a plugin system, you need to decide in which
dimensions it will allow extensibility. The answer to that should not be 'all
of them', because then you've just badly reinvented a general purpose
programming language without the tooling and with more awkwardness (c.f.
Spring).

Plugin systems also increase code complexity. Extensible software is usually
slower and less reliable than software which doesn't, _even before you
actually add any extensions_.

Lastly, software has to have a big enough market of developers to create and
maintain the plugins. So this works well for e.g. Emacs, but for each success
story they are more specialized or less popular tools with a failed plugin
ecosystem.

Consider Mediawiki as a cautionary tale. It's a big, popular piece of software
with a lot of extensions. Most of them are unfinished, unmaintained, untested,
insecure.

------
raldi
I can't make heads or tails of that graph. Which is supposed to be the
independent variable?

~~~
pc86
A certain amount of customization is cheap, easily supported, and makes
customers very happy. A little _more_ customization is very expensive and
doesn't make customers much happier (quickly diminishing returns).

~~~
raldi
That's nothing like what the graph is depicting.

~~~
pc86
I thought you couldn't figure out what it was depicting? :)

