The mistake I made for years
Early in my career, I thought my job was to be right. Someone would bring me a design problem, and I would go build a model, run the numbers, and come back with an answer. If the answer was defensible, I considered the job done.
That worked, for a while. It worked well enough that I kept doing it for years. But it is not actually what the job is.
Being right is not the same as being useful
A model can be technically correct and still miss the point of the question someone was actually asking. I spent a lot of time early on producing accurate results to questions that, in hindsight, were not the ones that mattered most to the program.
Nobody tells you this when you start. You get trained to solve problems, not to check whether you are solving the right one. So you get good at the first thing and assume that is the whole job.
The fix was not more technical skill. I already had that. The fix was learning to ask, before I opened any tool, what decision this analysis was actually going to inform. If I could not answer that clearly, I was not ready to start modeling yet.
What changed my mind
It was not one moment. It was a pattern I noticed after enough projects: the work that got used, that actually changed a design or a decision, almost always started with a longer conversation up front. The work that got filed away and forgotten usually started with me jumping straight to the analysis.
That pattern is hard to see in the moment because the analysis itself always feels productive. You are running cases, generating plots, making progress. It is only later, when nobody references the result, that you realize the progress was on the wrong problem.
What I do now
Before I start any significant piece of modeling or design work, I try to write down, in one sentence, what decision this is supposed to support. Not the technical question. The actual decision a person is going to make based on what I hand them.
If I cannot write that sentence cleanly, I go back and ask more questions instead of opening a workbook. This feels slower at the start of a project. It is not slower overall. It removes the rework that comes from producing a technically sound answer to a question nobody was actually asking.
I also changed how I treat early results. I used to hold onto a finding until I was confident in it, then present it as a conclusion. Now I share rough findings earlier, clearly labeled as rough, specifically so I can find out sooner whether I am even pointed at the right target. A wrong early answer, shared early, costs an hour of conversation. A wrong early answer, held until it is polished, costs weeks of rework.
The part I still have to watch
I am not naturally patient with the “what decision does this inform” step. My instinct is still to go build something. That instinct is useful in the right place, and it is a liability if it runs ahead of the framing work.
So I treat it as a discipline, not a preference. On any new problem, I make myself slow down at the start even when I do not feel like it needs slowing down. The projects where I skipped that step are still the ones I remember for the wrong reasons: technically clean work that solved the wrong problem, delivered on time, and useful to no one.
What I would tell someone earlier in their career
If you are good at the technical side, that skill will carry you further than it should, for longer than it should. It will let you avoid the harder skill of figuring out what actually needs solving. Build that second skill on purpose. Nobody is going to make you do it, because your technical answers will look fine without it.
The question that matters most on any project usually is not “what does the model say.” It is “what decision is riding on this, and does the person asking actually know what they need yet.” Ask that one first. The modeling is the easy part.