His team’s success comes from merging his publishing background with his wide-ranging, self-taught coding skills. The combination helps him keep tabs on developer communities and curate the most interesting news of the week.
As Peter will cover in his upcoming DevXCon talk, you need to understand what kind of email your audience wants to receive.
Everyone hates unwanted email, taking their attention away from more important projects. Since a developer’s important projects take even more focus, you’d think they would hate email more than the average person, but Peter busts that myth. “No, I would say it’s kind of the opposite,” says Peter. “Email is particularly good for developers.”
Peter points to mailing lists for open source projects as a long-standing example of email developers value receiving. “There’s so many people that are addicted to those really deep, dense mailing lists, like the Go Project uses them a lot at the moment,” he says. Indeed, Usenet, early networked forums were often distributed via email, and a common haunt for technical discussions.
There’s tremendous opportunity in sending developers emails that they expect to receive and consistently making sure they enjoy the contents within those emails. “No, I don’t see any indication that developers hate email. They just hate email that steals their time and makes their life worse,” says Peter.
The approach to ensure a developer doesn’t hate your email is deceptively simple: make sure everything you send makes a developer’s life better.
At Cooper Press, it all starts with the audience, something familiar to anyone doing developer relations. While Peter thinks you can get away with a broad audience definition, most of his publications focus on languages or specific technologies. The specificity helps them gain—and keep—the developer attention.
“From our point of view, it’s quite easy because we are only sending email to people that very explicitly signed up to us,” Peter says, “They want weekly emails about XYZ, and so, I think that’s actually our key advantage is they signed up for it, they want the email.”
Understanding the audience—and what the “XYZ” is they want—is where Peter and anyone in developer relations should start. Otherwise, you’re just tacking on a newsletter on top of your developer product, he says. In many cases, companies will simply subscribe everyone who signs up for an account. With that frame of reference, the topic ends up being about the product, rather than the problem that initially motivated the developer to try it out.
So, make sure you start with what your audience wants to hear about via email on a regular basis. “If you don’t know who you’re targeting and who you’re trying to reach,” says Peter, “then you don’t really have a newsletter.”
Once you understand the audience, it’s time to create something they want to read. That doesn’t mean pushing your product or updates, unless that’s the primary reason they’ve subscribed. Likely, they’ve come for the topic interest you share and the voice with which you talk about it. In other words, you need to treat your newsletter as if it’s a separate content property—your own developer publication.
While it’s not exactly a formula, Peter shared three general approaches that have combined to work well with his newsletters:
Every community has a place they’re already having discussions. For some that might be Hacker News, a sub-Reddit, or forum. There are also well-respected members of that community you should follow especially closely—think DHH for Ruby. Your newsletter should contain the very best of discussions, news, and viewpoints from the community in the last week or month.
Peter’s interaction with the community is one of the ways he can bring valuable content to the newsletter. “We’re familiar with a lot of bloggers who perhaps aren’t always discovered,” Peter says. “We also have people who reach out to us, know what we’re doing, and know that we’ll like it.” Some of those pitches are exclusives, shared first in one of Peter’s newsletters. That’s the power of thinking like a publication.
Knowing your audience and thinking like a publication means your newsletter won’t be right for everyone. That’s ok, as long as you can reach enough developers to make sense for your business. “If you have a really expensive product, you might end up with a newsletter like 50 people,” Peter says. For some early enterprise-focused startups, that might be fine, assuming it’s the right 50 developers.
For most of us, it will take higher numbers to achieve our company’s goals. In that case, “you have to think about it as a publisher, like we would,” Peter says. “What would someone subscribe to? Then work back to how that relates to your business.”
Finding the topic that speaks to your audience is the key piece of this strategy, which explains why Cooper Press sends a dozen newsletters instead of one massive email. “We’re kind of blessed in that we almost don’t have to be too interesting because we’re just covering one tiny topic and if you’re interested in that topic, we’ve got it there.”
Peter will be sharing more lessons learned from running these popular newsletters in his talk “Writing newsletters and sharing content that developers will enjoy” at DevXCon 2018 which runs in San Francisco over June 4 and 5.
All the fun stuff happens with shiny new tech, right? Nah. You can get audiences excited about older tech, if you serve them well.
Are dev rel teams just here to make everyone feel good about using a technology or is there a deeper responsibility?