Revamping Packaging & Pricing at Gainsight, with Johnny Cheng

My interview with Johnny Cheng on his time at Gainsight was one of the most instructive in terms of the challenges that occur with pricing when a company is in its high growth stage. As the then Director of Product Marketing at Gainsight, Johnny commandeered Pricing Strategy, CPQ (Quote-to-Cash), Go-to-Market Pricing and Packaging, Analytics and Reporting, as well as Deal Strategy and Support. He elaborates in his own words.

How Gainsight Pioneered the Customer Success Movement

Gainsight is the leader in Customer Success (CS) software. We are to CS platforms what Salesforce is for Customer Relationship Management (CRM), or what Workday is for Human Resources (HR).

The CS movement happened five or six years ago. If you look at CS roles back then, they didn’t really exist in an organization. You would have a support person and an account manager, and that was basically it. Gainsight pioneered the whole CS movement and actually built a community of CS professionals, almost a set of buyers. As a consequence of the community, we started seeing elevated roles like Chief Customer Officer (CCO). Interestingly, a lot of our early adopters and champions are CCOs at a bunch of companies now.

In terms of our target buyer, it is obviously CS professionals, like the CCO and VP, who we sell to. For more traditional companies, we try to sell to IT or the Head of Support.

This is especially true for companies going through a digital transformation, moving from a perpetual license to a subscription model. Earlier, when they deployed hardware, they would just charge for support and move on. Now, as they’re moving to a subscription model, they see a bunch of different customer touchpoints. And so, they need software that can basically handle that.

That’s kind of our sweet spot, in terms of who we sell to. We definitely have a lot of big names that really believe in this whole transformation, which takes them from what they always did, to ongoing CS.

Gainsight’s Pricing Problems

One of the reasons Gainsight brought me on-board was to fix the number one thing that was broken there – pricing.

In particular, the most broken segment was mid-market. Ironically, mid-market was actually their product-market fit sweet spot. Smaller customers couldn’t afford them altogether and larger companies could probably build something similar themselves. But to have pricing be broken in your target segment is bad.

In the mid-market space, at the time, Gainsight used a feature-based pricing model where it was just a good-better-best offering — that’s it. For a set price of say $1,000-$2,000-$3,000, you just get a good-better-best package. I’ll go into why that was broken.

They also had an Enterprise model, where it was just completely discrete pricing. Sales would basically make up a price. The top of the Enterprise deals worked fine with that approach because they were value selling, and they didn’t need much guidance.

But Gainsight was stuck in the mid-market segment, where they didn’t have the luxury of doing a return on investment (ROI) analysis of a five-year launch and building a discrete pricing model; all while wanting to sell on value and not leave money on the table.

The good-better-best model wasn’t even working, because they were always selling the middle tier package each time. Even when they sold the larger tier, it was at the same Average Selling Price (ASP) as the middle tier. Not only that, but the packages created a lot of shelfware, and there were constant downsells.

Gaisught’s software was extremely custom. Every company does CS differently and every client needs their platform to be something different. It’s not cookie-cutter or like Marketing Automation, with very defined for-use cases. Everyone knew how to do that. With CS, no one knew how to do it! Everyone had their own view, their own brain. The good-better-best approach didn’t really work.

For larger Enterprise companies, the top ones, if you did an analysis based on their price points, it was all over the place. They were selling stuff for like $5 a user or then $1,000 a user. It was just like the Wild West, whatever money they could get, they just went for it!

Johnny’s Approach To Packaging & Pricing

Creating a Modular Packaging Solution

Looking at my past experience, one thing that worked really well was solution-based selling. We created modular solutions — think of them as Lego pieces. We could tell a salesperson, “Here are your Lego sets, you can put them together however you want.” But, there was a price tied to each module. It was almost like a packaged-plus-à la carte hybrid model.

In order to develop these Lego pieces, I did this packaging exercise (which I do at all of my companies) in the following steps:

  1. List out: We broke down every single feature and just listed them all out. These usually end up in the hundreds.
  2. Group up: Once we had these, we looked through different lenses for how to bucket these capabilities into what I call modules - capabilities that are natural to group together, like things a set of users would commonly use.
  3. Test: When these bucketed modules were created, we started going through iterations to test them against customer segments, to see whether they fit that segment’s usage.
  4. Rearrange: We also checked to confirm if the features that formed the modules were mutually exclusive and completely exhaustive (MECE), or not. Based on the testing, we broke up or combined these modules further.
  5. Categorize: Finally, we categorized the modules we arrived at - based on their sophistication, price point, value, and a bunch of historical analyses about how they typically performed, adoption, and more.

Going through these categorizations, we started noticing patterns that helped decide packaging:

  • What if these products are of very high value, they’re table stakes, and used by everybody? These went into a base package.
  • What module does only the most sophisticated customer see, is of very high value, and increases adoption? This could be its own standalone add-on module.

The caveat with this approach is that it requires a fine balance, and not listing out a hundred things. What you do want is to group the modules to a point where the salespeople can understand it. Then, they can sell the value of each individual one, and it can carry a discrete price.

Setting The Value Metric

The main benefit of a solution selling model is that you can have zero to two value metrics per module, if you really wanted to go with that level of granularity. Our primary value metric at Gainsight was users; our secondary was number of customers.

If you think of the individual modules, they were either based on:

  1. Users, or
  2. Customers, or
  3. Users and customers, or
  4. None (which is a flat fee).

With that kind of flexibility in a model, you could start to hone in on where you really capture value. Certain things just do not make sense, aligned to users. 

