[cmorelli]

offering to build (tiny! like, 5-minute one-offs!) features _just for them_ sort of blows their minds

It seems worth noting that this can also be a dangerous strategy. It's really easy to fall into the trap of giving each customer exactly what they ask for, rather than learning what they actually need. If gone unchecked, this is the sort of product strategy that easily leads to disastrous results for product usability and experience.

This isn't to say that as a business you're always (or ever) better at knowing what your customers want than the customer is; but you are in a strategic position to be able to understand what similar customers are asking for, and distill that down to the core problem that needs to be solved.

I'm sure this isn't the extent that the original comment was aiming for, but it felt worth expanding on this since the whole topic is about early products getting users. A key component of that is ensuring you're building a product that people want to use.

[developer2]

A mitigation strategy here is to delay implementing any new feature for a single customer, in order to query your other customers as to whether they need the same or similar feature. Oftentimes you will find other customers who are interested, even if their exact needs are slightly different from the first customer's request.

Best case scenario you get to build the feature once, based on a spec that fits the needs of a larger pool of customers. This reduces the overhead of more customers inevitably requesting similar features weeks or months down the line.

Worst case scenario you still wind up releasing a feature that only one customer is going to use. At least you've tried your best to fold more customers' needs into a single unit of work. Better to have asked and found no takers than to have not asked and wound up with repeated requests for similar features once it's too late to combine the work.

[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

[shanecleveland]

Very good points about avoiding support and customer service traps that you can't back out of. But I think in the context of how to "acquire your first 100 users," trying things that don't scale may be worth the risk. There's limits, I'm sure.