EPM, Project Orion, and the Beginner’s Mind

I’ll always be thankful for my time at Salesforce both because I met so many amazing people and because I learned so much.  I learned about the importance of Trust in a SaaS company (and was drilled in the mantra, “nothing is more important than the Trust of our customers.”)  And I learned about shoshin, the Zen concept of the Beginner’s Mind.

The Beginner’s Mind
It’s not unusual when working at Salesforce to hear about Zen concepts or get an email reply from Marc containing only a Zen proverb.  But of all the concepts I learned about, the most powerful and elusive was shoshin, a concept that Benioff says he adopted from Steve Jobs.  Per Wikipedia:

Shoshin (初心) is a word from Zen Buddhism meaning “Beginner’s Mind.” It refers to having an attitude of openness, eagerness, and lack of preconceptions when studying a subject, even when studying at an advanced level, just as a beginner would.

Shoshin is powerful because it enables you to take a fresh look at an old problem.  Shoshin is elusive, however, because it requires you to step outside your paradigm — the filters through which you see the world — which perhaps sounds easy, but can be incredibly difficult.  In fact, in what I all the paradox of knowledge, the more you know about something the more difficult it is to break out of your paradigm, to get outside the metaphorical box.

As an example of this, our head of products, Sanjay Vyas, recently went to a silent, ten-day vipassana meditation retreat.  Vipassana means “to see things as they really are”  and is a technique that has been passed down from the Buddha by an unbroken chain of teachers to the present day.  At the retreat, the first phase is three days spent simply trying to calm the noise in your mind.  Only then, after three days of silent meditation, are you ready to start to attempt to see things as they really are.  Such is the difficulty in breaking free from a paradigm.

The Problem We Approached With a Beginner’s Mind
What problem did we try to see with a Beginner’s Mind at Host Analytics?  End-user planning, budgeting, and forecasting (three key pieces of enterprise performance management, also known as EPM).  Why did we do it?  Because despite decades of great success within finance organizations, we believe that EPM has under-penetrated the overall market.

Far too many people rely solely on Excel for planning/budgeting and far too many EPM end-users build budgets in Excel and mail them to finance as opposed to using the EPM system.  The same is true for reporting, where far too often users drop out of the EPM system and into Excel to make reports and charts.  (This is less true of Host users due to our strong reporting, but the trend remains true at an industry level.)

While as EPMers, we take great pride in our category and, at Host, in our ability to move enterprise-class EPM to the cloud, we must recognize that at some level EPM has failed to deliver against its broad vision of accountability and empowerment.  To get to the bottom of this, as Clayton Christensen has often observed, you can’t just talk to your customers to understand your market, you need to understand non-consumers as well.  All those Excel-only or primarily-Excel users are Christensen’s non-consumers, so we decided to talk to them.  Here’s an example of what we heard.

“I hate budgeting.  They made me attend the meeting to look at these tools.  I don’t want to use any of them.”  — Chief Legal Officer

We heard this over and over.  The average business user would seemingly prefer a root canal to working on the budget.  Yet we knew these same business users were passionate about metrics, empowerment, accountability, and performance.  So where had the whole category gone wrong?  Thus was born Project Orion.

By Finance For Finance
We realized that for forty years EPM has been designed by finance for finance (or even more specifically, by FP&A for FP&A).  EPM vendors did a great job of listening to EPM customers.  And EPM customers, particularly EPM buyers, often had job titles like Vice President of Financial Planning & Analysis (FP&A).  These were the people who selected the tools.  These were the people who bought the tools.  But, these weren’t always the people who used the tools.  An important part of EPM is to roll it out broadly across an organization, meaning to put the tool into the hands of business end-users, budget owners, in all the various departments.

The Perils of “Configuration” to Dumb Down the Interface
The universal answer to the end-user question was dumb it down.  Configure it.  Take the product that was built for a heavily analytical, highly skilled, finance professional — and FP&A people are whip smart — and dumb down the interface for a business end-user.  Hide some menu items.  Remove some toolbar buttons.  Take away some tabs.

