Sales for Founders with Ben Orenstein, Co-Founder of Tuple

Ben Orenstein shares his hard-earned tactics for navigating enterprise sales as a technical founder.

Michele Hansen: Did your latest
AWS bill give you a heart attack.

Cloud Forecast sends you daily
transparent reports that help

you understand your AWS costs.

Find any overspends and promote
opportunities to save costs.

Cloud Forecast takes complicated data and
produces accurate presentable reports.

So you can share stats quickly and
make strategic decisions swiftly.

With communication integrations
like Slack, Microsoft Teams,

and email to share insights.

You can go from managing your
AWS spends in hours to seconds.

Start a 30 day free trial today.

No credit card is required to get
started at Cloud Forecast.io dot I O.

Hey, everyone.

I'm so excited for today's episode.

We have Ben Orenstein with us.

Ben is co-host of the Art of
Product podcast and co-founder

of Tuple Tuple, which is one
of the most admired independent

software companies out there today.

I'm so excited to have you on.

Ben Orenstein: Thank you.

The most admired is uh application
I have not heard before.

That's pretty great.

Michele Hansen: Really, I feel
like that that's kind of how

people think of Tuple Tuple.

Like.

Ben Orenstein: As you were
saying, it kind of resonated.

I was like, oh yeah, I guess
people do seem to like us.

It's, it's that weird thing where
like, I am aware of all of our flaws,

but people have a more nuance or like
a sort of more holistic view of us.

And I was just thinking like of like
various Twitter threads and whatnot.

It's like, oh yeah.

I guess people are mostly quite positive.

Michele Hansen: Yeah.

So the genesis of this conversation
today was we met at Founder Summit.

Um, and you were supposed to give a talk
on sales for founders, which is a topic

we've talked a lot about on this show.

And is it like a really tough thing?

Um, for first time founders, especially,
uh, you know, a tough thing to learn.

And so you were supposed
to give a talk on that.

Unfortunately we're unable to, and I
was like super excited for that talk

and so sad it didn't happen and so I
thought it would really fun if you got a

chance to talk about sales for founders.

Ben Orenstein: Yeah.

I mean, that sounds great.

I, I have, I have the outline.

I have a table of contents of a book that
I would like, kind of wanted to write, but

it wasn't probably gonna follow up with,
and I have this talk that almost happened,

but then I went on a taco crawl in Mexico
City and got quite sick, don't do that

the night before you're supposed to say.

Um, And so, yeah, I'm
stoked to talk about this.

I have, I've I've learned some lessons, I
think it's, it's a bit of a limited data

set given that I have only done sales for
one company, but I think probably there

are some lessons in here that I learned
going from like being an engineer who

likes efficiency and not understanding
procurement and IT and pricing and the

sales process and what, even as a PO.

And I think I, I can probably
pass on some, some stuff that

is possibly going to be useful.

Michele Hansen: Yeah.

I mean, I think that point there is
something that, that really hits home

that, you know, Mathias and I talk
about is like, wait, why can't they

just like sign up online for an account?

And I'm like, no, they have
like, they have procurement.

Like you need to use their portal.

And like, it's like, why, why can't
we just build something that they can

just upload all of those things to, and
then we do it and then it's automated.

It's like, you can the bureaucracy
of each enterprise company.

Cause they're all, they all have
their own special way of doing it

and they all want you to conform
to their special way of doing it.

And the idea of just signing up
for something online is confusingly

simple to the point of being imposed.

Ben Orenstein: Yeah.

So the, the outline for this book that
I was going to write in the intro,

the, of the first topic heading is your
intuition is right, sales is kind of.

Like I kept fighting it for
a while where I was like, but

hold on, this is, this is dumb.

This doesn't make sense.

Why, why can't it work like this?

And eventually you sort of just learned
to like, you can't refactor the sales

process of everyone you're talking to.

And, there are things you can push
back on, which I think is kind

of an interesting topic as well.

But overall you are dealing with
a thing that is inefficient.

It is, is not the most
efficient way to get this done.

And so you need to sort of, you need
to act accordingly and respond to

that reality rather than fighting it.

Michele Hansen: So you mentioned there's
some key lessons that you've learned.

Ben Orenstein: Yeah.

Michele Hansen: What's the
high level of those lessons.

Ben Orenstein: It's kind of a lot, I would
say there's, so again, I'll throw this

caveat out there because it's important,
which is I have done this for one company.

And so our tool is a um, something
targeted at developers.

So it's adopted by engineering teams
and we make it easy for the teams

to come in and get in and try it.

And the way our sales process usually
gets kicked off is the engineers try it.

They like it.

They ask someone to buy
it over and procure.

They contact sales at Tupelo, and
then now the sales process has begun.

So yeah, so all of this advice here,
just, you know, just, just be aware,

like, it's not like I've done this for
many, like I ha I haven't seen enough

different viewpoints to know for sure
if this works all the time, but this

is what has worked for us, and so I'll
speak kind of authoritatively from our.

And at this point we've done millions of
dollars of enterprise deals at this point.

We closed like large six-figure
deals, multi-year deals, deals

with fortune five companies.

So it's, we've had success using
our approach and using our software.

So maybe this is so I can at least
sort of say, like, this works for us.

Maybe it works for you, but you
asked for a big picture things.

One, I actually kind of touched on, which
is that I think a bottom up sales process

is vastly then a top-down sales process.

So the fact that engineering has already
tried our product and liked it and then

asked for it means that when the sales
process gets kicked off more often than

not, we're just sort of taking orders.

Like we are helping procurement by the
software and not selling the company

or selling some high level decision
maker on the software and try to

get them to inflict it on their uh,

Michele Hansen: That's also how
we do sales as well, like we,

we never did any cold outreach.

I don't think we've ever really
tried to it to someone who

wasn't already interested in it.

And in many ways, I think we kind
of took inspiration from slack

because I feel like that was a
lot of their early growth as well.

Was the engineering teams using it
by like liking it, wanting to use

it, other teams hearing about it.

And then, and then it's
just a matter of filling in.

Ben Orenstein: Yeah.

Michele Hansen: so to speak rather
than having to do cold outreach and

pitching and stuff like that, which I
guess I've, I've only done sales as a

founder from that perspective as well.

But I did work at an agency
as my first job out of college

at a web development agency.

And we were going out and pitching and
making proposals and replying to RFP.

Dude that was so much work.

And most of it led to absolutely nothing.

And I think that's why I love this
bottom up approach to sales is.

