DevRelCon London 2019 Dec 10th and 11th

Paige Paquette leads developer marketing at Slack, focusing on growing the number of developers who are building on the platform. In this talk from DevRelCon San Francisco 2019, Paige runs through the essential steps in effectively marketing your API to a developer audience.

Transcript

It’s so awesome to be here with just a room full of my peers. This is so rare. This is exciting.

So, I’m Paige and I built my career in developer marketing. How many of you guys do something around developer marketing or something adjacent to that? So, a common thing that I hear especially when I’m talking to other marketing people is like, “Don’t developers hate marketing? Like, how can you market to them?” Who here has heard that? Yeah.

So, today, I really want to take you through a couple simple frameworks and things that I found helpful because the truth is that you don’t need developer marketing experience to market to developers, you don’t even need marketing experience, you don’t need deep dev rel experience.

Anyone can do developer marketing

If you’re just getting started or if you’re just starting out and you’re like, “I don’t even know where to start,” I really want to talk to be for you.

So, first, a little about me. My name is Paige. I lead developer marketing at Slack. At a high level, what that means is that my team is responsible for growing the number of developers who are building apps on Slack and helping them to be successful with things like education, and events, and other things.

So just some quick background is that there’s a large variety of apps that integrate with Slack. Does anyone use Slack? Does anyone use apps in Slack? Okay. That’s pretty good. Okay. So, you guys are probably familiar with this type, right?

There’s two types of apps. The first type is a public app that anyone can use. Here are some examples. You can install it, you can get it from our App Directory. But the second type is a custom app. This is an app that you’re just building for your own team to use, it’s not public. And so, there’s two types of apps.

Developers are important to us. Well, selfishly because that’s what I do, but also because these apps are what make Slack more than just a chat tool, right? And some of our biggest advocates and earliest adopters were developers.

So, today, I want to take you through this in the context of, like, a new API launch, imagine you’re launching a new API.

How are you going to understand your users and then frame your product in a way that resonates with them? And then how are you actually going to launch this thing? How are you going to get the word out? What are some tactics that you can take that don’t require the budget of a big company to be successful?

And then we’ll also talk about, like, a simplified framework for how you might think about understanding your developer funnel and really create sort of, like, a map of the health of your developer ecosystem.

The platform flywheel

All right. To back up, has anyone seen this before? Yeah. So, any successful platform creates this, like, flywheel effect and it’s really important to keep in mind.

So, let’s use Slack as an example. The more developers who build apps on Slack, the more our customers are likely to discover those apps, right? And use them, use them for work, use them to update sales leads, use them for project management. And that usage fuels value.

That’s the only thing developers actually care about, in my experience, is their apps getting used. And that usage fuels more development and it sort of creates this, like, virtuous cycle of any healthy platform.

So, pre-launch. What are you going to say? Who is your audience? How are you going to frame this in a way that resonates with them?

Jobs to be Done

The most important way I’ve thought about understanding why people make decisions and why consumers make decisions is this framework called Jobs to be Done. Who here has heard of Jobs to be Done? Oh, that’s actually more than I thought. Okay. This is awesome.

So, Jobs to be Done is the perspective that people use products or buy services to get a job done. And so, by understanding what the job is, then you’re more likely to understand how you can get them to use your service or to buy your product. That’s a lot. That’s kind of a mouthful.

So, to unpack this, I’m going to tell you a story that I really like. I think it does a good job of explaining this framework and it comes from the Harvard Business Review.

It’s about a condo company, a luxury condo company that was trying to sell a new building of luxury condos and the company was targeting downsizers, people who are moving out of their family homes probably looking for something a little bit smaller, their children were out of the house.

But they were having a lot of trouble with sales. Sales were slow. They started doing, you know, focus groups with the potential buyers, and they’d be like, “Okay. Sales are slow. Maybe you want, like, larger windows.” And people would be like, “Yeah. That sounds cool.” Like, “Larger windows, sure.” And so, they’d go back and, like, add some windows to their showcase units.

