Your developers are users. Your platform is a product. Most platform teams know this. Almost none act like it. The practices exist. The domain-specific playbook doesn’t.
The gap isn’t knowledge. Product thinking — user research, opportunity mapping, iterative validation — is well-understood. The problem is translation. These practices are extensively documented for customer-facing products: detailed playbooks for ecommerce customer journeys, B2B buyer flows, consumer app onboarding. Almost nothing equivalent exists for the internal developer domain. No canon of developer journey maps. No standard for platform user research. Teams that want to apply product thinking to their internal platforms aren’t ignoring the method . They’re missing the domain-specific examples that would make it usable. So they fall back on engineering instinct, stakeholder requirements, and the assumption that being developers themselves is close enough.
It’s not. The adoption numbers prove it.
This article introduces the methodology that closes that gap, adapted for software engineering organisations, where the users are developers, the products are platforms, and the stakes are delivery speed, team adoption, and engineering scale. It goes deep on the first phase: Frame. The one most teams skip entirely.
A warning before we go further
There’s a cognitive trap at the centre of almost every internal platform project that goes wrong. It has a name: the false consensus effect — the tendency to assume that others share your experiences, preferences, and pain points. Research into developer experience by Noda, Forsgren, and colleagues consistently finds that the factors developers say drive their productivity are not the ones their leaders assume. The gap isn’t malice. It’s projection.
In most domains, this is a manageable bias. In platform engineering, it’s a structural risk.
Platform teams are typically staffed by experienced developers. They’ve built things, shipped things, felt friction firsthand. Those instincts are real, they’re just not representative. The developers they’re building for live in different parts of the codebase, work in different team structures, and run into friction in completely different places.
Being a developer doesn’t make you a proxy for your users. It makes you a particularly confident one.
I’ve seen this play out in a specific, recurring way. A platform team, all experienced developers, builds a local development environment improvement because slow local builds were the thing they personally found most frustrating. They’re right that it’s a problem. But the developers they’re serving spend most of their time waiting on code review, not on builds. The improvement ships. It’s good work. It barely moves the needle on what developers actually needed. The platform team is surprised. They shouldn’t be, they built for themselves, not for their users.
The methodology that follows is built to correct for exactly this. Every phase — Frame, Research, Analyse & Ideate, Define & Prioritize — replaces assumption with evidence. Not because instinct has no value, but because instinct alone has a track record in internal platform work, and that track record is not good.
The methodology: four phases
A Developer Experience Discovery (DX Discovery) runs in four phases: Frame, Research, Analyse & Ideate, and Define & Prioritize.
Frame aligns the research before it begins. Research finds out what’s actually true. Analyse & Ideate turns raw findings into prioritised opportunities. Define & Prioritize converts those opportunities into a focused, measurable plan. The output of the full cycle: confidence, the kind that lets you commit to an investment decision, or walk away before the cost of being wrong gets high.
This article covers Frame in full. Articles 3 and 4 in this series cover the rest.
Before you start: three conditions
The methodology delivers when three conditions are in place. They’re a go/no-go filter, not a checklist.
High uncertainty. Discovery earns its place when there’s a genuine question research can answer: where to invest, what to build, whose problem to solve. If the evidence is already clear and the direction is set, you don’t need discovery. You need to build. The higher the uncertainty, the higher the return.
Influence and control. Scope the research to what the people running it can actually act on. Out of control means out of scope. Findings that land outside anyone’s mandate don’t create clarity. They create frustration. Developers participated, shared real problems, and nothing changed, not because the research was wrong, but because it was aimed at the wrong level. Scoping to what you can influence isn’t a constraint. It’s what makes findings usable.
Readiness to act. If there’s no mandate, budget, or genuine appetite to move on what you find, don’t start. I mean that without qualification.
Research raises expectations. Developers who participate expect something to change. Running a discovery you can’t act on surfaces real problems you have no power to fix, and that does more damage than not asking in the first place. It signals that the organisation listens but doesn’t follow through. That reputation is hard to recover. Scope the research to what you can influence, or wait until the conditions are right.
Phase 1: Frame
Discovery without framing produces generic results. Interesting, sometimes. Actionable, rarely.
Framing is the work done before research begins: aligning the people who will run the discovery with the people who will act on its findings. Skip it and you’ll surface insights nobody has the mandate to do anything about. Get it right and everything downstream moves faster and lands harder.
The output of Frame isn’t research. It’s alignment on what the discovery is for, who it’s about, and what the team is empowered to act on.
Three things get defined in this phase.
Flight level: getting the scope right
Flight level is the organisational scope of the research. It’s the single most consequential framing decision and the one most teams get wrong.
Four levels to choose from:
1 — Full engineering organisation The broadest scope. Research spans the entire org. Best when uncertainty is high and no specific domain or platform has been identified as the priority. Requires broad stakeholder mandate.
2 — Domain or value stream Scoped to a team cluster or value stream. Right when a specific part of the engineering organisation is underperforming or underserved and you have the mandate to act within it.
3 — Developer lifecycle phase Focused on a particular workflow; local development, CI/CD, deployment, incident response. Best when friction signals point to a specific phase rather than a general malaise.
4 — Specific platform or toolchain The narrowest scope. Right for validating direction, diagnosing low adoption, or prioritising a platform roadmap.
The right level depends on where uncertainty is highest and where stakeholders have real influence. Picking the wrong one is the most common reason discovery findings end up ignored.
A composite example: a platform team I worked with scoped their discovery to a specific toolchain — Level 4 — when the real friction lived upstream in the CI/CD pipeline, a Level 3 problem. Their findings were solid. Their recommendations were actionable. The toolchain improved, and developers adopted the updates. The underlying lifecycle friction — the thing actually slowing teams down — remained untouched for another six months, because the discovery had been aimed at the wrong level. Nobody shelved the research. It just answered the wrong question.
Cohorts: who you’re researching
A developer cohort is a group with sufficiently similar context that research findings will be consistent within it and distinct from other groups. That specificity matters more than most teams expect.
A platform developer, a mobile developer, and a data developer live in fundamentally different realities, different codebases, different toolchains, different definitions of what “slow” means. Grouping them into a single “developer” cohort produces a blended average that accurately describes nobody.
I’ve seen this made clearly costly. A team ran a discovery across their entire developer population without segmenting by role or context. The findings were genuine. But when it came time to act, every initiative generated the same question: which developers does this apply to? The research couldn’t answer it because the cohorts had never been defined. Findings that should have driven a roadmap in weeks took months to prioritise and some of the most important ones never made it at all.
Define cohorts before research begins. Get this right upfront and the research produces something you can actually act on.
Focus areas: keeping the research pointed
The third framing decision is scope within the cohort: what are you actually investigating?
Based on known pain signals, stakeholder priorities, and what’s within the team’s control, the discovery team agrees on the areas worth exploring before a single interview is scheduled. This keeps the research pointed. Not by constraining what developers can tell you, but by ensuring the team knows what to do with what they hear.
Scope creep is where discoveries go to die. A focused discovery that answers three questions well is worth more than an unfocused one that grazes ten.
The output of Frame is alignment on what the discovery is for, who it’s about, and what the team is empowered to act on. Get that right before research starts, and everything that follows moves in the same direction.
The platform teams getting this right aren’t the ones with the biggest budgets. They’re the ones who found out before they committed.
Next in this series: the research itself — how to find out what developers actually need, what to do with what you find, and where AI is compressing the work.
Before the methodology: three questions I hear most
How do I know if we’re ready to run a DX Discovery?
Three conditions need to be true. First, uncertainty is high enough that you can’t make a confident investment decision without research. Second, the stakeholders involved have real influence over what’s being researched. Out of control means out of scope. Third, there’s genuine readiness to act on the findings. If all three are in place, you’re ready. If one is missing, address it or wait. Running a discovery without all three is how you end up with findings that go nowhere and a team reluctant to participate in research again.
What are the conditions for running a successful DX Discovery?
High uncertainty, influence and control, and readiness to act. These aren’t checkboxes, they’re structural requirements. High uncertainty means there’s a genuine question research can answer. Influence and control means findings can be acted on within the scope of the research. Readiness to act means there’s mandate, budget, and appetite to move on what you find. The most commonly skipped condition is the third. Teams run discoveries they can’t act on, surface real problems, and then wonder why developers disengage from the next initiative. Don’t start if you can’t finish.
What’s the difference between a DX Discovery and a DX Assessment?
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, producing prioritised recommendations. In practice the two are often combined. Discovery is right when you have high uncertainty and need a go/no-go signal before committing. Assessment is right when you know roughly what you’re building and need to know how far you are from where you want to be.