Ben Orenstein: Yeah, I think
it's just a nicer way to be.

And I think if, I think, especially
if you're a bootstrapped company,

it makes life a lot easier.

Like the sales process is much simpler
when they're already sold on the thing.

It's easier on from your side, and I
also think you're more likely to succeed.

Like it feels like to me getting a tool,
selling a tool from the top of the org

chart and then having that decision get
made and then having it sort of trickled

down, feels like a recipe for bad fit.

Like you could imagine, like the software
is being foisted on you by someone

two levels above you in the org chart.

And you're like, oh, I
don't even like this tool.

It doesn't do what I want it
to do, or it doesn't do what

we were trying to accomplish.

I feel like it would probably lead
to worse outcomes uh, that approach.

Michele Hansen: I'm curious, you know,
I don't want to oversimplify the sales

process because we do have a lot of
times when you know that person on the

engineering team or even that team and
their manager really liked you Geocodio,

for example, but then they have to
sell it to their director or their

VP and they bring us to help sell it.

And it's not just like that.

They like it.

And then a PO shows up that does happen.

And that is awesome when that happens,
but rarely does that happen and more

so there is some sort, but there's
not only like basically we are

helping that team sell the product.

And then of course there's, there's
the whole negotiation side of things.

Which speaking back to founder
summit was kind of fun because I

got to live one of those Twitter
threads where people ask, what could

you give a talk on with no notice.

And I did that on negotiations
when your talk unable to happen

um, which was pretty fun.

And so I'm curious, like, what are your
experiences with when, like, do you have

that happen when a team needs you to help
sell the rest of the organization onto.

Ben Orenstein: Um, That is totally like
a high leverage opportunity, I would say.

So that does happen with us so often
it is a an engineer somewhere towards

the bottom of the org chart, trying
to sell it to their team lead or

a team lead, trying to sell it to
a director or a VP or something.

And those are pretty critical
conversations actually like that, that,

that affects that can have a big impact.

And so the main thing we've done
around this is we made a thing.

We call it the boss page, which
helps is like basically like our best

attempt to sell Tupelo to someone a
little bit further up the org chart.

Where it talks about the
benefits of pair programming.

Like what's likely to come like the
benefits a slightly higher level

manager might care about, and also
answers some common objections or

questions that people would have.

And I think there's a lot more, I
think there's more we could do here.

Like this is sort of just a simple,
like one pager that we send to people

as a trial is ending saying, Hey, if
you want some help selling this to

your boss, here's something we made.

But I think we could go
even further on that.

Michele Hansen: So you just, you
just touched on something that.

I think is a key part of this, which
is letting people try it for free

or very cheaply before they need,
you know to be able to use like the

corporate credit card or, or, you
know, get a PO for it or whatnot.

So you mentioned that after the free
trial, so, so what is the sort of

Tupelo model from that perspective?

Ben Orenstein: Um, Right now
we have a 14 day free trial

with no credit card required.

Michele Hansen: And you mentioned
right now, you have that I'm

curious, has that changed over.

Ben Orenstein: Yes, it's
changed several times actually.

So immediately before that it was a
14 day trial with credit card required

upfront which we switched away from
because so many of our customers don't

actually have a company credit card.

So it was like, Hey, I
want to try this tool.

Oh, it needs to require a credit card.

Let me go ask my boss
for their credit card.

Oh, I haven't tried the thing
that I'm asking for the credit

card for, which is awkward.

And people have this sort of
discomfort around, oh, well, what

if you start charging my card?

I'm not aware of it, or
you like, I might forget.

And so we, we moved to this, this current
model, which has been popular and I'm

happier with, but even before that um, we
experimented with a number of different

ways of getting people into the product.

Uh, so in the very early days, we
actually charged a hundred dollars

flat for your first month for a limited
usage and then we would start billing

by user, after that month was up.

And that was sort of intentionally
a high bar that we set where

we, we made it a little bit.

You had to sort of show some
commitment to get into the product.

And we did that because we w we didn't
want to grow too fast at the time.

Like we were just, we were getting
exposure to lots of different environments

and user requests and things like that.

And we didn't want to get overwhelmed
with new people coming in the door.

And we also wanted people to try
to take the trial very seriously.

So it slowed things down.

Like we had fewer trials for sure,
but it was kinda interesting that our

trial conversion rate was super high.

I was like 60% or something
because like, people are like,

well, we paid a hundred bucks.

We have to try this thing now.

And so we didn't have, we had very
few of those trials where it's like,

oh, they never really got started.

They never really tried it.

And then even before that in
the very earliest days, I was

pre-selling the tool by the year.

And so would say like, we're
looking for like a core group of

teams to become our initial users.

And so we want people that are really
committed are willing to like stick

with us as we improve this thing.

So if you're interested, you have to
like pay per seat per year to get in.

Michele Hansen: That's really interesting.

Cause I, I feel like I hear in
that, that you have learned a lot

about how teams acquire software.

Ben Orenstein: Yeah, for sure.

That was, I mean, that was
the big learning for me.

I originally thought that the customers
for Tupelo were going to be freelanced.

Just like individual developers
working with clients or something.

And I was like, it didn't even
occur to me that like, no, no, your

ideal customer is a whole bunch of
developers on the team, obviously.

And it just didn't click.

And so there was like, there was a lot
of learning that went on as we, as we

actually launched and saw who was using
it and how, and then how they bought it.

And you know, me just being like,
can't you just go put the credit

card in and they'd be like, no, no,
we can't go put the credit card in.

Michele Hansen: So when you have those
people who are using the, the $100

free trial, which sounds like it was
like the, I mean, the thing about Tuple

you have this network effect, right?

Like the more people within
the organization are using it,

the more value the organization
is getting out of it, right?

Like if you're the only one Tuple in
your organization, you do not have

anyone to Tupelo within the organization.

So like, you'd need at least
one other, one other person

to use it with ideally a lot.

And when you had that a hundred
dollar For the trial level, I'm

curious, do you know who was
making that purchase at that point?

Ben Orenstein: Um, Do I know who

Michele Hansen: Like who was
actually putting in the credit card?

Cause you said the next step you
switched to having credit card, trying,

credit card required for a free trial.

And that didn't really work because
the people who wanted to try

it didn't have the credit card.

So it sounds like there was a shift in
the buyer when you changed from paid

trial to free trial with credit card.

Ben Orenstein: Weirdly enough people
with sometimes DME and say, I wanted

