Productive product partnerships

Kelley: Quick raise of hand, who thinks that DevRel should belong in product and who thinks it should belong in marketing? Alright, we've got some people in both camps and I'm here to tell you that I don't think it really matters. I'm here to talk about an alternate opinion over there. I'm here to talk about what you can do as a DevRel team to work good internally with your product teams. This is productive product partnerships with a lowercase p as someone said for partnerships. So if you're doing external partnerships, I value your work. That is not what we're talking about here today. My goals with this are to set you up for success in your DevRel programmes in terms of, especially if you're doing any of that advocacy work of working with your product teams, you want to go into that with the least amount of frustration possible.

And this is true both if you are branching into new products or maybe that's done via an acquisition of some products, which was how I was brought in when we acquired our Authe product, they decided to bring me in to try to build some of that product led growth motion for a company that had previously been much more focused on the sales led growth. And this is in Twilio's case too. This works really well in terms of doing product evangelism for certain products that we offer. It works well for things like the user verification products. It didn't work as great for our video product. And I'm going to talk about some of the reasons that that is and some of the playbook that I think that we should use. So thank you again for having me today. I live a couple hours north of New York City here with my dog there.

You can see us, my chief stick officer. I've been a Twilio now for seven years. So I have the privilege of having been the first product evangelism hire. And the way that I define that, which I decided I get to define that, is a combination of the internal advocacy and the external promotion. And so there's a overlap of those disciplines. We have people that are focused on each one of those because we're a larger team. I recognise that not everybody here has that team. And you might be doing all of this together. And so maybe some of the stuff that I'm talking about will speak to you because there is that overlap. The product team that I support is really amazing. And so I think that there's definitely some survivorship bias here that I will acknowledge in terms of the fact that what's worked well for me is because I get to work with really great product managers.

But that's part of the thing that you need to recognise is when you're going to have a product team that you are going to be able to work with and that's going to want to work with you. And because I have the tenure there, I've seen enough change to know what at least know or have opinions about what works well. So let's get into the playbook that we have that we've tried to roll out to other products and where that's worked and where that hasn't. And at the end of the day, all of our success comes down to better developer experience. That is the goal of what we're doing. It's not necessarily always about driving the awareness side of things because we want to make sure that we're improving the developer experience for the people that are using our products.

And when I talk about some of the playbook here, so we have get stakeholder buy-in, and this is if anything else, the biggest thing that you need to make sure that you're doing when you are going to try in and work with DevRel and product together. So the stakeholders are going to be different depending on your company. Obvious stakeholder here, product managers, you might think that that's obvious, but it might not be for some people because if product isn't willing to work with you, then you're going to have a really hard time. And before you go in and try to hire for somebody to do this or bring in developer relations to try to improve, give product feedback. If you know that your product team is not amenable to that feedback, if you don't have that relationship with them yet, it's something that you want to work on building before you dedicate a lot of resources to that.

And you can do this all day by building programmes and processes. But underpinning all of these things is that building relationships side of things. So whether that's with product managers, with engineering managers, with solutions engineers, even support, there's different teams that you want to have in terms of your stakeholders to make sure that you have those relationships built. So focusing on the one thing, if you forget anything from today, echoing something that Ron said earlier in his workshop, the one thing that you want to do here is build relationships with your teams, with your stakeholders, and especially with product. This is not going to work as well for you if you don't have those personal relationships, even if that's something that you have great processes in place. The next thing in the playbook is to become a subject matter expert. And I say a subject matter expert, you don't necessarily have to be the subject matter expert, but you want to know your products, you want to know how to get information about your products.

And so this is both industry expertise about what's coming in the industry. So I work on our user verification products. So I've been doing some research on PEs keys and that kind of thing, but I'm also an expert on how our products work so that if there's an edge case that comes up, people are seeing error codes, they have information about how do you send user verifications in Singapore. I know some of those edge cases that you need to take into consideration there. Or if I don't know, I know who I can go to ask for that information. And that's I think a key point with a lot of this stuff is you don't necessarily always have to have the answer in DevRel, but you can be a step ahead of the people that are asking the question and help guide them to that answer a little bit more effectively than they could on their own.

And then finally, learn your product development process. I think if you're going to work with product in order to make the products better, you need to know how product works. And so that's asking where they get feedback, how the products are designed, is there a design document? Who reviews those? When do they review those? How often can you make changes to the API? If it's in beta, can I still make changes to the API response? This is going to depend on your company and your company policies if you have policies around this. So that's something that's really useful. If like Twilio, you can only make major changes in the API when it's at a pilot stage. You want to make sure that you get in pre-pilot to make sure that you are reviewing the products so that you can give that developer feedback while there's still time to make those changes.

And like I said, underpinning all of this is building relationships. You're going to have a much easier time with all of this if you have a product manager or product managers, engineering managers, any of these stakeholders that you can go to have a conversation. You want this to be mutually beneficial. You want them to think of you as a resource as much as you think of them as a resource for making your job easier. And you want to make sure that you have aligned incentives. And so that's one thing that I think is really important is if you are trying to improve signups, but all that sales cares about or product cares about is improving revenue, those might not always be completely aligned. So if revenue is one of those things that they might be able to also improve revenue based on things like selling support plans, but that's not necessarily aligned with some of the self-service goals that you might have on a developer relations team. So you want to make sure that you're talking about those things and getting alignment there. It's not that you have to have complete overlap, but you want to make sure that there's enough there that you're going to have that mutually beneficial relationship.

And finally, this wouldn't be a talk at DevRel Con if we didn't talk about metrics for success. So the ways that I try to think about where we impact the developer experience metrics here are focused on the conversion and usage stage. And I think to Joyce's point this morning, these things change over time, right? You'll notice that there is no metric here about retention, and that's something that we've looked at before and we've cared about it in the past, but that isn't one of our current priorities right now. And so when I'm reporting back on the work that I do, I'm thinking about how we're converting users. Is there a clear value proposition for the product for developers that's that sign up if they're signing up. And there's that idea there. And then usage API calls product spend, that type of thing. So thank you so much for having me. I think this is a great conversation starter in terms of what you think works well for working with product. I focus on what I think works well. If you want to hear my opinions of what I think doesn't work well, you're going to have to come find me after. And once again, my name is Kelly Robinson and thank you for listening.