It is possible to build exactly what was asked for, on time, working correctly, and still have changed nothing about the situation that caused someone to ask.
That gap is the thing I think about most.
Delivery is easier to see
A feature either exists or it does not. It can be demonstrated. Whether a problem got smaller is much harder to observe, takes longer to find out, and depends on whether people actually changed how they work.
Because one is legible and the other is not, it is very easy for a team, including me, to drift towards optimising the legible one.
What I try to ask before something is considered done
- Did the thing that was painful become less painful, for the person it was painful for?
- Are people using it, or are they using it plus the old workaround?
- Did we solve the case that actually happens, or the case that was easiest to define?
- If this disappeared next month, would anyone notice?
Usage is not the same as success
People will use something because they have no alternative. That is not evidence that it works well. It is evidence that it is mandatory. The more honest signal is whether the underlying complaint stopped.
Where this leaves me
I do not think there is a clean fix. Solving is slower to verify than building, and that asymmetry does not go away. What I can do is keep the original problem written down somewhere visible, in the words of the person who raised it, and check the finished thing against that rather than against the specification we wrote in between.