Still, sales wouldn’t improve. And so, they’d go back to the focus group people and say, like, “Do you need, like, a second bedroom?” And people would be like, “Yeah. Okay. Sure. That sounds good.” And then they go back and, like, add a bedroom to their showcase unit and sales were not improving.

So they actually brought on an innovation consultant to try to figure out, like, what is going on here. So in their conversations with these focus group participants, people said, you know, they wanted a bedroom, they wanted a big window, they wanted a big kitchen, they wanted all these features.

And yet, in this consultant’s conversations with actual buyers, one theme kept coming up repeatedly, which was, “As soon as I figured out what to do with my dining room table, then I was free to move.” So, like, what the hell is it with his dining room table thing?

So, as this consultant went home for Christmas and sat around his own dining room table, he suddenly realized, like, “This dining room table is where we spend all of our Christmases, it’s where my children’s birthdays are spent, it’s where I spend time with my family.”

And the epiphany here is, like, this condo company is not in the business of selling a list of features. They’re actually in the business of competing with the anxiety of not wanting to move at all. When people were free to do what they wanted to do with their dining room table, then they were free to move.

So, the perceived job that the company has is to target people and sell them a smaller home with many nice features. The actual job is to enable someone to downsize without making them feel like they’re threatening their family ties. Does that make sense?

What is someone hiring your API to do?

So, this is kind of the essence of Jobs to be Done. This is an image you might have seen. I also think it does a good job of explaining, like, what is the job that you’re hiring, that someone is hiring the API to do for them.

This is key. Like, people don’t really buy a bike because of its, like, particularly curved handlebars or, like, the rear derailleur. People would buy a bike for, like, the promise of a more active lifestyle.

And for us at Slack, the way I think about it is, developers aren’t using, like, our Events API, for example, because of certain features that it has. People are hiring our APIs to relieve the annoyance of something that they do over, and over, and over again 18 times a day, whether it’s like updating a sales lead or updating a project management task.

So, that’s the basic framework. I want to take you through how this might show up in a piece of copy. So, you’re writing an announcement. This is a fictional product. Let’s take a look at this.

So, we’ve been working hard for months and the day has finally come. We’re so excited to announce that dialogs are now available. Before, it was extremely difficult for your app to collect a series of user inputs. With dialogs, it’s super easy, giving you a simple, flexible way to create pop-up modals.

This sounds, like, pretty standard. Something that you might read on any product blog. There’s a few things, though, I think we can improve with the lens of Jobs to be Done.

It’s never about you

So, and these are themes that I see over, and over, and over again that I can spot now. So, one is that it’s never about you, right? At the risk of sounding too harsh, no one really cares how hard you worked on something.

So it’s not like, “We’ve been working hard for a year and we’re so excited. The day has finally come.” It’s like, people don’t care, people also don’t really read that much on the internet. Like, that’s just the truth.

Secondly is, I see this a lot, don’t introduce your product by saying how hard things were before you launched it. Again, like, no one knows or cares how hard it was before. I encourage people to speak about what is happening today and most importantly, like, the problems that you’re solving for the reader.

This one is just like, don’t be lazy. People often fall into the trap of using words like easy, streamlined, super simple, to describe their product, and when I see this, I know that this person doesn’t understand Jobs to be Done, what is the job that someone is hiring. Because if you’re using words that you could literally apply to any launch that you would ever do, you’re not getting specific enough, right?

Easy can be alienating

A side note on easy, as well for developers, I feel like it can be alienating to say something is super easy to use because if you’re a new developer or if you’re not as experienced, it may not feel easy as much as you think it is. So, just something to keep in mind.

And then finally, this is just a lot of words. We can probably just cut, like, most of it. Kevin Malone from The Office, I think this a wise quote. “Why say lot word when few word do trick.” He’s so smart.

So this is, like, keeping these things in mind. take a look at this version. I’m not going to read it because you can read it yourself, but I think this does a lot better job of explaining the value.

Make it about the intended audience

