 Welcome everybody, I'm Libby Clark, I'm the open source community marketing manager for AWS. And I'm Colleen Bettich, that's loud. And I am a product marketing manager for Amazon RDS. And today we're going to talk about how to build open source marketing into your product marketing. And it's all about finding the right balance, that'll be the theme of our talk today. But first I wanted to start off with a little story about a project launch that we did last fall. At AWS, we launched this project called Finch, which you may have seen in our booth. Finch is an open source command line client for building, running and publishing Linux containers on Mac. And it is built on itself, is built on four open source projects, Nerd, CTL, Container D, Build Kit, and Lima. And so that makes it sort of an interesting case study for open source marketing. Because when it launched, it was a crowded space already. There are many competitors in this space and our competitors also build on those same projects. So why does that matter? Why do you care? Our solution is better than theirs, right? If you're thinking of as a product marketer, you're saying our solution is better than theirs, it's faster, it has more features, our logo is cooler. So why don't we just go talk about our product and may the best product win? But not so fast. You're building on products with, remember how I said you're building on projects that our competitors are also building on. What happens if your competitors feel threatened? And perhaps they, we can't make important updates to Finch because they're suddenly disagreeing with some changes that we want to propose to underlying projects. The bottom line is that product success, your product success depends on the community support from the projects that you're building on. And so that's why we do open source marketing as product marketers. We need those projects, the underlying projects to be successful so that our products can be successful. So a core group within the Finch team, which is inside of our containers, Oregon AWS was experienced in open source launches and they followed a few best practices in positioning their product. One of them is communicating with the upstream. So Phil Estes, who you saw speak yesterday on the keynote stage is a contributor to Continuity. He's a maintainer and he's well respected in those communities and he was able to go before the launch and go talk to some of his community members, the people that he works with every day on those projects and tell them what we're planning and ask for their feedback and gave them reassurance that we're still continuing and planning to continue to contribute upstream to those projects. And he also made the case that this is a big ecosystem that benefits when more people join it and when your product on top of those projects, we all learn from each other in the products that we're building. We also, the second thing that we did was we credited the projects in the launch. So make sure we say these are the projects that we've built on and thank them and make sure that we're not taking credit basically for the work that they've already done and helping us to launch our product. And then the third thing that Phil and his team did was that they released the project early and gathered feedback from the community. So this creates a more open development process and shows the community that we're open to feedback and that we want to work with them and there's room for contribution. And the result was a product launch that launched with community support from the very beginning. Phil actually got approval from a couple of key community members, Akihiro Suda and Justin Cormack from Docker to use quotes in our launch blog saying we are excited to work with AWS on these projects. And so that public support when you launch or just in general for your product is really important because now the risk to the product has gone down dramatically and you're able to bring the community along with you on your product journey. So now Finch is an open source project itself which is a bit of a unique case study, right? Because, and it's an edge case because as a product marketer you're not always gonna have an open source engineer like Phil Estes helping you guide your product. But the story of Finch can be applied to most if not all product launches and products as we use marketers launch and own today. So, and this is because up to 85% of products of software out there is built on open source. So whether you know it or not your product is built on open source. Yet as product marketers we're not really integrating open source marketing enough into our product marketing strategies. And it's hard, right? We as product marketers have enough to do already and carving some time out for promoting open source projects can feel like a burden sometimes. And it may feel like additional work. It can also be hard to convince leadership to give you the funding and resources you need for a project to promote the project along with your product. And when an traditional enterprise marketing follows different kinds of metrics, right? Then an open source marketer might. So you're following leads and conversions and clicks and you have different metrics for open source. So that can be a bit of a challenge. But it's worth it. And you get the benefit as a product marketer by integrating some of these practices that we're gonna talk about today. It does take time and discipline. So an open source marketing is a skill that you build with practice and Colleen and I are not experts in that area. We're learning just like everyone else. But we do have some kind of best practices that we wanna share with you today. The key is find the right balance. If I want you to take anything away today, that's the key message, right? Find the right balance between project and product and integrate project, open source project marketing into every aspect of your marketing activities. Ideally, you're walking the right balance between product and promoting your product and promoting the projects that you're built on. And to do this, you can build open source practices and considerations into every part of your product marketing strategy. Today for the purposes of this talk, we're gonna focus on launches. But you can use these practices in any kind of activities that you are doing. But launches are fun, so we can focus there today. So the first step in product launch is doing your research. You wanna know the key players and know the launch. So you wanna learn the story behind your product, the problem it solves, its technical capabilities, competitors in the market, what differentiates your product and who the potential users are. And as you're doing this research, so this is kind of a standard product marketing practice, but as you're doing this research, it's a perfect opportunity to ask, are there any open source dependencies for my product? And what do we mean by a dependency? Those are the dependencies are the software components that your software is built on. And those are providing critical functionality to your product. And some dependencies are more important than others when it comes to what you're gonna market. So you should ask, how important is this dependency for my product? And a good rule of thumb is if you were to yank that project out of your product, if it were to disappear, what would happen to your product? Would you have a product anymore? If the answer is no, then that project and community needs to be in your marketing strategy. And even if your product doesn't have any strong open source dependencies, that means it's written completely from scratch in house, you should still be asking if your product has open source compatibility and that's another way to build open source considerations into your marketing strategy. So with your list of open source dependencies and compatibilities in hand, then you need to go research those communities as well and the technologies that you're building on. Talk to your, to talk to the leaders in the community. In the Finch example, that was Akahiro Suda and Justin Cormack, who are those people in your community? And do you already have connections to them? Are there engineers on your team who are working upstream already, perhaps? Or at the very minimum, if they're building on the project, they probably already have the expertise in the project and they can help you, help navigate through the technical discussions that you need to have. So you wanna find out who pulls weight on the project, who are the committers, who's influential and respected in the community, make a point of going and talking to them. And if it's not you yourself, then perhaps you send a delegate and get some questions answered through your engineering team. Some questions you wanna ask are what does this community care about? How is our company perceived in this community? Are our contributions welcome? Are we an active and valued member of the community or not? And you can use tools like the CNCF DevStats tool to find out how your company is contributing. So for example, I pulled up container D, which is a CNCF project. And I was able to see that AWS is, or Amazon is the number four contributor to that project. So doing that research and figuring out how you're contributing and what quantity and what quality are important things to consider. And then you wanna ask how will this product impact our community? And that's a really key question. Will they welcome our product or will they consider it a threat? Learning about the community is then key to being able to assess some risk, right? And I have to stop and say that free is not free when it comes to open source. So you can download the code from the internet and go use it. It's free and that means getting to market faster. It means being able to iterate and innovate. But then there are some risks to that as well because now you're taking a dependency on that community and you're reliant on people outside of your company to maintain the code that your product is dependent on. So some of these risks include supply chain security risks if there are vulnerabilities in the upstream project, governance issues, perhaps maybe there's one vendor who controls the project and all the code that goes into it. Maintenance is also an issue. Are there, is there one or more maintainer on the project and how easy is it to get changes into the project? So once you learn those, you can then start to plan for contingencies. And these are things that you should be asking before you launch, right? And if your project leadership and engineers are not already asking these questions, then that is a huge red flag as a marketer. You need to take it upon yourself to ask them those questions because otherwise it can put the product at risk. Maybe not in the short term because you can still get a product out the door. But when you start to build your product on a community over the long term, it can have deleterious effects if you're not taking those things into consideration. So don't sacrifice the long term growth of the project for the short term gain of your product. So the next phase of the launch process for a marketer is positioning and messaging and I'm gonna turn it over to Colleen then to talk through some of the rest of the steps. Thank you Libby. So hopefully everyone here today has a basic understanding of what positioning and messaging is, if not, no worries. I'm gonna go into it a little bit. So great positioning is vitally important in a product marketing strategy. This is because this helps define what your product is, who you're targeting for it, and when they should buy it. It is ideally well thought through, research backed if you can, and it is an internal tool to help you determine what are the gaps in the market? How does my product help to fill those gaps? What are some of the similar products available on the market today that I'll be competing with? So if positioning is your tool for defining what your product is, then your messaging is your vehicle for communicating directly with the customer the unique value of your product. Ideally, good messaging is crisp, clean, and accurate. And unlike positioning, messaging is an internal or an external tool to communicate that value. So I already said messaging positioning is probably one of the most important things that we can do. If you are wanting, if you are considering the fact that whether your product includes an open source project or it's strongly tied to an underlying project, then you might be asking yourself, how do I incorporate open source marketing into my positioning and messaging strategy? Well, to do that, let's take a step back and think about how marketers today might begin to form their messaging and positioning strategy. One way we do this today is a tool we like to use as a messaging framework. This includes all kinds of normal sections typically, such as your positioning statements, key problems that your customer may be facing, how your product solves for those problems, AKA your benefits, and usually a detailed competitive analysis. You can include other sections, of course, as well, depending on your product and what you need, but these are kind of the core things that you can focus on. So as you're developing this, it's important to ask yourself, through each of these sections, how does open source come into play for each of these sections? You've got to invoke the project with purpose. Don't just sit there, what this means isn't that you need to mention the project in every single one of these sections, rather that you have actually thought through how it fits into it. So one thing that we've done, this can be a difficult task sometimes, so we've come up with a list of questions as well, that you can use as you begin thinking through each of these sections, such as what does my product do that the open source project does not, and vice versa. How would the community feel about this statement? Who is our real competitor? Let me tell you, it's not the community. And these can be difficult questions to answer. So to help you kind of think through these as you're going through this exercise, we've come up with a list of tenets to keep in mind. The first being relevant. Good product messaging, references, relevant open source communities, and positions your product compared to them, or not compared to them, but next to them. Second is collaborative. Community involvement informs your positioning. Good collaboration with an open source community is going to be better than any single marketing statement or campaign that you come up with. Third is humble. Demonstrate your open source knowledge by accurately and humbly talking about your contributions to the community. Four is positive. Don't disparage your open source community. Always talk and don't compare your product directly to the community. Five is appreciative. As Libby already mentioned, open source is not free. Appreciate and publicly acknowledge the innovation that has driven the creation of your product. And then finally, balanced. Again, a common theme you'll see out the presentation, but balance the promotion of your product with the promotion of your product or project. So another example of what this might look like in practice is we're gonna look at is naming. This is something else you might be doing at the positioning and messaging stage of your launch. So if you have a launch and it is strongly tied to an open source community, one thing you might be asking, you might need to ask yourself, does it make sense to include the project name in the name of my product? So let's take AWS, for example. Today we have somewhere around 30 managed open source services. These are services that utilize communities that are well-loved and popular today. And we have AWS's operational expertise built on top of these. So AWS takes care of things like provisioning, scaling your clusters, software installation, et cetera. By including the project's name directly in these services, it's automatically clear to customers that this is something that they're already familiar with and that is similar to something that they're already using today. On services that don't include the name of the project, sometimes we have customers coming to us confused. We might have someone come up to us and say, I had no idea you offered a managed version of this project. So in order for, and whenever you have a number of services available, it makes it that much harder for the customer to find the product that is gonna be most relevant to them. More specifically, when determining whether or not to include a product name in your project, you also have to think about your product, the industry it's in and where your product's gonna be in one years, three years, five years. I know it's a fun conversation to have with your product management engineering teams, but it's one that often needs to come. So looking more specifically at an AWS example, we have the Amazon Relational Database Service. We launched the Amazon RDS service in 2009 with RDS for MySQL. And when you think about the relational database market, not everyone in the world is going to want to build on a MySQL database. Some folks are gonna wanna build on a commercial offering and others are gonna wanna build with other open source projects, such as MariaDB or PostgreSQL. So in scenarios like this, this is why we were able to expand our services to seven engines today and five of which are open source or open source compatible. To be able to reach market the other folks in our market. So this is something that you should keep in mind with your product in thinking about the future of your product. Is this going to be something that you're gonna have to expand yourself into other open source projects? And as you think about this, one of the advantages that we had in naming our products this way is that we were able to name them in such a way that it clearly shows who should care about our service. By having Amazon RDS as a family of services, we created a broader umbrella brand that ubiquitously speaks to the unique value while each service within that umbrella speaks to the end user. When our customers think of Amazon RDS, they should think of a managed relational database that is easy to set up, operate and scale. And when customers think of RDS for PostgreSQL, they should think of their favorite PostgreSQL features and extensions made available on Amazon RDS's managed environment. So whenever you're thinking through your own product naming, that's what you need to come back to. Think back about your product and the industry that you're in. Think about where your product's gonna be in a couple years and think about whether it makes sense to include other projects with your product. So the next phase of our launch that we're gonna go through is now your tactics. You've built a strong foundation of messaging and positioning and guardrails to begin to create content that increases the awareness and education of your service. So how do we begin to put this into practice whenever we're thinking about building the community into our content? Well, one thing you have to keep in mind is that whenever you're building content as a product marketer whose service relies on an open source technology, is the fact that you're gonna be wearing different hats at certain times. Sometimes you're going to need to focus on your product and promoting your product and wearing your product marketing hat. Other times you're going to have to think about your product through the eyes of the community and wearing your open source marketing cap. What would people think about the content you're creating through that lens? A lot of times you might have to be wearing both of these at the same time. And then there are other scenarios where it might make sense to bring in somebody else from your team to wear your product hat or open source marketing hat for you. So you can remove yourself if you are trying to talk to someone from the community. Someone else can talk about your product without creating this bias or conflating your two different offerings. So let's go back to our launch. As a marketer there's a lot of content that goes into creating awareness and education for your product. You're gonna have to think about your marketing pages and what that copy's gonna say, blogs, videos, social media and on-site advertisements. As you begin to develop this content it's important to think about key considerations with the community such as first what type of content are you creating? Where is this content going to live? When you're thinking about open source are you allowed to use the community's logo or branding? Think about things like how does the community typically create content? Do I wanna replicate that? All of this will help you create content that is better able to talk to both your customer base and the broader open source community. So another example we have from the Amazon RDS team is a webinar that we completed in the past year. So to give you guys some background over the past couple of years the Amazon RDS team has been working on bringing in more folks from our relevant open source communities and amping up our participation with our existing team in those communities as well. As part of this for PostgreSQL in particular over the past couple of years we have been creating webinars talking about the latest major versions of PostgreSQL. The purpose of this is to of course just educate our customers on what are the latest features, capabilities, bug fixes that they can get in the newest version. So in 2022 when this blog was made the latest version at the time was PostgreSQL 14. And because we have folks from the community on the team something that we were able to do with this latest version was to provide our customers with a sneak peek into PostgreSQL 15. By doing this we were able to create excitement not only for our own customer base but also for the broader PostgreSQL community. And doing something like this would not have been possible without our team's collaboration with the community. So with this in mind you might be asking yourself to what extent can I include the community in my marketing? And so it's always important to keep in mind how much you're using them in your marketing against how much your company is giving back to the community. If your company really isn't giving a lot back but you're using them a lot in your marketing then this might create the negative perception that your product or the negative perception that you're taking too much from the community. If you on the other hand might be giving or sorry contributing quite a bit sometimes depending on the project some folks might see this as you trying to take over the community, which is also not great. In addition to this you also wanna balance the importance of considering which product, sorry, you need to balance the consideration of when you're conflating you don't wanna conflate your product tactics with your project tactics because when you get too involved it can be easy to get these two intertwined and folks can't tell which one you're talking about when. So a good rule of thumb to keep in mind is that you can take a bit or you can use the community to the extent that you are giving back to that community. So the next phase of your launch as a marketer is to actually launch the product. And in order to see how your product is performing you need to start thinking about how what a successful launch looks like. For a product that's based on open source you especially have to consider what it looks like to be successful in having your project succeed and your product succeed. What is one mechanism for doing this? Goals. So a common issue that folks might have is asking yourself what are the right kind of goals to take? Chances are your VP or your C-suite wanna know the actual revenue impact of your marketing tactics. And depending on your company this can be very difficult to do if not impossible. Furthermore the connection between product and open source isn't always obvious to everyone on your team. As product marketers we need to be able to make the case for the purpose of including open source in our marketing. But you might ask it's already difficult to get alignment on goals. How can you develop the right goals to ensure how your product is being perceived by the broader community? So coming back to our launch we'll chat through some examples of goals you can consider depending on your product and the project it relies on. As you're doing this it's important to ask a couple key questions. Is your project one that's been around for a couple decades? Or has it only been around for a couple years? Is the project important for a wide variety of use cases or something that's quite niche? As you're thinking about this if your product is more well established a better type of goal it might be for you to focus on is expanding your awareness in the existing project today. Versus if it's somewhat newer a better goal for you might be to look for ways to grow the community and therefore your business as well. So what are some different type of goals you can take? The first one is social listening goals. You can look at this through a number of different lenses. One example is considering the sentiment of your project or your product being mentioned alongside the product. You can use social listening tools to see how the community is thinking about your product and talking about it. Ideally you start from a neutral to positive place and as you begin to build trust with the community it grows more positive over time if you're doing it right. Then you can also consider more impactful social listening methods such as looking at key influencers in your community such as committers or maintainers of that open source community. What you can do is create a key list of influencers in this community and like you would on launch day look at the number of press mentions of your product. You might go look at each of these influencers and whether they've been talking about your product. Ideally this list of folks should already heavily overlap with the folks you've been working with closely during the research stage that will be covered. And then another key social listening method. And one of the great things about an open source community is the fact that they have their own channels as well. Oftentimes these communities have their own newsletters they have their own flat slack forums and other types of forums. If you aren't already plugged into these it makes sense to reach out to your product and your engineering teams and ask them what are the best channels to be plugged into? And then looking into these communities and seeing again how your product is being talked about. Another key type of goal you can consider is ones that help the project grow. So one key way you might look at it is looking at how many pull requests you might have on GitHub or other similar platforms. Is it more or checking how many that happened before the launch and after? Although I do always caution folks from taking a goal like this. Important thing with the community of course is quality contributions over quantity. So if you do decide that this is something you wanna focus in on to make sure to build that nuance into your goal. Another important one is you can consider sponsoring a certain number of community events. By doing this you not only help the event be more successful and create a more interactive community event for everyone. But in addition to that you have the opportunity to potentially increase awareness of your product in these places where folks are gonna be most interested. And then finally you can tie in open source into your existing tactics. If you have a content goal for example where you're trying to create a white paper or two infographics this year or five different webinars. Something you might need to consider is whether you're gonna put that content into a gated content format. You'll have to think of course whether this makes sense for your use case. But by doing this you could include a question in the form. Where did you learn about our product? Where did you learn about this piece of content? And include any sources where someone might have learned about your product from the open source community. From here you can begin to understand how many leads, how much money, or how many folks from sales are coming in from the community. And then using all this information together you can begin to start to build a use case with your leadership about why open source is important. But as you're doing this it's important to think through each of your goals very carefully and think of course about all of the effort, the time, the money that goes into successfully completing your goals. Ask yourself, also if I'm doing this goal how does this impact the community? If I don't do it or do anything related to these tactics is the community gonna notice? Is there gonna be a negative reaction if I don't do this? Wave that cost against the cost of your development and your engineer teams and your future revenues. From here you can begin to really start to see create data points to create an argument for open source marketing. All right, final step. Your product's been out for a while. You are starting to see the benefits of all of your hard work with a growing customer base and positive feedback from the community. You have laid the groundwork for getting involved, building trust and giving back to your community. But now what? In order for you to succeed you need to think about how your project is going to grow or the project your product works with is gonna grow as well as your product. So the one of the most important things of course is to stay involved with the community because as the old adage goes trust is built over a number of years. It can be broken in a second and then it takes forever to rebuild. As a product marketer your role is to keep these best practices that we talked about today in mind as you're going through as time progresses and then your product and project evolve. As mentioned earlier you must balance how you're including open source in your messaging and marketing with how much your company is involved with these products or projects. For example, of something that could look what this could look like in practice is if your company and your project were together on a long-awaited capability for the broader community. Something you might be able to do as a result of this collaboration is work with the community to test new messaging and positioning involving this new capability. As a result of course you get better messaging and have the opportunity have also helped the community achieve this accomplishment of improving the community with this long-awaited capability. So the next thing is of course a part of creating a positive sentiment around the community is staying involved. Encourage your product and engineering teams to look to continue to give back to continue to have contributions. Of course, like I said, quality over quantity. Encourage folks to become maintainers. Have them also set up regular cadences with members of the community. All of these things together will help ensure that your product and your project are moving in the same direction. And as you continue to build this positive reputation with customers and the community it is important for people for you to look for people who are willing to advocate for your product. Having people and companies that are willing to testify to the benefits of your product will always be valuable. However, one of the key advantages of creating a product that is built on top of an open source project is its community of passionate users. If you're able to create a product that is well loved by an open source community you're able to more quickly build a loyal customer base and credibility for your product. By continuing to work with the community it should help you find advocates who are willing to act as references for your product whether it be on an event stage in a quote or in a case study. Like any other content you develop whenever you work on a customer reference it's important that you begin to pull out why open source mattered and helped with that customer's benefits and success story. Work with them to understand did they rely on a specific community capability or feature? Did they start using your product because of the fact that it was built on this open source project? Were you able to innovate with the community to create something that the customer needed? By asking these questions you are further building trust and creating content that is relevant to other project users that your product can help them while also showcasing the benefits of your product. Furthermore, if there's a member or a group of members in the community who are extra passionate about your product do what you can to activate them. See if they'd be willing to become influencers for your product. Whenever you wanna create a blog or if you wanna co-speaker on stage you can utilize these folks to hopefully speak to the benefits of your product and share it out with an audience you might not be able to reach by yourself. By doing so though, I do emphasize it is of course important to be respectful of folks time, understand what they are and what they aren't willing to do, keeping in mind that product marketer and open source marketer had. So in conclusion, marketing open source alongside your project is a marathon, not a sprint. It takes time to build trust and effort to build and maintain. Just because your product is alive does not mean that your work is done. As you begin to build out your marketing content and campaigns, your messaging and positioning you have to think about how the open source community can impact this at every stage of the way. You wanna build campaigns and begin to measure them. And by measuring them you will be able to start building a use case with your leadership as to why your product is, or open source is important to your product. And this is probably one of the most important points of this presentation. Whether you're determining your messaging and positioning, building this content, it's always important to maintain a humble tone. You are one of many contributors helping to make this technology better for all users. Finally, for looking for opportunities, finally look for opportunities to amplify the story of those who are most passionate about your product. Look for opportunities to highlight how open source has contributed to your customer's success. Work with others in the community to put your content in front of new audiences. And with that, that's the conclusion of our presentation. If you guys have any questions, Libby and I will be outside for the next 10 minutes or so. Before you guys go though, one thing that would be super helpful to us if you are willing is to just quickly take this survey, it takes two minutes. And it helps Libby and I do other presentations like this. It'll say something about an emergent day, just ignore that. Think about it in the context of this session. Thank you.