Interview Intro

Richard Rodger:  [0:00:00] Welcome to the Voxgig Podcast. We talk to people in the developer community about developer relations, public speaking and community events. For more details, visit voxgig.com/podcast. All right, let's get started.

Today I am speaking to Daniel Bryant, who has got me into a lot more conferences than I care to admit, who is head of dev rel for Ambassador Labs. Daniel was pretty much there from the start and has had the experience of building an integrated developer relations function inside a company that works really well with all the other functions within the company.

But we start our discussion with the banal: swag, the place of swag in the modern developer conference. A question of great importance for your times. I don't know where I would get my T-shirts from if there was not swag.

We then get a little philosophical, because the word community has come to mean a great may tings and almost nothing now. And what does it mean to have a developer community, and what does the word community mean in that context? Daniel talks about why he prefers the word ecosystem.

Finally, we talk about product-led growth and how creating the right operational structures, and in particular, working really well with your data science team, can be super effective at making the whole organization work together functionally. All right, let us get started. [0:01:40].

Main Interview

Daniel Bryant

Richard Rodger:  [0:01:41] Daniel, it's great to have you on the podcast. Welcome. [0:01:43]

Daniel Bryant:  [0:01:44] Thanks Richard. No, it's great to be chatting again. [0:01:45]

Richard Rodger:  [0:01:46] Awesome, yeah. I – and in fact, you have the honor of being the last person that I spoke to in person at a conference before COVID. [0:01:54]

Daniel Bryant:  [0:01:54] That's it.

Richard Rodger:  [0:01:55] So, I think it's bringing back good memories. [0:01:58]

Daniel Bryant:  [0:01:59] Yeah. The KubeCon. [0:02:00]

Richard Rodger:  (Inaudible, 0:02:00) we were going to the loos, right/ Yeah, that was KubeCon London, you're right. That was KubeCon London. So, I'm just talking to you on Zoom here, and I notice the lovely swag you have from Ambassador Labs, lovely sweatshirt. So, I thought we would jump straight in to talking about swag, the place of swag in developer relations. What's the future of swag? This is the most important question in developer relations today. [0:02:28]

Daniel Bryant:  [0:02:29] You reckon? As we were talking off mic, it's interesting, and a some would say controversial topic. Because a lot of the swag is not particularly environmentally friendly, for example, and it's manufactured ad hoc. And then a bunch of stuff often gets thrown away at the end of conferences, if not everyone picks it up. So, I do see some folks – and we've even looked at it at Ambassador Labs – offering to donate to charity in lieu of giving swag.

So, if someone comes up to the booth, you do the pitch, have a chat; learn some good stuff. And then you, like – they donate to their charity in their name, like instead of taking a T-shirt, instead of taking some other kind of swag. So, that is increasingly popular, but still, it is niche. When I – I was in KubeCon Detroit, last month now, and the vendor hall was packed. It was, you know, probably one of the most vendors I've ever seen at a KubeCon, and swag was front and center.

You know, you get your clichéd competitions; you win your Lego Star Wars stuff, and there's lots of there – that there, lots of fun competitions. But every vendor had some form of, like, you know, takeaway. Like, we did little angry penguins as we call them, squishy ball, stress balls, or angry blackbirds. So, our official mascot, Edgy, it's a blackbird. And so, we did that, and of course, it had our logo and our website on the back.

Because that's kind of what – for me, the swag stuff, like – I try to keep it, like, not to heavy environmental impact, but some fun stuff people can take away. Because I think back when I was on the other side of the equation, when I was a customer and chatting to folks at conferences, I would take the -shirts, the pens, the swag. And it would – I sort of put it on my desk; you know, I like to have that kind of executive toys, what we call them. So, when I'm thinking, sometimes I'll throw a stress ball around or whatever.

And you couldn't help but sometimes you'd be thinking of a problem and you look down and you see that stress ball branded with X or you'd see that pen branded with Y, and it would take you back to the conversation at the conference. And you go, "Oh, yeah. I need to follow up with those folks." So, that's my take on swag, that people – some people will – are going to grab whatever they've got, whatever you've got. Some folks are only going to take swag – interesting vendors and then use it as a prop to remind themselves of the conversations later.

So, I think swag is important from that perspective, but I think it's going to be going – my personal take, see with the general awareness of environmental issues now, is we'll see less and less swag going forward. I think there's still going to be an important place for it, but less and less classic – bring everything and the kitchen sink to give to folks as they walk past the booth. [0:04:54]

Richard Rodger:  [0:04:55] Yeah. The first question I would have is, what the effectiveness is. And I'm sure somebody, somewhere has an Excel spreadsheet tracking it, of the squishy toys with the URL on the back. Because if the developer is there at their desk, they're trying to solve a coding problem, and the squishy thing is helping them relax or figure it out, perhaps it works. Another- [0:05:18]

