How 37signals Destroyed SaaS Pricing Power

Published 13 May 2014 by C. G. Brown

This isn't a hit piece. I like 37signals a lot and admire their business. A lot of who we are, we learned by watching them.

However, one of the things that we (and our competitors) learned from them was wrong. And that's how to price a SaaS service.

I recently read a piece written by Jason Fried about how 37signals came up with their pricing. He said they priced on two factors:

  • What would they pay?
  • What numbers feel right?

 

The first one sounds fair at first. He cites the example of Campfire, where they were going to charge per chat but then realized that wouldn't fly; that's not how people think about chat. They eventually came up with a recurring fee for x number of chat rooms, which makes sense. That's reading the market, understanding your value, and pricing accordingly.

Campfire and Basecamp in particular, were products they understood well and used in their daily jobs. If you are building something for an industry that is more outside your direct daily experience, you may need to get input from people who know what the solution is worth, tangibly and intangibly, and find out what they would pay.

How much would I pay for a factory monitoring system? I don't know, a few thousand, maybe five figures? Sounds like a lot, right? What if I told you that it would save $3,000,000 a year? I have no idea of the pain felt and the value received, so I can't effectively tell you what I would pay. I'd need to defer to someone who knows the business directly.

As for his second point, "what numbers feel right" is a dangerous place to be if your market is not sufficiently large. For instance, in our industry, it's easy to approach the problem as "throw some open-source stuff up on a box and run it" instead of "how can we make software developers' jobs go faster and easier" and look at the problem as a variant of web hosting. However, managed development is a different and more focused market than web hosting, and also requires more complex solutions to truly meet developer needs.  

A tools-based approach instead of a solution-based approach doesn't take into account the needs and ways of thinking of your customer. In the best case, you'll leave money on the table by not providing a people-oriented solution. In the worst case, you won't be able to convince customers that your tools are better than doing it themselves. In either case, selling a bare-bones answer into a market that is demanding more leaves the seller without the resources to creatively meet the need, and robs the buyer of a complete solution to their problems.

(As an aside, if you are trying to decide to build instead of buy, we've developed a great worksheet that shows you the true cost of ownership of managed development infrastructure. You can download it by clicking the button below.)

Download The Worksheet

Fried and DHH guessed right about Basecamp, a simple platform to share information on projects without lots of methodology overhead, perfect for designers and customers who just want to get things done.  However, with Highrise, a business relevant to them but not squarely in their field of expertise, that same pricing potentially leaves a lot of money on the table. CRMs are used by sales people with a value directly traceable to revenue, and as such are priced per-seat. They could charge more and still deliver substantial value above their cost to customers, but by being tied to that pricing model, they lost an opportunity.

Many companies set pricing based on what feels right, rather than what supports a viable business that can deliver optimal value. Fried states in his comments that "you can change prices if you have to". Our experience has been that on the contrary, you can generally lower prices, but it's much more difficult to raise them. Your guess may not be exactly right the first time, but there's a limited range. Too low, and you can't grow, but too high, and you can't attract customers.

Companies with limited pricing power sounds like a great deal for customers, but in the long-term the ecosystem is harmed. Customers get a great price today, but the companies in a space where pricing power has been weakened substantially have a harder time gathering the resources to innovate, either through revenue or funding. The end result is a space that could be doing more for customers, but isn't.  

When you next evaluate software as a customer, don't just trust your feelings or look for the cheapest solution. Work the numbers, and see how much a SaaS solution can save you over running things in-house or building a solution from scratch. In most cases, the value should be obvious.

Once you've done that, the equation is simple. Either your purchase saves or earns meaningfully more than you spent on it or it doesn't. 

Topics: Business, Software Development, SaaS, Pricing

Subscribe to ProjectLocker's Blog

Follow Us

Get Updates by Email

Follow @ProjectLockerHQ on Twitter

Follow Us

Free Checklist: How to Choose Source Control for your Project