First of all, it’s about the reader. It’s not about you, it’s not about how hard you worked on it. It leads with use cases, right? You’re making it about the intended audience immediately. And every sentence has a purpose. There’s not a bunch of fluff. You’re not saying things are easy, and simple, streamlined, a bunch of words that mean nothing. Cool?

So, now you understand how to frame your product. How are you actually going to get the word out? So we talked about funnels. Who here has worked with developer funnels or is familiar with the concept? Cool. So this is a really simplified funnel and I’ll talk about some tactics that you can use at each stage.

Awareness of your API

So, first of all, awareness. Awareness is the first stage of this funnel. Awareness just means someone is aware that your thing even exists. They haven’t done anything yet, but they’re aware of it.

Traditionally, people think of this stage as, like, PR campaigns, other tactics like bus ads, billboards, expensive things, right? But you don’t need to spend a ton of money. Talks are a great way to raise awareness, meetups, syndicated content, GitHub, Stack Overflow. The idea here is that you’re thinking about where your potential users are and then going there. Pretty simple.

Engaging with your content

The second stage of this funnel is interest. So, this means someone has raised their hand in some way and shown some sort of interest with your product.

Typically, this comes in the form of content. This content is often very value-driven like Jobs to be Done. You’re leading first with, “Why even would I spend, you know, days or weeks of my time building on this API?”

So you can think about blog posts, you can think about getting started tutorials, these very simple easy ways to get people interested and help them understand that this could be for them.

Intention to build

Intent means someone, in my mind, someone actually intends to finish something. You can think about this as sort of a conversion moment. Like, someone intends to start building, they’re actually actively building, they intend to finish, and your job at this stage is to remove as much friction as possible from the process of them, like, getting value.

So, here, you can think about 201-level tutorials, really comprehensive documentation, help pages, FAQs, maybe even proactive onboarding campaign that answers some common questions before people even ask them.

Extending product

And then finally, expansion is kind of a funny one. So, someone in this stage has built something and here, they are actively continuing to improve it, they are adopting new features when you release them, their products are getting more and more usage. You can think about this, sort of, like, retention. And here, this is really key because expansion is this phase where you can take a passive developer and turn them into an advocate for your service.

So tactics at this stage, you might think about advocacy programs, right? Someone is already invested. Like, you should make it easy for them to, like, sing the praises of their product to others and also to share their expertise. They’ll probably learned some things.

You know, road shows. You can host your own conference if you’re a big company. Or just, like, regular newsletters, regular ways that people can continue to advance their understanding.

One metric at each stage of the funnel

So, metrics. I actually love the talk before this because I think it really teases out, Sydney. I see you. I was like, yes, metrics are important. So, really, I would recommend picking one metric at every stage of the funnel to basically develop a simple map of the health of your ecosystem.

So if you’re tracking one thing and one thing only at every stage, you can start to diagnose problems and bottlenecks in your funnel when they come up.

So, awareness, people often think of, like, expensive, fancy things like aided awareness studies and unaided awareness studies. You totally don’t have to do that. You can think about, like, direct website traffic is a great metric to measure awareness. Are people going to your website? Are people, like, starring things on things that you’ve put out?

Interest. This is all about engaging with content. So, like, blog reads, pretty simple. GitHub stars. If you have any downloadable assets, are people engaging with them? Very basic. It’s all about focus at this point.

Intent. So again, someone has started building and intends to finish. And this is sort of the conversion moment, right? So, if you have developer signups, that could be a metric. It could be API keys that people are getting. This is like, someone intends to build.

And then finally, expansion. So you can think of expansion in a couple of ways. Retention over time, so are your weekly API calls going up or are they plateauing? Are the things that people are building getting more users over time? And then secondly, if you release new stuff, are your developers adopting it, basically? Are they adopting new features? Are they improving the things that they’re making?

So, really quick case study, I just want people to, like, shout out some potential answers. Here’s the case study. More people than ever are reading your docs, but your API calls have plateaued. What stage of the funnel do we think is leaking here?

