You should take extraordinary measures not just to acquire users, but also to make them happy.
I'd like to elaborate on this point, because it's probably the most valuable thing I learned while working at Cloudkick.
Similar to how every Marine is a rifleman, I think every developer should be tech support[1]. It's an incredibly easy way to please users. Many customers don't realize how small your company is. They expect an experience similar to Comcast or Verizon: Listening to on-hold muzak interrupted by advertisements. Forced to enter obscure info such as an account number on a billing statement. Getting handed between people in various departments, each time repeating answers to the same set of questions.
To your users, it's as if they called Comcast and a cable modem firmware developer picked up the phone.
Could you imagine how much you would love Comcast if that happened to you? You'd still love it if the person said, "Oh sorry, that's a bug in our firmware. We'll probably have it fixed by tomorrow. I'll contact you with an update then."
That sort of support is impossible in a larger company. It makes your users outrageously happy. Many of them will praise you publicly and tell their friends how great you are.
1. Modulo standard disclaimers, working at a small startup, etc. I also think everyone should be in the on-call rotation, but that's another can of worms.
I disagree with having developers do tech support. In fact I think it's insulting to those that are great at tech support. Tech support is a skill in itself, not just a place to let developers play.
If you really care about support, you'll have people with that expertise doing it.
Also, developing is really something where being in the zone gets the most productivity, and support is usually an intermittent and sporadic distraction, it can be a real productivity killer.
I see why people say this in pricinple, I just don't think it's a good idea in practice.
Tech support is a skill in itself, but it's also a crucial feedback channel for learning how users use your software. Empathy with users is what lets you distinguish a good programming decision from a bad programming decision when it comes to the software. Distinguishing good programming decisions from bad ones is what programmers do all day.
It's possible for tech support to work out as a disruptive distraction, but it doesn't always have to be that way. And yes, there are programming things where being in the zone is crucial, but there are usually programming things where it isn't, too.
I'd like to elaborate on this point, because it's probably the most valuable thing I learned while working at Cloudkick.
Similar to how every Marine is a rifleman, I think every developer should be tech support[1]. It's an incredibly easy way to please users. Many customers don't realize how small your company is. They expect an experience similar to Comcast or Verizon: Listening to on-hold muzak interrupted by advertisements. Forced to enter obscure info such as an account number on a billing statement. Getting handed between people in various departments, each time repeating answers to the same set of questions.
To your users, it's as if they called Comcast and a cable modem firmware developer picked up the phone.
Could you imagine how much you would love Comcast if that happened to you? You'd still love it if the person said, "Oh sorry, that's a bug in our firmware. We'll probably have it fixed by tomorrow. I'll contact you with an update then."
That sort of support is impossible in a larger company. It makes your users outrageously happy. Many of them will praise you publicly and tell their friends how great you are.
1. Modulo standard disclaimers, working at a small startup, etc. I also think everyone should be in the on-call rotation, but that's another can of worms.