Why has Standalone Cloud BI been such a Tough Slog?

I remember when I left Business Objects back in 2004 that it was early days in the cloud.  We were using Salesforce internally (and one of their larger customers at the time) so I was familiar with and a proponent of cloud-based applications, but never felt great about BI in the cloud.  Despite that, Business Objects and others were aggressively ramping on-demand offerings all of which amounted to pretty much nothing a few years later.

Startups were launched, too.  Specifically, I remember:

  • Birst, née Success Metrics, and founded in 2004 by Siebel BI veterans Brad Peters and Paul Staelin, which was originally supposed to be vertical industry analytic applications.
  • LucidEra, founded in 2005 by Salesforce and Siebel veteran Ken Rudin (et alia) whose original mission was to be to BI what Salesforce was to CRM.
  • PivotLink, which did their series A in 2007 (but was founded in 1998), positioned as on-demand BI and later moved into more vertically focused apps in retail.
  • GoodData, founded in 2007 by serial entrepreneur Roman Stanek, which early on focused on SaaS embedded BI and later moved to more of a high-end enterprise positioning.

These were great people — Brad, Ken, Roman, and others were brilliant, well educated veterans who knew the software business and their market space.

These were great investors — names like Andreessen Horowitz, Benchmark, Emergence, Matrix, Sequoia, StarVest, and Tenaya invested over $300M in those four companies alone.

This was theoretically a great, straightforward cloud-transformation play of a $10B+ market, a la Siebel to Salesforce.

But of the four companies named above only GoodData is doing well and still in the fight (with a high-end enterprise platform strategy that bears little resemblance to a straight cloud transformation play) and the three others all came to uneventful exits:

So, what the hell happened?

Meantime, recall that Tableau, founded in 2003, and armed in its early years with a measly $15M in venture capital, and with an exclusively on-premises business model, literally blew by all the cloud BI vendors, going public in May 2013 and despite the stock being cut by more than half since its July 2015 peak is still worth $4.2B today.

I can’t claim to have the definitive answer to the question I’ve posed in the title.  In the early days I thought it was related to technical issues like trust/security, trust/scale, and the complexities of cloud-based data integration.  But those aren’t issues today.  For a while back in the day I thought maybe the cloud was great for applications, but perhaps not for platforms or infrastructure.  While SaaS was the first cloud category to take off, we’ve obviously seen enormous success with both platforms (PaaS) and infrastructure (IaaS) in the cloud, so that can’t be it.

While some analysts lump EPM under BI, cloud-based EPM has not had similar troubles.  At Host, and our top competitors, we have never struggled with focus or positioning and we are all basically running slightly different variations on the standard cloud transformation play.  I’ve always believed that lumping EPM under BI is a mistake because while they use similar technologies, they are sold to different buyers (IT vs. finance) and the value proposition is totally different (tool vs. application).  While there’s plenty of technology in EPM, it is an applications play — you can’t sell it or implement it without domain knowledge in finance, sales, marketing or whatever domain for which you’re building the planning system.  So I’m not troubled to explain why cloud EPM hasn’t been a slog while cloud BI absolutely has been.

My latest belief is that the business model wasn’t the problem in BI.  The technology was.  Cloud transformation plays are all about business model transformation.  On-premises applications business models were badly broken:  the software cost $10s of millions to buy and $10s of millions more to implement (for large customers).  SMBs were often locked out of the market because they couldn’t afford the ante.  ERP and CRM were exposed because of this and the market wanted and needed a business model transformation.

With BI, I believe, the business model just wasn’t the problem.  By comparison to ERP and CRM, it was fraction of the cost to buy and implement.  A modest BusinessObjects license might have cost $150K and less than that to implement.  That problem was not that BI business model was broken, it was that the technology never delivered on the democratization promise that it made.  Despite shouting “BI for the masses” in 1995, BI never really made it beyond the analyst’s desk.

Just as RDBMS themselves failed to deliver information democracy with SQL (which, believe it or not, was part of the original pitch — end users could write SQL to answer their own queries!), BI tools — while they helped enable analysts — largely failed to help Joe User.  They weren’t easy enough to use.  They lacked information discovery.  They lacked, importantly, easy-yet-powerful visualization.

That’s why Tableau, and to a lesser extent Qlik, prospered while the cloud BI vendors struggled.  (It’s also why I find it profoundly ironic that Tableau is now in a massive rush to “go cloud” today.)  It’s also one reason why the world now needs companies like Alation — the information democracy brought by Tableau has turned into information anarchy and companies like Alation help rein that back in (see disclaimers).

