To Pre-Meet Or Not To Pre-Meet: That Is The Question

I once asked one of my board members which CEO ran the best board meetings across his portfolio companies.  His answer was, let’s call him, Jack.  Here’s what he said about him:

  • Jack got the board deck out 3-4 days in advance of the board meeting
  • Jack would call him — and every other board member — 2-3 days before each board meeting and walk through the entire deck and answer questions, taking maybe 2 hours to do so.
  • Board meetings with Jack would go very quickly and smoothly because all the questions had been asked in advance.

When I heard this, I thought, well, I have a few issues with Jack:

  • He spends a lot of time managing his board instead of running his business.  (I guess he got his CEO job by managing-up.)
  • He completely violates my “do it in the meeting” principle by having a series of pre-meetings before the actual meeting.

While I may have my doubts about Jack, others don’t seem to.  Consider entrepreneur and VC Mark Suster’s recent post, Why You Shouldn’t Decide Anything Important at Your Board Meetings.  Suster straight out recommends a 30 minute pre-meeting per board member.  Why?

  • Agenda input so you can adhere to the Golden Rule of Board Meetings:  “no surprises.”
  • So you can “count votes” in advance as know where people stand on important and/or controversial issues.
  • So you can use board members to convince each other of desired decisions.
  • Ultimately, because in his opinion, a board meeting is where you ratify decisions that are already pre-debated.

OK, I need to chew on this because, while practical, it violates every principle of how I think companies should conduct meetings — operational ones, at least.  When it comes to operational meetings, nothing makes me grumpier than:

  • Pre-meeting lobbying
  • Post-meeting “pocket vetoes”

My whole philosophy is that meetings should be the place where we debate things and make decisions.  Doing everything in advance defeats the purpose of meeting and risks encouraging political behavior (e.g., “if you vote for my bridge in Alaska, I’ll vote for your dam in Kentucky”), with managers horse-trading instead of voting for ideas based on their merits.

The only thing worse that teeing up everything in advance is what one old boss called the “pocket veto,” where a manager sits in a meeting, watches a decision get made, says nothing, and then goes to the CEO after the meeting and says something akin to “well, I didn’t feel comfortable saying this in the meeting, but based on point-I-was-uncomfortable-raising, I disagree strongly with the decision we reached.”

I remember this happened at Business Objects once and I thought:  “wait a minute, we’ve flown 15 people from around the world (in business class) to meet at this splendid hotel for 3 days — costing maybe literally $100,000 — and the group talked for two hours about a controversial decision, came to resolution, and made a decision only to have that decision overruled the next day.”  It made me wonder why we bothered to meet at all.

But I learned an important lesson.  Ever since then, I flat refuse to overrule decisions made in a meeting based on a pocket veto.  Whenever someone comes to me and says, “well, I didn’t feel comfortable bringing it up in the meeting (for some typically very good sounding reason about embarrassing someone or such), but based upon Thing-X, I think we need to reverse that decision,” I say one thing and only one thing in response:  “well, I guess you should have brought that up in the meeting.”

You see, I believe, based on a bevy of research, that functional groups of smart people make better decisions than even the smartest individuals.  So my job as CEO is to then assure three things:

But I’ve got a problem here because while we know that boards like pre-meetings, operationally I am opposed to both pre- and post-meetings.  Would it hypocritical for to say that pre-meetings are OK for me to conduct with the board, but that managers internally should avoid them?

Maybe.  But that’s what I’m going to say.   How can I sleep at night?  Because I think we need to differentiate between meetings with a decision maker  and meetings of a decision-making body.

Most people might think that the pricing committee, product strategy committee, or new product launch committee are democratic bodies, but they aren’t.  In reality, these are meetings with a decision maker present (e.g., the CEO, the SVP of products) and thus the committee is, perhaps subtly, an advisory group as opposed to a decision-making body.  In such meetings, the decision-maker should want to encourage vociferous debate, seek to prevent pre-meetings and horse-trading, and eliminate pocket vetoes because he/she wants to hear proposals debated clearly and completely based on the merits in order to arrive at the best decision.

However, board meetings are different.  Boards truly are a decision-making bodies ruled by one-person, one-vote.  Thus, while I reject Suster’s advice when it comes to conducting operational meetings (which I believe are inherently advisory groups), I agree with it when it comes to decision-making bodies.  In such cases, someone needs to know who stands where on what.

And that person needs to be the CEO.

The Old “Don’t Bring Up a Problem Unless You Have a Proposed Solution” Rule

There’s a rule out there, undoubtedly made long ago, and circulated widely as conventional wisdom that in the workplace you should never bring up a problem unless you have a proposed solution.

For example, consider the following excerpt from this Inc Magazine article, Eight Things Great Bosses Demand from Employees:

Rule 6:  Provide Solutions, Not Complaints.  Complainers are the bane of your boss’s existence. Nothing is more irritating or more boring than listening to somebody kvetch about things that they’re not willing to change.  So never bring up a problem unless you’ve got a solution to propose–or are willing to take the advice the boss gives you.

The argument goes that if you just bring up problems, then you’ll be seen as a whiner, as a complainer, who drones on endlessly about problems that can’t be solved or that no one knows how to solve.

The question is:  is this a good rule?

Let’s take an old example from my career.  It’s 1990, you work at Ingres which is $250M division of ASK, and you compete in the relational database market against Oracle, who is about $1B.  You are getting your ass kicked up and down by Oracle in the RDBMS market.  Management is silently executing a retreat strategy into the application development tools market and worse yet, your parent company, ASK, is betting all-in on a new version of Ingres 4GL that only works on the Ingres DBMS for their next-generation ERP system.

Here are some darn good problems:

  • Oracle is killing us in the DBMS market.
  • We are moving into tools when “runtimes” are increasingly free and there is no money to be made
  • We are double-downing on a proprietary, unstable application development environment instead of using standard tools
  • ASK is suffering from a serious escalation of commitment problem and should not double down on a dying database business.

If you followed the “don’t bring up a problem without a solution” rule then you could never talk about any of these problems.  And they are only the most important problems facing the company (and that would ultimately lead to its undoing).  What if, for example, you ran sales and had no idea what application development tools the company should be using, but simply knew which it should not?  Should you make up a bad solution just so you can talk about the problem?

I can take more recent examples of similar no-easy-solution problems:

  • What do we do about the Internet?  (At Business Objects in 1996, when we were 100% Windows client applications.)
  • What do we do about NoSQL?  (At MarkLogic in 2009 when we were a closed-source non-relational DBMS into a strong open-source trend.)
  • What do we do about Zendesk? (At Salesforce in 2012 after acquiring Assit.ly and mistakenly seeking synergy vs. trying to use it in a major blunting initiative.)