Daniel Bryant:  [0:05:18] That's it.

Richard Rodger:  [0:05:19] Another thing is, have we just – because developer conferences, if you look at the history and how they came about, they kind of come from more traditional trade shows. So, if you've ever been to industry trade shows. And back in the day, I used to do a lot of work in telco, so I would have gone to Caller Congress, all these types of things. So, they're much more – a trade show is about trade and selling, so it has a very different vibe to a developer conference.

I also went to a couple of them in Vegas, and I remember taking a wrong turn and ending up in the American Car Wash Association room, which was bigger than the telco one I was at. I was like, "Okay, wow, okay, this is a huge industry." But swag and sales orientation is much more part of that scene. And do you think that maybe historically, developer conferences have just adopted trade show practices? And maybe we've just been doing it because it was done instead of because we should. [0:06:26]

Daniel Bryant:  [0:06:27] Yeah. I've walked a similar path, Richard. Because I remember some of the early gigs I did, like selling software. The whole purpose of going to an event was to meet customers and sell. Whereas I'll be honest, the KubeCon, from Ambassador Labs' perspective, yes, if folks come up and want to buy our stuff, that's fantastic. But we mainly go to generate awareness and key, we go to listen to folks; what's their problems; where are they struggling. So, it very much is that community focus these days, and KubeCon is a fantastic example of that.

But I think over the course of the years I've been going to conferences, which is about 20 years now – showing my age. But I've definitely seen that switch you mentioned, from we went to a trade show; we were just selling our stuff. And all the conversations were like, "Here's my pitch. Here's what we can do for you," kind of thing. And we listened a bit, obviously, but there was mainly that one way, in terms of, buy our stuff. We'd set up the calls to follow up and things.

And there, to your point, swag was a bit of a perk, so in some ways to remind folks of the things we talked about, and also to get them to come up to the booth and engage with us. We had some really cool stuff. So, I think that's the thing, as in, we rightly or wrongly still think that – even though we're not maybe doing the hardcore selling at the booth anymore, we still want to engage with folks. We still want to learn from them; we want to pick their brains.

So, we need – we think we need – to your point – we think we need a hook, as in, having something there that's something tangible you can take away. And I'll be honest, you're making me think there, because at KubeCon – I don't know. Put a number on it; say 10%, 20% of folks I chatted to at the booth didn't actually want the swag. They were just interested in having a chat.

And that is definitely – arbitrary number I just picked there, not scientific at all. But it was definitely less folks that turned away swag at previous KubeCons, if that makes sense. Pre-pandemic, we used to get lots of folks coming up to the booth, and they were all like, "Give me a T-shirt," and we were all like, "Hey, what are you doing on Kubernetes," And they'd go, "I want a T-shirt," and you're like, "Fair enough, right?" So, in some ways, whatever – we're here to help folks however they want to be helped. So, that was that.

But we definitely had a bunch of folks – maybe there's some other sort of issues around in general, but people were like – some of them were like, "Hey, no, I'm not interested in a T-shirt. Great conversation. Thanks so much, that's all I wanted." And they'd move on. And I thought, huh, that is interesting.

So, it is a definite shift, again, not a massive shift, but I did notice at KubeCon, some folks were there just for the conversation. So, to our point, maybe we don't need the hook anymore. Maybe we need to have our branding front and center, which we do anyway, and make super clear our messaging and our value prop and what we're interested in learning front and center. Maybe we don't need the T-shirt; don't need the squishies. But I think we still have a gut feel that we've not reached that tipping point yet. [0:09:13]

Richard Rodger:  [0:09:14] I think the T-shirts are probably the least objectional, because they are a utility item. We're all such nerds, we wear them. [0:09:22]

Daniel Bryant:  [0:09:22] I know, yes. [0:09:23]

Richard Rodger:  [0:09:23] My wife makes fun of me for literally wearing techie T-shirts in public. [0:09:26]

Daniel Bryant:  [0:09:27] Yeah. I hear you.

Richard Rodger:  [0:09:28] So, I thought, I really like my Reinvent T-shirt from five years ago. [0:09:32]

Daniel Bryant:  [0:09:33] Although I'm always rocking the Kubernetes swag; I'm not going to lie. People do that – "What is that? Is that a band logo, some kind of music?" A logo for technology. [0:09:39]

Richard Rodger:  [0:09:41] Yeah, they look like – if you squint from far away, they look like band T-shirts. [0:09:44]

Daniel Bryant:  [0:09:44] That's it.

Richard Rodger:  [0:09:45] Pretending to be cool. I wonder is it because people take conferences a bit more seriously now. Because before the pandemic, people would have just gone. You – it's fairly easy to get approval to go for a lot of people, so it wasn't valued as much. Whereas now, maybe people are there to actually get stuff done rather than just go to a conference because that's fun. [0:10:13]

