Developer experience usually sits with engineering. It gets discussed as internal velocity, onboarding time for new hires, how painful the build is. All legitimate, and all inward-facing.
The outward-facing version matters commercially too, and I rarely see a single owner for it: engineering, product and developer relations each hold a piece. When a developer who has never met you signs up, reads your docs, and tries to get something working, that sequence is doing the job a sales team does in other categories. It is the first and often only demo, it runs unattended, and it decides the outcome. Developer experience (DX) is the quality of a developer's whole interaction with a product, from docs and onboarding through APIs, error messages and support, and the version a prospective user meets is a marketing asset whether or not marketing owns it.
In my experience, most companies measure it as an engineering metric and market around it rather than with it.
Key takeaways
- Atlassian's guide to developer experience focuses on developers' everyday work inside an organization. This post is about the version prospective users meet: your docs, your quickstart and your first code sample.
- In Stack Overflow's 2026 Developer Survey, the most common reason developers gave for recommending a technology was that it is reliable, performant and stable (17.3% of 22,371 answers). A strong developer experience drew 11.4%, and useful AI features 2.3%.
- For self-serve onboarding, the number to own is time to first success: how long a developer with no prior context takes to get the product doing something they wanted. Signups measure interest; that number measures whether the product delivered.
What happens in a developer's first session?
A developer evaluating your product has a specific, impatient question: can I get this to do something real, right now, without talking to anyone?
That window is short. An authentication step that requires a sales call, a quickstart that assumes context they don't have, or a code sample that doesn't run as written can end the evaluation before the developer ever contacts you. In my experience, many don't file a complaint. They close the tab and try the alternative, and you never learn it happened.
This moment deserves to be measured as closely as signups and conversions. Marketing tracks signups and marketing tracks conversions, and the thing between them can end up treated as somebody else's problem.
What do developers evaluate when they try a new tool?
Developers trying a new tool judge more than whether it works: they read the experience for signals about the company behind it.
Whether your docs match reality. A code sample that errors is worse than no sample, because it says your docs aren't tested and invites the question of what else isn't.
Whether you respect their time. Required sales contact before evaluation reads as a company that doesn't trust its product to speak for itself.
Whether the hard parts are documented. Every tool has sharp edges. Documenting yours builds more confidence than pretending they don't exist, because the developer will find them either way and the only variable is whether they find them with your help or on their own at 2 a.m.
Whether anyone is home. A stale changelog, unanswered issues, a community forum with no staff replies. These get read as evidence about the company, not about the docs.
Why is developer experience a marketing asset?
Developer experience decides whether the attention your marketing generates turns into product use.
It's the highest-fidelity marketing asset you have. Everything else you publish is a claim; the experience is a demonstration. A developer who gets something useful working in fifteen minutes has direct evidence of the product's value, and in my view that persuades more than a campaign can.
Before I started Salient, I ran developer marketing at a mobile company, and we wanted app developers to integrate our SDK. We made them an offer, and I don't remember the exact terms, but it was roughly: give us a short trial, and if you don't see the lift, we'll pay you. It had a very high response rate. Developers have a high BS filter, and putting something real on the line got past it.
It's what gets described to other people. When an engineer recommends a tool to a colleague, the reason is often about the experience rather than a feature list: "it just worked" or "the docs are good." That sentence is your positioning, written by someone else, and it starts in the experience. Stack Overflow's 2026 developer survey points in a similar direction: the top reason developers gave for endorsing a technology was that it is reliable and stable, and useful AI features drew 2.3%.
It's the constraint on everything upstream. Launch coverage, community and content all deliver people to a front door. If the door sticks, spending more on the upstream work just increases the number of people who bounce off it. A Product Hunt or Show HN launch is the sharpest version of this, because it sends many developers to the door on the same day.
How do you improve developer experience?
The quickest way to improve developer experience is to watch where a developer with no context gets stuck, fix that spot, and time the path again.
Watch someone use it cold. Not a customer who already knows you. Someone unfamiliar, screen shared, without helping them. It is uncomfortable and it is the single most informative hour available to a devtools company.
Test your code samples in CI. Automated tests catch documentation examples that stop working as the product changes. Run them the way a new user would, with the published install steps and current versions, because a sample that passes in a simplified setup can still fail on a real one.
Time the path to first success and treat it as a number you own. Not signups. The gap between arrival and the first moment the product does something the developer wanted.
Remove every gate you can survive without. Each one converts a self-serve evaluation into a sales conversation the developer didn't ask for, at the exact moment their interest is highest and their patience is lowest.
Write down the failure modes. A troubleshooting page that names real problems in plain language is worth more than another feature page. We run our own blog on a version of that idea: it exists to answer, plainly, the questions people have before hiring a PR agency for the first time, like how long results take and whether they're ready.
The connection to everything else
Earned coverage, technical content and community all work on the same underlying asset: whether developers who encounter you come away thinking you're competent. That connection is the part that gets missed in the marketing plan.
The experience is where that judgment actually forms. You can generate attention without it, and the attention will convert badly and produce word of mouth that works against you.
Common questions
What is developer experience? Developer experience (DX or DevEx) is the quality of a developer's interaction with a product or platform, from documentation and onboarding through APIs, error messages and support. Some guides, including Atlassian's, focus on a company's own engineering teams. The externally facing version, what a prospective user encounters, functions as marketing whether or not marketing owns it.
How do you improve developer experience? Watch an unfamiliar developer use the product without helping, test documentation code samples automatically, measure time from arrival to first successful action, remove evaluation gates, and document known failure modes honestly. Start with the unassisted session, because it shows you which of the other fixes matters most.
Why does developer experience matter for growth? Because it's the demo. For a self-serve product, onboarding lets developers test its value directly, and a working quickstart and clear documentation help them reach a useful result. In Stack Overflow's 2026 survey, reliability was the most common reason developers gave for recommending a technology.
Who should own developer experience? Engineering owns the implementation, but the externally facing path, from the docs to the first working result, needs someone accountable for it as a commercial asset. Where responsibility is split across engineering, product and developer relations, assign one person to coordinate the whole path.
What's the best developer experience metric? For self-serve onboarding, start with time to first successful action, measured for someone with no prior context. Signup counts measure interest; that measures whether the product delivered on it. Internal measures such as build times and deployment frequency describe your own engineers' experience, not a prospect's.
Sources
- Stack Overflow, 2026 Developer Survey: Work, Stack Overflow, October 6, 2026
- Wikipedia contributors, Developer experience, Wikipedia, accessed November 8, 2026
- Atlassian, What is developer experience?, Atlassian, accessed November 8, 2026
Salient PR works with developer tools companies across CI/CD, testing infrastructure and developer platforms.
About Salient PR
Salient is a B2B tech PR agency. We help startups become the story — landing tier-one coverage, building executive visibility, and turning attention into pipeline.
Senior team. No hand-offs. Radical transparency. If you’re ready to talk, reach out.
