What is the first step in building a developer marketing organization?

The first step is to focus on people. Start by building relationships with your developers, both within your company and in the broader community. Understand their needs and challenges through one-on-one conversations, which will provide invaluable insights as you scale.

What are the challenges of building developer marketing in a seed-stage company?

In a seed-stage company, challenges include small developer communities, limited awareness, and skepticism about the business value of the technology. Focus on building trust with developers, providing product-market fit, and showcasing use cases that demonstrate the technology’s potential.

How do developer marketing strategies differ for mid-sized companies?

For mid-sized companies, the focus shifts to scaling the community, building developer relations (DevRel), and showing the broader business value of the technology. It’s essential to develop developer-facing resources like documentation, onboarding tools, and partner collaborations to prove the product’s value.

Best practices for building a developer marketing org

Over the past seven years, I’ve built three marketing organizations from the ground up, and today, I’m excited to share what I’ve learned along the way.

We’ll walk through the essential tools and strategies for every stage of your team's growth – whether you're starting from scratch with no developer marketing in place, or you're scaling an established team to the next level.

I’ll also share real-world examples from my experiences at a seed-stage startup, mid-sized Niantic, and industry giant Stripe, along with a few extra lessons learned along the way that you can apply to your own journey.

Let's dive in.

Building a dev marketing org in the wild

Who knows ‘Bear Grylls Running Wild’? For those who don't, he goes out into the wild and survives on his own. He has this new show called ‘The Challenge,’ where he does a two-day challenge with actors and teaches them how to survive in the wild.

One of the things he teaches folks about outdoor survival, and what I thought might have commonality with the way that we have to approach building our team, is this acronym: ‘Please Remember What's First.’

I thought maybe you could walk away knowing how to build your dev marketing org, and you'll also be able to know how to survive should you get lost in the wild.

So, when he talks about ‘Please Remember What's First,’ the interesting thing to me was that the first thing is ‘Protection’. So when you get dropped somewhere that's totally unknown to you, you might think you need rescue or water and food so that you can survive. But, really, it’s about checking your immediate surroundings.

See what's going on, check for the threat of animals, and check if you’re going to fall; otherwise, the next three don't matter. If you’re hurt or there's an animal right next to you, you can't get to the rescue, the water, or the food.

Then you go to the ‘R’ for ‘Rescue’ and you look for ways to get seen. You find a spot where you can maybe put up a signal, and then, and only then, do you figure out where your water is. And after you have that, you go foraging for food.

So, when I was approaching the teams that I was building at these organizations for the first time, you know how that flip for me happened. So here's how we go about this and how it relates to us.

People research wins future opportunities

For me, ‘Please Remember What's First’ started with people. We're looking at your community and the people in your department, but also the people and developers in your organization. And then the research, the wins, and the future opportunities.

Sometimes, I think we look for the future opportunities and the wins first, and it's really about going back to your developers and having those conversations.

So, going back to the people, the first thing that I did at each stage of growth was talk to developers one-on-one and meet with those teams.

So, just remind yourself, your teams, and your executives that this is really when you're scaling or coming in from scratch and building an org that didn't exist in the past, which is what I'm doing at Stripe.

Jump in and personally know your community, whether others on the team know them or not internally.

Ask them questions, learn what they need beyond your product, what they look for, and what helps them succeed. And then just repeat that as you scale. Do the same as you grow across regions, launch new products, and build new teammates out as you get more resources.

Second was research. It's going back to the data, but really for this one, I’d like to flag that you should constantly be doing the surveys and research reports internal and external, understanding the sentiment and the barriers, and then comparing those discussions with your one-on-one discussions with your developers.

You've already started with your people, so you should be armed with the tools that you understand about what your developers need. And then the research is backing that up, versus starting with the research and not really having a comparison or a pulse to be able to check that against.

