Pricing heuristics

If you’re an early-stage founder and you’re not charging for money for a product that you intend to eventually charge money for, you should start doing it, now. That’s because the best way to tell whether you’ll be able to charge money tomorrow is to see if you can successfully charge money today.  

If early customers refuse to pay for your product then you have a strong signal that you need to change something with your approach. Many founders avoid this at first because it’s uncomfortable and because it’s a big hairy problem. It’s so abstract that it’s partly philosophical.

That’s why there’s almost as many theories of pricing around as there are entrepreneurs. In my opinion, the best way to approach a hairy, abstract problem like this is to simplify it by using a heuristics, or rules of thumb, as a starting point.

Below are a few common heuristics that worked for me at Firefly.

While none of these are particularly ground-breaking, I hope it’s useful to see them all in one place and explained for early-stage founders (instead of MBAs).

Heuristic #1: Value-based

If what you’re doing really hasn’t been done before (much less common than most entrepreneurs think) and there aren’t any comparable products for you to base your price on, then a good model is called value-based pricing. It works like this: estimate the amount of value your product brings to a customer, and then charge some small percentage of that.

In practice, this is much more difficult than it seems because in most cases you have no idea how much value you bring to a customer. So you start with a bunch of assumptions – and depending on whether you think you should charge a lot or a little you fit your assumptions to your preference – and boom out comes the number that you wanted all along.

But this approach has the advantage of forcing you to make your assumptions explicit so that later on you can modify the price as you falsify or change them.

Heuristic #2: Cost-plus

You can look at how much it will cost you to build and support your product and charge some multiple on that. Generally the cost in cost-plus is referring to unit cost – the cost to produce one unit of a product. However, because many software companies have very low unit costs, this heuristic may not seem to apply to a lot of you.

However, sometimes adding a customer will increase the overhead required to run the business. In this case, it can be good to incorporate the overhead costs into the cost-plus model when pricing to be sure that you won’t end up losing money by signing a new customer.

For example, at Firefly we were signing contracts that required us to support the product 24/7, so we looked at what it would cost us to hire enough people to do that support so that we could estimate whether the value of the contract made that worthwhile.

We didn’t end up hiring 24/7 support people, we just always had our cell phones turned on and under our pillows, but it was a good exercise nonetheless.

So, for software, cost-plus can be a good defensive pricing strategy, or a good way to set your floor.

Heuristic #3: Look at your competitors

What are your competitors charging? This is often the best place to start because they already have much more information than you. Map out every offering and its price. Then either go higher if you’re trying to create a premium product, or go lower if you’re trying to provide the same value at a lower price.

Even if a competitor doesn’t do exactly what you do, it’s still a useful barometer. For example, when we were starting Firefly and were doing pricing for the first time, we looked at other co-browsing companies but because there weren’t many out there we also looked at screen sharing companies.

This allowed us to come to market with a price that was reasonable, that we could get in the door with and justify.

Then we modified it from there.

Would I do this for 10 years?

Let me tell you something I believe that I think most people in tech don’t:
If you’re a young entrepreneur just starting out, asking yourself “Would I do this for the next 10 years?”, as a way to figure out whether or not you should be working on something, is, in my opinion, totally unhelpful.

This isn’t because I’m advocating against a long term approach. I think it’s great to work on something for a long time.

Rather, I think it’s a bad question because we’re just not good enough at predicting our desires over the long term to be able to answer it. We’re capricious animals. We’re generally fickle and impulsive. We’re maddeningly mercurial.

Mostly this advice is given by 50-year old investors to 20-year old founders as a way to figure out what they should work on. But I think it misses something important: when you’ve never worked on anything for more than a couple of months, you don’t have the tools to judge whether your answer to this question is reflective of temporary enthusiasm or something more lasting.

I’ve seen this first hand. I can’t tell you how many of my friends have come to me at some point or another and say things like, “I feel like I’ve found it! Supply chain management is what I want to spend the next 10 years on!”

With a few exceptions, they’ve almost always moved on to something else within a couple of months.

