6 ms·

The Customization Curve

78 points by janober 9y ago

raldi 9y ago
I can't make heads or tails of that graph. Which is supposed to be the independent variable?
- pc86 9y ago
  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 9y ago
    That's nothing like what the graph is depicting.
    - pc86 9y ago
      I thought you couldn't figure out what it was depicting? :)
- deleted 9y ago
  [deleted]
- yogipatel 9y ago
  Rotate it 90° counter-clockwise.
- bradleyjg 9y ago
  It seems to be saying that you can do an awful lot of customization and it'll only make customers a little happier. It is only when you get to high customization that it makes customers much happier, but at that point you are well beyond sustainable costs. Take men's suits. It's saying fully bespoke isn't a sustainable business model. Made-to-measure might or might not be (depending on which side of the line) but it isn't going to make your customers ecstatic, just a little happier than off the shelf. One odd thing, is it seems to start by trending downwards. Not sure if that was intentional.
3pt14159 9y ago
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 9y ago
  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 9y ago
    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 9y ago
      Not sure why this got down voted -- no expectation of customization does seem to lower the threshold of satisfaction. Yours seems a solid explanation.
- yogipatel 9y ago
  The dependent typically goes on the Y axis. That said, he does seem to be going at it in a non-intuitive manner (for me, anyway). The cause and effect seem backwards. He's optimizing for a customization level even though that's clearly the cause for happiness, not the other way around. Not disputing his point, but I agree, the graph is confusing.
  - 3pt14159 9y ago
    Ah, sorry, I mistyped what I meant to type. That's how confused I was. Fixed.
skmurphy 9y ago
"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.
nicodjimenez 9y ago
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.
nighthawk454 9y ago
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".
katastic 9y ago
That graph is so bad people are going to discuss it more than the article itself.
- cratermoon 9y ago
  It's a Bezos chart.
  - tw1010 9y ago
    What is this a reference to?
    - B1FF_PSUVM 9y ago
      A quick search suggests a trivial conspiracy ... https://twitter.com/jsnell/status/481863414180896769 https://twitter.com/jsnell/status/481863414180896769
deleted 9y ago
[deleted]
bluetwo 9y ago
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 9y ago
  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.
makesense 9y ago
Rotated the graph! https://i.imgur.com/a7ds0fr.png https://i.imgur.com/a7ds0fr.png
curun1r 9y ago
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.
FLUX-YOU 9y ago
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.
- netfire 9y ago
  Then you have to support changing said system and it may make it difficult to change your product as needed. Plus you've got to setup the marketplace, payment processing, add documentation and market to and support third party app developers. Unless you've already reached scale (or have other products that have -- like Google, Facebook, etc), this is probably a dangerous option.
- GlennS 9y ago
  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.
tyingq 9y ago
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.
anovikov 9y ago
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).

78 points by janober 9y ago

raldi 9y ago

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

pc86 9y ago
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 9y ago
  That's nothing like what the graph is depicting.
  - pc86 9y ago
    I thought you couldn't figure out what it was depicting? :)
deleted 9y ago
[deleted]
yogipatel 9y ago
Rotate it 90° counter-clockwise.
bradleyjg 9y ago
It seems to be saying that you can do an awful lot of customization and it'll only make customers a little happier. It is only when you get to high customization that it makes customers much happier, but at that point you are well beyond sustainable costs. Take men's suits. It's saying fully bespoke isn't a sustainable business model. Made-to-measure might or might not be (depending on which side of the line) but it isn't going to make your customers ecstatic, just a little happier than off the shelf. One odd thing, is it seems to start by trending downwards. Not sure if that was intentional.

3pt14159 9y ago

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 9y ago
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 9y ago
  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 9y ago
    Not sure why this got down voted -- no expectation of customization does seem to lower the threshold of satisfaction. Yours seems a solid explanation.
yogipatel 9y ago
The dependent typically goes on the Y axis. That said, he does seem to be going at it in a non-intuitive manner (for me, anyway). The cause and effect seem backwards. He's optimizing for a customization level even though that's clearly the cause for happiness, not the other way around. Not disputing his point, but I agree, the graph is confusing.
- 3pt14159 9y ago
  Ah, sorry, I mistyped what I meant to type. That's how confused I was. Fixed.

skmurphy 9y ago

"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.

nicodjimenez 9y ago

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.

nighthawk454 9y ago

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".

katastic 9y ago

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

cratermoon 9y ago
It's a Bezos chart.
- tw1010 9y ago
  What is this a reference to?
  - B1FF_PSUVM 9y ago
    A quick search suggests a trivial conspiracy ... https://twitter.com/jsnell/status/481863414180896769 https://twitter.com/jsnell/status/481863414180896769

deleted 9y ago

[deleted]

bluetwo 9y ago

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 9y ago
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.

makesense 9y ago

Rotated the graph! https://i.imgur.com/a7ds0fr.png https://i.imgur.com/a7ds0fr.png

curun1r 9y ago

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.

FLUX-YOU 9y ago

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.

netfire 9y ago
Then you have to support changing said system and it may make it difficult to change your product as needed. Plus you've got to setup the marketplace, payment processing, add documentation and market to and support third party app developers. Unless you've already reached scale (or have other products that have -- like Google, Facebook, etc), this is probably a dangerous option.
GlennS 9y ago
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.

tyingq 9y ago

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.

anovikov 9y ago

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).