I would also check with your internal teams and see if this is aligned. Are executives thinking the same way? We just heard one thing from our developers and now they're saying this other thing externally in this larger 1,000-person research report.

And, yet, internally, when I talk to PMs or executives they're thinking a third.

This is a good way to start thinking about where the cracks are and what you might need to double down on or fix.

Then, I would go to the wins and look at what's working. For example, these things for Stripe Docs are really working, and for Niantic what was working was the brand.

Then I would move to: why are these programs hitting the mark? What is it that makes this company work here? Do I just not touch it, keep it, and let it go? Do I double down on that because that's what's working and we want to invest more in that area?

That helps answer those questions based on the conversations you've had with the community and with the data you got from your research reports.

And then where to focus next? Again, remember that this might also just be the future opportunities, things that don't exist yet. They're not built. We know we need them so we're going to try to build those out from scratch.

So, where are the gaps? What are the areas that you've learned from your devs and the data that you might need to fix? What can wait?

This is the hardest one too, where you’re looking at future opportunities and the sky is the limit. Especially in dev marketing, we can constantly be making content such as webinars and tutorials and doing events.

But, hopefully, with the data that you’ve got, you'll have a good idea of which ones you’d prioritize over others, which ones you’d save for a little bit later, and where you’d need to invest immediately.

So, here's the little acronym for us: ‘People Research Wins Future Opportunities’.

What dev marketing looks like at seed-stage, mid-sized, and large organizations

As I mentioned, I don't know why I did this over the last seven years. I'm super tired over it, but I did do seed-stage, mid-sized, and now large, so I'm just going to jump through some examples.

Seed-stage company

With the seed company, it was an AR technology company that Niantic bought and we were starting out a platform for developers for the first time for building up AR applications.

With them, the ‘Please Remember What's First’ was that there were a small number of developers who just didn't have the skill set. I think there were only 40,000, and it was probably even smaller because our tech was really hard to use out of Oxford Lab.

So we were looking at a smaller number of devs and just talking with them. They were super excited, but the value of the technology wasn't really known to them beyond, “I can build this really cool thing that I can put in my living room.”

So then when I ran the research, we needed product market fit. Developers were skeptical about business value; they knew they could go and build something that was really interesting, but they weren't sure if they were going to be able to make money off of it.

They also weren't sure if we’d be around. To be honest, they were a little nervous about going back to the people, whether we’d get acquired, which is what happened, and then it would go away. So, based on the pulse of the community plus the research, we looked at where we needed to focus.

Some of the wins this company had is that the CEO was really strong with his thought leadership around AR and the metaverse, and he still is today. The community and PR knew him really well. We had Forbes calling us all the time to ask him questions and get him in an article, so that really helped, especially as a seed-stage company.

And then the technology was really fascinating and unique, so the future opportunities were trust in the tech with the devs. The trust also came because we didn't have pricing announced yet. We launched that within a few months and explained what we would and wouldn't do for developers with regard to pricing them too high along with the long-term stability of our tech.

Here are a few ways that we approached that.

With the community, we did lots of contests and challenges, “Come in and build with us.” Our engineers were actually on a Slack channel one-on-one with our devs; they were acting as our support and our community leads. We had strong relationships with dev agencies and we often did one-on-one conversations.

We also partnered with top-tier partners like Airbnb and tried to get those examples out to show that the tech could be trusted.

We did lots of videos of our apps working. We actually paid through a contest to have developers build something and post a short film of it on Twitter, and that got us a lot of recognition from the VC firms and companies like Niantic and Apple because we were showing what it looked like and it needed that visual.

Then, we doubled down on comms and thought leadership because of that CEO, and continued to do the interviews. But like I said, setting the long-term vision, telling the customer success stories, and showing the visual proof of the tech were the future areas that we had to focus on.

And this is just a little example of what the team looked like. Again, we were a company of 12. All of our engineers were constantly on Slack talking to our devs as the support team.

