Ian is right about one thing: many programmers have an irrational fear of tech support. To hear some people tell the tale you would think it is a black hole of wasted time sucking out any ability or desire to improve the product.
If you treat it like an engineering problem, it really doesn't have to bury you. Improve the product, get less support requests. Improve your answers, get less support requests. Proactively answer questions on the site and in the app, get less support requests. Provide self-help tools, get less support requests. Do a bang-up job on those emails you do get, get less support requests.
I used to work as a CSR and picked up the habit of charting stuff (it is much harder to improve things you can't measure). Since January 1st I've passed out something like 16k trials and had about 225 sales, and that has resulted in about 40 emails to me (including pre-sales inquiries).
That's about one-fifth the mails-per-sale ratio I had when I started out. Measure it, make improvements, do more of what works. (Plus, the less mail you get the more you can afford to blow folks away on the ones you have to answer personally.)
How much detail do you go into? I can see the value of tracking progress and trying out different ways of improving your tech/sales support but there must be a point when you've taken things too far.
For example do you track which page a user is on before they contact you? If you do A/B testing do you include tech support as an endpoint?
At my CSR job the rule was Track The Right Amount. In my case, that used to involve me splitting the emails up by cause. These days the coarse count is enough.
I've never spent any engineering resources on tracking people around the site, with one exception: I pipe unsuccessful requests to the Find Registration Key function to my dashboard. That is less for my benefit and more for allowing manual follow-up for folks who are having trouble.
Indeed. I thought the (almost) defacto Web1/2.0 model was - do it cheaply, make it free, spur terrific growth - get acquired and/or turn this growth into revenue.
Yes. And "some people" win a shitload of money on the Lottery. Just because you have a really slim chance of winning a whole lot doesn't mean it's the smartest way to go about earning money.
It's also hard to be a pro tennis player. Not everyone can do it. But that doesn't mean trying is like buying a lottery ticket.
Succeeding with an ad supported business model, believe it or not, takes skill. Being acquired is probably more luck, but I'd say is still pretty 'doable' if you have the right approach.
Sure it is, but it's much easier to just build and provide a service which people are willing to pay for.
Everyone is free to do whatever they think suits them of course, I'm just saying that a lot of the time people take the harder path that leads them nowhere at all.
If you're really passionate about some particular kind of web service or product, then naturally you're going to use whatever model suits that particular service.
But, if you're simply looking to make money while you sleep and are open to building a number of different services, chances are pretty good you're going to make more money, and sooner, if you make a great service and charge a price for it.
>> "Sure it is, but it's much easier to just build and provide a service which people are willing to pay for."
People keep repeating this. How do you know for sure? Have you tried both? Are you sure you learnt how to do both well enough to be sure of your abilities in each model?
Why do you think making money from advertising is hard?
As for scared: A lot of companies are scared that people won't pay for their product at all, and if they make something great but charge, someone will swoop in underneath and make the same thing for free with ads. People just default to making their site an ad-supported business - its a race to the bottom in everybody's mind even if there are no competitors waiting in the wings.
Cool take on it. It's true that small paid apps require you to be more service oriented than code oriented. I kinda like that sometimes - I like interacting with people - but I can see how some wouldn't.
Beyond that, popularity might be an issue. Just like avoiding certain work can be a driver, so can the want to be popular. Free things are going to be more popular and I think most of us would like to help as many people as possible and we'd at least like to think that our programming helps people (whether it's fun or makes their work easier or whatever).
If you can pull off free, it's a wonderful thing. Being able to help people at no cost is great. However, it isn't always the best or most practical thing. Often times it means that you'll have a lot of users who you can't give any support to and lackluster resources for improvement.
many startups are founded by programmers - I don't think this is true, but for a programmer, who presumably hangs around other programmers, this is an easy mistake to make. I bet that a lot of business school types wonder why mostly business types start companies. You are biased because of the people you meet.
I have a couple of friends who are doing startups, one is selling vitamins on the net, another is doing an E-book on sex, and a third runs a successful online translation service. None of them are programmers.
He is still writing :-) But it's based on an actual book that he wrote two years ago. It was pretty successful for its niche, but since it was in Danish (population 5 million) he never made much money because the native market is so small. So the idea is to spiff it up, translate it to English and sell it as an e-book.
The only thing he proved was that statements that state the general aren't absolute.
With a bit of thought, I think most people can understand the point I was trying to make. If you cannot, I don't see any reason to explain it in more words.
If you treat it like an engineering problem, it really doesn't have to bury you. Improve the product, get less support requests. Improve your answers, get less support requests. Proactively answer questions on the site and in the app, get less support requests. Provide self-help tools, get less support requests. Do a bang-up job on those emails you do get, get less support requests.
I used to work as a CSR and picked up the habit of charting stuff (it is much harder to improve things you can't measure). Since January 1st I've passed out something like 16k trials and had about 225 sales, and that has resulted in about 40 emails to me (including pre-sales inquiries).
That's about one-fifth the mails-per-sale ratio I had when I started out. Measure it, make improvements, do more of what works. (Plus, the less mail you get the more you can afford to blow folks away on the ones you have to answer personally.)