Can product-led growth and developer experience co-exist

Speaker 1: DeepRel gone deep dives. Yar. Hello.

Speaker 2: Hey, you.

Speaker 1: Hey, everyone. So I'll give you some context. I'm really interested, in this roundtable. Can developer experience and product led growth exist? And I'll do that by sort of giving an introduction of myself for everyone who's watching also.

Speaker 1: So I do developer relations at a company called Stripey. We're an open source headless CMS. And like most people in developer relations and at this stage, my company is at. So a couple of things that, we see quite often, developer experience and product led growth. And there's always this question, can they two work together?

Speaker 1: Because you don't necessarily see a lot of people in developer relations, or at least my side of developer relations on the advocacy side, sort of, like, pioneering this product led movement. And so today, I reached out to a bunch of people, some amazing people on the topic. I'll let them introduce themselves in the order that I see them. Sam, do you wanna go first?

Speaker 3: Sure. I'm Sam Richard. I work at OpenView Partners, on the growth team. OpenView Partners actually coined the term product led growth back in 2016, after we made our investment in Calendly. But I work mainly on our growth team helping our developer focused, portfolio companies and prospects with go to market.

Speaker 3: So things like sales, things like marketing, and especially developer relations.

Speaker 1: Nice. That's super cool to have the coin as of the term. I'm sure I'll get a lot of really interesting insight about how that came to be. And up next on my screen is Kurt.

Speaker 2: Hey, everyone. I am Kurt Kempel, founder and principal adviser at Forthright, where I help companies, teams, and individuals create better developer experiences. I do that through consulting and training. And, yeah, happy to be here.

Speaker 1: Thank you so much, Kurt. And last but not least, Mario.

Speaker 4: Hey. Hey, folks. Hey, everybody. Thanks for having me here. I'm I'm Mario.

Speaker 4: I work at software.io, and I'm heading growth up there. And I've been I've been a developer relations professional for for a long time, helping develop the ecosystem the ecosystem of a a big community. And and and for the past maybe five, six years, I've been very much focused on product live growth, also advice for some startups that are going through the journey.

Speaker 1: Nice. Thank you very much. And for the people watching who might not have context, I feel like now that we have Sam here, let's let's sort of have a definition of what product that growth might be for a a developer tools company because I'm assuming a lot of people watching this are in the developer context. What does that look like, Sam?

Speaker 3: Yeah. So I, you know, I think it's I think it's interesting when folks try and define PLG specifically for developer led companies. PLG is really where the product is doing a lot of the heavy heavy lifting for you in terms of providing wonderful experience, bringing in folks to discover your product and to guide them through. Products led growth takes people out of the the process and makes it sort of, like, less people heavy and more focused on providing value and making sure that those people who are involved in the process are there at the right times. I like to think of developers as people too, not just gray shadowy figures that are behind a keyboard.

Speaker 3: So I like to think of product led products as also selling to developers. And I actually I started studying developer focused tooling because I feel like it's the cutting edge of PLG because it can be really challenging to get developers on the phone or interacting with folks because they are so incredibly busy.

Speaker 1: Awesome. I feel like that's that is that is very true. But in something that you said, it it left me thinking. You know? Having the product do the heavy lifting when it comes to growth.

Speaker 1: Traditionally, this has sort of been where developer advocates, developer experience sort of sit. They are the people who go and do that. So I can understand why there's some sort of fear for what this might bring. And I'll have this one be open. I would love to know from from everyone, like, Why why do you not see a lot of dev tools companies sort of, like, approaching product led growth, at least at the moment?

Speaker 2: I could dive in a little bit there. I actually have seen quite a few companies that are doing product led growth and their developer experience or relations teams are integrated pretty tightly into that system, right, because it should be company wide. If it's what you're leading growth with, it spans all verticals, right? So think GitHub is a pretty good example. I've known the folks over there for a long time.

Speaker 2: They're doing amazing work, and they are definitely a product focused advocacy team. But you're right, I think it's not as common, but I also feel like marketing led growth and now we're seeing the expansion of community led growth is another avenue. There's just multiple ways to approach it, and I guess it depends on who you have, the experience, the resources, and, you know, basically where you start and where you can go.

Speaker 1: That's so interesting that you mentioned that, you know, what you have. Why would someone want to take productive growth? I I think a lot of people in the advocacy side, you know, have been using and have followed community led growth. And in mentioning all these terms, I feel like we leave we don't leave a lot of room for them to work together. Can they?

