SaaS Coach

[Speaker 1] (0:00 – 0:37)
One of the biggest struggles for early stage software companies is pricing. What do we do with
our pricing? What if we go too high and nobody buys?
What if we go too low? We don’t make enough money. What, ah!
Pricing’s a struggle. Fortunately, I had Chris Mele. He came on the show.
He’s from Software Pricing Partners. And that’s what he does is help people understand how to
price accurately, how to make sure you’re not missing out on anything. And there’s a lot of
complexity to it that sometimes we don’t think about and we make a lot of mistakes as software
founders.
So I know I have, and I know many people out there have. Check this out. I think you’re gonna
like how you can structure your pricing in maybe a different way than you’ve thought of before.
I think you’ll like it.
[Speaker 2] (0:38 – 0:50)
Welcome to Sastry in the Making, the podcast that features the people who made the software
world what it is today and the leaders who are shaping the future of technology. Here’s your
host, Matt Wallach.
[Speaker 1] (0:50 – 12:14)
Hey, welcome. Super excited to have you here. Thank you for coming.
Really appreciate it. Now, I am really, really looking forward to today’s guest. I’ve got Chris
Mealy with me, and this is something that is so important as you’re getting started within your
company, or even as you’re in your growth phase and you’re really taking off.
Pricing, pricing is critical and knowing how to price correctly, knowing how to avoid pricing
mistakes is unbelievably important. And it’s something that a lot of my clients ask me about. I’m
so excited to talk to Chris Mele today.
Chris is an expert around pricing. Chris, how are you doing? I’m doing great.
Thanks for having me, Matt. Absolutely. Let me tell everybody about you, Chris.
So Chris is the managing partner at Software Pricing Partners. The name says it all right there.
What they do, they help software companies outmaneuver competitors by exposing and

applying more strategic approaches to monetization.
I’m really looking forward to diving into that. He’s also formerly the CEO and co-founder of a
SaaS company, Companion Cabinet Software. He’s really privileged to have worked with, helped
grow an amazing team that developed an award-winning number one business management
ERP solution in the remodeling industry.
So, so, so glad to have you here, Chris, once again. Thanks for coming on the show. You’re very
welcome.
So tell me, what’s going on with you lately and what’s coming up? Well, maybe the best way to
start is, maybe unlike a traditional consulting company, we have quite a bit of tech. And so what
that means is we’re kind of a hybrid.
We’re a little bit of a software company and part consulting company. And so that’s how we do
what we do in pricing. It’s a lot of modeling and it’s a lot of homework.
And of course, one of the mistakes that I made early on was, you know, you sort of launch a
new product and you get really excited. Back then I was on-prem software in 2008. We were
going to the cloud in 2000 and right before the market crash.
And that took us, I think it was like a year to do the security. And I think you can do that in a
couple hours now in AWS, just to give you kind of a feel. The Lego pieces parts were there, but
they weren’t quite as amazing as they are now.
And so that transition that we went through, we actually ended up hiring software pricing
partners because we made some mistakes. And one of the mistakes that I made was, we just
kind of made up the pricing because we felt like, you know, that’s kind of like what would work.
And we really miss hit on some key transactions that probably should have been five to 10
times the size that they were.
And a little thing that I’ll start with as the nugget of the big lessons learned was don’t forget
about services. And I think in the effort to get SaaS and get people up and running, we kind of
just figured services were all included, implementation services, support services, and a
transaction was 30 grand a year, really could have been a couple of hundred thousand. Then of
course we were raising capital on my equity money, my equity stake.
And so that was a really expensive mistake. It ended up being really expensive. No kidding.
And it’s something I think a lot of people don’t do. Do you, when you help out, are you seeing, I
don’t know if you track it, is there a percentage of software companies who have a setup cost or
a services cost versus those that don’t? Well, so this is an interesting topic, right?
It’s best practices and there are some best practices, but unlike in maybe a B2C setting, and we
were talking about planes, trains, automobiles, that kind of stuff, this is intellectual property.

