Directly partnering with your sales team to evangelise and enable your developer customers has a dramatic effect on your product’s value both to your community and your company. JJ Kass demonstrates how Dropbox is teaming up dev rel and sales to great effect in this talk from DevRelCon London 2018.
Hello, everybody. My name is JJ, and I lead developer programs at Dropbox. So, I want to give you all a little bit about my background, and mostly because it’s relevant to this talk, but also because Matthew just mentioned that he really loves hearing these stories.
So, I went to University of Michigan where I studied political science and communications. I actually thought I was going to be a researcher and I did my thesis on sexism in the media. So, I was a little ahead of my time there. And then I started my career at CEB in sales. And after moving to San Francisco for that job, I really fell in love with tech and the startup life, so I made the transition to Dropbox, also on the sales team.
And I spent four years within the revenue.org at Dropbox, I started our first sales productivity team, building out that training program. And then I went on to be the Global Business Manager for our Chief of Staff, oh, sorry for our head of revenue. And then what I really noticed while working in the sales world, is that developers and partners are really important to sales at Dropbox.
And that’s what ultimately led for me to transition into Developer Relations. Which leads me to the topic of this talk. So, I’ve found that dev rel teams and SaaS tend to focus a lot on building and growing a vibrant developer community. That’s obviously where it all starts, and is incredibly important.
But there are two key areas that I don’t typically hear people talk about that I want to focus on today. The first is on cultivating team-focused third-party integrations that specifically deliver customer value. And the second is on evangelizing developers within your customer base. And that second point should really be a key audience for everybody.
When developers integrate your product into their products, either internally, or externally, you really see the business value and make your product stickier. And that stickiness factor is something I’m going to refer to throughout this talk. So, today, I’m going to share how the dev rel team at Dropbox works with our sales team and our business development teams to ensure we’re evangelizing the APIs, partners, and our overall platform with our prospects and customers.
To start, I’m going to give a tiny bit of history about Dropbox and the platform. So, really quick, can I see a show of hands how many people here have a Dropbox account? Okay, I think that’s 100% better than most audiences, to be honest, that’s great. Okay, now, raise your hand again, if you use it for work? Awesome.
Okay, maybe about 50% of the room. And out of those people who use it for work, raise your hand if you pay for it. Pretty good. Okay. And so, with Dropbox, we’ve mostly been known as a cloud storage company. And it’s true that when we started 11 years ago, that was really our focus, file, seek, and share. But over the past couple years, we’ve really moved beyond that to become the place where teams get work done.
And when we think about that, and connecting all of these systems, we’ve also evolved our platform over the years. So, the Dropbox API was first released just two years after our product started in 2007. And then we went on to release our business API in 2014, just a year after we released our business product.
And that API has continued to evolve. And just last year, when we really shifted our focus to team collaboration, we released new APIs that focused on bringing Dropbox into people’s workflows. And even just earlier this year, we released a new team events API that helps people understand better their team activities through the APIs. And as we’ve enhanced this product, we’ve continued to see the scale of our platform increase.
So, we now have more than 500,000 developers making over 2 billion API calls per day. And we also see that 75% of our paying teams on Dropbox business have a linked third-party app. So you can see the importance of applications being linked with teams using Dropbox. So, with the majority of teams linking apps, let’s talk about how we can make products stickier with platform adoption.
So, this is the stat I just mentioned and what we see of those apps that are linking or these teams that are linking apps, we see that they’re way more engaged, we see that they expand their license count at a higher rate, and we also see that they have higher retention rates.
So, knowing these stats, when we think about the ecosystem, our platform, and how we can make Dropbox stickier in our customer environments, we’ve started to focus on three key aspects. The first is the use of third-party apps that are connected with Dropbox. So, that’s what all those stats were just about and is a key focus area.
The second is getting customers to build custom integrations for their internal workflows that bring Dropbox into it. And the third is adding Dropbox to external facing solutions that actually face their customers. So, let’s talk about the first one here. When we look today at how people are working inside almost every company and every function, we find that work is collaborative, and it’s often content-centric.
So, we look at the lifecycle of this content and building solutions around it. Sometimes that means we launch a new product like Dropbox Paper, if anyone here hasn’t tried it, I highly recommend it. But most often, it means that we integrate with best of breed tools to offer our customers the tools they want to get their work done. So, we’re constantly trying to educate our customers about partners that are available and how they can connect them into their content lifecycle, because we know when they do, we see those positive impacts in the numbers I just mentioned.
So, for each one of these examples, each one of these situations, I’m going to give an example of a customer and how they do this. Plex Systems is one of our Dropbox business customers, they’re a manufacturing ERP company, and they purchased Dropbox to allow their employees to collaborate internally. And they found that when they connected Salesforce to their Dropbox, and since it dramatically changed the way their sales reps were working, and made things much easier for them to access files.
And it also allowed them to ensure that the legal team was always giving the sales team the most up-to-date contracts and documents. Now, you can imagine this relatively simple workflow with one app connected quickly expanding. Before Salesforce is linked, maybe they link Office 365, and they collaborate on documents online in Office 365, then maybe at the end of this workflow, they use DocuSign to kick off the e-signature process.
So, you can quickly see how this expands to linking more and more apps and making Dropbox stickier within their instance. And so, the next one is building custom integrations in-house. This is one I think a lot of people don’t think about as a solution. Typically, we see this where we have an engineer within an organization who’s tasked with simplifying a workflow. And either someone tells them, they should be doing this with Dropbox, or they just want to get scrappy and make their job easier.
And the example here I’m going to talk about is Dow Jones, where the engineer was actually specifically tasked with making this workflow easier for their GDPR team. So, their challenge was Dow Jones, it’s a very large company, they have lots of third-party apps accessing customer data, and they needed to make sure that all of those apps were compliant.
So, Alex was tasked with architecting the solution for collecting, storing, and distributing that data whenever it was requested. And that solution, which is quite complicated as depicted here, and every one of those code brackets is where the Dropbox API is pulled into it. And the workflow really made Dropbox a source of truth for this data for the legal team.
And therefore, it became really important to their workflow. Again, just showing how sticky the product can become when it gets integrated into something like this. This is actually just one of many examples of how the Dow Jones engineering team has used our APIs. And because we’ve established a really close relationship with them, they actually come to us and ask us, how they could use Dropbox to solve a problem.
And we now have a one-on-one relationship with our engineering team, which is really special. Okay, and the last one here is adding Dropbox to external facing workflows that actually solve things for their customers. So, the example here is a publishing company, and they actually had an issue getting younger publishing firms to interact with their FTP.
So, they updated their client portal to accept submissions from Dropbox. And the back-end is completely powered by Dropbox. And then they also share those folders with customers as shared folders, so they use Dropbox kind of in every aspect of this life cycle. So, what that does is it brings Dropbox, not only with our customer, but then takes it a step further to their customers.
So, these are three success stories of how customers have used the platform in different ways. And what I want to spend most of the time actually talking about is how we make these happen behind the scenes at Dropbox. With some examples of how dev rel and sales can work together. When I was thinking back through how we’ve worked on this and the key areas where we connect with sales, there are really four places where I see us working closely.
The first is sales, actually selling the vision of the platform to customers and prospects. So, sales is the first point of contact for customers, and they need to understand the vision of your platform. This is something that is actually depicted within our sales deck that customers use in first calls, which is what I’m going to show you in two slides.
Sorry. So, there’s three key areas that they typically point out when they’re on a call with customers, and the first one is our open ecosystem. So, we invite all apps to join the ecosystem. And it’s not a walled garden approach, which is how we have to refer to some of our competitors in the space. And because we connect with all these tools, we can simplify workflows with them connecting the tools they love in their workplace.
And the last is on scale and size. So, talking about how large our ecosystem is, is a point of trustworthiness and reliability. And these are actually three slides from the sales pitch deck, you don’t need to read the details on them because I’m actually talking about them throughout this talk. But this is three slides of maybe 20 that they present when they have a first onsite meeting with a customer.
And they worked in partnership with us to build this story and continue to refine it. And it really shows this overall story of how Dropbox can be used by a customer. And this last slide here, which shows the security solutions, that’s kind of our main pitch point with a lot of customer meetings. But depending on who they’re talking to, if they’re talking to a design firm, a construction company, or an education institution, they’ll change that slide to show apps that makes sense in those workflows.
The second thing I want to talk about is how dev rel should evangelize and enable the technical sales team. So, this is maybe the most important thing and the biggest action item for everyone in this room. So, say the sales team has a first call, the points on those previous sides were all pretty easy to get through. But then they have a follow up call and the customer really wants to get into how they can use the API.
This is where it’s really important to have the technical sales team educated on how to answer those questions, and what’s possible with your APIs. So, we’ve tried a few different things here. The first is hosting internal API trainings. So, we actually earlier this summer, hosted a getting started workshop for our internal solutions, architects, technical architects and CSMs, so that they could understand how to use the APIs and not just at a theoretical level, but actually get their hands dirty and build some apps, and then how to actually communicate that to their customers.
And the amazing thing about this was, we love this as a workshop knowing that we wanted to launch this as a workshop publicly. So, we were able to test it with our internal technical sales team, get their feedback on it, see how they thought it would resonate with our potential customer developers, iterate on it a couple of times. And then we launched it publicly at our developer days, and we also launched it as a guide online.
So, I’d encourage everyone to think about how you can use your internal technical resources who would benefit from this type of content as a way to practice and get reps up on stage presenting in.
The next one is we host API office hours. So, we have a standing weekly meeting, which you’ll see the screenshot of it here.
It includes all our global solution architects in the company, and it’s really just a time where they can come and ask any questions they have, they can troubleshoot the problems that they’re facing in a customer account. Sometimes it’s just a new solutions architect who wants to know everything about the API and we spend an hour giving them a deep dive. So, there’s all sorts of things we cover in this, but it’s open time for them to come ask us questions.
And the last one, because we have this close relationship with sales we’re able to hear some of the common workflows that come up, and what people are trying to solve that maybe isn’t a feature set of our product, but can be solved with the APIs. So, we started a GitHub repository that was actually spurred and started by our solutions architect team and now we help maintain, but it has all the common business scripts that they face when they’re on customer calls.
And this is also public on GitHub, so customers and businesses can now access it. Okay, the next one here is pretty short, but it’s all about creating an avenue of feedback from sales about integrations and API requests. So, if we’re asking them to evangelize and get people talking about and thinking about using the APIs, we really have to be willing to take the feedback about what’s not working and what’s working well.
So, there’s two avenues for this. The first is integration requests, which typically come either through a Slack channel that we have set up, which is actually #askBD. And normally, that’s, “Hey, do you have an integration with this company?” And the other is through Salesforce data they fill in forms where customer have asked for specific integrations.
And the way these are typically handled, it actually funnels to our business development team and if the answer is yes, we have that integration, they’re a partner, here’s how you get in touch with them, here’s the information they handle that. If it’s a company that doesn’t yet have an integration and isn’t a massive company we’re already trying to partner with, they’ll pass it on to the dev rel team for us to actually get on the phone with that company and help them architect how they might integrate with our product, doing our job, developer relations.
And the last one is on API feature requests. So, these typically come directly through the dev rel team through our support channel, but also can come from calls and come from these meetings with the sales team. And this is something that our team does to funnel these requests from our big customers back to our engineering team. And lastly, we think about engaging customers and prospects jointly together for our community and our events.
So, there’s a few aspects of this with events, we’re always thinking about inviting customers to attend them, and inviting prospects that could be interested in attending them. And this is actually a great touch point for the sales team, they get really excited about it. We draft them an email that they can forward along that’s typically something along the lines of, “Hey, I’m so excited about us working with you. I thought your technical team might be interested in this. Will you pass it along?”
And they send it to their key business decision maker, who then typically forwards it along to an engineering team and helps us get really qualified leads to our developer events. And we also invite customers who have already worked with our APIs to engage and speak at these events. So, Dow Jones is a perfect example. We have had their engineers come out and speak at both our New York and our Tokyo developer days that we hosted, and talk about the internal solutions they built.
We also typically see that roughly 75% of people who attend our meetups work in an organization that could range from a small business to a really large enterprise. But we also work with sales to curate that list, and let them know who’s coming and if any of their accounts will be in the room, so they can make sure they attend as well, which they obviously love the hot leads. So, that creates a really good working relationship and engages them to try to get more people in the room as well.
And then we also host occasionally on-site trainings with customers. So, this is really high touch and something we try not to get in a habit of because we really want to scale our team. But when it’s a big enterprise customer, we always welcome to get in the room and talk to them about our APIs and help them to architect a solution.
So, the solutions architecture or the customer success teams will engage us with that and we’ve done everything from one-hour calls to full-day trainings on our APIs. And then we also have that GitHub repo, we share that with customers and that’s something the sales team has as a resource. And lastly, is marketing. Actually the slide examples I showed you of the success stories, those are slides that the sales team can slot into their first call decks and use as examples of how businesses have been successful using the APIs. So, those are all public references that we talk about when we’re engaging our customers.
Okay, that was a lot and I’m looking at my clock I’m at 19:30. So, I really timed it well. In summary, building custom integrations and linking apps leads to more engaged customers. And dev rel can directly impact those numbers by driving business applications of your APIs.
And a key piece of that strategy is directly partnering with your sales team to evangelize and enable your customers. So, I encourage you all to go talk to someone in sales at your company when you get home from this conference, and ask them how you can help them. If there are ways you can partner closer together and I’m pretty sure they’re all going to take you up on it.
All my contact information is here. I’m JJ, at almost everywhere or JJ Kass. And lastly, because everyone has to give a plug on hiring, if any of this sounds cool, come work with us at Dropbox. We’re hiring a platform evangelist, a developer advocate, and a partner technology manager.
So, you can contact me, email is probably the best way if you’re interested in the job, but we’d love to grow our team. So, thank you guys so much for listening, and feel free to find me afterwards if you have questions.
How much do we think about the experience developers go through when learning new tech? How can we serve them better?
Naomi Pentrel from MongoDB talks through a framework for defining dev rel strategy for your team in this talk from DevRelCon San Francisco 2019.
Write for us