Let’s look beyond the business environment and see some problems that we couldn’t talk about if we followed the rule:

  • Mid-East peace
  • Cancer
  • Global warming

“Sorry Jimmy, if you don’t know the solution to global warming then you shouldn’t bring it up because you’ll just be whining.”

Obviously, I think it’s a stupid rule.

The correct rule is:  don’t whine.

It turns out the hardest problems, the most important problems, often have no obvious solution.  So if you prohibit discussing them, you cripple our organization and limit discussion only to easier, more tactical matters, akin to re-arranging the deck chairs on the Titanic.

PayPal President’s Ream-the-Team Email: Good or Bad Leadership?

As you may have heard, PayPal president David Marcus recently zipped off a zinger of an email to company employees which was leaked to Business Insider and featured in this story:  PayPal Chief Reams Employees — Use our App or Quit.

Some highlights:

PayPal It, our program enabling you to refer businesses that don’t accept PayPal has seen the least amount of leads in *absolute* and relative terms vis-a-vis ALL other locations. Offices with under 100 employees beat us by an order of magnitude (total PayPal it leads to date: 126,862, San Jose leads: 984…).

Product usage data is similar. Employees in other offices hack into Coke machines to make them accept PayPal because they feel passionately about using PayPal everywhere. I don’t see these behaviors here in San Jose. As a matter of fact, it’s been brought to my attention that when testing paying with mobile at Cafe 17 last week, some of you refused to install the PayPal app (!!?!?!!), and others didn’t even remember their PayPal password. That’s unacceptable to me, and the rest of my team, everyone at PayPal should use our products where available. That’s the only way we can make them better, and better.

[...]

In closing, if you are one of the folks who refused to install the PayPal app or if you can’t remember your PayPal password, do yourself a favor, go find something that will connect with your heart and mind elsewhere. A life devoid of purpose, and passion in what you do everyday is a waste of the precious time you have on this earth to make it better.

While I think it’s easy to agree that companies should “eat their own dog food,” it’s harder to decide whether this email constitutes good or bad leadership.

Here are some things to ponder in answering that question.

  • In this day and age, there is a 100% chance that this email will leak.  I argue that every all-hands CEO email must now be written as if it is going to be leaked.  While perhaps a surprise 5-10 years ago, these leaks are simply a realty today.  The CEO should know that.
  • While we all want our employees to use our products, should they not do so because they are good products and they want to use them as opposed to being forced to at gunpoint?
  • By the way, using only the company’s products (and not our competitors) creates an insulation from the market such that the company may lose tough with realty.  (Think:  Detroit auto-makers giving execs new company cars every year.  They never had to deal with the vehicles poor aging/maintenance and never drove the competition for comparison.)  The PayPal cafeteria should accept Square and Google Wallet on these grounds.
  • Would a better approach have been to “seek first to understand” and learn why employees weren’t using their accounts?  (Ditto for the iPhone app.)  After all, you can force your employees to use PayPal but you can’t force the other 99.999% of the market.  Why not use  your employees — who should be naturally predisposed — as a test lab.
  • Could he not have provided an incentive (say a 10% discount) at the cafeteria if you use PayPal.  Then it would be really interesting to see why people weren’t using it.
  • Does anyone honestly believe that if everyone uses the products they will get better?  It’s a quaint idea, but if one of the junior marketing events people has some product feedback, does PayPal really run the kind of organization where it’s going to be listened to?  If he’s going to say “everyone should use the products so everyone can make them better,” then he better put wood behind the product-input arrow (e.g., an internal “ideas community” — today PayPal seems to lack even an external one).
  • Does this email actually motivate anyone or just make the CEO look frustrated and desperate?
  • To the extent San Jose employees are unexcited about the company and its products, will this email do anything to improve that?
  • Finally, should telling people to quit if they don’t use the products accomplish anything?  In complacent companies it’s the non-complacent who quit.  The complacent generally need to be fired.  So why yell at everyone about complacency — it irritates the non-complacent and has zero effect on the complacent (“oh, David’s yelling again; wonder when he’ll stop.”)

That’s my take.  Overall, this email was a terrible idea.  What’s yours?

Is Salesforce / Siebel a Classic Disruption Case?

Like many others, I have often used Salesforce / Siebel as a classic example of Innovator’s Dilemma style disruption.  Several months ago, in response to this article about Host Analytics, I received a friendly note from former Siebel exec and now venture capitalist Bruce Cleveland saying roughly:  “nice PR piece, but the Salesforce / Siebel disruption story is a misconception.”

So I was happy the other day to see that Bruce wrote up his thoughts in a Fortune article, Lessons from the Death of a Tech Giant.  In addition, he posted some supplemental thoughts in a blog post Siebel vs. Salesforce:  Lessons from the Death of  a Tech Giant.

Since the premise for the article was Bruce gathering his thoughts for a guest-lecture at INSEAD, I thought — rather than weighing in with my own commentary — I’d ask a series of study guide style questions that MBA students pondering this example should consider:

  • What is disruption?  Given Bruce’s statement of the case, do you view Siebel as a victim or disruptive innovation or a weakening macro environment?
  • Are the effects of disruptive innovation on the disruptee always felt directly or are they indirect?  (e.g., directly might mean losing specific deals as opposed to indirect where a general stall occurs)
  • What does it feel like to be an executive at a disruptee?  Do you necessarily know you are being disrupted?  How could you separate out what whether you are stalling due to the macro environment or a disruptive innovator?
  • What should you do when you are being disrupted?  (Remember the definition of “dilemma” — two options and both are bad.)
  • While not in the article, according to friends I have who worked at Siebel, management could be quoted in this timeframe as saying “Now is the time to be more Siebel than we’ve ever been” (as opposed to emulating Salesforce).  Comment.
  • What should Siebel have done differently?  Was the over-reliance on call center revenue making them highly exposed to a downturn in a few verticals?  How could they have diversified using either SFA or analytics as the backbone?
  • What should Siebel have done about the low-end disruption from Salesforce?  Recall that in 2003 Siebel launched Siebel CRM On Demand as an attempted blocking strategy in the mid-market and acquired UpShot as a blocker for SMB.  How could Siebel have leveraged these assets to achieve a better outcome?
  • To what extent should external environment variables be factored in or out when analyzing disruption?  Are they truly external or an integral part of the situation?
  • To what extent do you believe that Oracle’s acquisition of Siebel left Salesforce unopposed for 8 years?  To what extent was that true in the other categories in which Oracle made large acquisitions (e.g., HCM, middleware)?
  • After hearing both sides of the argument, to what extent do you believe the reality of the case is “Salesforce David slaying Siebel Goliath” versus “Siebel getting caught over-exposed to a macro downturn, selling to Oracle and giving the CRM market to Salesforce?”   In effect, “they didn’t kill us; we killed ourselves.”