That was the conventional wisdom.  Take a product built for one person and configure it for use by another.  Now some EPM vendors were better than others at this bluff, some had slicker interfaces that would be relatively more appealing than others.  But amazingly, nobody ever said,  “wait a minute, what if we designed the product for people who actually used it?

Thank to shoshin, that’s exactly what we did with Project Orion at Host Analytics.

Task-Oriented Design
Instead of starting with what we had, a template-oriented product built for finance people, and a desire to twist/configure into something else, we started with a blank sheet.  We asked business end-users what they wanted to do with an EPM product.  Those end-users gave us a three-part answer:

  • We want to be able to quickly figure out where we stand relative to the plan.
  • We want help in determining where we are going to land on the current quarter — and to optimize that result.  (Not an easy problem, mind you.)
  • We want to get the next period planned in line with objectives and targets.

And we want to do all of the above quickly and easily because, much as we love this stuff (and we don’t), we’ve got a business to run.  This idea, what we came to call the stand / land / planned message, became the center of Orion design.

How We Knew We Were Onto Something
We noticed quickly that people had strong reactions to Orion, which typically fell into one of two types:

  • Reaction 1:  “Holy Cow, why didn’t I think of that?  It’s kind of obvious in 20/20 hindsight.”
  • Reaction 2:  “That’s not needed.  You just need to configure your way out of the problem.”

In the early days, we got a lot of reaction 2 — particularly from our internal EPM experts, who were somewhat blinded by the paradox of knowledge.  The internal resistance was, at times, intense.  But that resistance told me that we were onto something.  We were challenging the conventional wisdom in a way that could lead to a major breakthrough.  And the more we asked people outside Host, and the more we showed Orion to business end-users, the more convinced we were that we had made such a breakthrough.

The same chief legal officer who said “I hate budgeting” above, said this:

“When I look at Project Orion, it’s clear that you are the only folks thinking about me.  I could and would use this tool.” — Chief Legal Officer after seeing Orion.

Tips on Adopting a Beginner’s Mind
We’re launching Project Orion today and proud both of the software we built and how we came to build it.  We believe Orion is a breakthrough product that is going to change the EPM market.  All because we looked at an age-old problem in EPM with a Beginner’s Mind.

I’ll finish the post with some tips on how to take a shoshin approach that we learned along our journey — and which happily don’t involve 10 days of silent meditation.

  • Put a mix of veterans and neophytes on the project.  This will reduce the paradox of knowledge and naturally bring in some fresh eyes.
  • Confront tough facts.  The data says lots of people still use only or primarily Excel despite 40 years of EPM.  That’s a fact.  The question is why?
  • Challenge the team to document hidden assumptions.  Configuration as the solution to the end-user problem was one such huge assumption.  You can only go outside the box when you know its edges.
  •  Talk to non-consumers.  Talking to customers is great, but it can create an echo chamber.  Talk to non-consumers, too, particularly when fishing for breakthroughs, and ask them why they have not purchased in the product category.
  • Embrace resistance.  View resistance as a good sign, as a sign that you’re changing something big, and not just as a yellow flag.
  • Test early and often.  Go back to the non-consumers you interviewed and ask if your prototype would change their mind.  Iterate in response.



The Single Biggest Myth about MBOs and OKRs

I’m a big believer in written quarterly goals.

The old way to do this was to adopt “management by objective” (MBO) and to write down a set of MBOs for each quarter for each team member.  Most folks would do this either in Word, or if they liked weightings and scores as part of calculating an MBO bonus, Excel.  Over time, larger enterprises adopted HR performance management software to help with managing and tracking those MBOs.  When writing individual objectives, you were advised that they be SMART (specific, measurable, attainable, realistic, time-bound).

Despite best intentions, over time MBOs developed a bad rap for several reasons:

  • People would make too many of them, often drowning in long lists of MBOs
  • Few people could write them well, so would-be SMART objectives ended SQUISH (soft, qualitative, unintelligible, imprecise, slang, and hazy) instead.
  • They were often hard-linked to compensation, encouraging system-gaming