And so intellectual property is an idea. The product itself is a bunch of usually code and
obviously infrastructure.
And so you can kind of do whatever you want. Now, in general, you should charge for all of
your IP. And I think that where we really made the big hiccup, Matt, and what I now fully
understand, but at the time did not, is that intellectual property can be delivered in a lot of
different forms.
I was very focused on the product form, the features and the things that our software did. It
never really dawned on me that intellectual property was contained within the services that we
do because like many software companies, if you’re not a point solution, then you’re
implementing some behavior change. And that behavior change is usually because some
workflows and other things that might be in the background that are getting redesigned.
And of course, in order for you to redesign a workflow, you kind of have to understand that
customer’s business, what’s optimal, what’s not. And that is your expression of your know-how,
your intellectual property, and you can charge for that. And there’s many different gradients of
what that looks like.
You know, there’s implementation, there’s support, there’s professional services, but you have
a lot of IP know-how tucked in there. And so to charge for that in relationship to the software
fees is totally fine. And we have customers whose software access fees pale in comparison to
the services.
So I think like a million dollars to kind of configure the software, get it in, and then maybe they
pay a couple hundred grand a year in the software ongoing fees and then vice versa. We have
companies whose lion’s share of the transaction is software access fees with a little bit of
services and everything in between. But I think the big finding is charge for all of your
intellectual property.
And there’s a third bucket, which is really interesting, and that’s called insights. So imagine that
you and I had a software company and we analyzed our customer environments. This is
actually a real story from a software company where if you and I were recruiting, we want to
buy technology to help us find and place a position that we have.
So if you want to hire an enterprise architect here in Charlotte for serverless technology, let’s
say, you can count the number of individuals that would be available on one hand. There’s just
not a lot. I actually know them all by name and good luck getting them.
I mean, you’re just not, it’s gonna be very hard for you to extract that. So what they do is they
analyzed customer environments and looked at how people flow from different states into
those jobs. And it turns out that if you’re targeting somebody who went to school at UNC
Chapel Hill or UNC Charlotte, went to college here in the US or Duke, and they’re like in another
county or another state or they’re on the West Coast and they’re married and they’re in a happy

position, not even looking, they’re four times more likely to move back to their college
hometown than they would be otherwise.
And so that’s an example of something that could be extracted as a feature, maybe introduced
into some higher level offer like an enterprise edition, and you can charge for that. So if you
really just sit back and think about like, well, what’s all the stuff that is in that intellectual
property, your job, unlike the car or the plane example is to broaden the horizon of all the
different forms of things that you do. And monetization is about capturing all of the intellectual
property.
And I use that IP term very specifically because you’re not monetizing software. I thought we
were pricing software, right? So I missed out on services and these other aspects of things that
you could charge for.
And it’s all in there and you can charge a premium for that. I love it. I know I’ve missed out on it
several times as well with many of my companies.
What are some of the biggest mistakes that leaders are making around their pricing and what
are they missing? Well, I think that probably the biggest mistake was on par with, so when we
started, it was late nineties and my software company. So we were all on-prem and we couldn’t
ship a product on time and we were having a brutal time at it, and engineers and software, but
we just couldn’t quite pull it together.
So we, and this is before product management was this huge discipline. And this was kind of
the time when you could build it and they would come and thankfully they came. And the thing
that you’re trying to do is to zero in on what we now know is a very agile-like process and agile
has wonderful estimation characteristics where we build libraries of things that are similar and
we kind of know how long things take.
And that problem that we were trying to solve was we just wanted to ship on time. And so we
got into agile and product management over the next decade would bloom into this
unbelievable discipline. And it’s a lot like that with pricing.
So pricing is a real science. There’s also aspects to that that carry with it good judgment, but it
is a soon to be dominant part of the business model if you have a software company is to treat
that more on par with product management so that you’re making decisions about how you
might put an offer together, a good, better, best, or a basic pro advanced or not. A lot of people
think you need three choices.
You don’t, you can have one. That sometimes is the best, right? People want an all-in-one
solution.
And so you’re trying to come up with the idea that when you build your business model, just
like you would spend a lot of money in product management and management of that, you
really have a product that’s always changing. So if it’s always changing, the assumption is it’s

