Reigniting Dropbox’s developer programme led to a rethinking of how they engage with their developer community. JJ Kass looks at how they went about that in her talk from DevXCon San Francisco 2018.
So I’m JJ, and I head up developer programs at Dropbox. I’m not gonna do a long intro into myself because when I clocked these slides, I was just about at 20 minutes and I know we’re keeping right on track. So I’m here today to talk to you about Dropbox’s journey to discover who our developers are and how to engage them. And at Dropbox that really means re-engage them, because we’re thinking about how do we engage developers who built on our platform eight years ago, nine years ago, to those who built on the platform last week, and how do we keep them engaged?
I’m gonna start off with how ecosystem became a Dropbox strategy and the evolution of the DBX Platform as a baseline to get us started. So you all know this already. Today there’s a lot of tools that we work with and there’s increasingly more every day. A lot of you are startups who are building new tools in this ecosystem. And that gives us a lot more capability but it also makes things a lot more complicated and makes our workflows way more broken up. So we believe this is a huge opportunity for Dropbox to become a home base between these content silos and provide a place for content creation, feedback, distribution, coordination and organization.
We’re calling this content-based collaboration. And with this it creates simplicity of working across a single system. And we want at Dropbox to provide a distraction-free environment where you can focus on what it takes to build the next big thing. And what we’re connecting a lot…this really can’t happen, this creativity can’t be unleashed if you’re still switching back and forth between different tools. So our partner apps and our developers bridge these gaps. And this is something that is a company strategy, and these aren’t slides that me or the ecosystem marketing team put together to tell our platform story. These are slides that our CEO and several executives at Dropbox have presented to customers and investors about our story as a company.
And as we evolve as a company to this content collaboration space, our platform has also evolved. So in 2009 we released our first API, and this was really all about bridging silos between users. And we did this through backup, storage, photo storage and shared folders, a lot of what you all probably know and love about Dropbox. And then in 2013 we really went all in on platform. I don’t know if anyone attended DBX which was our first developer conference, but we had our CEO on stage talking about the importance of the platform to Dropbox. And since then we had been chugging along. We released our team APIs in 2014 which had the ability to programmatically manage your team management and web hooks. And then we kinda got quiet. I don’t know if anyone noticed this but our blogs kinda slowed down, we stopped doing a lot more developer relations and engagement with our community. And that all changed when we did this research that I just presented on what our company strategy was. And when we realized we needed to be that connected tissue between tools, we relaunched this program. And what that looked like internally was a reorganization of our product, engineering and business development teams into a new ecosystem pillar within product and engineering. And then we also launched DBX Platform in 2014 which released three new APIs which were all about building workflows and really set us on this path to start creating the next content-based collaboration platform.
And we see this in the numbers. We have over 50 billion API calls per month. This is roughly two billion per day and that’s a big number. I mean, it shows how used the platform is. We also have more than 500,000 developers on our platform. And the one that really shows why this is important to the company strategy is this last one, which is 75% of our paying business teams have linked a third party application. So customers are telling us that this is important and that they need their applications linked to Dropbox.
So now that in 5 minutes I’ve given you 10 years of history, I’m gonna go into what we’ve been doing over the last year. So developer programs at Dropbox, what we’re working on and what we’ve seen is working.
So here’s everything that we see as part of developer experience at Dropbox. There’s a lot here and I’m not gonna go into detail into all of it, but I want everyone to know the holistic picture of what we’re talking about and it’s big. There’s a lot to do here.
So as we think about the goals that we are trying to accomplish we looked at it in a phased approach. So the first one as we kicked off this team and the platform was we need to understand who our developers are deeply. We need to know who they are, what they’re building for and why they’re building. And then we need to create awareness and empower creativity. So let’s start with the first one, understanding deeply.
This encompasses in that graph I just showed, really two of these buckets. One is in API support and feedback. So us being able to take what developers have already told us and translate that into meaningful data that we can use. The next is analytics on platform usage. And then the last one is through additional research of surveys, focus groups, user groups and online testing which we’ll also talk about a bit today. And so we did those…did this in this order and we answered everything we could through internal research. We developed hypotheses and then we developed questions that we couldn’t answer through data and we conducted a survey. So we surveyed our developer base and had roughly 2,000 responses to that that we’re using to interpret and make judgements on what we invest in.
So as we think about our more than 500,000 developers, that’s a lot of people. Who are they and what are they doing? So looking at our data, this is a map of where our developers are in the world. Every dot on this represents a city that at least has at least 100 developers as the ball point. And you can see where it’s condensed, where there’s a lot more of them and listed here also are top cities in alphabetical order. So out of this list of our top cities, only three out of these 13 are in the US. When we look at the top 10, only San Francisco is in that list. The rest are all international, which tells us a lot about where we need to be focusing our efforts.
Also when I showed this for the first time someone said to me, “This can’t be right. There are blue dots in the middle of the ocean.” And sure enough, you click on those and there’s islands where there’s developers.
So then we moved on to our survey data to answer some of these questions. The first one which I think is probably relevant to everyone here because your developers are our developers, we’re all in this together, is where do our developers work? So we asked the question of their company size and the vast majority are in really small businesses. These are startups, solo developers, small business fueling our platform.
And then when we asked them to describe what their role is, surprisingly only 45% identified first as a software developer, and then out of the rest of them we had a large chunk that identified as self-employed or business owners and then the rest were small different roles like product manager, QA, students engaging on the platform. So this helps us inform who we’re marketing to.
We also asked what level of experience our developers have and this one kinda surprised me. Forty-five percent of our developers indicated they have more than 10 years of experience. That’s a hugely experienced base of developers and it has informed how we are going to market with a lot of our enablement materials and we’re targeting to ensure that we’re speaking to an experienced developer.
We also asked them what their apps do. And this one was pleasantly surprising to me. Data migration and backup only…indicated by 20% of the developers and I expected that to be higher. That’s what most people know Dropbox for. But when we look at it, actually a lot of people are already building in productivity and workflow which is the direction we’re headed. And we hope that when we redo this survey in a year, year and a half, that that number’s gonna continue to grow.
We also asked a series of questions about the target audience of applications and the vast majority, or the largest majority were still building for themselves and their personal use. We asked short answer fill ins for what their apps do and backing up smart home data is still one of number one use cases, but we also see that 35% indicated they’re building for external users. And out of that external use still a majority, roughly 70%, are building for individuals over teams.
So this last slide which is the one that I expect everyone wants a picture of too, so I’ll smile for a photo, but this one is we asked developers to drag and drop what was most important to them. So this wasn’t related to Dropbox at all. It was just what features and offerings are most important. And not surprisingly, the basic things they need to do their job are the most important. They want good SDKs, language coverage, documentation that’s easily searchable and organized and enablement resources that tell them how to build. These seem pretty obvious. So it’s really good for us to know this and to focus our efforts on this foundational effort.
And then the least important were, sadly for us dev rel people, were community engagement. So meetups, hackathons, forums, app promotion and discovery and communications. This was initially a little bit of a hard blow to follow or to take as we were working on a lot of these things and we still are, but I just think it’s important to remember that the emails you send, the marketing you do, the blogs you write all have to be helpful to developers and are only gonna work if you have a product that has the foundation they need to build what they’re working on.
So the second phase of this now that we know who our developers are, is to create awareness. And we can only do that now that we know them. We know how to speak to them and we know what we should be putting out there. So this is across these two middle blocks of our experience grid, community and content. And two that I…there’s a lot here that I know everyone’s already doing and is working well for them but there’s a few learnings we had from two specific areas that I’d just love to share because they may be something you hadn’t thought of and be relevant to your work.
So the first is with meetups. Right now, we started doing meetups last year and we’re doing about one every other month. So they’re still pretty rare and we’re doing them in our offices around the world. Now that started off as we should do it in our offices because we don’t have to pay for event space, we can be scrappy, we have engineers there. So let’s just try it with that before we expand bigger. But it turned out that developers were really drawn into seeing where we worked, to touring our office spaces and getting a feel for who we were as a company. So wherever you can when it’s possible, even if it means your meetups are smaller, I highly encourage you to try to do them in your offices.
We also found that email invites directly to developers were our best source of recruitment over any other websites or postings, including our own. So I highly encourage folks to think about that. And we’re seeing roughly 60% attrition. That seemed high to me but in talking to people it seems pretty normal, but that’s just kinda our baseline for every event. And what…if anyone attended Evan’s Data they talked a lot about the importance of connecting with engineers. So we’ve been working really hard to ensure we always have engineers at our events and it’s really going well and developers are giving feedback that they really enjoy that time one-on-one with our engineers.
And finally, you can see in these two photos, they’re panels with some of our partners and customers, and leaning on them to tell our stories has been the best thing that we’ve done. These panels are by far the most engaging and these partners can tell a little bit about that…their apps, what they’re working on and why they built them. But it also gives people real examples of what’s possible with Dropbox.
And I wanna quickly tell a little story about one of these meetups and how they re-engaged a developer. In New York we invited anyone who had ever built an app based in New York City to the event. And there was debate about this. Should we only invite engaged developers, should we invite everyone? We ended up inviting everyone. And there was a developer who attended who built an app five years ago while he was a student in college. Since then he hadn’t used Dropbox and he hadn’t used our API. Now he’s an engineer at a bank and when he got the invite he invited two of his colleagues to join him to the event. He comes to the event with two of his colleagues. We have Alex who’s in this top photo here in the middle who’s an engineer at Dow Jones and built a workflow at Dow Jones they’re talking about. They chose Dropbox because of security and it was great for the team management and they built a whole document workflow off of it. And now this engineer looks at his colleagues and says, “Can we build that? Can we do it?” And they’re talking to our sales team now about a potential engagement and a custom solution. So it shows that it can be anyone who’s gonna be your next potential big customer, big developer and you should continue engaging everyone.
On a similar note, we’ve been experimenting with different blog content, and our blog post that’s been most successful this year has been a collaborative blog post with did with Zapier on development workflows. And this to me, it could be many things. It could be that people love Zapier. It’s possible. We definitely use it a lot at Dropbox. But to me, it shows that people care a lot about connecting the tools that they’re using. And I would guess the next time we do a blog post like this that’s collaborative, it does equally well because it’s about connecting your workflows and your tools. So whenever you can engaging your partners to work with you to market to your developers.
We also overall see that how-to materials and enablement materials are by far the most commonly viewed month over month. And we have now roughly eight years of blog data behind this and I’ve been digging into it, and blog posts from four, five, six years ago on how to authenticate your app with Dropbox is still the most commonly viewed blog every month. So as we think about building this enablement material which our developers told us was important to them in a survey, we’re thinking about how do we continue to do this over marketing moments and giving them materials that are really valuable and will continue to be valuable in years to come.
And that leads into this next phase goal which is about empowering creativity. So we wanna enable developers not just to build on Dropbox but to build powerful creative workflows easily on Dropbox.
And that pretty much covers everything in our grid. That’s from the foundational tools that they have in order to build the applications that they want to build. It should be easy for them to do it and they shouldn’t be getting bogged down in the details. And then it goes to all the way to a blog post that inspires them on what they can create. And as we think about this enablement material, I work on a team right now of two developer evangelists, and we can’t possibly create enough enablement material for every use case and every developer. So one thing we just launched and I’ll have to update everyone on how it goes, but we launched a program. It’s a super user program aimed at scaling our enablement and support. So the idea is that we get users to apply to be a part of this program and as part of it they get connected to the Dropbox team, they get closer engagement with us, they can work closely with us but they also are asked to contribute high-value content into our forums. And the idea here is that we both get more scaled content and support questions answered but we also get additional creative thought that we might not have had as a team of three people. And new ideas, new industries, new audiences reached through this content. And by having everyone geared towards our forums we’re able to also stamp it with a seal of approval that this is actually an effective workflow to build and that we believe that it was built and recommended in the correct way.
Now across all of these, we’re thinking about measures for success, and we think about these in two different categories. One is input; so this is everything we’re all doing as developer relation specialists to do our job every day. And then there’s output which is what we hope to see from it. So within input, it’s the content you’re creating, your blog posts, your meetups, your events, website and messaging experiments; and then within output, we’re hoping to drive new apps and new developers. More importantly, active apps and active developers. Bugs and feature requests filed. We hope with better enablement content that’ll go down. Blog and Twitter impressions and website visitors and call-to-action engagement on our website as we do those experiments.
So, in summary, these are a few things I think we’ve learned that are really important to be successful. Aligning with your company strategy is critical. I know that can be hard but even if it’s aligning with a single product strategy, it’s important to have that alignment internally. Using analytics. First, your internal analytics and then combining that with surveys and conversations and your support feedback together to get to know who your devs are is a great place to start. And then engage your partners, customers and developers to help you tell your story. They’ll do it way better than you can. I promise. And then create clear measures with inputs and outputs that you can track on a daily, weekly, monthly basis that guide how your team is doing. And make sure that’s done in partnership with all the teams you work with whether that’s sales, marketing, business development, product engineering. Everyone should be aligned on what you’re driving, that outcome and know what they’re doing to contribute to it.
Now to show how deep this new strategy goes with Dropbox, I wanna talk about our logo. Did anyone notice it changed in the last year? So we did a brand redesign and changed our logo. And the rationale that the entire company heard for why it changed was that the logo should show that we are more than storage. The old logo was a box. You put things in a box, you set a box aside. The new logo was meant to be cleaner and simpler and evolve from a little box to a collaboration of surfaces that move and interchange and show that Dropbox is an open platform and a place for creation. And that is what our company said was the rationale for why we changed our logo. If that doesn’t stand behind that platform is a company’s strategy, I don’t know what does.
And that’s the mission we’re inviting developers to join us on. Build apps to unleash the world’s creative energy with DBX Platform. And so that’s an open invite to all of you in your developer communities. If you’re interested in co-marketing and exploring creative ways to use Dropbox, you can contact me. I’m [email protected] and JJ or JJ Kass almost everywhere except for Twitter and whoever has that, if you know them, let me know. But I’d love to hear from all of you and work together on collaboratively marketing to our developers. Thank you.
All the fun stuff happens with shiny new tech, right? Nah. You can get audiences excited about older tech, if you serve them well.
Are dev rel teams just here to make everyone feel good about using a technology or is there a deeper responsibility?