The objective / key result (OKR) system is a more modern take on objective setting popularized by, among others, Google and venture capitalist John Doerr.  OKRs fix some of the key problems with MBOs.

  • A strong guideline to have no more than about 5 OKRs per person to avoid the drowning-in-MBOs problem.
  • Adding a tiny bit of structure (the key results) helps enormously with producing objectives that are specific and measurable.
  • A realistic and intelligently calibrated scoring system whereby 70% is considered a “good” grade.  The defeats a lot of the system gaming.

But, regardless of which system you’re using, you can still hear the following myth from some managers and HR professionals:

“Oh, wait.  The objectives shouldn’t list things in your core job.  They should be the things on top of your core job.”  Sometimes followed by, “who’d want to pay you a bonus just for doing your core job?”

This is just plain wrong.

Let’s make it clear via an example.  Say you’re a first-line technical support person whose job is to answer 20 cases per day.  To ensure you’re not just closing out cases willy-nilly, your company performs a post-case customer satisfaction (CSAT) survey and wants you to maintain a post-case CSAT rating of 4.5 out of 5.0.  In addition, the company wants you to do 6 hours of skills training and write 4 knowledge-base articles per month.

If you live by the myth that says written objectives should be above and beyond your core job then this person should have two quarterly objectives:

  • Write 4 knowledge-base articles per month.
  • Attend 6 hours of skills training per month.

This is simply insanity.  You are going to the trouble of tracking written objectives, but overlooking 90%+ of what this person actually does.  This person needs to have 3 quarterly objectives:

  • Close 100 cases per week with a 4.5+ CSAT rating
  • Write 4 knowledge-base articles per month
  • Attending 6 hours of skills training per month

And if we’re tying these to a bonus, most of the weight needs to be on the first one.

While I know I’ve argued this via reductio ad absurdum, I think it’s the right way to look at it.  If you’re going to track written objectives — by either MBO or OKR — then you should think about you the  entire job scope, be inclusive, and weight them appropriately.


My SaaStr 2018 Presentation: Ten Non-Obvious Things About Scaling SaaS

Below please find the slides from the presentation I gave today at SaaStr 2018, about which I wrote a teaser blog post last week.  I hope you enjoy it as much as I enjoyed making it.

I hope to see everyone next year at SaaStr — I think it’s the preeminent software, SaaS, and startups conference.

How to Walk From a Deal

Like it or not, once in a while it’s appropriate for a vendor to walk away from a prospective deal.  Why might you want to do that?

  • You think your product is a poor fit with the customer’s needs.
  • You believe there is insufficient budget to achieve success on the project.
  • You feel like the deal is wired for another vendor, i.e., you think you are column fodder in the evaluation process.
  • You (and all your fellow reps) are fully booked with other more qualified opportunities.

One day I should probably write a post on how to make the critical stay vs. walk decision.  But today, I want to focus on something downstream of that — I want to focus on how to successfully walk from a deal once you’ve decided that it’s necessary to do so.

A good walk-away process should pass three tests in the mind of the customer.

  1. The customer should feel like they were treated respectfully.
  2. In the future, the customer should remain interested in buying from both you individually and your company, should circumstances be different.  (Ideally, they will be more interested in buying from you because you walked.)
  3. The customer should feel like the decision was not unilateral.

Given these three tests, here a few ways NOT to walk away from an opportunity.

  • Calling five minutes before a meeting to say you’re too busy to work on the opportunity because you don’t think it’s qualified anyway.
  • Leaving a voicemail in the middle of the night saying that you’ve decided to stop pursuing the opportunity.
  • Telling the customer their problem is too simple and/or their people are not sufficiently sophisticated to use your software.
  • Emailing to say that they are running a rigged process in which you can no longer, in good conscience, compete.

And there are lots more.  In short, there are a lot of WRONG ways to walk from an opportunity.  The right way involves doing the following things:

  • Bring it up quickly.  Once you realize there’s good reason to walk, you immediately get in touch with the customer.
  • Get the key contact on the phone and saying you’re considering dropping out and would welcome the chance to explain why.
  • Have a meeting or call to discuss the reasons you believe you should no longer participate in the sales cycle.
  • Ask for their feedback on those reasons.
  • Unless you hear otherwise in their feedback, thank them for their time.
  • Check back in later (e.g., in a few months) to ask how things turned out.