Daniel Bryant:  [0:10:14] Yeah. I think it's true. The pandemic forced a lot of us to think about travels. And it forced a lot of companies to think about the value they get from sending folks round when you can jump on Zoom instead. And we're going to see over the next 12-18 months, with the macro-economy as it is, that everyone's going to be very conscious about these kind of costs. And if you send people to a conference, there's the travel, logistics costs. But there's the opportunity cost as well.

So yeah, I do hear you on that, as in the – we definitely – there's probably less people that were walking around – I keep using KubeCon as an example, recency bias because we were at KubeCon. There was probably less people at KubeCon, though it was the same for other events I've been to this year. But the quality of conversations was higher, and I think that jives with what you're saying, in that folks were there. They weren't just like, "Let's grab some swag," or chat to folks to get the lie of the land.

There was a few of those folks, but there was a lot of folks that: I have this particular problem. I've done some research before the event. I've heard of you. I wanted to come and chat to you as a company, as a person, and find out more about what you do. Because people do still value you, even us techies; we're all of us introverts at heart.

We do still value the human interaction. The old cliché in sales, we like to buy from people we like, is still true. You want to rock up to folks and say, "I've heard of Ambassador Labs. I've got this API gateway problem. What do you recommend?" And you have a sensible conversation; you're not pitching straight from the start. You're listening to their problems. So, I think you're on to something.

The folks that were there, some of them – pick a number – had a job to be done. They were like, "I need – I've got this problem, or I need to buy this product." And they were deliberately going round to the vendors' spaces, going to the talks that are relevant to them. And even the folks that perhaps didn't have a job to be done, they were more serious in their conversations in terms of exploring what everyone did and what the current challenges were in the Kubernetes space, as an example. [0:12:12]

Richard Rodger:  [0:12:14] Yes. And something you said there touches on another question which has been coming up a little bit in the dev rel community, which is the purpose of dev rel, is it actually part of the sales engine? Or is it about building community and indirectly supporting sales?

Ultimately, business is business; you have to sell. It is all about sales in the end, if you think it; it has to be. But it's more of a question of emphasis and how you engage the community and where – whether you view the community as the top of a funnel or whether you view it as people. [0:12:59]

Daniel Bryant:  [0:13:01] I think you can do both, in fairness, Richard. That's a great question. You can do both; you can look at the community at the top of the funnel. But I do agree with you, what you're saying. They're people at the end of the day, so you've got a community. One thing I would say – I learned this in my Java days, when I was doing the JCB work for Java community process, and we talked a lot about a community.

And some of the stuff there, it was not a community; it was more like a collection of people that were being talked at, in terms of there were these big enterprise organizations were like, "I've got this community." I'm like, "It's not a community because you don't listen to what they say." You don't prime the pumps for them to connect with each other. And that's something that Ambassador Labs – like Cindy's on my team; does amazing work. She runs the OSS Slacks we've got; she runs a lot of the community programs, our Ambassador community advocates.

And she is all about – the two things she really focuses on is making sure we take the feedback from the community, push it into sales; push it into product, push it into the company. But also, Cindy's about joining folks within the community. It – some of it's altruistic. She likes helping people, seeing them grow, connecting interesting folks. But some of it is like, if we can get help – folks to help each other, we don't need to get involved in helping them on the open-source stuff, which is great. That's the community sort of reinforces itself.

So, there's – you can look at the community as both of these things. But treating it properly as a community is – that's where a lot of folks get tripped up in dev rel, when they don't like community being connected into the funnel and connected into sales. What they're really saying is, you've not got a community. We've just got a collection of people we're talking at. And that's one of the big problems. [0:14:34]

Richard Rodger:  [0:14:36] Yeah, and to get philosophical for a minute, we love using this word community, open-source community or the community around Node.js, which is the one I'd be more familiar with, or the community around various tooling or languages, the Kubernetes community. But what is that? Is it possible to define? What does it actually mean? What are we trying to get at when we use that word community? [0:15:06]

Daniel Bryant:  [0:15:08] Yeah. I often put in ecosystem. But it's – ecosystem is a similar kind of concept, but is also an overloaded term, because ecosystem can mean the technologies, the people, the companies all associated with it. But I hear you, Richard. In terms of community, some folks have latched onto it as – we're even talking now as the next stage of go to market strategies could be community-led growth. We're talking a lot about product led growth as well, but folks saying community led growth. But if you're not careful, it almost becomes a meaningless phrase, because to your point, community means many things to many people.

So, I say ecosystem, particularly from my Kubernetes lens. I look from this – most of my work was in Java, so I've learned a lot from the Java community. I owe them a lot, and amazing mentors from there. But we talked a lot about the ecosystem, because even if you have that benevolent dictator, whether it's Sun Microsystem or Oracle and these kind of folks. As in – and it worked, for the time again. Some of the things I'm saying here are in the context of 20 years ago, so the industry was very different; the world was very different.

