How Pusher Scaled Content Production and SEO for Developers

This post by François Dufour is part of our series on Product-Led Growth Playbooks, an emerging field that pushes the boundaries of conventional sales, marketing, and customer success. In the series, we share insights and advice from leaders who have built successful PLG businesses and offer specific playbooks for founders running high-growth software startups targeting software development teams today.

I met Sylvain when he was leading marketing at Pusher. I was really impressed with the technical content factory he built and scaled from the ground up, and its outsized impact on Pusher’s acquisition engine. Sylvain was kind enough to chat with me and talk about the keys to writing, scaling, and iterating developer content.  

How To Crawl, Walk, Then Run. And Associated KPIs

Phase 1: Build Muscle Through Regular Publishing

Starting and scaling content is a bit like starting a new workout regimen. You can waste your time wondering if you have the right shoes for the gym, or you can go to the gym and start your workout.

Write at least one post a week. Don’t get hung up on readership metrics at this stage. Your goal is consistent publication so you get into a rhythm and learn. Consistency is the most important metric at this stage. Once you’ve published weekly for a couple of months, do a worked / !worked post mortem, review your traffic and traffic source metrics, and iterate accordingly.

Phase 2: Attract and Track Traffic and Leads

At this phase, you want to tailor your content strategy further to show the power of your product and address the pressing interests of your community. Your focus should be on traffic generation first (sessions, page views, organic and referral traffic) and then on leads, and boosting high-touch activities like demo requests. Make sure you’re noting traffic sources, page paths, and page depth per session.

Phase 3: Keep Scaling

When you’re attracting visitors, sign-ups, and leads, keep going. Focus then on your success with active registrations and paid users. Make sure to make use of cross-linking to route users from one relevant post to another and keep the flywheel going.

Content is a Big Investment with a Massive Upside

Quality reigns supreme in technical content. While some might think a developer can write a high-quality technical blog post in an afternoon, that would be vastly underestimating the work and care involved in producing an impactful post.

Here are a few examples of Pusher blog posts beloved by the developer community

• Golang’s Real-time GC in Theory and Practice
• Pusher Realtime Reddit API
• Track Pizza in Real-Time with Pusher and Google Maps

“You’re writing a blog, you’re writing code, and people will use that code. So you need to make sure it works.”

Your quality of code and narrative dictate the quality of a developer’s experience.

“You’re writing a blog, you’re writing code, and people will use that code.  So you need to make sure it works,” says Sylvain. From Github repos, to sample code, and the instruction in-between, everything counts in a blog post.

At Pusher, Sylvain kick-started content production and blog post authorship himself. He wanted to free up Pusher’s developer relations team to speak at events, go to meetups, and have more time to work on content ideas rather than having to focus full-time on writing.

But, content is a full-time job. To scale up content production, Sylvain started and eventually grew a team of 100 external technical writers and contributors. With that arsenal of talent, Pusher was publishing roughly 30 posts per month.

How to Select What Developer Content to Write

The first step in assembling a content arsenal was knowing what to write about. You need to carefully select and tailor content to a particular tech stack, programming language, and audience of programmers. Here are critical factors and steps to consider when selecting what to write.

• Audience: Decide who you’re writing for. You can’t be everything to everyone. Focus on who your audience is whether that’s mobile developers, front-end engineers, or full-stack programmers.
• Use Case: Determine what your audience is using your product for. Focus on solving a users’ problem with technical expertise and a clear narrative.
• Start with the Outcome: Think of the moment after a user reads your post. What’s their ideal outcome? What were they able to fix or figure out after reading your post? When sourcing new blog posts, start with the desired outcome and work backward from there to inspire new content ideas.
• Plug into the Matrix: Once you find a sweet spot at the intersection of audience and relevant use case, map out those critical intersections to find more. Organize your new content ideas by desired outcome, persona, tech stack, and use case.
• Let’s take this post as an example, Building a Slack clone using Laravel, Tailwind CSS and Vue.js, and examine the target audience:
• Developer Hook: Building a Slack clone
• Programming Languages: CSS and PHP
• Interest Groups: Open Source, Full Stack Devs
• Tech: Blade, TailwindCSS, Vue.js, Laravel,
• Track and Iterate: When you see results from “plugging into the matrix”, use those as guideposts for your next batch of content. If you see an outsized interest in one area, that could be a rich well of content for your blog.

Tailor Your Content to Become Domain Dominant