Most pressingly, when you’re just starting out, I think asking yourself that question can be actively harmful because it sets the bar too high. If you’re constantly asking yourself, “Would I do this for 10 years?” for something you’ve just started, the answer is more likely than not to be “No” at a few points along the way — given the extreme ups and downs involved in starting a company.

When you ask yourself that question, you’re focusing on surface-level results which tend to fluctuate randomly early on. Some days you’ll be on top of the world, and some days you’ll be down in the dumps. It’s a bad habit to draw long term conclusions (like whether you should be working on this long term) from short term results. It will make it much harder to manage your psychology.

Instead, it’s more helpful to ask yourself questions whose answers don’t depend so entirely on how things have been going that day. For me, the most helpful one was this:

Am I learning? Importantly, am I learning what I want to learn?

If the answer was yes — and at Firefly the answer was mostly yes — it gave me the stamina to keep working even when things didn’t seem to be going my way. And that can make all the difference.

One good trick for interviewing candidates at a small startup

At the beginning of every interview I always ask one question, and it almost always separates the high-quality, serious candidates from the people that are just curious or are used to skating through interviews. The first question I ask is:

So can you pitch me what our company does?

And it’s always 100% clear which candidates have spent time doing their research and thinking about our product and which ones have just shown up hoping to wing it.

This isn’t as useful for a really well-known company, but if you’re a small startup it’s wonderful.

And the best part is that I’m not giving up any secret that will make this less likely to work in the future. The only people who will read this are the ones that already do research anyway.

Should I OEM my product?

I was sitting on my roommate’s dilapidated couch in West Philadelphia when the contract came in:

$4,000 a month with significant room to grow.

There was a squiggle at the bottom of its 15 pages indicating that a real live person working at a real live company had committed to pay us that much money every month for some software we had written.

I checked everything through to make sure this wasn’t a joke. Then I screamed my head off with joy. This was it – we were finally a real business.

We had launched Firefly approximately 11 months prior, and until then had been scraping along with about $1,500 a month or so in revenue from a few small customers. For a bootstrapped startup run by just two college age kids this latest contract represented a giant step up in our revenue graph, and by extension our prospects. We could now run the business indefinitely – and maybe even hire someone to help us out part time.

This moment validated a somewhat unusual strategy we had decided to pursue some months prior. We had started out the company selling directly to the customers that were going to use our product. But over time we had shifted strategies, and this deal was the first fruit of that shift. Instead of selling directly to customers, we decided to build our product into an API, and allow other companies to build it into their products, and sell it to end-customers for us.

How we got to the API strategy

We had this technology we had built called co-browsing. Basically, it works like screen sharing, but instead of sharing your screen you share just a web page. It doesn’t require any downloads or installations to run, and it works across platforms (Mac, PC, iPhone, iPad and Android).

After some playing around we decided to focus primarily on a customer service use case: when a customer is having a problem with a website, we allow the agent to look over their shoulder and help them through the site in real time.

And we had been trying to sell it with some success, but we weren’t blowing it out of the water. What we found was this: small companies wanted it but couldn’t pay too much for it. Big businesses, on the other hand, moved really slowly, looked at it as a feature rather than a product, and were hesitant to work with a company as small as ours.

Becoming an API company solved our distribution problem in one fell swoop: by allowing other companies to sell us to their customers we could launch to thousands of SMBs without having to go through the pain of signing them up individually and we could be sold to large businesses through their existing vendors (thus eliminating their worries about our size and whether what we were selling was a feature or a product).

Over time we did more of these deals, and evolved our vision for what the company could be based on what we saw. Instead of just being a co-browsing company, we looked at ourselves as something like a Twilio for co-browsing. We provided an API that allowed any company to build this feature into their product and sell it to their customers.

If you have a product that works well as a feature of a larger platform, becoming an API company and selling your product through OEM relationships can look like a very appealing path. As someone who’s walked it, I want to go through the pros and cons of running this type of business so you can decide whether it’s right for you.

