We’re all obsessed with being user-centric, and for good reason. We conduct endless research, map intricate user journeys, and live by user feedback. But are we ignoring a critical user persona whose experience directly torpedoes our ability to deliver value? I’m talking about our developers.
The ‘Developer Experience’ (DevEx) isn’t just about keeping engineers happy with good coffee and cool monitors. It’s about the efficiency and friction of their daily workflow—the tools, the CI/CD pipeline, the documentation, the ease of spinning up a test environment. A poor DevEx, bogged down by technical debt and clunky processes, is a direct tax on every feature you want to build. It leads to slower velocity, more bugs, and burnout, all of which ultimately spill over into a poor customer experience.
As PMs, we often see platform work or tooling improvements as ‘non-feature’ work that distracts from the ‘real’ roadmap. But what if we started treating our internal development platform as a product in its own right, with our engineers as the primary users? Prioritizing their experience isn’t just a favor to engineering; it’s a strategic investment in our own ability to ship high-quality products faster.
How much influence should a PM have over the internal developer experience? When have you chosen to prioritize platform improvements over a new feature, and how did you justify it to stakeholders?