Speaker 1: Do they? Is that something that happens? What are you all seeing?

Speaker 3: I well, so some of the best DevRel folks that I see and dev experience folks that I see I think people think of product led companies as having this incredibly data driven strategy where they see what users are doing in the product. They take that quantitative data back, and they build a product around it. But I feel like some of the best developer relations folks and dev experience folks can be that person too. They're going out. They're talking to the community.

Speaker 3: They can act as a filter and say, hey. Wouldn't it be great if our products did this? Or my users are having a ton of pain, and this would solve for that. Or how can we solve for that as a team? And I I think some of the best developer relations folks can think of solutions that suit a lot of different needs that create a really simple and straightforward product so that they, in turn, technology themselves out of a job and can do bigger and better things with that community.

Speaker 4: Yeah. I would I would add that there there are multiple layers of of a strategy for product led growth. There's the acquisition side of things. There's the retention activation and retention side of things and also the the the monetization side of things. If the only area where I can see, you know, a a a possibility for the job to become off obsolete would be would be acquisition.

Speaker 4: Like, take software, for example. We we don't have a marketing team. We don't have a sales team. We have 55,000 users, fifteen months of product, all through word-of-mouth. So our users were the acquisition team.

Speaker 4: There are no we don't there's no community person or whatever. So in in as opposed to my previous previous company where we had an army of developer relations folks for a long time focused in acquisition, but then it was really hard to measure. And you folks in developer relations will will will know. It's really hard to measure. You go to an event, and you have to justify spending 50 k on a sponsorship and, you know, how many sign ups, how many is and it you are not gonna be able for majority for the, you know, for the majority of it to really attribute that investment to some sort of return.

Speaker 4: So for acquisition, I think it's it's not the function that it becomes obsolete. It's the approach, the method that became obsolete. So the shift to an experience that is remarkable, a shift to an experience that is remarkable in a way that people talk about it, that is solving real problems, a shift to value, like Sam was mentioning earlier, is is gonna bring the the return. And in in that sense, for bigger teams, the developer relations team is a tremendously valuable source of data. And, yeah, I'll I'll pause because I don't wanna ramble too much, but but that that was that was my two cents on the topic.

Speaker 2: If we have a sec, I'd like to follow-up on that because I think it is a very important topic, right, which is, like, can they work together? And I think without a doubt that they can, absolutely. Developer experience should be able to work with, any led growth strategy. Because the real value of developer experience is the context that we accrue by being deeply involved both in company and community. Right?

Speaker 2: We are able to find alignment ideally or misalignment sometimes as well between company goals and community needs. So we can always be that voice of of input coming from the outside. So even in a product led growth with, yes, we are looking at a lot of data in internal. Like Sam said, we do have these people still representing external factors, new things that we might not be aware of. You can't only have your viewpoint be what exists within the platform already and try to move forward off of that.

Speaker 2: That leaves no room for experimentation and and create, you know, creativity to to branch out into new things. Developer experience should be enhancing any of these products. Like, the feedback we can give to product teams is invaluable. Most times, they're very focused on the product coverage, right, and how that looks as a whole. We have the opportunity to focus on the developer journey, which is what are the touch points between the products and how is that experience.

Speaker 2: And so, you know, we can do the same thing. But I do think that DevRel teams have a tendency to try to push too hard with, like, a community led growth strategy independent of a product led growth strategy. And I think it's important to remember that we should be as any department really focusing our energy on things that are going to contribute to like the top level strategies of the company. And it doesn't mean we can't do community. It's a large part of what we do.

Speaker 2: You can't engage, you can't know the community and understand things without having a strategy for community, but that's not the same thing as community led growth. Like when you're saying we're a community led growth company, that means that is your main focus. Like marketing is also focused on this. Product understands this and knows that we're gonna use community to try to foster growth, right? Like all of the verticals are bought into this and in alignment and working towards it.

Speaker 2: So honestly, we're most times using community within a ML or a PLG. Right? Like it's either product led growth or marketing led growth and we're using community as a tool within that. Now there is the emergence of community led growth where people are putting that first and that is what they focus on is building community day one and they'll try to grow through that. But all that to say is developer experience serves all of those.

Speaker 1: Sam, I see you Noreen, do you wanna add to that?

Speaker 3: Yeah. I I really like community led growth as a model, especially when your product may not necessarily be able to give everyone a little bit of value. Like, I think a really strong product led product gives everyone a little bit of value for free. Right? Like, Snyk, you know, as a developer focused product that gives everyone a little bit of value for free.

