Adopting the product operating model at Priceline

Engineering Enablement by DX

0:00

-42:09

Adopting the product operating model at Priceline

How Priceline used developer experience metrics, organizational change, and a product operating model to improve engineering effectiveness and prepare for AI-driven software development.

Justin Reock

Jul 10, 2026

Listen and watch now on YouTube, Apple, and Spotify.

In this episode of the Engineering Enablement podcast, I sit down with Sejal Amin, Chief Technology Officer at Priceline, and Pedro Gutierrez, Senior Director of Software Engineering, to discuss how Priceline adopted a product operating model and the role developer experience played in making that transformation successful.

We explore why the company moved away from a project-based approach, how DX metrics and developer feedback helped uncover organizational bottlenecks, and why a phased rollout, clear communication, and empowered engineering managers were critical to building trust and improving developer experience. We also discuss creating a dedicated developer experience team, lessons learned throughout the transformation, and how Priceline’s product operating model has helped the organization adapt to AI-driven software development.

Some takeaways:

Developer experience as a driver of organizational change

Developer experience data can reveal organizational problems that traditional engineering metrics miss. At Priceline, DX signals uncovered organizational bottlenecks—including handoffs, dependencies, and team friction—that ultimately led the company to adopt a product operating model.
Developer experience should be treated as a strategic capability, not just an engineering metric. Rather than measuring developer satisfaction in isolation, Priceline used DX insights to guide structural changes that improved autonomy, delivery, and engineering culture.

Adopting a product operating model

Reducing dependencies gives teams greater ownership. Priceline shifted from a project-based organization to cross-functional product teams, reducing handoffs and giving teams the people and capabilities needed to own outcomes end to end.
Autonomy requires visibility into team health. DX metrics gave engineering managers a clear view of the obstacles affecting their teams, allowing them to improve local workflows while staying aligned with broader organizational goals.

Turning developer feedback into action

Developer experience surveys should lead to action—not just measurement. Managers reviewed survey results, completed a triage process, created quarterly action plans, and measured whether those improvements had an impact in the next survey cycle.
Small workflow improvements can have an outsized impact. DX data helped teams reclaim focus time, identify tooling regressions after migrations, surface cross-team dependencies, and address day-to-day friction before it became systemic.

Building trust in developer experience metrics

Clear communication is essential for adoption. Leaders consistently reinforced that DX metrics existed to improve teams rather than evaluate individuals, helping build confidence in the process from the outset.
Trust grows when developers see meaningful change. Acting on feedback quarter after quarter encouraged greater participation, strengthened psychological safety, and made developer experience part of the organization’s culture.

The evolving role of engineering managers

Engineering managers became owners of developer experience. Managers were expected to understand DX data, improve their team’s DXI each quarter, and make developer experience part of their regular operating rhythm.
Developer experience became part of everyday engineering leadership. DX metrics were discussed openly in all-hands meetings and other forums, making developer experience a visible measure of organizational health rather than a one-time initiative.

Preparing engineering organizations for AI

AI changes where bottlenecks occur—not whether they exist. As AI accelerated code generation, Priceline used its product operating model and developer experience data to identify where constraints had shifted and respond accordingly.
A strong operating model helps organizations adapt to AI. Autonomous teams, continuous measurement, and visibility into developer workflows allowed Priceline to embrace AI while continuing to improve flow across the software development lifecycle.