I spend a lot of time with dev tool and data companies. I think I’ve more or less banished myself to a life of working in the space, no consumer products for me. In that world a common topic that comes up amongst marketing teams is how do I get my team to contribute to content? Sometimes the person already has an idea of how they want the team to jump onto the bandwagon of their plan, sometimes they’re entirely open minded. I won’t get into pros and cons of various approaches here, rather after sharing some of my approaches in one on one settings I thought it could be useful to share more broadly here.

Turn emails into blogs

I’m a big fan of high quality content when it comes to developer focused products. Yes, you can publish x vs. y with FUD and get some traction with it. You can publish high level customer stories that don’t get down into the details. But publishing high quality deep technical content that other engineers appreciate gives you a huge head start in getting buy in from your customers. The best thing about much of this type of content is you likely already have it sitting within your organization.

Engineers spend a lot of time being thorough and articulate in their emails to their peers. If you see a well written email from one engineer to the engineers@ list and then others chime in either with questions, follow-up, or praise then it’s likely a great candidate for a blog post. We recently had one of these at Citus where another engineer replied with “Nice blog post :)”, a few weeks later we had a post for the rest of the world to read.

The thing about emails though is the engineers won’t usually take and turn them into a blog post. Get a technically minded person that likes to write and put some framing around it, pull out relevant details, and collaborate with the engineer. I’ve often found going from one of these emails to a fully published blog post can be anywhere from 2-8 hrs (including reviews and edits).

Beginner mindset with tickets

As your product people and engineers spend more and more time with the product they become numb to the cool feature from 2 years ago. That initial awe is just expected. Yes there are new advanced features and tech that is being built… but most of your users aren’t the advanced power users. You still need to speak to the people just now onboarding and discovering you.

The best way to maintain this beginner mindset is to capture the interactions with those that are newer to your product. Over the years I’ve made the practice of cataloging support tickets and the type of issue encountered. Any time the same issue is seen several times it becomes a candidate for a blog post or at the very least being clearly documented.

Make sales engineering obsolete

Your sales engineers spend weeks with customers helping them implement complex solutions with your product. In a lot of cases they get really good at helping re-implement a similar solution over and over. Similar to your process with support tickets they’re a great source to take what they’ve done a few times over and turn it into a blog post.

Usually after the first time implementing they have some ideas but there are rough edges. The second or third time they’ve helped a customer implement a particular approach it becomes a candidate for a post.

Training and Documentation don’t have to be siloed

I’m a big fan of not doing anything for one reason. You should absolutely document your product, and if you need to do training to support customers go for it. But that doesn’t mean those bits of content can’t be re-used. Documentation is a great place to take the factual how something works and then give it some narration of the end to end experience in a blog post.

The process

If you’re asking the question how do I get more good content out there, then you’re not leveraging the content you’re already sitting on top of. Though perhaps equal is getting a process in place. A few tips for that:

• Don’t blanket ask to a list for volunteers, ask individuals and about specific posts. If you see a great email, respond and ask if you can work with them to get it turned into a blog post
• You’ll need to navigate the process, and make sure to have a process
• Separate messaging/flow from grammar
• My typical process is: outline -> draft -> feedback from 2-3 on draft -> finalize draft -> feedback from 4-5 (often some external parties) -> publish

What’d I miss?

Have other tips that are key to the process? Know of other places where content may already exist but isn’t being leveraged? Would love to hear your thoughts.