Every floor plan starts with assumptions.

Where should the kitchen go? Which rooms need to connect? How will people move through the space?

At first, those decisions are lines on paper. Easy to erase.

Then the walls go up — and everyone has to live with them.

Products work the same way.

Their structure begins with assumptions about how people work, what they need, what belongs together, and what should happen next.

Those assumptions become requirements. Requirements become architecture and code. Eventually, what started as a reasonable guess becomes expensive to question.

My work is translating how people actually work into the structure a product is built around — while those decisions are still cheap to change.

That means looking for where the product is organized in ways that conflict with the work people are trying to do. Separating necessary complexity from complexity inherited from old decisions. And helping teams develop a shared picture of the problem before committing to a solution.

I’m a product design leader working in complex, high-consequence domains — scientific software, life-safety systems, healthcare workflows, and AI-assisted tools — usually bridging research, engineering, and the business rather than working inside any one of them. The work has picked up a handful of design and business awards along the way.

I’ve always been drawn to understanding how systems fit together and what else they could become — an instinct that started with taking apart Lego sets as a kid and still shapes how I approach product work.

I’m most interested in complex product work where design can translate structure into direction, not only execute what follows — because the cheapest wall to move is the one that hasn’t been built yet.