Question everything. Care about the details.
I believe in a healthy irreverence for constraints no one can explain, and a deep respect for the details that help people understand and trust a product.
I’ve spent much of my career working on complex B2B products, and one pattern keeps showing up: products accumulate assumptions. A workflow designed for one customer becomes a convention. A technical limitation becomes a product rule. A configuration option becomes something everyone assumes users need. Over time, those decisions can harden into facts about the product. Teams learn to work around them rather than revisit whether they still reflect how people actually think and work.
I’ve learned to make questioning the constraints around a problem part of how I work. Which constraints are real, and which are inherited assumptions we’ve stopped questioning? What is the user actually trying to accomplish? Does the system reflect how people really think and work? Are we solving the problem, or just making a symptom easier to live with? Some of my strongest work has come from stepping outside those constraints and realizing that the product model, the system, or our approach to the problem needed to change.
Stepping back from the interface doesn’t make the details less important. If anything, it makes them more meaningful. I’m wary of words like craft and delight when they become shorthand for “make it nicer.” They matter when they’re doing something useful you can point to: reducing friction, building trust, making a system easier to learn, or helping someone act with more confidence.
The details are where people feel that the product was made with them in mind. Someone thought about this, anticipated what they needed, and cared enough to get it right.
