Laura Schaffer: evaluation

Transcript context

…The first is that developers are just a very different audience from any others. I've seen so many people who have come in strong on growth really well or product really well with other audiences and like, "Oh, I'm going to take all those learnings, I'll pivot into serving developers." And as it being a very steep climb because developers are so different. And let me give you a couple just fun facts that make them really different. And some of these have some interesting stories. One is developers, almost two, one, do not look at your marketing website at all. They go straight to your signup flow. So what that means is all that beautiful context that you're setting and the product aid pricing, all that stuff, very often they're skipping all of it context free and going straight to your signup. And so anytime you make an assumption like, "Oh, well, they probably know this coming in to signup." Or like, "Well, we don't need to include, that's on the marketing website." None of that's going to apply to this group of people. They're there. The analogy I have for this group is they're the IKEA buyers who when IKEA package comes, they're not opening up the instruction manual and reading in and then starting to go through, they're in there tearing open the bags and starting to pull the pieces together and trying to build it. They'll come up for context and steps and such when they get stuck if they're motivated. So that's one thing. And then another one is just the aversion to talking to sales. And I think hearing that, some they're like, "Oh yeah, well, I hate sales too." When I'm sent out and get bombarded by sales, that's the worst. I totally get that. But developers are on this whole other level. There was a fang company sign up for Twilio, built a POC, launched to production, all this, and operated in that space for months without engaging once with sales. I was trying to reach them and I ended up being the one that talked to them first because they reached out to support because there was something about their delivery that was off ,there missing a feature and they did not want to talk to sales. They ended up talking to me when I was in product marketing. And that was my first exposure of like, these people not want to talk to sales. And then there's another one where a giant retail company where the engineering team signed up with their personal e-mail addresses so they wouldn't get bombarded by sales. It was only later that we found out. Anyway. But the thing that's most important, these are fun facts, but the thing that I would say is the most important, the thing to leave with listeners here is what makes them so different? Why? What's the deal here? And it stems from their charter and their responsibility. ing that I would say is the most important, the thing to leave with listeners here is what makes them so different? Why? What's the deal here? And it stems from their charter and their responsibility. So if we put ourselves in developer's shoes for a minute, a developer, if a developer is required to use your product, especially if they're the primary user, the primary builder, it's really important to recognize that they're responsible for that. If your service goes down, that's their responsibility. Not just for themselves but their team. If the pager wakes up someone because the service they bought from you goes down, that's on them. If, oh, it turns out that doesn't work with the systems that they said it was, well, that's on them. Doesn't integrate with the data the way that everyone wanted it to? That's on them. Everyone lives to developer when it's not working right and it cannot work right. In so many ways, that's their failure, it can cost them their job, it could cost them the trust to their team. It cost them their reputation. And that means that the stakes are very high for them every time that they're adopting something new. So they can't afford to take someone's word for it. Especially a sales rep who might have some other motivations from their perspective, they can't afford to trust your content or someone's word. They must do it. They must prove it themselves. And so that's why, for developers to be bought in, they need to do something, build something, a proof of concept at the very least, if not moving further than that. And so that means they're going to be pretty darn deep in their self-serve experience with you before they're ready to commit. And so if you are a company that is providing, that requires developers to build, you must invest in self-serve experiences in order to effectively convert your audience. And you should be thinking of them. Something akin your self-serve function and growth folks, someone akin to Salesforce because your developers are not going to accept sales coming in and trying to convert them at that stage. I love that you always come back to the psyche of the user and how in this case, developers like, here's why they're responsible for this thing. Salespeople are going to convince them this is going to work. And it's not. That's a really interesting tool and that's a really cool takeaway. Is there anything else that we didn't cover before we get to our very exciting lightning round?…

Stored transcript either side of the excerpt. The highlighted words are the published quote; the surrounding text is unedited source, never generated.