We had one community lead who was internal, but he was also an engineer and would do our booth, staff our challenges, answer questions, and be my partner in crime there.

I sometimes used a comms agency to help double down on the thought leadership we already had, but then everything else we just did ourselves.

Mid-sized company

Once we rolled over to Niantic, they hadn't launched their platform yet. They were known for gaming. There was a low number of devs, just like in AR for the seed company. There weren't that many who had the skill set, but they were very excited about the tech.

However, they were still skeptical of how much they could make or what they could make with this technology for business purposes.

We needed to show product market fit. Niantic's a bigger company and this was a bigger play for them than at seed-stage, so we needed to show that it was stable but also that it was actually providing value to brands.

Pokémon GO is a well-known game, and devs wanted that tech. They were excited about that. So the awareness, the excitement, the brand, and the vision they were getting, they were excited that it was Niantic.

There was also this interesting thing when talking to the people; they said they didn't want to give their data to Facebook or other companies who are investing in the metaverse and AR.

So, Niantic's vision for this world of combo, an open metaverse that doesn’t disconnect from the real world too much, really inspired them. And so we doubled down on that.

The things that we were missing by having no platform in the past and also by being a gaming company were all the basic stuff that I'm sure you guys all have, and that Stripe's really strong at too like docs tutorials, dev onboarding. We didn't even have a developer relations team, so we were basically starting from scratch.

