With AI making it easier than ever to publish anything we're all drowning in content and a lot of the time it's noise. Additionally, developers, more than most audiences, can smell 'slop' a mile away, and once you've lost their trust, you don't win it back with a louder headline. So our job in DevRel isn't to add to the pile. It's to earn enough trust that when we do publish, developers actually stop and read. Which leaves the question:
How do we build a content strategy that earns developers' trust?
That's exactly what I had to ask myself when I took over the developer content strategy for my Developer Advocacy team at Amazon. And as the saying goes, nothing good in life is easy 😂. It wasn't just about writing quality content. The issue was that our developer audience is enormous: multiple Appstores (Amazon Appstore, Ring Appstore, Alexa Appstore), two Operating Systems (Fire OS and Vega), and a growing set of form factors (Fire TV, Fire Tablet, Echo Show, Ring, Bee). Now combine that with the fact that each one of those surfaces comes with its own SDK releases, platform quirks, and tsunami of inbound content ideas: product teams wanting help with launches, developers dropping feedback, marketing needs for newsletters. Not to forget keeping on top of the latest trending AI tooling we need to weave in.
Overwhelmed was an understatement!
Honestly, my first thought was: is it too late to become a farmer? 😅 Jokes aside, I needed a way to sort out the mess, so I started with a few questions:
Before deciding what to make, we needed to know what content themes we had. And by theme I mean an idea or topic, not a finished piece of content yet, something like Improve performance on Vega or getting started with our MCP server. So I started by collating where those themes come from. Every theme in our backlog has to trace back to at least one of these sources:
With the sources named, I can look at any sprint's backlog and quickly check we're covering the ground. If any of those sources are quiet, that's worth a conversation before we create anything else.
Once we had a list of themes, the next call was to figure out what shape each one should take. This is where teams usually reach for their favourite format by default (we're a video team, we like blogs, someone loves workshops), and I wanted to stop doing that.
So the first thing I did was write down every format we can make, roughly how long each takes, where it gets published, and who it's really for.
With every format on the table, picking one for a given theme becomes a judgement call, but not a random one. Here's the rough rule of thumb I use:
None of these are hard rules. Plenty of themes get more than one format (a launch might get a blog, a video, and a sample app), but the rule of thumb makes the first format choice feel less arbitrary, and it forces us to justify when we depart from it.
Now we know what the theme is, and what shape it'll take. The last question was where in the developer's journey it belongs, because this is how we decide where to target activation.
Every developer moves through roughly the same stages when they land on a new platform. They discover it, evaluate whether it fits, actually build something with it, and (hopefully) ship, grow, and monetise. If all our content lives at the "discover" end, developers get excited and then bounce because there's nothing to help them build. If it all lives at the "build" end, no one finds us in the first place.
So we tag every theme with the stage it activates. It's not a strict rule, more of a sanity check. When we're staring at a quarter's worth of ideas, we ask: is this balanced across the journey? Or are we accidentally shipping five discover-stage pieces and nothing that helps someone actually ship?
Once every theme has a source, a format, and an activation stage, deciding what to prioritise stops being a vibes exercise. What we're left with is a well-curated backlog with a good spread across sources, formats, and journey stages, a lot less overwhelming than the pile I started with. And when a new idea lands, it goes through the same three passes. Anything that clears all three joins the backlog and gets assigned out during sprints. But ultimately it gives me an answer I can back for every stakeholder in the room - product, marketing, my team, and the developers themselves 💛.
And on the note of Voice of the Developer, if there's anything you've been hoping we'd cover on Amazon devices, drop it in the comments and I'll add it to the backlog 😉.