So, I think that cloud BI proved to be such a slog because the cloud BI vendors solved the wrong problem. They fixed a business model that wasn’t fundamentally broken, all while missing the ease of use, data discovery, and visualization power that both required the horsepower of on-premises software and solved the real problems the users faced.

I suspect it’s simply another great, if simple, lesson is solving your customer’s problem.

Feel free to weigh in on this one as I know we have a lot of BI experts in the readership.

Do You Want to be Judged on Intentions or Results?

It was early in my career, maybe 8 years in, and I was director of product marketing at a startup.  One day, my peer, the directof of marketing programs hit me with this in an ops review meeting:

You want to be judged on intentions, not results.

I recall being dumbfounded at the time.  Holy cow, I thought.  Is he right?  Am I standing up arguing about mitigating factors and how things might have been when all the other people in the room were thinking only about black-and-white results?

It was one of those rare phrases that really stuck with me because, among other reasons, he was so right.  I wasn’t debating whether things happened or not.  I wasn’t making excuses or being defensive.  But I was very much judging our performance in the theoretical, hermetically sealed context of what might have been.

Kind of like sales saying a deal slipped instead of did not close.   Or marketing saying we got all the MQLs but didn’t get the requisite pipeline.  Or alliances saying that we signed up the 4 new partners, but didn’t get the new opportunities that were supposed to come with them.

Which phrase of the following sentence matters more — the first part or the second?

We did what we were supposed to, but it didn’t have the desired effect.

We would have gotten the 30 MQLS from the event if it hadn’t snowed in Boston.  But who decided to tempt fate by doing a live event in Boston in February?  People who want to be judged on intentions think about the snowstorm; people who want to be judged on results think about the MQLs.

People who want to judged on intentions build in what they see as “reasons” (which others typically see as “excuses”) for results not being achieved.

I’m six months late hiring the PR manager, but that’s because it’s hard to find great PR people right now.  (And you don’t want me to hire a bad one, do you?)

No, I don’t want you to hire a bad one.  I want you to hire a great one and I wanted you to hire them 6 months ago.  Do you think every other PR manager search in the valley took 6 months more than plan?  I don’t.

Fine lines exist here, no doubt.  Sometimes reasons are reasons and sometimes they are actually excuses.  The question isn’t about any one case.  It’s about, deep down, are you judging yourself by intentions or results?

You’d be surprised how many otherwise very solid people get this one thing wrong — and end up career-limited as a result.

The Role of Professional Services in a SaaS Business

I love to create reductionist mission statements for various departments in a company.  These are designed to be ultra-compact and potentially provocative.  My two favorite examples thus far:

I like to make them based on real-life situations, e.g., when someone running a department seems confused about the real purpose of their team.

For example, some police-oriented HR departments seem to think their mission is protect employees from management.  Think: “Freeze, you can’t send an email like that; put your hands in the air and step away from the keyboard!”

I think otherwise. If the HR team conceptualizes itself as “helping managers manage,” it will be more positively focused, help deliver better results, and be a better business partner — all while protecting employees from bad managers (after all, mistreating employees is bad management).

Over the past year, I’ve developed one of these pithy mission statements for professional services, also known as consulting, the (typically billable) experts employed by a software company who work with customers on implementations after the sale:

Professional services exists to maximize ARR while not losing money.

Maximizing ARR surprises some people.  Why say that in the context of professional services?  Sales brings in new ARR.  Customer Success (or Customers for Life) is reponsible for the maintenance and expansion of existing ARR.  Where does professional services fit in?  Shouldn’t they exist to drive successful implementations or to achieve services revenue targets?  Yes, but that’s actually secondary to the primary mission.

The point of a SaaS business is to maxmize enterprise value and that value is a function of ARR.  If you could maximize ARR without a professional services team then you wouldn’t have one at all (and some SaaS firms don’t).  But if you’re going to have a professional services team, then they — like everybody else — should be there to maximize ARR.  How does professional services help maximize ARR?  They:

  • Help drive new ARR by supporting sales — for example, working with sales to draft a statement of work and by building confidence that the company can solve the customer’s problem.  If you remember that customers buy “holes, not bits” you’ll know that a SaaS subscription, by itself, doesn’t solve any business problem.  The importance of the consultants who do the solution mapping is paramount.
  • Help preserve/expand existing ARR by supporting the Customer Success (aka, the Customers for Life) team, either by repairing blown implementations or by doing new or expanded implementations at existing customers.  This could entail anything from a “save” to a simple expansion, but either way, professional services is there maximizing ARR.
  • Help do both by enabling the partner ecosystem.  Professional services is key to enabling partners who can both provide quality implementation services for customers and who can extend the vendor’s reach through go-to-market partnering.

