Developer advocacy is usually framed as communication: talks, demos, tutorials, launches, community work, and product explanation.
That is only part of the job.
The strongest developer-facing work usually starts earlier, in building something real enough to expose the product’s rough edges.
That is where credibility comes from.
When you have actually wired the API, fought the deployment, hit the edge cases, and revised the example after it failed in practice, your explanation changes. It becomes less abstract. It becomes more useful. You stop writing for an imaginary user and start speaking to the actual points of friction that slow people down.
Software changes the quality of explanation
A working prototype is not just a demo asset. It is a thinking tool.
It forces questions that slide past presentation-only work:
- What is confusing on first contact?
- Which defaults are strong and which ones are fragile?
- Where does the product ask too much from the user?
- What assumptions exist in the docs but not in the UI?
You can feel the difference between advocacy built on experience and advocacy built on surface familiarity.
The best examples are opinionated
One mistake teams make is trying to build examples that show everything.
That usually makes them worse.
Good example apps should be opinionated, small enough to understand, and real enough to teach tradeoffs. They should show a path that a developer could reasonably follow in production, even if the example itself is simplified.
That is also why cloud examples matter so much. Cloud products only become understandable when they are part of a workflow: deployment, observability, cost awareness, failure handling, and the handoff between local development and a live environment.
Advocacy is also product feedback
When developer-facing teams ship working software, they become a feedback system for the product itself.
They see which abstractions feel natural, which naming choices create confusion, and which steps feel unnecessarily expensive. That is valuable because it connects narrative to reality. The result is not only better content. It is often a better product.
What this means in practice
For me, strong developer advocacy should include:
- building internal and public prototypes
- writing from direct implementation experience
- treating examples as product surfaces, not marketing extras
- revising content after usage, not only before launch
The point is not that every advocate needs to be a full-time product engineer.
The point is that the work becomes sharper when it is grounded in something concrete.
If the story is good but the software is weak, developers notice.
If the software works and the explanation is honest, people remember.