Different types of API businesses

Before we get started, it’s important to note that not every API company is an OEM business. In fact, the percentage of API companies that pursue OEM as a strategy is probably relatively small.

This piece is going to focus on the OEM strategy specifically – that’s where much of our business at Firefly came from – but some of this applies to other types of API businesses.

Let’s start with the benefits of pursuing a strategy like this.

Instant distribution

When you do an OEM deal with another company that already has a large customer base, it’s a great way to scale up your operation (in terms of customers and revenue) quickly. For example, one of the first OEM deals we did was with a live chat company called Olark. When the deal closed we went from being used a few times a day by a couple of SMBs to being deployed to (at the time) about 5,000 SMBs – a number which grew reliably every month.

It also can give you access to companies that wouldn’t ordinarily give you the time of day. For example, shortly after launching with Olark we did another deal with a large customer service company that bundled us into their product and sold us to Best Buy – a company that would have been difficult or impossible for us to sell to on our own given our size and lack of funding.

Great acquisition target

Doing OEM work makes you a very attractive acquisition target for the right type of business.

For one thing, your partners become natural acquirers: they know your product works, they have a need for it because they’re selling it to their customers, and you’re already integrated into their platform.

But more generally, because you’ve built your product to integrate seamlessly into anyone else’s platform you’ve taken one of the big risks / pain points of most acquisitions – integration – and made it into a non-issue. This makes you a much more attractive buy than if you had a product that would have to be totally shut down and rebuilt to integrate into the existing platform.

Indeed, when senior execs at Pega were initially looking to buy Firefly they were stunned that it took only a few minutes to integrate our co-browse into their flagship CRM product Pega Customer Service. That made a big difference in the deal.

Guaranteed revenue, low cost

Finally, the upside of doing these types of deals and getting instant distribution is that you can generally translate that pretty easily into revenue. When we closed our first OEM deal we went from about $1,500 a month in revenue to over $5,000 a month. And within less than a year we had almost 10x’d that number. And we were still just 2 full time founders with a couple of contractors helping us out part time.

To get to that kind of a revenue number without doing OEM deals we would have had to expand our headcount dramatically above where we did. For example, because we were selling to businesses almost all of our contracts had stringent SLA requirements for both server uptime and customer service response time.

Doing support for thousands of businesses, and ensuring that we had a 24/7 operation would have been pretty much impossible with just two co-founders and a few part-time hires. But because we were OEMing our product, the businesses we were selling to were responsible for the first level of customer service when anything went wrong.

Because our customers acted as a filter for their customers, this allowed us to get away with not scaling up our support operation. Instead, we hooked our “24/7” support line up to our cell phones and never slept without our phones under our pillows. We had a few late-night emergencies, but not nearly as many as if we had been doing first line support.

To recap: doing OEM deals allowed us to build a significant base of monthly recurring revenue at a very low cost. This is really important if you’re bootstrapping.

The darker side of OEM

As beneficial as becoming an OEM can be, there are also significant issues involved in running an API-based OEM business that can dramatically limit your growth potential. Let’s discuss those.

Serving multiple constituencies

When you run an API-based OEM business you have to serve two constituencies: your customer, and the end-customer (your customer’s customer.)

Serving multiple constituencies hurts as a startup for a few reasons. First, because you have limited resources it can be hard to spend enough time optimizing your product for what the end customer wants and what your integration partners want. It’s not impossible to do, but it results in a less focused, sometimes lower quality product for each of the constituencies you’re serving.

Second, sometimes the needs of your constituencies are opposed. For example, the end customers may want you to implement a feature that competes with one of your OEM partners. If you built it, you’d make them happy, but you’d be putting your business at risk.

You don’t own the customer relationship

When you go the OEM route you don’t own the end-customer relationship. This is an issue for a few reasons:

First, your business is less valuable if you don’t own the customer relationship. Any potential acquirer is going to look at your list of customers as a way to value your business. If all of your end customers are actually owned by someone else, it makes your revenue stream less valuable.