But for me, it wasn't a community then; it was an ecosystem. And there are definitely pockets of communities. We – big break in my career was joining the London Java Community, the LJC, and there was fantastic folk like Martijn Verburg, Patricia G, Ben Evans, lots – Simon Maple, lots of interesting people there.

And there was a pocket of genuine community. We'd go for beers; we'd go for meals, coffees, whatever. We'd hang out; we'd connect on a human level, and we happened to like Java. And we – and Oracle for example did support us in certain ways in terms of funding activities, meetups, all these things.

But I looked at that; that's the ecosystem.  And we chose – and I know you've done the same, because I've spoken at some of your events. But we chose to do a community thing and we happened to be around the London area, so we spun it up around London. And I think that's the thing, as in, sometimes when folks use the word community and they're from an organization or a company, it really is about their ecosystem, the folks that are in their orbit. And they use community as a bit of a euphemism almost. [0:17:15]

Richard Rodger:  [0:17:17] Yeah. I think the word ecosystem is better to describe that form of community; that is a good choice. Community is – the issue that I see is, in the dev rel community, because of the overloading of the term – because to some people it evokes the idea of the Amish community, barn raising. Or a village choir or – but you have this idea of mutual aid to have mutual benefit. Whereas an ecosystem, by its nature, even the natural ones, are about entities feeding off each other. [0:18:00]

Daniel Bryant:  [0:18:01] Yeah, in harmony, keeping it – [0:18:02]

Richard Rodger:  [0:18:03] In harmony.

Daniel Bryant:  [0:18:03] A sustainable ecosystem is all about harmony; I'm with you, yeah. [0:18:05]

Richard Rodger:  [0:18:09] Unfortunately, as with most – many tech terms, it gets – it has a meaning and then- [0:18:14]

Daniel Bryant:  [0:18:14] Yeah, totally. [0:18:15]

Richard Rodger:  [0:18:15] -it's extended and overloaded, which is a little unfortunate. Yeah, so the – and that then leads to another thing, which – I was having a look at the Ambassador Labs website, just before we started chatting. And I often do that with guests to see how the – how companies that sell to developers position themselves.

So, there's a really great author – her name is April Dunford – who wrote a book about positioning. And you know the way – there's a lot of business books out there and there are very few that are really cool. This one's really good, because as a techie, I'm not very good at marketing. Can't really understand the difference between the marketing activities and the positioning, right? [0:19:04]

Daniel Bryant:  [0:19:05] Right, interesting. [0:19:06]

Richard Rodger:  [0:19:07] You know, so the classic example she gives is the company she worked for. They had this product that was – the core of it was a database, but it could do all this analytics stuff. But when they tried to sell, it was always, "You're a database, so can you do joins, and how do you compare to PostgreS and Oracle.

And completely the wrong positioning, it was impossible, because you were in the database bucket. And then when they put themselves in a different bucket, it all started coming together. So, your website, Ambassador Labs, I think is really cool, because you just go straight for the throat. You speak directly to developers. You put up- [0:19:49]

Daniel Bryant:  [0:19:49] We do.

Richard Rodger:  [0:19:49] -a simplified YAML on your front page, right? [0:19:51]

Daniel Bryant:  0:19:51] Yeah.

Richard Rodger:  [0:19:53] Whereas some other people would try to say, "No, we need to be a bit more – not professional, but we need to be a bit more enterprising and we need – it needs to be nebulous benefits."  As a developer, it drives me nuts when I go to websites and there's the nebulous benefits. Show me the code. What are you actually- [0:20:11]

Daniel Bryant:  [0:20:11] Yes, exactly, yes, totally. Show me the docs. [0:20:13]

Richard Rodger:  [0:20:14] I love your website. Is that – was that deliberate, or how did that come about? [0:20:16]

Daniel Bryant:  [0:20:17] Yeah, very much so, Richard, very much so. Because – and just to be clear, for more salesy folks who that listening, we do have sales enablement collateral, which is more like the data Sheets, the one pagers. The – here's how you sell into your boss or your manager or whatever. And we do have that if folks want it as well.

But the way I look at – or the way the team, I should say; I'm standing on the shoulders of giants here. The way the team looks at it in Ambassador Libs is, our webpage is like the storefront analogy in the real world. And the folks are most interested in the tech and most interesting us are the developers, are the users of the tech.

So, we deliberately build the website, and if you look, it's super easy to get to link to the docs, super easy to get to a link to get started, get your hands on the tech. We've deliberately engineered the whole experience. And even the stuff that you don't see: the feeding, the top of funnel, the adverts, the other places we've put our content that feeds into the main getambassador.io and website, is all about developers.

