The DevX Listening Tour
Before you build a tool, walk developers through their yesterday
- Difficulty
- Easy
- Time to result
- ~days to results
- Steps
- 4
- Confidence
- 88%
A first-move technique for improving developer experience: instead of building tools or automation, interview a handful of developers by walking them through a concrete recent day and mapping where friction occurred. It surfaces low-lift, high-impact fixes and unnecessarily complex processes. Use it as the very first thing you do when starting any DevX effort.
Origin
Forsgren's answer to 'what can a team do this week' — she insists you 'start with listening and not with tools and automation,' noting the podcast's PM audience is already good at this and that developers are eager to tell you what's broken.
Core principles
- 01Start with listening, not with tools and automation
- 02Anchor questions to a concrete recent day, not abstract opinions
- 03A handful of interviews is enough to surface a handful of fixable things
- 04The best opportunities are often low-lift process changes, not engineering builds
How to run it
- 1
Pick a handful of developers
Choose a small set of developers to talk to directly — you don't need a large sample to find patterns.
Pro tip Most developers are more than happy to tell you what's broken and what's bad.
- 2
Walk them through yesterday
Ask them to recall yesterday concretely: 'What did you do yesterday? Walk me through it.' Ground the conversation in real events, not generalities.
- 3
Map delight and friction
Probe for the delightful points and the difficult ones: where they got frustrated, where they got slowed down, where there was friction.
- 4
Surface low-lift, high-impact fixes
Identify the handful of relatively low-effort changes — or an unnecessarily complex, slow process — that keep recurring across interviews.
Pro tip Resist the urge to solve only the problem you personally hit or the one that's easiest to automate.
In the wild
Forsgren observes companies default to 'I'm just going to build this tool,' usually solving a challenge the builder personally had or one that's easy to automate. Talking to developers instead reveals what actually slows the team down.
→ Effort gets aimed at real, shared friction rather than a convenient-to-build feature.
Common mistakes
Building the thing that's easy to build
Teams build tools for problems that are easy to automate or that the builder personally faced, rather than the friction developers actually report.
Is it for you?
Best for
PMs and eng leaders in the first week of a developer-experience effort
Not ideal for
Situations that already have rich instrumentation and a clear, data-validated priority
From the transcript
“start with listening and not with tools and automation”
“think of think of yesterday, what did you do yesterday? Walk me through it. What were the points that were just delightful? What were the…”
“if you go talk to a handful of people, a lot of times you can surface a handful of things that are a relatively low…”
From the episode
How to measure AI developer productivity in 2025
Nicole Forsgren