Developer Experience Is A Product, Not A Feeling

Developer Experience Is A Product, Not A Feeling

The phrase "developer experience" gets used like a vibe. Make the docs nicer. Add a CLI. Put up a landing page that says "built for developers." That's not developer experience. That's marketing for developers. They are not the same thing.

I work on platform product for the M365 suite at Microsoft, and the developer experience layer is one of the highest-leverage product surfaces in the entire stack. Get it right and 12 partner teams ship faster every week. Get it wrong and the platform becomes the thing engineers route around.

The right unit of measure is "time to first useful thing"

I don't measure DX in NPS scores or survey results. I measure it in time to first useful thing: how long does it take a new engineer, on day one, to do something real with our platform? Not "hello world." Not the tutorial. A thing that ships, in their actual codebase, that solves their actual problem.

If the answer is more than 30 minutes, something is wrong. If the answer is more than a day, the platform has a serious adoption problem you haven't yet noticed.

The metric is brutal because it forces honesty. You can't fake it with better docs. You can't paper over it with a Discord channel. The integration either works in 30 minutes or it doesn't, and the developer either keeps going or quietly drops your platform and uses a competitor's.

The default path matters more than the advanced path

Most platform teams over-invest in the advanced configuration surface — the 1% of customers who need every dial. They under-invest in the default path that 95% of customers actually take.

This is backwards. The default path is where developer experience is won or lost. If your default works without configuration, the developer is hooked. If your default requires a 14-line YAML file before it does anything useful, you've lost the developer before they learned what your product does.

I now ask the team, every time we add a config option: *what does this look like with no configuration?* If the answer is "broken" or "unusable", we haven't designed the product, we've designed a kit.

Errors are the real documentation

Nobody reads docs proactively. Everybody reads error messages. That asymmetry should change how teams write both.

A great error message tells the developer three things: what went wrong, where it went wrong, and what to do next. Most error messages tell them only the first, and even that one badly. The result is a developer who pastes the error into Stack Overflow, finds nothing useful, and writes us off.

In platform product, the error surface is the documentation surface. If the error is bad, the docs don't matter, because by the time the developer is reading them they've already lost trust.

Sovereignty changes everything

In a regular cloud, developer experience can be iterated. In a sovereign cloud, the air-gap means iteration is much harder — there's no telemetry coming back, the developer can't easily file a bug, and the deployment context is locked down. So your DX has to be right *before* the developer ever touches it.

That's pushed me to a more conservative product philosophy on platform work: ship less, ship slower, ship with more upfront design. The cost of "we'll fix it in the next release" is too high when the next release lands behind a firewall.

What I'd want a new platform PM to internalise

Three things, briefly:

- Measure DX in time-to-first-useful-thing, not satisfaction surveys. - Optimise the default path before the advanced path. - Treat errors as your most-read documentation, because they are.

Developer experience is a product, with users, with metrics, with a roadmap. The platforms that get this right become the substrate other people build on. The ones that don't quietly fade.