There’s a growing conversation in our field about Developer Experience (DevEx), and for good reason. A happy, productive engineering team can ship higher-quality code faster. The argument is that investing in internal tools, streamlining CI/CD pipelines, and reducing developer friction ultimately serves the end-user. It’s a compelling point, and many of us have fought for resources to pay down tech debt under this banner.
But I’m starting to wonder if the pendulum is swinging too far. Are we becoming so focused on optimizing internal workflows that we’re inadvertently creating ‘internal tool factories’ at the expense of the core user experience? It’s easy to measure the adoption of a new internal platform; it’s much harder to measure the second-order impact on the customer.
As PMs, we are the stewards of user value. While a seamless DevEx is a powerful enabler, it’s not the end goal. We have to weigh the immediate, tangible benefits of a new developer tool against the direct, and often more impactful, value of a user-facing feature or fix. It’s a delicate balancing act between empowering our team and serving our customers.
How do you distinguish between essential DevEx improvements that unlock user value versus ‘gold-plating’ internal tools that have diminishing returns for the customer?