I deliberately will offer no answers here.  As an old friend of mine says, “there are three sides to every story:  yours, mine, and what really happened.”  Real learning happens when you try understand all three.

10 Things Never To Do at a Business Dinner

Business travelers spent $260B in 2012 with food services being the #1 source of expense.  Salespeople love dinners with customers and prospects. Marketers love networking dinners.  We have customer advisory board dinners, pre-board dinners, awards dinners, relationship-building dinners, team dinners, customer appreciation dinners, partner summit dinners, project completion dinners, analyst dinners, investor dinners, … the list goes on and on.

Because business dinners can be so powerful, I am a huge fan of them as a marketing tool.  However, I’ve also been a part of many “dining accidents” over the years — the most infamous being the “white burgundy and stone crab incident” at Estiatorio Milos — almost invariably due to a combination of lack of focus on the business goals of the meal, lack of pragmatism, and lack of adaptation to changing circumstances.

As a result of these experiences, I have composed this list of 10 things never to do at a business dinner.

10.  Lack clear goals.  Whether we’re organizing a 1-1 meal for the CEO and a key customer or a 56-person customer appreciation dinner, everyone on the team should understand the goals for the meal.  Every member of the team should understand why they are there and what they are supposed to do.

9.  Eat in a noisy restaurant.  A universal purpose of a business dinner is for people to get know each other.  That is not going to happen when it’s loud, especially if your guests are a bit older.  Some restaurants are just incredibly noisy (e.g., Wolfgang’s on Park Avenue with a parabolic tile ceiling).  Sometimes private rooms can be quite loud as well, especially if they are not really cut off from the main room.  Avoid live music at all costs.  Avoid low ceilings.  Beware converted bank vaults and train stations.  I’ve seen more business dinners die on this hill than any other.  Fun or hip doesn’t matter if people can’t hear each other.

8.  Have tables bigger than 8.  If people are going to get acquainted, they need both a quiet environment and a table small enough so everyone can hear everyone else.  One friend has a rule that if you want one conversation at a table, then you should limit table size to six.   I think you can go up to 8, provided your team members know there is supposed to be one conversation.  Avoid rectangular tables which greatly limit the number of people with whom one can speak.

7.  Bring too many people.  One advantage of clear goals is that they help in deciding the guest list.  If the goal is to recognize the hard work of a 24-person team, great:  go get 3 tables of 8.  If the goal is for the CEO to build a relationship with another CEO, then either hold a 1-1 dinner or a 2-2, where each CEO brings a lieutenant.  But don’t say you’re having a CEO relationship dinner and bring your sales VP, sales director, account manager, and CFL rep.  It ends up like dating with an audience.  Don’t invite people just because they are in town — you can easily unbalance a dinner by bringing 9 of us and 3 of them, turning it into a multi-conversation, intra-company event to which a few customers are invited.  When in doubt, say no.

6.  Mis-level the crowd.  I think the most important part of networking dinners is that each participant feels like he/she gets value from meeting every other participant.  So if you’re hosting a 16-person CMO dinner, make sure the invitations are non-transferable so you can say “no” when several CMOs want to send their advertising or PR directors at the last minute.  While your PR director may enjoy having dinner with a bunch of CMOs, it’s unlikely to work in reverse.  The worst case is when two CMOs show up and are surrounded by 14 PR directors:  your intended target ends up feeling out-of-place.  It is far better to have 6 CMOs when you were hoping for 16 than it is to have 6 CMOs and 10 PR directors.  Burn that into your brain.  Tattoo it to your wrist.  Don’t not prioritize filling up seats at the cost of mis-levelling the dinner and destroying the event concept.  You can build on a great 6-person CMO event in the future.  You are dead when you host a mis-leveled event.

5.  Leave seating to chance.  Since we’re investing peoples’ valuable time (and probably $100 to $200 per head) in the event, we shouldn’t leave anything to chance.  For larger events, use place cards.  For smaller events, pre-brief the team on who to direct where.  It’s a disaster, for example, when at a square table, you place the two people you want talking next to each other, instead of across.  Make sure it doesn’t happen.  (And if it does, change it per rule 2 below.)

4.  Take more than 2 hours. Business dinners are business.  If you want to add a social part, go the bar afterwards for drinks.  It’s very awkward to leave a business dinner in progress and someone could  end up missing their train and getting in trouble with a spouse, because they expected a business dinner and you ran a lingering social event that took 3.5 hours.  In general, the more senior the invitee, the more likely the dinner is “just another calendar slot” as opposed to a social opportunity.  So when having dinner for 4-6 people at a restaurant (and I’m not in Europe), I tell the waiter in advance that my goal is to be done in two hours and that we want to have two courses and possibly dessert — no shared calamari pre-appetizer, no extra-salad (i.e., salad plus appetizer) shoved in as they love to do at Morton’s.  Just an appetizer per person, a main course, and when the time comes, a decision about dessert.  If things start to go too slowly, have some pre-appointed to leave the table, speak to the waiter discretely and say “get it moving.”  On dessert, if asked first, my answer is, “no thanks, just an espresso.”  If the customer  subsequently orders then I can always join in afterwards. Overall, by respecting your guest’s time, you increase the odds they will say yes the next time you invite them out.

3.  Order very expensive wine.  Here are a few things that can go wrong when you do:  [1] the wine is bad and you end up distracted with the whole rejection and re-tasting process, [2] the attendee is subject to a company policy where he/she has to pay his part of the meal (e.g., government, journalists) so you backfire screw them on their expense report, [3] people love it and you drink three bottles, tripling an expensive proposition, [4] you look pretentious, [5] your company looks wasteful and poorly controlled, [5] your three employees drink it but the customer subsequently announces he doesn’t drink wine and you end up treating the crew and not your customer.  When I lived in France, our classiest sales VP had a simple rule: order Sancerre.  It’s neither too cheap, nor too expensive.  It comes in dry, aromatic white (sauvignon blanc), mild-bodied red, and even rosé (both pinot noir based) so most people will like it.  I’ll demo the Sancerre principle on the wine list from the tony Village Pub, one of the best restaurants in Silicon Valley, where a Corton-Charlemagne will set you back $400 and a Kistler single-vineyard chardonnay $250.  The Sancerre weighs in about $130.