Because our main product offerings, our main solutions we – spaces we work in, are developer led. We often talk about it as a bottom-up adoption moment. And again, back from my Java days, I used to be subjected, in some of the companies I worked at, to what I call the golf course deals. I'd rock in Monday, and suddenly, my boss or his boss or her boss – we bought this new thing from – I'll pick a – actually I won't. Yeah, I'll say IBM; everyone loves IBM. [0:21:44]

Richard Rodger:  [0:21:44] Yeah, I know what you mean. [0:21:45]

Daniel Bryant:  [0:21:45] It's an example – you're – we've bought a (inaudible, 0:21:46] from IBM.

Richard Rodger:  [0:21:46] Does it begin with W and have an S in it? [0:21:48]

Daniel Bryant:  [0:21:49] Yeah, exactly, it's the same kind of thing, right?  And they say, "We bought this massive gateway" or "we bought this new message cue; make it happen. And we'd be like, "What? We didn't need this thing." Or "Oh, my days, how do I actually connect all the things together?" The docs were impenetrable or they'd be delivered in PDF format or whatever. So, that was very much a top down go to market motion.

To your point, the websites were all enterprisey; the deal was done on the golf course or somewhere else. And then we as developers have to pick it up and make it work. But open source and CloudNative, all the kind of things you've seen in the last 10 years have really flipped that on its head.

And we are – there's pockets of expertise, of again, ecosystems, communities, emerging that all overlap between dev rel, what we call growth now, which is marketing rebranded to some degree, bit of a different focus. There's sales, and you and I talked off mic about product led growth, PLG, which is very popular.  It's the next evolution of SaaS, you can argue to some degree. SaaS selling was, you could get started; you could do trials. You saw the value of the product and then you buy.

PLG gets rid of that trial friction to some degree. It's product led growth, because all the enablement experiences, learning, comes via the product. We – folks can download our software; they can use it via the cloud. They do not need to chat to a salesperson, because as you and I know as developers or ex-developers, we – if we can not chat to sales, that's great.

Because rightly or wrongly, we think sales are going to be doing the heavy pitch, are going to be always trying to get more money. And I've met some amazing salespeople over my career, and that's not always true. There's some genuinely super helpful and amazing salespeople. I'm lucky enough to work with a bunch at Ambassador Labs. But yes, some folks just want to get started, want to do their thing, without contacting sales, without signing up for that trial, without even giving an email sometimes.

And we try and make it as easy for folks as possible, and when I say folks, I mean developers in this context because they're our target customer. We try to make it easy as possible for folks to get started in the way they want to, whether it's readying the docs, paper prototypes; whether it's getting their hands on the tech; whether it's learning more big picture. So, the website, as you've seen, Richard, is front and center for helping folks to get that job to be done. They want to – we want to make it easy for them to get it started as quickly as they can in the way they want to. [0:24:07]

Richard Rodger:  [0:24:08] Yeah, it's – and it is a great example, because you can navigate almost straight away to the learning mode which you – that you're comfortable with. This product led growth thing is interesting, and we should talk a little bit more about that and try and define it. If you guys have implemented it, I'd be interested to hear how you structure that.

And just to your point about the sales interaction with dev rel and with product led growth, my own experiences –so this would be doing consulting and building systems for people, where we often have to integrate third party providers, API vendors, that type of stuff. We would often get asked to make a choice between a couple of vendors, as – and the criteria are not just price but also how long is it going to take, our technical assessment, this type of stuff. We're not just influencers; we're very much almost majority decision maker, even for compliance. Because there's a trust relationship there; that's what we're there for.

But the other issue is that if there's too much sales, if sales is a bit overbearing and vendors are insisting on demo meetings and this type of stuff, what's particularly annoying – and this is the important thing in sales – is slotting up on their dev rel side of things. Often, if I agree to a demo, it's because I've already made the purchasing decision.

The sale has already been made; I wouldn't waste my time on the demo. I'm going to use it anyway. It's just, you need that part of your gateway, your gatekeeping process. And I can't get at the code and the API docs until I do the demo. Have you ever heard this phrase, selling past the close? [0:26:09]

Daniel Bryant:  [0:26:11] I don't think I have, Richard, no. [0:26:11]

Richard Rodger:  [0:26:12] Yeah, it's one of these sins that they – that – I learnt it from – we brought in some advisors into our last company, and one of the advisors, he was an old hand at sales. And selling past the close is where the sale is made. You don't shut up as a salesperson; you just keep talking about its benefits and its virtues. You keep going on and on because you're not reading the other person's emotional state.

And you can lose the sale by doing that, because you start annoying people. If I buy this product, I'm going to deal with this guy, bit overbearing. Especially developers are introverts. So, I think that's an issue that some people have, is that they – by having these gate data processes, they're selling past the close and almost losing the sale as a result. But in your case, so it is product-led growth, but lead us through the structure of that, how you've designed that. What does that term mean? [0:27:17]