Speaker 3: But for a lot of folks, you know, if you have a really complicated product, you that's gonna be really tough to ask for the product team or for the engineering team. So how do you build community around it? Well, you've got folks who understand it and who are really passionate about this, like, niche area. So for me, community led growth is is part of product led growth in that it really helps you experiment and understand what is the value that we can add to these folks. And sometimes the value is being part of that community.

Speaker 3: It's having a place to go. It's having folks to talk to. So in a way, you are you are developing a product in your community.

Speaker 1: Absolute the community is the, unique value proposition that enables the growth.

Speaker 4: Yeah.

Speaker 1: That's that's super interesting. Right? So I think we've established that a lot of these sort of, like, growth strategies can coexist and work together, and and the community is the core of a lot of these also. For people watching who would want to know, how do I get started with embracing a product led strategy in my existing developer relations, developer experience function? How do they get up and running?

Speaker 4: That's a that's a very good one. I'll I'll I'll start by saying that one of my favorite sentences for for teams that are just starting, depending on also the size of the team, but assuming that it's a fairly it's an established an an established company, you know, let's say a team of fifty, sixty people. I I don't know. It it it's sort of along those lines. This will be a marathon, not a sprint.

Speaker 4: You will if you if you primarily rely on sales on on sales and Google and advertising and marketing dollars to grow, this will be a marathon, not a sprint. And so that that will be my my my number one thing. The the second the second thing that I would add to this is imagining a world where the product sells itself because, again, of how remarkable, how easy to use, how easy it is to get to value is a tremendous challenge for these developer experience for for the entire product team. I would go as far as say that community is the product. At least in my in my conception, there is no such thing of community led growth to in my opinion.

Speaker 4: There is a a more broader thing that the the community is the product. It's not just siloed somewhere. It is part of the journey. And yeah. So I will I will I will let others chime in as well, but these are my two, I guess, top points.

Speaker 3: I mean, I would say, you know, this is a a kind of garbage answer, but I would say, you know, the best way is to really focus on your user and that experience that they really want. I, you know, I think the the majority of us are focused on developers as users. What experience do they want to try out your software or to to to start using it? Do they wanna be talked to you by sales? My gut says no.

Speaker 3: But so how can we sort of make mimic that experience that they love, and that's gonna give them a really pleasant interaction No matter if they're a customer or not, just just thinking about them as a user and what they would want to to do in terms of trying and buying software.

Speaker 2: Yeah. I'm gonna add a little input, like, more tactically for DevRel and DX teams to how to really help enhance product led growth strategies. We do a lot, we have a lot of coverage in the things that we can do to help out. And we tend to really not focus as much as we could. And what I mean by that is, you know, we create a lot of content.

Speaker 2: Some of it might be very much like more marketing awareness driven and viral, but we really want to help product led growth, education, and things that are gonna lead people into the product features, that type of content, things that have calls to action are gonna have a lot of benefit. Focusing more of your energy internal than external and that means engaging with the community, understanding what they're going through, doing the workflows. If you understand the persona and the developer journeys, you can go through those journeys, friction log them, provide amazing feedback back to product teams so they can constantly improve the product. So those are some of the things that you can do in practice to really help product led growth strategies.

Speaker 1: Nice. And out of curiosity, just like I think when when we think about developer experience, when we think about product led growth, at least from from from my sort of, like, context, when I think developer experience, I'm thinking of developer experience engineers. I'm thinking, you know, develop advocates, evangelist, community managers. What does that look like on the PLG side? And follow-up question, is there even a need to sort of staff or have extra staff to sort of, like, see through this PLG strategy?

Speaker 1: Should I be thinking about headcount?

Speaker 3: Can you sort of clarify? Do you mean headcount in terms of developer experience engineers, or do you mean more broadly?

Speaker 2: More broadly. Like, a team structure? Like, what would that look like for if you wanna help product led growth? Is that what you're saying?

Speaker 1: Yep. Just that. I see.

Speaker 2: Yeah. I mean, all companies are different. You can't really shoehorn a particular structure, but you'll definitely want developer advocates who are integrated with the community and providing really detailed feedback. Depending on what you're building and offering, developer experience engineers could be very beneficial if you have a very integration heavy product, right? Like you can have a lot of third party integrations, DX engineers are great then.