changing for the better and increasing value. So we should have processes around the idea
that we would revisit the price, alter the packaging, change the way that net prices are
calculated, change the way that incentives are structured or presented to customers.
Today’s 5% volume incentive might only have to be tomorrow’s three and a half percent. And
how do you know what that right number is? And that just means that you have a perspective
on your value before we put the pizza under the door and get the code back.
You know, during the design process, we have a roadmap and our problem that we eventually
solve through Agile. And you can kind of think of pricing in the same kind of way is, if I could
understand how long something took, then I could estimate the cost and I could bounce that
maybe against a forecast where if I invest a quarter million to build this feature, then I would
hope to get a return on that. And we got very good at measuring that.
Well, with monetization, if you have the appropriate ability to model, and again, this is kind of
what some of the software that we have does to figure out, like if I built this, who would buy it?
What might they pay? And what would the revenue, not the list, but the net price extraction of
that.
You know, if you’re using a consumption model and you had a thousand units or 10 units, like
what do you get out of that deal? If you kind of had an angle on that, you could imagine that
during the planning of the roadmap, you might reorder some things, right? Because this thing
that you’re gonna do second, if you did it first, would unlock three times the amount of revenue
production.
And so why not? And in fact, that’s what we do with our customers. And that prioritization of
the roadmap is where monetization connects into at the very start of that product management
process.
And then of course, it glues a lot of other things together that we can talk about. But that
concrete gluing point on the way in which we plan what we’re gonna build was a real aha for
me. Cause I actually ended up hiring software pricing partners and it was 08 when we moved
into the cloud.
[Speaker 2] (12:16 – 12:18)
So you ended up here.
[Speaker 1] (12:18 – 27:36)
That’s amazing. So you hired them and now you’re managing partner. That’s kind of a fun
route, I bet.
But you said something earlier that I really wanna key on. You’ve talked about revisiting pricing.
How often should software companies revisit their pricing and their monetization?

So that’s gonna have a couple of different answers. So first in periods of high inflation more
often, right? Secondly, you are kind of tying it to the cadence of the production from the
roadmap.
So if you have a more legacy product and you’re keeping it in sort of maintenance and support
mode and you’re late to the cloud and converting over, the manner by which you would touch
that pricing or adjust it is very different than I’m coming out of the gate, I’m on my 20th
customer. That’s a time of high velocity, high change, high exploration in the form of being
much more agile around packaging and pricing. And so the thing to keep in mind is we always
wanna talk about pricing, but I think that pricing always gets glommed together with one of
two other things.
There’s licensing and pricing, which says, do I charge by user? Do I charge by the number of
transactions? And that means that depending on what I pick in the quantity field of my contract
that I’m gonna put and multiply by the list price and size of the deal, right?
That has to be very realistic or we end up with these gargantuanly sized list prices and buyers
are like, I don’t know what you’re smoking, but we’re not really gonna talk right now because
we’re not gonna write you a check for 22 million a month. Those are real examples that
software companies struggle with. If you think about packaging, then the pricing that we’re
talking about, it’s the offer, right?
So what are you offering? Well, if you don’t know what it is you’re offering it, boy, is it really
hard to attach a price point because does it include these services or not? Does it include these
features or not?
And you kind of have to anchor that down before you can attach a price. Otherwise, I think
many listeners could relate to conversations where you feel like you have it all anchored down
and somebody comes in and says, well, I know we have like a one size fits all offer, but should
we do a good, better, best? Because I read a Wall Street Journal article that says, if you give
somebody like a false option in the middle, like they’ll more oscillate over to buy the upper,
which is BS, by the way, that doesn’t work in B2B, but in general, then the conversation ensues
of, well, now you just changed what it was that you were offering.
So any conversation you had on price point is somewhat meaningless, right? And so the other
big lesson learned is I think the price point discussion, the economic thing that you’re so
interested in, which is the output of what all these discussions are gonna be like, actually
shouldn’t start first, right? Because everything else can change.
So you kind of wanna tuck that in the back. So the discipline that we’re talking about under the
software business model is how do you think about licensing? That has a set of frameworks and
that’s different problems.
How do you think about packaging? That’s a whole different ball game. You know, we have a