Daniel Bryant:  [0:27:19] I can definitely give you the perspective from the dev rel side, because I've got some amazing colleagues that work in – it's very much a cross-functional thing. The thing with PLG is, it is genuinely, literally, a cross-functional thing. As in – so, everyone has a stake; it's product led growth, but – so clearly, products are involved, and the growth team, but engineering are clearly involved.

We have the growth engineering team that does experiments. We have sales involved, in terms of how they message things. So, PLG, it's a huge company wide effort that a lot of companies – HubSpot are one of the famous ones, and a bunch of other companies as well. Once you get it right, it can be a real game changer.

Exactly to your point, Richard, folks can sign up and get started, and then they on-ramp super quickly; they on-ramp themselves typically onto the products. And then there's room for expansion in the future, maybe again without even talking to sales. So, it's a real virtuous feedback loop, so to speak, if you get PLG done right.

But the biggest thing that – we've really leaned into it over the last year, I'd say, particularly with the telepresence product that we have, which is for fast feedback developer loops if you're using Kubernetes. We've reused some of those – there's a SaaS component. We've got Ambassador Cloud which is – that's the way the product growth is mainly driven, through our cloud product. But you install a telepresence product locally to your machine and connect up to your ID and debugger and things.

But we've really leaned into the PLG focus for the last year with that. And the main thing, the biggest thing that is a shift for me is – I was like, "How is this different to what we've been doing before. And a lot of the stuff before – we've always been doing, to be honest, some form of PLG, similar to – a lot of us who are in dev rel maybe not have the dev rel title, but we've been doing dev rel-like things all our career. I think that's a very common thing when I chat to dev rel folks. I didn't have that title, but I was going to community meetups. I was selling the – my ideas, my – sharing my ideas out with folks.

And I think it's the same with PLG. A lot of folks have been doing it already, but the real counter-example with PLG is a top-down sales motion, sales led growth. Which is exactly what you and I talked about a minute ago, on the golf course. That was the way it was done. We'd have folks, back in the day – not in Ambassador Labs, in other companies I worked with.

We'd have folks cold calling CEOs, cold calling COOs, saying, "We've got this awesome product. Come meet our sales team. We'll take you out for lunch; we'll go to the golf course, whatever works for you. And then we'd very much sell the big value prop. It was a long sales lead time, six months or whatever, big, high value deals.

But it was very much a top-down motion; we have to win the approval of the COO, the C-level, the VPs, that kind of thing. Whereas product led growth is the exact opposite of that; it's a bottom-up motion. You're targeting your users typically, and often the users are the economic buyers too, or they have a lot of influence on the economic buyers.

So, the –  a trend we've seen in the industry. It's all the purchasing power has moved down – to use a phrase – moved down through the hierarchy. Sure, the COO, depending on the size of org, may sign off some purchases, but then the middle management also are quite empowered.

And now we bump into a lot of folks in Ambassador Labs, that even the developers working actually working on the code, they're empowered up to a certain value to buy tools that make their lives easier. So, they are the users and the economic buyers, but even if they're not the economic buyers, they're still the users, and they are the champions; they are the influencers within the org.

We – PLG, very much focused on making it frictionless. And we use that word a lot in Ambassador Labs, making it as frictionless as possible for a developer to get experience of the product, and then the product does the selling, hence the product led growth. The product leads to the growth of the org, growth of the revenue, growth of all the good things we want to do in terms of open source and feedback as well.

As we said with the website, everything is targeted towards getting developers into the product and having a best experience as quickly as possible, through whatever means they want, whether it's videos, whether it's blog posts, how-to guides. We've done some sandbox activities where they can get hands on, like in a web browser, by using a Kubernetes cluster that we spin up in the back end.

And once they like the product – they can chat to sales at any time. There's always that break-glass moment where they go, "Hey, I've got a slightly weird use case. Can I have a chat to a sales engineer or something?" That's totally cool, but they can also sign up with a credit card in our website and never talk to sales, and they're off and running and they can get the full value of the product.

And then – and there's the flywheel there, so to speak, is if the product delivers on the promise and it's all frictionless and folks are getting more value, you often see – because it's – the pricing model is typically based around consumption, how many things you're using or how many developers are using the product or how many shares you're making, that kind of thing. Then over time, you typically find happy customers spend more money, because the product again drives that internal growth of revenue.

So, product led growth, it's a big topic. Hopefully that's given yourself and your listeners a bit of an overview.  But even the dev rel sort of – you can hopefully see the hooks there of how dev rel would play into that in terms of driving all the frictionless experiences. And we do a lot of content marketing, of course; we write a lot of content. We create a lot of tutorials; we create a lot of interactive experience. But we're also – this is an interesting one – we're also the voice of the customer here, because we are – my team – we're all developers. We're in marketing- [0:32:47]

