This article aims to share some knowledge and specific action items to help open source creators understand product marketing as a concept and how to bootstrap it on their own until a project reaches the next level of traction.
What is product marketing?
Product marketing for COSS is materially different from product marketing for proprietary software and from general marketing practices like ads, lead generation, sponsorships, booths at conferences and trade shows, etc. Because the source code is open for all to see and the project's evolutionary history is completely transparent, you need to articulate—from a technical level to a technical audience—how and why your project works.
Using the word "marketing" in this context is, in fact, misleading. It's really about product education. Your role is more like a coach, mentor, or teaching assistant in a computer science class or a code bootcamp than a "marketing person."
Proprietary software products rarely need this level of technical education because no one can see the source code anyway. Therefore, these companies focus on educating their audience about the product's business value, not its technical advantages.
To build a successful open source project (and any commercial product that may be derived from it), you must educate your audience on both its technical details and business value.
While this may sound like extra work, it's an advantage inherent to COSS because so much buying power for technology products is shifting to developers. They care deeply about technical details and want to see and understand the source code. Being able to learn, appreciate, and have confidence in a project's technical design, architecture, and future roadmap are key to its adoption.
Also, developers often treat open source technology as a way to scratch their technical itch and stay sharp in a fast-moving technology landscape. It's an audience that yearns for education, above all.
Being able to speak to an audience that has these goals and desires is what product marketing and education in the COSS context is all about.
How to bootstrap product marketing
So you (or maybe one or two other engineers) are laboring away to create your open source project, likely in the evening after your day job or on the weekends. How do you bootstrap some effective product marketing on your own?
I recommend a three-step process to yield the best return for your time:
- Peruse online forums
- Write content
- Do in-person meetups
Online forums
Rummaging through forums—from general ones like HackerNews and Reddit to ones like Discourse or Slack channels geared to projects that are closely related to what you are building—is a great way to figure out what questions developers have in your space. Starting with this step is less about inserting your project into the discussion and more about gathering ideas on what you should focus on when putting together educational materials about your project.
Effectively, what you are doing is akin to "listening to your customer."
Let's be honest; you already spend a lot of time on these forums anyway. The only change is one of mindset, not behavior: Have more focus, jot ideas down actively, practice absorbing critiques (you may see threads critical of your project), and develop some intuition about what developers are thinking about.
This step assumes you don't already have an active community where developers are asking questions directly. The long-term goal is to build your own community, and good product marketing directly helps with this.
Write
Now that you have gathered some ideas, it's time to produce some content. Compared to formats like videos and podcasts, writing is the highest-leveraged medium. It has the best long-tail benefits, is most suited for ongoing reference material, and can be most easily repackaged into other mediums. Another factor: open source has a global audience, many of whom might speak English as a second (third, or fourth) language, and written content is easily consumable at a person's own pace.
Focus your writing on three categories that answer three fundamental questions:
- What problem does your project solve? In other words: Why should it exist?
- How is the project architected, and why is it done that way? Is this a technically well-designed solution that has potential, thus worth investing time in?
- How do I get a taste of it? How quickly can I get some value out of it? This is crucial to reducing your time-to-value metric to the shortest amount possible. For more on this topic, please read my article A framework for building products from open source projects.
A smart way to begin is by writing three blog posts, each addressing one of the three points. The posts should be canonical to your specific project so that repackaging them into different formats (e.g., slide decks, Quora answers, Twitter threads, podcast interviews, etc.) for different channels should be straightforward.
After you publish the posts, work the materials into your GitHub, GitLab, Bitbucket, or other repository along with the project's documentation. This is important because your public repo will likely be the face of your project for a long time, even if also you have a dedicated website. A repo with strong educational content will go a long way in building your social proof in the form of stars, forks, and downloads and may even yield some contributions.
One note on writing: Be patient! Your words likely won't go viral overnight (unless you are a celebrity developer). But if the material is educational, useful, and accessible (no need for fancy language), it will draw attention to your project in time. You do your part, and let Google's SEO algorithm do its part.
In-person meetups
With a few posts out in the wild, the next step is to find an in-person meetup where you can give a presentation about your project using your writing as foundational material to build a compelling talk.
You may wonder: "Why? Isn't doing something in-person the biggest time suck? I'd rather code!"
True. You are not wrong. I recommend this step specifically at this moment, not earlier or later, because you'll get feedback on your output more quickly than what the internet can give. Comments and feedback on your posts will trickle in, but giving a talk at a meetup, taking questions, and chatting with attendees afterward over pizza is valuable and immediate.
The goal is not to shamelessly pitch your project (reminder: you are an educator, not a marketer), but to listen for the kinds of questions you get when you put your project (and yourself) out there. Another benefit is that it gives you practice delivering presentations, which will become important as your project grows, and you need to present in higher-stakes situations, including large conferences, demos with prospective users, etc.
I know this may not be practical if you don't live in a tech hub where meetups are aplenty. You may want to look for groups that are open to doing virtual meetups via video or work this into your existing travel plans. (But don't fly across the world to talk at one meetup.)
In-person meetups can feel scary. Public speaking is not for everyone, and it's a legitimate source of fear. My main tips: Just think of yourself as free entertainment, lower your expectations, don't overthink it, and offer yourself up to meetup organizers proactively because they will love you! Having been both a presenter and a meetup organizer, I know developer-focused meetups are very hungry for good technical education.
Final words
There's a lot more nuance, strategy, and sheer work to effective product marketing, but I hope this post gives you enough guidance and specific action items to bootstrap it. Ultimately, you should still spend the bulk of your time building your technology. And if you have some revenue or funding, it's worth hiring someone who has deep expertise in product marketing, even as a part-time adviser.
Frankly, product marketing talent is hard to find. You need someone with both the technical chops and curiosity to learn about your project on a deep level and the communication skills to compellingly tell the world about it.
This article originally appeared on COSS Media and is republished with permission.