2.  Not roll with the punches.  Entertaining is always full of surprises and you need to roll with them.  We once arrived at The Triomphe in NYC only to find ourselves literally surrounded by a loud, drunken, office Holiday Party.  On arriving, we knew we were dead, so we dispatched a team member to find a quieter spot and did about 3 blocks away.  If a snowstorm wipes out 30% of your attendees, you better eliminate some tables and redo your place settings.  The key thing to remember in rolling with the punches is how to preserve the original goals of the meal.  Twice, I’ve been in cases where 4-5 employees had gathered at a very expensive restaurant (e.g., Morimoto) waiting for a group from a customer who never showed up.  In this case, rolling with the punches should mean eating somewhere else because the company shouldn’t be dropping Morimoto-style dollars on a basic mid-week traveling dinner.

1.  Order the tasting menu.  There are four problems with tasting menus:  they are expensive, they take the whole table hostage because they are ordered on an all-or-nothing basis, they take a long time to serve, and they don’t fill you up. The thing I hate most about tasting menu is not the first check — the $900 check for 4 — it’s the second check, the one for $100 for sliders and wings at the sports bar afterwards.  I am so opposed to tasting menus on business dinners that I actually try to avoid restaurants that offer them; I try to reduce the odds to zero that one person, typically a new employee, will provoke the chain reaction that results in the whole table ordering one.  I’ll do a tasting menu at a business dinner only if we are a small group of known foodies who will order the wine pairings, take three and a half hours on the meal, greatly enjoy it, and not run to McDonald’s right after.  Otherwise, stay away.

I could add as “rule 0″ don’t get drunk, but frankly I’ve not seen that rule broken terribly often at the business dinners I’ve attended.  More often, I see it broken at company events — which is a whole different blog post.

I hope you find these rules, and the thinking behind them, helpful to you in optimizing all your business dinners.

Bon Appétit!

Insight Ventures Periodic Tables of SaaS Sales and Marketing Metrics


I just ran into these two tables of SaaS metrics published by Insight Venture Partners (or, more precisely, the Insight Onsite team) and they are too good not to share.

Along with Bessemer’s awkwardly titled 30 Questions and Answers That Every SaaS Revenue Leader Needs to Know, financial metrics from Opex Engine, and the wonderful Pacific Crest Annual SaaS Survey, SaaS leaders now have a great set of reference documents to benchmark their firms.

(And that’s not to mention David Skok’s great post on SaaS metrics or, for that matter, my own posts on the customer acquisition cost (CAC) ratio and renewals rates / churn.)

Here is Insight’s SaaS sales periodic table:

ivp saas sales

And here is Insight’s B2B digital marketing periodic table:

ivp saals mkting

Did You Just Make a Plan or a Budget?

Congratulations!  If your company is like most, you’ve recently finished a (hopefully) solid 2013 and, from an EPM perspective, completed your 2014 annual planning process. 

Before we get too excited, however, let’s ask one quick question:  did you just make a plan or a budget?  In business, we tend to use the terms “plan” and “budget” as synonyms. But are they?  Methinks strongly no.

A budget is a set of numbers that say how much each operating manager (above some level of seniority) is supposed to spend and/or sell in the coming fiscal year.  A budget is made by finance and owned by finance.  Budgets are often built by trending (i.e., if we want revenue to go up 30%, then to improve profitability, we want expenses to up by only 20%, so give every cost center 20% more than last year, spreading it across time periods in line with historical actuals).  Operating managers often perceive budgets as “falling from the sky” — i.e., targets are dropped on them without conversation which makes sense in some perverse way (if the whole thing is a giant trending exercise, then there really isn’t much to discuss anyway).  Because budgets are trended, they are often nothing more than “buckets of money” — i.e., marketing is going to spend 20% more than last year on analyst relations, but no one can tell you  – and the model certainly does not include — any line-items/details on how it is to be spent.  Finally, the seniority-line (mentioned above) is usually quite high in the organization with budgets; only the top functional managers may actually have budgets that they control.

Budgets aren’t evil.  We need them.  We need targets against which to hold people accountable.  We need to be able to forecast cashflows.  We need, if we’re public, to set revenue and EPS guidance for Wall Street.

But a budget is not a plan.

A plan is strategic.  It starts not with an expense trending exercise, but instead with the company’s position in the market and a strategy for improving it.  A high-level strategy is defined.  Concrete goals/objectives are identified that support the strategy (e.g., start a European operation and sign 3 distributors).  Revenue targets are negotiated, ideally rewarding managers not just for beating the targets (which encourages sand-bagging) but also against more objective and external measures (e.g., market share).  Expense targets are set not simply by trending, but also by challenging past expenses and adding the costs of new strategic projects (i.e., stop/continue/start analysis).  Budget ownership is pushed down the organization, ideally with every people-manager controlling his/her own budget.

Plans have linked-detail, not just buckets of money.  When planning, you say “what do we need to accomplish in analyst relations and what will that cost.”  When budgeting, you say “how would we spend an extra 20% in analyst relations.”

The biggest way to tell if you’ve made a plan or a budget is when it comes to cutting time.  Budgets are cut with broad, top-down, across-the-board cuts:  “look, everyone’s going to need to take 10% more expense out.”  Plans are cut by removing strategic objectives:  “it looks like we were premature in wanting to open Europe, so I want to see a version of the plan where everyone removes those costs.”

I’d argue that a good plan is more well thought out in every way.  Budgets just trend revenue.  Plans triangulate using multiple different models with sensitivity analysis.  Budgets have TBH1, TBH2, and TBH3 as new hires.  Plans have AE/NYC, AE/Boston, and AE/Denver.

In philosophy, budgets are done by pragmatists with a goal to get them done:  “it’s imperfect, but you can’t predict the future, and we need something finalized by 12/31.”  By contrast, plans are done by strategists in a true attempt to anticipate what can be anticipated about the future.

  • If you’re going to hire 3 sales teams, they are going to want leads.
  • If Q2 is usually a rough seasonal quarter, then it’s likely to be one again.
  • If you’re going to acquire 100 customers, you are going to need to grow your support team.
  • If you are going to launch a focus on pharma sales, then you will need to develop a pharma sales kit.
  • If you know a competitor’s strategy and the backgrounds of their executive team, you can anticipate many of their moves (e.g., when Oracle put bankers in charge of the company was it a big surprise that they moved heavily towards an M&A strategy).
  • If you know industry trends, you can anticipate competitor strategy (e.g., do you think Oracle and SAP will be investing big in cloud in 2014, how about Microsoft and mobile)