Speaker 2: Probably not bad to have one or two around anyway, honestly, just to help the developer advocates with building out things as needed. Right? But, yeah, I definitely think there's generally a need to have a good mix of folks around on the team.

Speaker 3: Yeah. I don't necessarily think there's a silver bullet in terms of team structure. We're all sort of t shaped as as individuals. So, you know, if you have a developer experience lead that you love or DevRel folks that you love or a marketer that you love, you have to build for their weaknesses. So think about, you know, is this person really strong in analytics?

Speaker 3: Are they gonna really help us understand what's going on with our community and further down the line when people actually start to leverage the product? Or are they gonna need someone who's really helpful there? And, like, start building out the team that way by understanding the requirements of how you build a product led product or how you build a product led motion.

Speaker 1: Mario, anything to add?

Speaker 4: Yeah. I would I would the way I the way I see it, and I've worked with it's interesting because I worked with with with in a company where the product growth team was just starting, and we we we created this sort of product growth team where and and all the developer evangelists all all the developer relations team was made part of this thing. With it it was like, we wanna grow the product bottoms up, and these folks are out there, and and we we we want we respect their their intuition and and their knowledge and so on. So they they were we were all part of something, and we were working together. What I what I can say is that on the developer the when I worked in developer relations, what what this would force me to be or to develop was empathy and and and intuition that I would develop by talking to people.

Speaker 4: I don't know if that's true for everybody in developer relations in developer relations, but at least that's why I'm speaking for my for myself because I don't wanna perhaps offend anyone. But empathy and intuition, being a t shaped you know, I I also consider myself pretty reasonable looking at data, but I was being, but I was developing these two things. On the other hand, a a a mature product growth team is looking at data and impact, looking at data to figure out what to do next and impact to to measure what what is done. The the the four things together are pretty powerful. Empathy and intuition and the facts and the the and and the data and and then the impact that you get are pretty powerful.

Speaker 4: So I think the both teams when merged, at least in my past experience at at OutSystems, was was pretty was was pretty powerful. And if you don't know OutSystems, it is a product for developers that is really hard for developers to adopt because there's some resistance there. So it's it's really critical in this situation to have people that that understand the objections, the concerns, what what what makes people tick. How can we improve product to be better at objection a or b? So so I see I see a cross functional team as as valuable as valuable here for for, you know, for for for this setup that I just mentioned.

Speaker 1: Nice. Thanks for sharing. And I I'm getting something from from all your answers. You know? There's aspects of product led growth that require sort of, like, a different skill set.

Speaker 1: I think we've touched on sort of, like, the definition, and Mario talked about, you know, acquisition retention. I'd love to sort of get into what the core sort of characteristics of a a product like are and and and how those sort of manifest themselves in in execution. Sam, do you wanna kick this off?

Speaker 3: Yeah. So, I mean, I I I do trainings for this quite a bit for our associates here at OpenView. One of the first things I have folks look for is that there is a free product that you could receive some value from. I've seen so many websites that will have, you know, try now where it's just a a form that goes to sales, and they're then they're seeing a demo from sales. So, you know, I I haven't go through that.

Speaker 3: Yeah. Kind of a bummer. But, you know so the product needs to provide some value for free at any point in time. And you build on that to say, okay. How does the team structure then?

Speaker 3: You know, typically, if you have a free product, there's a ton of analytics required to to monitor usage and users. You also from the moving from the front down, you you also have to, figure out acquisition in a in a more affordable way because a lot of folks are coming into your product. They're not necessarily signing up for a demo. The rates of visitor to web conversion are incredibly low. The rates of user to converted paying customer are incredibly low, around 5%.

Speaker 3: So you also have to look for viral motions, inviting users to collaborate, having an excellent community, having a ton of GitHub stars. Those types of things are really the signals that we look for. And then, you know, you have to think, okay. Moving backwards, how do you build those things? How do you how do you really develop that wonderful experience so that people are able to discover us for free, get started relatively quickly, and then in turn fall in love with the value that's provided by the product?

Speaker 3: So from there, we like to see a lot of engineers playing marketer. Zapier is one of my favorite examples and that they have this incredible discoverability because they have these automated landing pages of the the tools that you can connect to one another. Snyk is another great example on the developer focus space. They have their open source tooling that allows you to understand how risky certain open source tools are in terms of building them into your enterprise stack. And, also, I mean, GitHub is also another really great example, especially in their early days.

