Open Source Creator Series (5 Part Series)
Recently, we launched the Open Source Creator Series to help you – the technology creators -- understand and bootstrap some of the essential non-technical elements of building a successful project. (Part 1 of this series was on licensing fundamentals by Heather Meeker.)
In this post, we will focus on Product Marketing.
About every other week, I get questions from an open source project creator or a new founder of a commercial open source software (COSS) company on “how do I do product marketing?” Implicit in that inquiry lies some more foundational questions: “What the hell is product marketing? How much time should I spend on it?”
My goal with this post is to share our knowledge and some specific action items to help you understand “product marketing” as a concept and how to bootstrap it yourself productively until your project reaches the next level of traction.
Product marketing, in the COSS context, is materially different from product marketing for proprietary software and general marketing practices (e.g. ads, lead generation, sponsorship, booth at conference, etc.). Because the source code is open for all to see and the history of the project’s evolution is completely transparent, you need to articulate how your project works and why from a technical level to a technical audience.
Having the word “marketing” here is in fact misleading. It’s about product education. Your role is akin to a coach, mentor, or a teaching assistant in a computer science class or a code bootcamp -- not a “marketing person.”
This level of technical education isn’t something proprietary software products tend to need, because no one can see the source code anyway. Thus, these companies focus exclusively on educating its audience on the business value.
To build a successful open source project (and any commercial product that may be derived from it), you must educate your audience on both the technical details and business value.
While this may sound like extra work, it’s an advantage inherent to COSS because so much of the buying power of technology products are shifting to the developers. They care deeply about technical details and want to see and understand the source code themselves. Being able to learn, appreciate, and have confidence in the technical design, architecture, and future roadmap of a project is key to its adoption.
Developers also often treat the use of open source technology as a way to scratch their technical itch and stay sharp in a fast moving technology landscape. It’s an audience who yearns for education above all.
Being able to speak to this audience with these goals and desires is what product marketing/education in the COSS context is all about.
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 propose a three-stage process that could yield the best return for your time:
- Online Forum
- In-Person Meetup
Rummaging through forums from general ones like HackerNews and Reddit, to Discourse or Slack channels of 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 directly, but 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, we already spend a lot of time on these forums anyways. The only change is 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 is assuming you don’t already have an active community, where developers are asking questions directly. The long-term goal is to build your own community, which good product marketing directly helps with.)
Now that you have gathered some ideas, it’s time to produce. We recommend writing as the highest leveraged medium versus other forms like videos, podcasts, etc. This is because writing as a format has the best long-tail benefits, is most suited as reference material for people to go back to repeatedly, and can be more easily repackaged into other mediums. Also, open source has a global audience by default, many of whom might speak English as a second (third, or fourth) language, thus written content is most easily consumable at one’s own pace.
Your writing should focus on three categories that answer three fundamental questions:
- What problem does your project solve? (Answers: why should it exist?)
- How is the project architected and why? (Answers: is this a technically well-designed solution that has potential, thus worth investing time in continuously?)
- How do I get a taste of it? (Answers: how quickly can I get some value out of it? NOTE: This is crucial to reducing your time-to-value metric to the shortest time possible. For a detailed elaboration on this topic, please read my post on deriving commercial product from an open source project.)
Your first set of writing could simply be three blog posts that address the above three points. These posts are canonical to your specific project, thus 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 them, work the materials into your GitHub (or GitLab, Bitbucket) repos 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 you have a dedicated website as well. A repo with strong educational content will go a long way in building social proof in the form of stars, forks, downloads, and 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 over time. You do your part, and let Google’s SEO do its part.
With a few posts out in the wild, the next step is to find an in-person meetup that you can give a presentation about your project, using your writing as foundational material to build a compelling talk.
You may ask: “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 want quicker feedback on your output than what the Internet may give you. Comments and feedback on your posts will trickle in, but giving a talk at a meetup, taking questions, and chatting with attendees afterwards over pizza is valuable and immediate. The goal is not to pitch your project (reminder: you are an educator, not a marketer), but to listen for what kind of questions you get when you do put your project (and yourself) out there. It also has the added benefit of giving you practice delivering presentations, which will become important as your project grows and you will need to present in higher stake situations, e.g. large conferences, demos with prospective users, etc.
I know this step 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 plan. (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 a legitimate source of fear. My one mental state tip: just think of yourself as free entertainment, lower your own expectations, and offer yourself up to meetup organizers proactively and they will love you! Don’t overthink it. Having been both a presenter and a meetup organizer, I know how hungry developer-focused meetups are for good technical education.
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 already, it’s worth hiring someone who has deep expertise in product marketing, even as a part-time advisor.
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. If you have specific questions on how to hire for product marketing, feel free to contact us. We are happy to help!