I like that quote. But conquering complexity also leads to competitive advantage, differentiation, and barriers to entry. It's nice to be able to defend your products and services from imitators.
I agree that there are some serious benefits to having many small customers rather than a few big ones, but I strongly disagree with their decision not to charge per user. When you charge per user, the cost of the software increases linearly with the number of people using it, which is generally appropriate. Instead, with Basecamp pricing, the cost is based on the number of projects which seems way more arbitrary, and it incentivizes very strange behavior.
For example, the cost of going from 9 projects to 10 projects is $0. The cost of going from 10 to 11 is $30/month. Tiered plans like that have always seemed confusing and unfriendly to me.
I'd argue that charging per-project makes much more sense than charging per-user. Charging per user creates incentives to have as few users as possible using Basecamp, which makes it much less useful. Charging per-project means that you're charging based on how much people are actually using your product, not based on how many people happen to have accounts.
Tiered pricing is easy to understand and predictable. Businesses (and people) like predictability when it comes to pricing. In most companies, it's a lot easier to say "we are going to pay $X a month (or year) for this product" than to say "we are going to pay somewhere between $X and $Y this year".
In any case, if you have more than 10 projects you're probably a large enough group that paying another $30/month is not an issue. And if you're not and $30/month more is too much, 37s response would probably be that you're not the kind of customer they're targeting.
If charging per user encourages companies to have fewer user accounts, then certainly charging per project encourages companies to enter fewer projects, which is even worse (given that managing projects is the whole point).
However, I should rephrase my complaint. I'm not opposed to per-project pricing rather than per-user pricing, I'm opposed to tiered pricing in general. It's ridiculous that there's a 150% price increase for adding one project. Then, after adding 29 more projects for free, there's another 100% price increase for adding one additional project. I don't see how that can be considered "charging based on how much people are actually using your product."
Tiered pricing isn't simple (my customers tell me this all the time), it isn't predictable (my costs just increased by 150% because an employee started working on a new project!?), and it incentivizes all the wrong kind of behavior. The only good thing about it is that it's a great way to get some companies to pay for more than what they actually use (why do you think the cable companies don't have a la carte pricing?)
You're conflating two separate arguments I made about two separate topics. The first is about per-project vs per-user pricing. The second is about tiered pricing. They are independent.
First, per-project pricing:
Any pricing scheme creates incentives. You get customers' money when the benefits outweigh the price. Per-project pricing makes it easy to get your product in front of as many eyes as can benefit from it, which can create internal network effects that boost internal adoption, which in turn leads to more use. Per-user pricing does not have similar network effects, because you associate a cost directly with adding people to the network.
(Which doesn't mean that per-user pricing has no place ever--that's absolutely not my point--just that it's not something that always makes sense.)
Second, tiered pricing:
It absolutely makes sense that your customers like per-user pricing: they've already self-selected to use your product, which has per-user pricing. The people who don't want per-user pricing are probably just going to ignore your product in the first place, and you'll never know they exist. Tiered pricing is preferred by a certain class of customers. Some of the reasons for that are listed in my initial post. It's unsurprising that it's not preferred by other classes of customers.
Again, I am not arguing that tiered pricing is a universal good or anything similarly silly. What I'm doing is arguing against your suggestion that tiered pricing is always bad.
Tiered pricing isn't simple (my customers tell me this all the time)...
Can you talk more about this?
Overall, pricing is difficult and I'm currently struggling with it for an idea I have developed. So I would like to hear different opinions on pricing.
Sure. My company is called "Less Annoying CRM" and one of our main marketing techniques is to identify all the things that annoy people about existing CRMs, and then do something that's not as annoying. Pricing is one of the huge things customers find annoying with business software right now. This is all anecdotal, but here are some things my customers have told me they hate about the pricing practices of other CRM companies:
-Requiring a credit card up front (assuming there's a free trial). Everyone is worried that they won't be able to cancel once they've signed up.
-Listing prices by month, but charging annually, or requiring an annual contract. It's easy to think that an extra hundred dollars up-front isn't a big deal, but it really is for many small businesses. You'd be shocked at how many companies struggle to afford their monthly software licenses.
-Limited free trials. Many people I talk to are shocked when they find out that the free trial works just like the paid version. I didn't realize that some companies offered limited free trials, but apparently they do, and customers hate it.
-Forcing customers to choose how many seats they want in advance, rather than just billing based on how many users there are in a given month. This makes it look like you're hoping a customer will pay for seats they never use, and the customer instantly stops trusting you.
-Having tiered pricing plans, particularly if more than one thing can trigger the next tier. For example, if you look at the Highrise pricing page (http://highrisehq.com/signup) some companies might only have two users, but they might need 20 deals. Or they might have one user and one deal, but more than 5,000 contacts. Tiered plans can make it very difficult to figure out how much you'll actually pay, and it forces the users to constantly be paranoid that they might accidentally trigger the next level without knowing it.
This obviously depends a lot on your specific business, but here's the approach that I like best based on my experience: First, figure out what type of activity has the highest correlation with value added for the client. For example, we decided that each additional user on the system is the most important dimension on which to bill, but a project management product might pick # of projects. Then offer a la carte pricing based on only that one dimension, and make everything else unlimited.
For my company, this means we charge $10/month/user, and everything else is unlimited. You can put some caps in place under the terms of service to prevent people from abusing your unlimited policy, but make them high enough that they won't impact any of your non-abusive users.
You wouldn't believe how much it helps to have a simple pricing policy. How much does it cost? $10/user/month. What if I have a lot of contacts? $10/user/month. What if I need access to the API? $10/user/month. What if I need mobile access? $10/user/month. This approach removes a major stress point from the lives of the users because they no longer have to worry about trigger the next billing tier based on normal, everyday usage. It also makes your life easier because you when customers try to negotiate the price with you, you can make it clear that every single customer pays the exact same price no matter what.
I've had customers on the phone tell me that they love me because of this pricing model. Seriously. As I mentioned, this is all anecdotal, and I don't have any hard numbers to back up the efficacy, but it seems like common sense, and my customers validate the approach every day.
I've some reservations with regards to your pricing model. Say when I go from 3 user to 4 users I pay 33% extra. At basically no extra cost for you as a supplier ... (the operational cost difference between 3 or 4 users is in the case of a CRM system negligible). That simply doesn't feel right.
1) That is even more true for tiered pricing. Is there an alternative you know of that doesn't involve the price going up as your usage goes up?
2) If you expect software pricing to match the marginal cost to the supplier, then I think you're out of luck. All software is this way. There are huge up-front costs to build the software, and the cost of actually selling an individual license is close to zero.
Pricing in general shouldn't be about what a product costs to provide, but rather what it's worth to the customer.
I do not expect software pricing to match the marginal cost to the supplier per se. And you're right that pricing in general is done in relation to what's the customers perceived value.
However, I disagree with your first statement. Lets take Highrise pricing plan as an example. For the 6 user plan you pay $24/month - which comes down to $4 per user. For the 15 user plan you pay $49 - about $3.26 per user. So my total cost of course goes up with usage, but not in a linear fashion.
You could also make that happen with the $x/user/month scenario, but that gets probably rather complex without ending up with tiers again.
Thank you for your response because it was - for me - really informative. I really like your approach to pricing (as well as how you developed your pricing model).
We have that problem with Github. We're a three person company and we do most of our work on iPhone apps. We spend 95% of our development effort in our main repo for our main app. But we have some other repos for the website and for some contracting, and for some experiment projects that make the most sense in their own repos, but Github penalizes us for that.
We'd probably have 30 projects on Github if their pricing was set up differently instead of cramming it into 20. We're already paying them 50/month, which seems high.
If we were a larger company that worked less with outside people we could just have one repo that was a misc catch all, and put things in folders inside that, but we often need to manage permissions with outside people.
I think Jason has this perspective because basecamp caters to smaller businesses (basecamp isn't an enterprise product per se). Big/enterprise customers will usually want to have software like basecamp housed on their own servers vs having to sign up for a SaaS, and its instructive to note that even though github follows the same pricing model as basecamp (top plan has unlimited access) ... they do have a much more expensive product targeted at the enterprise crowd ... https://enterprise.github.com/
Its pure speculation on my part, but I think that if he had a bunch of 500+ user companies signing up to use basecamp for $150/mo, then sucking up bandwidth, storage space and cpu cycles, basically for free, he'd feel a little differently
The cost economics for this model for a CRUD application like everything 37 Signals builds seems favorable for a capped pricing model. Having a business where all of the data is entered by a live human being on a keyboard slows down the pace of consumption to a point where COGS are negligible (in my limited experience.) In an organization with 30,000 people using BaseCamp you're still not likely to get > $150 worth of COGS in data storage, compute, or bandwidth since all of that data still has to be intentionally, manually created by a person. And the pareto principle still applies: only a small portion of those users in an enterprise organization are going to be the ones who actually use it with regularity and frequency.
I don't know if a flat / capped price model like Jason's will work for a more service-oriented product that integrates deeper into the organization and touches parts of a company's automation, like a payment processing gateway or a web analytics system. What type of COGS would a web analytics service incur for a website with millions of uniques a month?
> In an organization with 30,000 people using BaseCamp you're still not likely to get > $150 worth of COGS in data storage, compute, or bandwidth since all of that data still has to be intentionally, manually created by a person.
I hadn't actually thought about that. good point. However, I think you forgot to factor in consumption of said resources. Just as a wild example I can upload a 50MB video by myself, if 1000 people in my 5000 person company view that video, thats 48GB in bandwidth that somebody has to pay for.
> I don't know if a flat / capped price model like Jason's will work for a more service-oriented product that integrates deeper into the organization and touches parts of a company's automation, like a payment processing gateway or a web analytics system. What type of COGS would a web analytics service incur for a website with millions of uniques a month?
I think this was more along what I was (very clumsily) trying to say. A resource intensive service wouldn't work that well with this capped pricing model.
So you are saying that hosting is what makes the difference between products like Basecamp and other enterprise software? I am genuinely interested in knowing the differences. Specifically, I want to know what makes up enterprise software.Should anything that is not SaaS but is still provided to more than few companies be considered enterprise?
What I'm saying is that, for whatever reason, Basecamp & 37 Signals in general doesn't strike me as having a lot of enterprise-scale customers (500+ users for me), probably because they don't go out of their way to attract that crowd.
Because of this, I don't imagine they've had to deal with issues of lots of users consuming massive amounts of resources, hence their perspective.
But I'm completely speculating here ... they do factor GB of storage in the pricing for basecamp, so there's that
I can't help but wonder whether leaving money on the table and leaving complexity on the table are correlated to such a severe degree at every price higher than $150.
Big customers are dangerous, and I've seen businesses where I have worked (ad agencies) operate completely out of fear of losing the big accounts.
But is there no middle ground between $150/mo and thousands/mo? What about $250/mo or $500/mo? Would tiers like these necessarily add complexity?
Obviously, it depends on the data. Speculation: a handful of customers paying $250/mo might not justify the dev time needed to implement the new plan or the risk introduced by pricing changes.
This is a good question, and the truth is there actually isn't much of a middle ground between a few hundred dollars/month and thousands or tens of thousands.
The reason is purchase process. Any purchase above a certain about usually has to go through the procurement department at a large company, which means that any sales above that amount become very expensive. That's why there's such a big gap in software prices.
"This, of course, is unusual in our industry. Many of our competitors, and nearly every company that sells enterprise software, charge per user (or per seat, in industry parlance)."
Could be also be a case of being the fool at the table. If everyone in your industry prices a certain way and you don't, sure maybe you are inventing a new model and not taking advantage of people.
But maybe there are reasons they do this that you don't understand yet or haven't experienced?
One example is what I would call "the rule of large numbers".
If I have 200,000 people using my service there are going to be more problems that show up then when I have 10 users.
Let's say I offer webhosting to a single customer with 10 employee email boxes for a total of $20 per month so then I have one set of customer support issues based upon the number of people that could potentially have problems.
Now let's say I offer a webhosting reseller account for $20 per month. And the reseller can offer 500 sub users each of which have the potential to create 10 employee email boxes per account. So potentially there are 5000 email accounts that are now setup.
And you don't think there will be more support issues with 5000 email boxes then with 10? And you don't think if there is a service interruption there will be more pressure to get things restored when 5000 users are having problems rather than 10? And more legal liability?
More "seats" creates more potential issues.
I've had equipment service contracts in the past where the service provider only authorizes a single point of contact. They don't want to have to deal with a bunch of newbies using the equipment each time it jams. They want a person who will ride over those newbies and already be able to intercept any cases that they have already been trained for.
"What's more, it's not fair to your other customers if you're putting most of your energy into pleasing the big spenders."
Grow up. What's not fair about that?
Why shouldn't service be separated by the degree to which you are important business wise as a customer?
Your largest customers many times subsidize your smallest customers who you might not make any money on at all.
While I don't necessarily disagree that there is a benefit to being able to not be controlled by a big customer that is a business decision that you have to make strictly based on what your business model is. Unfortunately in some businesses it's not possible to not cater to large accounts.
Great article that hits home since I work for a company that uses Github Enterprise and Basecamp and the company bends over backward to avoid adding new users on Github Enterprise while having no such concerns about Basecamp.
The decision to use Github Enterprise to begin with was not, IMO, a good one (we could be paying $25/month instead of $5000/yr while having many more users and saving on admin costs too), but the IT culture is such that if they can bring something in-house, they do it (even if the cost structure results in having to stupidly limit use). But the fact that we also use Basecamp shows that if the service isn't available via the in-house model but is still useful, we will still adopt it.
