Pricing Without Confusion: Creating Clear Software Pricing

Pricing Without Confusion: Bringing Clarity and Confidence to Your Customers
[Speaker 2]
Hey everybody, welcome to this episode of the podcast. Today we’re going to be talking a little
bit about how to create clarity and confidence in your pricing and try not to confuse your
customers. And we’ve got with us today, Chris Mealy, who’s going to kind of have some advice
and information around this.
So Chris, maybe start off with a bit of an introduction of yourself.
[Speaker 1]
Well, thanks for having me, Tim. I didn’t always maybe run software pricing partners. I was
actually a former customer in 08 and we were moving from on-prem to the cloud and terribly
confused at the time.
And so that was my entree, having spent millions on product to realize when a board member
said, well, how much did you spend on kind of the science of how to extract revenue from the
product that we’ve all invested so much money in? And I had to have a little bit of an awkward
answer, which was, I didn’t have an answer, reached out, found software pricing partners and
one thing led to another. When I exited that, I ended up here and that was 15 years ago.
And so I spend my day job dealing with executives that are in high performing companies
trying to get clarity and transparency around their pricing. And it’s often very complicated in
the world that they’ve created and lived in.
[Speaker 2]
Awesome. So maybe that’s a good place to start, right? Why is it so tough to try to create some
good clarity in your pricing and what are the challenges behind that?
[Speaker 1]
Well, I think if you were to maybe look a little bit on the evolution of the software company, at
least in my case, it was bootstrapped. We would spend all of our time and energy on product.
The focus back then was on product market fit.
And arguably, I don’t think what we call product market profitability fit really kind of settled in
until the late 2022. Back when everybody was growing, it didn’t really matter if you were losing
money or not as profitable like growth. That’s all there was.
In fact, I would tell you, even when I was on the phone with folks that needed help with their
pricing, if they were growing like mad, you weren’t getting in on that deal. You just couldn’t get
their attention. And the risk of upsetting the boat, I think, outweighed the potential gains that
you could get.
Pricing, believe it or not, is a pretty new thing from a discipline perspective. Most software
companies have not ever gone through a formal pricing engagement. If they have, you can
count them on one hand, maybe on two fingers.
And it is not a skill inside the organization. In fact, very rarely do we see pricing teams, except in
larger organizations. And even then, when you see a pricing team, it’s like one guy in a food
truck.
You know, it’s just like he’s being asked to do everything. And ultimately, that devolves down
into a bit of a deal desk-like role rather than a traditional pricing role. I think that’s one of the
frustrations with pricing professionals.
Things have gotten very complicated on the innovation front. We have a lot more products, a
lot broader portfolios. As we learned throughout the years, you and I might have said, hey, we
have this older software, we’ll start on a user basis.
Then you and I spartaned up and said, well, we have this second component, so why don’t we
do some usage-based example? And everybody else had a flavor of that. So if you imagined in a
multi-product like Play, we might have, and many of our customers do have, 12, 15 different
ways in which they license the technology.
And that creates all sorts of challenges and problems as customers try to buy multiple products
and take those down. So there’s an inventory of a bit of a mess, I think, for software companies
who’ve been out there for a while. And there is a real, like we were talking about earlier, term
confusion already.
Prior to AI’s chunking process and merging everything together and the ongoing
hallucinations, it was a hard thing to have a dialogue about pricing where you and I would be
talking the same language, even though we’re using the same term. And we can give lots of
examples of that later in the podcast. But now that we’ve got the munging process of the chat
GPTs and the anthropics and all that, kind of putting all this stuff together, things are getting
really weird on the conversation front.
And I would tell you, we spend a lot of time sort of rounding everybody on a bit of a semantic or
a lexicon or a bit of a playbook of how we can talk about this stuff without confusing the hell
out of each other. Hey, welcome, little cat. Yeah, the cat decided to join us here again.
[Speaker 2]
Yes, on cats, copycatting, right? I guess really what happens is with lack of a real formal practice
around pricing and going through the exercises like you mentioned, there’s a lot of, well, I kind
of look like company X or company Y is growing at all costs with the pricing that looks like this.
And that’s what was popular.
And just kind of copycat and bringing that to their business. And I’m just curious on what your
observations have been around people trying to go that route versus a formal pricing exercise
and kind of where the pitfalls there.
[Speaker 1]
So I did a talk at the Business of Software Conference a few months ago, and I was being
interviewed by a gentleman who sold his business to the London Stock Exchange. His name
was Bill Spruill. And Bill had asked me, and actually we’d asked the audience, if you had a new
AI-like capability and you were pricing it in a certain way, sit down if you were charging by user,
sit down if you were, and just kind of walking through like, well, how did you get to that?
And then when he finished the talk track, like 80% of the crowd is still standing. And we kind of
did like a double take, like, well, wait a minute. How did you come up with your price?
And they said, well, we just copied the competitor. And then Bill said, well, if you copy the
competitor, sit down. Like the whole room went, whoa, and sat down.
And we just kind of had a bit of a laugh about that. But I actually think that there’s a reasonable
explanation for this. If you imagine as an engineer, it’s all about reuse.
And can I build a component? And can I take this widget and build a widget factory and borrow
from that and put these things together? And you’re trying to get that leverage.
So I think it’s actually natural and pretty common to look outside and then take what somebody
else is doing that you perceive for some reason is better and to then pull that inside. It’s a bit
like reusing a Lego kit, I think, is kind of the engineering-like focus. And I have a computer
science degree.
And that’s, frankly, what I did at my software company. I just looked out at what other people
were doing. And I glommed on a bunch of stuff.
And things got really weird as we grew. And then we kind of had to hire software pricing
partners to ungum what I had. The pricing was super accurate, Tim.
It just was a little incomprehensible, I think, to our customers and our salespeople. But I
digress. So when you borrow from the outside in, two things happen.
First is you copy unknowingly their blueprint of risk. And the problem with that is you don’t
know what the blueprint looks like. And I can tell you, being in those organizations, especially
the ones that are perceived as probably more successful than the others, there are lots of
things that need to change, lots of problems, lots of inefficiencies.
And so then you see this kind of propagation. And actually, there’s a classic example with
charging by the number of contacts in the CRM space. I mean, that was made up early on,
copied everywhere.
And it’s a really challenging metric for customers to get a hold of. Because if I generate 1,000
leads or contacts over in Dubai, and I don’t have an office in Dubai, and I don’t do business in
Dubai, those leads are worth nothing to me, right? So I don’t really want to pay for them.
And the second problem that happens after we unknowingly copy the blueprint of risk is we
have therefore robbed ourselves of the internal exercise of expressing, enumerating, listing out
our value, having an internal perspective on our value. And when we don’t have an internal
perspective on our value, we can’t equip the sales force and the partner channels and the other
distribution channels with how to defend that price. Because we haven’t really done our
homework, because we borrowed from the outside in.
And so then all of a sudden, you’ve got to borrow their playbook, their sales material, their
other stuff. And there’s lots of examples of corporate espionage gone wrong, et cetera. So I
think it is great to do outside in, but it has to be balanced with and weighted much heavier
towards inside out.
And that means we need a process, we need some tools, we need some supporting technology,
and we need some people dedicated to that function.
[Speaker 2]
Yeah, and I think it comes back to the definition. You talk about that blueprint of risk. There is a
difference in your risk on whether you’re doing tokens, whether you’re doing credits, whether
you’re doing seats, whether you’re doing number of contacts, whether you’re doing pure usage
of how you’re using the system.
And definitions matter. And maybe you talk a little bit about more, we hinted on it earlier,
around what are the differences? What are the risks that come behind some of those different
ones specifically on the way that they’re defined?
[Speaker 1]
Well, let’s take an example. This one actually just happened last week on our team. Kerry is a
former CMO, worked at Microsoft.
And we were trying to tear through the sea of new terms that have come out. And we do that
periodically. We take the new terms, we map them into our framework and make sure that we
understand.
And it’s sometimes puzzling to figure out what is being talked about. But I’ll give you a basic
example. Somebody talked about tiered pricing.
In our frameworks and lexicon, tiered pricing describes volume pricing. And you typically would
see tiers where I would tell you the first 25 units are full price, units 26 through 50 are a
different. And there’s a stair step and some calculate it as a tax table and others calculate it as
an all in price.
And there’s a whole world of terms that we would be thinking about and discussing under this
umbrella term called tiered pricing. But you’d be amazed how many times you can go out and
read on the web about tiered pricing and what they’re talking about is a good, better, best.
That’s actually tiered packaging.
But yet imagine if two executives were in the room and we were talking back and forth about
tiered pricing, not talking about in the weeds, but more strategically, like it might be. And I can
tell you it was about 28 minutes when I sat in a recent executive meeting where somebody
realized, oh shit, like you’re talking about that. Oh, I was talking about this.
And that’s like one of hundreds of definitions that are cropping up over the years. And there
was a wonderful talk also on the business of software conference by a gentleman named Bill
Allett. And he said, and I loved it.
This was 2012, I think, 2013. And he said, the problem in the software industry is we keep
inventing new terms for the same thing. And his example was a pivot.
He’s like, it’s not a pivot. It’s a change in business strategy. But every time we layer in another
set of terms, we rob ourselves again of the ability to share lessons learned and to build this
repository that everybody can leverage.
And what I’m seeing is a real, especially with the AI and the content generation, just a real
propagation of a lot of messy terms that are making it even more difficult now than ever before
to just have an open dialogue around pricing. And then secondly, like what would we do to
maybe correct or make our pricing simpler or more transparent? And we’ve got hundreds of
examples of these.
It’s a really, I think it’s a growing problem.
[Speaker 2]
We see it reflect across verticals as well, right? Like someone will call something a package and
a bundle. And it depends on if you’re in the telecom industry, then they’ve got a specific
verbiage that you’re using for the same sort of thing.
And so when you’re selling your software across multiple industries, it becomes a challenge
there as well. And I’m just curious on like how there’s acquiring the customer to begin with,
right? And then there’s the long-term customer experience and how you’re doing upsells and
cross-sells and these different things.
And I’m just curious on how that clarity around how you’re structuring your pricing affects your
customer experience right from purchasing experience to long-term.
[Speaker 1]
Well, it will affect that and it will affect the salesperson’s motion. So let’s talk about the, I think
this is just a great sort of segue to, there’s three major problems you have to solve if you’re
going to create a pricing strategy. The first one is, what are you going to put in the quantity
field?
So we use terms like usage-based to consumption-based. These are now synonyms, even
though for our last, I think consumption was more tied to hardware and usage was more tied
to application, but everything’s kind of munging together now. That defines the range of
quantities that you’ll see on the sales floor.
And if the range of quantities are too large, people are buyers, the buyer’s experience, they’re
going to have a hard time estimating. And if they have a hard time estimating tokens, for
example, then what they’re going to do is they’re not going to want to buy because they’re not
sure if they bought enough. So they’re going to want to do a paid pilot.
Actually, they’re probably going to do a free pilot and you’re going to push for a paid pilot. So
right away, the customer experience is different. Plus, your selling motion just got impacted
and you may not have even realized that decision, led down that road.
And so that’s a big topic to just discuss with its own terms and things to work through. Then
you get into packaging, which has terms like, interestingly enough, you brought up a bundle.
Well, there’s bundling, which more generically is used synonymously with packaging.
But then there’s a bundle, which is a combination of two things that are typically bought
together, whose sum of the list prices in a lot of cases is that the bundle price is less because it
has a built-in incentive or discount to get you to take down the bundle so that we get this cross-
selling motion. OK, so in packaging, though, how you express, whether it’s modular platform, is
AI going to be sold as an add-on? Do we meld it over into the main application?
And if so, what happens if somebody uses too much of this and we get hurt on cost? That
packaging can also be its own animal that you have to wrestle to the ground. And many of our
customers have what we call skew sprawl.
So some of our customers have 40,000, 50,000 skews. It’s mind-boggling across 20 different
currencies. I mean, the price points are in the hundreds of thousands.
It’s a really hard problem to get through. After you get past the second bridge of packaging,
which, by the way, if done correctly, makes it super easy for the buyer to come on in and get
what they want. If done incorrectly, then you and I show up and say, well, I love package B.
I don’t want 20% of this crap. So can I please have a discount? Because I’m never going to use
this stuff.
And that’s a huge problem also. Then after you cross those two bridges, licensing and then
packaging, then we get into this idea of pricing. What is the right price point?
What is the right price structure? Are we going to treat things like nonprofits and education
facilities uniquely because they don’t have the same ability to pay, let alone different
willingness to pay? Those are two different concepts.
Then we get into sales promotions and all these things that happen where the customer just
wants to understand, can you please tell me my net price, Tim? I just want to know. Then after
we spend a rodeo and I still can’t figure out the net price, I’m like, but I want to take two things
out, put this other thing in, and I just want two or three different choices here.
You’d be amazed how many times this is done in Excel with software companies. Salespeople
have libraries of all these models and things to do and how often this simple request by a buyer
turns into a week or more of the salesperson coming back and giving them an answer. And I
think that in and of itself is hugely problematic for buyers, especially right now where software
companies, the ones that are best to breed, we’re having a dialogue like on the phone, I’m able
to manipulate price with you on the phone.
I’m giving you a sea of choices. Between $50,000 and $125,000, if you choose this module, it
looks like this. This is how discounts are earned.
This is your per unit price. If we go and skip over the pilot, I can take the $100 per unit all the
way down to $2.50. Our pricing is built to scale. Let me show you how that works.
If you’re not having that talk track and it’s sort of the other stuff, sort of the older style stuff, I
think you’ve got some soul searching to do right now.
[Speaker 2]
Yeah. And we see that skew sprawl as well in the deal. At the end of the day, it’s like, how much
am I going to pay?
What am I paying for? And is it in my budget? Right?
Because they’re just on the other end of that conversation going, OK, you sent over a quote
sheet that’s got 17 skews with a $0 price on them, but they’re still on my quote sheet. And why
are they there? And I think one of the things that we see, especially in the enterprise deal space,
is the salespeople want to have the flexibility to be able to win the deal.
Everybody wants to feel as though they’re getting a good deal. Hey, those are 20 things that I
don’t want. I shouldn’t have to pay for those because I’m not going to use those even though
they’re part of the package.
So what is the right balance then between providing your salespeople the right flexibility to be
able to get the deal done, but then not infinite flexibility that turns into full indecision that I
don’t even know if I can say yes or no to what you’re proposing?
[Speaker 1]
Well, so this hits right in the center of packaging. So I think that the mistake—so remember, as
software company engineers and sort of this reuse, we also like to reuse frameworks in other
areas. So remember, pricing isn’t really a discipline that we stand up inside the software.
It’s very rare to see pricing treated. In fact, the one that comes to mind is MythicQuest, who has
like a formal chief monetization officer. That’s the only one—MythicQuest is like a Silicon Valley-
like show.
But they actually have a CMZO, a chief monetization officer, and it’s hysterical. But we don’t
have that in our industry. And so because we don’t have that stood up as a discipline, we tend
to then borrow a framework that we use for monetization, which I believe is inappropriate.
And the inappropriate framework is when we do segmentation. So when I’m in marketing, if
you and I were in the marketing team, segmentation is—don’t get me wrong, it’s very
important. I need to know who’s in the buying process.
And I don’t know why Betty’s always in purchasing, but she’s always in purchasing and Dan is
always in scheduling. And you understand all this stuff because you have a lead gen engine and
I need to feed you very specific content because in this case, Betty and Dan want to read
different things. And that’s great for lead gen and the marketing stack.
When we bring that over into monetization, we end up with really complicated packaging. And
you can see examples of this all day long. If you go to some of the big dogs, you’ll see every
feature is metered.
I think on HubSpot, the latest count was 26 different things are counted from active lists to
number of contacts to you name it. Everything’s metered. When we go down that road, what
we’re doing in a sense is we’re focusing more on the differences rather than the commonalities.
And there’s always a reason why somebody is different. And this creates the SKU sprawl. This
creates pricing schedules unique to industry verticals.
And when we step back and look at the differences, they’re really not all that different, but they
are transacted in the sales op and the billing systems differently under different SKU structures,
et cetera. When we have a monetization lens on, we want to focus more on the commonalities,
not on the differences. The differences are still important, but the commonalities is really what
unites people together.
And those commonalities, once discovered, form very concrete boundaries between a small,
finite number of groups. You can call them customer groups. Think of them as many customer
segments could fit in a customer group.
Many different two customers in the same SIC and industry vertical could be in two different
groups. And you’re kind of looking at how they use the software, how they derive value, what
they value. And in those commonalities, you can tease out some really universal truths that
bring a method to the madness and settle this differentiation game down.
Instead of seeing a thousand Lego pieces on the table, we see like five. And those five form the
basis, let’s say, of some pretty major packages. And then you’ll start to see like there are some
adjuncts that are only, you know, if you’re service line driven, well, maybe then you’re not going
to be interested in this feature over here because it doesn’t relate to your service line.
Or if you’re in some other pattern, you might be interested in certain features. And those could
form the basis of these add-ons. But this is the inside out exercise that software companies
don’t typically do.
The thing that they have are product marketing slicks, dozens of them, right, where they’re all
talking at different layers of value and benefits and features. And it’s all like kind of co-mingled
together. But pulling that out into a repository, being able to process it, being able to have
customers weigh in on what they think about, you know, we call them value drivers.
You know, what is valuable, what isn’t. That turns out to be a really important exercise in the
simplification part of the journey. Having just gone through this with a client last week, I can tell
you it’s very painful.
It’s sort of like painting all the walls. You know, you finish one and you’re like, oh, yeah, this
looks great. And you’re like, I’ve got like 17 more of these to do.
And you kind of, you got to pace yourself. But you do have to tear into the products and tear
into them. You know, marketing calls these the majors and the minors and really start to ask
questions and build this together.
And I think that as long as we overweight the outside in perspective, again, we’re not doing this
homework assignment. And the end result is a lot of complexity in packaging and therefore a
lot of complexity in pricing.
[Speaker 2]
Yeah, so I like your analogy of the thousand Lego pieces, right? Like, do you think some of the
cost of that is going back to some of the things you commented about being kind of
engineering driven, right? Because some of those things and why they probably have prices on
them is that there’s underlying infrastructure and there’s an infrastructure cost behind each
one of those things.
And the obvious thing from an engineer, I’m a computer science grad myself as well. Well, this
is our infrastructure and we don’t know how much of it’s going to be used by the customer. So
we need to put a margin on each of these things and put that in the pricing to make sure that
we’re covering ourselves and our infrastructure costs.
But you’re surfacing all of those details up to your customer to make a decision on them not
knowing that. And then I’m curious on what your views are on how do you deal with variable
infrastructure costs when you’re trying to get these packages into a point? Because there’s
always that fear that I’m going to run over if I charge you too little, if I’m not doing it on like an
X plus percent markup on these things.
I’m just curious on what you’re finding works out there.
[Speaker 1]
Well, I think there’s two parts here. I think the first part has to do with anything that carries with
it, even a third party cost. And if the organization is launching a product at a time where they
don’t fully understand what those costs look like, there is a heavy, heavy tendency to pass that
capability through as an add-on with its own pricing model, which really is a cost model on how
you’re being charged.
And so now I’m charging you by users, but I’m also charging you by storage. And I’m also
charging you by tokens because that’s a pretty common AI thing. And I’m also charging all.
And we know that you have to be very careful with add-ons because we have the attachment
rate problem. The attachment rate typically goes with implementation and software. And if
implementation is optional or if training is optional, anytime something is optional, you have to
really pay attention to how often it’s being attached and bought, basically, along with the main,
let’s say, driver product.
When we take something that we don’t truly understand the cost and we sort of punt it down
the field and we glom that vendor’s pricing model or infrastructure model onto our pricing and
we say, here you go, Tim, go ahead and buy your Amazon QuickSight licenses separately, but
we’ll go ahead and charge. It creates a lot of confusion. But worse yet, some customers also will
tag a margin on top.
And then, of course, now they’re in a pickle because similar to a postage stamp, everybody can
go look online what a postage stamp is. And I’m going to ask you, why are you embedding an
extra $0.05 on the postage stamp? That whole phenomenon also created complexity.
So the reason that that or what really needs to happen is that the organization needs to get a
perspective on their cost using things like fair use policies and other things, using the
packaging levers where we don’t always couch something as an add-on. Otherwise, every new
thing on the roadmap is an add-on. And you’ll know that you’ve gone too far when customers
are like, I just feel like I’m nickel and dimed here.
Like that just is add-on hell. And you’ve gone way, way, way, way down the road there. You’ve
got to bring some of that stuff back.
So if we talk about AI for just a moment, while you can price AI separately, we have a secondary
problem, which is an accuracy problem inside of AI where people, it’s pretty common
knowledge that thing kind of does some wacky stuff. And if you played with it long enough,
you’ve definitely seen some wacky stuff. So all of a sudden, if I’m using AI to summarize a
bunch of notes or to do something and it goes a little awry, I’m not going to maybe be super
excited about paying for that.
And now if you cast that to me as an add-on, I’m probably maybe not going to take it on right
away. So then we have a double whammy, right? Because the organization doesn’t know its
token usage.
If they’re running agents, it gets even worse because that really obscures things. And we’re not
getting the usage data from the customers because it’s a poor attachment rate as an add-on.
And now we’re not learning.
We don’t have any information. We have really crappy usability, and they’re not coming online
fast enough, right? Now, that’s not every case.
Some customers, everybody’s taking in the AI. But you have to look at, I think, the broader goal
of what you’re trying to do. If you’re early on and you’re trying to get that usage data, you
probably want to meld that in.
If you already have the usage data, you understand what that looks like, then maybe you can
play with it separately. And you have to pay attention. You know, if I sell you an add-on, it’s
going to be really hard if this add-on really takes off and it’s as revolutionary as this AI stuff is
making me.
An add-on can’t really be more expensive than the core. I mean, I can’t go to you and say, I
know you spent half a million on the core, but it’s two million for the add-on. I mean, you can.
It’s just kind of like a slog on the sales front. So you really have to be careful about how you cast
things. And I think how you protect yourself is, just like in monetization, your job is not to
monetize the customer and maximize the money in that transaction.
Your job is to monetize the portfolio. And so your job is to have an opinion early on that you’re
going to revise and you’re going to iterate on pretty darn quickly on, well, what is appropriate
use? How much does everybody need?
What’s that 80-20 kind of balance? And let me wrap that into some fair usage policies. And now
we’re hitting square into pricing as a process.
So if we’re on a period of time or in a period of time where innovation is very high, which I
believe we are, things are happening very quickly, new models are coming out, new cost
structures, all that stuff has the potential to literally change overnight. I think you’re really stuck
if the best you can do is update your pricing for the SKO sales kickoff coming up in January.
You’re going to need to turn this model.
And so if you’re playing with AI and some of these