When I went in there, we tried to grow the community. I brought all the devs from my seed-stage company over to do this three-month feedback project with our top developers. We paid them and had them give weekly input on the product (we hadn't been getting that to tell what was working and what wasn’t), and also give our executives confidence that they could launch this.

In addition to the devs being able to show that this could be used by externals, we did a six-month program with partners across the globe, including the UK Science Museum, Jurassic World, and Coachella.

Doubling down with the agencies and these brands to have at least 5 to 10 apps launching with us when we came out of the gate was really important to prove their tech was valuable outside of just gaming.

So, really looking at partners who are the non-gaming ones, and then trying to differentiate the vision and double down on the awareness of Niantic.

And then with the future opportunities, we obviously had to launch the platform, build a community, and get a Slack channel or Discord set up. All that basic stuff had to be created, plus dev events which are actually all on right now. They're in London and they're building out the VPS community and learning and training programs.

So, what that team looked like when I jumped in and built it out from scratch was the community lead, Hal, and the PMM lead, Brynne. We had contractors come in and out and I'm happy to share with folks who might need dev marketing contractors who we used at both Stripe and Niantic.

Then, we worked super closely with our PMs. All our product market fit research was PM led, and like I said, there was no DevRel, so we had to help the team hire and find the right people and build that out.

Large company

Then I decided to go and do it all over again at Stripe. What's interesting that you might not know is that Stripe actually didn't have a dev marketing team organization.

I've seen folks talk about it, and I agree on their strength in their docs and the developer brand. And one thing that's interesting is that the docs were so strong as well as the APIs and the founders, those are all their wins.

When they went and they built their organization, they were focusing on sales enablement, product marketing, partner marketing, and all those other pieces because they naturally had dev marketing.

But coming in, there wasn't really anybody at a certain point that was building the team and running dev marketing. So they asked me to come over and do the same thing all over again.

So one of the things we're looking at is there are millions of developers who use the product but they all have different skill sets. So unlike AR, everybody can use Stripe no-code, low-code. They need the tech to work and they need to trust it.

Unlike other developers I'd worked with in the past on AR, they’re tinkering with it and the whole thing relies on that platform. These devs need it to just work so they can actually build their business.

And there are various personas we've run. As you can imagine, Stripe's a big company, so we have a UXR team. We're constantly running research reports. My Head of Community has been running surveys just to try and get an understanding of where they’re now hitting these gaps and challenges.

We began with how-to docs so we know how to get started, but a lot of our senior devs are hitting these edge cases and more complex situations that we don't have a tutorial for yet.

So we need to bring that feedback back to our DevRel team and our PMs to say that this is a strategy for content we should be writing or these are the things that we should be creating for them because we've spoken with the devs and we've heard that they’re falling short here.

And the wins as you all know, are the brand, the growth, and the community. The devs are really a strong community for Stripe.

And the thing that's interesting too is we really need to have a place for them. We've gone out there and met the devs where they are, but we're now trying to bring them back to a website or a discourse community where they can all get together and share and answer each other's questions.

We want to build a champions network to try and get developers across the globe to give presentations and events on our behalf and try to build those funnel campaigns to target those personas.

We’ll hopefully do a dev conference one day, but it was interesting that every company that I've seen in the past seven years where I've done this all have different strengths and weaknesses. And you really have to adjust to what you're seeing, what's in front of you, and what your community’s in need of.

So what we're doing is trying to get the one-on-one discussions. We're trying to build that website, and we're updating our personas to try to grasp the number of different types of developers who are using the products.

We're doubling down on the brand and the community and trying to uplevel those champions, and also build out new campaigns and social media. With data analytics, we're trying to get more there to track where our devs are coming from and where they're going after they hit our stuff.

So, just to give you an example of the larger scale team, for the community lead I came in and hired Ricardo. Some of you may know we've hired a Dev PMM for dev marketing, but then we also have a large DevRel team.

There are about 12 or 13 dev advocates across the globe who are just shelling out content and building videos. They're awesome. They've been running Twitter before our team existed and it's really cool. And then we also have an eng brand and comms team.

But even with that and with our internal docs team and tech writers, we’re also looking at external agencies to help us run hackathons and with writing to get the content we need from a marketing standpoint, beyond the ones that we need from a docs and tutorial standpoint.

Extra learnings and key takeaways

So I'd be curious if others are dealing with having to constantly define your team's roles and responsibilities.

Hal at Niantic would walk into every meeting and say, “This is what we're doing. This is our community and this is what it isn't before we even talk, because there's still confusion over what this is.”

From my experience, that's happened at every company, no matter the size. Where does your lane start? Where does my lane end? What is it that we're trying to do with this thing? Is it what I think we should do? Or is it what you guys think we should do?

Just being that org that establishes what the roles and responsibilities are, what our North Star is, and double checking that.

I think, as we scale and as more people come in or as things change for business priorities, so do your lanes and your roles. I wouldn't assume that every DevRel or advocacy team is the same. The ones I've worked with in the past have all had different R&R. Some of them are really engaged in the community and doing one-on-one conversations. Others are content and tech writers.

In Niantic's case, they’re there to help the developers succeed. They're really seen as helping them build AR applications because it's truly difficult to get started in some cases. So in every situation when you come in for the first time, understand the R&R there.

And then internally share the learnings from the community as much as you can. We all know that this is important, but it's interesting that at every stage, people don't get the opportunity to talk to devs. It's the most exciting part of the job in my opinion.

But package that up the way that you would if you were a sales enablement person having a customer conversation. Package that up in a monthly digest or share feedback to executives and PMs who don't get the chance to hear from the devs, and be that voice internally.

One size doesn’t fit all. Each community and each company is unique. We can show roadmaps and frameworks, but at the end of the day, it's looking at what you have in front of you, what your product is doing, what your team is doing, and what your community needs, and adjusting accordingly, which is why I'm hoping this ‘Please Remember What's First’ thing helps.

We learned how to survive in the wild if that happens, how to focus your dev marketing structure, and some extra tips on building a newly formed marketing org. And if you can take anything from this, at least you can survive in the wild.

This article is based on Meghan Hughes's talk at the Developer Marketing Summit in San Francisco, 2022. At the time, she was the Global Lead of Developer Marketing at Stripe.

You can enjoy this session and many more with Developer Marketing On Demand.

For more expert content from global industry leaders, check out our podcast series!