As John Naisbitt once said, “the most reliable way to predict the future is to try to understand the present.”

So, if you just made a budget, congratulations.  You are far better off than many companies who can’t even get that process completed.  But beware you’ve got an opportunity ahead of you to make a plan.  If you’ve made a plan, congratulations again.  While your plan may changes many times as you go forward, the process of planning itself has made your organization more ready than most to respond to those changes.  I’ll finish with my favorite quote on planning, by Dwight Eisenhower:

“In the process of preparing for battle I have always found that plans are useless, but planning is indispensable.”

And I don’t think Eisenhower would have considered trended buckets-of-money a plan.

Kellblog’s 10 Predictions for 2014

Since it is the season of predictions, I thought I’d offer up a few of my own for 2014, based on my nearly three decades of experience working in enterprise software with databases, BI tools, and enterprise applications.

See the bottom for my disclaimer, and off we go.  Here are my ten predictions for 2014.

  • Despite various ominous comparisons to 1914 made by The Economist, I think 2014 is going to be a good year for Silicon Valley.  I think the tech IPO market will continue to be strong.  While some Bubble 2.0 anxiety is understandable, remember that while some valuations today may seem high, that the IPO bar is much higher today (at around $50M TTM revenues) than it was 13 years ago, when you could go public on $0 to $5M in revenues.  In addition, remember that most enterprise software companies (and many Internet companies) today rely on subscription revenue models (i.e., SaaS) which are much more reliable than the perpetual license streams of the past.  Not all exuberance is irrational.
  • Cloud computing will continue to explode.  IDC predicts that aggregate cloud spending will exceed $100B in 2014 with amazing growth, given the scale, of 25%.  Those are big numbers, but think about this:  some 15 years after Salesforce.com was founded, its head pin category, sales force automation (SFA), is still only around 40% penetrated by the cloud.  ERP is less than 10% in the cloud.  EPM is less than 5% in the cloud.  As Bill Gates once said about prognostication, “we always overestimate the change that will occur in the next two years and underestimate the change that will occur in the next ten.”  IT is going to the cloud, inexorably, but change in IT never happens overnight.
  • Big Data hype will peak.   I remember the first time I heard the term “big data” (in about 2008 when I was on the board of Aster Data) and thinking:  “wow, that’s good.”  Turns out my marketing instincts were spot on.  Every company today that actually is — or isn’t — a Big Data play is dressing up as one, which creates a big problem because the term quickly starts to lose meaning.  As a result, Big Data today is nearing the peak of Gartner’s hype cycle.  As a term it will start to fall off, but real Big Data technologies such as NoSQL databases and predictive analytics will continue to face a bright future.
  • The market will be unable to supply sufficient Data Science talent.  If someone remade The Graduate today, they’d change  Mr. McGuire’s line about “plastics” to “data science.”  Our ability to amass data and create analytics technology is quickly surpassing our ability to use it.  Job postings for data scientists were up 15,000% in 2012 over 2011.  Colleges are starting to offer data science degrees (for example, Berkeley and Northwestern).  There’s even an a startup, Udacity, specifically targeting the need for data science education.  Because of the scarcity of data science talent, the specialization required to correctly use it, and the lack of required scale to build data science teams, data science consultancies like Palantir and Mu Sigma will continue to flourish.
  • Privacy will remain center stage.  Trust in “Don’t Be Evil” Google and Facebook has never been particularly high.  Nevertheless, it seems like the average person has historically felt “you can do whatever you want with my personal data if you want to pitch me an advertisement” — but, thanks to Edward Snowden – we now know we can add, “and if the government wants to use that data to stop a terrorist attack, then back off.”  It’s an odd asymmetry.  These are complex questions, but in a world where the cost of data collection will converge to free, will the privacy violation be in collecting the data or in analyzing it?  In a world where one trusted the government to adequately control the querying and access (i.e., where it took a warrant from a non-secret court), I’d argue the query standard might be good enough.  Regardless, the debate sparked thus far will continue to burn in 2014 and tech companies will very much remain in the center of it.
  • Mobile will continue to drive consumer companies like Dropbox and Evernote, but also enterprise companies like Box, Clari, Expensify, and MobileIron.  Turns out the enterprise killer app for mobile was less about getting enterprise applications to run on mobile devices and more about device proliferation, uniform access to content, and eventually security and management.  (And since I’m primarily an enterprise blogger, I won’t even mention social à la SnapChat or mobile gaming).  As one VC recently told me over dinner, “God bless mobile.”  Amen in 2014.
  • Social becomes a feature, not an app.  When I first saw Foursquare in 2010, I thought it should be the example in the venture capital dictionary for “feature, not company.”  Location-awareness has definitely become a feature and these days I do more check-in’s on Facebook than Foursquare.  I felt the same way when I worked at Salesforce.com and we were neck deep in the “social enteprise” vision.  When I saw Chatter, I thought “cool, but who needs yet another communications platform.”  Then I realized you could follow a lead, a case, or an opportunity and I was hooked.  But those are all feature use-cases, not application or company use-cases.  Given the pace of Salesforce, they fell in love with, married, and divorced social faster than most vendors could figure out their product strategy.  In the end, social should be an important feature of an enterprise application, almost a fabric built across modules.  I think that vision ends up getting implemented in 2014.  (Particularly if Microsoft ends up putting in David Sacks as its next CEO as some speculate.)
  • SAP’s HANA strategy actually works.  I was one of relatively few people who was absolutely convinced that SAP’s $5.8B purchase of Sybase in 2010 was more about databases than mobile.  SAP is clearly crafting a strategy to move both analytics and transactional database processing onto HANA and they have been doggedly consistent about HANA and its importance to the firm going forward.  They have been trying for decades to eliminate their dependency on Oracle — e.g., the 1997 Adabas D acquisition from Software AG  – and I believe this time they will finally succeed.  In addition, they will succeed — quite ironically — with their ingredient-branding strategy around HANA using a database to differentiate an application suite, something that they themselves would have seen as heresy 20 years ago.
  • Good Data goes public.  Cloud-based BI tools have had a tough slog over the years.  Some good companies were too early to market and failed (e.g., LucidEra).  Birst, another early entrant, certainly hasn’t had an easy time over its ten-year history.  Personally, while I was always a fan of cloud-based applications (having become a big Salesforce customer in 2003), I always worried that with cloud-based BI tools, you’d have too much of the nothing-to-analyze problem.  Good Data got around that problem early on by adopting a Crystal-like OEM strategy, licensing their tools through SaaS applications vendors.  They later evolved to a general cloud-based BI platform and applications strategy.  The company was founded in 2007, has raised $75M in VC, is reportedly doing very well, and an IPO seems a likely event in its future.  I’m calling 2014.
  • Adaptive Planning gets acquired by NetSuite.  Adaptive Planning was founded in 2003 as a cloud-based planning company and — despite both aspirations and claims to the contrary — in my estimation continues to play the role of the low-priced, cheap-and-cheerful planning solution for small and medium businesses.  That market position, combined with an existing, long-term strategic relationship whereby NetSuite resells Adaptive as NetSuite Financial Planning, makes me believe that 2014 will be the year that NetSuite finally pulls the trigger and acquires Adaptive Planning.  I think this deal could go down one of two ways.  If Adaptive continues to perform as they claim, then a potential S-1 filing could serve as a trigger for NetSuite (much as Crystal Decisions’ S-1 served as a trigger for Business Objects).  Or, if Adaptive hits rough road in 2014 for any reason (including the curse of the new headquarters) then that could trigger NetSuite with a value-shopper impulse leading to the same conclusion.

