Improving Developer Satisfaction

How We Used Outcome-Driven Innovation (ODI) to Improve Developer Satisfaction

Understanding the Problem: Why Traditional Feedback Methods Fall Short

Developer satisfaction directly impacts productivity, code quality, and efficiency. Frustrating workflows slow down releases, increase cognitive load, and create unnecessary friction. At GitLab, we wanted to improve the Developer Experience, but the challenge was identifying where and how to make meaningful improvements.

Traditional feedback mechanisms, like CSAT surveys and direct feature requests, provided insights but often lacked clarity on underlying causes. We frequently encountered feedback that was either too broad to act on effectively or too narrow, focusing on specific pain points without addressing systemic issues.

For example:

  • A developer might request a new filter in the Merge Request list (Pull Request for the GitHub inclined), but was that solving the real problem? Or was it a workaround for deeper issues in the code review process?

  • A low CSAT score for a feature signaled dissatisfaction but didn’t reveal what aspects of the experience needed improvement.

Instead of reacting to isolated feedback, we applied Outcome-Driven Innovation (ODI)—a methodology focused on identifying underserved user needs by examining the “jobs” developers are trying to accomplish rather than just feature requests. This structured approach helped us move beyond assumptions and systematically pinpoint where improvements would have the most significant impact.

Applying ODI to Developer Experience at GitLab

We structured our approach into three key phases:

  1. Defining Developer Jobs to Be Done (JTBD)

  2. Measuring Satisfaction and Importance

  3. Prioritizing Underserved Outcomes

Each phase was critical in ensuring our efforts were focused, data-driven, and impactful.

Phase 1: Defining Developer Jobs to Be Done (JTBD)

Before identifying pain points, we needed a structured understanding of how developers work in GitLab. Instead of viewing GitLab as a set of features, we focused on the jobs developers need to complete within the platform.

Using the Jobs to Be Done (JTBD) framework, we mapped out end-to-end developer workflows, breaking them into discrete job steps. For example, a Code Reviewer’s workflow included:

  • Identifying which MRs require review

  • Understanding the changes and assessing their impact

  • Providing feedback and verifying fixes

  • Approving and merging changes efficiently

By framing developer workflows as a series of jobs, we could assess which parts of the process worked well and where developers encountered friction that slowed them down.

Phase 2: Measuring Satisfaction and Importance

Once we identified key job steps, we needed to determine where developers were struggling the most.

Using ODI’s structured survey approach, we asked developers to rate:

  1. How important each job step was to their workflow

  2. How satisfied they were with GitLab’s ability to support that step

By comparing these two metrics, we pinpointed where the biggest gaps existed—areas where developers struggled the most relative to their expectations.

For example, if developers rated "Approving and merging changes efficiently" as extremely important but gave it a low satisfaction score, we knew this was a priority area for improvement.

This method cut through the noise, allowing us to focus on systemic issues rather than reacting to individual feature requests.