For a long time, when I got assigned a ticket, my mind jumped straight to the implementation. Which component, which hook, which endpoint. How do I build this.
Now the first thing I ask is different: what user problem does this solve, and what value does it add to the product?
It sounds small. It is not.
When you start from implementation, you build exactly what the ticket says, even when the ticket is wrong. You ship the feature, it works, and nobody uses it. When you start from the problem, you sometimes realize the ticket is solving the wrong thing, or that half of it is unnecessary, or that there is a simpler path that the person who wrote it could not see.
That question is most of the difference between a developer who closes tickets and an engineer who improves a product. The code skills matter, but they are table stakes. Knowing why you are writing the code is the part that compounds.
It is also the shift that took me longest to make, probably because nobody assigns it as a task. You have to decide to care about it.