to try Tuple so badly that I paid for
the a hundred dollars myself on my

Michele Hansen: Wow.

Ben Orenstein: Yeah.

Which is cool.

I mean, it's a vote of confidence, right?

That was like awesome.

Our reputation was really good.

And so like people wanted to
try the software but it was also

like, okay, that's seems wrong.

People probably shouldn't be
shelling out a hundred dollars

personally to try or software.

Michele Hansen: I mean, I hope
they got reimbursed later.

Once

Ben Orenstein: Hopefully, although it's
like, you know, it's one of those things

where we're getting a hundred bucks back.

It's probably not quite worth
it from the company, you know?

Michele Hansen: That
is really interesting.

So then when you shifted to free
trial credit card required, were

you thinking that people would
continue to use their personal cards

Ben Orenstein: They did.

That happened a lot because they still
didn't have a company credit card and

they still want to try the software.

It just got a bit easier.

It got cheaper basically.

Whereas before they would like eat
the a hundred bucks to try it or

slash get reimbursed, now they would
put their personal card down and then

be like, okay, I have to remember to
swap this out for the company card.

If we like.

And so a thing we kept seeing happened
was people would try it on one credit

card and swap like right the day before
the trial was supposed to end or cancel.

And we'd be like, oh no, why'd you cancel?

And be like, oh no, I liked it.

We just are waiting on approval
to use the company credit card.

And so we have to wait for that
to get, get a yes on that before I

can go grab the card and put it in.

Michele Hansen: So let's get
down to like nitty-gritty here.

How did you figure that insight out that
what was happening was that people were

putting in their personal card and then
either canceling it or maybe even doing

a chargeback or, and then trying to get
it switched onto their personal card.

Take me into how that insight developed
that the people basically, you need

to sell this within the organization,
don't have access to a credit.

Ben Orenstein: Um, I don't remember
exactly how I got that insight.

I would say that we are pretty, especially
in the early days as very aggressive

about talking to not aggressive, but
I was, you know, I was trying to talk

to everyone or like email everyone,
so like if we had a failed trial like

that, if a trial canceled that looked
like it was good, I would email them

and say, Hey, what was going on?

Or, and I think we even had automated
emails for when people would

cancel or trials wouldn't succeed.

We were sort of like, we have all these
like customer feedback traps built

into the product and built into the
process so that we're sort of always

asking people like what's going on.

And also at this time where we
were experimenting with like the a

hundred dollars upfront approach, I
was DM-ing people a lot on Twitter.

like, I knew all our customers
basically in those days.

And had sort of contact
with almost everybody.

And so, I was just close to them.

Like I was taught, I was taught, I
was in contact with them quite a bit.

And friends of mine would like, you know,
be working at some company and they would

message me like, Hey, just so you know,
like I want to try to Tuple, but I don't

have a car, I don't have a credit card.

Or like, this is a deal breaker.

Like, Hey, I tried it.

And I paid for it.

Yeah, a friend of mine just like said,
Hey, by the way, that's right, that

came from like, he was a Twitter DM,
Hey, I paid a hundred dollars out of

pocket because I wanted to try it so bad.

But just so you know, this is
probably hurting your adoption.

Michele Hansen: Interesting.

So when you shifted between
those sort of acquisition models.

Did you head to head test them against
each other or did you go okay from one

day to the next you, you changed the most.

Ben Orenstein: We just swapped.

Yeah.

I think there's value in AB testing stuff,
but I'm not sure we had the volume to

like, do like a statistically significant
test or really the willingness to like the

interest, we were sort of like, this, this
model has worked for us for a little bit.

But like, this just seems like a better
fit and that might've been foolish in

retrospect, there are times I think
about going back to that thing, that

model, because, yeah, we got fewer
trials, but the conversion rate was so

high and the engagement was really high
and it was like, people felt bought

in, in a way that signing for free
trial does not make you feel bought in.

And so there's a big benefits and to
have like a very open and permissive

trials, and there are downsides too.

And so I, I would be interested almost
in an AB test between no credit

card required long free trial versus
like, yeah, no, you have to pay us

a hundred dollars to even, try this
thing, like go back to that and just

see like what does that look like
these days as we have more reputation.

Michele Hansen: Yeah, that would
be really, really interesting.

Mean, so you mentioned that the strength
of the Tuple brand and I think something

else that's probably going on that I'm
curious about your thoughts on is, you

know, you have people who have been
using Tuple at their jobs for maybe

like, you know, years at this point.

Um, So when did you guys launch?

Ben Orenstein: Um, Launched, we
will be four years old next month,

but our first eight months were a
little more than three years ago.

Michele Hansen: Is that it

Ben Orenstein: Yeah.

Michele Hansen: dude?

I feel like you like your legends of
the indie, like software world, like

quite frankly have probably, you know,
after base camp, like resigned their

position as the leaders of the movement.

I feel like it's almost you
guys who are leading it and

you're only like four years old.

What is this like,

Ben Orenstein: Uh, Yeah, well, yeah,
there was this, there was this event

where a lot of people started working
remotely at that happened a couple of

Michele Hansen: Oh, yeah.

That thing.

Yeah.

I feel like I vaguely heard about that.

Ben Orenstein: So you could, you
could argue we've had some tailwinds.

Michele Hansen: So, okay.

I was going to ask something else, but
I want to go in on that for a second.

So you started out with us, you had
this pay us an upfront for a year.

Period, which was your first eight months.

And then you shifted to pay us
a hundred bucks for a month.

So then it, so if your first eight
months, if we're kind of making a

timeline here was pay us for a year.

Then you went to a hundred dollars
for a one month unlimited trial.

How long did that period last.

Ben Orenstein: uh, Six months, Maybe,

Michele Hansen: Okay.

So now we're, we're 14 months
in and then you switched to

free trial credit card required.

How long did that last?

Ben Orenstein: A long time a years?

Michele Hansen: So did that
shift around like 20 20 period?

Ben Orenstein: Uh, No, actually it was,
I mean, it was this, it was this year.

I think it was

a few months ago or last and last year.

Yeah.

Michele Hansen: Oh, oh, okay.

So super recent.

Ben Orenstein: That the one where we
shifted note to no credit card was,

yeah, was six, less than six months ago.

Michele Hansen: Oh, interesting.

Interesting.

But, so I wonder if you, if you've had
this, like, All of this growth over

the past couple of, I S I'm still like
in shock that it's only four years old.

That's just, that's just not true.

