Building a Dev Content Strategy that survives Monday

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:

• Where do the ideas come from?
• What kinds of content can we make?
• Who is each piece for?
• And finally, how do we decide what to prioritise?

Step 1: Get all the ideas on the table

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:

• Voice of the Developer. What are developers actually telling us? Forum posts, GitHub issues, event conversations, survey data, DMs. Not what we assume they want.
• Goals. What are we trying to achieve as a team and as an org? If a piece of content doesn't ladder up to something we've committed to, it's worth de-prioritising.
• Go To Market. What's launching? New devices, SDK releases, Appstore APIs. If product is shipping something, developers will need help using it and we need to plan for it.
• Walk the product. What did we find when we built with it ourselves? Friction we hit before it becomes a developer pain point is important to mitigate.
• Our own experience. What do we think developers need, based on years of doing this? This one's the most subjective and the easiest to over-index on, so we treat it as one voice among five, and never the loudest one in the room.

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.

Step 2: Pick the right format for each idea

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:

• If it's visual, show it → Video. Anything with a UI, a device interaction, or a screen / IDE flow defaults to a video tutorial or a livestream / office hours. A tutorial telling someone to "press left, then OK, then wait for the next generic screen" is fighting the medium.
• If it's a series of decisions, write it → Written. Architecture choices, trade-offs, and "why this and not that" pieces belong in a technical tutorial or a thought leadership article. Readers can scan, jump around, and make informed decisions.
• If they need to build it, make it hands-on → Hands-On. When the payoff is "developer has a running thing on their machine", this becomes a code lab, a sample app, or a boilerplate / template. Written explanation on its own doesn't cut it. In-person versions of this become workshops.
• If AI is doing the work, make it AI-shaped → AI. If the developer is going to be pair-programming with Claude or Kiro to solve this, the content has to fit inside that workflow. This is where agent skills, prompt libraries, MCP server configurations, and AI-embedded tutorials earn their spot, not sit alongside as a novelty.
• If it's a moment, make it a moment → Written + Social. Launches, milestones, community wins, big learnings. Blog posts on developer.amazon.com, case studies / spotlights, and social content on LinkedIn and dev.to. Optimised for reach and timing, not depth.

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.

Step 3: Map each idea to a stage of the developer journey

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?

How we decide what to create

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 😉.