Product Coffee

Close your eyes, exhale, feel your body relax, and let go of whatever you’re carrying today. Well,
I’m letting go of the worry that I wouldn’t get my new contacts in time for this class. I got them
delivered free from 1-800-CONTACTS.
Oh my gosh, they’re so fast! And breathe. Oh, sorry. I almost couldn’t breathe when I saw the
discount they gave me on my first order.
Oh, sorry. Namaste. Visit 1-800-CONTACTS.COM today to save on your first order.
1-800-CONTACTS. Most software companies struggle with how to be better connected to the
truth on the ground of their data. Meaning, like, what are people actually buying and what are
people actually doing inside the software? And then if you think about it as a software executive
team, you’re just in roll-up mode, right? Like dashboards, reports, and you tend to roll up all
this stuff.
Like on average, things look like this and you get into Excel and you do your little trend lines
and you try to determine these relationships. And what happens is it pulls you so far away from
the truth, you end up with really bad information. You end up with really misleading
information.
If your head’s in the oven and your feet are in a block of ice, on average, you’re warm. And I
think it’s like that for software companies. In the executive team meeting, you rolled up and
you’re telling everybody you’re warm.
But the reality is like this guy’s head’s in the oven and that other customer, you know, the feet
are in the ice. And on average, it sounds reasonable. But when you take the on average and you
put it against the reality, there is no average.
And I think I see this over and over and over and over again, where somebody says, well, you
know, on average, we sell these things. And then you go look at the data. You’re like, you don’t
sell that.
You don’t sell that at all. Welcome to Product Coffee, a podcast where product management
leaders share stories, advice, and thoughts on all things product over a cup of coffee. Grab a
cup of Joe and join us to level up your product career 30 minutes at a time.
I think a lot of what we do is kind of challenging the sacred cows and the assumptions and
maybe the stories that we tell ourselves that we think are representative of the customers at
large. Maybe they really are just a one-off. And it’s amazing how much the one-off customer
who paid you very little and ended up just getting huge amounts of value become a really
powerful story inside the organization that set the tone like everybody’s doing that.

And then you go look and you say, well, we just spent four hours talking about that. And that’s
just one customer. That represents 0.001% of your revenues.
Like we’re spending a lot of time solutioning one odd duck over here. It’s hard because the data
feels like it’s at your fingertips, but it’s not. That’s what I think is kind of the bringing the science
to the pricing first means you have to have some good tools to understand the truth on the
ground.
And you really got to get onto the ground. And if you get on the ground, it’s messy. And there’s,
you know, SKU lists that might be hundreds of unique SKUs all over the place and add-ons and
little things here and there.
If you’re a big company for a small company, maybe it’s relatively simpler, but it’s still kind of, it
always kind of gets away from you a little bit, or you get into the data and it’s like, why are these
net prices greater than our list prices? Oops, sorry. Yeah. We made a mistake over there and
you get into this other data and it’s incomplete.
Like it’s just to go in there means it’s like the dark cave and Luke Skywalker, right? Like nobody
wants to go in and confront it, you know, but like, that’s what you have to kind of do, or you
don’t really get to the stuff that you’re always operating in the world of metadata and summary
data and averages and things that you think are real and they’re not. It’s a really tough
problem. Let’s dive into that problem.
But before we do give the listeners a little bit of background on yourself. I started my journey as
a founder. So I built a software company in the late nineties, actually programmed the first
three versions of the software before we had a development team.
And then I got swapped to sales. So then I started to learn as a computer science grad. Yeah.
I didn’t really, I wasn’t very good at sales, right? Like I needed a real, this was in my early
twenties. I really needed to buckle down if we were going to live and die by our ability to sell,
which wasn’t very good when we started out. And so this would have been the early two
thousands.
And then along the way, I got my, you know what handed to me in a monetization lesson that
at the time I didn’t know it was a monetization lesson, but it really upset me because we were
transitioning to the cloud in 08 and one of our customers. So this is your, is your back then you
can imagine if you built it and they came, that’s kind of what the model, you know, this was
early agile. We were one of the first agile adopters, but this is late nineties, early 2000.
And we did build a lot of stuff and other smarter ways of doing that hadn’t quite become
mainstream yet. So we, we built all this stuff and it turned out that customers loved it. And one
customer in particular said, Hey, you carry a bunch of catalogs in your software.
And this was ERP software for, you know, all kinds of interior and exterior products and all kinds