Richard Rodger:  [0:32:45] Yeah, you have an advocacy role, right? [0:32:48]

Daniel Bryant:  [0:32:48] That's it, yeah. And I don't make it mandatory, because I've had some folks on my team in the past that have come out of college and have done it – or university and done a bit of programming or whatever. And they can do fantastic work in the dev rel space. But at the moment, the makeup of the team is pretty much everyone has done some development in the past, so they can empathize.

There's a sniff test, if we're doing a new experiment. It's product led growth; you do a lot of experiments. You have a lot of hypotheses. If we tweak this, if we make this better for the user, will it drive more growth in the product? But we can give that a sniff test. We can go, "Hey, I see what you're trying to do there, but actually, that's going to make onboarding more tricky." Or "Actually, I don't think the average developer's going to even care about that feature."

We can offer that sort of sniff test, and we can also say, "That's really cool, and here's how I'd measure the impact of that thing," because that's not always that obvious to non-developers on the team as well. So, that's where dev rel provides a lot of value, because we're pseudo customers, to some degree, of the product. [0:33:46]

Richard Rodger:  [0:33:48] Yeah, that – so, that touches on the follow-up question I had for you is – so you've given an overview of the concept of product led growth and the benefits and how it fits together. It all makes sense. But the fine details operationally, you've touched on those a little bit now, where you were giving feedback on specific features. But do you go right down into this whole thing of having user segmentation and cohorts and tracking various metrics and getting extremely data analytical about it? Or is it a little bit softer and you're using your developer intuition? How do you operationalize the PLG? [0:34:35]

Daniel Bryant:  [0:34:35] Great question, Richard, love it. And funny, depending on when this gets published and when listeners are looking back. I'm doing a talk in Prague at DevRelCon next week, which – there's some of the slides will exactly hint at this. And I would say it's a twofold answer in that we are very data driven, but that is run by a different team I work with very closely day in, day out, at Ambassador Labs.

Run by Kelsey, and I can – Kelsey Evans, I can ping you a link. She did a fantastic interview with a bunch of other PLG folks in the dev rel – in the dev marketing space, sorry, for The New Stack. Myself and Adam LaGreca, buddy of mine, we wrote up this interview that Kelsey did. So, Kelsey sets – she's the leader of the growth – digital growth, marketing; we call it different names now: the overall tone for goals, experiments to be driven. And on her team are a set of amazing data folks: data scientists, storytellers, the whole thing.

So, that part of the org, very focused on understanding where folks come from in terms of where they – the top of funnel, where they land in the product, what do they do, that kind of thing. Data is – I often say it's a PLG superpower. And more importantly, interpreting the data. Again, Sara and Adash on Kelsey's team, they are amazing at looking at data, telling the story, and more importantly, helping the rest of us understand that story as well.

So, we lean a lot into data, but the joke I'm half making in my DevRelCon talk last week, is the data science team – though it's not true, because they're amazing people. But I quip with them sometimes that they don't pay attention to the qualitative aspects. They're all about the quantitative; X number of users did this thing X times.

And I'm like – and they tell a story around it, but I'm like, "Actually, I think from a qualitative point of view, if we go and interview some folks in the community or the ecosystem or we interview a customer, we'll get a better story." Because what you see in the data – the data doesn't lie, but we might interpret the wrong things from it. Does that make sense?> And that's where dev rel is really powerful. We are the voice of the user, the voice of the customer.

And because we've got that sort of background, I can often – and to be fair, there's totally things that come out of the data that I would have never seen. And I'm like, "Wow, that's awesome. That's super interesting insight. We can make – tweak our products and prove our docs based on that observation." But likewise, there's some things I'll say to the data science team. I'm like, "Hey, what about – what do you think about this story" – from using my dev rel brain – "mapping onto the data you've got there."

And they'll be like, "Oh, interesting. I didn't see that perspective." That kind of – let's chat to some customers; let's go and see what they're doing with the products. So, I think both things and I think – at least in our – the way we've split it, not – so the way we've divided the work in the org. And again, to be clear, it's super cross-functional; we meet as a team twice a week and we're on Slack all the time.

So, it's really one – we're 100 people in the whole org of Ambassador Labs, but particularly this growth, this PLG engine and the marketing side of it, sales, growth and dev rel, we're constantly collaborating and sharing ideas on Slack on a daily, hourly basis. So, we're telling each other the perspectives that we've got, sharing those perspectives and coming up with an ultimate story, an ultimate plan of what we're going to do next, based on those stories. [0:37:58]

Richard Rodger:  [0:37:59] That sounds very healthy compared to some organizations that I've seen. Did that happen organically or was it designed? Was it a deliberate design? Because a lot of organizations have this thing where dev rel has been tacked onto the side. [0:38:12]

