>> Join Pricing Discussions in our Community
Prefer to read? Here's the full transcript.
Sara: Hi, I’m Sara from Stigg. And today we’re talking about how Pleo build a 100% flexible pricing and packaging infrastructure. Pricing is one of the most effective growth levers of a SaaS business. Nailing it though is not just ‘set and forget’. Your customers’ willingness to pay changes by the product offerings, the markets, the competition, … In order to effectively hit, expand, and retain your customer base, you need to continuously monitor and update your pricing.
Most companies that I know have a long list of ideas on how to improve their pricing strategy, but most of these ideas remain in the end ideas. These projects are quickly deprioritized due to the huge operational impact and the amount of resources they require. Pleo, a business spending solution, has achieved a SaaS stream: Being able to do fast and frequent pricing changes. And today I’m talking to Arnon. Hi, Arnon.
Arnon Shimoni: Hello.
Sara: You’re senior product manager at Pleo, and not only responsible for Pleo’s billing and revenue infrastructure, you’ve also built an entire entitlement infrastructure from scratch.
Arnon Shimoni: Yeah.
Sara: I want to hear everything about that.
Arnon Shimoni: All right. So, where should I start?
Sara: Let’s start with the definition. What are entitlements?
Arnon Shimoni: All right. So, there might be some pedantic definition. I don’t really care about the specific dictionary definition. For me, an entitlement is something that a user or a customer can access. It might have a limit attached to it. For example, you might say, “On Netflix, you can watch up to 10 movies a day.” That might be an entitlement. Spotify, for example, you might have access to the higher quality recordings, right? That would be an entitlement.
And then, entitlement could also be just access to a product in general. So, you could have a free product where the entitlement is just on by default, anyone can access it, or you might want to gate the access to your product behind a payment. And that would be an entitlement.
Sara: All right.
Arnon Shimoni: I hope that made sense. I haven’t really… there’s probably a dictionary definition, but I think it will change depending on which industry, which product you’re talking about. And entitlements can be a lot of different things.
Sara: No, I think actually that was a great definition. What you find in textbooks is usually more technical, right? You use Netflix, Spotify, things that people can relate to. Now that we built the base for our talk, can you take us back to the moment that you guys decided to build your own entitlement infrastructure?
Arnon Shimoni: Yeah. Okay. So, I didn’t really… I wasn’t doing tons of research and then I thought, “Oh, we should do this.” I just, something about having the entitlement to our product being tied very tightly to the billing, that just felt wrong. It felt very old fashioned. I think in the old days you would buy a product, right? So, you would maybe get a purchase order and you would hand that in, you would get an invoice, you would pay and then you would get… your entitlement would start. You would get access to the product after you had paid the invoice. And I think that works for some products.
It might work particularly in enterprise, but we need a little bit more of an immediate feedback loop. I’ll give you an example of what I mean. We would have customers who would want to upgrade their plan from a low tier to a higher tier. And the way that our billing system worked at the time is it would batch those overnight because we didn’t want to make frequent changes during the day. And so, then customers had to wait overnight to get the new features.
I just felt that was a pretty bad experience. So, what I said was, “Let’s separate those two. We can give customers the better experience. We can give them the added features immediately, and we can update the billing later. We don’t have to tie those two together.” And that was the original idea. Just to say, “Let us… give us the ability to control what our customers see and feel in a product without having to update a different downstream system,” in this case, billing.
That is no longer the case. We don’t do those batched updates anymore, but at the same time, we also really wanted the ability to do more. And as we were thinking about this, this problem, I wasn’t doing it myself. I have a team of engineers. We were thinking about this problem. We said, “Oh, we could actually really play around with not just pricing but with also feature entitlements.”
We could see different markets with different features. They don’t have to be tied to the plan. So, the same plan, which we would, let’s say, call, our gold plan, could have different features in different regions. And that’s why we decided to build this as an entire entitlement service, really.
Sara: Wow. Arnon, you’ve mentioned a ton of things that I want to talk with you about in this chat. Let’s do it step by step. So, this whole idea started actually from trying to make your customers’ experience better, correct?
Arnon Shimoni: Yeah. So, it started from the… yeah. We were thinking about customers primarily.
Sara: And now it’s one of Pleo’s growth tools. Amazing. You even wrote about this on your blog, right?
Arnon Shimoni: Yeah.
Sara: Why do you think SaaS companies should have their own entitlement infrastructure?
Arnon Shimoni: So, I’m not sure it’s for everyone. I said at the beginning, for some enterprises, it might not make sense. Sometimes you just have one product, and that’s what you sell. And that’s perfectly fine. It might not make sense if the company is very small as well. And small can mean different things. It could be five customers. It could be 10,000, right? It really depends on your industry.
And you need to know that for yourself. But what I would suggest is, “Do you think about where you might want to take it?” If you’re operating in with one very, very uniform type of customer, very uniform persona in one region, then you may not need to do this ever. You might only offer good-better-best pricing, and then you can tie it. And it’s fine.
But if you are looking to expand into new territories, new geographies where the features might not make sense anymore, you might have features that are very region-based, then you might want to start thinking about this. But also, if you’re thinking about different personas and different company types, different, what you would call verticals or industries, right, each of those might have a different set of requirements.
And you see this, by the way, really well with airlines. I would actually say that airlines have broken apart the entitlements, right? If you buy a plane ticket today, you have everything decoupled. You can book your seat separately. You can pay for that separately, right? And each seat might have a different price. You can decide if you want to bring in one bag, two bags, three bags. If you want to bring in a cabin bag, right? All those are like decoupled entitlements. And I think it’s not right for everyone. So, you really need to know your industry and where you want to take it in order to decide if you should separate it.
I would say separate it from the start and just make your life easy and just separate it from the start. But I realize that may not be a worthwhile investment for everyone.
Sara: Okay. So, you say the business life cycle is one part. What about a company’s go-to-market strategy, if they’re choosing a top-down sales or a bottom-up product-led-growth strategy?
Arnon Shimoni: I mean, probably, yeah. It’s really hard to say, right? Because customers have different expectations in different markets.
Sara: Right.
Arnon Shimoni: I think if you’re operating in like the SaaS cloud, whatever world, you want immediate feedback and you want those immediate changes. And in that case, I think it’s worth separating. If you’re operating with a much longer process where it might take you three, four, five months to upgrade the software in a customer’s data center or something like that, I think it may not make sense in that case. You still might want to do it, but it would really depend on the business model. And I think you are correct. It does depend on the go-to-market strategy.
Sara: So, you say, for every company it’s different, …
Arnon Shimoni: I know that’s a really unsatisfying answer, right? You want to say, “No, this is right for everyone.” But like I said, I think I mentioned this, we spoke about this a little bit earlier, we said, “It’s like an art. It’s not a science. There’s no one size fits all. There’s no one solution that would work for everyone.” Or maybe there is, maybe there will be, right? Because I know Stigg is working on something. I’m really excited to see where you end up with that, but-
Sara: I’m glad you do the promotion for us. ;)
Arnon Shimoni: Yeah. No, it’s not about that, right? But I really do think it’s a really interesting problem to solve. If you can formulate it into, for example, “Here are four common patterns which companies might want to apply to their pricing, to their entitlement strategy, to how they build their product,” I think that might be really, really compelling.
Sara: Interesting. Might be very useful for companies that are just getting started, like a quick start to your pricing strategy. Because you’ve mentioned it yourself, pricing is an art, not just a copy-paste from your competitors and that’s where it stops, right? I think that’s the issue. The products and the markets are dynamic, but pricing often stays static.
Arnon Shimoni: Yeah. Pricing is really interesting because it’s the first thing that customers really look at, I think. When they go to the homepage, right, one of the most common routes to go is the pricing page, because you want to understand, “What am I getting for a price?” It’s not that so much that they care if it’s €8 per month or €9 per month or €16, they want to understand what they get. So, a lot of pricing pages actually include entitlements on that page, right? You have like the check mark saying, “This feature is included. This feature is included.
One of the most common routes to go is the pricing page, because you want to understand, “What am I getting for a price?” It’s not that so much that they care if it’s €8 per month or €9 per month or €16, they want to understand what they get. So, a lot of pricing pages actually include entitlements on that page.
This feature is not included, but you’ll find it in our more expensive enterprise product,” or something like that. You will see those things. So, I think pricing and entitlements drive a lot of decision-making for people, even if it’s not the decision being taken at the exact point. It’s just to give an understanding of what the company is trying to do. And I think by looking at a company’s pricing and the entitlements that they include with those prices, you can learn a lot about their strategy, about what they care about and really who they’re targeting.
If a product is really, really cheap or entirely free, you can understand which segment they’re going after. Whereas, if a product is very expensive, you understand, “Okay, they’re probably going for the enterprise market or companies with very deep pockets.” Right? You can learn a lot by looking at a company’s pricing, just the pricing page, really.
Sara: Yeah, absolutely. The pricing page is part of the company’s business card in a way. And it also makes sense that it’s one of the top-visited pages on a website. I always check the pricing page before I go deeper into a tool. It’s my way of figuring out if it’s relevant for me, this product or service, right? If I’m just looking to get my feet wet, I might not need the most expensive product — and the other way around.
Let’s go back again to the infrastructure that you’ve built for Pleo, from the moment that you’ve pitched until you’ve launched the infrastructure, how much time do you estimate this project took you?
Arnon Shimoni: All right. So, I think we were about five engineers, maybe four engineers at the time. It wasn’t a very big team. I think we talked about it for a while. It wasn’t a really hard sell. I was actually expecting, I would tell them I want to separate entitlements from billing. First of all, the question was, “Of course, what are entitlements? Why do we need to do this?” That’s my job as a product manager to explain the context to engineers and sell them on the idea.
I’m not telling them how to do it. I’m not telling them, “Oh, we should build a REST API on the blockchain, whatever.” I’m not going into those details. And I don’t… it was actually not a very hard sell. I brought it up on one of our Friday… we call these unstructured meetings where we just sit down for 45 minutes, brainstorm, talk about ideas. We have those every other week. I brought it up in one of the meetings and they were like, “All right, let’s go for it.”
Sara: Right.
Arnon Shimoni: I think two weeks later, we already had a prototype up and running. It wasn’t fully functional yet. It could just about store a bunch of entitlements, but it wasn’t really useful for us yet. And I think it took maybe three or four extra weeks. So, about a month and a half from when we started working on it until we had something that was actually live and supporting some of our business decisions. So, when you would go into the app, it would check, “Do you have entitlements for these features, yes or no?” But it wasn’t as fine grained yet.
We took an iterative approach where we said, “Okay, the first entitlements that we’re going to focus on is just how many users are allowed on this specific plan for this specific company. And do they have access to the product, yes or no?” That’s pretty much what we started with. And then, we started adding all these features one by one as it was necessary. One of the things I actually found really challenging about building this was, I didn’t know how to set good success metrics for understanding if this was the right thing to do or not.
Because I was thinking, “Okay, I can measure like, are all the other components in our tech stack using this platform? Are they making API calls?” But it felt wrong. I didn’t really know how to measure success for this. And I think that’s actually part of the reason I was a little bit reluctant to talk about it with my stakeholders, because they didn’t really understand what we were doing. I told them we were doing this and they were like, “Okay, cool. Nice. You do you. We trust you. You do what you need to do.”
But it was really hard for me to explain how massive this could be for us. And actually, the first time that someone understood this, it was from our market expansion team. So, we have a market expansion team which is designed to go-to-market in different regions. And they said, the product manager in charge of that group at some point says, “This is the market expansion dream.
I can actually control for each region.” Even within a region, like for example, in Belgium, we might have two different entitlements because you have a Wallonia and Flanders. They have different requirements. We could control that on that level. And I think that actually got them really excited about that, to the point where they formed an entitlement team that uses my infrastructure. So, it’s still my infrastructure, but they control how it’s used.
And they actually promote the use within the product. So, going back to your original question, it took about a month and a half to build, a little bit longer to get this feature involved in all of the components. And probably four months after we started, we started an entitlements team.
Sara: Wow. That’s impressive. So, within half year, you’ve built an entire new team based on your infrastructure. Once the market expansion team came into the equation, I can imagine that changed the initial requirements quite a bit, no?
Arnon Shimoni: 100%. Yeah. And so, we didn’t actually have to redo the system. The system was built in a flexible way, so we didn’t have to redo it or anything, but we’re constantly adding little bits of more entitlements to it and more edge… not edge cases but scenarios where we might do what we call an override. So, some company might have an override where they get a feature that they’re not traditionally eligible for because they’re not in the right market or they’re not on the right payment plan. So, we have a bunch of those.
But more than that, it just shifted the focus of this component from being something that we designed in order to just give customers a better experience to something that actually enables business for the company where it means that we can launch a new market in a matter of, let’s say a day. In terms of technical work, it takes us a day to launch a new market.
And I’m being a little bit generous here. It takes a lot less, but let’s say a day, including time for all the testing. And it wasn’t the case before, it would take a lot longer, probably a couple of weeks. We don’t have to deploy code anymore. We have this component up and running. We tell it, “We’re launching in country X tomorrow or next week.” We can schedule that. And then, we don’t have to touch it anymore.
Sara: And today, is your team still getting new requirements or add capabilities to this infrastructure?
Arnon Shimoni: So, right now we’re not expanding the entitlements infrastructure anymore because that just works. Like I said, we haven’t had to touch it in a fairly long time, actually. It just does what we need. What we’re doing is, we are experimenting with pricing and we’re doing lots of little changes. Some of these are market specific. Some of these are just to change some models to make the product more in tune with what the market requires from us.
So, that’s probably the thing that we were working on the most right now. And that’s hard. Pricing is hard.
Sara: Pricing is…
Arnon Shimoni: Yeah. Luckily, I’m not the decision-maker on the pricing. I don’t want to be the decision-maker on the pricing. I have to be honest. I think we said, “It’s an art. And with art, it can be wrong as well because it’s not a science, right?”
Sara: Correct.
Arnon Shimoni: And it could… I think it’s really difficult to get pricing right, so you have to do lots of little tweaks. And that’s what my team supports. We support those little tweaks, little changes. We will probably do a big overhaul of pricing about once a year, where we change everything pretty much. And then, we will do little tweaks as we learn how things go.
Pricing is an art. And with art, as opposed to science, it can be wrong also. It’s really difficult to get pricing right, so you have to do lots of little tweaks.
Learnings From Introducing a Freemium Experience
Sara: So, let’s talk more about pricing strategy and how you do it at Pleo. You’ve mentioned you do one big pricing change per year. On your pricing page, there is a new tag on the free plan. Was that one of those big changes that you mentioned?
Arnon Shimoni: Yeah, that was pretty big. We did that early last year. We had a… one of our cheapest tiers, we just changed it to be free. We didn’t change the offering on that tier at all. We just made it free. And I have to admit personally, I’m a little bit afraid of making things free because in my mind, if there’s a value to a product, it doesn’t matter if it costs a little bit or not, but I’m wrong.
I was wrong about that, right? A lot of people love the free offering and I was actually afraid it would cannibalize things, but it really didn’t. It just got a lot more people onto the platform and using, and actually enjoying the product, which that’s the end goal, right? That’s what we all want. We all want our product to be widely used and loved and appreciated. And a lot of companies upgrade from that. So, it’s not like this is canceling everything else.
It’s just another piece in how you, as you say, go-to-market, and it’s a type of… it’s almost like a marketing strategy, right? This free tier. It’s a way to get people in. And this free tier could be perfect for them, and then they never need to upgrade. And that’s perfectly fine. It doesn’t really cost us a whole lot to offer this to them either. It costs a few database centuries and yeah, we do have some things that we might send to them. We have cards, like plastic payment cards, which we would send to them that does cost us money.
But I think that’s negligible if they actually use the product and they like it, and they can distribute it, right? When you have a customer that’s happy, the word of mouth of a happy customer is worth more than the price you would be charging them, really, I feel.
When you have a customer that’s happy, the word of mouth of a happy customer is worth more than the price you would be charging them.
Sara: 100%. I think there’s no better marketing than word of mouth. Also thinking of myself, I’d much rather consider a solution someone I know suggests to me than a company that is trying to sell their services or their product. It’s a trusted source. It’s based on probably a positive user experience, believable, most likely relevant to me because the person knows me. Free is a really interesting go-to-market strategy. It’s allowing someone to try a product or service without entering a bigger financial commitment. Plus, everybody loves free stuff.
Who doesn’t love free stuff? Also, there’s an interesting psychological effect. We use a price to estimate the value of a product. Discounted or cheap prices can affect the perceived value I get, but free doesn’t have a number to it.
Arnon Shimoni: It’s phenomenally effective, right? Like I said, I’m not too happy with free as a concept because I don’t like the fact that it works that way. Right? It shouldn’t work that way. But then, it just does. So, why fight it, right?
Sara: Why fight it. Was that the first time you’ve introduced a freemium experience in Pleo?
Arnon Shimoni: Yeah. And of course, we learned a lot from doing that. And I think the way we started when we launched free in just one market and we saw how it played out, we didn’t move anyone to this free tier. We volunteered. Right? We said, “It is now free. Would you like to get the same experience for free?” And by the way, not everyone did. I think we did the launch in Germany if I recall correctly. And I think we had something like 40 or 50 customers who did not want to move to the free tier, even though it made no difference to them.
They wanted to keep paying. So, we had to find a solution for these customers, which was to move them to a more expensive plan with a discount so that it looks like the current, so that they’re still paying the same amount. But yeah, it was weird. I have to admit, I wasn’t expecting that. I thought everyone would not want to pay if we can give them the option to. But, you know, some people…
Sara: Very interesting.
Arnon Shimoni: You get all kinds, right?
Sara: Did you get any feedback as to why they didn’t move plans?
Arnon Shimoni: There was some feedback. I don’t remember it, but there’s something to be said about having a very reliable, consistent invoice coming in every month. I think there’s something to do with a commitment, right? When you’re paying for something, you feel, “Okay, this company is now committed to me as well because I’m paying them.” Right? I think it might have something to do with that. There’s some reassuring thing where you say, “Okay, I’m paying for this. I will get good service because I’m paying for this.” And I understand that. That I can actually get behind.
Sara: Yeah, definitely. Me too, definitely understandable. So, when you introduced freemium last year, you introduced a completely new pricing model in your strategy. Looking back, which departments or which team members had to be involved when rolling this change out? Usually, such a massive change means all hand on deck, no?
Arnon Shimoni: Yeah, it’s everyone. So yeah, marketing is big, when you’re doing new pricing, you want to shout it to the world, “Hey, we’re doing something new, something exciting. There’s a change coming.” So, marketing is of course big. I think for a lot of people in sales, account executives and customer support, they were actually a little bit afraid of what this free plan would mean. Sales people of course are worried that they won’t be able to sell if there’s a free tier.
But I think once you think about it a little bit differently, you say, “Okay, the free tier is actually your way in.” You don’t have to schedule a… you don’t necessarily have to schedule a demo. You don’t have to tell them about all the great things. They can just try it for themselves. And once they try it, they can either decide to stay on free and then no further action needed, or you could upsell them. Right?
And an upsell motion is very different from the traditional selling motion where you’re just like cold calling someone and asking them, “Hey, I want to show you my product. Let’s schedule a time. I’ll bring in the suitcase with all the product features.” It’s very different, right? And it’s very different from the marketing perspective as well, because it really drives down the cost per lead. So, it changes everything. You also have to change what you consider a customer.
Because before, when we had paying customers only, it would be very easy to see when a customer was using. Because once they stopped paying, they’ve stopped using. With free, you don’t really have that. And then, you have to understand how do you push customers to use the product again, in case they’ve stopped. And you can’t see that from just the billing or just the invoices anymore. You have to start tracking a lot more things.
Luckily, the company already had all that in place. So, it wasn’t like a massive change, but it was still something we had to think about to say, “Okay, how do we know if a company is churning? What are the risk triggers?” That changed a lot of the perspective.
Sara: Many things to take into account. Did you see a change in your churn rate?
Arnon Shimoni: Not really actually. Well, a little bit. So, for a lot of companies, instead of just shutting down their account, we could tell them, “Hey, move to free for a while. If you don’t need it, then just shut it down eventually, but you don’t have to shut down your account now. You can downgrade to the free plan and you can come back whenever you want and upgrade again.”
So, I think that does affect the, what you… in terms of finances, it’s still churned because you’ve lost your recurring revenue. It went from, let’s say, €50 to €0 because they’ve gone from paying to not paying. But from a customer perspective, they haven’t churned. They haven’t completely abandoned your product. So, it depends what we call churn. There’s, of course, multiple definitions, and everyone has their own opinion on what constitutes churn.
Examples of Pricing Changes You Can Run Right Now
Sara: Pricing changes is a pretty loaded term. It’s often associated with a big change in strategy like you at Pleo introducing a freemium model for the first time, or we think of a big jump in the price, … But pricing changes can also be small tweaks or not at all connected to the actual price on the plan. Can you share a few examples of pricing iterations at Pleo?
Arnon Shimoni: Yeah. So, an example of a pricing iteration could be, as you say, a massive thing where you just rip out all your prices and you put in new prices. Let’s say, you had good-better-best, like, three different product tiers. You might go to four. You might add a fourth or a fifth. That could be a pricing iteration, right? Another change is you might say, “Okay, we no longer allow this feature in this tier. We’re going to… that’s going to be a paid feature. You might have to pay per use.”
That could be a pricing iteration where you’re only monetizing one additional feature. A pricing iteration might be you’re slashing prices or you’re doubling prices. Right? All of those would be, I would call those pricing iterations. For us, we’re always… we’re launching new features all the time I think every time we launch a new feature, which could almost be considered its own product. So, when I say feature, I don’t mean like one team working on a small change.
I’m talking about a big project, something that one or two or three product teams worked on for a few months to get it up and running. Every time we launch one of those, I think we have to reconsider our pricing because we’ve added value, or we hope we’ve added value, right? And we need to test that. So, we might want to launch that feature without charging anything for it.
We just include it on all the plans. You just see how it plays out. But once it reaches a certain stage of adoption, we have to consider, “Are we going to monetize this? Is this something that’s like, it’s so core to our experience that we wouldn’t want to monetize it, that it’s just included with everything? Or is this something that only a specific industry would be interested in?”
And there’s this little play here, because on the one hand, you want to deliver the most value to customers. But on the other hand, you’re working for a company that’s trying to make money, of course. Otherwise, you’re not going to be in business for very long. The VC money can only hold you for so long, right? So, you need to monetize it. You need to be able to charge for it, especially if it costs you money to develop, or if it’s costing you money to support.
There’s this little play here, because, on the one hand, you want to deliver the most value to customers. But on the other hand, you’re working for a company that’s trying to make money, or you’re not going to be in business for very long. So, you need to monetize it. You need to be able to charge for it, especially if it costs you money to develop, or if it’s costing you money to support.
So, you always have to be on top of things. You always have to understand, “How much did you invest in this? How much are you investing in it in the long run? And what is a reasonable… what is the value of this for customers?” Because I think if there’s a feature that has value, then customers will pay for it. We’re not talking about charging hundreds of thousands of dollars for a small feature, but it might make sense to say, “The first five every month are free.” Make a feature up. “The first five uses of this feature are free per month.
After that, we’re going to charge you money because it costs us money to operate this feature.” So, I think we have to constantly be looking at those, and that’s just our own product, just our own platform on an island, but we’re not alone. Especially in the SaaS world, you have hundreds of different competitors often. You have different competitors in different markets, and they’re all doing different things. And you have to constantly be looking at what they’re doing, because maybe they’ve come up with a really fantastic pricing plan and they’re going to conquer the entire region from you.
And you will lose out because your pricing is no longer attractive compared to that other product. So, it’s not just about the absolute value. It’s also about the relative value, because if someone else is providing value and charges differently in a way that’s more palatable to a customer, they will win. So, it’s really, really important to be on that 100% of the time. And luckily, I don’t have to do that personally. We have a CRO, and he’s got a dedicated team working on that.
It’s not just about the absolute value. It’s also about the relative value. Because if someone else is providing value and charges differently in a way that’s more palatable to a customer, they will win. So, it’s really, really important to be on that 100% of the time.
So, they’re doing a tremendous job at not just planning and understanding what everyone else is doing, but also with designing our own pricing strategy. So, that was a very long monologue about, you have to be constantly… like you have to be vigilant. You have to always look at your own product and at other products.
Sara: Wow, Arnon, that could be a beautiful, tl;dr summary of our conversation today.
Arnon Shimoni: Long monologues?
Sara: No. (laughs). So, I fully agree, a successful pricing strategy cannot be built in its own little bubble. It has to survive in a dynamic market. So, it has to be taken into account.
Now, a topic for a potentially heated conversation, who should own pricing in a company? And I guess we want to look at that more granularly, taking factors like business cycle, business life cycle and company size into account. What’s your take?
Arnon Shimoni: Yeah, that’s a really hard question, right? I guess it depends where the competencies are, because pricing is everything. As we said, it’s a go-to-market strategy. It tells you a lot about the vision of the company who you’re directing it to. It tells you a lot about how you value yourself as well, how you see your features, how well you think you can compete with other products and the other offerings on the market. So, it has to be a combination.
And I think it’s worth having almost like… I mean, in the end, most companies have a board and they will want to decide what the revenue looks like for the next year. So, pricing has to report to the board to some degree. You have to get an approval to… you’re saying, “I’m launching a free tier. I’m going to slash my revenue targets this year because of that.” The board will definitely want to know about that, right? So, it has to be a relatively high up function. You will need executive sponsorship from the leadership of the company to do this.
So, it’s worth having like a core group, which is relatively high level and has visibility into where the company is going, what are the north star metrics for the company for the next two, three years, what are the profitability goals, what is the market, what does the marketing look like? Right. So, you need someone who spans those different areas in the company. But then, the people who actually do it, they don’t need to be in that group.
They don’t need to be that high level. In the end, the people who are actually deploying the pricing changes at Pleo are engineers. And they’re not C-levels, they’re not reporting to the board directly. So, at least at Pleo, we have our CRO who’s managing this process, and everyone’s involved. We have product marketing involved, we have marketing, we have sales operations. Everyone is involved in making sure that what we’re doing makes sense. There’s an important topic that we didn’t touch on until now in this conversation.
And that’s, how do you even issue a quote or a contract because not everyone is working on a pay-as-you-go approach. Sometimes you want a customer to commit to you to a year, and sometimes you’re willing to give them professional services. You might be doing some special integrations for them. You might be developing custom features even. In that case, you might want to contract. That needs to play into that as well. So, how you, what we call, configure price and quote, a deal is massively important as well. So, if you have sales operations, so you have this RevOps group, that group also needs to be involved.
It might not be the deciding group on the pricing, but it definitely needs to be consulted. So, I think in the end, to recap, you need someone who’s responsible. And I would put that on a person who’s very, very high ranking in the company. And then, you can have different groups, consulting and advising. And in the end, you have someone who’s responsible for actually making the change. And that would probably be engineers or a product team, or a few product teams.
Sara: And in Pleo, rolling out those pricing changes, that’s where your infrastructure plays a big part, right?
Arnon Shimoni: Among others, yeah. You need to think about more things. Because if, for example, if you add a new feature, you might want to gate that feature, right? You don’t want everyone to be able to access it, but you still want to plan a way for a user to upgrade, to access that feature. So, you might need to plan upgrade and downgrade paths. For example, if they stop paying, how do you stop access to that feature? Do you just cut it off entirely?
What if there are a few pending operations within that feature. You still need to plan how you’re going to stop those from happening, or if you’re going to let them continue and just weigh off naturally. So, it involves everyone. It involves product designers and product teams and their own product and features and different components. It’ll end up being everyone. Pricing affects everyone in the company.
Pricing affects everyone in the company.
Sara: Okay. So, you say someone high level needs to be in charge, but everybody’s going to be involved.
Arnon Shimoni: I hope that made sense. It made sense in my head.
Sara: It makes total sense. I think this also touches the common misconception that pricing is the pricing page on the website. That’s just the tip of the iceberg. Rolling out pricing changes affects, as you say, the product, access controls, updates to your CRM, to your billing. So many things to take into account that need to be updated, that are so much more than the pricing page on the website. Customer portals, if you have, the whole notifications…
Arnon Shimoni: Legal. You sometimes have to change your terms and conditions when you make a modification like that. Sometimes you need to alert customers three months in advance if you’re going to change a feature on them. Right? So, there’s legal implications. Yeah, there’s implications everywhere. So, that’s why I’m saying, everyone needs to be involved in this.
Sara: Bottom line, several teams you want to bring in when deciding on a pricing change.
Arnon Shimoni: Yeah. You still want an executive driver though.
Sara: Yeah, with someone in charge.
Arnon Shimoni: You want someone with a vision to drive it and then people executing.
Sara: Great. So, we’ve got our team together.
Let’s say someone in the audience right now follows our conversation. They haven’t done any pricing iterations yet, still have their initial model, but now they want to get started testing and tweaking their pricing strategy. What do you suggest? Where should they get started? What do they need to think about?
Arnon Shimoni: Yeah. So, it depends who’s asking, right? If it’s an engineer asking-
Sara: Very true.
Arnon Shimoni: … then you just need to know, right, you need to know if that is even possible with your system. That’s a very basic… it’s a heavy question, but it’s easy to understand. The higher up you are, the more you need to understand that everything will have to change every time you make it. Not everything, but everyone is affected when you make an iteration. So, as you say, changing it on the website is just the tip of the iceberg. You need to make sure everything matches up with that. And it’s very easy for us.
If you look at some websites, it’ll tell you, “Oh, to change a feature, you just drag it from here to there. And everything changes.” It’s never that simple. It’s only that simple if you plan for that ahead of time, which most companies have not. So, getting started with pricing iterations means you need to understand what parts will be affected when you make that change. If you’re just changing the pricing, like from €6 to €5, probably not that much needs to change.
But if you’re changing the composition of a package, if you’re changing how you charge, if you’re going from like a, let’s say, a seat-based to usage-based, that’s a massive change. You need to make sure that you’ve got all the metrics that you can track. You need to understand what will happen if someone complains, right? You need to think about the after-sale as well. Let’s say you’ve made the change. You started building customers in a new way, and they complain now, what are you going to do? What’s your action plan there.
You at least have to think about it. You don’t necessarily have to plan everything well in advance, but just think about it and just know you have something that you can do. I would say in the end, it’s not that scary. There are a lot of moving parts to this, yes, but it’s not that scary. And the more you do it, the more you build that muscle and you will be able to do it more frequently. So, the first one is going to be hard, 100%. Any change you make is going to be hard. There’s going to be a lot of things that break, but you will be so much better off by learning what those things are and you will be able to make more iterations.
So, the first thing is probably start small, start with something relatively minor, something that you’re okay with being proven wrong about. Like, let’s say, I think for us, the free tier was mostly an experiment. That’s why we started in Germany, specifically in one market. We were okay to be proven wrong about it. We went into it not knowing if it would work. And we said, “If it doesn’t work, we can always just go back to what we had before. Not a big deal. And we will have learned from that.”
So, that would be my suggestion. Start small, understand that things will break and things will fail, and be prepared to learn from that. The lessons you learn from these things are the most valuable thing you can pick up because you don’t know how your product will react. You don’t know how your customers will react to changes. And it’s impossible to say without running those little experiments.
Start small, understand that things will break and things will fail, and be prepared to learn from that. The lessons you learn from these things are the most valuable thing you can pick up because you don’t know how your product will react. You don’t know how your customers will react to changes. And it’s impossible to say without running those little experiments.
Sara: All right, last question, for the engineers in our audience, what are key challenges or learnings that you can share with somebody who is thinking of building their own entitlement infrastructure?
Arnon Shimoni: That’s hard to say. For us, our billing system is rather complex. It’s built up of at least two components that I will mention. One of them is our own internal billing system and the other one is Stripe. So, we use Stripe as an external billing scheduler. We have already augmented Stripe with additional capabilities. So, we can pretty much do anything that the business requires us to do. We can invent new hybrid billing models that only update quantities every fifth day and multiple… we can do all these kinds of math things outside of Stripe.
But I think for a lot of companies, they will probably just use Stripe or Chargebee, or I don’t know, Zuora. There’s a whole bunch of different kind of billing products. They will use them a lot more in a maybe stock configuration without having built a lot of business logic on the outside. In which case, I would suggest you stick to what those products have to offer. And don’t try to do something too crazy. The reason is, those products have already boiled down most models into a relatively small subset of predictable, easy-to-understand pricing models.
I would say stick to those. As you know, the business will always have an appetite to do weird hybrids and weird things. And as engineers, that hurts because then you have to build all that logic outside. And if you’re doing that for the first time, that will be exceptionally painful. So, I would say, as engineers, you should push back on those things and try to urge companies or the company leadership, or whoever’s deciding on the pricing to go for the basics.
There’s like, let’s say Stripe has four or five different models. You should be able to come up and say, “What you’re asking for is like this, what if we made a small change and made it exactly like this?” And I think that makes it a lot more… it means you can go to market faster with those pricing iterations, with those changes. And it means you’ll have less work to support it in the long run. So, I would strongly urge you to understand what models your billing system supports and offer one of those.
