Before investing in complex system instrumentation, use simple surveys to get a quick baseline of developer experience. Ask engineers to name their top three productivity blockers. This provides immediate, high-signal data to prioritize where to focus deeper data collection efforts.

'Happiness' is a poor metric for engineers as it is influenced by many non-work factors. A more useful and actionable metric is 'satisfaction.' You can directly measure and improve satisfaction with specific tools, processes, and team dynamics, which in turn leads to better work.

Many teams wrongly focus on the latest models and frameworks. True improvement comes from classic product development: talking to users, preparing better data, optimizing workflows, and writing better prompts.

A platform's immediate user is the developer. However, to demonstrate true value, you must also understand and solve for the developer's end customer. This "two-hop" thinking is essential for connecting platform work to tangible business outcomes, not just internal technical improvements.

To get buy-in for developer experience initiatives, don't use generic metrics. First, identify leadership's primary concerns—be it market share, profit margin, or velocity. Then, frame your measurements and impact using that specific language to ensure your work resonates.

When employees are 'too busy' to learn AI, don't just schedule more training. Instead, identify their most time-consuming task and build a specific AI tool (like a custom GPT) to solve it. This proves AI's value by giving them back time, creating the bandwidth and motivation needed for deeper learning.

Vercel's CTO Malte Ubl suggests a simple method for finding valuable internal automation tasks: ask people, "What do you hate most about your job?" This uncovers tedious work that requires some human judgment, making it a perfect sweet spot for the capabilities of current-generation AI agents.

To move beyond static playbooks, treat your team's ways of working (e.g., meetings, frameworks) as a product. Define the problem they solve, for whom, and what success looks like. This approach allows for public reflection and iterative improvement based on whether the process is achieving its goal.

It's not enough for platform PMs to interview their direct users (developers). To build truly enabling platforms, you must also gain wider context by sitting in on the developers' own customer interviews. This provides deep empathy for the entire value chain, leading to better platform decisions.