3 ms·

Dear iDoneThis team - do NOT lower your prices [1]. As a fellow subscription revenue biz, we've found that lower priced plans invite customers whose support re

by asanwal 13y ago

Dear iDoneThis team - do NOT lower your prices [1]. As a fellow subscription revenue biz, we've found that lower priced plans invite customers whose support requirements are much greater. And you won't make it up in volume. Real businesses that value their time will spent $50/month for a service that saves them time without thinking twice. Your early traction proves this out. The graphic you had in your post about developer thinking makes me think you guys already know this, but I see the lower price advice a lot on HN, and almost always, I think it is the wrong advice. [1] - This is obviously 100% opinion, and you know your business 1000x better than I do. BTW, our product's subscription price point is significantly higher $12k per annum at the low end, and we just moved this up from $7500 earlier this year. BEST DECISION WE EVER MADE.

tagabek 13y ago
I second the notion to not decrease your prices. There may be a few people that have the time and are willing to produce their own alternative product, but iDoneThis is definitely worth the cost (probably even more). As with many subscription products, I feel that iDoneThis will become the product that business owners get used to paying each month.
graeme 13y ago
Seconding this. In consulting or SAAS work I've done, the trend has been the same: low priced customers generate the highest levels of support, send the largest amount of unreasonable requests, and produce the most headaches. None of this is a dig at the grandparent comment. Just a general tendency. Produce something of value, and people will pay and be glad to do it. The whiners will go elsewhere and you'll be better for it. (again, NOT a dig at the grandparent. There's an actual class of whiny users that vanishes when your don't pander to them)
kansface 13y ago
Clearly some price point is too high. Why do you think the current pricing is below that threshold?
- akbar501 13y ago
  Test higher prices, like you've done so far. Some price point is too high, but you won't now what it is until you've found it via testing.
rgrieselhuber 13y ago
Couldn't agree more. With all due respect to louthy, making a decision to lower your prices based on the notion that a customer finds it to be a good use of their time to save $600 / year to build a copy of your service indicates that the amount of time it takes him to build it is worth less than $600. That might not be a great target market.
- alanctgardner2 13y ago
  If I were him, I wouldn't worry about 1 customer saying they'll build their own. My coworker (a PM, no less) decided, rather than Solr or ElasticSearch, to write his own search engine for a work project. He did it, and it obviously took 10 times longer than estimated and cost way more than was necessary. There will always be a proportion of customers who want it cheaper, but that doesn't mean you're priced wrong: it means they're not measuring value accurately. For a good engineer, 600 dollars gets you something between 10 and 20 hours of work. To produce a polished project, start to finish, that's not going to happen.
- _mulder_ 13y ago
  'Less than $600 a year' is different to 'less than $600'. If you plan to use it for 4 years (assuming team size remains constant), that's a potential saving of $2400.
7Figures2Commas 13y ago
> As a fellow subscription revenue biz... I think it's hard to group all "subscription services" into the same bucket. Selling proprietary data in the financial services market (like CB Insights) is very different from selling a simple tool (like iDoneThis). Also, it should be noted that price is just one component of a pricing model. If you don't look at how you charge, and only consider how much you charge, chances are you're not going to maximize revenue. $5/user/month looks good on paper, but I wouldn't necessarily assume that the perceived value scales with a flat-fee-per-user (no tiers) model. Example: 1. If my company has 10 people, sending iDoneThis $50 each month probably isn't a big deal. 2. If my company has 10 teams of 10 people, iDoneThis is now a $500/month expense. That's $6,000/year. I might not dispute that there's value to the service, but my perception and consideration of its value is likely to change as the total cost increases.
- asanwal 13y ago
  Great points all around. I do agree that for larger company/enterprise type deals, the current iDoneThis pricing may not work and IMO, that's a large opportunity.