Daniel Bryant:  [0:38:13] Agreed.

Richard Rodger:  [0:38:14] It's – just go do marketing, whatever. [0:38:17]

Daniel Bryant:  [0:38:18] Yes, I can see that. [0:38:19]

Richard Rodger:  [0:38:19] We see both sides of the market, right? [0:38:19[

Daniel Bryant:  [0:38:20] Yeah. That's a really good point, Richard. I've been lucky enough; I've been with Ambassador Labs since it was five people. So, I've – and then we've got amazing leadership in Richard Li and Bjorn Freeman-Benson. And they've empowered us, particularly the early folk, to think about the business end to end.

To the point I made earlier, my official title, when I joined Ambassador Labs, was product architect. So, I was doing a lot of product stuff; I was chatting to customers, working with Richard, the CEO, very closely, in terms of what are we actually going to build here. And you'd even call it product market management now, PMM now. It's this sort of role where you're mapping the product and the marketing; PMM roles are very hot at the moment.

And I worked very closely and learned a lot from Richard, that as we evolved the role and the company was evolving around us, I'd always be going, "Hey, Richard, have you thought about this?" with my developer hat on. And he'd be doing some product stuff and he'd go, "No, let's feed it in." So, we were always doing dev rel-like things, even before – I think it was two years ago. Richard was like, "Hey, you know what? We're big enough now? We've got our series" – I think it was series A at the time."

And he was like, "We're big enough now that we need a dev rel department, and I want you to lead it." And I was like, "Awesome. Sounds great." "And so – because you've been pretty much doing some of that anyway, but let's make it more of a focus and let's bring a team in." So, I've hired some amazing people over the years to – I've got 4-5 folks on my team now, that support all the activities under the dev rel community umbrella.

It was a deliberate design with myself, Richard and several other folks, but also an evolution of – we've always been a developer-focused company. Richard even comes back – he's had amazing experience in sales and product and a bunch of other things, but he was a developer. He went to MIT over in Boston, in the States, and he got it from day one. So, that's one of the reasons I joined the company; I saw that he understood what developers were about.

So, I do – to your point, I've totally seen and I've even worked in a few companies where dev rel is, to be honest, pure content marketing. It's like, "Hey, you know enough about the topic. Write me some blogs." And that works for some folks; I'm not trying to be too judgmental. But for the kind of company we're at, and where I enjoy and where I want to lead my team and offer opportunities, is so much more than just content marketing. Is it; it's being (inaudible, 0:40:35) to some degree.

Richard Rodger:  [0:40:35] Yeah, it's so much more valued, so much more that you can do for the business than just- [0:40:39]

Daniel Bryant:  [0:40:39] 100%.

Richard Rodger:  [0:40:40] -write blog posts. [0:40:41]

Daniel Bryant:  [0:40:41] Yeah, 100%. That worked probably 10 years ago. HubSpot aced that, as in, they're the traditional case study of content marketing. They did amazing work. But these days, the algorithms on search engines are smarter. The people like us, we're all a bit smarter about how we choose to read things. And there's so much out there that that doesn't work. So, these days, you've got to be thinking end to – we have a big focus on end-to-end thinking and focus on the value. Don't chase the money; chase the value. What value are we giving to the customers? That's – then the money usually follows from that. [0:41:09]

Richard Rodger:  [0:41:10] Wonderful stuff. We shall conclude it there. That is a high note, because that's a really important little insight. Your organize is – I would see it as a model organization for dev rel having a fundamental impact in an organization. It does sound like it developed organically, but the right intentions were there. [0:41:37]

Daniel Bryant:  [0:41:38] That's it, Richard. That's perfectly said, yes, great intentions. [0:41:40]

Richard Rodger:  [0:41:40] And it – clearly, it works. [0:41:42]

Daniel Bryant:  [0:41:43] Totally, yes. [0:41:44]

Richard Rodger:  [0:41:46] Yes, that's – I think there's a bit of fundamental learning there, which would help a lot of people. Daniel, thank you so much; this has been really great. [0:41:55]

Daniel Bryant:  [0:41:55] Always a pleasure, Richard. Always enjoy chatting and hopefully, we'll get to catch up in person soon. [0:41:59]

Richard Rodger:  [0:41:59] Absolutely. Take care. [0:42:00]

Daniel Bryant:  [0:42:01] Fantastic. Cheers, Richard. [0:42:01]

Endnote

Richard Rodger:  [0:42:02] You can find the transcript of this podcast and any links mentioned on our podcast page at Voxgig.com/podcast. Subscribe for weekly editions, where we talk to the people who make the developer community work. For even more, read our newsletter. You can subscribe at Voxgig.com/newsletter, or follow our Twitter @voxgig. Thanks for listening. Catch you next time. [0:42:30]

‍