Speaker 3: They had a really strong community. They were a little fast and loose with privacy, but they would reach out to folks and have some in person events in larger cities of people who are really passionate about Git and who are really large contributors to open source models. So, again, I like to see that that really free focused acquisition model as well as that really value driven getting started and activating model before thinking about any sort of commercialization on the product led front.

Speaker 2: From a to felt oh, sorry. Go ahead.

Speaker 1: Yeah. No. Go ahead. I was just I was just saying that's that's a lot of really great insight. Have some follow-up questions, but go ahead, Greg.

Speaker 2: I was gonna say from a developer experience side as well, like, a really great place where we can help out in that endeavor is in onboarding. Right? Like, going through and shoring up, making sure we're removing as much friction as we can from onboarding to these different products. That was a huge part of work I did previously at Apollo. We saw amazing results from that.

Speaker 2: And that is just something that I also look for when companies say they're product led and they're wanting to start out with DX. I ask them, what are you focused on? If they're saying things like awareness and community and not like documentation, core education, onboarding and then product usability, Like, that's where those are the things I wanna hear when companies say their product load.

Speaker 3: Yeah. It's interesting how a few folks actually pay attention to their docs, or they think of them as just guides for the product. But so many developers discover your tool through your docs. If you're not also talking to them about why they should take these actions or what value they're going to receive if they do, then you're probably, you're losing out on a lot of folks there too.

Speaker 2: Absolutely.

Speaker 4: Through how

Speaker 1: That was muted. I I love where this conversation is going, the direction it's going. What what other ways are you seeing people add value for free? What notes can people watching take for how to sort of, like, optimize for a great developer experience that then ties into a product led motion. So for us

Speaker 2: I mean, this is pretty big. I don't I don't wanna monopolize, like, in the commercial open source space. Right? So taking something that is inherently time consuming or more difficult to do and adding a layer of abstraction on top of it. You're still essentially responsible for managing the outcome of that result, but you've been given a tool to make your life, your developer life, a bit easier in accomplishing that goal.

Speaker 2: It also opens you up very nice later to gather information data and figure out what you might offer as a managed solution.

Speaker 3: I think that there I think one of the things that I see is really cutting edge in the developer focused space too is how can we provide this value, especially if our tool requires a lot of onboarding or a lot of tooling in order to get started. Gray noise is really up and coming in the security space, and they actually have this entire Internet scanner that anyone can look at to understand, like, what are the broader risks in the Internet today. And I I think that there's this interesting rise in what I consider to be sidecar products or leveraging the superpowers that come from your product in and of itself to help the community more broadly. So, you know, Orbit, who's sponsoring this, you know, I think that they could have some really interesting approaches and thinking about different types of communities that people belong to and sort of publishing their data to help us understand our world more broadly, our little software world. And I think that, you know, if you can figure out how to leverage your superpower, that would be how you would be strongest.

Speaker 3: I see a lot of folks try and copy off of others, and I those tend to to be failures, because you have your own superpowers. You just have to figure them out first.

Speaker 4: Yeah. With just a couple of may maybe a maybe a slightly different way of of putting this. I the the the way I believe we should optimize and depending it it doesn't matter if your product is simple or complex, is for value before purchase. Some some products may have a higher setup time. Some some products may have, you know, shorter shorter setup time.

Speaker 4: The shorter, the better. In some cases, you'll see that products that have big setup time require a lot of lots of effort. They will offer some tools for free to do that do that to capture people's attention. That's not that's, you know, although it's an interesting marketing tactic, it it's not really value, in the sense of recurring value. So I've in order in order and I I I go back to Software Story.

Speaker 4: It happened before I got here. They accidentally launched in product hunt to see if users would use it. And then they had hundreds of thousands of users, maybe 30,000 users or whatever even before series a, and and they didn't sort of, you know, they weren't counting on it. Right? It was it was growing.

Speaker 4: So they had to build a team and a company on top of a product that was incomplete, and it's getting better by the by the minute. But the point was after talking to you know, I interview hundreds of users every quarter, and it's value before purchase. And it's value before it was like that in my previous big engagement as well. So it's it's getting to value getting to value before purchase. Then if you get if if if the product is good enough, if it's solving a relevant enough pain, people will continue to get that value.

Speaker 4: And so that's where engagement comes in. Right? And then you're gonna lose some users, so you have to put in some effort resurrecting those users that you lost. I advocate not too much. Because I I'd rather focus on the new ones that are coming in than than trying to work on resurrection.

