Notes
DevX Is a Growth Function
The growth loop starts when DevX owns repeated developer friction, ships the fix, distributes the better path, and measures whether behavior changed.
We more than doubled our unique active users across our open-source ecosystem in a year, driving direct growth in API engagement. We moved those metrics by treating DevX as a growth discipline, not a documentation queue. Our product, engineering, UX, and technical writing teams treated product, distribution, and measurement as one system, because presence in a workflow is not proof of adoption.
Documentation requests look like progress, but they usually mask friction that belongs in the product. Docs, code samples, advocacy, and tutorials all have a ceiling. The job is direct: identify the friction that stalls a builder, fix it in the experience, place the better path where they already work, and measure the shift in behavior.
Own the friction
Friction shows up everywhere: failed first runs, abandoned evals, support tickets, GitHub issues, field conversations, and user research. DevX needs one view across those signals. More importantly, DevX needs to own what happens next.
Our Voice of Developer program aggregates repeated friction from Discord, Stack Overflow, GitHub issues, support, field work, and dogfood sessions into ranked product opportunities. That makes the constraint visible. DevX ownership starts there: choose what to solve, ship the change, and measure what happened.
When builders work through coding agents, we design for both the person making the decision and the agent acting inside the task.
Ship the fix where builders work
A great experience doesn't matter if builders never encounter it. Documentation is one distribution surface, not the entire strategy. The right path also needs to appear in the editor, agent, search result, sample, template, or tool where the work actually begins.
Instead of relying on documentation alone, we distribute executable product behavior directly into developer workflows. Client libraries encapsulate the logic, while Code Assist delivers current official documentation and samples straight to compatible MCP clients. For repetitive tasks, our Agent skills bundle versioned workflows across Web, Android, iOS, and Web Services. Before shipping, we gate each skill with a task-based eval to ensure it works.
Distribution can't be an afterthought. Design the experience so it can travel, then make it the default in the workflows that already have reach.
Measure and own outcomes
Traditional feedback loops are slow. Interviews, support themes, and developer surveys remain essential, but they rarely drive immediate product decisions. We shorten this loop using Agent evaluations. When a coding agent attempts a representative task, its trace reveals exactly where the task stalls or branches wrong. A rubric then scores that result against a no-context baseline, giving us a clear ship-or-hold decision before we launch.
Evals don't replace user research, because no single score explains a human builder. An eval delta confirms that the experience completes the task mechanically. Product telemetry tells us whether builders actually found that path, finished the work, and returned. Finally, direct research explains why people behaved that way. Together, these signals let a DevX team test specific hypotheses and measure the real outcome.
This is the discipline: stop counting output as progress by default. Own the friction, solve it in the experience, ship the better path into the workflow, and measure whether behavior moved. If you're running DevX as a growth engine for your developer platform, how do you track and distribute your fixes? Share your loops in the comments.
Written by Ryan Baumann. Fine-tuned local language models assist with copyediting and voice consistency; all ideas, analysis, and code are my own.
Discussion
Comments
Comments are GitHub Discussions rendered by giscus. Sign in with GitHub inside the widget to post or react.