The intersection of developer relations and product management

So I'm product manager, don't tell Matthew. Not actually a dev rel, but I have worked with a lot of dev rels, and as a product manager we are professional scientists. We've been there, talked to customers do research, we make hypotheses. You didn't quite get as nervous as I was hoping, but yeah, that was my hypotheses. So if you see an office space, you've seen this conversation. My guess is that guy actually was a product manager, you know, take the spec from the customers to the engineers. Well, that's what I do. I talk to the customers and then I go and I take that to the other product managers and engineers and we build stuff. And sometimes it looks like that, it's a lot of fun. I really like that everybody's heads are like perfectly still, but there, yeah, all right.

So I found this on DevRel.net for Matthew, and I actually think this is really interesting how dev rel teams feel this way in between different dev rel teams at different companies. I actually feel exactly the same way about dev rel and product. So product managers, like I said, they sit down with customers, they talk to them, they do research, they bring this back, build new products that solve really interesting customer problems. Dev rel has all this information. We should be sharing this information. We wanna work together. So something else that's really interesting is if you look at the mission statement for the SendGrid product team, we want to do the same thing that dev rels wanna do. We wanna create these products that customers love and value. We want people to be really happy. It just works. We all can just build really cool stuff. Nobody really wants to know how email works, they wanna come in and copy paste and move on with their life. That's what we want from developer experience product team. So there's a disconnect. Part of the disconnect is that our go-to market times are different, they're completely different. So where is this disconnect?

Mind the gap

Dev rel talks to developers per day, per hour, per minute. Sometimes product people will talk to a couple developers a quarter a month. It's just a different economy of scale. So the normal product process, we identify an opportunity, and this could be any number of things. Somebody came and told us how much we screwed up our C Sharp library, if you saw Elmer's talk earlier, or that we need to add this new feature to email that only two people in the world have ever done. So we prioritise these based on how much feedback we get and then we spend some time digging in with other customers that look like these customers that we just talked to, and we try to figure out if this is actually a pervasive issue or not. The problem that we have is we can only work on one thing. We don't get to do 15 things at once. We've got to go research this one thing, go really deep and make sure that we can actually find a real problem. Once we've found a problem and we can actually verbalise what that problem is and it's interesting and potentially profitable, hopefully, we actually go and we start building a solution.

We'll take a first pass, very much like UI, UX team, and then we'll go and put it in front of customers. And we spend more time with them and we learn from what we did well, what we did wrong, and we iterate, we do this again. And then finally, if everything goes well, we actually take it to market. We hand it off to our dev rel team into marketing and everybody else and then we all make money, right?

This is how it actually goes. I'll come up with an idea, I want to be able to print emails and send them by mail for some god awful reason, and we go and we test that out. Well, it's not really a problem, nobody really wants to do that, maybe grandma, but she's not bringing in a lot of profit. So we go back, we pick a different idea. We go through the whole loop. We go over and over and over again. This is one of the biggest reasons for the disconnect. Our product team has to be able to justify spending time with engineering, and engineers are very, very expensive. Some of those 250 people that were up on that last presentation, those are engineers. These are people that have been coding for 10 years and now decided to go into dev rel. They're worth every penny, sort of the engineers at your team. All right.

So we're talking about one of the examples. If you saw Elmer's talk earlier, this is what he was talking about. We decided that we wanted to come out with our libraries very quickly so that we could actually give our new mail send endpoint as well as all 300 something endpoints that we had in our libraries. Before, we had one endpoint in every library. So we're talking about orders of magnitude different code, different lines of code in each library and all of that. So we set full in interfaces, reflection's awesome, a super easy way to do this. Well, that kind of blew up on our face. Let's see, so C Sharp, we totally screwed that up. We learned all about our moms from the ghetto community.

Let's see Java and Go are static languages that just we can't do that. And then the other languages all worked perfect, and it was great. But we really actually that hypothesis was just wrong and we had a really hard time actually getting to customers. We didn't have anybody who had opted in to be contacted. We put everything out on the repos but our repos had been dead for a year, like nobody had been in there, only people looking for support through a different channel. We hadn't been actively doing anything to gain people's trust.

Building trust

So one of the ways that we can gain trust is by having personal one-to-one connections. Again to refer to the previous presentation, the things that are most effective for us, events, one-on-ones, and hackathons. It's because we're spending time with developers. We're showing them that we're real people, we're not trying to sell them, and that we deserve their attention. And once you have a developer's attention, you now have the opportunity to ask them to opt-in for more. You can say, "Can we go talk?" things like that.

So here's my hypothesis. We can actually work together to drastically improve developer experience as a team rather than completely separate kind of angry at each other because you guys get to travel all the time and get to go have really awesome beer in various countries and we're super slow. We actually work together, maybe you guys can take me on a trip, that'd be sweet. So how do we do it? We'll get to how do we do it. Let's look at what we've got. So to help our relations, you guys have all the developers, product, I need them. Oh, I also put random builds in just because it's fun. You'll see. So we need feedback, but you guys have it in real time. You guys are able to immediately test something. You know, we talked about that go-to market and just build something and see what happens, right? We can't do that in product. We don't either have the skills or the resources to able to do that. And by resources, of course, I mean real engineering people. We all actually want the same thing here. We want amazing developer experience. We want our developers to tell all of their friends that we did this amazing thing and that we actually give a shit. We have that empathy. We have listened. We know what we're talking about because we've spent time with you.

All right, so what can product managers do? We should tell you guys what our road map looks like. What's in our opportunity backlog? What are we thinking about? What are we hearing? That way if you hear the same thing you can tell us, or if you're not hearing that at all, you can tell us. So that way we can save some time, we're not wasting our time chasing, printing emails. I didn't actually do that just so you know. We should also feel okay to come to dev rel and say, "Can we have some help? We need people that look like this. We need people who have used this feature, that maybe used this competitive product so we can ask them what's really working over there, why they choose this thing or that thing." We need people in our NodeJS library to tell us that the way we did know is just not great." And then once we have these results we need to follow back up and we need to tell the dev rel team what we learned. So we spend extra time with these developers, we learned this thing. Please if you hear this again we wanna know. This helps us to sell the product back up the chain to be able to get the engineering time to go and fix these problems.

"If you see something, say something”

So conversely, if you're on a dev rel team, ask the product managers what they're up to, right? Product may not feel comfortable coming and talking to you, so go bug them. They actually do want, they are real humans, they're not all assholes, some of them, but they wanna talk to you. They wanna know what's going on in the community because you're gonna be able to save them time and you make them look better, and as soon as they can release that product, it helps you guys, and it's a nice symbiotic relationship. If you learn something, share it.

You know, in the U.S. we say, "If you see something, say something." Same deal. If somebody is complaining about this authentication mechanism or this endpoint totally sucks because I have to do all these extra hops, bring that back. And every time you hear it bring it back. If you can bring it back with one of these, it's super helpful. That did work good. I did that without looking. Bring a gregarious developer back, give me the contact information, get their permission for me to contact them so I can have this in-depth conversation. I'm gonna ask all kinds of questions, you know, what's gonna be your GitHub username, how many kids do you have, what else do you do on the side because I wanna try to get into their mind a little bit, ask them what they do, and then I'm gonna dig in on the thing that I need to know, and that will help us out a lot.

If we do this right, we get to cuddle. I found that when I was looking for that friend's gift, and I was like, "Yeah, I gotta figure out how to make that work."

So really I think the opportunity here is to work together, we can actually make everything move faster. We can build better products for our developers and we can build better products that we're proud of taking out in the world and sharing with everybody. Thank you.