Thank you so much for coming and thank you
very much for having me. I'm honored to be here.
I know that a number of you had sat through Bill Lapcevic's
speech which was maybe about a month or so ago talking about overall what BD is, how it's defined,
how it can be used in startups.
I really wanted to have a much
more personal approach to this talking about my experiences, how I grew up with
startups and BD, how I've leveraged some of these
tools and then how over time I got into what
I call the BD toolset that is very much self described.
Hopefully we'll be able to help you guys out in terms of how
you leverage BD throughout your startups and opportunities.
A little background around me, I am local; I actually grew up in San Jose.
I know it's fairly rare to be from California
and work in tech, but here I am. I went to school at Stanford and got
my BS in electrical engineering. I went on to work at a small semiconductor
company you might have heard of; spent four years there doing a couple of different roles,
anywhere from having a quota as a technical
sales engineer all the way through a BDM handling relationships with folks like HP, IBM, Dell.
I went back to business school in 2007,
graduated and I wanted to try a stint in
professional services which lasted not so long. I joined New Relic at roughly about
employee 20 or so, grew to about 120.
After two years there, I was
recruited to go to Yammer where they did not
have a business development function; grew that for a couple of years and
then was acquired by Microsoft. I took some time off and now I'm currently serving as an
EIR at Trinity figuring out what I want to do next.
The one thing that I would note from my experiences
here is not that there are a couple of good companies in there, I had a great time, but really you should
never go to school when I go to school
because bad things happen when I graduate.
The dot com bust in 2001.
Intel is the only job offer that stuck after 11 other
startups and firms revoked their offer or ran out of money.
And in 2007-2008 the mortgage crisis; financial industry was hit pretty hard.
A little bit of background there.
One of the things I want to talk about is where
you start to partner and what kind of partners
you look at as you're evolving as a company.
Early on you're probably looking at
awareness as your number one goal moving into distribution, lead gen, and eventually of
course we all want to get to the trifecta of revenue.
When I joined New Relic we were nascent. It was 2008 or so, we had about 20 employees and we had one big
distribution partner and a handful of customers.
It was when Ruby on Rails was very new to
the market and APM and the Cloud was a brand
new concept we had to educate people on.
Lew Cirne was the founder of New Relic.
He actually had founded a company
before that called Wily Technology.
That company grew to about 80 million or so in revenue
and was sold to CA.
But one of the things that
Lew hated about the growth of Wily was that
enterprise sales completely outpaced his revenues.
It got to the point where he
was never able to get profitable.
He wanted to do things differently at New Relic.
He really wanted to leverage BD and partners and channels
and inside sales to get to that same kind of growth rate
without having to employ a huge enterprise sales team. And he focused on Ruby on Rails.
Building the ecosystem at zero,
we launched at RailsConf a couple of years back,
and our very first partnership was with Engine Yard. Engine Yard had roughly about 850 customers or so.
The value proposition was a number of
people are now moving applications from an
on-premise to a cloud-based hosting provider.
You are having issues because people call you every
time there's a slowdown, every time there's an issue. They'll go and say, "Hey, the hosting provider
is at fault here." But if I give you this tool, if I give
you the ability to get visibility into your application
then you'll be able to say, "It's actually over here. I can help you troubleshoot it, I can help
you look at the area in which your application
is not performant and then I can hand it off."
You would get happier customers, you have better relationships and
people don't leave, people don't churn from your platform. This actually worked out really well because every single
Engine Yard customer is now every single New Relic customer
from the get go. And we did the same thing with Heroku.
By then we had a couple thousand customers and we
were like, "Hey, this is a pretty good strategy."
We're going to call that distribution,
and we're going to expand upon that to get to ubiquity.
What we did was we started off in Ruby.
We then migrated to Java, PHP, .NET, Node.js
and we had to build relationships with all the
different hosting providers, all the different
platform-as-a-service providers in those ecosystems. Eventually we wanted to go to where all the developers were.
Tools such as RightScale, Pivotal, looking at Acquia, places where people were building applications; we wanted to be there and be in front of them
to bring leads in. And eventually to revenue.
We got to the bigger players, the
Rackspace, the Amazons, the Windows.
The note here is that these smaller partners that
are in your space that are very niche-centric
to you are going to be easier to build on.
It took us two years to get into Windows Azure. Not to say that we didn't have those conversations early on. It's the fact that it was a process where we had to build
out the ecosystem, we had to have partners, we had to have
traction and prove to them why it was important
for us to be. It was the same value proposition; it just took a longer conversation.
Within that we went from zero to 850 to over 2,000, to roughly about 30,000 or
so customers by the time I left New Relic.
Today I believe they're over 80,000.
From a ubiquity standpoint we have platform
partners and partnerships with tools and developers
across all these different technologies.
From a lead gen standpoint anywhere from about
5 to 10 percent of all of our leads that come
in to New Relic are through business development.
And I believe this is still standing where about 15 to 20 percent of our overall
revenue comes through our platform partners.
When I came to Yammer it was a very different story.
They were around for about three years,
they were about 200 customers and had gotten
to about five million enterprise users.
We had a viral model where people would go and
sign up with their HP.com e-mail address. Then I would be put into a network with anybody
else who signed up and I could invite all my friends.
That actually worked out really, really well.
We got to a million users in 18 months through that viral model.
Our sales cycle was to say,
"HP, you've got thousands of customers on our network.
Wouldn't you love to be able to get visibility to that content?
Wouldn't you love to have some sort of controls and processes
around what people were saying, and as an executive
team really be part of your corporate conversation?" The problem was though that once people
signed on, if they were active within the
first couple of weeks they would stay on,
and it actually would be a pretty vibrant network.
If they didn't, if within the first month
they were not engaged, they would probably
never be engaged and they would never come back.
Our problem here was we were trying
to drive engagement through BD.
What we decided to do was build
an ecosystem around ourselves.
We wanted to be the platform across all
these different enterprise apps, and we split
it up into a number of different categories: content management, customer relationship management,
HR, ERP, looking at things like ideation and innovation; anything that would drive users to come back
to our platform, use us more often and make
sure that we were a part of this conversation.
If you're a sales guy, how much of your day
are you spending on e-mail and Salesforce?
If you had the opportunity to share that Salesforce object,
that Salesforce record into Yammer and have a conversation
with product, or marketing, or customer success or
customer support that would hopefully get you to be
more engaged and enthusiastic about using Yammer.
Same thing with people who are NetSuite,
same thing with people who are doing things on Box, if you're able to take that content,
share it to Yammer, have the conversation around it â€” that breeds a huge amount of engagement.
On the flip side we were now the big players in the house.
We had the five million enterprise
users that people were excited about.
I was fielding a number of new enterprise apps that were
coming out that were doing things like Mindjet or
project planning, other content management,
the ability to do video and access chat, whatnot.
If you're a small player and you're looking to build into
something like Yammer the recommendation here is let's
figure out what they want, what their pain point is.
If my pain point is Yammer's engagement, and I'm
looking for other apps that will help me solve that â€” if you give me the value proposition of feeding
into my data stream and providing me something
meaty enough to engage with, that makes me notice.
What it actually looks like from a Yammer standpoint
is we use OAuth and YammerConnect and SSON.
Every single thing becomes an object.
We use OpenGraph, the Facebook-popularized OpenGraph
protocol to push objects into Yammer and make them
searchable so you have universal search across your
enterprise apps which is another value proposition.
Then of course through the activity stream
you'd be able to see what was going on,
engage in conversations, really piggyback off that viral
model and learn about new applications that maybe your
other colleagues are using that you weren't aware of.
At the end of that we found that users with two or more
integrations were 20 percent more actively engaged
on a weekly basis, and it shows in the numbers.
Within that first year, and I apologize if this
information is a little dated, I left Yammer in 2013, but the number of people that were using the apps,
that were companies using apps as well as the
amount of information that was now being pushed
into the Yammer knowledge sphere through the Yammer
platform helped draw that engagement more and more.
Another side of Yammer outside of building this viral model
and then selling top-down was the fact that Yammer, if you weren't excited about it, if you weren't
already on Facebook and familiar with the usage
model it was actually a little bit hard to engage in that it required some sort of change management.
It required some sort of transformation of
you getting off of e-mail, talking to people, frankly willing to be open about what you're
talking about and share with your colleagues.
There's a level of visibility and transparency
here that is lacking in a lot of corporations.
To help solve that we worked with a
number of SIs and innovation partners.
Deloitte was one of the very first that we
worked with out of Deloitte Australia.
They brought the Yammer practice into the US and it was the
very first software that was deployed at Deloitte globally.
There they built a practice around it.
They helped pull in customers.
This became even more important once
we were acquired by Microsoft.
Over 90 percent of Microsoft software
is sold through indirect channels.
They have a large direct sales force but those are actually
helping those channels push that software through.
So we're piggybacking off of the successes we've
had so far working with Microsoft and that
brings us to new enterprises, new regions.
Again, by the time I left roughly less than 10 percent or so of all deals were brought to us through our SI partners.
What did I learn through those two experiences?
This, again, is a very personal view of what the toolbox is.
How do you think about when do you leverage,
which tool and when, and how do you really get
that leverage as any early stage startup? The first layer, co-marketing and channel programs, I would
consider those that don't consider technical resources, that
you can do with some business people and some negotiations.
The product integration and feature enhancement
does require technical resources but have
their pros and cons for various reasons.
And of course, eventually there's the M&A aspect once you get big enough or there's an
opportunity for somebody to acquire you.
Co-marketing is a pretty simple one.
It's like, "I love your product, you love my product.
Let's put each other's logos on each other's pages." Which is nice, it's good. I'm aware of that but what
does that really bring me? Is it really sticky?
The one thing I would advise is co-marketing is fantastic
in parallel or in conjunction with some other tool.
If you have a product integration, if you have a feature
integration, co-marketing is very important
to build that awareness of what's going on,
what's available out there to get to that customer base. If you build a product integration with another company and
you don't tell anybody about it no one's going to use it.
If you tell everybody about how great your two products
work together but they don't actually work together
then you lose a lot of the value of the marketing.
It's something that needs to be consistent and
like any marketing it needs to be repetitive.
A couple of examples: This is pure co-marketing.
Softlayer has an ecosystem where they put up websites.
They have each individual partner website.
They tell you about it. They lead
you back to your partner website.
Again, useful in the terms of
awareness but it's not that sticky.
If you don't co-market, if you don't continue to push e-mail
programs, if you don't talk to customers or you don't
train sales people then this doesn't really mean anything.
Similar to Amazon. They actually have two versions.
They have their SAS co-marketing
page and then they have their AMIs.
Their AMIs are the ability to deploy a direct
integration into your AWS infrastructure.
The SAS marketing page is just this, a SAS marketing page.
They get 5x more traffic through their
AMIs than their marketing page.
A couple of things that I would look for, and again
it's a long list of marketing activities, but what I like to do when I bring on a partner and I have an
integration, I have some sort of a product fit there and there's at least a little bit of stickiness,
I like to do all these co-marketing things.
I think of it as a go-to-market package or go-to-market bundle.
You do joint PR, website presence, e-mail campaigns,
newsletters, webinars, white papers, all the above.
But you don't just do it once.
You do it every month, you do it every quarter.
You keep doing it. You check in on your partners.
You provide them with data and stats
on how well things are going.
You feed that back to them and say, "We should do more of this."
Channel programs. This is something that I'm somewhat
loosely defining but it gives you anywhere from a very,
very lightweight affiliate referral program all the way
through to a much more involved SI partner relationship.
Again relatively easy to get into especially if it's a referral program.
You say, "Here's my product.
I know you're a consultancy that works in this area.
Can you please refer me or refer your customers to me? Then if I do I give you a 10 percent referral fee."
The problem here is that there are so many people to work with.
There are so many mom and pop consultancies out there.
There are so many people specializing in
certain things that it's hard to figure out
who to work with and how well this will work.
I would caution to not do this until maybe you are a little
bit later, maybe you have more resources on hand.
It can be incredibly resource intensive just to provide
the overhead for this type of program if you are serious
about making this something that will drive revenue.
The same goes for the larger SIs.
If you are working with a Deloitte or Accenture,
often times to actually penetrate their ecosystem it requires a full-time head because you're talking about
getting the right partner, getting to the right program.
Each of those different offices are actually standalone
offices even though they lie under the Deloitte brand.
Deloitte Australia is not Deloitte US which is
not Deloitte Boston which is not Deloitte SF.
Each of those are relationships to manage.
Until you get to the point where you feel you have
enough resources and the partner and model you want to
go to, I would be wary of starting something like this.
On the positive side the revenue share is relatively
low and it could also bring you some great awareness if
you choose the right partners and have the right brand.
Some examples of these for distribution are ones
that are very large that you're probably aware of.
Certification programs like Microsoft or SAP or Salesforce
that have entire ecosystems around their products to
push their product into the market. And they're somewhat
like the Microsofts, every single time there needs to
be some sort of professional services custom deploy.
That's what makes these ecosystems very vibrant because they actually make a ton of money off of it.
There are also smaller affiliate programs such as the
NetSuite referral program or something like Twilio,
where your consultancy are building in
these APIs on behalf of your customer.
Even from the lightweight all the way to the larger ones
there's great examples of how people have made this work.
From a product integration standpoint, and this is where
we did most of our work at both Yammer and New Relic, it's the API integration. It requires some sort of OAuth or SSO.
You're pushing data that's relevant to your
customer across your different partner
products and there's a UI/UX integration.
The value of this is incredibly sticky.
Once you have gotten the buy in and the tech devs to
actually put in the time to do this work, they're not
going to tear it out. They have no good reason to.
The problem is also that these things change over time.
As your product evolves, as your feature evolves,
as the API changes, you'll have to continue to
monitor and make sure that these are working well.
One nice thing is the frictionless integration by the user.
The user can go and pick it up and say,
"This is great, I'm going to try this out.
I get a free trial. It works really well with this
other product that I'm spending all my time on." But back to the fact of if you don't do any co-marketing,
if nobody knows it's there no one's going to use it.
It's putting those two pieces together of driving
through those co-marketing channels as well
as having a great product integration experience
that will really make this successful.
The typical rev share, and you're probably
familiar with these marketplaces, there's AWS â€” all the platform hosting providers do this, Heroku is another really good example; it's roughly about 15 to 30 percent revenue share.
One of the things I would caution as well is when you look
at formulating these contracts, making sure you understand
where the pricing belongs and who owns the customer.
This was a huge, huge point of interest for us at
New Relic because our model was we're going to give
every single customer the bronze version of our product,
which is kind of the lower paid version.
We're going to give it to the partners for free and the
partners can then in turn give it to their customers.
It's a value add. Everyone is happy all and all.
You get a product you get to use, you get more visibility.
We get a new customer and the customer feels like they're
getting something for free that they're not paying for.
But what we needed from our partners was to
make sure that we had access to the customer.
One, for customer support purposes, any time they'd call we would be able to figure it out.
Two, and more importantly to revenue, that we
could have that contact information and the
relevance to be able to make that upsell and call out, cherry pick the best customers and make sure
that they were using the right product for their uses.
Customer information, who owns the customer? And then the pricing model, who actually bills
the customer and at what point in time? Is there a channel conflict if they decide
to move over directly on to your platform? These are all things that you should really
think heavily about as you're building out your
strategy and as you're creating these contracts.
These things might evolve over time.
This is great for both distribution and lead gen.
A couple of fantastic examples of
course is the Heroku marketplace.
There are add-ons that will get a 30 percent bump
just because they sit on that top banner out there.
If you do a whitepaper, if you do some sort of a blog post,
all of a sudden you get tons more traffic.
The problem with these marketplaces is that they're huge.
They've gotten to the point where there are maybe
20, 30, 100, 200 different applications on there that are
doing really interesting things for a particular customer set.
For you to really gain leverage through that customer
set you have to make sure that you're prominent,
that you're doing well within that ecosystem
and that marketplace is working well for you.
The initial strategy many people take is,
"I should be in all marketplaces everywhere."
Which is, again, good but it's not going to
derive the type of value and goals that you want
unless you're actually putting the effort in
to make that partnership a real relationship.
I would go and I would meet with
my Heroku partners once a month.
We'd share feedback, we'd share things that worked.
We gave them heads up in terms of product.
We did a road show every time there was
a product release or new feature going on.
It's again building that relationship and maintaining it so
that you're top of mind for them and they're more willing
to do things to promote you within their marketplaces.
Same thing for Jive and same thing for Yammer.
Every time there's a platform that people are looking
to leverage off of and they're looking to say,
"How do I distinguish this app from another?
How do I say this is working better?
How do I promote this to my customers?" Because they're not going to use all of them. But, from a New Relic standpoint and Heroku,
a large number of Heroku users use New Relic because of the promotion, because of that top line.
Two different aspects of feature enhancement; one is that I am a product, I'm a platform
and I'm trying to build in additional things.
For Yammer we used Crocodoc, we also used Bitly but we just white labeled those into our products
and eventually it's kind of a buy or build strategy.
The other aspect is if you're looking
to be an API from the beginning.
If you're a Twilio and you're saying,
"I'm going to build my business off of being an enhancement
to everybody else." What does that look like? Early on you're thinking about your strategy
and how you want to draft the BD and go to
market. Is it that I want to enhance my products? Do I want to be a product enhancement to other people?
The value here is once the integration is
done you have access to all these customers.
If you are a customer of Yammer then every single
time you use Yammer you're also using these five other
things that we've integrated in the product.
The downside is that they're typically not
branded, so it's a white label, and you
don't get access to the customer at all.
Yammer then is your customer and then
Yammer's customers are hands off.
On the flip side if you do a powered by,
this is also an interesting branding element.
You're typically trading off some revenue
share for the powered by branding. This can be a little bit cluttered if you use
too many of these different options so they're
typically fairly strategic about who you choose
and who you incorporate into your products. It's a high cost of change and then limited
access to customers is the biggest one.
Pay-per-usage is the agreement
that we have seen in the past.
Whether it's the number of documents, whether it's
the number of leads, or it can be an overall
enterprise license agreement that is also fairly common.
This is a pure revenue play here.
A couple of examples: we talked about Twilio.
Stripe is another good one. Any kind of payment processing,
anything that goes in the back end, shopping carts; people will cobble together a ton of great tools
and then just have it completely branded as them. Crocodoc and Bit.ly we talked about, and GoodData as well.
GoodData will take any of your data, put it in, give you
a beautiful visualization of that data and you can move on.
M&A. While we were at Yammer we had
a product build or buy strategy.
We did a bunch of different feature integrations but as we
were saying, "We want to have a chat functionality.
We want to have a video meeting/online meeting type
of functionality." We wanted to have the ability
to look at documents and then do some sort of
collaboration on the documents a la Google Docs.
Product team would be there fleshing this out and saying,
"This is our roadmap. These are gaps that we see. These are things we're willing to build." Then business development on the other side would be
looking at a ton of different companies that were looking
to integrate with us, but also looking for opportunities
in which they could feed into our product road map.
We ended up actually acquiring one
company by the name of oneDrum.
It was a team of, I believe eight or so engineers out of
Scotland, and they had been incubating for about four or five years and created a product that was very similar
to Google Documents but was for Microsoft documents.
You could load Microsoft documents and have five or six
different people collaborating. You got to highlight the changes.
We thought it was so compelling that we brought it in
and ended up buying the team and moving them over which may have set up a nice little roadmap
for us to get acquired by Microsoft as well. From there it can be distribution, it can be
lead gen, it can be revenue, all of the above.
I wanted to go back to the framework here
that we had initially talked about looking at the maturity of the company all the
way on the left and the ease of partnering.
Early when you start awareness is a really big thing.
I think that especially if you're a two or three man startup,
especially if you're a CEO who's doing biz dev
or you have maybe one biz dev resource, you
really have to hone in on how well you use your
resources for the goals you have at this time.
Establishing your core set of partners: Are you planning to be a feature enhancement? Are you
planning to do a lot of product integration? Are you looking
to build a platform or be part of somebody else's platform? That will help define who you choose your partners
to be and how you spend your BD resources. Hopefully, once you've had a couple of good channel partners
in there you can build customer traction fairly quickly.
You have your customers that can then lead
to other customers, and there's a little
bit of a viral model going on here, word of mouth, especially through the developer
community and getting to distribution.
Continue to build out your partner ecosystem. We've had a conversation about, "If this was the world,
if I could do everything, I would do all these things,
I would take all these tools and I would apply
them to get leverage as much as possible."
Being realistic, you really have to pick and choose.
Are you thinking about co-marketing,
are you thinking about partner integration,
are you thinking about feature enhancement? How do those things interact well with your product today? How does that interact with your product well today?
Once you have that initial set of partners â€” and I like to
think of it as I'm going to go after a couple of marquees. I'm going to go after a couple of Rackspaces and Windows Azures.
Then I'm going to have a number of other very quick traction
type of partners that I know are friends and family,
I can work with well today, they're a similar size,
similar state, and build that out as the top down as well as the bottoms up type of strategy.
Then from there fill it out and make sure
that I have great customer success stories, that I have great partner stories. I've got great metrics to
determine why my product is valuable with this marketplace. And then figure out who I want to build with next.
This is where you might want to start
thinking about having an affiliate program,
or a group of people that are trusted consultants, that you have customers that you have worked with, building out that SI, starting to
build into a lot of those ecosystems.
Feature enhancement is probably a good time at this point.
This was a big thing at New Relic,
the idea of gaining ubiquity especially if you are unique,
especially if you are new to the market; making sure that you are there before your competition is.
If you have some sort of integration in place, if you're
already there, hopefully you have a set of customers within
that market that makes sense already and you're blocking out,
blocking sockets, blocking and tackling, getting in
the way of your competition, having a really easy foray. A lot of it is land grab early on and making sure
that you have the partners that would be important.
Eventually you get to the point where you have a great
optimized deal flow, you're looking at all the leads
that go through, you can cherry pick the best ones.
That moves into maximizing revenue
through established channels.
Eventually once you're at a series C, series D, maybe
you're looking at IPO, looking for M&A to be able to scale and this may be talent acquisition, it may be for all the
various reasons, getting a number of customers, etc.
A couple of key things I want to pull out.
The BD tools can work in combination and
in parallel depending on what you're
doing and what your constraints are.
None of these are standalone.
I would actually recommend that you don't
start out doing all of them at once.
Your BD goals will change as you grow and you want to make
sure that you measure for what you're trying to get at.
If you want to maximize revenue in the first year
you probably don't want to go into huge distribution
deals because that will get you lead gen.
If you're actually looking at distribution and you
want free customers coming in you should actually measure
your BD team basically on: the number of people who are going in,
your site awareness, the number of leads that flow through,
the people who are trying your product and then eventually move into a revenue play.
Making sure that the goals and the
metrics align is incredibly important.
Finally, supporting your team.
BD teams tend to be very small.
They're usually a couple of people, maybe a dozen at scale,
but they require technical resources,
they require marketing resources.
They probably require some level of executive direction.
Making sure that your team isn't going out there and saying,
"We've got this great deal, we've signed this agreement,"
but then I don't have the resources to back it up and
actually create the integration. That's not helpful.
If I am promising to have some sort of a blog post or
a webinar or a tech lead out there, and if I don't
have that for my co-marketing, that's not helpful.
I can't do this alone.
Even though you have one person who's very resourceful
that can get you there to the last 80 percent, can talk about the product, knows the APIs,
can do all these things; you're still going to need support.
Making sure that the goals align to what you want to do,
having the right support for your team will ultimately
lead to a lot more success and be able to leverage
these really great distribution channels as you start.
And that is it.
Q: How does a startup pick which systems integrator to work with?
A: It's a great question. I think that the biggest
thing you would look at is: Is their customer
target the same customer target you want? Yes, you have a customer that is looking
to use my product, but is this a one off? Is this something that is replicable or not? Is it a custom build for this one customer? If that's the case then okay,
I appreciate the offer and I like the relationship,
you can have that one customer but I'm not going to spend
the time building the overhead of a relationship with you.
If you have a large set of customers that really
match up to what I'm trying to do and I see
the value of this, again it's the multiplier effect.
It's not the one customer I'm going after, I'm going
after the tens, the hundreds of thousands of customers.
If you have a set of customers that can all really value
this one certain thing you're talking about then yeah,
I would definitely take a look at it.
Q: When integrating with a partner company, do you borrow engineers from product team or do you build a separate integration team?
A: I've actually done it in both ways.
Starting off at New Relic we would have to
champion our project to the engineering team
and find somebody who would want to work on it.
I think that's fairly common, where everybody
is focused on the core product and then
integrations tend to be an ugly stepchild.
That's the way that we worked initially. I think that once you start proving traction,
and again if your executive is supporting the
strategy of actually going through these channels; we ended up hiring a specific business
engineering lead and then grew out that team.
I think you can get by relatively early
on by having a couple of key partnerships.
It works really, really well eventually if
you have somebody who's focused on the team,
knows the API and maybe is helping build out
that platform for other integrations to happen.
At Yammer we started off with just myself and
then about six or seven months in we ended up hiring
a gentleman who was focused on building out the APIs.
We also had a product marketing
person that was dotted lined in.
We also had a product manager on the
API team that was dotted lined in.
Even if they weren't part of the overall structure
there was a responsibility there, and they
felt obligated to making this channel work.
Q: What is the ideal relationship between business development, sales and marketing?
A: That's a great question.
I think that the answer is the typical
business school answer: It depends.
If marketing is over here and sales is
over here, BD is somewhere in the middle.
Depending on where you are in your company
life and what your objectives are it can
be closer to here or closer to here. I like to think of BD as a product and marketing
integration as well as having that sales responsibility.
It evolves over time, is the best answer.
Early on you'll be doing a lot of co-marketing, you're leaning on marketing for content and
distribution and you're looking at products
to help you build out these integrations.
From that standpoint with those earlier goals
and those earlier metrics you're very much on
the marketing and product side of the house.
Eventually you start shifting as you grow
towards revenue generation, towards lead gen.
Then you work very closely with the sales side to say: What
is a good qualified lead? Where am I actually making money? How do I get these more better qualified leads from
these partners into your hands so you can close the deal?
Q: Once you integrate with a company, how do you handle customer support?
A: That was actually very much the
case â€” it was learn as we go.
The typical process was you would talk to a company,
you'd get your business terms in line,
understand that you want to work together,
have some sort of a deal contract.
Before everything was cemented in you'd
bring in your technical resources.
They'd have a meeting of the minds and talk about what
the integration would look like, how long that would take.
That would get completed and done.
The paperwork would get done.
You start a co-marketing campaign out to that customer
set to get them excited and interested, have them flow in.
Then the question of customer support comes up.
What we would typically do is the first line of support
always goes to, if it's a platform, to the platform first.
Then we would have a direct line into supports on our side.
It'd be, there's a Heroku issue, Heroku takes the call.
They're like, "It's actually a New Relic issue,"
they push it over to New Relic.
That would be tagged as a Heroku
customer that has a New Relic issue.
Then we'd have Zendesk shared support
tickets, and then we would revolve around that.
We tried to keep our customer support as, and I think
this is probably a good recommendation across the board, every customer whether it's partner or direct
was a customer and we treated them equally.
The times when there were outages,
the times when things went down,
things didn't always work out, that support would ramp up.
We dealt with it like we had an outage ourselves.
Q: What qualities are you looking for in a business development hire?
A: This is a great one. And this is my personal journey as well.
I didn't think that I would end up doing BD for
four or five jobs over the course of my career.
I started off as an engineer; I was very much excited about hardware.
I actually did it for a while and I was like,
"This is not as fun. I can't talk to anybody."
I have found that I love working with people who have
a good sense of product knowledge, that are personable.
The deal making I think comes in terms of understanding
the contracts and understanding the business terms
but it's much more of a "what's in it for me?" kind of
relationship if you're looking to approach a partner,
especially if they're bigger than you. At any point in time it should always be: What are they getting out of it? What is their pain point?
How am I solving their problem? That very much is a personable sales conversation. I'm getting you excited enough that you're
going to devote resources and you're going to
expose all of your customers to my product.
Early on I would have somebody who had some sort
of product awareness, was very personable and
was able to execute up to the 80 or 90 percent.
They could talk about the APIs, they understand
the technology, they understand the data flows.
They can describe the ideal situation in which
your two products would work together and
then present that in a way where people get
excited about it and want to work with you.
Then you would think about bringing in somebody technical.
You'd probably need some sort of legal
counsel to review your contracts.
It is a combination of having some technical
background and being a little bit sales-y.
Back to the question earlier of is it a product person,
is it a marketing person, is it a sales person.
It's a combination of those things
to make a really great BD person.
Q: If you have a lot of enterprise customers, but the larger market isn't aware of your product, how do you grow with BD?
A: I'm getting your point here. It's like you have
a certain number of enterprise customers, you've been
very driven to do direct enterprise sales for a while, but there's still a huge untapped market maybe in the SMB, maybe in the smaller space where
you want to get traction through BD channels.
I would almost think of it as two separate things. If you're in a place where you're starting
in a new market you can't have the same
goals as that enterprise sales team does.
I would consider understanding, again, where
my customers are, what tools they're using,
what platforms they're on, how do I get to them,
what kind of consultancies are working with them; then picking a couple of those top different partners
to be able to attract that particular customer set.
Again it's contrary from the enterprise sales model.
The enterprise sales model is not
going to be a great BD channel for you.
But you want to get to scale, you want to have
thousands and thousands of customers across
that lower tier of customer, or lower base.
Going in through, we talked about, what
the channel strategy is going to be,
what the product integration strategy is going to be.
How do I solve their pain point in a
way that is interesting and how do I get
to them where they're already living?
If it's a hosting provider,
if it's an infrastructure provider,
if it's some sort of cloud or automation tool,
make sure you're present where they're currently using
things and stuff, and make yourself available there.
Q: How long did it take New Relic to set up a co-marketing agreement or to complete a full integration?
A: It varies quite a bit.
If you're looking at a co-marketing agreement it can be
anywhere from a couple of weeks to maybe a month.
If your heads are aligned, if you're talking to the right
people, if you're talking to the person who is of status, typically that can be done fairly easily. But
I would caution that if you're talking just to the
BD person you may not be getting the full leverage.
You should probably also be talking to their channel people,
their marketing teams, their product people.
It's really your job to not build a relationship
with one point person at a different company,
but build a relationship with the company.
That will help you over time.
These onetime contracts for a campaign
will last a couple of months.
You could sign a year-long agreement but
you'd want to auto renew that over time.
If you're building the relationship it's
also building it across the organization.
For a product integration, again it
depends on how sophisticated your APIs are. Are you building these as specific one-offs to integrate
with this one company that you'll never use again?
If you don't have that yet it can
be a couple of months to get there.
Do they have the engineering resources
on their side to actually support you?
Do they have APIs that you can read and write to?
Those are the considerations you would make.
For New Relic we got it down to if you had agreed with us,
the conversation can be anywhere from a month to
two years depending on if it was Azure or Heroku,
we could get the integration down to about less than two weeks, a week and a half.
Q: How do you manage your time and energy dealing with partners and consultancies?
A: I found the consultancies to be challenging early on.
We had an affiliate program at New Relic that we started quite early and we had roughly a dozen
or so every quarter of new consultants coming in.
These are your mom and pops, a 2 to 10 person shop that
did a very specific thing in a region that we weren't at.
It provided us with some awareness but at the end of the day
the number of referrals that we got through it, the actual
amount of business that we got through it was relatively low,
so we didn't want to spend a lot of time there. That's something that you just want to spin off a program,
get a referral fee, get some customers out there.
It's fine, but I would caution around brand awareness and
if they are doing things to misrepresent your company.
If there's no certification process,
if you're actually not talking to them,
you just push your logo out there; there might be some issues in consideration.
If you're looking to work with somebody who is much larger,
it's a 1,000-person, 1,500-person consultancy
it would probably take more time and effort.
How much effort you put into it will really
beget how much value you get out of it.
If it's going to be the Deloitte that we worked
with that would probably be at least half a person's
time to get to know who is the specific partner
that will be your champion within Deloitte.
How can you use them to talk to other partners? How can you get a practice in place? How do you get case studies out there? How do you remain top of mind with them as
they push out product to their customers
because they work with so many different people?
Being on them, being repetitive and once you have established the relationship,
maintaining it is still quite a bit of overhead.
Q: What role does business development play now that New Relic is established, and what metrics does BD use?
A: Early on we were responsible for leads.
It was a qualified lead that came in through a partner
and that was the number that we were tracking.
We were still tracking revenue but it wasn't as important.
It got to the point I believe three or four years in when we actually started looking at revenue as
a growth indicator, and it still had remained at the pretty
solid 15 to 20 percent as the company grew, which was great.
The way that New Relic has continued to function has been
much more marketing heavy and that's probably what you see. It's like the nerd life, the t-shirts, make sure you
deploy your agent now, Bermuda t-shirt, the spam e-mail.
Everyday for the first week or two weeks you get an email every single day. That's still true.
What we've done is we've taken these BD relationships and
we've pointed the marketing targets toward those as well.
You have a slightly altered view of the world if you're
through a partner versus if you're direct, but the
marketing channel still feeds through the BD channel.
We're still looking at different partners to
grow the ecosystem but the biggest change is
the fact that New Relic is now a platform.
Before it was, how do I get New Relic to be
distributed through all these other platforms? Now New Relic, again, compared to the Yammer example,
is the bigger player in the house
when it comes to APM and analytics, so people are coming towards them and building out tools and
then leveraging off their 80,000 customers that they have.
We did make the transition maybe a year or two ago.
Again, my information is a little
bit dated because I left in 2011.
But we did make the transition from being purely lead focused,
tracking revenue underneath, to actually having some sort
of revenue component to those metrics. Then got big
enough to the point where we had built out large ecosystems
around specific technologies and got to the point
where we had enough customers and enough leverage
where people were looking to draft off of our business.
Now today, the New Relic platform I think was announced
six months ago or so with the ability to push data
into New Relic and into having a visualization widget.
Thanks a lot!