I expected this role to teach me tools and process: how to write a specification, how to run a workshop, how to structure a backlog. It did teach me those. They were not the important part.
Slowing down at the start
My instinct has always been to move quickly towards an answer. Business Analysis has taught me that the beginning of a problem is the one place where moving slowly pays for itself, because everything downstream inherits whatever misunderstanding you started with.
Precision about words
I did not expect vocabulary to matter this much. A surprising number of disagreements turn out to be two teams using one word for two things: approved, active, complete, submitted. Getting definitions written down early feels pedantic and is consistently worth it.
Comfort with ambiguity
Early on, an unclear requirement felt like something had gone wrong. Now it feels like the normal starting state. The job is not to be handed clarity. It is to produce it.
Thinking about people, not features
The shift from "what should this do" to "who is doing this, and what is their day like" changed most of my output. It is the difference between a system that is technically complete and one someone can actually work with.
Being wrong earlier
The most practically useful habit I have picked up is trying to be wrong as early and as cheaply as possible: sketching something badly, showing a half-formed understanding, asking a question that might be obvious. Being wrong at the requirement stage costs a conversation. Being wrong after release costs a great deal more.
I am still early in this. But if I had to name the one thing that has changed most, it is that I am much less interested in appearing to understand something and much more interested in actually understanding it.