Like, I'm sorry.

I reject that.

Um, You have people who
are moving from one job.

To another, who probably used
Tuple at their previous job.

And then I feel like we've All had that
experience of going to a new job and

they're not using some like modern, you
know, tool that you're used to using.

And you're like, oh my God,
you guys are in the dark ages.

You aren't using like this thing.

I can't do my work without it.

You have to try it and then like
selling it within the organization

when they get like, do you like have,
have you heard anecdotes about that?

Ben Orenstein: All the time.

Yeah.

That happens a lot.

Which is great.

One nice thing about selling to
developers is they are passionate

about tools and also passionate about
sharing them and like arguing for them.

So yeah, we get, people emailing
us, like probably every week maybe

saying like, oh, I used Tuple at
this place and now I'm here and

I'm trying to get them to adopt it.

I'm trying to get us to
buy some licenses and.

Michele Hansen: That's awesome.

And the other thing running under
current of that too, is it's not

just that they are passionate about
it, but then company's value their

developers more than other employees
for better or for worse, like making

the developers efficient is like you,
you can't really find any executive

or VP that would argue against that.

Right?

Like it's, it's sort of like, you
know, straight in the heart, right.

Because, oh, well this will make
the developers more efficient

and they're like, sign me up.

Um, and so you've kind of got these
two current's really going for you or

has probably as Justin Jackson would
say wave of you know, of things in

your favor that lead to adoption of it.

Ben Orenstein: Yeah, for sure.

And if you take that and then add on
like a viral component where people

invite each other to it and inviting
people makes the monthly price go up,

it's a, it's a very good business model.

Michele Hansen: Yeah.

Ben Orenstein: Has a lot
of things going for it.

Michele Hansen: That sounds pretty sweet.

So I think we've only hit the
first points on your list.

Let's keep going.

What do you got next?

Ben Orenstein: Yeah.

So I think a big shift that happened as I
got more experienced with enterprise sales

was realizing how much I could say no to.

Michele Hansen: Ooh, I love this,
especially when you have some.

Ben Orenstein: Yeah.

And so there's this sort of
natural tendency, which is like,

oh my gosh, I want them to buy it.

I need to agree to everything.

And what it turns out is like
procurement and legal and everyone

will sort of make, will make requests
of you that are not deal breakers.

And so it's natural to assume
that everything is a deal breaker.

And if you don't do every single thing
they ask of you, it's not going to happen.

And in reality, it's more
like it's probably like 30%

of them are deal breakers.

You could probably more often
than not reject the request

and still get the deal done.

And so the first one lesson is
lose some deals or like get

some deals to close, to, to loss.

So like, one trick that I would do
is, people be like, oh, Hey, can

you fill out the security audit?

And I was just classic one.

Right.

And I would say, sorry, no,
I do have this detailed page.

That has um, lots of information
about our security practices.

If you have any questions that
aren't answered here, feel free to

follow up and I'll update the page.

And that like got rid of like 60, 70% of
requests for like custom security audits.

Most of the time they
would go, oh yeah, yeah.

People would say, oh yeah.

Okay.

I think that'll work.

Hold on.

And like someone would sign
off on it and it'll be okay.

When a big company buys a piece
of software, there's this giant,

that they have created over the
years, so they don't get burned.

So they like us and like that their
legal department makes them do that.

Procurement makes them do their, all
these items on this thing, like security

audits terms of service, custom red lines
in things, payment terms, background

checks for employees, pilots demos.

There's this giant check.

Most of them are not critical.

I would say a lot of
them are not critical.

And so if you just do everything to
ask you, it'll, it's, the smoothest

version is the easiest way to get them
to just, like, get through the process,

but it's kind of hell on your side.

And like, none of this stuff is as
good or as useful as working on

your product and actually making it
better or talking to more customers.

And so, I would recommend people
say, like, say no to things and

then ask, is that a deal breaker?

' cause, you could just ask like
that, like, oh, can we get a

volume discount on the whatever?

And I'm like, oh, sorry.

Like, We don't offer discounts
until this many seats.

Let me know if that's a deal breaker.

You're just sort of, you're throwing it
at them and say like, Hey, let me like,

tell me if this is going to sink the deal.

And if it's not going to sync
the deal, no, you can't have it.

It lets you gather Intel and over time
you'll sort of learn what things tend to

be deal-breakers and what things don't.

Michele Hansen: So let's demystify this
a little bit especially for founders

who don't have a ton of experience
with sales or big enterprises with

giant checklists, you said about.

30% of those things are actually required
and you can push back on 70% of them.

What are those examples of
things that you push back on?

Ben Orenstein: I actually made a
list of things I've said no to,

and still gotten a deal done.

Michele Hansen: This is going to be good.

Ben Orenstein: Yeah, this discounts.

Procurement is basically always
going to ask you for a discount.

Why not?

Michele Hansen: So this is, I'm just
going to pause you on this list.

So I heard and I think, I don't know if
this is from Patrick McKenzie or somebody

else the, basically when you're dealing
with like giant company procurement

people, they are basically incentivized
to get like something like five to a 10%

discount on every deal, every renewal.

And, that can A be a point of um,
negotiation where you get extra stuff in

exchange for that, or if you are already,
for example, discounting your annual plan,

simply updating the invoice to make it
clear that there is a discount in it, and

then you don't have to discount further.

So it looks like they are
hitting their metrics on the.

Ben Orenstein: Totally.

Yeah, you can make this easier on
yourself by inflating the base price and

then giving them a fake discount down
to whatever actually you want to sell

it for, and this is kind of like the
game that everyone, that a lot of people

play, Um, but you don't have to play it.

You could just be like, the price is the
price and we don't do discounts, sorry.

Or you could say like, we offer
discounts for purchases above this.

That's it.

And it's hard to say, like, if that's
one of those things, it's hard to

say no to, because like you have
this vague sense of like, if I don't

give this person what they want,
they're not going to pay me $50,000.

And I can tell you from experience
a lot of the times they still are.

They, they haven't, there's no cost
to them to ask, they will, they

will almost always ask because it's,
it's just pure upside for them.

But this gets to another one of my
points, procurement wants to get the deal.

Procurement has been asked by
engineering to buy something.

Engineering has more social capital
in the company than procurement

does, unless you are dealing with
a very dysfunctional organization.

So your average, bottom of the
org chart, you know, procurement

specialist is not going to want to go
to the VP of engineering and say, I

