💡 Philosophy

My ideals, principles, and approach to work

I find people and organize chaos.

That's been the pattern my whole life - whether I was running a music production business, supporting executives at IBM, executive producing video projects, or mentoring 500+ advisors at Apple. I see how systems work, spot where they break down, and connect the right people to fix them.

Nothing is about me. You can't lift a car alone.

Product management isn't about individual achievement - it's about making the team successful. My job is to take the heat so engineering can focus on building great things. I own the what and why. They own the how. When something succeeds, the team gets credit. When something fails, I ask myself first: did I ask the right questions? Did I lose something in translation? Did I hallucinate information?

Build for real problems, not theoretical ones.

I've spent 13 years working with advisors. I know the difference between tools that look good in demos and tools that actually help people do their jobs. The note organization tool I'm building isn't based on a hypothesis - it's based on watching hundreds of advisors struggle with the cognitive shift from thinking in narrative to forcing structured output. Meet users where they are, not where you wish they were.

Say no to many things. Say yes to very few.

The hardest part of product management isn't deciding what to build - it's deciding what not to build. I've seen organizations say yes to everything: every feature request, every trend, every stakeholder demand. They built complexity that collapsed on itself. Good product management is about focus. Build things that matter. Say no to the rest.

Design for pendulum swings.

I've been at Apple 13 years. I've worked professionally for 27 years across multiple industries. I've seen pendulum swings - remote work to office mandates, move fast to compliance-heavy, AI hype to AI skepticism. Tools built for one extreme become obsolete when the pendulum swings back. The question is: are we building flexible foundations around fundamental problems, or rigid solutions optimized for today's trends? Foundations survive. Trends don't.
Prototype before committing resources.

I build with local models first because I want to validate concepts before asking for production resources. Can we solve the core problem? Does the approach actually work? What breaks when we test it with real users? Fail small and early, not big and late.

See the forest and the seeds.

I understand both the big picture and the individual contributions that make it work. That's systems thinking - recognizing how pieces connect, where dependencies exist, what breaks when one part fails. Twenty years ago, I thought I just "saw things differently." Now I know that's product management: understanding the whole system well enough to know where to intervene.

I'm the office linebacker.

My job is to protect the team - from unclear requirements, from changing priorities, from pressure to ship faster than is realistic. I take the hits. I absorb the uncertainty. I create space for the team to do great work. Because nothing is about me. It's about making everyone around me successful.