of modules and stuff. And they said, you know, you’re carrying interior products and I sell
appliances and you don’t have an appliance catalog, but gee whiz, if you just go add a serial
number as a little custom field up there, all software will work, you know, just right out of the
box. And I thought, well, this is amazing because there’s thousands and thousands of people
that carry appliances.
This is a whole new market segment for us. Hey, this is great. Whole new competitive set, et
cetera.
So I say to the product team, I just need the user defined field. And then I leave on the road and
I come back months later and I’m excited to see the next rendition of the software and out
comes the demo. And I know I was supposed to be excited, Kevin.
I was horrified. So out came a whole entire module. You could build whatever field that you
wanted.
You could make it a drop down list box. You could make it this, you could make it that. It was
wired into our workflow engine.
You could make it required. You could make it optional. It had typecasting.
It had like, it was in all the, wow. It was amazing. And the whole time that I sat there, I thought I
could, I could, I could charge for that.
Right. But all the customers are going to get that for free, just flowed right into the
maintenance stream. We were in the cloud at that point.
And that was kind of the assumption we made. And I, you know, look back at that time, this was
during the market crash of 08. And you know, we were struggling for revenue and that was just
millions of dollars of mistakes like that.
It’s always a struggle for me. It’s like, if I knew then what I know now, but then I would have still
been there. Right.
But I like where I’m at now. So maybe you tell yourself it happens for a reason, but it was a big
mistake. I think that’s part of this podcast, right? It’s to share our experiences for others to
learn from, to build better products in the future and to have the foresight if possible to avoid
these situations, or at least think about them differently.
What did you do after that? I got to about 2013 and I decided I was, I didn’t really like interior
and exterior products and I needed to do something different. And I wanted to come back to
tech. I interviewed for a position heading a software company here in Charlotte.
And then we had hired software pricing partners in 08 to help us do our monetization strategy
and make the transition to the cloud. And I got a great appreciation for the science of, of what
was under the hood and what they did. And it was really just one of those random calls and the

team here was looking for another partner.
And I, on the way to the interview was just like, should, should we be having that conversation?
And I thought, why did I just say that? Like, that would be a really weird career change. And one
thing led to another. And then I took over the practice with the partners here in 2018.
One of the things that we wanted to do was, or that I wanted to do, which now I get a much
bigger vote because back then not everybody wanted to do this as is the software platform.
And so we get to kind of geek out in an AWS serverless environment and build all the tools that
we dreamed that we would have had as software company executives to manage and control
pricing for our clients. And how do you optimize that? And how do you make more money? And
what kinds of algorithms do you bring to bear on that? And how do you not take in so much
data that it’s misleading, but just the right amount of data.
So it’s right. And then how do you get to the truth on the ground and how do you see that very
quickly? And those tools, you know, bring us out of Excel, which I hate. It’s like, I love it in the
sense that you can model anything, but I hate it because nobody can understand what the hell
you did in an Excel spreadsheet if it has like more than one tab.
And so we just were able to kind of meld the software background and the pricing discipline
together. And so we’re a bit of a hybrid, you know, we have a consultancy plus we have a very
powerful set of tools and a software platform to manage all of this. And everything that we do
is on the intersection of pricing and selling.
You know, how do you move a transaction more effectively? How do we not geek out and build
some fun model that the salespeople and the partners are going to be like, what in the heck did
those guys just create? Like this is so overly complicated, right? And it’s that game of trade-offs
that you’re trying to make. And if you asked me, you know, what is monetization all about? I
think we all love the cloud. I do too.
When you shift to the cloud, you tend to forget that if you were never on the on-prem world,
you used to sell software. And then at the end of the year, you did this magic thing. Outside of
charging a huge amount of money up front, you charge a 20% annual maintenance, maybe
22%, sometimes 18 and everything in between.
But then at the end of the year, you had version 18 and you would charge for that. And then
when you go to the cloud, guess what you don’t charge for anymore? Version 18. I mean, you
just give all that crap away into the subscription stream and all that stuff that you’re giving
away, some of it is related to the subscription and a lot of it might be kind of worth more.
And so the question is like, how do you insert a gate check into the product management
function so that we kind of say, hey, this is support and maintenance and kind of what they’re
paying for. But this thing over here, like that’s the seat of a new product, or that’s, that’s really
an add-on. And how do we not create a mess in two years where somebody in sales says, well,