Amazingly, a lot of salespeople are afraid to walk away correctly.  So they procrastinate and then, suddenly, at the 11th hour, burst out saying “we’re not coming.”  This leaves a terrible impression on the customer and denies them the chance to correct potential misunderstandings in the logic that led to the walk-away decision.

My company has won deals by walking away in the right fashion.  To be clear, I am not advocating bluffing; when you say you’re walking you need to be prepared to do so.  But I have seen cases where the walk-away attempt revealed either a misunderstanding of the problem or the fact that no other vendor was willing to tell the customer what they didn’t want to hear.

I’ve seen cases where we get invited back six to eighteen months later and then win the deal.

I’ve also seen cases where the rep mangles the walk-away process, the customer goes ballistic and I, as CEO, need to jump in, eat a large piece of humble pie, figure out what’s going on, and assign a new rep to the deal.  We’ve won a few of these as well.

A fair number of salespeople like to brag about walking from deals, yet relatively few are mindful in how they do it.  Those who are mindful, and who follow the rules and steps above, will sell more in both the short- and long-term than those who are not.

My SaaStr Talk Abstract: 10 Non-Obvious Things About Scaling SaaS

In an effort to promote my upcoming presentation at SaaStr 2018, which is currently on the agenda for Wednesday, February 7th at 9:00 AM in Studio C, I thought I’d do a quick post sharing what I’ll be covering in the presentation, officially titled, “The Best of Kellblog:  10 Non-Obvious Things About Scaling SaaS.”

Before jumping in, let me say that I had a wonderful time at SaaStr 2017, including participating on a great panel with Greg Schott of MuleSoft and Kathryn Minshew of The Muse hosted by Stacey Epstein of Zinc that discussed the CEO’s role in marketing.  There is a video and transcript of that great panel here.


For SaaStr 2018, I’m getting my own session and I love the title that the folks at SaaStr came up with because I love the non-obvious.  So here they are …

The 10 Non-Obvious Things About Scaling a SaaS Business

1. You must run your company around ARR.  Which this may sound obvious, you’d be surprised by how many people either still don’t or, worse yet, think they do and don’t.  Learn my one-question test to tell the difference.

2.  SaaS metrics are way more subtle than meets the eye.  Too many people sling around words without knowing what they mean or thinking about the underlying definitions.  I’ll provide a few examples of how fast things can unravel when you do this and how to approach SaaS metrics in general.

3.  Former public company SaaS CFOs may not get private company SaaS metrics.  One day I met with the CFO of a public company whose firm had just been taken private and he had dozens of questions about SaaS metrics.  It had never occurred to me before, but when your job is to talk with public investors who only see a limited set of outside-in metrics, you may not develop fluency in the internal SaaS metrics that so obsess VC and PE investors.

4.  Multi-year deals make sense in certain situations.  While many purists would fight me to the death on this, there are pros and cons to multi-year deals and circumstances where they make good sense.  I’ll explain how I think about this and the one equation I use to make the call.

5.  Bookings is not a four-letter word.  While you need to be careful where and when you use the B-word in polite SaaS company, there is a time and place to measure and discuss bookings.  I’ll explain when that is and how to define bookings the right way.

6.  Renewals and satisfaction are more loosely correlated than you might think.  If you think your customers are all delighted because they’re renewing, then think again.  Unhappy customer sometimes renew and happy ones don’t.  We’ll discuss why that happens and while renewal rates are often a reasonable proxy for customer satisfaction, why you should also measure customer satisfaction using NPS, and present a smart way to do so.

7.  You can’t analyze churn by analyzing churn.  To understand why customers churn, too many companies grab a list of all the folks who churned in the past year and start doing research and interviews.  There’s a big fallacy in this approach.  We’ll discuss the right way to think about and analyze this problem.

8.  Finding your own hunter/farmer metaphor is hard.  Boards hate double compensation and love splitting renewals from new business.  But what about upsell?  Which model is right for you?  Should you have hunters and farmers?   Hunters in a zoo?  Farmers with shotguns?  An autonomous collective?  We’ll discuss which models and metaphors work, when.