Once you’re producing content, you can further refine its impact by examining who your new, expanding audience is and what they’re interested in.

For example, at Pusher, Sylvain found they had a high volume of users who were interested in Ruby content. So, they dove deeper into how they could be helpful to Ruby developers. That resulted in a flywheel effect, deepening their relationship with the Ruby community and also enhancing their SEO-power in terms of ranking for Ruby content.

Pusher amassed a wealth of Python, Ruby, and JS content, from being helpful to those developer communities and addressing their needs. That in turn gave them the platform and SEO ranking to reach a larger portion of the community.

How to Scale Your Developer Content Production

Sylvain wanted to scale the quality of content alongside the quantity of content. To do just that, he hired a community of contributors, predominantly subject matter experts who were active in a particular programming language or framework.

“Exposure and learning opportunities motivate developers more than pay or metrics.”

Pusher paid each freelancer per post, with added escalating incentives if a post achieved a certain page view metric within the first 30 days of publication.

Sylvain learned that exposure and learning opportunities motivate developers more than pay or metrics. The competitive pay rate per post attracted writers, so did the surging profile of the blog. But what kept writers coming back was the chance to join a community of elite technical developers writing for and educating fellow developers.

Many contributors to Pusher’s blog saw writing for Pusher as a “great signal to the community,” says Sylvain.

Here’s how Sylvain managed the stable of developers producing content for Pusher:

• Pitch: Sylvain’s team reached out to subject matter experts who could cover specific use cases. They offered competitive pay rates for publication as well as access to the larger Pusher writing community and swag to go along with it.
• List: Pusher kept a running Trello board of content ideas they wanted to turn into blog posts and, as mentioned earlier, organized that content into a matrix. They could easily find out, for example, what Ruby content addressed a specific use case they could cover and assign to freelancers at any time.
• Connect: Sylvain’s team at Pusher created a Slack channel for freelance writers on content. This gave the Pusher team an easy way to pitch new ideas, follow up with writers on edits, and keep a finger on the pulse of their growing writer community.

At Pusher’s peak, Sylvain’s team of 100 external contributors managed by an in-house team of a couple of full-time editors were posting nearly daily. They published ~30 posts per month helping bring Pusher’s monthly traffic from roughly ~8k to ~600k.

The Writing Process: How to Move from Idea to Promoted Blog Post

The most critical process in that content engine was the pipeline that helped writers move from idea to published work — and all in about two weeks for each post.

“You spend weeks working on a piece, spend some time promoting it too.”

• Draft: After a writer is assigned or picks an idea they should draft the post. This first draft is simply the scaffolding for the piece, it does not feature production-ready code. It should include an abstract detailing the focus of the piece as well as dependencies and frameworks used.
• Review: A full-time editor reviews the draft to check for grammar, marketing CTA consistency, and tone of voice. At this point, there is still no code to review.
• Iterate: The writer takes another pass at the draft, this time writing code that an audience of developers will use when going through the piece.
• Re-Review: The in-house editor reviews the latest draft, checking the code and assigning code reviewers to make sure there are no errors and the piece is ready for publication.
• Pre-Publish Check: The editor checks critical elements like SEO description, tags, titles, url structure, and more before uploading the piece into the CMS and scheduling it.
• Notify and Promote: Once the piece is live, the writer is notified and the piece is promoted both by Pusher, and the writer. Sylvain pointed out, “You spend weeks working on a piece, spend some time promoting it, too.” Typically, Pusher would encourage their writers to promote their posts on their personal social media accounts. Pusher would also put a few hundred dollars of ads behind posts on Facebook for the first 30 days, and share the content across Stack Overflow and Quora, as long as it was directly relevant to a user’s question. “If you can’t provide value, shut up,” says Sylvain.

Success Is In Consistency. Write For Your Old Self

As Sylvain notes, you shouldn’t let the perfect spoil the good. Start publishing in small but consistent waves. And don’t wait for a post to be perfect. Sylvain recommends that you ask yourself this question to decide whether it’s ready to publish: “Would the me from 3 or 5 years ago have benefited from this post?” i.e. remember that you are writing for people who are not as far along in the coding journey as you.

Then, keep riding the momentum of that consistency and start to scale. Soon, you might have yourself a successful content factory, just like Sylvain’s.

Sylvain’s success founding and growing Pusher’s content efforts led him from Marketing Manager to COO to CRO. That’s the power of quality content and a quality content strategy in the right hands. We hope Sylvain’s advice gives you the power to transform your content marketing.

‍