Ask YC: name your own price?
I'm a regular slimtimer.com user, and it now supports a premium-level membership with a "name-your-own-price" subcription model (http://blog.slimtimer.com/2008/05/07/data-export-backups-and-premium-subscriptions-are-here/). I'm curious about how this works as a subscription model with my own product in mind.
Anybody have any experience with this? How well does this work in practice? How do you prevent "gaming", whereby someone either asks around to figure out which of their friends gets what price and everyone just clusters on the local minimums, or just trying to fill out the form with lowball numbers and then incrementing until it's accepted?
14 comments
[ 607 ms ] story [ 321 ms ] thread:You ask $10, they wanted $15. No Deal
:You ask $12, they now want $15+1.50 = $16.50. No Deal
:You ask $15, they now want $16.50+1.65= $18.15. No Deal
:You ask $20, they now want $18.15+1.82= $19.97. DEAL
Now it's getting closer to a free market auction, and should be getting a little harder to game.
Now functionalize the price increase along business defined price-increase-heuristic. Now if they game your system, you should just hire them to work for you.
If it's "donate what you think it's worth (including zero)" that's fine; otherwise, just tell me how much you want for it, and I'll decide if I want to pay it.
1. Marketing 2. Sales 3. Customer satisfaction
It brings in uncertainty in your financial breakdown. It's silly, if you want to do silly things, do it in marketing, as they can have a positive effect there, but not in the way you close your sales. Your price is the end of the pipeline, don't mess with a customer that is already that far down your sales funnel.
I notice for example that if I absorb the tax on my products, it bumps up sales by over 90%, but if I decrease the price so that the tax does not matter, the rise in sales is about 5%. This is because of the no-suprise philosophy. A person who is clicking through your shop likely wants to buy. When you suprise him at the end with an additional fee, you lose him.
They likely know that any payments received from users will be worth more than a bunch of banner ads that never get clicked on.
is also relevant.
Pricing information services is hard, however since you are usually able to segregate your market into people who will pay little and use little and people who will use lots and pay lots; you can usually find some feature set that casual users will want but not be willing to pay for.
The set of people who will make an online transaction and pay, say $30, has a very large overlap with the set of people who will make an online transaction and pay $1, because the online transaction itself is the biggest barrier.
My point is, if you are going to charge, don't charge too little, as it will probably be counterproductive.
A good rule of thumb is that if you want your company to have revenue, you should require regular payment (make money while you gain traction, then sell or continue). If you want to have as many users as possible, you should make your application free (gain traction, investment, then sell or start charging). And if you want to optimize towards the fewest users, least revenue, and exude the least confidence to users, investors, and the media, and guarantee you'll be an employee of your existing company for another couple of years, have a donation system.
Soon you will find that as many people pay $2-$5 as those who would be willing to pay $30, if $30 was a standard price. If your goal is to minimize the amount of revenue your startup makes while making your users feel guilty while using your app, this is a great way to do it.
But give it a try. By the way, the reason Wikipedia has a donation system instead of a subscription system is because a subscription system would not make any sense to its mission and the licensing of the data, as well as tick every contributor off. In other words, it's a last resort for a company that already has traction but needs to remain free and cannot place third party ads on their product.
A couple other implementation notes:
* We don't prompt users to upgrade until they're a couple sessions into the service. Asking for them to name a price up front would probably result in a much lower conversion rate.
* We don't give the users a blank box for price. Instead we compute a suggested price based on the number of hours they spend on the service.
Overall, I would recommend stating a fixed price up front (and we'll probably convert to this once we build in the concept of a project) but the results thus far have been decent. The average monthly payment is a bit lower than I would have expected but the conversion rate from regular to paying users is a bit higher.
I'm planning on doing a detailed write up of our findings on my blog in about a month or so.
and I probably wouldn't recommend it to other people