[tuddman]

> It's really easy to fall into the trap of giving each customer exactly what they ask for ... this is the sort of product strategy that easily leads to disastrous results.

do you know any product/company examples where this was/is the case?

[cmorelli]

See aianus response for some examples, I would also add:

- Windows Mobile (pre WP8): Customers may have asked for a mobile computer, but most did not actually want a weak version of their computer crammed onto a tiny screen. Apple and Google helpfully showed them what customers actually wanted with iOS and Android.

- Blockbuster: Customers may have asked for a large selection of movies for rent, but they didn't want a physical location they could drive to and browse through. Netflix gave people a new option (multiple new options)

- MySpace: "Customers" may have asked for customized/personalized profiles, but they didn't mean a dumping ground of random html and css that eliminates any sense of uniformity, brand, identity, etc. Facebook gave people the personal touch they actually wanted without compromising the experience.

Now, these are colossal failures, and we can endlessly debate whether you believe these failures were the deciding factor in their respective products. But I think we can probably agree that, at the very least, failure to cater to the actual customer need (instead of what they simply ask for) was a major flaw in all of these cases. And these are just a few examples.

Also, I'm not sure if it was intentional or not, but you cut my quote at an interesting spot. I'm not trying to suggest that a business should not cater to its customers' requests. Rather, that it should not do so at the expense of trying to understand the need behind the request.

[dkarl]

I can't name examples, but I've worked for places where this happened, and the results were paralyzing. The only way to do it right is to add each feature as if all your customers were going to use it, but instead, people cut corners and write features in such a way that they only support the targeted customer(s). They compound the problem by adding special cases in the business logic to make sure the feature doesn't affect other customers even though it's broken for them. They add features for one customer that aren't even logically coherent for other customers. They lower their sights from "make this code work for every valid set of inputs" to "make this code work for all of our current customers, except the ones who won't notice because they don't use this feature yet."

The result is completely unmaintainable. You can't change anything because every piece of data has accidentally acquired special meaning.

"You can't remove the dog_shave_preferences column! It's how we distinguish between customers who were added before June 2013 and customers who were added after!"

The work to add a customer whose data doesn't trigger the right special case logic starts to be seen as a "new feature" rather than fixing bugs.

"Hold on, this is a fundamentally new set of requirements! We've never had a customer before who had the Bloop module enabled and had a logo bigger than 5k and wasn't AcmeCorp! We should have been aware of this new requirement before the customer went live."

The trap is how quickly people adapt to this kind of thinking, to the point where normal engineering starts to feel weird to them. I once quite seriously suggested creating a database table to record which customers a certain feature was broken for and had it shot down because people thought the byzantine special-case tests it would have replaced, which had no other purpose, constituted valuable business logic. The ideas and conditions we had invented to track the limitations of our code had started to feel like real business distinctions that they couldn't imagine living without.

Suffice it to say that eventually we slowed down to the point where declaring a feature freeze didn't feel like a drastic change to anyone, including our customers, and embarked on a substantial rewrite. It didn't end well. I've encountered another example that was a lot more sane (people knew they were doing the wrong thing all along and didn't actually start to believe in the reality of the distinctions they wrote into code) but it suffered from the same maintainability problems.

[tomcam]

A word processor company named WordPerfect used a similar "feature on demand" idea quite successfully during their early years in the 1980s. They only abandoned it when it got just too unwieldy, but by then they had become the standard word processor for law firms. They eventually got sold for what was then quite a decent sum.

[aianus]

Horse carriage makers, Kodak, Blackberry