February 2, 2016
Ep. #6, Building a Developer Community
In this episode, Yaron talks with Runscope's John Sheehan about the philosophy behind building a strong developer community, they also discu...
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.
Feature enhancements. 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!