Which is better: Many customers at low price-point or few at high price?(blog.asmartbear.com)
blog.asmartbear.com
Which is better: Many customers at low price-point or few at high price?
http://blog.asmartbear.com/price-vs-quantity.html
23 comments
As a data point I have about 900,000 customers to service (iPhone apps). I've also had times in my career where I have had one customer (department of defense). I'm much happier with the 900,000. I think an assumption Jason makes that i would contest is that you need to provide the same level of service to 10,000 people that you would provide to 10. When your app is at a low price point, you aren't competing on customer service anymore. So why try? Just use a virtual assistant to handle level one service requests, have a FAQ, etc.
How complex is your app? Is it entertainment or productivity?
Fairly complex entertainment app
Are there not perhaps thousands of people who would be using your product under the umbrella of the Department of Defense?
Those people aren't making purchasing decisions, ergo they're not customers but users.
Customer does not equal user.
My favorite part of this article was the first half of the summary:
"If you want happiness and fulfillment from a small company, strive for B"
$10,000/mo revenue with only 10 customers to keep happy vs. 1000 customers to service? Yes, please.
Company B could have just as much potential for growth as company A. Sure A has the potential to have more brand evangelists bringing in new customers but B has more time to devote to totally babying their 10 customers and making sure they will be likely to recommend the product/service to others in their industry. Company B only needs 1 referral to make another $1,000 per month whereas company A would need 100 referrals.
Also think about upselling down the road, if a company can afford $1,000/mo for your base product they will probably be willing and able to pay for upgrades that will make their work easier or more efficient.
I'm not arguing that B is better than A, but I think that B could have just as much growth with less stress.
"If you want happiness and fulfillment from a small company, strive for B"
$10,000/mo revenue with only 10 customers to keep happy vs. 1000 customers to service? Yes, please.
Company B could have just as much potential for growth as company A. Sure A has the potential to have more brand evangelists bringing in new customers but B has more time to devote to totally babying their 10 customers and making sure they will be likely to recommend the product/service to others in their industry. Company B only needs 1 referral to make another $1,000 per month whereas company A would need 100 referrals.
Also think about upselling down the road, if a company can afford $1,000/mo for your base product they will probably be willing and able to pay for upgrades that will make their work easier or more efficient.
I'm not arguing that B is better than A, but I think that B could have just as much growth with less stress.
On the other hand you need just one cost-cutting round or one unforgivable support foul-up to lose 10% of your revenue overnight. Model A likely won't see that kind of volatility.
As someone who runs a type A business, gives C+ customer service, and has a significant amount of unplanned downtime (ie. "oh shit, the server is down"), I can back this up 100%. We lose some customers due to my bungling, but it's never enough to shake the foundations of the business.
I disagree. People who are paying $5/month have a much lower threshold before they leave than an enterprise paying $20,000/month. Also larger more expensive services tend to end up with more business integration and the cost of moving to another service is typically substantial.
+1.
Also, consider setting a price that cuts out the vast majority of demanding cheapskates but keeps it salient for the rest. $200 is a good starting place. You can also achieve this by charging for the entire year up front instead of monthly billing.
Also, consider setting a price that cuts out the vast majority of demanding cheapskates but keeps it salient for the rest. $200 is a good starting place. You can also achieve this by charging for the entire year up front instead of monthly billing.
They do, but in $20,000 there are 4,000 individual lower thresholds. It's much, much less likely that any one event will cause all of them to quit - all other things being equal, which they never are, so with a grain of salt and all that.
Let me tell you (a bit from experience)
It has to be low, but it shouldn't be too low!
- Early adopters really don't mind paying more
- If the app has some intrinsic corporate value it can be priced higher
- Pricing "sets the tone" of the product
For example, a regular user won't mind paying $1 compared to a $0.10 product. So charge $1
And think of how many copies you have to sell more at price X to profit like price Y.
Suppose an exageration: price X is $1 and price Y is $100. Is selling at price X really 100 times more difficult than at price Y?
Selling 5 units at Y price may be difficult but selling 500 units at price X may be harder
You don't want to celebrate 1000 sales at $1, you're still starving at the end of the month.
It has to be low, but it shouldn't be too low!
- Early adopters really don't mind paying more
- If the app has some intrinsic corporate value it can be priced higher
- Pricing "sets the tone" of the product
For example, a regular user won't mind paying $1 compared to a $0.10 product. So charge $1
And think of how many copies you have to sell more at price X to profit like price Y.
Suppose an exageration: price X is $1 and price Y is $100. Is selling at price X really 100 times more difficult than at price Y?
Selling 5 units at Y price may be difficult but selling 500 units at price X may be harder
You don't want to celebrate 1000 sales at $1, you're still starving at the end of the month.
I’ve worked for 2 company Bs so far and can honestly say that I think I’d much rather prefer a company A instead.
Both company Bs are a little over 10 years old, and still run the same software they started out with. They both have had a history of having a few very large customers each year, each of them demanding a lot of customization. It could be the way the each company B handled it, but it shows. The codebase and system architecture is a mess, full of quick fixes and patches because big customer x was requesting feature y.
It’s made for an extremely frustrating system to work with. I’m sure a lot of it could have been avoided, but at the same time things sometimes needed to be done quick and dirty, and the software team probably didn’t have the resources to do things the “right way.” It’s easy to criticize looking back. Probably one of those things easier said than done.
If you are running or working at a company B, please please please think of the future, the business scalability/maintainability, and the sanity of your employees/peers.
Both company Bs are a little over 10 years old, and still run the same software they started out with. They both have had a history of having a few very large customers each year, each of them demanding a lot of customization. It could be the way the each company B handled it, but it shows. The codebase and system architecture is a mess, full of quick fixes and patches because big customer x was requesting feature y.
It’s made for an extremely frustrating system to work with. I’m sure a lot of it could have been avoided, but at the same time things sometimes needed to be done quick and dirty, and the software team probably didn’t have the resources to do things the “right way.” It’s easy to criticize looking back. Probably one of those things easier said than done.
If you are running or working at a company B, please please please think of the future, the business scalability/maintainability, and the sanity of your employees/peers.
I work for a company that has only tens of clients (banks) but each pays us in the hundreds of thousands to millions range, an extreme example of B. Just one of these customers takes up to a year to acquire.
On the plus side, things can move more slowly and in a well thought out way. Also, there's no worry around your usual "web scale" issues. There's also a lot of freedom around exploring new ways to do things because of the slower pace.
On the down side, the customers sometimes put insane requirements in our contracts. Security audits, source code in escrow, huge amounts of insurance, long weekly meetings. The culture of bureaucracy bleeds if you're not careful. Also, income is lumpy and one client can end up costing more than they're paying you if you're not careful.
All in all I think it's the best kind I've experienced so far. That's probably because my employer has done a great job of insulating me from the down sides though :).
On the plus side, things can move more slowly and in a well thought out way. Also, there's no worry around your usual "web scale" issues. There's also a lot of freedom around exploring new ways to do things because of the slower pace.
On the down side, the customers sometimes put insane requirements in our contracts. Security audits, source code in escrow, huge amounts of insurance, long weekly meetings. The culture of bureaucracy bleeds if you're not careful. Also, income is lumpy and one client can end up costing more than they're paying you if you're not careful.
All in all I think it's the best kind I've experienced so far. That's probably because my employer has done a great job of insulating me from the down sides though :).
Having been on both sides of the Fortune 100 sales cycle, it was always a fun game, as a buyer, to see how close we could get to being written off during the courtship process. Drinks at lunch are the norm, but maxing out the champagne costs, getting box seats at games, etc.
Once (if) the sale closed though, it was down to business, and doing our damnedest to maximize both our time and the vendors. I've never worked with or for banks, but I can't imagine them being TOO terribly different from federal IT, so I definitely sympathize with your plight. It seems as though all they really want you to do is acknowledge, in every way possible, how happy you are to have their business, and how lucky you are to be in meetings with them all day every day.
Once (if) the sale closed though, it was down to business, and doing our damnedest to maximize both our time and the vendors. I've never worked with or for banks, but I can't imagine them being TOO terribly different from federal IT, so I definitely sympathize with your plight. It seems as though all they really want you to do is acknowledge, in every way possible, how happy you are to have their business, and how lucky you are to be in meetings with them all day every day.
Funny thing is, we're a 25 person company and most of our competitors are much much bigger. However, they're so slow, inflexible and outdated tech wise that we just blow them out of the water with our offering (we charge 2-5x the going rate).
The biggest insight that contributed to our success came from our CFO who realized that big corporate IT is where dreams go to die and that we should route around them as much as is possible.
The biggest insight that contributed to our success came from our CFO who realized that big corporate IT is where dreams go to die and that we should route around them as much as is possible.
Strive to get many customers paying a high price for your product. Apple computers and IBM mainframes are two of the most profitable product lines in IT history.
Personally, I love the high stability of a broad consumer base. However, you can architect a successful business either way.
Personally, I love the high stability of a broad consumer base. However, you can architect a successful business either way.
The implication that Apple didn't make this tradeoff is false.
Apple charges a high price relative to its cohort but not its customers' aggregate spending - recent times see it it pushing towards r-strategist behaviour (lots of lower paying customers, e.g. iPad).
If Apple were pursuing a k-strategist mentality (few, high paying customers) I would not have to wait an hour to get serviced in New York, I'd have small batches of product with bleeding edge technology, and I'd have a personal support rep and probably custom app developer.
Apple charges a high price relative to its cohort but not its customers' aggregate spending - recent times see it it pushing towards r-strategist behaviour (lots of lower paying customers, e.g. iPad).
If Apple were pursuing a k-strategist mentality (few, high paying customers) I would not have to wait an hour to get serviced in New York, I'd have small batches of product with bleeding edge technology, and I'd have a personal support rep and probably custom app developer.
I'm surprised with the amount of Apple love in startup-land, more startups don't attempt to emulate their pricing strategy. Instead, we are A/B testing our way to local maxima with products that are supposedly changing the world.
I agree. I'm also a little surprised at the false dichotomy presented in this thread. Using hand-wavy or made up numbers is not a meaningful way to have this discussion.
Every business has a different decision to make. It feels like this thread is thinking of it like maximizing an equation (FindingMaxRevenueGivenPriceSensitivies()). Instead, some products lend themselves to low cost support; sell those more cheaply. Some products require insurance-like support contracts -- those are going to be enterprisey. Some products will lend well to cheap inexpensive versions and high end enterprise versions, without changing the product (the value prop is really high to a business, esp if it's a service that can automate out the cost of a person's salary).
This thread and the obsession with A/B testing result from a hyper focus, like you said, on finding local maxima. I think it's often useful to take a step back and find the high level factors and built a pricing model around that.
(Of course, nothing excuses you from talking to customers.)
Every business has a different decision to make. It feels like this thread is thinking of it like maximizing an equation (FindingMaxRevenueGivenPriceSensitivies()). Instead, some products lend themselves to low cost support; sell those more cheaply. Some products require insurance-like support contracts -- those are going to be enterprisey. Some products will lend well to cheap inexpensive versions and high end enterprise versions, without changing the product (the value prop is really high to a business, esp if it's a service that can automate out the cost of a person's salary).
This thread and the obsession with A/B testing result from a hyper focus, like you said, on finding local maxima. I think it's often useful to take a step back and find the high level factors and built a pricing model around that.
(Of course, nothing excuses you from talking to customers.)
Uniformity and automation.
With only 10 customers, the customers are less likely to be uniform than with 1000. With 10 customers automation is overengineering, but you can only get to 1000 customers if your processes are automated.
So the 1000 customer company seems more attractive to an investor (or candidate employee) than the 10 customer company.
With only 10 customers, the customers are less likely to be uniform than with 1000. With 10 customers automation is overengineering, but you can only get to 1000 customers if your processes are automated.
So the 1000 customer company seems more attractive to an investor (or candidate employee) than the 10 customer company.
Easy...both.
Keep the $10/mo plans for consumers. And offer the $1,000/mo enterprise plans for enterprise.
That way your cheap customers will drive a lot of your high end sales.
Keep the $10/mo plans for consumers. And offer the $1,000/mo enterprise plans for enterprise.
That way your cheap customers will drive a lot of your high end sales.
Maintaining two product lines for two segments is a recipe for lack of focus and serving two masters. In the end you will choose to focus on one at a time and may never do both.
it's up to you to define your product line.
nothing is stopping you from just limiting the products.
Normal Accounts? Max 5-20 users.
Enterprise? Unlimited Users
no real difference between the products except for a single value
nothing is stopping you from just limiting the products.
Normal Accounts? Max 5-20 users.
Enterprise? Unlimited Users
no real difference between the products except for a single value
That's not really the same thing.
What you are doing is offering a commodity product at a large discount to larger organizations.
Take MS for example, you can buy Windows for $100 or so a copy or you can take a site license but the product is the same.
For a large enterprise what they need is someone to take that and fashion it into something that fits their needs, this is where consultancy businesses and "Microsoft Partners" come in. They will have a small number of clients for whom they will support the MS products and be the first port of call if anything needs to be changed/fixed etc.
Then MS has a nice side business is selling training and certs to these partners.
We tried to do a hybrid strategy some years ago and it was a disaster. What we tried to do was create a product that could be sold as a basic system for $100 or so and then provide a "custom" version to a handful of companies based on the same codebase.
What we learned very quickly was that these are competing goals, we would get requests from the bigger clients to fundamentally change something about the software to fit their use case which they expected us to do because of the amount they were paying. Of course many of these changes would totally break stuff for anybody else, so the choice was either to build some sort of monstrous configuration system for the product, break it up into modular constituent parts (very hard to do) or just give up on the idea of selling it as a commodity product.
We chose the 3rd option.
Take MS for example, you can buy Windows for $100 or so a copy or you can take a site license but the product is the same.
For a large enterprise what they need is someone to take that and fashion it into something that fits their needs, this is where consultancy businesses and "Microsoft Partners" come in. They will have a small number of clients for whom they will support the MS products and be the first port of call if anything needs to be changed/fixed etc.
Then MS has a nice side business is selling training and certs to these partners.
We tried to do a hybrid strategy some years ago and it was a disaster. What we tried to do was create a product that could be sold as a basic system for $100 or so and then provide a "custom" version to a handful of companies based on the same codebase.
What we learned very quickly was that these are competing goals, we would get requests from the bigger clients to fundamentally change something about the software to fit their use case which they expected us to do because of the amount they were paying. Of course many of these changes would totally break stuff for anybody else, so the choice was either to build some sort of monstrous configuration system for the product, break it up into modular constituent parts (very hard to do) or just give up on the idea of selling it as a commodity product.
We chose the 3rd option.
It's fine to have two products for different segments within the consumer or business markets, but having one product for consumers and another for businesses is not as simple as changing a single value. Very different customers with different needs, demands, and expectations of your product.
So why differentiate, other than with a value that clearly segments them?
This is not unlike Apple's laptop plan - before it was retired, the plastic unibody 13" macbook and 13" aluminum macbook pro had almost no distinctions to a consumer aside from exterior.
This is not unlike Apple's laptop plan - before it was retired, the plastic unibody 13" macbook and 13" aluminum macbook pro had almost no distinctions to a consumer aside from exterior.
In my experience, this is very hard to do well. What you'll usually get is either a lot of prospects that would pay for the high-tier end up paying less, thus dramatically reducing your profitability for the sake of "having an option for everyone"
I am currently close to releasing an app on the iPad and I have done lots of internal debating as to which price to choose. Here is my situation:
-I am entering a smaller addressable market, so I know I won't be able to grow forever and therefore I am focusing on building brand loyalty and getting repeat customers.
-I am planning on releasing new apps at a steady cadence, probably 1/month (it doesnt make sense in my situation to release new content within the app itself).
So with these two things combined, it seems logical to go at a low price-point. A low price point should gather initial customers and then be small enough to keep them coming back month after month. So I am currently leaning towards $1 per app.
But I have heard enough about the app market pricing and from people on this board to give me second thoughts, specifically:
-early users are insensitive to price-point
-ipad app purchasing is very elastic (ie you get the same revs depending on whether you sell it at $1 vs $4 etc)
I've thought a lot about releasing it at a higher price point, $2, maybe even $3. The biggest reason I am leaning towards $1 is the fact that I intend to release many apps and I see each as a microapp and therefore a micropayment. So even though I think one app may be worth more than $1, I think the value of each app over time is logarithmic. Therefore its better to sell 5 at $1 than 2 at $2, etc.
The apps themselves are interactive ebooks focused on military history. (a vague description, but unfortunately I am a few days away from having my website up)
-I am entering a smaller addressable market, so I know I won't be able to grow forever and therefore I am focusing on building brand loyalty and getting repeat customers.
-I am planning on releasing new apps at a steady cadence, probably 1/month (it doesnt make sense in my situation to release new content within the app itself).
So with these two things combined, it seems logical to go at a low price-point. A low price point should gather initial customers and then be small enough to keep them coming back month after month. So I am currently leaning towards $1 per app.
But I have heard enough about the app market pricing and from people on this board to give me second thoughts, specifically:
-early users are insensitive to price-point
-ipad app purchasing is very elastic (ie you get the same revs depending on whether you sell it at $1 vs $4 etc)
I've thought a lot about releasing it at a higher price point, $2, maybe even $3. The biggest reason I am leaning towards $1 is the fact that I intend to release many apps and I see each as a microapp and therefore a micropayment. So even though I think one app may be worth more than $1, I think the value of each app over time is logarithmic. Therefore its better to sell 5 at $1 than 2 at $2, etc.
The apps themselves are interactive ebooks focused on military history. (a vague description, but unfortunately I am a few days away from having my website up)
This is simply a restatement of what Philippe Kahn showed the world and more particularly Microsoft. The Borland compiler came pretty much from no where and became a serious competitor for the powers that be. While the IDE was quite impressive, the major difference lay in the price. As I remember it, Borland was very near $100 while Microsoft was much closer to $500. Details (some) here: http://en.wikipedia.org/wiki/Philippe_Kahn More elsewhere by way of Google or your favorite search engine.
What is even more impressive was that while Borland began its rise without venture capital to 500 million dollars in sales Kahn himself was an illegal alien.
http://www.fundinguniverse.com/company-histories/Borland-Int...
http://www.fundinguniverse.com/company-histories/Borland-Int...
I view the acquisition as a tradeoff in whether you'd like to exert a lot of effort upfront or down the road.
If you exert a lot of effort upfront, you can collect a few high-paying customers and provide more tailored support to their needs. Of course the fewer customers you have means each has a greater proportional influence in affecting the direction of your product. That is, assuming customer feedback is something you're interested in, which I acknowledge is not necessarily always the case.
If you would rather exert effort more "constantly" and gradually down the road, than the many customers approach is good. Many apps which end up in this situation do so because of a massive user spike at the point when their app "goes big". In that case, the short-term growth is clearly not gradual, but the long-term growth leading up to that point may be.
My personal preference would be a small to medium customer base to provide more tailored support.
If you exert a lot of effort upfront, you can collect a few high-paying customers and provide more tailored support to their needs. Of course the fewer customers you have means each has a greater proportional influence in affecting the direction of your product. That is, assuming customer feedback is something you're interested in, which I acknowledge is not necessarily always the case.
If you would rather exert effort more "constantly" and gradually down the road, than the many customers approach is good. Many apps which end up in this situation do so because of a massive user spike at the point when their app "goes big". In that case, the short-term growth is clearly not gradual, but the long-term growth leading up to that point may be.
My personal preference would be a small to medium customer base to provide more tailored support.
I think having to please fewer customers could be great, but you run a greater risk of someone undercutting you and taking them away. Though, if you have 10 customers vs 1000, it's a lot easier to personally try convince those 10 to stay.
Welcome to HN.
In general, people (especially businesses) do not make decisions based on price. This is one of the most common misconceptions of new software/startup founders. Indeed, for higher paying customers, they are often shockingly price insensitive, assuming you are genuinely delivering value to them.
More on this topic in my Microconf speech in, oh, 7 hours or so, but I'll try to hit the highlights in a blog post or something in the coming week.
In general, people (especially businesses) do not make decisions based on price. This is one of the most common misconceptions of new software/startup founders. Indeed, for higher paying customers, they are often shockingly price insensitive, assuming you are genuinely delivering value to them.
More on this topic in my Microconf speech in, oh, 7 hours or so, but I'll try to hit the highlights in a blog post or something in the coming week.
This depends if you are dealing with public sector organizations or not.
In many cases these organizations have to review their contracts every X years and have to take the cheapest deal (unless they can provide evidence that the supplying cannot produce what they have promised etc).
I have spoken to a few people now who were supplying various government departments and had excellent supplier/client relationships (they were going out of their way on weekends to fix problems etc) where under any ordinary circumstances this would continue. However they got to the end of some review period and another supplier (who is known for providing very mediocre service) undercut them by some small amount that they were unable to match so they were unable to continue the relationship despite every stakeholder being happy.
In many cases these organizations have to review their contracts every X years and have to take the cheapest deal (unless they can provide evidence that the supplying cannot produce what they have promised etc).
I have spoken to a few people now who were supplying various government departments and had excellent supplier/client relationships (they were going out of their way on weekends to fix problems etc) where under any ordinary circumstances this would continue. However they got to the end of some review period and another supplier (who is known for providing very mediocre service) undercut them by some small amount that they were unable to match so they were unable to continue the relationship despite every stakeholder being happy.
I would always, always
— always —
prefer a higher margin and fewer customers.
— always —
prefer a higher margin and fewer customers.
Just tossing it out there, but isn't the price point of a product also a big director in consumer expectations? Not that I support making a crappy product, but consumers who pay a lot more generally have higher expectations about what they're spending their money on (rightly so, at times). If you have a 1000 people who figure it's the price of a soda so who cares vs 10 people who won't get off your case about some pet feature they want. It's all hypothetical, but maybe something to keep in mind.
You'd be surprised! In my experience, folks who pay A WHOLE NINETY NINE CENTS OF MY MONEY have very shockingly high expectations of polish / quality / feature selection (but no desire to e.g. read what the software actually does), whereas if someone signs e.g. a contract for $X0,000 for enterprise software, it lacks a feature, and they ask for it, "Thanks for the feedback, we'll consider adding that in a later release. In the meanwhile, I suggest ... as a work around" makes them absurdly happy.
For more on this topic, go to HNsearch.com and look for [patio11 pathological customers].
For more on this topic, go to HNsearch.com and look for [patio11 pathological customers].
Given that a 99c app will attract a _much_ larger user base, chances of running into those users who expect to sit on the front row seat for free also increases.
The nice thing is, they can be ignored, as long as you do it tactfully. If you lose them as a customer, it's no big loss. A single extremely high demanding big customer that pays in the ten to hundred thousands is hard to ignore. In fact, their high demands can run your business into the ground, if you're not careful.
The nice thing is, they can be ignored, as long as you do it tactfully. If you lose them as a customer, it's no big loss. A single extremely high demanding big customer that pays in the ten to hundred thousands is hard to ignore. In fact, their high demands can run your business into the ground, if you're not careful.
Absolutely see this for customers of iPhone apps. If. You're not careful the avalanche of customer service requests on a 99c app can sink you
"In my experience, folks who pay A WHOLE NINETY NINE CENTS OF MY MONEY have very shockingly high expectations of polish / quality / feature selection (but no desire to e.g. read what the software actually does)"
What you do? You shut them out.
Not "remote disable them". But feature/support requests policy has to be simple. Either a user forum, FAQ, etc
You should absolutely not waste your precious time with this kind of work. If they want a refund just give it to them (not sure how easy this is on App Store or others)
Also, if this is so overwhelming, raise the price If they really want this so much they can pay 1.99
You don't need to ignore everything they say, but take it with a huge grain of salt.
What you do? You shut them out.
Not "remote disable them". But feature/support requests policy has to be simple. Either a user forum, FAQ, etc
You should absolutely not waste your precious time with this kind of work. If they want a refund just give it to them (not sure how easy this is on App Store or others)
Also, if this is so overwhelming, raise the price If they really want this so much they can pay 1.99
You don't need to ignore everything they say, but take it with a huge grain of salt.
Thanks, yeah I'll have to check that out. It seems like people sure can be nuts about their money.
I can tell you from our experience with Stormpulse that this is 100% false and backwards. Those that pay more are more willing to work with you. Nothing more expensive than someone that expects the world for $10.
Maybe it's not that they pay more that makes them more likely to work with you, but rather there's something about people who have more money to spend (ex Enterprise-level customers) that changes their awareness of the realities of the solutions they buy.
They are convinced of the value and therefore less likely to abandon the product because of one negative. Whereas if you aren't sure the app is really doing something for you (making/saving you money), you're more likely to bail and just get your money back the moment it goes
South.
That's a really good way of framing it. It's good to get insight from people who are in the thick of it (I'm not). Thanks!
I think that often the cheaper products tend to be the most polished.
Let's say you are developing something with < 100 users, how good does the UX have to be?
Designing say a beautiful UI full of clever widgets is probably a waste of time vs adding features. It just needs to be "good enough" to use, if the users are having problems with it then it is probably more economical to get them in a room together and run a training session at which point they will grumble, stick some postits to their monitors and carry on.
I've developed some programs before that have had bugs and when I've offered to get right on and fix them I have been told by the client "don't bother, I'll just tell the users not to click that button under those circumstances".
With the cheaper app you are looking at ways to do things that will wow 100,000 people rather than just a few.
Designing say a beautiful UI full of clever widgets is probably a waste of time vs adding features. It just needs to be "good enough" to use, if the users are having problems with it then it is probably more economical to get them in a room together and run a training session at which point they will grumble, stick some postits to their monitors and carry on.
I've developed some programs before that have had bugs and when I've offered to get right on and fix them I have been told by the client "don't bother, I'll just tell the users not to click that button under those circumstances".
With the cheaper app you are looking at ways to do things that will wow 100,000 people rather than just a few.
If your product needs zero rework for each sale (and scales easily), many customers is the obvious way. If it requires a sales process (even if it's as simple as signing a contract), less customers (paying more) is the way.
Personally, I prefer the "less customers" approach. I find it much easier to pleas everyone and feel like I'm not "working for free" when "everyone" is a relativelly small group and the payback is still high
Personally, I prefer the "less customers" approach. I find it much easier to pleas everyone and feel like I'm not "working for free" when "everyone" is a relativelly small group and the payback is still high
$1,000/mo. is fine except if it becomes a mainstream need, then competition turns up with it's $100/mo. product (or even free) and you can't drop the price because the sales cycle costs too much, product requires individual integrations etc.
I've definitely concluded that work hectic is proportional to the number of clients to keep happy, but I imagine this only kicks in above a certain price point.
How clearly and "piss easy" your product or service works makes a big difference too. I run e-learning ventures since a few years and just changing the starting page of a course area can have dramatic influence on the amount of customer support you have to take care of.
After some time having a rather expensive product that is still popular is the best of both worlds and it can work out, especially if you are in a market where people need what you offer.
After some time having a rather expensive product that is still popular is the best of both worlds and it can work out, especially if you are in a market where people need what you offer.
The optimal price is obtained by maximizing price * number clients.
establishing a huge user base first is definitely better than scoring a few customers, who might unsubscribe at anytime because of the high price
It all depends on the elasticity of consumption.
I'm not an expert in this topic, but I would say that the many customers at the low price-point are more important than the few high-price one. If you have only 5 high-price customers, which generate the most of your income and they decide to break up the business relations with you, than you have probably a big problem and loose a lot of money. So, I think it's better to have a lot of low price customers, because if some of them break up the business relations with you, then it doesn't matter that much. You have enough low-price customers left, which generate the most of your money and some high-price customers on the top of it, which generate a lot of money as well. So the risk to loose money is probably lower. SAP is a good example. They first produced products for the big and important companies, but they figured out that the middle-class customers generate a lot of money as well. I guess it can differ, but I think it's probably the better decision.
With low-value products? Here is the price. want it? If you want to change the price, sure, sometimes you need to do that, but you change it for everyone. (In fact, in the VPS sector, It is traditional to change the price for existing customers as well as new customers. Linode deserves some of the credit for making that traditional. In the co-lo or bandwidth business, where it's all negotiated? it's traditional to offer like 50% better deals to new customers and to squeeze your old customers until they leave, like it is in real-estate leases. I recently lowered the price on my low-end co-lo and gave the lower price to all my existing customers, to much surprise. )
Right now, I'm trying to move some products that are traditionally sold with lots of negotiation (Like co-location) into the "here is the price, you want it?" model, which is really in everyone's interest except the salesguy. And salesguys in this industry make a lot of money; two big local co-lo salesguys have contacted me; I know they are good, and that they can bring me customers, as I know a bunch of people that bought through them. The problem? they want 10% of the revenue from the customer for the life of the customer. 10% isn't far from my own target margin for co-lo, and some plans, I don't even make that much. And for the life of the customer? through any upgrades down the road? it seems like a bookkeeping nightmare.
The other advantage of having lots of small customers is that if someone wants something that you don't want to do? (in my case, for instance, people that want password auth to my infrastructure, or people that want to run windows) it's pretty easy for me to say "That's not what I do. Here is a refund; I hear that provider X can help you out" - whereas if that customer was 1/10th of my revenue? I'd be spending all night trying to get a microsoft system working, or cleaning up after a script kiddie broke into a weak password and got into the customer's management interface.