Kevin, this is great software.
I have 73 different modules and 43 different add-ons and nobody can, you know, nobody has
any idea what the heck they should buy. So it’s the art of simplicity, the science of simplicity, but
it’s, it’s really making sure you don’t give away too much. And in our experience, most founders,
most executive teams, I did it to give away an enormous amount of value and don’t get paid for
it.
So we’re kind of on the mission to get people paid fairly. That’s a great mission. I have kind of
maybe two scenarios we can walk through.
The first one being, let’s use an example of a product or an engineering company where there’s
maybe a lot of different features, a lot of different experiments. That word beta is used very
frequently and maybe it looks a little bit like feature hell where there’s just so many things
going on under the hood and there’s a package and there’s a, there’s something that you’re
providing a service with this grouping of functionality and features to an end customer. How
would you approach that situation as a consultant or how should that person approach that
situation to analyze that mess of feature crud and determine what are the things that matter
most and are we taking advantage of those things the right way? There’s probably two things
that we could put into their own category because you mentioned beta.
So as a tactical item, and again, we’re going to go back to this intersection of pricing and
selling, I just would never use that word again. I would, I would instead propose a term called
early access. And early access is actually offered at a premium.
You don’t take in a gazillion people in early access, just a handful. And rather than giving them
a price incentive to come into your beta, when you say beta, people go, Oh, crappy software,
this thing’s going to be buggy. And my value as a customer, Kevin is I’m going to give you my
time.
And then what happens is I go through the rodeo with you and there’s been no talk of a
budget, no talk of a sale, no, now you’ve, you’re excited because you’ve got the software as a
footprint in the door. And let’s say I’m a home Depot, right? You’re like, Oh, this is going to be
amazing. You don’t realize you’re two years away from a transaction with those guys.
So now you’re in there, except this really bad thing is happening. And the really bad thing that’s
happening is they’re kind of crapping all over your roadmap. Well, I need this, I need that, I
need this, I need that.
But there’s very, there’s very little transaction potential in the forward facing road ahead
because nobody’s there’s no executive sponsors of it. You know, there’s been no talk of the
actual transaction itself. And on what basis are we going to pay? What package are we going to
buy? And what does this look like now during the pilot? So early access just kind of spins that on
its head.

It’s the same crappy software. It still has to be debugged, right? I mean, you’re just, but the
purpose of the pilot in, in my mind is your, to test your ability to extract a certain amount of net
price for that package or that offer or that beta piece of software that we’re saying is early
access. And when you exit that early access program, you will charge a premium, you will get
paid.
And you are trying to understand the range of price points wrapped around this philosophy
that you tell the early access participants, look, you’ll never get hurt Kevin with us. If for some
reason that you paid X and we went to the market at half X, I’ll just extend your term. It will be
as if everything will be, you will always be taken care of white guy.
And of course, these become the sweethearts of the moving forward, maybe the initial part of
the customer advisory board, but that shift from moving away from beta to a paid early access
program, I think is absolutely fundamentally crucial. Now you’ve probably heard the term
product led growth. Yes.
Okay. So I think the thing to pay attention to there is sometimes if you do that too early and you
gear your licensing and packaging, and it’s not ideal or not structured properly, it might be a
really long time to get to scale and revenue, which will exacerbate the capital raising process.
And I’m a big believer that an early access program and a handful of transactions, 10, 20, 50, a
hundred, 250 grand services and software is just what the doctor ordered for investors to get
really excited and for you then to get into that stuff.
And maybe at the moment in time that you activate that, just pay attention to what that means
for cashflow. It reminds me of the customer funded business model. You’re leading with
making sure it’s profitable.
Make sure you get the signals from the customers to showcase the traction, but you’re also
funding those growth investments with the capital that you’re receiving from the customers. So
it just inherently makes sense to grow. And then to ask for venture capital or for additional
funding is to grow faster, right? Because you have this proof.
But what you’re saying is that it’s a time. Yeah, exactly. If you need it, you’re going to pay
handsomely for it.
If you don’t need it, you have people lined out the door to invest with you. One of the tricks, and
so we would call it funding the roadmap and during the early access program, you might need
a feature that needs to be prioritized. And by the way, this is the main value prop of the early
access participants is to say, your value is you get a material footprint on our roadmap.
We’re going to listen to you. And when you exit our early access program, you’re equipped with
this thing called a competitive advantage. And that’s a huge value add for the right kind of
buyer who wants that at that time.
So the value add that you’re exchanging then says, well, I’m not your custom development

