
Big Customers? Who Needs 'Em (Jason Fried) - joshuacc
http://www.inc.com/magazine/201206/jason-fried/huge-accounts-make-me-nervous-it-takes-a-village.html
======
pchristensen
Even for people tired of 37s, this is a great quote:

    
    
      "We're probably leaving money on the table. But we're also leaving complexity on the table."

~~~
gdilla
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.

------
the_bear
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.

~~~
smokey_the_bear
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.

~~~
coffeecheque
Why not jump ship to another provider? Bitbucket, for example, charges "per
user" rather than per repo.

------
trustfundbaby
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

~~~
Aaronontheweb
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?

~~~
trustfundbaby
> 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.

------
studiofellow
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.

~~~
SatvikBeri
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.

------
georgemcbay
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.

------
larrys
"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.

------
larrys
"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.