- richardw 13y ago
  If your company has 10 teams of 10 people, your most important action is not saving $500 a month. You're (hopefully) earning a proportionally higher amount for your 100 people and you should continue to focus on that. If the software stack helps, don't fiddle with it to save a few bucks. The challenge for iDoneThis is not to make it cheaper per user, it's to re-invest the highish costs in order to beat the competitor who is charging 50c per user. Make iDoneThis better at managing the ever-growing complexities of syncing information when you have 100/1000/10k staff members and you have no damned idea what they're doing. Especially because quite a few hackers are thinking "you know, I could make that app and sell it for a few bucks less." Don't race them to the bottom, because Twitter is at the bottom at $0p/m.
  - 7Figures2Commas 13y ago
    > If your company has 10 teams of 10 people, your most important action is not saving $500 a month. You're (hopefully) earning a proportionally higher amount for your 100 people and you should continue to focus on that. If the software stack helps, don't fiddle with it to save a few bucks. This type of thinking is prevalent on HN, but it's not always realistic. Most companies of a certain size have financial controls, and even if $500/month is not a lot of money in a relative sense, the number of $500/month line items for nice-to-have, this-helps-a-little products and services is reasonably limited. Getting a budget for something that isn't in a "checklist cost" category can be a real headache, every vendor relationship has overhead, and instituting a new SaaS for 100 people (and getting them to actually use it) may have its own costs (staff time, etc.). > Make iDoneThis better at managing the ever-growing complexities of syncing information when you have 100/1000/10k staff members and you have no damned idea what they're doing. That's a fundamentally different product than what iDoneThis has today. To support development of that product, it will need substantially more than $1,000/month in recurring revenue, or it will need additional funding. > Especially because quite a few hackers are thinking "you know, I could make that app and sell it for a few bucks less." Don't race them to the bottom, because Twitter is at the bottom at $0p/m. If you build a business around a simple concept that requires limited functionality, you can refuse to engage in a race to the bottom, but it doesn't change the fact that you will almost certainly be undercut if others see a worthwhile opportunity. In other words, iDoneThis can keep its $5/user/month price point, but if this is an appealing enough concept, it will have competition, and cheaper competition, before it ever obtains enough revenue to "re-invest the highish costs" as you have suggested.
esw 13y ago
>As a fellow subscription revenue biz, we've found that lower priced plans invite customers whose support requirements are much greater. This has been my experience, too. The customers who consume the most support resources are almost always on the lowest cost plan.

by asanwal 13y ago

tagabek 13y ago

I second the notion to not decrease your prices. There may be a few people that have the time and are willing to produce their own alternative product, but iDoneThis is definitely worth the cost (probably even more). As with many subscription products, I feel that iDoneThis will become the product that business owners get used to paying each month.

graeme 13y ago

Seconding this. In consulting or SAAS work I've done, the trend has been the same: low priced customers generate the highest levels of support, send the largest amount of unreasonable requests, and produce the most headaches. None of this is a dig at the grandparent comment. Just a general tendency. Produce something of value, and people will pay and be glad to do it. The whiners will go elsewhere and you'll be better for it. (again, NOT a dig at the grandparent. There's an actual class of whiny users that vanishes when your don't pander to them)

kansface 13y ago

Clearly some price point is too high. Why do you think the current pricing is below that threshold?

akbar501 13y ago
Test higher prices, like you've done so far. Some price point is too high, but you won't now what it is until you've found it via testing.

rgrieselhuber 13y ago

Couldn't agree more. With all due respect to louthy, making a decision to lower your prices based on the notion that a customer finds it to be a good use of their time to save $600 / year to build a copy of your service indicates that the amount of time it takes him to build it is worth less than $600. That might not be a great target market.