partner, but of course, I’m going to listen to you, Kevin, if you have the need for a certain kind
of report or a certain kind of API call or a certain kind of this or a certain kind of that, I mean, it’s
going to get prioritized. So the product is going to meld around your operation much more
closely than it would somebody else who’s going to experience gaps because they’re organized
differently around their workflows and their use cases. And that sets the stage for funding the
roadmap, because if you want to prioritize a feature, I’m going to charge you for that.
And then we get to get paid for, and the opposite one we talked earlier as a beta, well, you’re
just building all that crap for free with no promise that they’ll ever use it. By the way, I, you
know, I’m talking from experience. You know, I, you know, we all went through, or many of us
went through traps like that.
This is a wonderful lens to now proactively strategize your roadmap. Now, what if you are that
scenario I painted before inheriting a bunch of those decisions, these beta, these massive
features, if you’re inheriting a bunch of that as an organization, you’re coming in as a leader
there or a consultant, how do you advise them to now evaluate that list to then make better
decisions moving forward? Usually there’s not a coherent one-stop shop place to go in the
organization to see the complete list. It’s, it’s a partial list, or maybe it’s tribal knowledge, or
maybe it’s on the website, but when you go to the website, it’s all this marketing speak.
It’s not, you know, that’s seven features under that bullet point on the website page. And so
there’s this real gap and, and we would instead want you to look at, you know, value drivers
and value drivers is just a fancy way of saying there’s this capability that the company that
you’re selling to is trying to accomplish. And that could be delivered through one or many
product features, or it could be delivered through one or many services or both.
And building that map is crucial and important. And if you’ve ever done any sort of process
decomposition work, you always run into this problem of, I have a high level activity and I have
a low level activity. And often what you’ll see when you put the list together is you have this
thing called a reporting module.
And then you have a thing called the ability to add a good user defined field. And it’s like, those,
one thing is really big on this table needs to be broken down a little bit. And this other thing is
maybe too detailed, needs to be summarized a little bit and rationalizing that list in English with
good thought process and good basic fundamental process decomposition skills to, to look at
what that list is.
So it’s orderly and it’s collectively exhaustive. And they’re not overlapped where if you count
these two things, they’re really kind of the same thing. It takes work.
It takes some thought process. Sometimes it takes help like what we do. Other times you can
do it internally, but getting that list is really important.
And then the second piece to the puzzle is don’t ever bring your traditional marketing stack to a