didn't buy that tool you asked for it
because they wouldn't give me a 10%.

Michele Hansen: Right.

That's not going to happen.

Ben Orenstein: Right.

And so if they say, can
I have a 10% discount?

And you say, no, they're not going to
walk away from the deal almost ever.

Michele Hansen: And especially if it's a
product that they have been using for two,

three years now, that is well integrated
into the engineering pipeline or

Ben Orenstein: Oh yeah,

Michele Hansen: Like they're going
to ask, cause they're incentivized to

Ben Orenstein: yeah,

yeah,

Michele Hansen: but it's not
going to tank the renewal or the.

Ben Orenstein: I mean, most of the time,
if it turns out your product is not

as useful as they thought it was going
to be, and engineering has said, yeah,

we'd like it, but it's not critical.

Well, now you might need to discount.

It depends a lot on what the
actual situation is, right?

Like if, oh, we use it occasionally, we
like it versus I don't, we get this done.

We want this, this is, you know,
please renew this, you know,

signs, Marriott, VP of engineering.

Like there's a difference depending
on what the context is for sure.

But.

If you're not, if you're not
occasionally sinking a deal or nearly

sinking a deal, you don't actually
know where the boundaries are.

Like you're not going to learn.

What's critical.

And like what actually are
deal breakers and what are

things they're just asking for?

Because they might as well.

Michele Hansen: I mean, this is the
equivalent of, you know, being in a

sort of traditional marketplace and you
are, you know, this, I mean, this is

effectively like bargaining at this point.

And then you just walk.

Ben Orenstein: Yeah.

And it's just like, as, as someone new to
sales, you will tend to, this advice is

like targeted towards people that kind of
becoming, like getting into this, like,

you know, probably engineers who are
sort of forced reluctantly into sales.

And I will say that you are, you're used
to a world where if someone asks you to

do a thing, you should probably do this.

And sales is just like,
everything is negotiable.

Your default mental like map
is probably kind of wrong.

And so I would encourage you to correct
in a slightly different direction.

So here's some more of the things I've
said no to where the deals still got

done discounts, active user pricing,
like only charged me for like the

number of users I'm using, filling out a
custom security audit, doing background

checks on our employees, a free pilot
uh, product changes, a custom demo,

scheduling a call at all, like talking to
something, or selling through a reseller.

Michele Hansen: Interesting.

I'm curious, what are things that
you have said no to that were a deal?

Ben Orenstein: Procurement generally
wants to get the deal done.

So sometimes it's price.

Sometimes you ask for a thing
and you say no, and they say,

we can't, do it at this price.

So occasionally price becomes the
deal breaker, but it's actually, while

procurement wants to get the deal
done, legal doesn't care as much, legal

has a weird place in the thing where
it's like because legal is protecting

the legal interests of the company,
they have a bit more social capital.

Um, Are more able to sink a
deal and are less concerned with

pissing off the VP of engineering.

And so if legal says, you have to
have this claim, this line in here

that says you're like absolving
us of liability in this situation.

Uh, That can be a deal breaker.

Like if you don't, agree to the legal red
lines, and this also is a negotiation,

like there's some things it's, the
same thing where some are going to

be deal breakers and some are not.

But I would say you're more likely to
bump into stuff where they'll just go.

Yes.

All right.

This is required for us because
we don't sign any contracts

that don't have this clause.

Um, you're, You're going to bump it with
them in the negotiation of the contract.

Michele Hansen: Yeah.

And speaking of negotiation, I'm reminded
of something that I often think of,

which is that you end up in cases,
especially in, I guess, organizations

with not tons of process, but there's,
there's still procurement and legal

and everything involved where people
just want to have an edit on something.

Like they feel like they're
supposed to negotiate.

They feel like they're supposed
to bargain in some way.

Um, It reminds me of, you know
uh, a designer, friend of mine.

And There's a word of that she talked
about how, when she would send designs

to a client, she would intentionally
put something, you know, in a button

in like bright orange, just so the
client had something to correct.

And I feel like very often
you mentioned invoicing.

I feel like invoicing terms is that
one, like if I get a contract back

that only has one edit, chances are
it's changing invoicing terms from

30 days to 45 days, or like, there's
just like these like small things that

people will always want to talk about.

But then as we kind of mentioned
before, like the role of leverage

in this and how you can play these,
these things off of one another as

Ben Orenstein: So that thing of including
some sort of request or item that

you know is going to get rejected is
something you can do in contracts as well.

So whenever possible, if you can,
I recommend starting with your own

agreement, like that's one question
that will come up as like who's paper,

are we gonna use, like, are you gonna
start from your agreement and we'll read

liner or the other way around, you don't
have a legal team, most likely, so I

recommend asking to start with yours and
have it sent over to their legal team.

You can use Y Combinator, SaaS
agreement, it's quite good.

Michele Hansen: So good.

We, we use that for years before
we actually got our, got our own.

Ben Orenstein: Yep.

So yeah, I would start from that and
then just edit it for your needs.

But then I would add a bunch of really,
really friendly clauses to you, so like

you agree to that we can do a case study
and we can mention your name publicly

and we can put your logo on the website
and you'll do an interview with us.

Uh, You agree that every year your price
is going to go up automatically by 10%,

that your payment terms are 15 days.

You can start with this stuff that
no one is going to accept knowing

they're going to redline it and you
give them that thing that like, oh,

they've done their due diligence.

They reviewed the contract.

You can put these things in
there that are like long shots.

That you're expecting them to reject.

And it gives them that sense of like,
okay, I I've done good lawyerly things.

I've protected the company's interests by
spotting these things and removing them.

And then some of them will get
through, sometimes I put clauses in

there that are like at their level.

They, they agree to it.

I'm like, oh, wow, nice.

Okay.

That's that's great for us.

Michele Hansen: So I agree on that,
that logo and you know, mentioned in

case study is a, is a really common
one that is sort of a awesome if

it gets through, but, oh, well, if
not, you mentioned invoicing terms.

You know, there was like
three of them there.

And I'm curious, are there any more
in there that you would suggest people

adding on to either their contract or
probably a good point to note if you're

not doing contracts with people at the
very least having a terms of service

that they are checking off, that they
agree to, but more often, like an

actual contract, especially for bigger.

I have one.

Um, And using you using
that Y Combinator agreement.

So like, what are those other
things that you throw in?

Ben Orenstein: Um, I think
I've touched on the main ones.

I usually start, I think another big
one is the limitation of liability.

