Ask YC: name your own price? | Hacker News Reader

Ask YC: name your own price?

14 pointsaggieben14 comments

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?

View on HN

Don't do it. It does not help your:

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.

What are the alleged advantages of this pricing model? I have to say that as a user, I don't think I'd sign up for anything with this kind of model.

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.

Try it. What have you got to lose?

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.

We (I run SlimTimer) went with a NYOP plan primarily because of we lack an obvious usage vector (ex: Projects) to limit and because it's hard to put a price on something after you've given it away for over a year.

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

Take a look at sliding scales http://en.wikipedia.org/wiki/Sliding_scale

They likely know that any payments received from users will be worth more than a bunch of banner ads that never get clicked on.

http://en.wikipedia.org/wiki/Price_discrimination

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.

It's not quite so simple online. (See also vlad's comment).

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.

Yes, this is where a lot of companies get lost, asking people for money in any amount is hard, and it comes with a bunch of unpleasant responsibilities. Providing something for free gives a warm glowy feeling and if advertising can support it, have at it; but remember that it's not a business until you have a proven revenue model.

I wasn't arguing against charging money.

My point is, if you are going to charge, don't charge too little, as it will probably be counterproductive.

Maybe the could say each time you ask a price, if it is not accepted, they raise the internal price by x%

: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 make the target price, with perhaps a forced minimum, and dynamically define it as the average price paid.

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.

X should vary according to a random component plus something based on user behavior. Someone who spends lots of time on your site, clicks links obsessively, etc., might get a higher bump, because they appear to have worse impulse control.

Tangent, but your comment reminds me of MIT's site morphing paper: http://web.mit.edu/hauser/www/Papers/Hauser_Urban_Liberali_B...

Why would you want to do this? Are you hoping people will pay more than what you want? If so set the price at $x and offer them the opportunity to pay more (and note it in the account for faster support or something).

Reply on news.ycombinator.com