Speaker 4: That's conversation for another topic. But all of these three things, all of these three inputs are the output for retention. When you have a good base of relevant users retained, they will eventually buy. Because you're giving them value, and they will eventually buy. We I was talking to a customer the other day.

Speaker 4: They were buying just to support the company. You know? How cool is that? I I just decided to buy. I don't even need the premium features, but I'm buying because I wanna support your product.

Speaker 4: And that's and that's you know, you can consider this community or marketing or whatever. But the point the point here is recurring value before before purchase will will drive good things for your for your business.

Speaker 1: It's interesting that you mentioned that, Mario, because I in the in the previous question, you talked about how OutSystems was this really difficult thing to get, you know, developers onto it, how did you solve the value addition problem and communicating that? And, you know, just like talking about what you just mentioned, what approach would you take for that, or what approach did you take rather?

Speaker 4: Well, there I I know there are people here for about systems in the in the they're they're chatting, so I know that they they would they would have a different perspective. But we we you know, by by I guess, at the time, by being humble, understanding understanding what we could improve, but also appealing to reason in in some scenarios. Is your objection something that is factual, or is just, like, the gut type of thing? Oh, this is a low code. In my case, now it's even more radical because it's absolutely no code, but at AltSystems, it was low code.

Speaker 4: And this would create sort of this gut reaction in some developers that they would lose control, they would lose they would lose flexibility and whatnot. And it's a you know, we work we we try to either, one, improve the product or show them that the objection was just emotional and not and not rational by demoing the actual thing. So it it's it's a it's a balance, and, yeah, it's it's hard. And I know I'm looking at the other panelists smiling, so maybe they have different approaches. But that's why we need people talking to developers and the empathy thing that I mentioned there.

Speaker 3: Right. Yeah.

Speaker 4: Because Friday is the formal world they look this Friday.

Speaker 2: I can't remember. We definitely can't have enough empathy, especially developer relations and developer experience. I feel like it's, like, pretty much the foundation of being successful in that endeavor. You know? Absolutely with you there.

Speaker 2: Yeah. No. Smiling and nodding more just I get it. I agree.

Speaker 3: Do you ever feel like there's a point in which you can have too much empathy and sort of, like I've seen, like, a lot of folks, like, overbuild their product or, like, listen to what people want in terms of features rather than problems that they're trying to solve, but I'd love to hear you guys as sort of, like, firsthand accounts.

Speaker 2: Yes. Absolutely. Right? Like, there's it's it's not enough to have empathy. You have to accompany that with a good communication.

Speaker 2: And, like, by that, I mean, like you said, getting through the surface to understand what the actual problem is instead of them saying, I want this. It's like, oh, that's cool, but what do you need that for? What are you trying to do? It's digging deeper and understanding the core problem and then talking to enough people to find repetition in core problems. Right?

Speaker 2: And that is that feedback. So now we've understood the communities. Actually, I was saying community needs, but that's actually not right. Community problems or friction or struggle points or gaps. That's what we're trying to identify.

Speaker 2: And then we always have to also apply the same empathy and communication internally so that we are aware of company, team, goals, strategies, current roadmaps, and and marketing campaigns, and all these other things. Because now we can take both of those sides, and we try to find alignment. Right? Like that sweet spot where we're connecting, where we find a community, you know, actual gap and can connect it to an upcoming company goal. That's, like, that's that's gold.

Speaker 4: Would that's a great prompt, Sam. The the the there there's a comment in the chat here where I'm saying that you need to deal with the developer objections up front, which was very in line with what was just just said. As far as far as as far as my take on on what you just asked, I would say that you you you also can't be everything to everybody. Right? So so we we in in in my team, currently, we know what types of people types of people, demographics, background in that sense, that's that that's what I meant, are more likely to love and use and adopt software and the ones that aren't.

Speaker 4: And for for the ones that aren't, if we will never be the product that they want to use, we're just upfront about it. Hey. This is this is this is not for you. I would suggest going with Webflow, for example, or something else. Just being sometimes being empathetic, it's it's it's about it's about just sending them to the right place.

Speaker 4: I I would I would quote one of my former bosses. If everything is important, nothing is. And so if you're serving everybody, you're serving no one, and you're you may be actually hurting yourself as your growth, I would say.

Speaker 1: Yeah. I agree. I think it's adding a lot of method to the madness because when you're working with the community, there's a lot of information that you get that's not necessarily like Kurt said, you need to figure out the needs. Right? It's all very valuable, but after you sort of sieve through it Yeah.