This is like, I think that gets fought
over quite a bit, and legal departments

are very much on the lookout for is,
who is liable when, and for what.

And who is going, like give each
other protection and defend each

other from, various things.

And so the Y Combinator agreement has, I
believe a very startup friendly take on

this, which will almost, almost always get
edited down or rejected by the other side.

And, so I think that's a good one
to leave in there as just like a red

herring almost, or just, you know,
give, the legal team something to do.

Um, But yeah, the other one's
like mostly around publicity and

marketing and mentioning their name.

And then like an escalator clause, like,
Hey, this price like this agreement auto

renews, unless you give us 90 days notice.

And when it does the price automatically
increases by this amount is

another good one to throw in there.

Michele Hansen: Have you played
those clauses against each other.

For example, someone is asking for, let's
say, they're asking for a discount or

they are asking for, let's say better.

You know, they, they don't
want to do 30 day payments.

They want to do 60 day payment
terms and then you play that

off of, okay, we'll do that.

If we can use your logo on it.

Ben Orenstein: oh, sure.

Yeah, yeah, totally.

Yeah.

You can try.

I, that does not worked that
well for me though, honestly.

A lot of the times.

You're dealing with legal when you're
negotiating the contract, but like

determining who can use the company's
logo is like a marketing thing or like

a PR or comms thing, and so sometimes
they're like, yeah, we can't offer this,

you'll have to negotiate this separately
with our PR department or something.

And so I haven't had a ton of success
being like, we'll give you this, if

you give us this sort of thing, I
think there's just like the slight.

Human tendency of being like,
well, they asked for 10 things.

If we said no to all
10 were kind of jerks.

So like what's a couple
that we can let slide.

Michele Hansen: Yeah, I think so.

So that, that element of like
social capital and like who has the

capital in the company and legal,
it might be stronger than the

communications team, for example.

Ben Orenstein: True.

Yeah.

And again, it also comes down to
like, how badly does the company

want to get the deal done?

And How badly do you want that thing?

Are you going to walk, if they
won't let you use their logo?

Because if you're going to walk,
if, if they won't and they really

want the software, I bet you can
get the logo, but if they kind of

want the software and you're not
going to walk, it's a lot harder.

Michele Hansen: So the thing I'm
curious about your experience with it,

that I've experienced is insurance.

This often feels like something in
contracts that feels pretty set in stone,

that it says, you know, it's pretty common
for there to be like, you know, five

different kinds of insurance required.

It says you need to have,
you know, general liability.

You might need to have umbrella, you
know, umbrella liability, excess coverage.

You might need to have employers comp,
you know, workers' comp like automotive

like or um, I mean, especially, you know,
in software having cyber uh, errors and

omissions and, you know, a cyber policy
on that and something that I have felt,

I guess I used to feel afraid about
in the past was upping your insurance

coverage can be really expensive and
like, and it looks very like, this

is what it is in the contract, right.

When you get, or those
edits back from them.

But you can just reply and say
like our policy is, you know, 1

million, 2 million, 3 million.

We don't carry this insurance.

We don't carry automotive insurance
because we don't have any corporate

vehicles , and more often than not, I have
found that to be acceptable, like, or I

say something to the effect of, you know,
if X limit on this is a hard requirement.

We are happy to discuss that with
our insurance company, and add the

cost of that additional insurance.

onto this contract.

Ben Orenstein: Yeah.

Michele Hansen: And then pretty
much then they're like, oh no, no,

Ben Orenstein: Yeah.

Yeah.

I've also experienced them sort of
folding on insurance requirements.

It's kind of like a
wishlist more than hard.

Do they really care if it's
5 million versus 4 million?

And I probably not, not really.

Although I will say it's a
very easy requirement to hit.

We use founder shield and we just
like tell them what we want and they

send us like a group, like I got
a collective policy kind of thing.

It was not very much work and it
was not actually very expensive

for the limits that we needed.

And so this was kind of like a one
day ish task to like get a bunch

of insurance that let us say yes,
we have this on, on contracts.

Michele Hansen: Uh, agreed.

We actually use founder's
summit ourselves as well.

Ben Orenstein: that founder shield.

Yep.

Yeah, they're good.

Michele Hansen: all the
things named founder.

So what else is on this list?

Ben Orenstein: I mean a million
things I'm going to give.

I'm going to give some, some
terrible legal advice here.

Michele Hansen: this is, not legal advice.

Ben Orenstein: this is not legal advice.

This

Michele Hansen: Consult your lawyer.

Ben Orenstein: This is advice.

that I think is probably
pretty good, 99% of the time.

And then 1% of the time will
be catastrophic for you.

And so just, just heads up, which is a
contract that you signed with another

company is enforceable in court.

You have to imagine, like, will we
get sued if if this thing is going to

be enforced by a judge in a courtroom
with lawyers involved that are

making thousands of dollars per hour.

And so sometimes you look over a list
of things in a contract and you go, is

it likely that if we slipped on this
thing or like had a million dollars

less coverage on this thing that we are
going to get dragged into, and sued for

breach of contract and you should ask.

And the answer is probably
not most of the time.

Um, So I think this is my like cavalier
startup attitude, which is like, if

you're trying to get a business off the
ground and like, I wouldn't worry it,

like, the reason you die is because you.

Uh, Miss a term in their terms of service
and did not technically comply with it.

And then they found out and took
you to court and sued you and

broke your company that way.

I think the number of startups that have
died that way, probably very, very small.

And so 99% of the time I wouldn't
worry about it quite as much.

Like, every single beautiful
line in the contract.

This is not how we do it now.

Now we're like a legit company.

We have a legit lawyer.

We like do all the right things.

We push back where we need
to, we follow all these.

But if you're like a brand, if
you're a two person company trying

to sell this tool to an enterprise
and they're like, you, you need to

do this really weird esoteric thing.

You need to conduct a uh, training
every so often on making sure that

your supply chain is not using
forced human labor and you go sure.

Yeah, we'll do that.

And then, like you have a two minute
conversation with your co-founder

on a calendar invite and say
yes, checked, compliance, done.

That might be okay.

Michele Hansen: I think it's also too
important to note that like, if there

is a conflict about something in the
contract, like everybody wants to avoid

court because as you said, it's extremely
expensive to the point where like a lot of

big enterprise contracts like that, they
said, it has to go into arbitration, like.

You start with negotiating, which
is talking about the problem and

finding a solution to it there.

And then if you can't do it, then you
go into arbitration, which is, you

