September 17, 2019
Heavybit Introduces New Operations Manager: Storee Moss
Storee brings experience in human-centered design and practices to help Heavybit clubhouse members connect, share lessons and collaborate.
Thank you everybody for taking a couple minutes out of your day to learn about self-serve go-to-market (GTM), a topic near and dear to my heart, I hope to be at least not the worst zoom of your day, given that we all live in zoom land these days.
You've heard a bit about my background. The part that may be more relevant, for the past 18 months or so since I left Heroku, I've spent it doing board advisory work for primarily developer-facing startups as well as some nonprofit organizations. One of the really rewarding things about being able to work across the range of companies that I do and at this stage is-- and there are probably about 30+ companies that I'm an angel investor in-- you really get to see a lot of the patterns that are surprisingly common when you're in the trenches every day. It's kind of hard to know what's unique and tough about whatever journey you and your company are on personally, versus, what's quite common to experience as a community.
I hope today to illuminate a little bit of that and share what I've seen working across a bunch of different companies, as we all look to increase our growth and revenue in this increasingly difficult time. This is a topic that I could literally spend hours and days talking about, but I'm really going to try and compress some key insights out. The other element of time here of course, is that in the current environment, all of us are under new pressure to really be focusing on our growth. And of course, with a little bit less margin of error, getting things wrong. So if I can help you avoid some of the mistakes that, at least I've made in the past, it will be mission accomplished. The other caveat is, I'm very much a frameworks person so this is going to be a frameworks presentation.
There's a lot of interest in self-serve as a thing. It's a topic that is getting a ton of attention and an important kind of theme in our industry. It's obviously been a trend particularly for developer-facing companies for a long time now. I think in light of how the current market environment is, it's getting even more attention for a whole bunch of reasons What is it? It's a lot more predictable than a traditional enterprise go-to-market. That can be really satisfying, especially in times of high uncertainties. But more importantly, at the end of the day, it's about having a much lower and much more efficient, go-to-market and customer acquisition machine.
I've had the pleasure of working a bunch of times with Tomas Tunguz, you probably know him from his blog. He's a partner at Red Point. This is a slide that I stole from him, basically looking at the sales efficiency of a bunch of software companies. And not surprisingly, when you look at the list, those that are kind of most self-serve oriented, and the core of their DNA tends to outperform in terms of efficiency. So that's obviously a really attractive thing in terms of the economics of your business, especially when we're all trying to manage cash that different way.
are a bunch of other factors that I
think are really appealing to founders. Building
a self-serve go-to-market, it
certainly isn't easy. I hope one of
the things I can share today is,
it's not as trivial as just putting your credit card form up
and waiting for customers to come. It
has much lower organizational complexity and
risk than building the enterprise go-to-market, which
is where so many companies not only stumble but
have kind of really unpleasant and
kind of gear-grinding experiences.
there's just a couple things to highlight there. One
is, at the end the day, building
self-service is a systems problem.
It's the kind of problem that hasn't been
solved. It's metrics oriented,
it's process oriented, it's more of a machine,
and founders are drawn to it. It's
just a more satisfying problem space.
The second, which is a little bit of
a more nuanced point is the differences.
It's like the
difference between meal kit versus
The point that I want to make there is,
I get a meal kit from a service or a store,
I'm on my own.
As the customer,
the expectation and burden of success,
is clearly on me.
When I go to the restaurant,
every part of the experience is the
responsibility of the restaurant,
from the quality, of the parking, to
the lighting, to the furniture, to
the utensils, it's really kind of
this holistic set of responsibilities you
take on. There's a similar thing
that happens with self-serve versus enterprise,
which leads to all of this kind
of organizational complexity.
Risk is the ethos. An enterprise sale requires this kind of very elaborate and engaged and expansive notion of customer success and responsibility, and that can be very tricky to execute. That's where a lot of the friction comes in.
I'll just add one caveat before I launch in. I'm a huge advocate of self-serve. With two caveats. One, in the long-run, it only works when it's paired with enterprise. I by no means hope to advocate self-serve at the exclusion of enterprise. It's essential that they go together, and that there are exceptions. It's not for everybody. It's not the only path. But for most companies, especially developer and infrastructure companies, it is the path.
Two kinds of modes I tend to see when I talk to companies: The first is the one that will probably match most of yours, is a free mode. You have no source product, whatever the case might be, and you kind of want to migrate self-serve. Or, I do see this about 20% of time, you're an existing enterprise, you got existing enterprise motion, you want to migrate down to self-serve. I'm going to focus more on the former today. And you're in the other camp, don't feel alone, that's definitely a pattern as well.
Here are some of the pitfalls and patterns. One of the main things I want to talk about is really how to frame self-serve, where it fits in the context, and how self-serve and enterprise relate. I'll spend time talking about aligning marketing, self-serve, some of the data infrastructure pieces, and ultimately ownership. So hopefully these will become a little clearer as we go through.
There are two
slides in this presentation that
you should pay attention to. This is one. It's
remarkable to me how much as founders, as
technologists, as product people,
as marketing people, we pay attention to the evolution and changes in
technology trends. We
all see the new frameworks and tool
sand databases, we read
HackerNews, etc. We have these
refined aesthetics for looking at
technology trends and migrations and patterns.
But as a community, we
end to not have as much an understanding or
an aesthetic for the evolution of go-to-market itself.
We tend to think about go-to-market as a static thing that was born out of fire however long ago and now we're all just trying to wade our way through it.
One of the main points I hope to make today is that go-to-market evolves quite rapidly. And insofar as you can understand its evolution, and understand those patterns, you will be much better able to capitalize on those in your company. A classic kind of version of go-to-market that existed back in the 90s-- Somebody's selling an Oracle database to a CIO, on a golf course, with a Gucci shoe sales rep.
That's kind of the mental model that we have, and I think a lot of us find that very unsatisfying. Why? Because in that model, there's kind of an asymmetry between the buyer and the end user, right? The CIO buys the database, somebody a million rungs in the organization away has to use it. The CIO buys the expense reporting system, the CIO buys the web conferencing system. There's this asymmetry between buyer and user, the quality of the experience with the product tends to diminish. And that's why a lot of us have a little bit of this enterprise-phobia and skepticism, rightly so.
I'm not going to focus on that as much today
important to understand that was
kind of where the world was in the
90s. I don't think we understand
just how revolutionary
the development of SaaS was for the
new go-to-market motion. For
the first time, with SaaS, I could
sign up and enter my email address
and get an application in an
instant. This was a radical idea. In
the 90s, if I wanted a CRM system,
I would buy it, wait
for the deployment to happen for 12 months, and
then I would finally put my fingers on it for the first time.
Having a trial motion was also radically different. To be able to think about selling to department first and then sell up to the enterprise, that kind of seed and grow motion, that was also new. Now I could sell to a team because they didn't have the burden of the implementation complexity that would otherwise require dragging in the C level IT organization. With search, I now had an easy way of reaching those people because I could buy keywords and other kinds of advertising.
What's new is
what I call go-to-market 3.0. That's
what's obviously emerged in the past 10 years.
That's the context in which true self-serve
exists. Instead of selling to the
department first and then selling
to the enterprise, we're going to
start with getting adoption for
product at the individual level, then
migrate up to the team via self-serve online motion, and
then ultimately have an enterprise motion on top of that.
But among other things, is an understanding that each of these three motions is selling to the C level. Go-to-market 1.0 that was one motion, in go-to-market 2.0, these were two distinct motions organizations. This isn't about just one go-to-market motion. This is about distinct ones that need to align together and as an organization, an expertise that you're going to need to have across all of these.
If you then kind of rotate that free team
enterprise, you can kind of run
those across what the customer journey is,
or kind of a customer lifecycle, and
see how these things kind of map out. This
is the second slide that I ask you to pay attention
to today, if you ignore the rest.
This is what I call the 1-2-3 model. If
anybody here today has ever worked with me at Heroku, they
would have seen this before, this
was really kind of my North Star for the organization, our
growth from as you heard about 35 to 300 million.
here is that there are really kind of
three distinct but adjacent business that
you're ultimately running. Now for
today's talk, we're going to kind
of leave out the enterprise piece, we're
really just going to focus on team and self-serve. But
it's helpful to think about these as again, kind
of distinct channels that you have as you are migrating the
user across them. You probably
already know all that. What's really
interesting is how predictable
and repeatable the value proposition, the
go-to-market motions, and the metrics
are across these pillars.
That's really where the helpful patterns emerge, as you think about what your self-serve business is. Kind of implicit in that is saying, the value and the value proposition of your product for a free individual user is going to be distinct and different from value proposition of your team user. So as opposed to thinking about self-service just to go-to-market motion, it really has to be holistic and has to be about a different value proposition. Then on top of that, it's going to have a different go-to-market motion and you're going to measure the market differently.
interesting about this ism if you
look across all of the all the companies that are kind
of adopting, again, what I consider
a 1-2-3 model, which is anybody
trying to go from freemium kind of free,
individual developer adoption all the
way up through enterprise,
it's remarkable how much the value proposition
of the products and those tiers align.
So I'd argue that
in a free product, the value
proposition tends to align to creation.
individual developer, I'm using
Herokum I'm deploying an app, life's good. I'm
a individual using a tool like Figma. I'm
creating the same kind of single user
mode that I would be in for creating
a UI. I'm having a great time.
That is very distinct from the value
proposition off collaboration, which
is fundamentally, how as a team are
we organizing our work around a shared process.
So Heroku and single player mode versus Heroku
and team mode, very
distinct things. It's essential
that you approach self-serve with
that intentionality because you're
ultimately going to be monetizing
self-serve on that product. With
free, what you're trying to do is
drive adoption and engagement with
team then with self-serve you're trying to
take some percentage of that and
convert it into ultimately what is typically a monthly MRR
The punchline again here is that one, the value proposition with a collaborator of the product is different. So this has to start from a product-value orientation and the metrics are going to be different, and they're going to be predictably different in that almost always what you're measuring on 1 is engagement. And what you're measuring on 2 is MRR.
What's really interesting and
what I look for both as somebody creating products or as an
investor, or as a coach in other
companies, is how you do that
transition up from free to team and
then ultimately from enterprise. What's
most fascinating for me is looking
at that nonlinear value proposition
change as you go from free to
team. When you have that,
it's almost like there are
two product-market fit or customer
discovery cycles that need to happen.
One is you
have engagement with a free thing, or
individual thing, but that is going
to be distinct and different,
complimentary but distinct, and
different from that value proposition in the team mode and
I'll give you one of my favorite examples, which
is Postman. I think I saw some
folks from Postman are on the call. Hopefully
I'll get this right. This is kind
of what I took away from talking to those folks.
So Postman is an API creation, authoring,
management tool. You can think
about individual mode as, 'this is a
really useful utility for a
developer to organize their API creation activities.'
Okay, that's great. Well,
in the team mode, what it becomes
is, 'a way for multiple teams to
organize what is a distributed development effort.' If
I'm no longer building a monolith, and
I'm now building across multiple teams with different services,
which is a pretty common way
for engineering organizations to
operate these days, how you
coordinate those teams, so you can
build a holistic system is a really
big strategic business problem.
postman found, at least in my
interpretation, is that by using
that same tool with modifications, it
now became this way of orchestrating this
really strategic business process. Similarly,
with LaunchDarkly if you just look at
it as a utility for creating feature flags, you
can say, 'well gee, that's
convenient. I can write it myself
or I can use this this thing off
the shelf and I'm saving time.' That's
kind of an interesting but limited value proposition.
think about LaunchDarkly in team mode, what
it becomes is a way for a team to organize its
business process in between PM and engineering, about
how features are actually being created and deployed. So
it almost becomes a product management process tool
on rails. It's a very distinct
value proposition, as you go into
fundamentally enabling these
collaborative business processes.
a hugely valuable thing. That's
where you start really driving conversion. If you're just
offering the same product, and this
one has some modest differentiation
from the free to team, you're going
to have limited success in conversion. It
has to be a distinct value proposition. I'll
go back one slide to just say, for
something on the enterprise side, what
comes after that almost universally is compliance.
Here's a Heroku example. I'm
an individual developer on free, I'm building apps, I'm
having a great time. I'm now using it as a team. So
now it's all about things like pipelines and
how I'm organizing my overall software delivery practice and
have multiple people contributing the same code base and
doing testing, all that kind of good stuff. Then
in enterprise, it becomes again
distinct, where now it becomes
primarily about what the compliance
is with the organization, which
means specifically, typically
security, HIPAA, all those kinds of
things, although there's also
important kind of business process
elements there as well.
What's also interesting then, is
if you could think about what your
different customer facing functions are--
from closest to the customer marketing to
further customer biz ops, so
marketing, sales support, customer
success and retention, and then the
back office pieces-- and you can
think about how you then array them
across these different pillars. The
point of the slide isn't that this
is the right answer. The point is
that you have to think differently about
who owns these pieces in these different modes.
example, who's the primary marketing
owner? Is it a traditional
programs-oriented marketing owner?
Or is it a PMM marketing owner? So,
often where companies go sideways, and
why I find this framework so helpful, is
it's really hard for an organization to
execute well,in any one of these pillars. If
you don't have some way of keeping
these things separate and
rationalized, you're just going to have
people running over each other all the time, and
it's going to make a bad time even worse.
really important that you understand, what
organization and who are the people in
the teams that own these along the way. As
an example, one of the more interesting discussions is,
who owns sales? Now sales here,
in the free mode means, wow
are you driving adoption? Though
not of course, it's most often a
marketing function. As you get into
team, there are a lot of different
ways of slicing it.
This is an area where I have a lot of different conversations with different startups. Sometimes that's done by marketing, which is to say, there aren't any reps at all. Sometimes you have an inside sales organization that's dedicated. That's how we did it at Heroku. Sometimes you have a support organization that, in addition to doing support, is effectively doing sales in that self-serve mode.
I will say I'm increasingly a fan of the idea of support again, especially for the products that we tend to work with as developer-facing companies, of having a combined support/sales organization for the self-serve tier. Again more to unpack there, but hopefully gives you some of the things that are important to consider.
of the most fascinating things I
see when I go talk to
organizations about their
self-serve efforts --and these are often companies that
have quite robust self-serve efforts in place-- is
who owns the number. So you're
creating a self-serve business, you
are, whatever the number is you're committing to for
the year, 3 million, 5 million, 100 million, who
owns that number? It's
fascinating to me that this is a question that
seems to elude so many companies or
they get it wrong.
When I go
companies and I ask them this
question and they say, 'well, I
don't know. We don't know who owns
the number.' Then I try the CEO, I
say 'okay, well you own it.' That's
the default state, where the CEO owns
that, which is not always a great
model. I think the common practice
is to have sales own it. I
have to say that I'm pretty skeptical of
that approach because typically what
will happen is you've hired some sales exec, who
comes from that 2.0 world and
you're asking them to participate in
a 3.0 land and they don't get it.
This is probably one of the most challenging
things overall, is there aren't
that many people in the universe as
a percentage who've done sales 3.0 versus 2.0.
Why framing is so important is because
they will tend to drag the company
back to a 2.0 frame or they'll just
be kind of a frame mismatch.
A classic example I
see all the time, here is a company has,
a bunch of free adoption, it's going
great. They hire their sales exec
because their VCs told them to. As
a standard product technology founder, they're
like, 'great, you go work on all
this mysterious stuff.' Then they
start immediately jumping to enterprise. Even
in those environments, if you then
try and backtrack and have some
self-serve efforts emerge, sales
will discount it, sales doesn't understand it, they
will kind of yoke the organization
back towards enterprise because
they're operating in that 2.0 model.
It's possible for sales to own it, but
I'm skeptical because it's often hard
for them to really understand the value
of having self-serve as a viable business. Then
you're down to marketing or product. At
Heroku, we had a hybrid function where
marketing owned the self-serve business, which
was pretty substantial, over 100 million when I left. I've
also seen models where product can
I do like the product orientation and ultimately, I even like aligning product to those channels, because really, these are three distinct product lines. Even having PM assume a GM function for that product line business, because of course, holistically the product, that go-to-market motion, the metrics are going to be different for each one of those tiers.
Couple tips as I almost
land this at 30 minutes. Hopefully I've
given you a little bit of insight to begin to
think about how to work on these problems or
some mistakes I've seen. The key
thing is to have the right
organization and ownership in
planning your self-serve and team
efforts. The biggest problem that
I see is companies not being
intentional and explicit about what
the theory of their business is and where
their customers are coming from.
Are your customers coming from lead
gen, 'white paper'-gated content capture which
is a classic sales 2.0 motion? Or
are they coming from you converting them
from being engaged active users, to
then some 'teams' product? They're
entirely different businesses, entirely different motions, yet
we tend not to be as intentional or as
explicit as I think we should be. I'll give you another
analogy here. If you're running a
product or an engineering
organization, and you aaren't clear
about whether you're building for
on-prem or for cloud, imagine how
confusing your engineering and
product efforts are going to be. It
will be a total mess of people just bashing against
each other and you wouldn't understand why
What happens all the time in organizations,
as they plan their go-to-market because
they don't have the right context, they
don't have the right framing for
what their customer journey is, for
what the theory of the business is, for
which of these modes they're operating. The
second thing is, when you build these organizations, think
very much about what the ownership looks like and
what the kind of skills that you're bringing in are.
Another super common anti-pattern is
a developer-facing company looking to
build a self-serve business, hires a bunch of
people with marketing in their title, but
it turns out that they're classic
sales 2.0 dimension people. So then
what they start doing is buying ads and
doing gated content you can capture, which
is completely opposite of how the
3.0 model works. The 3.0 level model
is about driving product adoption. 2.0
model is lead capture, trial, sell.
If you are confused about those
things, you are going to waste a
whole bunch of time and money. That
will lead to your 'VP Marketing Early Death Syndrome,' where
you churn out your VP Marketing in six months. That's
super costly and emotionally taxing for
the organization and a huge waste of time. It's
important to be thinking about what
are the skills the marketing organization that
you're building needs to support this?
Act holistically. As
I was mentioning, this is not just
about a price point or a Stripe
implementation. This is a distinct
business value proposition. Plan
for the journey. I
could spend hours talking about
how, as a self-serve business, it
really relies on having a very robust understanding of
customer behavior and activity, as
well as building automated billing and
provisioning systems. That is a
significant investment. That is a
How you do
that as a startup is really tricky, but
it's also really important. That's
a particular area of interest of mine. Lots
of interesting things happening in
that space to make it easier. I'll
leave with my last point. This
was particularly true a couple years ago, it's
less true now. There was a kind
of a consciousness at companies
like Heroku and GitHub in the early
days, that going all the way to
enterprise was going to be anathema
to the company values or goals, and
would somehow corrupt everything that
had made the company and product successful.
I couldn't disagree with any of those
statements more. If I see a
business that's just done free and self-serve, and
has resisted enterprise, I will see a
business that is living up to only
a fraction of its ultimate potential. So
in the long run, self service isn't enough. You
have to do the self-serve to
enterprise transition as well while
you're keeping all of those pillars healthy. That's
the point. You're doing all three.
For me, the question is when, not
yet, and as a benchmark, I wouldn't
even begin thinking about it until
your self-serve business. is at about
10 million ARR. So don't worry
about it too early. But if you're
up past 30, and you haven't done it, then
I would be pretty suspicious.
Hopefully that's a helpful framing to
help orient you and your teams around
thinking about self-serve.
I recently recorded an episode of EnterpriseReady podcast, where I spent a good hour and a half talking about this stuff in much more depth and probably more coherence. So I encourage you to check that out, I love talking about this stuff. I'm an official Heavybit advisor as well so please feel free to reach out to me at the email address.
There's a baseline of capabilities you need to offer a self-serve cloud product. Let's pick a random example: FedRAMP. It's a strict compliance regime, which certainly doesn't make sense to have in your self-serve product. Compliance is nuanced. It's not just about these certifications, it's about how the product aligns to a company's own compliance regime. My default case would be, most anything that's kind of advanced compliance is clearly an enterprise capability. I would be very careful to not muddy the waters around what is just base requirement versus what is real additional value at the enterprise level. If my product helps you become GDPR compliant, that's clearly an enterprise feature.
Trials are an interesting case. Again, it's not one size fits all. I think trials make sense if there's no individual value proposition for your products or there's very limited long term use for an individual. So if you've been doing trials and you want to add a self-serve component to that, I think that makes a lot of sense. I would think about just having the self-serve be the main offering in the trial for the enterprise. I tend to be skeptical of trials in 2.0 and 3.0 companies.
That's where that kind of meal kit
versus restaurant analogy comes in. A
lot of the costs of going enterprise are hidden. You
don't realize the amount of
person time and hand holding there
is for every aspect of supporting the
customer that goes into being an enterprise business. As
an enterprise, they have
expectations about how they're going
to interact with you as an
enterprise buyer. You have to
effectively have all the API's, which are
incredibly complicated and costly.
That said, I want to be very explicit about something. If you're selling to a department within an enterprise, that's totally fine. Enterprise sales is selling to the C suite with compliance features versus selling to the department with collaboration features. Those are my definitions. If you can get departmental customers, that is the key to your business, because those are the ones that are ultimately going to migrate up enterprise.
The other thing I see happen as an anti-pattern is, companies really want to go to enterprise and they skip self-serve. What ends up happening is, you end up selling via enterprise channels, which is very expensive. Essentially, self-serve deals, let's just call them deals under $40-50k annually. When I look at enterprise sales at an organization and they're doing $20k transactions annually, those should be self-serve deals. The biggest failure mode is not being intentional about where you are in the model and being indifferent to whether your customers are coming from trials and traditional lead capture versus via a freemium conversion process. There can be a tendency as a CEO to say those are just marketing tactics. Choose whichever one's best.
My message to you is, this
is as different as being cloud or on-prem. These
are existential questions about the orientation of
your business and if you're not
intentional about where you sit in
this model, you are going to have a
really bad time. You are just never
getting alignment and you're going
to be calling up your friends and
being like, "wow, this job sucks. How
come? My sales and marketing people
are fighting with each other all
the time, and I can't get anything out of
any of them."
When we talk to other founders, that's pretty common. Why does that happen? We're not being intentional enough about our go-to-market. Be intentional about how you're hiring and building your marketing organization and who you're doing it for. We've talked about self-serve but we haven't talked about what marketing motions and what kinds of investments make sense to build for free. That's where most of you, if you're under $3-4M revenue, probably should be focused on, building at the top of the funnel and adoption and getting that machine going so ignore that.
Typically what happens is, or at least what I've seen is, if you've built a freebie thing that's getting engagement and adoption, you've got a self-serve machine. If you crank that up to $10M ARR or somewhere in that ballpark, then you start doing some exploratory enterprise, probing, and selling. So typically you're not starting with a Head of Sales, you're starting with a sales rep who is going to be much more solution-oriented. Not your traditional kind of transactional or repetition kind of sales rep but one who's more comfortable with helping you as a CEO, who's helping your product teams, helping your marketing team.
what that value proposition is because
if you don't know what your enterprise proposition is, you're
going to have to tease that outwith
When you're ready for 3.0, it isn't like, "boom,
let's hire the head of X or a big
fancy sales executive." By far the
most common example is early days, you
hire a sales exec, then you end up
getting rid of them nine months later because
the whole thing is burnt out and you had a bad time.
Getting customers is incredibly hard. What the VP of Sales will say is "how come you're not giving me better leads?" and you'll point to the marketing exec and tell them to deliver better leads. Then when you have a 1:1 with your Head of Sales, they'll say you need to fire the VP marketing because they're not delivering the leads. The problem isn't the VP of Marketing. The problem is that you're operating on the wrong model and you have no repeatable way of actually generating pipeline and business.
The whole point is to take people from 1.0 to 2.0 to 3.0. If I had to interact with a different company or a different brand or a different product, that would be really goofy. So no, the whole point is that this this journey should be holistic and connected and that you're kind of moving people through these stages without forking the brand.
I've had a whole bunch of conversations with
existing or semi-mature open source companies,
which I'll define as being older than
5 or 6 years old, because the whole
model they went to market with was,
get a whole bunch of free adoption, and
then do some enterprise sales. They
did 1.0 and 3.0. That was their
pattern. They woke up and realized
two things. One is, and this is I'm
saying exclusively open source companies,
they realized that they were managing
a smaller number of larger accounts and
they weren't gaining new customers.
And on top of that, if you went inside those organizations and talked to the people, you realize that they kind of supported 1.0, they supported the developer community as kind of this lip service, "oh, it's good for the brand." Sure, but it had no connection to the business and driving leads and driving revenue, driving dollars. Sometimes that becomes enshrined in all of this cultural cruft of saying, "no, we can't possibly interact with these people on a marketing basis because that would violate some unwritten rule of developership," when in fact, what these people actually wanted was to be able to take these technologies and use them more deeply in their organization.
that that model is dead. So if
you're a new open source company and
you're thinking about doing 1.0 and 3.0, I
can tell you that all the existing ones are
trying to go back down and reinsert
2.0, because they don't have any
way of driving new pipeline. The
other thing I'll say is, which is a
little more controversial, there is
no distinction between an open source and
a cloud company. Because if you're
not doing cloud-first as an open
source company, you're probably not
going to survive.
But there's a guy who ran Heroku whose whole business premise was making cloud versions of open source products. So that might be a topic for a different day. But on-prem, don't do it. I don't care how many customers want to pay.
That's more a function of the AI business than it is of the 1-2-3 model. Everything that I've come to understand about the AI business is, margins tend to be poor because it's so resource intensive. It tends to be very professional services heavy, which is implicitly a 3.0 business, not a 1.0 or 2.0 business. So, you know, there are exceptions. If you've got margin problems, you have value problems, and crafting value out of AI is super hard. That's just part of the space. It depends on what your definition of a good margin businesses is. Traditional SaaS businesses can operate at 20-30% and still have a good business. But there definitely are kind of yellow flags associated with the AI business in general.
As I mentioned,
I'm a fan of, at least in
the beginning, building integrated
support and sales teams for self-serve. Because
in my experience, the work that those
people are doing, the account
managers who manage self-serve, it's
almost always technical and support in nature.
So why not actually integrate those
things and just have it be a
support team that is oriented
around talking, not only to
existing customers, and this is the
difference, but to prospective
customers as well and helping get
them through the buying process.
So it's not to say that they're exactly the same as just taking a support organization and drawing them in. But I do think the same team and the same people with the right training can get you there in the most efficient way. The caveat is when you're ready to add 3.0 , then you need a different kind of account management to go into the self-serve accounts and aggregate the right ones and get them ready to go from the 2.0 to 3.0 motion. But that's a separate thing than going from 1.0 to 2.0, which is kind of primarily what we're talking about here.
The metrics are
about how you're doing or about the engagement and
adoption of your product. In almost
every Series A deal I've seen, what
investors are looking for and what
they expect is that you have a product that
has developer engagement and adoption. What
they're giving you money to do is
to work out how to build 2.0 once
you've done 1.0. This is another
anti-pattern I see in fundraising, maybe
even later than series A, is to
confuse building revenue with building a machine.
Speaking for myself, I'm not looking at the business as a function of the revenue, I'm looking as a function of the opportunity. Frankly if a Series A company came to me and said they closed a $100k deal, I would probably treat that with some suspicion because I would worry that they were over rotating to enterprise, which I think wouldn't be sustainable. I'd be much more interested in what their adoption is, which ultimately translates into potential for building self service.
I think you can make it work in different ways. At Heroku, enterprise was a separate part of the organization. We even had online sales as part of marketing. But there are a lot of different ways of sorting the org. The org structure isn't as important as the intentionality. Let's say you have a separate org for self-serve, okay, that can work. Well how are they interacting with product?
One of the key things that I've tended to do is create standing monthly meetings, across sales, marketing and product. One for the free business, one for the self-serve business, one for the enterprise business, to give the clarity of allowing each of those cross functional teams to have a common set of priorities and backlog items within each one of those verticals. Because if you just have one product backlog for the company as opposed to having some view or lens that allows you to think about it based on a business line, it affects your ability to really prioritize. How do you begin to rationalize those priorities in a way that's coherent, high trust? You have to have lanes for these things operate.
In some ways, this is a blessing. I'll tell you that one of the positive things I've seen-- this is an opportunity to save your organization, reset your people, have a conversation, and realign your organization around a better marketing model. You get a free pass to shake up your organization and realign without having to ruffle a whole bunch of organizational feathers. I don't want to minimize any of the challenges of the environment. But for the products that we sell, selling, engaging, and marketing online, given that we're all nerds, we're at least better off than most.
You can think about CI/CD as being a team value proposition, right? Anytime you have multiple developers working on a code base, there's a whole universe of stuff that tends to come with it that's less important. If you were just an individual developer, writing by yourself, the reality is that we tend to have this idea, this mental model of developers as solo practitioners. What it means to actually develop and work in a team is very different from what it means to develop and work as an individual.
So an example is something like source control. We're all familiar with it. We all use it every day. It's implicitly a team value proposition. Other than backing things up, I don't really need source control. Think about the individual value proposition of Dropbox which is, I can pack my stuff up so if my computer catches on fire, it's still there and I can have access to stuff remotely. That's great, super valuable. Then think about the team value proposition of Dropbox which is, teams can collaborate and stay synced.
Most enterprise sales are about business transformation in some way. What an enterprise is buying a product for, is to be good at a business process. This is even true of something like Heroku. This is one of the more strategic things that you as an organization need to focus on. That's what commands the C suite attention. There's some fundamental business change that's trying to be affected. Great enterprise sales align to that. What company isn't trying to fundamentally grow its customer revenue? To use kind of a cliche, compliance is a good anchor, but also something that is really transformative and strategic to the business.
A lot of where developers get frustrated is like-- "I'm selling a Kubernetes run time. Why isn't that the most strategic thing in the world? Look how cool and different it is?" Well, you've got to build the delta between the potential of that product and technology change and its realization to make it as simple as possible to spoon feed to have an impact on transforming an organization. That is the difference between an individual product and an enterprise product. It's hard and you have to have empathy for organizations to do it.
I think the key thing is that you better start with a product and product vision that is distinct from the enterprise product. One of the things that you see is failure modes in companies going from 3.0 to 2.0. A common path is, they take a product that ships usually with a busload of Deloitte consultants and what's implicit in the sale are all these people and all these processes that kind of surround the product and take it from sale to implementation. That smooths over a whole universe of edges that otherwise exist and that's okay for 3.0 for an enterprise sale. That's got to happen in order to really have impact on the business transformation.
But if you don't have that, it's a very different experience holistically to create value for self service, create value for a team. And so I'll see companies take an enterprise product and put it onto the self-serve channel and say, "go out and have fun." Of course it's chaos because it's a product that has no meat, that has no experience or orientation to actually serving those customers. Intentionality has to start with a product first.