Hacker News new | past | comments | ask | show | jobs | submit login
The Customization Curve (blog.ycombinator.com)
78 points by janober on Sept 14, 2017 | hide | past | favorite | 29 comments



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.


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.


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


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


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.


Ah, sorry, I mistyped what I meant to type. That's how confused I was. Fixed.


There's nothing wrong with flipping the axes, just unusual. Maybe Aaron has been reading economics, they tend to do that.


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.


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.


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


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.


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.


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


It's a Bezos chart.


What is this a reference to?


A quick search suggests a trivial conspiracy ...

https://twitter.com/jsnell/status/481863414180896769


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.



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


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


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.


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.


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.


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


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.


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


That's nothing like what the graph is depicting.


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


Rotate it 90° counter-clockwise.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: