User Valued Work#

We often need to balance prioritization between user-facing work and internal or developer-facing work. It’s helpful to distinguish between these in conversations of prioritization and measuring success.

User-valued work#

This is work that directly affects users. It solves their pain and gives them a delightful experience. It includes work like the following:

  1. Features that solve user pain

  2. Features that delight users

  3. Documentation that many people read and engage with

  4. Directly answering user questions

Developer-valued work#

This is work that mostly developers see.

  1. Paying down technical debt

  2. Fixing CI

  3. Writing well thought out technical documentation, even if it isn’t widely read

  4. Discovering bugs or problems in the system

  5. Writing design documents

  6. Developing features behind a feature flag

  7. Developing features but not releasing them or releasing them only very recently so that most users don’t have them yet

  8. Benchmarking to track success and avoid regressions

Developer valued work is valuable, but only in that it makes us faster in delivering user-valued work to users.

Timing and Judgement#

We are judged as a team on user-valued work in the long term. Developer-valued work is good, but only in service of helping us to perform user-valued work more effectively. It’s great to do developer-valued work for a week or a month, but beyond that it comes into question.

In a professional context when upper-management judges the performance of a team, user-valued changes are typically what matter. This matches how the public judges our work.

Usually a well-functioning team will do both. Focusing entirely on user-focused work tends to be a sign that the team is under short-term pressure. Focusing entirely on developer-focused work for months at a time may be a sign that the team lacks a strong prioritization function.