You know DX matters.
But knowing where friction
actually lives is a different
problem entirely.
A pragmatic methodology for engineering and platform leaders who want to stop guessing — and start making DX investments based on what developers actually need.
Why DX Matters
Most engineering leaders already know that developer experience matters. What's harder to justify is treating it with the same rigour as a product or infrastructure investment.
That's a costly gap.
Productivity and efficiency
Developers lose roughly 22% of their time to inefficiencies — context switching, broken tooling, unclear documentation, waiting on slow pipelines. According to DX Research, that's a $1.55B drag on engineering output. A 20% improvement in developer experience translates directly into reclaimed capacity — without a single new hire.
Talent acquisition and retention
Replacing a developer costs up to 200% of their annual salary, before you account for lost momentum and the institutional knowledge that walks out with them. Developers talk. Poor DX gets a reputation. Strong DX becomes a hiring argument.
Innovation and product quality
Spotify reduced engineer onboarding time by 67% after deploying a developer portal — measured by time to meaningful contribution. Teams with fast feedback loops and low cognitive overhead ship more and break less. That's the kind of compounding return that shows up in product velocity.
Morale and culture
According to Noda & Forsgren's DevEx research, flow state, cognitive ease, and fast feedback loops are the three dimensions that most consistently predict developer satisfaction and output. The leaders who treat DX as an organisational leverage problem — not a perks problem — are the ones whose platforms get built, used, and built on.
The Awareness Problem
The awareness problem is solved. Every engineering leader knows DX matters. The harder problem is that knowing it matters and doing something about it are two very different things — and the gap between them is where bad platforms are born.
The excuses are familiar. You've probably used one.
"We don't have the bandwidth right now."
There's always a delivery deadline, a migration, a reorg. The research gets deprioritised. The platform gets built on assumptions instead.
"We already know what developers need."
You've been an engineer. Your team leads are engineers. Surely that's enough. It isn't — and the adoption numbers usually prove it eventually.
"We ran a survey last year."
A survey is not a discovery. Aggregate satisfaction scores don't tell you why the CI pipeline makes people want to quit.
"The team will adopt it once it's better."
It's been eighteen months. Adoption is still being mandated, not earned. The Slack channel has three messages in it.
Imbalance in decision-making between business & technology needs and developer needs
The result is always some version of the same thing: a platform that exists, that people are technically required to use, and that nobody would choose if they had an alternative. Every company has one. Most companies have several.
The root cause is almost never bad intentions or bad engineers. It's the absence of structured research before the commitment was made. Business goals push for efficiency gains and cost reduction. A new technology creates urgency — a wave of excitement that makes it feel irresponsible not to act. And somewhere in that process, the people who will actually use what gets built never factor into the decision. No one mapped what they were trying to do. No one asked where the friction lived. The platform gets built for the organisation, not for its users.
How Discovery Solves It
Confidence is the product. Not a report, not a set of recommendations — confidence. The kind that lets you make a good investment decision, take it into a funding conversation, or walk away before the cost of being wrong gets high.
The situations that bring people to discovery are usually one of these:
You want to improve developer experience, but can't point to where.
The intent is there. The investment case isn't — because nobody can say with certainty where the friction lives or what it's worth fixing.
Something in the dev lifecycle is slowing teams down.
You have signals — complaints, slow cycles, quiet workarounds. Not enough to act on with confidence.
You're building or evolving a platform and need to validate the direction.
The business case exists. What's missing is clarity on who you're building for and what they'll actually adopt.
One or more platforms are struggling for adoption.
Usage is mandated. Voluntary uptake is low. You suspect the platform isn't solving the right problem. You just can't prove it yet.
In each case, the gap is the same. Not enough confidence to commit. Not enough clarity to prioritise. Too much risk of building the wrong thing.
Discovery closes that gap. It gives you a clear picture of your developer personas and their real friction points, a set of prioritised opportunities specific enough to drive roadmap decisions, and a signal you can take into a funding conversation — or use to justify stopping. The foundation everything downstream builds on. And the thing that keeps the cost of walking away low.
It doesn't have to be heavy. A well-scoped discovery — right cohorts, right questions, right flight level — moves fast. The bottleneck is rarely the research. It's the decision to start.
The organisations that get this right aren't the ones with the biggest research budgets. They're the ones that found out before they committed.
Confidence over time
The Methodology
Product thinking works. User research, opportunity mapping, iterative validation — proven tools, widely accepted, consistently effective. In customer-facing teams, this is just how good product work gets done.
Internal platforms are a different story. Engineering instinct substitutes for user research. Business goals substitute for developer needs. The practices exist. Applying them to the internal domain is where it breaks down.
This methodology fixes that. It takes proven product practices and adapts them to the realities of software engineering organisations — where the users are developers, the products are platforms, and the stakes are delivery speed, adoption, and engineering scale.
Four phases. Frame. Research. Analyse & Ideate. Define & Prioritize.
Three conditions determine whether you'll get full value from running it:
High uncertainty.
The higher the uncertainty about where to invest or what to build, the higher the return. If you already know the answer, you don't need a discovery.
Influence and control.
Scope the research to what the involved stakeholders can actually act on. Out of control means out of scope. Findings nobody can act on create noise, not clarity.
Readiness to act.
Research raises expectations. Teams who participate expect something to change. If there's no appetite or budget to move on the findings, don't start.
Get those three right, and the methodology delivers — a clear picture of where to invest, and the confidence to commit or walk away.
Frame
Discovery without framing produces generic results. Interesting, maybe. Actionable, rarely.
Framing is the work you do before the research starts — 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.
Three things get defined in this phase:
Flight level — the organisational scope of the research. Four levels to choose from:
Level 1
Full Engineering Organisation
The broadest scope. Research spans the full engineering organisation. Best suited when uncertainty is high and no specific domain or platform has been identified as the priority.
Cohorts.
Who you're researching. A platform engineer, a mobile developer, and a data engineer live in very different realities. Defining the right cohorts upfront ensures the research reflects the people whose experience you're actually trying to improve — not a blended average that represents nobody.
Focus areas.
What you're looking for. Based on known pain signals, stakeholder priorities, and what's within scope, the team agrees on the areas worth investigating. This keeps the research pointed. Scope creep is where discoveries go to die.
The output of this phase 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. Everything else builds from here.
The false consensus trap
Engineers researching engineers feel like insiders. That's the problem. The false consensus effect leads people to assume others share their experiences and pain points. Being a developer — or having been one — doesn't make you a proxy for your users. It makes you a particularly confident one.
Research
This is where you find out what's actually true.
The approach is mixed-methods by design. Qualitative interviews give you the why — the context, the frustration, the workaround nobody documented. Quantitative methods — surveys, analytics, DORA metrics — give you the what and the how many. Scale, frequency, severity. Anecdotes without data can't be prioritised. Data without context can't be understood. You need both.
Qualitative
The why
- Interviews
- 5–8 per distinct user group
- Context, frustration, workarounds
Quantitative
The what & how many
- Surveys, analytics, DORA metrics
- Scale, frequency, severity
"Anecdotes without data can't be prioritised. Data without context can't be understood."
On interviews.
Five to eight per distinct user group is enough to surface most recurring themes. Beyond that, you're confirming what you already know. The interviews work best when the research team combines business and technical expertise — it's the difference between understanding what a developer says and understanding what it means.
Research looks different depending on where you are in the journey:
Early — problem/solution fit
Are we building the right thing?
- Mapping the problem space and validating assumptions
- Deciding whether there's something worth pursuing
- Output: a go/no-go signal and the raw material to act on it
During execution
Are we building it right?
- Testing prototypes, validating direction, running experiments
- Research is continuous and specific at this stage
- Questions get narrower as confidence grows
An advantage worth naming
Unlike B2C or B2B research, your users are colleagues. They're easy to reach, already context-aware, and have a vested interest in things getting better. That removes one of the biggest friction points in user research — access. There's no recruiting pipeline, no incentive budget, no cold outreach. Just a calendar invite.
Analyse & Ideate
Raw research doesn't make decisions. Synthesis does.
This phase is where interview transcripts, survey results, and observation notes get transformed into something a team can act on. The goal is speed without sloppiness — from data to insight to opportunity, before the analysis becomes the project.
From transcripts to insights
Start by clustering. Group observations, quotes, and notes into recurring themes — pains, needs, behaviours, workarounds. Patterns emerge fast when the data is visible and the team works it together. AI-assisted transcription and synthesis is compressing this step significantly, turning hours of interview material into structured starting points in minutes. The human judgement comes in deciding what matters.
Prioritising what to act on
Not every insight is equal. Prioritise by frequency — how many developers experience this? — and by severity — how much does it slow them down or block them entirely? That intersection is where the real opportunities are. That's where you focus.
Ideation
Once the priority pains and needs are clear, the team diverges. The brief is simple: what could we do about this? Volume matters here — generate options before you evaluate them. Deciding too early is where good ideas die before they get a fair hearing.
Hypothesis formation
Before anything gets prioritised for testing, it gets written as a hypothesis. This discipline matters more in the DX domain than almost anywhere else — because the temptation to skip straight to a solution is highest when the team building the platform is also part of the user group. A hypothesis forces the assumption into the open. Where it can be tested rather than acted on blindly.
Hypothesis format
"We believe that [action] will result in [outcome] for [user]."
Define & Prioritize
Research gives you options. This phase forces the choices.
By this point you have prioritised opportunities, validated hypotheses, and a clear picture of where developer friction lives. The job now is to turn that into a focused, measurable plan — without the list of good ideas becoming a reason to avoid committing to any of them.
Align to strategy first.
Before anything gets prioritised, it gets checked against the platform strategy. Good research surfaces a lot of opportunities. Not all of them belong on the roadmap. The ones that do solve the right problem, for the right users, within the constraints that actually exist.
Prioritise ruthlessly.
Sequence opportunities by impact, confidence, and feasibility. Decide what gets prototyped and validated before committing, and what's ready to move straight into delivery. The output is a roadmap input — not a wish list.
Define what success looks like.
Every initiative that makes it through needs a measure of success attached to it. What does better DX look like for this specific problem? How will you know when you've got there? Without this, initiatives drift. With it, they stay honest.
The output of this phase is a focused plan — grounded in research, aligned to strategy, and specific enough to act on.
Inputs
- — Prioritised opportunities
- — Validated hypotheses
- — Developer friction map
Output
A focused plan
- Grounded in research
- Aligned to strategy
- Specific enough to act on
AI-Powered Discovery
Discovery has always been the right thing to do. The honest objection was time and expertise. AI is removing both.
Across every phase of the methodology, AI is compressing the work that used to create the most drag — without compromising the quality of what comes out.
Desk research synthesis, stakeholder interview prep, cohort definition support
Interview transcription, automated note-taking, survey analysis
Theme clustering, pattern detection across interviews, persona drafting, opportunity mapping
Hypothesis drafting, prioritisation scoring, roadmap input structuring
The result is a discovery process that's more accessible to teams without dedicated research expertise, and more feasible for organisations working under real time constraints. You don't need a research team. You need a methodology, the right questions, and the tools to move quickly from data to insight.
AI doesn't replace the judgment calls — who to talk to, what to probe, which insights actually matter. Those stay human. What it removes is the volume of mechanical work that used to make discovery feel expensive before it had even started.
Post-Discovery
Discovery doesn't end when delivery begins. The organisations that get the most from it treat it as a practice — something the team does continuously, not something a specialist runs once and hands off.
Continuous discovery
The questions change as the product matures. Early research asks whether you're building the right thing. Later research asks whether you're building it right. Later still, it asks whether what you built is actually working. The loop doesn't close — it compounds. Teams that stay close to their users make better decisions, faster, with less waste.
Research is a team sport
Discovery works best when it isn't owned by a single role. Product managers, engineers, designers, platform leads — everyone who builds the platform benefits from direct exposure to the people using it. Not every team member runs every interview. But everyone should be close enough to the research to feel it, not just read a summary of it. The further the builders are from the users, the more assumptions fill the gap.
Measuring DX over time
Phase 4 defines what success looks like. Post-discovery is where you find out if you were right. Track the metrics you committed to. Watch for the gap between what the research predicted and what actually happened. When the gap widens, that's the signal to go back to research — not to push harder on delivery.
When to run the next discovery
Continuous discovery doesn't mean permanent discovery. It means staying alert to the signals — adoption plateauing, new cohorts emerging, a strategy shift that invalidates earlier assumptions. When uncertainty is high enough again, go back to research.
Product thinking for platforms
The mindset that makes all of this work is treating the platform as a product — with developers as customers. That means understanding what's blocking them before deciding what to build, offering something better than what they're already using, and earning adoption rather than mandating it. Platforms that operate this way compound in value over time. Platforms that don't stay on life support.
The tension worth naming
Every platform decision sits on a spectrum between centralised control and full team autonomy. Neither extreme works. Full centralisation reduces tooling sprawl but erodes developer agency. Full autonomy maximises freedom but creates security blind spots, duplication, and hiring complexity. The right position depends on context. The research helps you find it.
About Discovery
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.
Readiness and Conditions
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 one of the most common traps in platform work. The false consensus effect leads people to assume others share their experiences and pain points. Being a developer doesn't make you a proxy for your users. It makes you a particularly confident one.
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.
Running the Research
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.
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 also matters significantly for speed and quality of insight.
After Discovery
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.
Most of what you've read here isn't new. These are well-known discovery practices — adapted, not invented. What's new is the context they're being applied in.
I've worked with a lot of engineering and platform teams. Very few apply these practices consistently when it comes to internal platforms and developer experience. I've been guilty of that myself.
It's not a knowledge problem. The methods are understood. What gets in the way is underestimating how much they actually matter here — or convincing yourself you'll do it properly later, once the real work is done.
There is no later. Research isn't something you sprinkle on top.
— Jacob
Want to explore what DX Discovery could do for your team?
Whether you're facing a specific DX challenge, planning a discovery engagement, or simply curious about the methodology — I'm happy to talk it through.
hej@jbpt.de