monetization exercise. And what I mean by that is buying personas and other things. Those are,
those are frameworks that are used to drive content, to build Legion, to build the funnel, to
understand in the sales process, who talks to who, who influences who, who’s the decision
maker, who’s the budget, who holds the purse strings, right? That marketing stack is geared for
those kinds of mechanics.
Monetization is about value. It is possible that within an industry segment, two customers can
experience value very differently. And it’s also possible that across your standard SIC, two
customers that maybe have the same word in their name, XYZ Lumberyard and Kevin’s
Lumberyard experience value almost identically, or maybe Lumberyard in category number
one and healthcare company, Kevin’s Healthcare in category number two are almost identical.
So how people take down value has nothing to do with firmographics, has nothing to do with
employee size, has very little to do with the things that we attach in product marketing, which
ultimately equip us with the ability to drive a target 100 list, which means you’re like in query
language, right? So how are all those databases built? Well, they’re built with a name and a
employee size and an industry segment and all this stuff, because there’s a service provider or
a technology behind the scenes giving you that list. But that’s not, that doesn’t describe how
people use your software and get value from the software. And so the first thing you want to do
is redefine your ideal customer profiles.
And that means that they probably, what maybe what makes somebody ideal in the early
access program is that they don’t use your API level. Why? Because you haven’t built it yet. And
maybe in three months, what makes a customer ideal, they use your API layer in some way.
And so this, this, what I’m talking about is this very dynamic sort of refreshing of who it is that’s
ideal. And then there’s frameworks that we use to kind of score those and those give you a
much on the ground, truth on the ground, who really is an ideal customer? What kind of service
do they take down? I mean, there’s tons of SICs and employee size and everybody goes, Oh
yeah, I’d love to have that company. Well, you’d love to have them until they’re on your support
call.
And then you’ll be, you know, crying a river with the pain and suffering that you’ll go through
with a customer like that. And I think we’ve all had those experiences. So getting really clear on
that then says, well, now I understand my customer mix.
And, and a customer mix again, is not firmographics. Customer mix is what we’re talking about
here. And understanding your customer mix means that, that you understand how it changes,
how fast it changes.
And you understand how people are taking down your software and solving real problems and
that you can produce what we call class. A customer class is just a group of customers that
experience value similarly and trying to solve the same problems. When you do that, then you
can begin to exercise your judgment, which early on you may not have, but it’s a product

management function.
I believe that you would understand how your customer mix represented by a dozen or so
customers uses the software values. These, you know, is this important to me? Is this not
important to me? And that is the key ingredient for the underpinning of the packaging that
you’ll put together. And if you don’t have the underpinning, and I’m sure you sat through these
meetings, Kevin, then you’re in a room and somebody says, I think we should have a pro, a
basic and an enterprise, or I think we should have, and what they’re doing is they’re Babe
Ruthing what the output of the packaging would be.
But I think if you rewind and just get the inputs correct, it will tell you what so many times we
don’t focus on the inputs. Everybody wants to know what’s the best practice. Well, guess what?
It’s software.
There are some best practices in general, but what’s best for you is very different than what’s
best for somebody else. Your software company, if I duplicated it and we had a mirror universe
and everything about you was identical, your team structure, your staffing, but there was one
thing that was unique about both of these mirror companies. And that is that their customer
base is different.
Might be in the same SICs and similar, but what they’re doing in the software and the rate at
which they’re doing that, and the kinds of volumes that they buy and the kinds of products they
take down are different. And that gives you the blood test of that software company, which by
the way, is why you never copy a competitor’s licensing, packaging, and pricing strategy.
Because I can promise you, like I did, somebody just made it up.
A founder went out, read on a blog and said, well, Dharmesh Shah and Brian Halligan, right?
Charged by the number of contacts in the database. On the medium in 2021, I think it was
Dharmesh wrote a piece about, you know, the pricing isn’t really all that great. That’s a publicly
traded company.
That’s like a Boston sweetheart. Imagine what they could have been if they got it right from day
one. So it doesn’t mean you still can’t be successful.
I think that what it means is if you get the ingredients and the inputs right, especially early on,
it’s great. And this is the other piece to the puzzle that I think happens in early access as well.
Prior to that moment that you mentioned, you probably don’t have enough data and enough
track record and enough sales to have this idea of what all this would look like.
And I would just tell you, you have to have a perspective. Pricing is not a democratic function.
Customers do not want to pay you anything.
In fact, our data would tell you they’re happy with paying you slightly below your costs,
provided you’ll still answer the support line. If you don’t answer the support line, they might be
willing to pay a little bit more. But my point is that that perspective that you’re developing in