whole separate teams that do that.
And then we have pricing, which is the modeling and the mechanics and the price point setting
and the optimization and sort of how do we understand what truly our value is? And what does
this look like a year from now or two years from now as we start building more things? Because
the things that you’re building can radically impact sometimes the value that you create.
And you really wanna get ahold of that and sort of rounding out, since we’re talking about
mistakes, you know, I gave away a lot of value. I remember we called it the UDF. This was the
biggest cluster I’ve ever been through on a software company.
So a user-defined field. We were serving interior products, mostly in the cabinetry and really
cabinets, countertops, marble, hardware, flooring kind of stuff. And actually flooring was really
kind of later.
So it’s just think of your kitchen and all the stuff that you would do surrounding that. And it’s a
configuration challenge. Not many people realize that you can do a lot of things in the kitchen.
It’s like measured now on par with the grains of sand on earth with the number of choices that
you can make because you can color cabinets and glaze them and raise their height and reduce
their depth and all this stuff. And in that problem set that we were looking at is this idea that we
could scale the engine to other categories. And in fact, during the 08 market crash, that’s what
we did.
So we had a customer, they were carrying appliances out here in Wilmington. And they said,
you know what? If you could just give me a user-defined field to store this serial number, like I
could, the whole software works.
And we were like, oh, that’s great. So in goes the request. This is a product management
nightmare, by the way.
In goes the request for a user-defined field. Three months later, I’m traveling around selling
everybody on the new cloud edition. And I look at the demo of what comes out in the product.
And it’s like, you can build any field you want of any type, drop down list boxes, and you can
structure. They can be required. They can, remember the original quest, right?
Very simple. It’s tied into our workflow engine. It was tied into the report.
It was like Rolls-Royce gold-plated nightmare kind of stuff. It was amazing, but like not what we,
a hundred times more than what we needed. And that flowed out to our customers.
And we didn’t have that monetization checkpoint that basically said like, maybe if we kind of
thought more about packaging, we could have stopped that. And that maybe was better
presented as an optional component for a percent up charge or a flat fee or something that
drove more revenue. And so the cost of not treating pricing with a discipline is quite high.

So it sounds like you should have a lot of your teams communicating with each other. If
customer success or support hears about something, they get it over to the product, product
builds it, they throw it out. Maybe they should have run through whoever’s on monetization,
sales, marketing, whoever it is to make sure, hey, maybe we should put this in one of our
higher packages, make it an add-on, up the pricing overall.
It sounds like that’s what should happen, right? Yeah, and you’re, so you want an owner and it
doesn’t have to be like you hire a whole new team. Like if you’re a smaller stage software
company, a few million in revenue, the odds of you hiring a full-time person for this is remote.
But having a clear owner such that like if you’re the founder and I’m maybe on sales and there’s
somebody else on legal, like maybe the triumvirate kind of treats it as a discipline and we have
very distinct kind of roles there. But your original question around, how often should you
change pricing? I just want to tie that back to, it’s how often to really change packaging is
another part of that.
And of course, when the roadmap is delivering lots of stuff early on, you want to turn that
wheel a little bit faster and changing the pricing doesn’t always have to be that you change the
list price. People sometimes say, well, if I change my pricing, I got to go update the website.
What we’re talking about is changing the way net prices are calculated.
And there’s this philosophy and pragmatic underpinning that we really will tell you the
performance when you adhere to a thing called market fairness pricing is exquisite. If you fall
into the trap of the 90s where, hey, Matt, that looks kind of like a nice shirt. So I think I’m gonna
charge you a little bit more in the form of less of a discount for your purchase and somebody
else tomorrow buys exact same thing and maybe they get a little bit more of a discount
because their shirt wasn’t as nice or for whatever reason, customers now have the tools and
the abilities buyers to uncover that.
And when they see that other person got the discount, they’re armed with that on with your
salespeople by saying, hey, they’re just gonna shred the sales team’s ability to defend price
because they have a price point from, in this case, another buyer that got a special deal. And so
market fairness pricing just says, pragmatically speaking, when I come in, I wanna trust that I’m
getting the price. So discounts are earned, they’re not given.
We can show you, the customer, how they’re earned, how you earn incentives. And we adhere
to market fairness in the sense that for that offer and that volume, that net price is the net
price. Now you might have a sales promotion and customers will withstand a reasonable
variation, but they will not stand, you got an 80% discount and I’m being quoted a 25%
discount.
That’s just the stuff that really shuts down the sales process real quick. Yeah, that makes sense.
But that implies you need some discipline, right?