9.  You don’t have to lose money on services.  Subsidizing ARR via free or low-cost services seems a good idea and many SaaS companies do it.  But it’s hell on blended gross margins, burns cash, and can destroy your budding partner ecosystem.  We’ll discuss where and when it makes sense to lose money on services — and when it doesn’t.

10.  No matter what your board says, you don’t have to sacrifice early team members on the altar of experienced talent.  While rapidly growing a business will push people out of their comfort zones and require you to build a team that’s a mix of veterans and up-and-comers, with a bit creativity and caring you don’t have to lose the latter to gain the former.

I hope this provides you with a nice and enticing sample of what we’ll be covering — and I look forward to seeing you there.

Quota Over-assignment and Culture

Here’s a great slide from the CFO Summit at Zuora’s 2017 annual flagship Subscribed event.


Since they talk about this as under-assignment, since people aren’t great at flipping fractions in their head, and since I think of this more intuitively as over-assignment, I’m going to invert this and turn it into a pie chart.

quota over

So, here you can  see that 22% of companies have 0-11% over-assignment of quota, 44% have 11-25% over-assignment, 23% have 25-43%, 5% have 43-100% over-assignment, and 7% have more than 100% over-assignment of quota.

Since this is a pretty broad distribution — and since this has a real impact on culture, I thought examine this on two different angles:  the amount of total cushion and where that cushion lives.

The 0-11% crowd either has a very predictable business model or likes to live dangerously.  Since there’s not that much cushion to go around, it’s not that interesting to discuss who has it.  I hope these companies have adequately modeled sales turnover and its effects on quota capacity.

The 11-25% crowd strikes me as reasonable.  In my experience, most enterprise software companies run in the 20% range, so they assign 120 units of quota at the salesrep level for an operating plan that requires 100 units of sales.  Then the question is who has the cushion?  Let’s look at three companies.


In company 1, the CEO and VP of Sales are both tied to the same number (i.e., the CEO has no cushion if the VP of Sales misses) and the VP of Sales takes all of the cushion, giving the sales managers none.  In company 2, the CEO takes the entire 20% cushion for him/herself, leaving none for either the VP of Sales or the sales managers.  In company 3, the cushion is shared with the CEO and VP of Sales each taking a slice, leaving nearly half for the sales managers.

While many might be drawn to company 3, personally, I think the best answer is yet another scenario where the CEO and VP of Sales are both tied to 100, the sales managers to 110, and the aggregate salesrep quota to 120.  Unless the CEO has multiple quota-carrying direct reports, it’s hard to give the VP of Sales a higher quota than him/herself, so they should tie themselves together and share the 10% cushion from the sales managers who in turn have ~10% cushion relative to their teams.

I think this level of cushion works well if you’re building it atop a productivity model that assumes a normal degree of sales turnover (and ramp resets) and are thus using over-assignment simply to handle non-attainment, and not also sales turnover.  If you are using over-assignment to handle both, then a higher level of cushion may be needed, which is probably why 22% of companies have 25-43% over-assignment in their sales model.

The shock is the 12% that together have more than 43% over-assignment.  Let’s ponder for a minute what that might look like in an example with 60% over-assignment.


So think about this for a minute.  The VP of Sales can be at 83% of quota, the sales managers on average can be at 71% of quota, and the salesreps can be at 63% of their quota — and the CEO will still be on plan.  The only people hitting their number, making their on-target earnings (OTE), and drinking champagne at the end of the quarter are the CEO and CFO.  (And they better drink it in a closet.)

That’s why I believe cushion isn’t just a math problem.  It’s a cultural issue.  Do you want a “let them eat cake” or a “we’re all in this together” culture.  The answer to that question should help determine how much cushion you have and where it lives.

Speaking of India: Five Lessons on India-Based Product Development

One of the interesting new challenges I faced when I joined Host Analytics about 5 years ago was working with an offshore development team in India.  Host was originally co-founded in both the US and India, so literally from inception we had employees in both places.  While this has proven to be a huge advantage for us in the market, I learned a few important lessons along the way that I thought I’d share in this post.

