You know DX matters. But knowing where friction actually lives is a different problem entirely.

A DX Discovery is a structured research effort designed to reduce uncertainty before you commit. It answers three questions: who your developers are and what they're trying to do, what your business goals and constraints actually require, and whether there's something worth building — and if so, what. The output is confidence, not just findings.

A survey tells you what developers think when you ask them a direct question. Discovery tells you why things are the way they are — the context, the workarounds, the friction that never makes it into a survey response. Surveys measure. Discovery understands. Both are useful. They're not interchangeable.

Discovery defines the problem. You're figuring out who your users are, what they're trying to achieve, and whether there's a real opportunity worth pursuing. Assessment evaluates current state against a target — diagnosing gaps, measuring maturity, and producing prioritised recommendations. In practice, they're often combined. The right starting point depends on how much you already know and how much confidence you need before the next decision.

A discovery produces four things: a clear picture of your developer personas and their real friction points, a set of prioritised opportunities specific enough to inform roadmap decisions, validated hypotheses ready for prototyping or testing, and a go/no-go signal you can take into a funding conversation. It's the foundation everything downstream builds on.

Three conditions matter. First, uncertainty is high enough that you can't make a confident investment decision without research. Second, the stakeholders involved have real influence over the areas being researched — out of control means out of scope. Third, there's genuine readiness to act on the findings. Research raises expectations. If there's no appetite or budget to move on what you learn, the discovery will do more harm than good.

Possibly not — if you have recent, structured evidence rather than informed intuition. But most engineering leaders who believe they know are drawing on their own experience as developers, feedback from a vocal minority, or assumptions that haven't been tested. Discovery exists to correct for that. If you're confident and right, the research will confirm it quickly. If you're confident and wrong, you'll find out before it costs you.

No — and this is where the cost tends to be highest. Platform teams built by engineers, for the engineers they imagine, routinely ship tooling with good intentions and low adoption. The false consensus effect means the team's own experience reads as user insight. It isn't. The developers who struggle most are rarely the ones represented in the room. What you get is a platform optimised for the people who built it — which is usually not the people who need it most. That gap shows up in adoption numbers, mandated usage, and workarounds nobody documented.

Don't run the discovery. Research raises expectations in the organisation. Developers and teams who participate expect something to change. If there's no mandate, budget, or appetite to act on what you learn, the discovery will surface real problems you can't fix — and that does more damage than not asking in the first place. Scope the research to what you can actually influence, or wait until the conditions are right.

A well-scoped discovery runs in weeks, not months. The Frame phase typically takes a few days. Research — five to eight interviews per user group, combined with quantitative data collection — takes two to three weeks. Analysis and synthesis, especially with AI-assisted tooling, can move fast. The bottleneck is almost never the research itself. It's alignment before you start and decision-making after.

Five to eight interviews per distinct user group is enough to surface most recurring themes. Beyond that, you're largely confirming what you already know. The key word is distinct. A platform engineer, a mobile developer, and a backend engineer live in different realities and count as separate cohorts. Quality of interviews matters more than volume.

No — and this is one of the structural advantages of internal platform research over B2C or B2B. Your users are colleagues. They're reachable, context-aware, and motivated to see things improve. There's no recruiting pipeline or incentive budget. Getting five to eight developers in front of you is a calendar problem, not a research problem. Often the developers you interview can point to solutions already. That's their job.

Discovery works best as a team effort, not a solo task handed to a product manager or designer. Engineers, platform leads, and business stakeholders all bring different lenses — and the closer the builders are to the research, the fewer assumptions fill the gap later. Combined business and technical expertise on the research team matters significantly for speed and quality of insight. The team should have enough separation from day-to-day platform work to approach findings with curiosity rather than defensiveness.

It can — and in mature teams, it should. Early discovery answers whether you're building the right thing. Discovery during delivery answers whether you're building it right. The two operate at different cadences and with different questions, but they're not mutually exclusive. The organisations that get the most value from research treat it as a continuous practice, not a phase that ends when delivery begins.