Or, as our SVP of Services says, “our role is to make happy customers.”

I prefer to say “maximize ARR without losing money” but we’re very much on the same page.  Let’s finish with the “not losing money” part.  In my opinion,

  • A typical on-premises software vendor drove 25% to 30% gross margins on professional services.  Those were the days of one big one-shot license fees and huge multi-million dollar implementations.  In those days, customers weren’t necessarily too happy but the services team had a strong “make money” aspect to its mission.
  • A typical SaaS vendor has negative 10% to 20% gross margins on services (and sometimes a lot more negative than that).  That’s because some vendors subsidize their ARR with free or heavily discounted services because ARR recurs whereas services do not.

I believe that professional services has real value (e.g., I’ve worked with several amazing services teams) and that if you’re driving 0% to 5% gross margins with such a team that you are already supporting the ARR pool with discounted services (you could be running 25% to 30% margins).  Whether you make 0% or 10% doesn’t much matter — because it won’t to someone valuing your company — but I think it’s a mistake to shoot for the 30% margins of yore as well as a mistake to tolerate -50% margins and completely de-value your services.

10 Questions to Ask Yourself Before Moving into Management

I went looking for a post to help someone decide if they should move into management, but couldn’t find one that I really loved.  These three posts aren’t bad.  Nor is this HBR article.  But since I couldn’t find a post that I thought nails the spirit of the question, I thought I’d write one myself.

So here are the ten questions you should consider before making a move into management.

 1. Do you genuinely care about people?  

Far and away this is the most important question because management is all about people.  If you don’t enjoy working with people, if you don’t enjoy helping people, or if you’d prefer to be left alone to work on tasks or projects, then do not go into management.  If you do not genuinely care about people, then do not go into management.

2. Are you organized?

While a small number of organizational leaders and founders can get away with being unstructured and disorganized, the rest of us in management need to be organized.  If you are naturally disorganized, management will be hard for you — and the people who work for you — because your job is to make the plan and coordinate work on it.

This is why one of my managment interview questions is:  “if I opened up your kitchen cabinets what would I see?”

3.  Are you willing to continuously overcommunicate?

In a world filled with information pollution, constant distractions, and employees who think that they can pay continuous partial attention, you’d be amazed how clearly you need to state things and how often you need to repeat them in order to minimize confusion.  A big part of management is communication, so if you don’t like communicating, aren’t good at it, or don’t relish the idea of deliberately and continuously overcommunicating, then don’t go into management.

4.  Can you say “No” when you need to do?

Everybody loves yes-people managers except, of course, the people who work for them.  While saying yes to the boss and internal customers feels good, you will run your team ragged if you lack the backbone to say no when you need to.  If you can’t say no to a bad idea or offer up reprioritization options when the team is red-lining, then don’t go into management.  Saying no is an important part of the job.

5. Are you conflict averse?

Several decades I read the book Tough-Minded Management:  A Guide for Managers Too Nice for Their Own Good, and it taught me the importance of toughness in management.  Management is a tough job.  You need to layout objectives and hold people accountable for achieving them.  You need to hold peers accountable for delivering on dependencies.  You need to give people feedback that they may not want to hear.  If you’re conflict averse and loathe the idea of doing these things, don’t go into management.  Sadly, conflict averse managers actually generate far more conflict than then non-conflict-averse peers.

6. Do you care more about being liked than being effective?

If you are someone who desperately needs to be liked, then don’t go into management.  Managers need to focus on effectiveness.  The best way to be liked in management is to not care about being liked.  Employees want to be on a winning team that is managed fairly and drives results.  Focus on that and your team will like you.  If you focus on being liked and want to be everyone’s buddy, you will fail as both buddy and manager.

7. Are you willing to let go?  

Everybody knows a micromanager who can’t let go.  Nobody likes working for one.  Good managers aim to specify what needs to be done without detailing precisely how to do it.  Bad managers either over-specify or simply jump in and do it themselves.  This causes two problems:  they anger the employee whose job it was to perform the task and they abdicate their responsibility to manage the team.  If the manager’s doing the employee’s job then whose doing the manager’s?  All too often, no one.

8.  Do you have thick skin?

Managers make mistakes and managers get criticized.  If you can’t handle either, then don’t go into management.  Put differently, how many times in your career have your run into your boss’s office and said, “I just want to thank you for the wonderful job you do managing me.”  For me, that answer is zero.  (I have,  however, years later thanked past managers for putting up with my flaws.)

