[2:06] Paige gives her advice to those who want to develop an ecosystem.
[3:58] What are the jobs to be done while starting to develop an ecosystem?
[5:21] What developers should you target?
[6:56] What did it look like for Paige at Slack back when she was starting out and identifying those initial developers?
[8:22] Once you’ve figured out which developers to focus on, how do you actually attract them?
[9:54] How does Paige get developers to actually build something of value?
[11:50] After you have developed something, how do you get people to adopt it?
[13:21] What metrics matter in a partner ecosystem or a developer ecosystem?
[14:45] How to scale a developer platform?
[16:48] If you build a successful partner program, what's the impact of it on the business?
Paige Paquette: This is probably one of the most common questions that I get for founders is:" We want to develop our ecosystem. How do we do it?" The first thing is to understand, of course, that" developers" is a blanket term. Almost anyone can be considered a developer these days, so it's not enough to just say" We're targeting developers," right? Great developer marketing, great DevRel, great marketing in general always starts by deeply understanding and aligning on who you're targeting in the sense of a primary user and potentially a secondary user and probably a tertiary or third decision- maker. That might be an executive decision- maker, that might be someone else.
Blake Bartlett: Welcome back to the BUILD podcast. I'm Blake Bartlett, a partner at OpenView. The world of SaaS is always evolving and we're here to help you adapt, compete, and win with your startup. The BUILD podcast brings you stories and insights from my conversations with the most successful people in SaaS. In today's episode, I chat with Paige Paquette about how to build and scale a developer program like an app store or a marketplace that's built on top of your product. Paige certainly knows a thing or two about this, as she's spent years leading the platform and developer marketing team at Slack. In today's conversation, we go through Paige's step- by- step guide, from identifying which developers to target, how to attract them to your program, and ultimately, how to get them to build something that's valuable to the ecosystem and that actually gets used. All that and more on this episode of BUILD, so let's dive in with Paige Paquette. Paige, thank you so much for joining here on the BUILD podcast. It's great to have you on the show.
Paige Paquette: Thank you. I'm happy to be here.
Blake Bartlett: We're going to talk through a lot of things. I think a great place to start is that a lot of people have this idea. They want to start and become a platform, or they want to build out their developer ecosystem, or build an app store or a marketplace, or the list goes on, but it's a lot easier said than done, and so when somebody comes to you with this, like," I want to be the next big thing in developer ecosystems," what's the first piece of advice that you'd give to them?
Paige Paquette: The first thing I try and understand is the why behind building a platform beyond just wanting a developer ecosystem, right? Why should this platform exist? That's the first question you need to be able to answer. Critically, some of the questions that I would ask are: What are the core use cases that the platform needs to unlock for your user base? What jobs to be done are you going to solve for your users through this ecosystem? Secondly, why should developers care? Developers' time is split and there are more and more and more platforms vying for their attention. You really need to hone in on the compelling reason why developers should spend time with your APIs beyond just the fact that you have an open API. Often, those reasons really come down to growth and unlocking revenue for them. If you can't help them get users, if you can't help them grow or unlock revenue, it's going to be a hard sell to external developers.
Blake Bartlett: Yeah. I like that, starting with the why, and the why being both what are the jobs to be done for your existing customers and users, but also, why should developers care? What are they going to do with this? What are they going to get out of it? Understanding that as a starting point is so much more powerful and more helpful than just," Well, all the big companies have an app store, so I have to have one as well." But really why, why does this need to exist? I think that's a super helpful starting point. Could you say a little bit more about the idea of jobs to be done within the context of that question?
Paige Paquette: Yeah, so understanding the jobs to be done, the jobs that your users will achieve through your platform. By that, I mean jobs to be done is a perspective that helps you understand why consumers or why users make the decisions that they do. Another way to think of this is what are the tasks, or what are the pain points that are going to be solved through your platform? It's not enough to just have a bunch of apps. That's not a job to be done. You actually have to have a perspective of the problems that you're going to solve for your users through the platform. I don't want to discount that sometimes competitive reasons for having a platform, they can be a real reason. If your biggest competitor doesn't have a platform or it doesn't have apps, that might be a reason for you to do it, but you don't always need an open developer ecosystem. You might just want to think on or focusing on a few strategic partnerships that might solve that for you, or you might even go ahead and build the top 10 integrations yourself and just say," We'll worry about an open developer ecosystem later," so there's, different ways to crack that nut. The first step is to figure out the why.
Blake Bartlett: Say everybody checks those boxes and they're like," Awesome, good to go." All right, Paige. Now, step one: What developers do I target?
Paige Paquette: This is probably one of the most common questions that I get for founders is:" We want a developer ecosystem. How do we do it?" The first thing is to understand, of course, that" developers" is a blanket term. Almost anyone can be considered a developer these days, so it's not enough to just say," We're targeting developers," right? Great developer marketing, great DevRel, great marketing in general always starts by deeply understanding and aligning on who you're targeting in the sense of a primary user and potentially a secondary user and probably a tertiary or third decision- maker. That might be an executive decision- maker, that might be someone else, so there's probably two to three core personas that you need to nail down. The way that you do this is pretty simple. It really just starts with interviewing current and prospective developers, deeply understanding your early adopters. It's really a set of deep conversations with people where you're trying to understand them as a person, their role, what keeps them up at night, their motivations, their pain points. You really want to listen closely to the phrases that they use when describing their problems and their motivations because that's the language that you want to build your messaging off of. That's what you want other people coming to your website, for instance, to see so that they can say," Oh, I also have that problem. This sounds like me. I'm going to try this."
Blake Bartlett: What did it look like for you guys at Slack back when you were starting out and identifying those initial developers?
Paige Paquette: Slack was a rocket ship. At that point, this was like 2016 when I joined, so this was like peak growth mode, and so we didn't so much have the problem of attracting developers. The advice I'm giving you now is more oriented towards this tiny startup, the zero- to- one platform. The other thing is that Slack, with acquiring developers to our ecosystem, we were primarily drawing from our own user base. It's pretty rare that you would find a Slack developer that wasn't also a Slack user, which has major implications on if you think about the top of the funnel, like where do you find these people? How do you acquire developers? The bigger challenge, I think, that we were facing at that time was around helping developers build something with as little friction as possible and critically something that would get used. The use of piece is super important because you can send all the special stickers and all the swag that you want, as I said, but if developers are building stuff that never gets discovered or used, then they're just going to move on to the next platform. You really need to deliver on that value prop for them and help them build things that are useful and with as little friction as possible.
Blake Bartlett: Okay, so you figured out which developers to focus on. Now, how do you actually attract them?
Paige Paquette: Yeah, so once you've figured out a little bit of" This is the type of person that we're going after," who we think is going to get outsized value from our platform. It doesn't mean you're ignoring everyone else, but it just means that you're adding a layer of focus to your efforts, which is super important. Then it goes down to, okay, what are you going to say to them? What are the value props to use, like business jargon? It could be growth for an ancillary product or for their main service, or in the case of an internal developer, it could be solving their own problems. It could be professional recognition or professional development. Look at Salesforce. Professional recognition is a pillar of their massively successful developer community, so it's value props. Then from there, it's thinking about," Okay, what are the channels and what are the tactics that we're going to use to actually find these people? Where do they hang out?" As I said, you can't really do that without understanding who are you trying to find. We think about this in terms of watering holes. There's existing watering holes, to use that metaphor, where these people are hanging out. There's existing blogs, newsletters, community groups, meetups, social networks, et cetera. There's existing places where these people hang out, so just start by thinking about where might those places be and how can you go to them first versus trying to acquire people out of the ether to come to you.
Blake Bartlett: Now, how do you get them to actually build something and build something of value? What kind of enablement, what kind of support, what does that process look like to actually get to the promised land of a cool thing being built?
Paige Paquette: Well, you've already sort of hinted at it, which is enablement and support. At this stage of the developer funnel, your job is to reduce as much friction as possible in the getting- started process. Obviously, that starts with a good product like well- built APIs and developer tools, but it also means things like really great docs. I know everyone says" Docs are table stakes," but I work with a lot of companies and I will say docs are not treated as first- class citizens of the product all the time. It's pretty rare that they are, actually. That can look like making sure that education is available in a variety of mediums. That means webinars. Weirdly, surprisingly popular. You don't think webinars are going to be that popular, but I don't know, in my experience, developers still love webinars. That can look like YouTube videos, getting- started tutorials that are written, et cetera, code samples, lots of robust code samples. Then also, guidance around what a great app looks like. I think it's a belief that it's like if you build it, they will come kind of thing, like if you just create a good API, developers will just figure it out themselves and that's the way that they will prefer it. That's sort of the assumption, but I don't actually think that that's true. I think some developers, yes, but a lot of them just want to be told," Okay, what should I build? Don't make me go through the motions of trial and error to figure that out. You're the platform, you're the company, you know your product best," so encourage people to create things like design suggestions or ideas, idea lists, et cetera, that help developers build something great.
Blake Bartlett: We're at the point where you've built something now, how do you get people to adopt it?
Paige Paquette: It is absolutely your role as a platform to help users discover and adopt relevant apps. Otherwise, why have a platform? Barring that, you want to take the same approach that you take with your developer ecosystem building, which is starting with the user, starting with the person themselves, what are the top roles? What are the top jobs to be done, so to speak, that you're going to help these people achieve? Then segment these users by their role and start to curate recommendations for them. By that, I mean in my experience, people aren't seeking to go to an app store to spend an hour browsing for new things. They're really going there with a job to find the tools that they already are familiar with and that they use. But yeah, the bottom line is people care less about the total number of things that are available to them. They really just want to know," Do you have the tool that I use? Do you have the tool that is going to help me do my job?" so help them find those tools, essentially. Then from there, it's the role- based. What roles do you really want to solve for? Maybe pick a few of them to add some focus again, and then what are the tools that you want to make sure exist for those roles?
Blake Bartlett: We've started to already get to it a little bit as to what does success look like, but I'm curious, what metrics matter in a partner ecosystem or a developer ecosystem?
Paige Paquette: Ultimately, it comes down to usage as a proxy for value, let's say, if you don't have a monetized platform, which a lot of SaaS platforms aren't natively monetized. By that, I mean are people using the things that people build on your platform? To make that more tangible, when I was running developer marketing at Slack, one of the metrics that we were interested in was the number of things that were not only built but actually actively used, which is a really high bar because you're not just focused on," Can we get more developers?" period, which might actually mean a bunch of people, they're looky- loos, maybe they've started building something and then abandon it, et cetera. It never actually generates value for the end- user, so find a metric that speaks to that value for the end- user, and then go from there. It doesn't so much matter what your exact metric is, it just matters that you've aligned on something that you feel is directionally correct. You can always optimize it later, but just make sure that all the developer- facing teams are aligned on it so that you're all pointed in generally the same direction and know what you're trying to inflect.
Blake Bartlett: That closes the loop, if you will, but that leads to another question, which is: How do you then scale it? You've done this a couple of times and you're getting some good success. How do you go from those early days to where Slack is or somebody like that is today?
Paige Paquette: That is a great question. I think oftentimes this is where we get into the difference between DevRel and dev marketing, which looks very different at every company. The role of a marketer is generally focused about one to many. It's enabling many people through programs, through campaigns, through community. Then the role of developer advocate, in my mind, is more of a one- to- one. It's building deep relationships from a human to human level and getting feedback and taking that feedback back to the product team. They're different, but they're complimentary. When you think about scaling, if you're, let's say a small startup, I would say definitely get a DevRel person sooner than later to sort of take that initial zero to one on. At a certain point, you might need to think about a more scaled approach through something like a developer or a platform marketing person who can work with DevRel and with product to scale those efforts beyond what is possible through one- to- one relationship- building. Also, community itself can be a massive, I mean, benefit for a lot of reasons, but in the perspective of thinking about scale, if you build a smart set of community programs, you can start to see the benefits of scale very quickly. If that's a meetup- based program, you might see 50 meetups be organized, for instance, that otherwise would have fallen on your shoulders as a company, and you didn't even have to plan them. You just had to build the community and make sure that the people in the community were happy and enabled. Community can be massively effective and the ROI can be really, really effective with community.
Blake Bartlett: In closing, if you build a successful partner program, what's the impact of it to the business?
Paige Paquette: Ultimately, it's hugely impactful, but a lot of people think that if you can't put an exact dollar amount on a platform, i. e. like the amount of revenue that it is generating for business, then why invest in it? But I think that that's actually a really narrow- minded way of thinking about the benefits to your core business. Other ways that you can know that it's successful are by looking at, essentially, usage: Are users consistently using the platform? We also know that platforms bring a host of other benefits, like retention, they're less likely to churn, they're more likely to pay, they're more likely to expand, they're more likely to pay more over time. It's a lot easier to rip and replace the product when it is not connected to every single critical workflow of your company. It's not always an easy argument to make for an executive team that's focused on dollar figure, but it is possible.
Blake Bartlett: It's all about the long- term bet and the long- term ROI. It's not something that you're going to see within one quarter, but that's the bets that we make in building large and enduring businesses.
Paige Paquette: Yep.
Blake Bartlett: Paige, thank you so much for joining us here on the BUILD podcast. It's been an awesome conversation. I know I've learned a lot and I'm sure our audience has as well.
Paige Paquette: Thank you. It's been really fun. Thanks for having me, Blake.
Blake Bartlett: Thanks for you're listening to this episode of BUILD. If you like what you've heard, leave us a review on Apple Podcasts and subscribe to stay up to date with all the new episodes. Want more insights from OpenView? Follow me, Blake Bartlett, on LinkedIn for daily PLG content, and head to our website to sign up for our weekly newsletter.