early access gives you all the keys to the puzzle or to the house, if you prefer.
All the keys. My analogies need a little bit of work, Kevin. But it gives you all the pieces of the
puzzle in order to figure out how you will be selling this, how you will be defending value, and
most importantly, what your perspective on your value is.
My journey was I had really long hair, longer than your beard, and I could bite it. And my family
thought maybe I might be going a little hippie. I literally could not afford a haircut.
I was eating generic cereal. The cents really mattered. At age 27, I had $180,000 of credit card
debt.
I was scared like you wouldn’t believe. I’d look in the mirror some nights and I was like, holy,
you know what? This is the real deal. I can go bankrupt.
I don’t know what that is, but that’s really scary. Going through that journey and having that
perspective can get you out of that kind of a scenario. The reason that I mentioned that is I was
selling $2,500 software and every time I went back into the spreadsheet, everybody else got
paid except myself and our co-founder.
And that was my switch over to sales because I was like, I just can’t keep doing this. I can barely
afford rent, let alone a night out or a dinner out. So I hired a sales coach who recorded all my
calls for five years straight.
He was amazing and it was embarrassing. At the 14, 20 second mark, why did you say that? You
completely unraveled the deal. That was really stupid.
I’m like, oh, well, I didn’t know. I’m going to go back and read some more books. And so in that
drive to Atlanta, we had quoted a client at $15,000 and I went into the spreadsheet and I was
like, this is a great client and I’m not going to get paid again.
I was really frustrated. And the sales coach said, why don’t you just try charging a hundred
grand? I was like, okay. So then in the meeting, I upped it to 125 because I was like, why not?
Because he made up the number.
So I’ll make up the number. We lost that deal. But in that deal, that CEO said, Chris, it’s not the
price.
It’s the fact that you don’t have a purchasing model that does. And he rattled off what it needed
to do. So guess what we did? We went back and built the purchasing model.
Our very next sale was 140 grand. I went from a 15,000. Now I can tell you if I asked our
customer base at the time, Hey, Kevin, you know, what would you be willing to pay for this
software? They would have been like, about what we paid.
But here we went selling half a million dollar software after that. Just literally overnight. We just

didn’t know what we had created.
We didn’t understand the value. We didn’t have a perspective. We were too focused on the
mechanics, not on the value of what we created.
So you can’t dig through that feature list until you have this perspective from your customer’s
shoes. You got to take your shoes off first and see all the value that you’re providing through
their eyes. And the best way to do that, if you’re going through that exercise and you’re
scratching your head, like, I don’t know if you know your customer mix and you know that the
ideal customer is in this case, the pilot with home Depot, you pick up the phone and you call
them and say, Hey, this feature, is this like a gut half thing? Is it a night? And you ask them, you
know, you engage them in a dialogue and our customer research would tell you don’t need a
lot of data for that.
You really don’t. You don’t have to talk to a thousand people. You can talk to half a dozen and
the pattern emerges.
We had a team of anthropologists and other things that did research after six, seven interviews,
you’re going to see a pattern very clearly. I’m going to tell you what you need to know. If you
ask those questions.
I think that’s such a great mindset shift that product tech companies need to take. It sounds
like, and where you’re positioned in the company that you’re currently a managing partner of is
helping to teach that in a way that is also offering software and services. I think that’s a, it’s a
wonderful intersection of sharing what you’ve learned with others, as well as doing exactly
what you’re meant to be doing is to monetize that effort as well and not lose sight of, of what
matters and the cost to produce that teaching into that software.
I want to talk a little bit more tactically about that list. If you can give us a tactical real world
example, one positive and then one negative, meaning this is one that indicates some
opportunity and this is one that indicates like we need to kill it. The value drivers, I think the
crucial piece to that is that they do align with some aspect of the, of the capability that the client
or the customer is.
So I think it goes back to that sort of hierarchy example. You know, I, I need to be able to report
to the executive team is probably not, you know, I need to be able to drive out some dashboard
and an executive team is probably not a great value driver. Being able to see X, Y, E, you know,
key performance indicator or KPI on the dashboard, probably okay.