 All right, cool. Welcome everyone, I'm Emily O'Mear. And I'm gonna talk about applying the principles of product blood growth to open source projects. Before I start, I'll introduce myself just super briefly. I'm a positioning consultant and I work with primarily open source startups doing things like figuring out what their differentiated value proposition is, how to explain what it is that their project does in an accurate and differentiated way. And then I also host a podcast called The Business of Open Source. And I talk to a lot of people about the intersection of business and open source. All right, so let's dive in. So product blood growth is just a growth model, usually obviously in a commercial setting that refers to a bottoms up approach so where your product is supposed to drive all kinds of growth all by itself. The contrast is with what would be called a sales lead, a growth where you have a sales team that's gonna be cold calling accounts and driving growth of your product that way. So product blood growth, sorry, I'm not sure if my microphone is working correctly or not, I will assume it is. So in product blood growth, you want your product without any interaction from any human being to help people discover it. So driving customer acquisition, encouraging people to continue using it and then also expanding, which means people should be ideally referring your product to their friends but then also using it more and more and more. So in a commercial sense, this would mean each individual is spending more money with your product. And when you think of some good examples of what's product led versus what's sales led, think about Slack versus Microsoft Teams is a really good example. So Slack had a product led growth model where they encouraged actual users to use the product. They built it for the needs of the users in mind. Whereas Microsoft Teams, generally speaking, had a more top down approach where you'd have an executive or an IT person who's like, everyone here is using Microsoft Teams. You don't like it, that's too bad. So those are the differences, think of those two approaches or those two companies as really good examples of each approach. So when we're talking about this, particularly in an open source context, I think if you look like really at a surface level at product led growth, it can look like a field of dreams because it's like that sort of ideal. Yes, we're gonna build an awesome project and everyone's gonna come use it and it's gonna require zero effort other than building our project. But that's actually not true and the companies that do this for their commercial products put in a ton of effort into optimizing how their product is moving people from discovery to usage to referral and they also put a lot of effort into figuring out their fundamentals. So it seems deceptively easy when actually product led growth is quite challenging and that isn't any different in an open source context. It's still that you're gonna have to put some thought and effort like non-coding, non-building thought and effort into your project if you want to really succeed with project led growth. So the thing is though, most open source projects don't have a sales team that are making cold calls and trying to get people executives to force their project on their entire team. So by default, open source projects are following some kind of project led growth strategy. It's just that by and large they're not doing so with intention and that means like some people might do it fairly well almost accidentally, some people might do it less so but there's a lot less, there's not as much intention and iteration and figuring out well, if we change this about our project how does that impact how many people are discovering it naturally for example or how their experience is. So that's basically why I wanted to do this talk was to encourage more open source maintainers to be really intentional about their growth strategy and take some of the ideas from a product led growth strategy and incorporate it into how they think about their evangelism and then also how they think about their project roadmap because product led growth involves both. It's not just a marketing initiative. Okay, so what are the sort of three pillars of product led growth? First of all, user focus to design. Generally speaking, open source projects have this down. They're not usually designed with the needs of like the executive team in mind. They're built for the person who's gonna be actually interacting with the project. Awesome. The second one, delivering value before capturing value. This is one where I think there can be some misunderstanding because when people talk in a commercial context about capturing value what they mean is like capturing your money and open source projects are not doing that. However, open source projects do ask people to invest time. And I think often they underestimate how valuable that time is. And there's a lot of ways that an open source project can ask for that time investment. One is just asking people to spend four hours setting the project up and doing configurations and figuring out how to use it before they get any value out of the project. So that's one, just investing time in order to just use it on their own. But open source projects also want people to be active members of the community. They want people possibly to even contribute code, ideally to be evangelists for the project. That is a type of value that you as a maintainer could possibly be capturing from your audience. So you wanna make sure that your project is delivering a lot of value as soon as possible without asking very much from people who are using that project. And then the third thing is sort of a question of intentionality, building your product with growth in mind, building your project, thinking about how is this project built so that it removes friction for users? How is it encouraging people to use this project over and over again? How does it encourage people to interact with it increasingly? Are there any network effects? How is it encouraging people to talk to their colleagues and friends and get them using this same project? And that is mostly a question of intentionality. Is it something that you're even considering as you're thinking about what's this project roadmap looking like? Okay, so let's talk about some practical ways that you can apply these principles, these pillars of product-led growth to open-source projects. But before we do, also talk about some ideas, some product-led growth ideas that you have to keep in mind. One is the natural growth rate. Even if you have a hobby open-source project that does not have a marketing budget or anything, you're probably doing some kind of evangelism activity. You might be writing blog posts, you might be speaking at conferences, I don't know, something like that. You're telling people about the project. Your natural growth rate is actually how much your project would grow if you did none of that. You just put your project out there and you just allowed people to discover it without any sort of activities on your part. And it's just kind of a benchmark to think about is this growing even with me doing absolutely nothing to promote it? The next one is the activation rate, which is actually really important in thinking about project-led growth. Activation is the moment when somebody first uses your project and they experience like a magic moment. Basically, they experience a value. So the example of Slack being a good example, when you send a message on Slack, that's you're considered activated because you've sort of experienced the value of Slack. You're not activated if you've just created an account or if you've downloaded the application. We could use another example like an app like Uber. If you download Uber, you're not activated. If you actually book a ride, take the ride, you're activated. And that activation metric has, it correlates really heavily to somebody who's then gonna stick around. You want somebody to activate as soon as possible after downloading your app or your project. And it's also really important to know what activation is because, well, for those examples that I just did, it seems sort of obvious and not all projects and not all products have a very obvious, or they often do many things. And so it's not always obvious what exactly your activation moment is gonna be. But you wanna track that. And you wanna know how many people are activating versus how many are just downloading and then going away. Obviously, you wanna know your retention, how many people are using your project one time and then never interacting with it again. You wanna track how engaged people are. This can mean how many people are becoming active in your community. But also, are they using your project over and over again? Are they using it every day? Are they using it every month? Those sorts of metrics are really important. And then, of course, are they telling people about it? That's really important to know. All of these things, quite honestly, can be hard to track. And they are harder for an open source project than for a commercial product. But they are things that you wanna, like metrics that you wanna have in mind if you're thinking about really applying product-led growth to open source projects. But the bottom line is that you wanna think about how do I create a project that is really easy to discover? It's really easy to use and it's really easy to get value from without any kind of interaction with any human being. Or possibly with your community, but ideally without a human being. You'd want no human interaction in order for somebody to have discovered this project, used it, gotten value out of it and thought that it was totally awesome. All right, so let's talk about some steps to help make this happen. The first step is actually defining what your goal is. And the reason that this is important for open source projects is because unlike in a commercial scenario where your success metric is really obvious, it's more profit, in an open source context, your success metric is non-obvious. So it could just be that you want, sorry. It could just be that you want more users. It could be that you want more code contributors. It could be that you wanna connect this to whatever your larger goal for your open source project is, which maybe is like hiring people who are active in your open source community or whatever it is. Maybe it's that you personally have a side project that you want to help you get another job. And having in mind what is gonna be success from the growth of your project allows you to track the metrics that are actually gonna get you there. If you only care about increasing users, then you're gonna focus on your user's metrics and as you're evaluating is this growth strategy working, you wanna look at the user numbers versus the code contributor numbers. Okay, so the next step is really important, which is nailing your marketing fundamentals. So part of any project-led growth is making it easy for people to discover the project and really easy for them to understand is this going to fit my needs or is this not going to fit my needs? And to do this without interacting with a human being. So it means that you need to position your project well. So you need to explain really well what's unique about your project. Be accurate, be differentiated, be clear so that people understand and they don't have to spend two hours downloading, playing around with your project, only to discover that this doesn't actually fit their needs very well or almost even worse, using your project for something that it can kind of work for but doesn't really work very well for because then you get like disgruntled users. So you wanna be very clear and very intentional about how you're positioning and also communicating about your project. That's like testing and refining your messaging. So that means figuring out how to talk about your project and actually testing if it's working and changing the message. And when I say the message, the message that you're putting out on your website and your read me, places like that, getting input, getting feedback from people and then making adjustments to see how, to make it resonate more with the people in your audience. You also have to understand who the people in your audience are. What characteristics they share, what characteristics they do not share, what's unimportant, so that you can create documentation, you can create a website that and you can create a project quite frankly that's gonna work really well just for those people who are in, have shares very specific characteristics. You also need to know what outcome people are expecting. This can also be a little bit of a gotcha because you might have created your project with a particular outcome in mind and sometimes you will find that that matches the users that actually come to your project and sometimes you will find that it doesn't match exactly what people are expecting and you need to communicate exactly what you expect, what people should expect to get out of your project again so that they are able to discover it and then sort of use it and be happy with what they've got. So I said you need to understand who your users are but you also need to know why they're using your project and how they're interacting with your project. So we can talk a lot about reducing friction, getting people quicker time to value but you have to know where is the friction in what is preventing somebody from getting value out of your project sooner. This is where it can be really valuable to do user interviews where you have somebody share their screen and actually interact with your project in real time because then you can see where are the sticking points, what could I change so that people are able to more easily interact with my project. You also want to understand like why did people start using the project in the first place so that you can connect with others and adjust your message to connect with more people who are experiencing whatever problem it was that are bringing your users to you and then just figure out how are people discovering your project and how can you help more people like them find your project. Okay, so next is very important, optimize for time to value. So figure out what are the obstacles that are standing in the way of getting value out of your project and eliminate them. This involves making design choices, right? Are we gonna ask somebody to do a ton of work at the very beginning of using our project or are we gonna build it in a way so that you get something really immediate, get like provide a sort of immediate wow and then maybe I'll ask for work after that but building your project in a way that provides like a very obvious, aha, eureka moment is one of the best ways to follow a product led or project led growth strategy but there's a couple other things that you really need to do. So one is investing in really good documentation. Maybe the reason, maybe the friction that's preventing someone from getting value really quickly out of your project is that they are unclear about how they're gonna set something up it's really important in your documentation though not just to focus on the how you also have to focus on the why. So why would somebody want to use your project or use a particular feature in your project and then also how do they make it start working? You also want to make sure your support is really good because for actually two reasons. One obviously if someone needs help you wanna help them but your end goal is to make it so they don't have to interact with a human being at all you're not gonna understand what those sticking points are unless you have invested heavily and making sure there's a way for you to get the question and then later incorporate that question either into changes in your documentation or changes in how your project is actually built or unused. One of the sort of core tenants of product led growth in general is a good user experience. This is not something that all open source projects are known for and just as quite frankly like a very short time to value is also not something that a lot of open source projects are known for. So if you wanna really focus on a project led growth strategy that's something you wanna think about prioritizing like really good user experience really short time to value. So this is also a design choice not all software delivers an aha moment but the ones that are sort of the best fit for a product led growth or project led growth strategy do. So a counter example to this would be like if you had a software that is only going to give you reports over time and you have to install it now and then like two months later you are gonna get a report about how certain metrics go up or down. First of all, that's a really long time to value. It's a really long time to any sort of aha moment. So that's not a good fit for a product led growth strategy. So if you do want to have this project led strategy you wanna make sure that there is a moment when people interact with your project that is magical. One example I've seen of this is a open source project that allows people to visualize the relationships between their cloud infrastructure and you would install this software and then boom, you'd be able to see how everything interrelates to each other and users would consistently say this was a magical moment because I'd never had this view of all of my cloud resources, now I do. That's their activation metric. In product led growth, the sort of key marker is having an activation rate that's over 40%. That seems a little bit low but actually the reality is that a lot of people download stuff and sign up for stuff and never use it. So if you have 40% or more of people who download your project, actually opening it up and actually doing whatever thing it is that you do, actually getting the value that you provide, you're good. That's a really good sign that your project is gonna grow and then the magic moment should happen as immediately as possible and that's a product design decision that you can either make or not but make it as easy as possible for people to get to that magic moment. Okay, so last but not least and this is why product led growth takes a lot more effort than people expect. You have to iterate a lot. So for example, while it seems like obvious what some activation metrics should be, a lot of companies that do product led growth find it actually fairly challenging to figure out what the precise moment is, what the best moment is that they should be measuring. And you wanna see how do changes that we're making in our product, in our messaging, in our website, how are they impacting all of these metrics? The activation rate, the natural growth rate, the referral rate, et cetera. Which is gonna lead me actually to talk about why this is really, really hard for open source projects and the first thing is around metrics. So most open source maintainers don't have access to very many metrics about what's going on in their community and if you wanna be really serious about applying a project led growth approach, you probably have to get some more metrics than you currently are, some more metrics than the standards. The best way to do that without making people angry is to be very transparent about it. So be very transparent about any metrics that you're collecting. But if you're leaving yourself totally in the dark about even what's happening after the download moment, then it's gonna be really challenging to actually take an intentional, iterative approach to your growth strategy. So another thing is the feedback loop. I mean, this goes to the metrics problem, but another kind of feedback is also interviews. A lot of products, or a lot of open source projects don't have a super tight feedback loop that encompasses more than people who are actively coming to the community. And more than what they're actively bringing to that community. So again, you wanna try to get more information about what's going on in the minds of your users. And that can be challenging. And many open source projects find that that sort of effort is deprioritized, but it is really important if you want to really take seriously your growth strategy. So poor documentation can also be a really big challenge. This goes not just for open source projects, but a lot of software in general struggles with not so great documentation. But documentation is really important because it scales more than interaction with human beings. You can reach so many more people if you have really, really good documentation. So this is something to focus on for open source projects that want to grow naturally. And then just not being intentional. So whatever growth strategy you're following, you just wanna be intentional about it, be aware. And that's not always what happens with open source projects. Often open source projects are not even sure what those success criteria are. And that's sort of the most basic thing to know where you're trying to go. So I would say if you are intentional, you're collecting metrics, you've invested in having pretty good documentation, and you try to get to actively illicit feedback, you're gonna be way ahead of the game in terms of implementing product-led growth. And I'm gonna end with a couple more challenges, which is finding the right aha moment. And this last one, I wanted to make sure to touch on, because when you talk to people who are product-led growth professionals, this is what they do is they work with companies on product-led growth, they will all say that they feel like there's a certain amount of luck and guesswork that goes into getting product-led growth right. And that while you can look in hindsight at companies that have been these huge product-led growth successes, it can sometimes be really challenging sometimes you only see that success with hindsight, and it can be really challenging to see in the moment is this the right decision or not, is our product-led growth strategy working or not? So all these things can help your project to grow, but you have to sort of accept that it's both an art and a science, and you may not feel 100% in control of your project's growth, even if you do follow all of the product-led growth best practices. So on that very optimistic note, that's it. Does anyone have any questions? Okay, I'm supposed to repeat your question. The clarifying question is, is the aha moment and the activation the same? Yes, so the aha moment is the thing that your, when you talk about your activation rate, it is the percentage of people who experience your aha moment. Any other questions? What do you, I'm not sure if I understand. Okay, now I understand. Okay, let me repeat the question. The question is, let me actually also make sure I understand the question. So if you are building an open source project because you're scratching your own itch, does that always mean that the aha moment that you experienced will be the same as the aha moment that your users will experience? Is that the question? Okay, I'm actually really glad that you asked this question because the answer is maybe. So, and this is actually one of the biggest challenges is that just because you built something to scratch your own itch, doesn't necessarily mean that your project is going to, like it might mean that your project is gonna go out into the world and scratch that exact same itch for everyone else, but it might turn out that there's some other thing that people start using your project for that is, I'm not gonna say unrelated, but usually tangential to that itch that you were originally scratching and that's something you wanna be really aware of. So, sometimes you'll find that the aha, the magic moment is the one that you set out to create, but you don't want to assume that that is actually how users are experiencing it. Any other questions? Yeah, the best way to capture that moment? Like, so the question is like, how do you track what the aha moment is and what's happening like as people are going through the onboarding process, is that right? Yeah, so she was saying like, how do you know when they're experiencing the aha moment? Definitely, I would say like you ask them and you don't have to ask everybody, but you should ask some people and I think that you'll get much better answers if you have a conversation versus if you send a questionnaire, because if you ask somebody like, did you experience a magic moment? They'll be like, no. And, but if you ask them like, can you tell me what happened when you started using this project? Can you walk me through why you started, why you downloaded it in the first place? What did you find after you had got it set up? What were you able to do? And see how they react to that. That's how you're gonna get the information. You do have to do a certain number, like have a certain number of these conversations because there's gonna be weirdos. So you don't wanna pay too much attention to the weirdos, but on the other hand, if you have like 10 conversations and like nine of them are weirdos, then the weirdos are right. So that's the thing that you wanna like, pay really close attention to. And like, but have those conversations and see what the commonalities are. Thank you, Emily. Can you specify some of the metrics that you found pretty useful? So my assumption is once you've designed those success criteria, that's where you're gonna build your OCR towards. But before we even reach that OCR, I assume there are some more fine grained metrics that you probably find that more useful, that building towards there. So I wanna know some, whether it's tooling or it's anything specific you recommend. So there's a company called Scarf that also has an open source project. They'll help collect a lot more metrics about what's happening in open source projects than you would just get by default. The thing that you will really wanna pay attention to is not just are people downloading, but also are they using? Like, are they actually using the project? So that's absent any sort of qualitative feedback. That's the thing that I would be looking at is looking at number of people downloading, then number of people actually actively interacting with the project, and then from there, how many people are joining your community? I'd say those are the three things that you wanna track. What was that? So downloading versus people who are actually actively using the project and then who are joining your community, whatever it is. I mean, you could actually add a fourth in there because people will join your community and never participate. So people actually participating in your community. This is great. How can, so how might you find good examples of product like growth in open source projects? So to be totally honest, I would say any open source project that has become very successful, that means that they have used a product like growth. I can't think of any examples of an open source project that was like I said, like was like calling people, cold calling executives and like, hey, force all your developers to use this open source project. So that's why I would say like, ultimately product like growth is the default growth strategy that open source projects use, but they're not always aware or thinking about how to take these ideas and put it into open source. I'm just wondering whether some kind of investigation could be done to investigate how many companies or this kind of open source communities are successful following this practice. So thinking about how many companies are successful following product like growth, that's interesting. I don't really have a good answer to that question. I think, so I actually think that the number of open source projects that are very intentional about any growth strategy is as a percentage of all open source projects relatively small. And then intentionality is kind of like the bottom line, but yeah, I don't know like exactly the, I don't know what the research would find. Cool. If we have one more question, we could do that or we could finish up. I see you have the podcast listed. Do you have one recorded that's very similar to this discussion? I'd love to share it with my coworkers. Well, I did have a podcast with a woman named Sam from OpenView and she is a product like growth specialist. So that I think it was recorded, I think it published last December I wanna say. So yeah, that's who Sam Richards is her name. Okay, that's it. Thank you so much for coming and yeah, enjoy the rest of the conference. Thank you.