What Guides My Product Work

You can’t improve something you don’t understand. So I start with context — the users, the system, the history, the things that aren’t written down. I ask a lot of questions. I try to understand how things actually work before I decide how to change them.

And I pay attention to the quiet work: the documentation, the decisions, the conversations that don’t happen in a standup. That’s where trust is built. That’s where clarity comes from. That’s what holds a product together over time.

What I Believe

• The ticket is rarely the real problem
• “What should we build?” is often the wrong first question
• Users are experts in their own pain, even if they can’t describe the solution
• Shipping is just one part of a good release - rollout, communication, and follow-through matter just as much
• Internal trust is a product too
• Being the calmest person in the room is usually more useful than being the loudest

How I Make Decisions

I don’t follow one framework or method. I ask a lot of questions. I try to surface assumptions. I write things down so the conversation doesn’t reset every week.

When a request comes in, I look for the underlying friction. Is this a symptom of something deeper? Do we actually understand the problem? Has this come up before? What’s the real impact?

I’m comfortable working in ambiguity, but I try to reduce it for others. My goal isn’t just to ship features — it’s to help the team feel like they know why we’re building what we’re building, and how to talk about it when someone asks.

Where I’m Still Learning

Designing for scale
I’ve spent a lot of time making things work within messy systems. Now I’m learning to think upstream — to design systems, features, and decisions that still make sense a year (or five) from now.

Measuring what matters
I rely heavily on user instinct and qualitative signals, but I’m deepening my comfort with metrics and learning how to pair empathy with data to tell clearer stories and spot patterns I might miss otherwise.

Letting systems carry the weight
I’m learning how to document and structure my work in ways that make it durable — so others can pick things up, run with them, and still feel confident, even if I’m not in the room.

Sharing what I know
I’ve absorbed a lot just by doing the work, and I’m learning how to articulate it. In documentation, in mentorship, in writing. Not just what I’ve done, but how I think and why it worked.

Zooming out
I’ve gotten really good at solving the problem in front of me. Now I’m learning to ask bigger questions — about the market, the strategy, and the long game — and figuring out how to tie daily decisions to a larger story.