know, you have or mediation rather.

And then only after you have failed
negotiation, you have failed mediation,

then do you go into the legal system?

Right?

And so like, if there was some
massive problem, like it is unlikely.

That, you know, sort of
knock on wood, right?

That it ends up in court and hopefully
you have built a relationship

with them and they trust that you
are a well-intentioned person who

may be just screwed something up.

And there is some other way to
solve this rather than a courtroom.

Ben Orenstein: Yeah, exactly.

And that this advice is like coming
from someone that has not been sued.

So

Michele Hansen: Yes, I guess I

Ben Orenstein: I imagine some, some
number of years I will look back

on this conversation and go, wow,

Michele Hansen: We did get a
cease and desist list at once.

That was.

probably the closest we ever for
a side project yet a mobile app

Ben Orenstein: So, anyway, I guess my,
I guess my, you probably won't get sued

is my uh, my high-level advice and do
with that information of what you will,

Michele Hansen: cool.

What's next?

Ben Orenstein: um, Let's
talk about pricing.

I learned a weird thing when I
started doing these deals, which

is that a hundred thousand dollars
a year is not a lot of money.

Michele Hansen: Can you break that down?

Ben Orenstein: Yes.

So as a person, a hundred thousand
dollars a year is a lot of money.

Like you're uh, an individual,
you have a job, you make a

hundred thousand dollars a year.

You make a lot of money.

You're doing great.

If I was like, Hey, you need
to pay me an extra a hundred

thousand dollars this year.

You say what?

Absolutely.

There's no way I can pay you a hundred
extra $200,000 this year, a hundred grand

a year as a person is a lot of money.

A hundred thousand dollars a
year to a company of a decent

size, not a lot of money.

So like, it is very reasonable to
give an invoice to a company that

says I would like you to pay me a
hundred thousand dollars a year and

have them not even blink because
it is less than their lunch budget.

You Have to really shift your mentality
around money and dollars and value when

you start dealing with organizations that
are bigger than 20 people, let's say.

Michele Hansen: You mentioned a lot
of this advice in the beginning is

stuff that will break somebody's
brain, especially if they come into

this with an engineering mindset where
everything makes sense and is logical.

And this is absolutely not logical on
the surface, but then it actually is.

When you think about all of the work
that you not only put into serving

these customers, but also this all
of this gymnastics that goes into

actually delivering the product to
them and all of these other pieces of.

Ben Orenstein: I would almost phrase
it differently, actually, which is

that a hundred thousand dollars a
year is just, is something that if a

company has a hundred engineers paying
a hundred grand a year is something

that they would do to solve a problem
with like medium below annoyance.

They are like a hundred
percent company is solving.

It is throwing much, much, much more
money than that at thing like not huge

problems, not even the most critical
problems of the business or the most

important expenses in the business.

I think it's, it's kind of like
useful to think about salaries.

For example, just to kind
of give you a data point.

If there's a hundred engineers
in the company, that company is

paying $20 million a year in.

Probably more like $20 million a year.

You could be 0.005 of that and
charge a hundred grand a year.

And it's like, it's just,
it's just not a big deal.

Like They're the numbers they're
looking at, and the numbers are used

to dealing with, especially because now
they have a procurement department, a

hundred grand a year standard standard
software cost, a hundred grand a year.

Absolutely.

All day long.

Michele Hansen: And, you know, the thing
to think about with that is that they

have that $20 million investment in their
engineers, and you know, speaking of

like to Tuple, for example, to spend a
hundred thousand dollars to a much higher

return on that $20 million investment.

It might be a very small percent of
that total cost, but even if they get

a 1% or a 5% efficiency improvement,
or they save those developers X number

of hours per week, which is more of
the category that Geocodio falls in,

like that is incredibly valuable.

Ben Orenstein: Yeah, totally.

And I wish they would think about that.

Exactly like you placed it, like you
said, it like a hundred grand a year is

half a percent on a $20 million payroll.

And so it would be great if I could
just say tubal makes you 0.6% of a

percent uh, more efficient and therefore
you should clearly pay me a hundred

grand a year and they would go, yes,
that makes perfect logical sense.

I agree.

It doesn't quite work that way.

It'd be nice if that argument
like resonated better.

But in the, in the bigger
scheme that, that does work out.

Yes, exactly.

If you, if you're making them
more efficient the ROI can be,

can be there for big numbers.

Michele Hansen: Yeah, absolutely.

What's next on the.

Ben Orenstein: Um, Do annual
pricing with quarterly truths.

So charge a big amount per year and every
quarter, like so, well, first of all, have

pricing that gets, goes up as the company
gets more value as they use your product.

Uh, expansion revenue is
the best kind of revenue.

So if your pricing model does
not allow your most successful

customers to continually be paying
you more money, you're pricing.

And so what we do is we do, we'll say,
like, they'll say we want, we want to

buy a hundred seats and we'll go great.

Here's the cost for a hundred seats, by
the way, if you use more, no problem.

We don't need to do a whole negotiation.

We're going to put this on the order form.

We're going to put this in the agreements.

Once a quarter, if you go over it,
we'll charge you a prorated amount for

the additional seats that you started
using so that we don't need to do like

a whole, we're not just gonna like
float those seats for an entire year

and then catch up a year from now.

And we don't need to do a whole
new agreement negotiation.

We're just going to send you an
invoice for those, prorated amounts.

Michele Hansen: Interesting.

I think it's always interesting for you
to, like, we don't do per seat pricing.

Um, But we do do like volume-based
pricing for example, which is sort

of a, like, I feel like per seat
pricing is the most, most typical form

of expansion revenue and, you know,
they're getting more value out of it.

So you, they pay you more.

There's also, you know, volume
based, which is where we are.

And I'm trying to think of if
there's any other sort of way of

having like expansion built in.

Ben Orenstein: So the high-level
term for this is value metric.

Um, And I think your pricing needs a value
metric of some kinds, which I think the

the way to figure it out, it's just like
if the customer started getting 10 times

as much value from the software, what
would they be doing more of or using more

of, or seeing more of that you can charge.

So, is it, is it compute time?

Is it requests?

Is it users?

Is it, you know, tasks they
can have in the system?

Um, figuring out the answer to
that question is pretty critical.

For Tuples growth, a lot of the
times our expansion growth in a

given month will be like two or
three times what our new MRR is.

So the business is growing like
three or four times faster because

we have a good expansion, right.

Michele Hansen: Wow.