Audience member: Interest.

Audience member: Intent.

Paige: Interest, intent.

Audience member: Expansion.

Paige: Expansion.

I would probably say this is likely a problem with intent or expansion because people are, you’re getting interest, right? People are engaging with your docs more than ever. Your docs, these are going up. You’re good there, but that’s not translating into actual, like, product usage. So, something in there is not working.

What tactics could we think about using or things that we want to investigate to fix this problem?

Audience member: Calls-to-action.

Paige: Calls-to-action. Say more about that. Have more of them?

Audience member: Just leading them from the docs to actually make an action.

Paige: Yup. So maybe, like, information design on your website. That’s a really good one. What else?

Audience member: Demos.

Paige: Demos. Totally.

Audience member: Onboarding.

Paige: Yup.

Audience member: Errors in your documentation.

Paige: Errors in your documentation, onboarding. Yup. That’s absolutely right.

So, I would look at maybe you’re getting an influx of support requests. That could give you a clue. Your docs might be out of date, they might be incomplete. Maybe your, like, website design is unclear. There’s a bunch of ways that you can look into this. Maybe it’s a problem with the product itself. Support tickets might give you a clue as to what’s going on.

The launch playbook

All right. So, you’ve thought about how you’re going to frame your product users or to developers, you thought about what your funnel is going to look like. I want to just encourage you, if you’re about to launch something, create a launch playbook.

This should be a single page brief that puts your whole launch strategy together. It’s important that it’s short because you should be focused. You don’t need to do everything. So, I’m going to share what I would recommend for the single-page launch playbook.

So, sections. One, what is the product? This should be a pithy, super-concise, kind of dry, like, very plain, short definition of what your product is.

Target audiences. You probably have more than one, you probably have two, you might have three. So, I would identify the primary audience and then maybe a secondary audience. These are people who you probably have to tweak the messaging for them. They have different needs.

The know/feel/do is, like, my favorite tool of marketing. It’s just a section that has three subsections. So know is, like, what are you actually going to tell people? Typically, this is a few bullet points. Again, it’s all about focus, that basically describe what your product is and what it enables for the audience that was difficult or impossible to do before.

Feel, you’re not going to say this outright, but like, how do you want people to feel about this? It sounds kind of hand-wavy, but it’s actually helpful. Do you want them to feel relieved, excited? What is the feeling that you are trying to impart in this launch?

Do is simply the call-to-action. What do you want people to do? What is the single most important action that you’re going to be looking at as a measure of success?

Goals and metrics, pretty straightforward. What are your goals and how are you going to measure them? I always recommend having one clear goal. You can look at other things, but, like, get clear on what your number one measure of success is going to be.

And then tactics, simply how are you going to get the word out? I always encourage folks to think about launches not as a day or even a couple days, but, like, as the start of a long series of things. So, organize your tactics in, like, day of launch and then follow on tactics.

You want to extend the moment beyond a single day. You want to make it a journey. Like, one example could be you release a blog post on the day of and then you, in the blog, invite people to, like, an online session that they can join in a couple of weeks to get a deep dive into how to actually use this thing. Cool.

So, today, we’ve covered some ways to understand people through the Jobs to be Done framework. We talked about understanding growth bottlenecks by building a simple funnel. We talked about some tactics that you can use to get the word out at every stage of the funnel and then bring it all together in the launch playbook.

Developers are humans

So my last piece of advice, the answer, my secret, to the question when people are like, “How do you market to developers? Aren’t they, like, so grumpy and hate marketing,” is actually this, “Developers are just people.”

Treat people like people, treat them with courtesy, treat them like they’re intelligent, and they will respond, right? If you treat anyone with courtesy and you avoid jargony, salesy, lazy language, you’re going to do just fine. Thank you so much.

Recent Articles

Sue Smith

Author

Sue Smith


Sue works in developer education / advocacy and is based in Glasgow, UK.

Write for us

Upcoming Events

Join our Newsletter for the latest DevRel news