For example, if we had this capability that basically communicates out to customers, like marketing automation for CS. In this, you cannot just pass on the number of users, the value of this module has nothing to do with users. It has everything to do with customers, though. If I have 5,000 customers, I’m going to reach out to them and charge you based on those customers. So, certain things are measured on different levers, and what’s nice is that you can tweak this on multiple axes. That was a really big change, because Gainsight, as with a lot of SaaS companies, relied too heavily on users. A lot of SaaS companies just go ahead with users as the metric, not caring if it doesn’t align, because they don’t know how to price.

A lot of pricing professionals aren’t willing to change the value metric or explore other options, because they’re afraid it will mess up ASP or sales cycles. But it is one of the few things you just have to get right, even if it means tweaking it.

I learnt this from my time at Marketo, when I first started there, the overall industry metric everybody used was sent email volume. If you think of how that lever aligns to value, it doesn’t! You can send a bunch of emails out, but it doesn’t mean that you're going to capture more value from them or get more contacts. It’s also extremely hard to predict how many emails you’re going to send in the following year.

So, we were one of the first to pioneer the concept of pricing per contacts, which actually aligns very closely to value – “If you use my product to get more leads and pay us more money, you’re still more successful in return.” Finding this lever is almost like a silver bullet; which a lot of companies fail to do.

Selecting the Value Metric for ‘Marketo for Mobile’

An instance of where we had the wrong lever was when we introduced Marketo for mobile, our pricing lever was the number of app downloads. We thought that since we’re mobile marketing, it makes sense because the more apps your customer downloads, the better your marketing is doing, the more you pay us money. Within a month of launching pricing packaging and going out to market, we realized we had completely messed up.

If you asked any mobile first company what metric they value, it’s always monthly active users (MAUs). That’s the number they put to the board and they tell investors. They don’t care that they got a million people to download their apps, they want engagement. How many of those million people actually went in and touched the app? That’s their MAU. We quickly pivoted as well, because when our earlier lever didn’t resonate with value, we changed it up immediately.

Results of The Pricing Revamp

Impact on the Sales Process

The change was very well-received in the mid-market segment, as they now had guidance. They could do value selling, there were price curves, they understood the discount ranges, what other customers bought for, and more.

As for the Enterprise segment, they were fine with getting some structure and the discount was still up to their discretion. So there was still a lot of value selling and proven ROI. In certain Enterprise cases, where something wasn’t priced according to expectations, we would create sub-packages. These Enterprise-grade packages made it modular enough to cater to both segments.

Ultimately, where we struggled is in the small to midsize business (SMB) space. Here, you tend to develop a crutch — “I only sell this one package and that’s all I sell. I don’t care if the customer needs 20 percent of it, or more, I am just going to sell this.” This way, we also didn’t sell under value. But eventually, the company had to actually learn how to do value selling - about modules and how to position modules for customers. That was difficult, but it was a step in the right direction, in terms of behavior.

Changes in Performance Metrics

A few things were really apparent:

  1. Firstly, ASP obviously shot up, right off the bat.
  2. Annual Recurring Revenue (ARR) also went up.
  3. The really good thing is we sold less for more money, which is like the Holy Grail. I sold less modules for more money because it felt more custom and it was selling under value.
  4. In return, our expansion dollars went up as well.

Overall, it was just a very positive and huge change in how we were monetizing our capabilities. This change was almost expected from me at the three companies where I headed pricing, if you make these changes and train the reps on how to use this model, the ASP will go up and the expenses can, too.

Data Sources to Tap for Analysis & Research

The only three things I do are:

  1. Talk to customers or prospects.
  2. Look at historical data.
  3. Look at competitive data.

I’ve seen a lot of McKinsey-like studies where they do a lot more, but at the end of the day, as a pricing professional, you just have to be really flexible and organic with your pricing. You can’t get stuck at a figure. You have to be able to look into analysis and optimize. A lot of pricing professionals don’t like the optimization part. It’s all about just tuning, tuning and tuning. I’m a strong believer in optimization and change my price curves especially for newly launched products once a month. It then becomes once a quarter, then maybe once a year, and finally maybe never. But you have to keep tweaking.

Johnny’s Take on Pricing Operations: The Ups and Downs of CPQ

I have a very strong point of view on Configure, Price and Quote (CPQ) systems. If you’re just doing feature package selling, you don’t really need a lot of sales tools or CPQ. It’s easy enough to do especially because it’s so transparent to your customer. But once you start moving up and begin value selling, you have to start creating tools for sales. It is a must. My fundamental belief is that in order to do value selling, you need a ton of flexibility. And there is a level of complexity when you introduce it. This can be the deal killer, as it slows things down, makes it so that reps can’t defend the deal or price points. It’s very hard for them.

In order to address that complexity and keep the flexibility, you have to introduce tools. In every company I’ve been at, I’d give them both the pricing calculator and a CPQ. I’m a strong believer that the pricing calculator is used very early in a sales cycle to do budgeting, rough numbers and packaging. CPQ is basically a guidance selling process.

Whenever I mention CPQ, a lot of people feel it is one of the worst tools to implement in the history of software. But I’m a huge fan of CPQ because it gives all that guidance and all those instruments. It also means less reliance on the Deal Desk and allows your company to scale. This is while giving you a lot of data on the backend. There are a lot of positives about CPQ, but it is painful to implement, especially if never done before.

While I led the process, it had to be in partnership with sales ops, IT, and finance, all the people actually building it. It’s almost like the four legs of a table. If you’re missing any of the legs, it’s guaranteed that implementation will be bad, and there will be pitfalls. If your sales ops are very tuned in to sales, product and the various spokes, things may be fine. But then, most sales ops try to build CPQ for the Deal Desk. CPQ is not a Deal Desk tool. It’s a sales tool. Unless they have that perspective, it’s extremely difficult.

That’s why my guidance is that if you build something like a calculator in parallel with CPQ and say “CPQ is the source of truth”, the calculator basically just follows.