Which is better: Many customers at low price-point or few at high price?
blog.asmartbear.com
blog.asmartbear.com
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.
"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.
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.
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.
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.
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 :).
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.
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.
Personally, I love the high stability of a broad consumer base. However, you can architect a successful business either way.
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.)
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.
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.
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.
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
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.
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.
-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)
http://www.fundinguniverse.com/company-histories/Borland-Int...
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.
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 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.
— always —
prefer a higher margin and fewer customers.
For more on this topic, go to HNsearch.com and look for [patio11 pathological customers].
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.
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.
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.
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
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.