#4 nails it, but I see it slightly differently: Hackers don't realize that while what they do is easy for them, it is immensely difficult for the common person.
My level of skill currently rests somewhere between "intermediate" and "proficient" with the languages and libraries I use on a day to day basis, in my opinion. I'm nowhere near a guru with anything I use - however, I can't even discuss the implementation of things I consider trivial with the people I implement them for, because there is such a huge divide in knowledge, and domain-specific language. I would have to spend a long time explaining basics before I could even get close to making the point I would like to, but would probably be able to explain what I needed to to make the point in 20 minutes to someone who just had some basic software development experience.
It's very easy to forget just how much stuff goes on, and how much you have to take into account, and how much you learned to get to the point where you could implement what you did - even with what we consider to be very simple apps. As such, it is very easy to extremely undervalue an application.
It very much depends on the problem domain, but 2,3 and 4 are the real dangers.
The solution to 2 and 3, for me, is to repeat this every time I'm dealing with a potential client : do they value their time more than their money? People who value their time are quite willing to commit money to save it / use it better.
The solution for 4 is way wrong. You never ask people how much would they pay for things, because the answers are always wrong. You price things high and bring down the price until you're making sales and about 5% or so of your customers are complaining about the price. That's as close as you'll get to a scientific pricing strategy.
I asked a couple of customers how much they'd pay for a new software product I was writing. They all low-balled the figure. In the end I priced it 5 times what the highest suggestion was, and it has sold well. If I had been receiving 5x less revenue, I would have given up before the product took off.
you're right, other than having a large enough distribution to do experiment with different pricing scheme pricing too high and backing off is probably the best way to go.
Well let's make the rule of thumb more explicit: hackers tend to undervalue their own products. Why is this? And what are some solutions?
1) We have many examples of free services that rely on ad revenue that we feel we are competing with
Solution: realize that only massive sites can get away with this as a true business model. On regular sites this will at most be a lifestyle business.
2) Hackers overvalue money relative to their clients (understandable if you're working for ramen money, the first 24k a year is the most important)
3) Hackers undervalue their own labor because we have fun doing it
Solutions for 2&3: um, stop doing that?
4) Hackers don't correctly value how much labor our product is saving people, and how much that efficiency is worth to them.
Solution: This one can be fixed simply by knowing your demographic really well and putting feelers out. "how much would you pay for x?"
does anyone else have any other reasons?