[dkarl]

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

How did you manage to do that without making it impossible to add major new functionality to your app? Did you nail the basic functionality of the app from the starting gate and go straight into maintenance/feature-tweaking mode?

meticulous hand-holding through the first few weeks usually convinces them to stick around

This must have created some awfully high expectations from users, which is a double-edged sword. Were you able to keep up with expectations when you got enough users to sustain the business?

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

[jaredklewis]

If we are choosing between the problems of:

A) Having users, with high expectations

B) Not having users

Problem A is a way better problem to have. Of course, no business would intentionally try to cultivate a user base of picky, high maintenance pain-in-the-necks. Nor would it be anyone's long term goal to be hacking on user requested features. But if those things bring users, easy trade. It's hard to think of any problem that would be more important than the problem of not having users.

[cmorelli]

This.

There's also a difference between holding your customer's hand and building unsustainable expectations. The only expectation you've built by holding their hand through the onboarding process is that you care about your customers and want them to have a great experience. That's exactly the expectation you want your customers to have. Many startups have been incredibly successful at acquiring customers from incumbent businesses with more features and possibly cheaper products, by simply caring more about people.

At the end of the day there are people using your product (presumably). The more those people feel you care about them and their problems, the more likely they are to give you a little space as your business gets off the ground. Maybe they're willing to tolerate a few minutes of downtime, the occasional bug, or missing feature, because they know that they're always going to be treated well by your team.

Cultivating strong customer relationships is a great element in any business, and it's virtually a requirement in modern B2B.

[Mz]

It's hard to think of any problem that would be more important than the problem of not having users.

Having a rabid crowd that wants your head on a pike comes to mind. But if that doesn't apply, then your advice is sound.

[Doches]

> ...nail the basic functionality of the app...

As much as possible, yes. The app is essentially a point-of-sale system with a bunch of reporting features bolted on; nailing that core POS functionality in a way that kept it easy to build new reporting features on top was always my top priority.

> Were you able to keep up with expectations when you got enough users to sustain the business?

This is the situation I'm in now, actually -- most of my early users are in a nice steady-state, but I have lost a few who weren't happy with the drop in support as I slowed down on their specific, special-snowflake requests. All of them were also early adopters of the affiliate marketing scheme, though, so they've basically signed up their replacements already, and those users are entering into an app that's in a much more steady state, and have expectations set accordingly.

It's not a perfect outcome, and you're 100% right to call out those high expectations as a potential problem -- but as problems go I find that it's better to have demanding users than non-existant ones :)

[devopsproject]

On adding features:

You have to be flexible with how you classify your product. If you are stuck in "maintenance\small tweaks only" mindset you will constantly find excuses to say "no".

New features will break your model. It is your job to try and figure out if it is worth the cost. I typically use the "common customer" argument. If this would be useful to the "common customer" it gets serious consideration.

On hand holding:

Most people will "get" your product and stop calling you. There will be some who call all the time. You can use these calls to help direct your work eg: "I'm getting 15 calls a week about username\password issues, it is time to rethink the login\password reset process."