Ben Orenstein: Yeah.

Michele Hansen: I think the thing I
love about that too, is that you are.

Your incentives are aligned
with your customer, right?

Because the more value they are getting
out of it, the more you are charging them.

And, you know, there are some products
like gyms are the classic example of

this, that they expand their revenue by
their customers, not using their product.

And It creates this conflict of incentives
between the company and the customers um,

but something like expansion, revenue,
you know, charging for more seats that

aligns you with your customers and
encourages you to keep serving them well

and have a good relationship with them.

And also for them to keep using it because
they're getting more and more valuable.

Ben Orenstein: It also has to make
intuitive sense to the customer.

Like I use bare metrics and their
pricing has always kind of irked me a

little bit where bare metrics charges
you, bare metrics has an analytics

tool for like diving into your
financial data like your subscription

metrics, like churn and average
customer value and things like that.

And bare metrics, charges you a
base amount and then increases as

you make more money as your MRR
goes up, as your revenue goes up.

And that has always felt weird to
me because it was like bare metrics

doesn't make my revenue go up.

It tells me stuff about my
revenue, but it doesn't actually

increase the thing I care about.

So like, it has to, it has to
kind of work, whereas if your

team is using Tupelo, and you add
three more engineers to it, it's

because you like it, you like it.

And you want them to use it too.

And then they like it.

So it sort of makes sense,
it tracks you're like, yeah,

we're using the tool more.

We're getting more value
from it, we should pay more.

Whereas just being like, oh, you're
making more money than last year.

We're going to charge you more money now.

I was like, well, but you didn't,
you're not, that's not your value.

That's just like a value
that you decided on.

Michele Hansen: I think it's
bare metrics, I, and they are

redoing their pricing right now.

I've seen a couple of friends post a
rather long email they got from bare

metrics on their pricing changes.

That does not say what the pricing
changes are, but I'm curious.

I bet they have a sense that
their pricing was not aligned.

Ben Orenstein: I think they're struggling
with some pricing stuff right now.

And I think that email was
a big swing and a miss.

Michele Hansen: Yeah.

Okay.

So we've got about five minutes left.

We usually think that, you know, people
listen to software social while they're

out, say running 5k, and they are
probably approaching 10 K at this point.

So I apologize to your legs,
dear listener, or to your dog

who is tired of walking around
the block uh, so many times.

So can you give us a, just like
a quick point by point of those

remaining items that were on the

Ben Orenstein: right, I'm
going to do them all lightning

Michele Hansen: yes.

Lightning lightning rounds.

Ben Orenstein: All right.

Here's the rest.

Here's the rest of the things,
don't agree to a custom contract that

does not have a big price tag on it.

Make sure you negotiate that upfront
before you dive into the terms

and figure out what you agree on.

Put your price on your website.

It's good to have an anchor
there, starts at 20,000 a year.

So you don't people wasting your, charge
more for single sign on, even though

it annoys people, put that in your
enterprise to your charge a lot for it.

Um, put an expiration date on your
quotes, so that procurement feels

a bit of pressure to get them done.

Um, offer quarterly payments
instead of discounts.

If people ask for a big discount,
say, oh, we can't do that,

but you can pay in pieces.

If that helps.

If you do offer a discount, ask for
something in return, try that, do that

negotiation that we talked about, like,
Hey, can we feature you in or whatever?

Um, Keep in mind a hundred engineering org
pays $20 million a year in software or in.

Um, It can be useful when you're dealing
with procurement to say, you don't know

what you're doing and ask for advice.

I had a procurement person from Shopify
basically walk me through how they

buy stuff and he was very helpful
and it helped us get that deal done.

Ask the deal get done faster often
there's shortcuts or price points

that get the deal done easily.

For example some places require a
C-level sign-off for price points above

X, make sure you know what that is.

Ask about it and try
to come in under that.

If you don't get a hard, no, you
don't know where the limits are.

Uh, It's often useful to tell somebody
you're a tiny startup when you get our

security or an it request saying like,
Hey, can you fill out this a hundred

page security audit, say, no, sorry.

We're just three people, blah, blah, blah.

Don't get a SOC two upfront.

Not worth it.

You can get tons of deals done.

Even with giant companies without
it, we have um, create a reusable

security document rather than
filling up a spoke questionnaires.

Um, You can often agree to implement
things later in a contract.

So they say, we need X.

You say, we can do this.

We can agree to get X done
within the next 12 months.

And they say, okay legal cares
less about getting the deal done.

Use the white commenters SAS agreement.

You probably won't get sued.

I'm always included an escalator clause
that increases the price and auto renews.

When you eventually try to hire a sales
person to realize that most of them are

charming, hardworking, and not that smart
look around for a smart one instead.

Michele Hansen: There's so
much good advice in there.

Um, So what are the things I wish we could
dive in on a what a tremendous gifts to

spell all of that out, I feel a little
bit obligated to give you some advice

at this point and say, Ben, when are we
getting the sales for founders review

newsletter, where you start writing the
rough draft of your sales for founders.

Ben Orenstein: Hmm,
that's a good question.

So actually it was inspired of the
day because Nathan Barry shared that

he has a paid email sequence, like
a paid email course that he sells.

And I think that's an awesome format
where like, he can sort of like when

he feels like, if he adds another email
to the sequence and you're basically

buying it, like for like a hundred
bucks, you get like what, however many

emails are currently in the sequence.

And then at any additional ones.

And I was thinking, this might be a good
topic for this, where it's like, anytime

I'm feeling inspired, I'll pull one
of these points off, flesh it out into

an email, add it to the sequence of my
people who are in this position of needing

this information, get access to it.

Michele Hansen: That sounds awesome.

Hope to see that out there sometime soon.

Ben Orenstein: Well, thanks Until
then you can follow me on Twitter.

and I'll eventually talk about it there.

If I do it.

Michele Hansen: um, Awesome.

Well, thank you.

so much for stopping by Ben.

Such a pleasure to talk to you, and
I hope that we will get more writing

from you on sales for founders.

Ben Orenstein: thank you.

Appreciate that.

Happy to come by.

Michele Hansen: And that will
wrap up this week's episode

of software, social, Colleen.

We'll be back with me next week.

Make sure to check out this week,
sponsor a cloud forecast to manage

your AWS bill@cloudforecast.io.

Creators and Guests

Michele Hansen
Host
Michele Hansen
Co-Founder of Geocodio & Author of Deploy Empathy
2022, Software Social