I should end with a bonus prediction (#11) that Host Analytics, our customers, and my colleagues will enjoy a successful 2014, continuing to execute on our cloud strategy to put the E back in EPM — focus and leadership in the enterprise segment of the market — and that we will continue to acquire both high-growth companies who want an EPM solution with which they can scale and liberate enterprises from costly and painful Hyperion implementations and upgrades.

Finally, let me conclude by wishing everyone a Happy New Year and great business success in 2014.

Disclaimers

  • See my FAQ to understand my various allegiances and disclaimers.
  • Remember I am the CEO of Host Analytics so I have a de facto pro-Host Analytics viewpoint.  
  • Predictions are opinion:  I have mine; yours may differ.
  • Finally, remember the famous Yogi Berra quote:  predictions are hard, especially about the future.

The Pillorying of MarkLogic: Why Selling Disruptive Technology To the Government is Hard and Risky

There’s a well established school of thought that high-tech startups should focus on a few vertical markets early in their development.  The question is whether government should be one of them?

The government seems to think so.  They run a handful of programs to encourage startups to focus on government.  Heck, the CIA even has a venture arm right on Sand Hill Road, In-Q-Tel, whose mission is to find startups who are not focused on the Intelligence Community (IC) and to help them find initial customers (and provide them with a dash of venture capital) to encourage them to do so.

When I ran MarkLogic between mid-2004 and 2010, we made the strategic decision to focus on government as one of our two key verticals.  While it was then, and still is, rather contrarian to do so, we nevertheless decided to focus on government for several reasons.

  • The technology fit was very strong.  There are many places in government, including the IC, where they have a bona fide need for a hybrid database / search engine, such as MarkLogic.
  • Many people in government were tired of the Oracle-led oligopoly in the RDBMS market and were seeking alternatives.  (Think:  I’m tired of writing Oracle $40M checks.)  While this was true in other markets, it was particularly true in government because their problems were compounded by lack of good technical fit — i.e., they were paying an oligopolist a premium price for technology that was not, in the end, terribly well suited to what they were doing.
  • Unlike other markets (e.g., Finance, Web 2.0) where companies could afford the high-caliber talent able to use the then-new open source NoSQL alternatives, government — with the exception of the IC — was not swimming in such talent.  Ergo, government really needed a well-supported enterprise NoSQL system usable by a more typical engineer.

The choice had always made me nervous for a number of reasons:

  • Government deals were big, so it could lead to feast-or-famine revenue performance unless you were able to figure out how to smooth out the inherent volatility.
  • Government deals ran through systems integrators (SI) which could greatly complexify the sales cycle.
  • Government was its own tribe, with its own language, and its own idiosyncrasies (e.g., security clearances).  While bad from the perspective of commercial expansion, these things also served as entry barriers that, once conquered, should provide a competitive advantage.

The only thing I hadn’t really anticipated was the politics.

It had never occurred to me, for example, that in a $630M project — where MarkLogic might get maybe $5 to $10M — that someone would try to blame failure of what appears to be one of the worst-managed projects in recent history on a component that’s getting say 1% of the fees.

It makes no sense.  But now, for the second time, the New York Times has written an article about the HealthCare.gov fiasco where MarkLogic is not only one of very few vendors even mentioned but somehow implicated in the failures because it is different.

HealthCare.gov

Let me start with a few of my own observations on HealthCare.gov from the sidelines.  (Note that I, to my knowledge, was never involved with the project during my time at MarkLogic.)

From the cheap seats the problems seem simple:

  • Unattainable timelines.  You don’t build a site “just like Amazon.com” using government contractors in a matter of quarters.  Amazon has been built over the course of a more than a decade.
  • No Beta program.  It’s incomprehensible to me that such a site would go directly from testing into production without quarters of Beta.  (Remember, not so long ago, that Google ran Beta’s for years?)
  • No general oversight.  It seems that there was no one playing the general contractor role.  Imagine if you built a house with plumbers, carpenters, and electricians not coordinated by a strong central resource.
  • Insufficient testing.  The absent Beta program aside, it seems the testing phase lasted only weeks, that certain basic functionality was not tested, and that it’s not even clear if there was a code-freeze before testing.
  • Late changes.  Supporting the idea that there was no code freeze are claims that the functional spec was changing weeks before the launch.

Sadly, these are not rare problems on a project of this scale.  This kind of stuff happens all the time, and each of these problems is a hallmark of a “train wreck” software development project.

To me, guessing from a distance, it seems pretty obvious what happened.

  • Someone who didn’t understand how hard it to build was ordered up a website of very high complexity with totally unrealistic timeframes.
  • A bunch of integrators (and vendors) who wanted their share of the $630M put in bids, probably convincing themselves in each part of the system that if things went very well that they could maybe make the deadlines or, if not, maybe cut some scope.  (Remember you don’t win a $50M bid by saying “the project is crazy and the timeframe unrealistic.”)
  • Everybody probably did their best but knew deep down that the project was failing.
  • Everyone was afraid to admit that the project was failing because nobody likes to deliver bad news, and it seems that there was no one central coordinator whose job it was to do so.

Poof.  It happens all the time.  It’s why the world has generally moved away from big-bang projects and towards agile methodologies.

While sad, this kind of story happens.  The question is how does the New York Times end up writing two articles where somehow the failure is somehow blamed on MarkLogic.  Why is MarkLogic even mentioned?  This the story of a project run amok, not the story of a technology component failure.

Politics and Technology

The trick with selling disruptive technology to the government is that you encounter two types of people.

  • Those who look objectively at requirements and try to figure out which technology can best do the job.  Happily, our government contains many of these types of people.
  • Those who look at their own skill sets and view any disruptive technology as a threat.

I met many Oracle-DBA-lifers during my time working with the government.  And I’m OK with their personal decision to stop learning, not refresh their skills, not stay current on technology, and to want to ride a deep expertise in the Oracle DMBS into a comfortable retirement.  I get it.  It’s not a choice I’d make, but I can understand.

What I cannot understand, however, is when someone takes a personal decision and tries to use it as a reason to not use a new technology.  Think:  I don’t know MarkLogic, it is new, ergo it is a threat to my personal career plan, and ergo I am opposed to using MarkLogic, prima facie, because it’s not aligned with my personal interests.  That’s not OK.

To give you an idea of how warped this perspective can get (and while this may be urban myth), I recall hearing a story that one time a Federal contractor called a whistle-blower line to report the use of MarkLogic on system instead of Oracle.  All I could think of was Charlton Heston at the end of Soylent Green saying, “I’ve seen it happening … it’s XML … they’re making it out of XML.

The trouble is that these folks exist and they won’t let go.  The result:  when a $630M poorly managed project gets in trouble, they instantly raise and re-raise decisions made about technology with the argument that “it’s non-standard.”

Oracle was non-standard in 1983.  Thirty years later it’s too standard (i.e., part of an oligopoly) and not adapted to the new technical challenges at hand.  All because some bright group of people wanted to try something new, to meet a new challenge, that cost probably a fraction of what Oracle would have charged, the naysayers and Oracle lifers will challenge it endlessly saying it’s “different.”

Yes, it is different.  And that, far as I can tell, was the point.  And if you think that looking at 1% of the costs is the right way to diagnose a struggling $630M project, I’d beg to differ.  Follow the money.

###

FYI, in researching this post, I found this just-released HealthCare.gov progress report.

The Customer Acquisition Cost (CAC) Ratio: Another Subtle SaaS Metric

The software-as-a-service (SaaS) space is full of seemingly simple metrics that can quickly slip through your fingers when you try to grasp them.  For example, see Measuring SaaS Renewals Rates:  Way More Than Meets the Eye for a two-thousand-word post examining the many possible answers to the seemingly simple question, “what’s your renewal rate?”

In this post, I’ll do a similar examination to the slightly simpler question, “what’s your customer acquisition cost (CAC) ratio?”

I write these posts, by the way, not because I revel in the detail of calculating SaaS / cloud metrics, but rather because I cannot stand when groups of otherwise very intelligent people have long discussions based on ill-defined metrics.  The first rule of metrics is to understand what they are and what they mean before entertaining long discussions and/or making important decisions about them.  Otherwise you’re just counting angels on pinheads.

The intent of the CAC ratio is to determine the cost associated with acquiring a customer in a subscription business.  When trying to calculate it, however, there are six key issues to consider:

  • Months vs. years
  • Customers vs. dollars
  • Revenue on top vs. bottom
  • Revenue vs. gross margin
  • The cost of customer success
  • Time periods of S&M

Months vs. Years

The first question — which relates not only to CAC but also to many other SaaS metrics:  is your business inherently monthly or annual?

Since the SaaS movement started out with monthly pricing and monthly payments, many SaaS businesses conceptualized themselves as monthly and thus many of the early SaaS metrics were defined in monthly terms (e.g., monthly recurring revenue, or MRR).

While for some businesses this undoubtedly remains true, for many others – particularly in the enterprise space – the real rhythm of the business is annual.  Salesforce.com, the enterprise SaaS pioneer, figured this out early on as customers actually encouraged the company to move to an annual rhythm, for among other reasons, to avoid the hassle associated with monthly billing.

Hence, many SaaS companies today view themselves as in the business of selling annual subscriptions and talk not about MRR, but ARR (annual recurring revenue).

Customers vs. Dollars

If you ask some cloud companies their CAC ratio, they will respond with a dollar figure – e.g., “it costs us $12,500 to acquire a customer.”  Technically speaking, I’d call this customer acquisition cost, and not a cost ratio.

There is nothing wrong with using customer acquisition cost as a metric and, in fact, the more your business is generally consistent and the more your customers resemble each other, the more logical it is to say things like, “our average customer costs $2,400 to acquire and pays us $400/month, so we recoup our customer acquisition cost in six months.”

However, I believe that in most SaaS businesses:

  • The company is trying to run a “velocity” and an “enterprise” model in parallel.
  • The company may also be trying to run a freemium model (e.g., with a free and/or a low-price individual subscription) as well.

Ergo, your typical SaaS company might be running three business models in parallel, so wherever possible, I’d argue that you want to segment your CAC (and other metric) analysis.

In so doing, I offer a few generic cautions:

  • Remember to avoid the easy mistake of taking “averages of averages,” which is incorrect because it does not reflect weighting the size of the various businesses.
  • Remember that in a bi-modal business that the average of the two real businesses represents a fictional mathematical middle.

avg of avg

For example, the “weighted avg” column above is mathematically correct, but it contains relatively little information.  In the same sense that you’ll never find a family with 1.8 children, you won’t find a customer with $12.7K in revenue/month.  The reality is not that the company’s average months to recoup CAC is a seemingly healthy 10.8 – the reality is the company has one very nice business (SMB) where it takes only 6 months to recoup CAC and one very expensive one where it takes 30.  How you address the 30-month CAC recovery is quite different from how you might try to squeeze a month or two out the 10.8.

Because customers come in so many different sizes, I dislike presenting CAC as an average cost to acquire a customer and prefer to define CAC as an average cost to acquire a dollar of annual recurring revenue.

Revenue on Top vs. Bottom

When I first encountered the CAC ratio is was in a Bessemer white paper, and it looked like this.

cac picture

In English, Bessemer defined the 3Q08 CAC as the annualized amount of incremental gross margin in 3Q08 divided by total S&M expense in 2Q08 (the prior quarter).

Let’s put aside (for a while) the choice to use gross margin as opposed to revenue (e.g., ARR) in the numerator.  Instead let’s focus on whether revenue makes more sense in the numerator or the denominator.  Should we think of the CAC ratio as:

  • The amount of S&M we spend to generate $1 of revenue
  • The amount of revenue we get per $1 of S&M cost

To me, Bessemer defined the ratio upside down.  The customer acquisition cost ratio should be the amount of S&M spent to acquire a dollar of (annual recurring) revenue.

Scale Venture Partners evidently agreed  and published a metric they called the Magic Number:

Take the change in subscription revenue between two quarters, annualize it (multiply by four), and divide the result by the sales and marketing spend for the earlier of the two quarters.

This changes the Bessemer CAC to use subscription revenue, not gross margin, as well as inverts it.  I think this is very close to CAC should be calculated.  See below for more.

Bessemer later (kind of) conceded the inversion — while they side-stepped redefining the CAC, per se, they now emphasize a new metric called “CAC payback period” which puts S&M in the numerator.

Revenue vs. Gross Margin

While Bessemer has written some great papers on Cloud Computing (including their Top Ten Laws of Cloud Computing and Thirty Q&A that Every SaaS Revenue Leader Needs to Know) I think they have a tendency to over-think things and try to extract too much from a single metric in defining their CAC.  For example, I think their choice to use gross margin, as opposed to ARR, is a mistake.

One metric should be focused on measuring one specific item. To measure the overall business, you should create a great set of metrics that work together to show the overall state of affairs.

leaky

I think of a SaaS company as a leaky bucket.  The existing water level is a company’s starting ARR.  During a time period the company adds water to the bucket in form of sales (new ARR), and water leaks out of the bucket in the form of churn.

  • If you want to know how efficient a company is at adding water to the bucket, look at the CAC ratio.
  • If you want to know what happens to water once in the bucket, look at the renewal rates.
  • If you want to know how efficiently a company runs its SaaS service, look at the subscription gross margins.

There is no need to blend the efficiency of operating the SaaS service with the efficiency of customer acquisition into a single metric.  First, they are driven by different levers.  Second, to do so invariably means that being good at one of them can mask being bad at the other.  You are far better off, in my opinion, looking at these three important efficiencies independently.

The Cost of Customer Success

Most SaaS companies have “customer success” departments that are distinct from their customer support departments (which are accounted for in COGS).  The mission of the customer success team is to maximize the renewals rate – i.e., to prevent water from leaking out of the bucket – and towards this end they typically offer a form of proactive support and adoption monitoring to ferret out problems early, fix them, and keep customers happy so they will renew their subscriptions.

In addition, the customer success team often handles basic upsell and cross-sell, selling customers additional seats or complementary products.  Typically, when a sale to an existing customer crosses some size or difficultly threshold, it will be kicked back to sales.  For this reason, I think of customer success as handling incidental upsell and cross-sell.

The question with respect to the CAC is what to do with the customer success team.  They are “sales” to the extent that they are renewing, upselling, and cross-selling customers.  However, they are primarily about ARR preservation as opposed to new ARR.

My preferred solution is to exclude both the results from and the cost of the customer success team in calculating the CAC.  That is, my definition of the CAC is:

dk cac pic

I explicitly exclude the cost customer success in the numerator and exclude the effects of churn in the denominator by looking only at the new ARR added during the quarter.  This formula works on the assumption that the customer success team is selling a relatively immaterial amount of new ARR (and that their primary mission instead is ARR preservation).  If that is not true, then you will need to exclude both the new ARR from customer success as well as its cost.

I like this formula because it keeps you focused on what the ratio is called:  customer acquisition cost.  We use revenue instead of gross margin and we exclude the cost of customer success because we are trying to build a ratio to examine one thing:  how efficiently do I add new ARR to the bucket?  My CAC deliberately says nothing about:

  • What happens to the water once S&M pours it in the bucket.  A company might be tremendous at acquiring customers, but terrible at keeping them (e.g., offer a poor quality service).  If you look at net change in ARR across two periods then you are including both the effects of new sales and churn.  That is why I look only at new ARR.
  • The profitability of operating the service.  A company might be great at acquiring companies but unable to operate its service at a profit.  You can see that easily in subscription gross margins and don’t need to embed that in the CAC.

There is a problem, of course.  For public companies you will not be able to calculate my CAC because in all likelihood customer success has been included in S&M expense but not broken out and because you can typically only determine the net change in subscription revenues and not the amounts of new ARR and churn.  Hence, for public companies, the Magic Number is probably your best metric, but I’d just call it 1/CAC.

My definition is pretty close to that used by Pacific Crest in their annual survey, which uses yet another slightly different definition of the CAC:  how much do you spend in S&M for a dollar of annual contract value (ACV) from a new customer?

(Note that many vendors include first-year professional services in their definition of ACV which is why I prefer ARR.  Pacific Crest, however, defines ACV so it is equivalent to ARR.)

I think Pacific Crest’s definition has very much the same spirit as my own.  I am, by comparison, deliberately simpler (and sloppier) in assuming that customer success not providing a lot of new ARR (which is not to say that a company is not making significant sales to its customer base – but is to say that those opportunities are handed back to the sales function.)

Let’s see the distribution of CAC ratios reported in Pacific Crest’s recent, wonderful survey:

pac crest cac

Wow.  It seems like a whole lot of math and analysis to come back and say:  “the answer is 1.

But that’s what it is.  A healthy CAC ratio is around 1, which means that a company’s S&M investment in acquiring a new customer is repaid in about a year.  Given COGS associated with running the service and a company’s operating expenses, this implies that the company is not making money until at least year 3.  This is why higher CACs are undesirable and why SaaS businesses care so much about renewals.

Technically speaking, there is no absolute “right” answer to the CAC question in my mind.  Ultimately the amount you spend on anything should be related to what it’s worth, which means we need relate customer acquisition cost to customer lifetime value (LTV).

For example, a company whose typical customer lifetime is 3 years needs to have a CAC well less than 1, whereas a company with a 10 year typical customer lifetime can probably afford a CAC of more than 2.  (The NPV of a 10-year subscription increasing price at 3% with a 90% renewal rate and discount at 8% is nearly $7.)

Time Periods of S&M Expense

Let me end by taking a practical position on what could be a huge rat-hole if examined from first principles.  The one part of the CAC we’ve not yet challenged is the use of the prior quarter’s sales and marketing expense.  That basically assumes a 90-day sales cycle – i.e., that total S&M expense from the prior quarter is what creates ARR in the current quarter.  In most enterprise SaaS companies this isn’t true.  Customers may engage with a vendor over a period of a year before signing up.  Rather than creating some overlapped ramp to try and better model how S&M expense turns into ARR, I generally recommend simply using the prior quarter for two reasons:

  • Some blind faith in offsetting errors theory.  (e.g., if 10% of this quarter’s S&M won’t benefit us for a year than 10% of a year ago’s spend did the same thing, so unless we are growing very quickly this will sort of cancel out).
  • Comparability.  Regardless of its fundamental correctness, you will have nothing to compare to if you create your own “more accurate” ramp.

I hope you’ve enjoyed this journey of CAC discovery.  Please let me know if you have questions or comments.