People generally don’t complement their managers; they criticize them.  You probably have criticized most of yours.  Don’t expect things to be any different once you become the manager.

9.  Do you enjoy teaching and coaching?

A huge positive of management is the joy you get from helping people develop their skills and advance in their careers.  That joy results from your investment in them with teaching and coaching.  Great employees want to be mentored.  If you don’t enjoy teaching and coaching, you’ll be cheating your employees out of learning opportunities and cheating yourself out of a valuable part of the management experience.

10.  Are you willing to lead?

Managers need not just to manage, but to lead.  If stepping up, definining a plan, proposing a solution, or taking an unpopular position scares you, well, part of that is normal, but if you’re not willing to do it anyway, then don’t go into management.  Management requires the courage to lead.  Remember the Peter Drucker quote that differentiates leadership and management.

“Management is doing things right, leadership is doing the right things.”

As a good manager, you’ll need to do both.

The Dogshit Bar: A Memorable Market Research Concept

I can’t tell you the number of times I’ve seen market research that suffers from one key problem.  It goes something like this:

  • What do you think of PRODUCT’s user interface?
  • Do you think PRODUCT should be part of suite or a standalone module?
  • Is the value of PRODUCT best measured per-user or per-bite?
  • Is the PRODUCT’s functionality best delivered as a native application or via a browser?
  • Would you like PRODUCT priced per-user or per-consumption?
  • Rank the importance of features 1-4 in PRODUCT?

The problem is, of course, that you’ve never asked the one question that actually matters — would you buy this product — and are pre-supposing the need for the product and that someone would pay something to fulfill that need.

So try this:  substitute “Dogshit Bar” (i.e., a candy bar made of dog shit) for every instance of PRODUCT in one of your market research surveys and see what happens.  Very quickly, you’ll realize that you’re asking questions equivalent to:

  • Should the Dogshit Bar be delivered in a paper or plastic wrapper?
  • Would you prefer to buy the Dogshit Bar in a 3, 6, or 9 oz size?
  • Should the Dogshit Bar be priced by ounce or some other metric?

So before drilling into all the details that product management can obsess over, step back, and ask some fundamental questions first.

  • Does the product solve a problem faced by your organization?
  • How high a priority is that problem?  (Perhaps ranked against a list of high-level priorities for the buyer.  It’s not enough that it solves a problem, it needs to solve an important problem.)
  • What would be the economic value of solving that problem?  (That is, how much value can this product provide.)
  • Would you be willing to pay for it and, if so, how much?  (Which starts to factor in not just  value but the relative cost of alternative solutions.)

So why do people make this mistake?

I believe there’s some feeling that it’s heretical to ask the basic questions about the startup’s core product or the big company’s new strategic initiatiave that the execs dreamed up at an offsite.  While the execs can dream up new product ideas all day long, there’s one thing they can’t do:  force people to buy them.

That’s why you need to ask the most basic, fundamental questions in market research first, before proceeding on to analyzing packaging, interface, feature trade-offs, platforms, etc.  You can generate lots of data to go analyze about whether people prefer paper or plastic packaging or the 3, 6, or 9 ounce size.  But none of it will matter.  Because no one’s going to buy a Dogshit Bar.

Now, before wrapping this up, we need to be careful of the Bradley Effect in market research, an important phenomenom in live research (as opposed to anonymous polls) and one of several reasons why pollsters generally called Trump vs. Clinton incorrectly in the 2016 Presidential election.

I’ll apply the Bradley Effect to product research as follows:  while there are certain exception categories where people will say they won’t buy something that they will (e.g., pornography), in general:

  • If someone says they won’t buy something, then they won’t
  • If someone says they will buy something, then they might

Why?  Perhaps they’re trying to be nice.  Perhaps they do see some value, but just not enough.  Perhaps there is a social stigma associated with saying no.

I first learned about this phenomenom reading Ogivly on Advertising, a classic marketing text by the father of advertising David Ogilvy.  Early in his career Ogilvy got lucky and learned an important lesson.  While working for George Gallup he was assigned to do polling about a movie entitled Abe Lincoln in Illinois.  While the research determined the movie was going to be a roaring success, the film ended up a flop.  Why?  The participants lied.  After all, who wants to sound unpatriotic and tell a pollster that you won’t go see a movie about Abe Lincoln?  Here’s a picture of Ogilvy doing that research.  Always remember it.

ogilvy