Second, when you don’t own the customer relationship information flow becomes a huge problem. This isn’t so obvious before you try to run one of these businesses, but becomes a big pain once you’re in the middle of it.

What we wanted to do was build the best co-browsing experience possible for end-customers. But we didn’t have access to those end customers (aside from during support calls) even though there were thousands of them. We had to go through our partners to find out what was happening with the product, what should be improved, and where we could expand.

For example, using a product like Intercom, or Feedbackify,  most startups are able to talk directly to their end-users or gather survey data from them as they’re using your app. Because we didn’t technically own the customer relationship we couldn’t just add a little chat widget into the co-browse experience. Our partners wanted a branded, seamless, and streamlined co-browse experience, not one that included surveys or chats with us. So doing something like this to gather feedback was a no-go.

This extra friction makes it hard to move as quickly as you need to – which often spells death for a small startup and can result in a lower quality end product.

Perverse incentives for word of mouth

With a regular company, if your product works really well, the people that buy it will tell their friends and your business will naturally grow via word of mouth. OEM businesses don’t really work this way because a company that is OEMing you is naturally incentivized to keep it as quiet as possible by white labeling you and not tipping their competitors off to the fact that you’re providing this feature for them.

Think of it this way, if a company considers it a competitive advantage to have your product incorporated into theirs, what is their natural incentive to share that knowledge with their competitors? They have none, and so the task of signing up more OEM customers is that much more difficult.

Beyond not owning the customer relationship, serving multiple constituencies, and encountering perverse incentives, there’s one other major difficulty in selling an API-based OEM product. I call it walking the strange line.

Walking the strange line

This is the big issue that we ran into time and time again in our sales cycle and limited our growth more than anything else. When you’re selling an API solution to a company that wants to integrate it into their product and sell it to their customers you have to walk a line:

You have to simultaneously convince them that it’s not core enough to their business for them to build themselves, but you also have to convince them that it’s still important enough for them to pay you lots of money to provide to them.

These are two conflicting notions for a customer. If something isn’t core to their business, why bother to buy it and build it into their product? If something is core to their business, shouldn’t they own it?

You’ll run into this often when building an API-based OEM business. And unfortunately, whether or not you can manage the objection has more to do with the type of product you have than it does with the answer you give.

The key to a successful OEM business

The only way around the strange line problem is this:

You have to have a product that is important to their business, but that they don’t have the expertise to provide effectively themselves.

The best example I can think of for this is Windows – although it’s not an API it is the classic software OEM play.

We struggled with this a bit because most of these companies could build our co-browse product themselves (building client-side heavy, realtime software was a core competency) but what we were doing was difficult enough for them to shy away from doing so in many cases.

The best way to think about this is as a graph. On the X-axis is how different what you’re doing is from your partner. On the Y-axis is how much demand there is for the feature you provide. If you’re in a quadrant where what you’re doing is significantly different from their core, and there’s demand for the feature you enable, you’re in the clear:

Otherwise, think twice about whether pursuing an API-based OEM strategy is right for you.

Final thoughts

So let’s say you’re in the top right quadrant of the graph above. Should you pursue an OEM strategy?

If you’re running a venture backed software company my recommendation would be to avoid doing OEM deals – a recommendation that you’ll likely hear from your VCs. This is because you’ll likely encounter problems that will hamper your growth like perverse incentives, multiple constituencies, and the strange line problem.

However, if you’re running a bootstrapped company like we were, doing OEM deals can be a huge boon to your business. You’ll be able to scale up quickly with minimal overhead and get your revenue number to a point where you have a self-sustaining business.

We bootstrapped our business to almost a half a million dollars a year in recurring revenue in about 2 years with two co-founders and 3 part-time contractors before we sold it to Pega – a publicly traded enterprise software company – in 2014. If we hadn’t pursued an OEM strategy, we would not have been able to sniff the revenue numbers we hit in the time period we did without raising money and significantly scaling up our operation.

Thanks to Miles Grimshaw and Ryan Dawidjan for reading drafts of this.