The value of software is its usefulness. That sounds obvious, but it's genuinely easy to forget when you're three levels deep in a data model wondering how to persist something. The domain bleeds into the implementation and the user disappears.

Jobs to be done is a useful corrective. Instead of asking "what does the system need to store," ask "what is the user trying to accomplish." The difference shows up immediately in the UI. A generic "Edit profile" form asks users to figure out which fields matter and what changing them triggers. A "Change name" action (maybe you got married) and a "Change address" action (maybe you moved) makes the intent explicit, the side effects predictable, and the form much shorter.

Those side effects matter. A name change might need a notification sent, a PDF reissued, a partner system updated. An address change probably triggers different things. When you model these as distinct jobs, the domain logic stops hiding inside a blob of conditional update code and becomes visible. Which is also why JTBD maps so well onto event modelling: the job is the command, the outcome is the event, and the side effects are explicit. The model earns its complexity.