alanctgardner2 13y ago
If I were him, I wouldn't worry about 1 customer saying they'll build their own. My coworker (a PM, no less) decided, rather than Solr or ElasticSearch, to write his own search engine for a work project. He did it, and it obviously took 10 times longer than estimated and cost way more than was necessary. There will always be a proportion of customers who want it cheaper, but that doesn't mean you're priced wrong: it means they're not measuring value accurately. For a good engineer, 600 dollars gets you something between 10 and 20 hours of work. To produce a polished project, start to finish, that's not going to happen.
_mulder_ 13y ago
'Less than $600 a year' is different to 'less than $600'. If you plan to use it for 4 years (assuming team size remains constant), that's a potential saving of $2400.

7Figures2Commas 13y ago

> As a fellow subscription revenue biz... I think it's hard to group all "subscription services" into the same bucket. Selling proprietary data in the financial services market (like CB Insights) is very different from selling a simple tool (like iDoneThis). Also, it should be noted that price is just one component of a pricing model. If you don't look at how you charge, and only consider how much you charge, chances are you're not going to maximize revenue. $5/user/month looks good on paper, but I wouldn't necessarily assume that the perceived value scales with a flat-fee-per-user (no tiers) model. Example: 1. If my company has 10 people, sending iDoneThis $50 each month probably isn't a big deal. 2. If my company has 10 teams of 10 people, iDoneThis is now a $500/month expense. That's $6,000/year. I might not dispute that there's value to the service, but my perception and consideration of its value is likely to change as the total cost increases.

asanwal 13y ago
Great points all around. I do agree that for larger company/enterprise type deals, the current iDoneThis pricing may not work and IMO, that's a large opportunity.
richardw 13y ago
If your company has 10 teams of 10 people, your most important action is not saving $500 a month. You're (hopefully) earning a proportionally higher amount for your 100 people and you should continue to focus on that. If the software stack helps, don't fiddle with it to save a few bucks. The challenge for iDoneThis is not to make it cheaper per user, it's to re-invest the highish costs in order to beat the competitor who is charging 50c per user. Make iDoneThis better at managing the ever-growing complexities of syncing information when you have 100/1000/10k staff members and you have no damned idea what they're doing. Especially because quite a few hackers are thinking "you know, I could make that app and sell it for a few bucks less." Don't race them to the bottom, because Twitter is at the bottom at $0p/m.
- 7Figures2Commas 13y ago
  > If your company has 10 teams of 10 people, your most important action is not saving $500 a month. You're (hopefully) earning a proportionally higher amount for your 100 people and you should continue to focus on that. If the software stack helps, don't fiddle with it to save a few bucks. This type of thinking is prevalent on HN, but it's not always realistic. Most companies of a certain size have financial controls, and even if $500/month is not a lot of money in a relative sense, the number of $500/month line items for nice-to-have, this-helps-a-little products and services is reasonably limited. Getting a budget for something that isn't in a "checklist cost" category can be a real headache, every vendor relationship has overhead, and instituting a new SaaS for 100 people (and getting them to actually use it) may have its own costs (staff time, etc.). > Make iDoneThis better at managing the ever-growing complexities of syncing information when you have 100/1000/10k staff members and you have no damned idea what they're doing. That's a fundamentally different product than what iDoneThis has today. To support development of that product, it will need substantially more than $1,000/month in recurring revenue, or it will need additional funding. > Especially because quite a few hackers are thinking "you know, I could make that app and sell it for a few bucks less." Don't race them to the bottom, because Twitter is at the bottom at $0p/m. If you build a business around a simple concept that requires limited functionality, you can refuse to engage in a race to the bottom, but it doesn't change the fact that you will almost certainly be undercut if others see a worthwhile opportunity. In other words, iDoneThis can keep its $5/user/month price point, but if this is an appealing enough concept, it will have competition, and cheaper competition, before it ever obtains enough revenue to "re-invest the highish costs" as you have suggested.

esw 13y ago

>As a fellow subscription revenue biz, we've found that lower priced plans invite customers whose support requirements are much greater. This has been my experience, too. The customers who consume the most support resources are almost always on the lowest cost plan.