Carving the Turkey

One of the things I learned early on in my DevRel career is that you’ve got to be creative when it comes to content production. Starting from scratch for every blog post, video or conference talk means that you can only produce 1-2 pieces of deep content per month.

Fortunately, I’ve worked with some great advocates that taught me how to “carve the turkey”. Just like there are lots of different cuts from a turkey, there are ways to get more out of a single piece of content.

An Abstract Workflow

I start each project with the intention to produce at least three pieces of content - internal documentation, a public blog post and a demo video about the feature. Many projects will lead to more pieces of content than this, but three is the minimum I aim for.

For larger projects, you might end up with live streams and a conference talk in addition to your documentation, blog post and videos. This all depends on the team you have and how much emphasis you’re putting on content

Here’s the process I go through when working through a project:

• (Offline) Read the basics + build up a list of docs / cheat sheet to use later
• (Live Stream, optional) Try out the things you’ve learned. Make mistakes, it’s ok! We’re all learning together at this point. These aren’t expected to be polished.
• (Documentation) Write user facing documentation that combines the generic understanding of your topic with things that are specific to your business
• (Blog Post) Write unique content about the topic. It could be something you struggled to understand, or an innovative application of the technology. It may or may not mention your product.
• (Videos) Record short demo videos to show off the capabilities of your product. Try to explain both why and the how these things work. These can be used for multiple purposes (with some editing), including:
  • Sales enablement
  • Social media promotion
  • Product capability videos on YouTube
  • Documentation
• (Conference Talk, optional) Take what you’ve learned and combine them in to a 20-40 minute conference talk. Here are a few suggested frameworks:
  • Introduction to X
  • A deep dive in to X
  • X for Y Audience
  • Extending X
  • Real world X use cases

This follows a pattern that’s common across most of my projects:

• Learn
• Try
• Document
• Apply
• Teach

It’s hard to imagine what the above might look like for your project if you’ve never done it before, so let’s take a look at a project that I’m currently working on.

A Real World Example

Context: I’m the product manager for Kong Ingress Controller for Kubernetes. As part of my role I’m learning about new Kubernetes APIs

I’m currently learning about the Gateway API in Kubernetes, which is an area that I’m not too familiar with. There’s a lot of reading involved, and a lot of testing things out to see how it actually works.

Here’s a rough list of things I need to do to be successful:

• Read the Gateway API specification
  • Understand the component parts
  • What are the differences between the Gateway API and Ingress API?
• Try out the most common parts of the Gateway API
  • I think this is HTTPRoute and TCPRoute from prior conversations
• Document how Gateway API works with Kong
  • How to add a service and a route
  • How to add an authentication plugin
• Provide Gateway API examples for the top 5 Kong use cases
  • Prebuilt demos for Sales Engineering org
• Talking points for the sales team targeting Kubernetes accounts

Looking at the above list, I can start to think about what content I can produce for each stage:

That’s a lot of content for something that could have resulted in zero pieces of public facing material. It would have been easy to spend a week reading everything and making private notes. Instead, we’ve produced 13 pieces of content which help your team mates, your customers, and you!

After all, the best way to learn is to teach.