Speaker 1: I think that works out with the sort of, like, data approach that that PLG is proposing, the data first approach rather. So that's that is a really good question. And and I think it's a it's an issue a lot of teams have, like, too

Speaker 4: much

Speaker 1: empathy saying yes to everything. I think it's sort of, like, drawing the line and saying, okay. This is sort of where we hand where we sort of, like, stop, and and then we'll we'll do our part. And it leads me to ask another sort of, like, cherry related question. How in in sort of, like, facilitating product direction, right, and sort of trying to be that that voice, how do you sort of balance having the community and and, you know, all these all these all these opinions per se versus sort of, like, your, you know, your gut feeling, but your intention for product direction.

Speaker 1: You know? Yeah. And let me know if you want to get this for

Speaker 4: I I'll I'll pitch in because I have someone in the audience is texting me, and she's saying and she's saying, empathy does not mean saying yes all the time. And I I agree with her. Hey, Jen. I know you're there. Empathy empathy is is absolutely not just saying yes.

Speaker 4: It's about understanding and sometimes saying no. But but, yeah, I just wanted to shout out for for the comment there because it's it's I don't want us to fall into the app of thinking that, again, we have to be everything to everybody.

Speaker 1: That is a great point. Yeah. Empathy is not always saying yes. We have a question actually from the the chat. I'll read it out.

Speaker 1: So Silvia wants to know Silvia says rather, I'm curious to hear about your experience on when slash in what capacity slash how often DevRel could best be involved in the product development process?

Speaker 4: If your development relations team is not involved in the developer in the product development process, you have a bigger problem, I would say. Because as representatives, as the voice of the people using the product, it's just concerning to me that you're not in involving these people in in the process.

Speaker 2: I think it means by I think it depends on what we mean by involved in the development process. I think they might be asking, like, them actually developing, working on the product itself as an engineer. Yeah. I completely agree. If you're not familiar with the product, it will be very difficult to help anyone or provide any feedback on on the product.

Speaker 2: I don't think that you have to engineer on the product though to be effective in developer relations. However, I also don't think that it's necessarily a bad thing to have folks from developer relations teams take on shifts like rotations essentially working on product. Again, when we think of just understanding better the system, the requirements, restrictions, the product roadmap and where things are at, we're developing more empathy, we're getting more familiar with who stakeholders are around different parts of the product and platform. So it's not a bad thing and it gives DevRel folks a chance to keep their product engineering skills up because we tend to be focused very much still on engineering and solving problems, but moving more into education solutions architecting style. So yeah.

Speaker 2: Yeah. It's it's a good thing. I'm not opposed to it, and I also don't think it's a necessity.

Speaker 3: Yeah. I'd say, you know, one place where I'd like to see become more involved is understanding the market as a whole or understanding sort of the ecosystem as a whole. We can get really entrenched in our communities and the nuances there. But, also, if you're thinking about a company, you know, ultimately, you're you're commercializing at some point. So why are people saying no to hiring your tool?

Speaker 3: What are what about the people who said no? What about people who don't wanna join your community? Can you learn about that? And I feel like DevRel is uniquely positioned to do that and to understand, you know, obviously, you're not gonna make everyone happy, but how can we make more people happy? How can you get more people some value there too?

Speaker 1: Absolutely. And we're just around time, so I wanna leave some time for for everyone sort of, like, share their closing thoughts. I think we can take sort of two minutes. But, actually, I I would love to to hear some perspective before we get into that. Sorry.

Speaker 1: Your closing thoughts would be about one minute just so that I can sneak in this question. You know, companies need to make profit at some point. I think we've talked about developer experience, product led growth. What bridge do you see between both and, you know, profitability in terms of gaining sales?

Speaker 2: My end, like how I want to enable that is, again, focusing our efforts on things that are gonna focus help increase product led growth. So we want to shore up onboarding. The smoother onboarding it is, the more likely people are to get into the app. How is it working between the products? We know how it is to work with one particular feature in isolation.

Speaker 2: We can provide feedback on that. What does it look like when I'm actually trying to do something that like developers who are gonna use this tool at their jobs are doing? I can go through those and audit those workflows, those experiences, and provide that invaluable feedback that otherwise is very difficult to get. And then just lastly is, again, just being out in the community, engaging, understanding what folks actually really need in bringing that information back to the company.

