Estd 4.22.2023
.png)
.png)
Natalie Louie is a pricing guru and is currently Sr Director of Product Marketing at Zuora. She is also a pricing SME at Impact Pricing, LLC.
I spoke to Natalie about her time at Oracle. As the head of Oracle Marketing Cloud’s (OMC) Pricing Operations from 2015 to 2018, Natalie Louie has extensive experience in value creation through creative subscription pricing and packaging strategies. Her innovative strategies made it easier for customers to buy Oracle products, as well as for the sales team to sell and drive more revenue, profits and lifetime value. She elaborates on some of the innovative price changes made during her time with the company, and more.
If I were to detail one specific pricing journey during my stint at Oracle, it would be in the mobile space. At the time, many years ago when I was there, Oracle was making its foray into a mobile-first world. Mobile can be a really complicated domain, thanks to the variety of messaging channels.
When you’re sending out mobile marketing messages, there is a whole network of third-party partners you have to work with. When you send that text message from your phone, it actually comes from a phone company, which sets the price of how much it costs.
So, you don’t completely own pricing. There are several people taking a piece of that pie, and you have to play by all of their rules and regulations.
Every country has their version of networks like Sprint, T-Mobile, AT&T. In each country, every region sets its own rate. It’s something like the stock market, pricing keeps changing every minute. For instance, the rate of a phone call changes rapidly, and each mobile company has their own framework for it. All in all, it becomes a really complex thing to price.
The challenge was, how do we work with this very complicated network of different providers that ultimately set the price of one thing?
When we priced and rolled out our first mobile product, we just took on the cost of sending a text message and marked it up before selling, in a very transactional one-time product sale type manner.
In creating a Stock Keeping Unit (SKU) for each one, we soon had literally hundreds of SKUs for our mobile product.
Each time, we (those of us in the marketing space) worked with an end customer. Say if a J. Crew or an Apple wanted to send international mobile messages, they would be sending them to the US, Canada, Europe, Japan, etc. Each country had a separate SKU, because there’s a different cost to do business. It really all just ended up being an SKU explosion.
While this was also just the easiest way to go and price, over time, when we started looking at the pricing, we realized that it had become very hard to manage.
It was also hard for the customers. Soon, they started coming back and asking why they should send more mobile messages to one country than another. They asked whether they could apply unused credits elsewhere. Alternatively, they asked if they could use what they are paying for - on email and apply it to mobile, since they are using the latter more. Basically, everyone was saying that it was hard to predict what they were going to send, because they couldn’t control it.
Further, they might have been able to relatively control text messages, but not responses, because there’s a cost both ways —and at two different rates! This increased the complexity. We looked at all of this and asked ourselves what would just make it easier for the customer.
We needed to make product changes in a way that we are no longer passing on the complexity to the customer. That experience of how the customer used these messages and bought them, needed to be easy. What needed to be done was the hard work behind the scenes, to ensure an easier customer experience. So, we began meeting and debating on what to do.
Finally, we came up with an idea, a world where customers who are sure they want to do a whole marketing cloud with us can pay just one price, whether they want to send an SMS, email or display message, via whatever marketing channel. Nowadays, it’s all about talking to the customer on the right channel at the right moment. This is hard to predict, especially when you bring in Artificial Intelligence (AI) that tells you when and where to send a message.
At this point, we could manage pricing wherein you just buy a bucket of messages and apply cost to every channel, depending on use. We owned email, web and display, and those had some hard costs. But mobile had many hard costs. How were we to make it really easy?
After going to the drawing board, we thought, how about when people log into our product, we aggregate all of these different countries and telephone companies for them. Customers can come into the product and pick countries. There’s a hard cost and there was full transparency involved in presenting that. They pay the hard cost directly to the aggregators and get a bill for it.
As for Oracle, we charge you the same fee for sending a message, across any channel.
What this means is that we moved the burden of hard costs that we couldn’t control. We gave full transparency to the customer, but in a really easy way so that they could see what the costs of doing business were.
Usually, complex expenses are not exposed. Customers just keep negotiating because they just see one price and don’t realize all the third-party hard costs. We needed to expose those hard costs to them, but we had to do it really easily. We couldn’t just tell them to go to all these different aggregators, because that’s not what they wanted to do. To remedy this, we built (almost) a marketplace for aggregators to come in and showcase their hard costs. Then, customers could pick whoever they wanted to work with directly, and know which bill they would get.
But then, with Oracle, they would be just paying that usage fee, like Cost Per Message (CPM), some kind of fee for any message, to be sent across any channel they wanted. The only channel that was going to have a hard cost was mobile, which is what we exposed.
Pricing elegantly is like the Holy Grail. We came up with a pricing strategy and I spoke to my product managers and engineers. Our roadmap was baked out, but we would require a re-architecture of the entire product.
So, we got a lot of pushback. That’s the hard thing with pricing, you can come up with all these great ideas, but it gets hard to actually implement and build it. So, how can you use tools to actually support that? How do you convince product management?
Over time, we were able to convince them to do it because we started taking on revenue goals. I made a case of how pricing impacts revenue directly. If we wanted to move the needle on revenue, this is how much we could bring in. I calculated all the numbers, because in pricing, you’re always doing analysis.
I detailed how much revenue we could rake in and how to make sure we’re always making a profit. I did my margin analysis and showed that we would never go in the red or lose money again. I also went and pulled data on all the different mobile deals we had sold in the past and how we lost money on them.
On the outside, things may look like really big dollar value, but there are lots of hard costs. When you looked at the discounts, we were actually paying our aggregators more than we were collecting from the customer, because the customer had no idea. They didn’t see the transparency in our high, hard costs.
In doing all of this, I got buy-in from executives to prioritize this in a roadmap. The next thing you knew, I had to get engineering resources, product managers and lead an almost scrum-like team, as a pricing owner. I had to put forth use cases and detail what we wanted to do with pricing. We were able to put it in the roadmaps and six months later, build it, launch it, and work with all the aggregators. It was almost two years in the making.
Suddenly, there was a whole new way of working with mobile aggregators. Soon, our engineers were getting patents on what they had built, because it was really novel. It was exciting and it also hit the press, making our customers more delighted because now they didn’t have to feel nickel-and-dime to buy different products piecemeal. They had to pay one price and apply it to usage of many features, versus having a different SKU for each product.
Amid all of this, we also had to figure out how to keep track of profitability.
In this aggregator network that we built, we let the customer decide. We told them the reason some costs are more than others, is due to things like connectivity and uptime. There are all these different reasons why hard costs are the way they are.
We provided full transparency, in saying if a customer wanted a certain kind of coverage or connectivity, they would be paying a certain amount. If they just wanted the cheapest price, they could decide on their own hard costs.
I ended up calling this cost per interaction. We were going cross-channel. At the end of the day, we were the platform for a bucket of interactions, however you wanted to interact with it.
That could mean sending an email or an SMS message, whatever you want, and you just paid that one fee. As a customer, that gave you full range to decide if you wanted more of any one feature. You were just buying a bucket of interactions and could control your overall usage. You just may not have been able to control your individual usage within each channel.
There were two ways to provide features to customers. In one, the customers could build their own bundles and start with base usage. So, they got the basics and could add more on top of that with different optional add-ons. Or, we could pre-package them, which a lot of companies like, because it makes things easier to just dole out a good-better-best package.
That’s probably good once you’ve got some data and understanding, or can maybe just start out with a ‘good’ package. At one of the smaller start-ups I was with, we just had one package, which we started with. Later, we introduced a more robust package because customers started growing with us. They were outgrowing what they were habituated to using and we created a bigger package to increase our Average Selling Price (ASP).
Over time, one soon realizes that they forgot about the start-ups that used to work with them after growing a lot. And then, you do a smaller package again. When your package keeps growing, you create a bigger one, and then sometimes you go backwards and create a smaller package again. I have seen this motion a lot, at both Zuora and Hired.
While all of this is a good problem, you also have to think about whether you as a business want to go after those small guys again, or keep it Enterprise. You have got to figure out where to put your resources. But one thing is for sure, something has to have that distinction between the different segments you’re serving, and it is either going to be your packaging, price points or discount strategy.
Pricing strategy is one thing, pricing operations another. For me, at least, the former is the easy part. In pricing operations, you face a lot of “no”, and “we can’t do this or that”.
This is part of the reason I joined Zuora, I was tired of people saying no. At Oracle, even for a startup, we were using Enterprise Resource Planning (ERP). This was basically built for one-time sales. You sell the product, then you mark up your margin. It works beautifully.
But now, if you want to do a percentage-base, value-based pricing, and all these different things on the fly, based on changing customer behavior, that’s going to take six months, because we’ve got to do customizations. I had to write up use case stories to make sure it got submitted, work with engineering – all in the span of six months.
It depends on what your tech stack looks like, too, and what the office of the Chief Finance Officer (CFO) is using in terms of tech stack. Are you using an ERP? It’s just going to be a lot of change orders, and there’s not going to be any flexibility in order to automate.
Or, it’s a lot of this plus spreadsheets, and certainly a lot of human error. I’m used to that as well. Working with spreadsheets, working with teams in Europe and India to go and do data analysis and have then give it back to me, it’s all about having the right tech stack.
The reason I came to Zuora was because being a subject matter expert, I am the ideal use case. I have spent my career “Frankensteining” the entire pricing process together - where I was stitching together people doing some work and manual spreadsheets, and then some customizations and change orders that I got into a Jira system. And then having to wait for six months!
I used to tell all product managers on my team that I would need six months to a year for a big pricing change. I would ask them to not even begin architecting or building a product till we talk, because if there’s usage, I need to track it and feed that back to the customer. Customers are going to get a bill based on the usage and have questions about it. You have got to make sure the contract is right.
Additionally, revenue recognition (rev rec) is huge. You don’t want to put up any rev rec flags. In fact, sometimes, rev rec is my first meeting to understand what the rules are, because that’s black and white. If you don’t get rev rec right, your entire pricing falls apart. Rev rec has to be there, in legal, contracts, billing, quoting, you name it.
Any pricing practitioner needs something like Zuora to own their pricing catalog, which is why I joined the company. In fact, we have a Configure-Price-Quote (CPQ) product that’s really simple, right out of the box, and helps 90 percent of customers with their needs, very easy CPQ that manages your entire pricing catalog.
It helps if you want to change from a fixed annual fee to a usage based one, or if you want to deal with different tiers and different currencies without managing foreign exchange (FX), finance and different SKUs for different currencies. It is all out of the box and just puts out your bill in an automated manner.
So, you’ve got your Customer Relationship Management (CRM), and then you’ve got Zuora for all of your recurring revenue pricing strategies and subscription lifecycle management.
If your customer wants to pause your subscription, you’ve got to use Zuora. That makes your ERP basically your general ledger. Zuora creates the general ledger, because it takes all the recurring revenue and is doing all rev rec in real time, and then inputs it into your ERP. This is because Zuora can handle usage data, payments and tax with all its partners. In fact, pretty soon, it can bring in your one-time revenue into the same bill as well.
CPQ is just where you begin. That’s just your salesperson coming in to build a quote. It’s a way for you to put your pricing in front of a sales team. But that should not be the first thing you’re looking for.
The first thing to do pricing right is really finding a recurring revenue platform that can handle all these iterations and flexibility. That’s what we need. Because when you’re thinking about value-based pricing and making sure that we’re pricing according to what our customers find value in and building that recurring relationship, it has many different touch points. If customers change their mind, we need to change pricing.
For instance, the competitor gives that feature away for free; we want to bundle it. I need to make those changes in real time and be able to capture that usage and manage the whole life cycle. So, you need to start with something like Zuora, which already has CPQ and is going to satisfy most of your use cases. If you’re an enterprise company with very complex CPQ use cases, there are lots of different CPQ vendors that actually integrate with Zuora.
CPQ is just the exterior sales productivity tool that takes their inputs. These inputs aren’t tied to a platform that’s managing them correctly, or that eventually puts out to your general ledger automatically for finance, and for your auditing or financial purposes. That whole middle mess is yours to own, and it has been a recurring nightmare for me. I have literally sat with my controller, who would have all these spreadsheets about it. I would be told of difficulties each time I make a pricing change. But my answer was always that if we wanted to grow Annual Recurring Revenue (ARR), we needed these pricing changes.
I got to hear “no” so much. But a business will never grow the way we want to, unless we can do these pricing changes, you need that agility and flexibility. You have to make sure you have the right platform and then you tack on your CPQ.
Now, when we have a go-to-market meeting, I work on pricing strategy with product managers and come in with it, even at Zuora. Thereafter, we could talk about operations. And then in one meeting with our entire go-to-market team, because we use our own product, we have solved it all — from quote all the way down to rev rec. This is because we are all on one tool now, with all those cross-functional partners. And then, my work is done.