Lesson 1:  Read Speaking of India.

When I lived abroad in France for 5 years (which I’ve written a bit about, here), my team discovered a book, French or Foe, that we gave to every new expat when they arrived.  The book explained many important basics of language and culture that we referred to frequently as we tried to make sense of our day-to-day experiences.

Consequently, the first thing I did in approaching India was to search for a book to help me.  I found a great one, Speaking of India, which is all about communications (and how they go wrong) between people from US and Indian work cultures.

For example, see this excerpt which demonstrates “the Indian no” (i.e., the absence of saying yes) in action.

MARIAN: I’m fine, thanks. I was wondering, Kumar, what you would think if we decided to move up the date for the systems test?

KUMAR: Move it up?

MARIAN: Just by a week, at the most.

KUMAR: I see. Do you think it’s possible?

MARIAN: Should be. But what do you think?

KUMAR: Me? I guess you don’t see any problems?

MARIAN: Not really. My people can be ready at this end if your people can be up to speed by then.

KUMAR: I see.

Kumar is basically screaming no here while Marian might very well be hearing yes.

These kinds of misunderstandings are common and if you teach yourself listen appropriately then you can actually hear what is, or in this case, is not being said.

You’ll learn this — and much more — in the Speaking of India.  And you can learn some unique Indian-English words/expressions (e.g., a fresher) as well.

Lesson 2:  Show Up.

It’s hard to get to India.  From San Francisco, it’s 16 hours to Dubai and then 3.5 to Hyderabad (or 14 hours to Hong Kong and then 6 hours to Hyderabad). It takes me a full week to get about 3.5 days of actual work time there.  And let’s not even talk about the 12.5 to 13.5 hour time difference.

But that’s the point.  Because it’s hard, too many people don’t do it, preferring conference calls at odd hours over noisy telephone lines.  If you are serious about your India development center and the people in it, then you need your top executives to show up — at least a few times per year — to get to really know the people and the work environment.

I go three to four times per year with a agenda that typically looks like:

  • A large number of 1-1 meetings
  • Attendance at a few regular group/team meetings
  • A few special, topical meetings
  • An all-hands meeting at the end where I report back on what I’ve learned
  • A few dinner / drinks meetings along the way

Remember the old Woody Allen quote, 80% of success is showing up.  It’s a great rule to follow when thinking of your India development team.

Lesson 3:  Think of Product Management as a Giraffe.

I first came up with the giraffe analogy when I was at Business Objects in Paris.  While our development team (the body) was in France, we needed to have our eyes and ears in the US market if we wanted to be globally competitive.  Hence, product management needed to be the long neck that connected the two.

Concretely, this means you need to staff product managers in both locations, typically putting a greater number of more specialized product managers (PMs) in the USA and a lesser number of more generalized PMs in India. This means your PM investment might be higher than it would be with a co-located model, but it’s worth it.

Some people believe you should call the US-based staff product managers and the India-based staff product owners (POs), but I prefer to call them all product managers.  The reality is the job will inherently be different as a function of location — the USA PMs more customer-facing and the India PMs more engineering-facing — but in the end they are all product managers in my view.

Lesson 4:  Do Real Work.

The fact that we build our core SaaS offering in Hyderabad is a big attraction for talent.  Too many companies use India to do only lower-value work (e.g., porting, localization) which sets up a self-fulfilling prophecy of getting lower-quality talent.  We have found that when you do real work in India — core, critical stuff — that you will have a much easier time attracting talent to do it.

Lesson 5:  Do More Than Development.

Finally, we’ve increasingly been leveraging our footprint to do additional work — such as customer support, customer success, professional services, and even some marketing — which helps transform the environment from purely a “development center” to a generalized satellite office.   This is great because it provides developers and product managers with more direct access to the business — because people in other customer-facing functions are working right across the hall.   Practically, this helps with 24×7 operations (e.g., techops, customer support) as well, where we can provide customers with round-the-clock monitoring and services without having to ask too many people to work the graveyard shift.

I hope you’ve learned something from my journey.  Please feel free to share lessons from yours.