🍐 #77: Growing traction in open-source, how to tell a debugging story, and my favorite user research question

Hey,

If you are ever in Vienna go to one of the vineyards on Nussberg. Took this photo of a pear tree while there 🍐. The photo is horrible but the place was awesome ;)

This week on the agenda:

• Tips for growing traction in open-source with Zeno Rocha founder of Resend

• My favorite question to ask to nail the core messaging

• How to tell a debugging story from GitLab

• + a few bonus links at the end

Before we start a word from our sponsor:

Why advertise on TLDR?

A friend of mine runs one of the best dev communities I know. They wanted to drive more event signups.

This is what he has to say about advertising in TLDR newsletters:

They have newsletters (with over 4 million subscribers) for AI/ML, DevOps, Webdev, Security, and a few more coming soon. Worth taking a look.

Learn more about running your first ad campaign.

Developer marketing insights

1. Tips for growing traction in open-source with Zeno Rocha founder of Resend

See the full episode on YouTube but here are my learnings:

• When launching, spend 1 week on the library and 3 weeks on the website, and the GitHub Readme. Nail the information flow, the readme sections, how easy it is to get started, how to ask for help, what code to copy-paste,

• Solve for this job to be done: “As a developer, I want to get it up and running now. What can I copy-paste and get started as quickly as possible”

• Goal to keep in mind: you want devs to say “I get the use case, I get how to inject it to my project, and scale as the project/usage grows”

• “Master plan”: he shared a very re-usable game plan: "Launch open-source project around email, establish ourselves as experts around email, launch a SaaS around email”

• Vision vs positioning/messaging: your vision is so much bigger than the first step you communicate to the dev community. For Resend, it started with only devs + only transactional emails. Over time, it extended to also marketing emails. And the vision is so much bigger than this.

2. How to tell a debugging story from GitLab

One of the best types of developer content is a debugging story.

"What is X" or "How to solve Y" work in some situations, especially when you focus on SEO distribution. But a good debugging story is something that even senior devs want to read.

This is an old article from GitLab and is such a good example of that format:

• Set the scene: Say what happened, what results you managed to get, and introduce the problem. Skip the fluffy intro and invite devs into the story

• Go deep into the problem: show what happened and go into technical details. Address the obvious solution that unfortunately didn't solve the problem. Showing profilers, charts, UIs. Make the problem more concrete.

• The journey: explain what you tried, how it failed, and what you learned, go technical and detailed. Take people on that journey

• Close the loop: Close with a win, show the improvements/results, summarize what you learned

The downside of using this format is the same as with most good developer content. You need a real situation, explained by an actual dev in a technical language.

See more dev tool blog examples ->

3. My favorite question to ask to nail the core messaging

When I start working with dev tool startup founders, one of the first things I do, is go to the website and read the header H1/H2 sections. Then I ask them to explain the product.

8/10 times those two explanations are completely different.

The explanation they give me, while wordy sometimes, is way more concrete and clear than the slogan-like header copy. 

Why is this important?

Most of the developers who hear about you, go to your website and read the header.

Some of them read on, some of them go to the docs, and some of them leave the site and never come back. But most (or all) will read your header. 

It is in your best interest to let them learn something about your product that they can remember and repeat to their dev friends when the conversation around your problem space comes.

If you go for some flavor of the “Build better software faster” you can be certain that they won’t repeat that.

How do you fix it then?

Ask this question: 

Doing that will show you how real devs talk about your product. What they think is important, differentiated, real. 

Then you take common themes from the answers and convert them to the message on your website and other assets.

Ok, but who do you ask?

The closer you get to your ideal developer audience the better.

I suggest going in the following order:

• Developers who activated in your product

• Developers who converted and retained

• Developers who signed up for your product 

• Developers who you think are your target audience

• Developers from your devrel team

• Developers from your engineering team

• Developers from your founding team

Why are activated users better than converted and retained?

Because activation typically happens within 7-30 days after signup.

Those developers not only built a habit around using your product but also remember how the world looked before they used it. 

So if you’re having trouble explaining what you do to your dev audience start asking this question whenever you can. And build your messaging from those answers.

Read other tips like this ->

Need more developer marketing insights?

1. Work with me 🍐

Every week I have a few slots for Workshops (60-minute session on whatever you want), Teardowns (audit+suggestions for your homepage/messaging/ads etc), and longer-term Advising.

See how it works ->

2. Bonus links to check out

• 📰 A DevTool Sales Exec’s Guide to Getting Warm Account Entries 

• 🧵 My learnings on cold email – in case helpful to any other founders : r/ycombinator

• 📰 Growth for developer products 

3. Join our Slack community

1800+ dev tool CMOs, heads of growth, product marketers, and other practitioners talking shop.

Check out marketingto.dev ->