I wish I had learned this earlier.
Not the frameworks. Not the tools. Not the processes.
Just one habit.
Always ask why.
Early in my career, I was focused on doing things right. Hitting deadlines, delivering designs, following the process. If something was requested, I executed. If a feature was defined, I designed it. If leadership aligned on a direction, I supported it.
And for a while, that worked.
Until it didn’t.
I remember a project where everything looked like a success. We shipped on time. The design was clean. The flows were efficient. Stakeholders were happy.
Users weren’t.
Engagement dropped. Confusion increased. Support tickets went up. Nothing catastrophic, just enough to know something was off.
At first, we treated it like a usability issue. We made adjustments. Tweaked layouts. Improved labels. Smoothed out flows.
It didn’t fix the problem.
That’s when someone on the team asked a simple question.
Why are we solving this problem in the first place?
It sounds obvious now.
At the time, it stopped the room.
Because the truth was, we hadn’t asked it. We had been so focused on delivering the solution that we never questioned the problem. The feature we built wasn’t wrong, it just wasn’t necessary. It solved something that didn’t actually matter to users.
We had optimized the wrong thing.
That moment changed how I approach everything.
From that point on, “why” became part of the process. Not once, but continuously.
Why are we building this?
Why does this matter to the user?
Why now?
Why this approach over another?
And more importantly.
Why does this feel off?
Because it almost always does, before you can explain it.
Over time, I started to notice a pattern. The biggest issues in products were rarely execution problems. They were thinking problems. Problems that came from assumptions that were never challenged.
A roadmap filled with features no one needed.
A workflow that made sense internally but confused users.
A “best practice” applied in the wrong context.
All of it could have been caught earlier with one question.
Why?
As I moved into leadership roles, this became even more important. Teams move fast. There’s pressure to deliver, to align, to show progress. It’s easy to confuse momentum with direction.
Asking why slows things down in the right way.
It forces clarity.
It surfaces assumptions.
It creates better conversations.
And sometimes, it stops you from building the wrong thing entirely.
This is especially true now.
With AI, data, and increasingly complex systems, it’s easier than ever to build something that looks impressive but doesn’t actually help. More capability, more automation, more output.
But if you don’t ask why, you end up adding complexity instead of removing it.
You end up with systems that do more, but make it harder for users to understand what to do next.
That’s the risk.
The discipline of asking why is not about being difficult. It’s about being intentional. It’s about making sure that what you’re building actually matters.
Looking back, the biggest growth in my career didn’t come from learning new tools or processes.
It came from getting comfortable challenging what seemed obvious.
From asking why when it would have been easier not to.
So if there’s one piece of advice I’d give, especially to people earlier in their careers, it’s this.
Don’t just do the work.
Understand the work.
And never stop asking why.