You need some structure for pricing and packaging. For sure, yeah, absolutely, I would agree
with that. What advice would you have for early stage software leaders thinking about their
pricing and what should they be focused on with monetization and pricing?
Well, the idea that you might be able to upfront understand all the ramifications of your value
as it relates to the customers, I’m sure everybody’s familiar with the term willingness to pay, is
really quite abused in software. And people forget that software is an experienced good. It’s not
like a car and there’s a lot of similarities.
The code bases can be quite different on-prem versus cloud, for example. And so you don’t
really know what you’re willing to pay for software until the behavior starts to change around
the software. And I, as the consumer of the software, start collapsing more and more
workflows into the software as my organization changes to make room for the software to
generate more ROI or more return for the, I’m extracting value from the software and I’m
returning that value back somehow in my ecosystem of my buyers, my customers.
And so once you understand that, which is rule number one, you really wanna get a beat on
what the yin and yang or the sort of scope of your impact is, then you really wanna subscribe to
the idea that nobody really knows the answer. And if you were to ask what you’re willing to pay
for this new AI engine, the fork has already been stuck on that one. They don’t know the
answer.
In fact, I can’t even run a conjoined analysis on you and show you a good and a better and
swap out a feature because if that price changes, your human brain’s gonna pick up on that
real quick. Higher price, higher quality, lower price, lower quality. So you really wanna adopt a
philosophy that I wanna continually explore my value and have a process by which I’ll use the
term max, but not in the negative connotation.
I wanna get maximum value such that it’s fair to the customer or for the exchange of money for
intellectual property. And I wanna do that at the maximum rate and as max defined as, I don’t
wanna unnecessarily create sales friction in the dialogue where I’m slowing down the sort of
flywheel of the deal velocity. I don’t wanna get such a premium price that my deal velocity,
instead of doing five deals in a timeframe, I’m only doing one.
It’s like the idea that software is about scale. You can literally scale that thing unbelievably with
you’re not manufacturing parts and things like that. And so you really wanna crank the flywheel
at a high velocity such that your early access pricing is designed in a way that you are not
inadvertently slowing down new customer acquisition because the, and it’s not just price.
It’s really a lot of times not the price. It’s actually more the licensing or the packaging. Like for
example, let’s say that you’re in the AI space and we wanna sell to, oh, I don’t know.
Think of a, I’m gonna make up a gas station conglomerate and we have an AI facial detection
algorithm. What’s really common in that space is I’m gonna charge you based on the time that

the number of times the model runs. So now I, as the customer show up and say, well, that’s
great, Matt.
You wanna charge me the number of times that the model runs, but I have 247,000 cameras
across the U.S. on a mix of 24 by seven and some of them are just night vision. So like, what’s
my bill? And you don’t really know how to answer that.
So in that example, the licensing that you pick was so unknowable that your buyers will be like,
well, that’s not acceptable. I’m not gonna just carte blanche let you in for a 200 grand budget
knowing that my bill could be 2 million. So that’s like, that’s a licensing issue, right?
That has nothing to do with price point. That’s a light packaging issue could be, I know you
have a good and a better and a best, but I’m looking at your better and it frankly doesn’t look
like anybody would use it because it was fabricated. And the best has too much stuff in it and I
don’t want it.
So I don’t wanna pay for it. So now I’ve got all that friction to contend with, which is, well, you’re
giving me an offer and I get that I have access to your APIs, but I don’t need that and I’m never
gonna use that. So I’ll close today, can I please have a discount?
So that’s, this is what we call partial use argument. And so that’s a packaging problem, right?
That doesn’t have to do with the price point.
It just has to do with what you put in the kitty is too much crap and they don’t want it and
nobody wants to pay for stuff they’re not gonna use. I mean, there is, I’m okay with a little bit
extra, but not like tons extra. And so there’s a lot of nuances to thinking through that.
And I think that going slow to move fast as we think about licensing and packaging and pricing
and early on, especially being very open to how customers want to buy is really important
because you could have a great technology, but if your consumption strategy is untenable, it’s
not going anywhere. And that’s of course a failure rate that that founder may not realize where
the problem lies. So problem identification is really, really crucial.
Yeah, I would agree. Sadly, we have reached our time, but this has been amazing. The amount
of depth that you’ve got into here, Chris, for us is fantastic.
I love how you’ve covered everything. You’ve made it really clear. I wanna make sure that
people can get in touch with you and get to know more about what you’re doing.
What are the best ways to learn more about what you guys are doing? Softwarepricing.com.
Okay, that’s easy.
Softwarepricing.com, that’s so awesome you have that URL, by the way. Everybody out there,
softwarepricing.com. We’ll put that, by the way, in the show notes so everybody can click it
easy, but really simple to get there.

Chris, this has been awesome. Thank you so much for coming on the show and sharing all this.
Yeah, happy to do it again, Matt.
Thanks for having me. Absolutely. Everybody out there, thank you for coming.
Make sure you’re subscribed to the show. You don’t wanna miss any amazing leaders and
innovators like Chris. So hit that subscribe button so you’ll be able to get all of that notified to
you so you can get to each of these shows.
But thank you so much for coming. Really appreciate it. We’ll see you next time.
Take care. We’ll see you next time. Take care.