Speaker 3: Yeah. I I I don't necessarily wanna echo that, but I wanna add to it. I wanna say, you know, people tend to think of sort of go to market professionals like marketing and sales as being extremely commercially driven and sometimes to the fault of especially, developer personas and sort of at odds with developer relations and developer experience. I feel like, you know, there's going to be a new generation of marketing and sales professionals who are more empathetic, I believe. But in the meantime, it really is developer relations and developer experience's role to say, we're going to commercialize, but here's where we're gonna draw the line.

Speaker 3: And so many products led companies or companies that I see going product led, you actually have to correct for the the desire to commercialize too soon or too forward so that people are not receiving any value in the product. So, I mean, it was hot five years ago as to be charging per user or for SSO or those sorts of things and products, but the best product led companies have moved past that because they realize that that inhibits engagement. When I can't add the rest of my team, my team's not gonna adopt the product, and ultimately, my business is never gonna pay for it. When I can't SSO in or integrate into other products that I love and already pay for, then my data is not gonna be into the tooling, and I'm never gonna get deeply engaged. So I think it's really up to DevRel and dev experience to say, hey.

Speaker 3: We wanna engage these users. We wanna engage this community as a whole. And the things that you guys are doing in marketing and sales, you're totally hamstringing us there. So that's where I see

Speaker 4: that role.

Speaker 2: Absolutely. I

Speaker 4: would I would, add to what was just said. Just just one one concept, the concept of relevancy. It is it is a a company exists if it is sustainable. So, you know, in order to be sustainable, they have to make money. Addressing retaining users, retaining a community of users, catering to users that are not relevant for the business, that they will never be relevant for the business will will will not will not result in in monetization of those users.

Speaker 4: On on the other hand, when when a user pays you, they're they're recognizing there's an exchange of value. I got value. Here's some money back. So we need to find more of those and nurture more of those even if they stay free for two, three, five, six, seven months, that that's the focus. And there's, and, again, we can't be everything to everybody.

Speaker 4: And you need to go into your pool of users and figure out which ones will never buy and which ones will. And then and then you have to optimize for the ones that will that you will be able to monetize. And, yeah, that's I guess I guess you asked the wrong the a good question, but in a panel that is slightly biased towards growth, which may be you know, you may be getting a biased answer. But but yeah.

Speaker 1: Yeah. But that's the value that everyone subscribed for, so thank you for your ask. And, yeah, I'm just, like, digesting everything so much inside from all of you. It's just been amazing. And we're around time.

Speaker 1: So like I promised, one minute of closing thoughts. Again, thank you so much to everyone for joining. Shall we go in in this order? Yes, sir.

Speaker 2: Go right back around. Yeah.

Speaker 3: I mean, my closing thought is really that PLG, product led growth, is the strongest in the developer community, and I actually look to this community the most in order to to get inspiration and ideas. And, ultimately, it is I think you guys are the the OG PLG and you don't even really realize it. But really focusing on that user, focusing on their needs, and advocating them to the larger organization is that best practice, and that is what PLG is. It's not just a freemium model. It's not just picking out people who are showing a propensity and converting them with sales, and it's not just removing sales from the process.

Speaker 3: I still think it is really people heavy, but it's people who have empathy and who can take learnings from solving problems and apply that to the product rather than just doing it manually.

Speaker 1: Awesome. Great.

Speaker 2: Yeah. I honestly don't have, like, much closing thoughts to follow-up on that. It just except to reiterate one more time that developer experience and product led growth work really well together. Not only can they, but they really complement each other if you're focusing your energy in the right places.

Speaker 4: Yeah. There's there's there's there's really not a world. I'll go back to my my earlier comment. Community is the product, and there's no product without there there isn't a product out there that is growing 100% year on year without some good user love, word-of-mouth, and and and so on. So that's that's community.

Speaker 4: That that that's your community. That's your ecosystem, whatever you wanna call it. So, it's just a balance. I don't again, there are no two concepts. There's one, and, we should look at this as one team, with the same goal.

Speaker 1: Absolutely. Thank you so much. Like I mentioned, great takeaways. I'm definitely watching the recording of this immediately after. Well, immediately, it's available.

Speaker 1: But thank you so much, Sam, Kurt, Mario. It's been a pleasure. And I think in the Discord, there'll be a couple questions after, probably. So maybe hang out there and see you somewhere on LinkedIn or in real life. DevRelcon deep dives.

Speaker 1: Yar.