How I Work

I work across the full stack of product design: from research and strategy down to production code.

Most design problems are system problems. A confusing interface usually traces back to unclear requirements. A slow team usually has a coordination problem, not a talent problem. I look for the actual constraint, then work at the level where fixing it has the most leverage.

Three levels where I operate, depending on what the situation needs:

Flight Levels

01 Product level

UX strategy, design systems, interface design. This is where most people expect design work to happen. I use research to validate assumptions, prototypes to test direction, and metrics (HEART framework, task completion rates, user satisfaction) to measure whether what we built actually works. Product work is always connected to business goals: revenue, efficiency, customer acquisition, retention.

02 Team level

How the team actually operates. Agile or not, most teams have coordination drag. I establish product roadmaps that connect to strategy, implement lean validation cycles (build, measure, learn), and create working agreements that reduce friction. The goal is velocity with quality, not just shipping features faster.

03 Organization level

This is where transformation happens. Culture, decision-making patterns, how design and product fit into the broader business. I've worked through shifts from waterfall to agile, from project-based to product-based thinking, from feature factory to outcome-driven teams. The work here is diagnosing why good intentions don't translate to results and changing the conditions that create the problem.

How I Work in Practice

A Discovery

When I join, I start with observation and questions. What decisions are being made? Who makes them? What information do they use? Where does work get stuck? I look for patterns, not symptoms.

B Diagnosis

This is where I figure out what's actually happening versus what people think is happening.

For product challenges, I map where you are in the product lifecycle. Introduction phase products need different approaches than mature products. A SWOT analysis shows strategic position. Product maturity assessment reveals whether you're optimizing features or need fundamental rethinking. Market and competitor analysis clarifies if you're solving a real problem or chasing feature parity.

For team and organization challenges, I analyze the business model (Business Model Canvas), stakeholder dynamics, and decision-making patterns. Often there's a gap between stated strategy and actual resource allocation. Finding that gap explains why good teams produce mediocre results.

C Execution

After diagnosis, I work at the level where the constraint actually lives. Sometimes that's a UX problem (confusing interface, poor information architecture). Sometimes it's a team problem (unclear ownership, no feedback loops). Sometimes it's organizational (conflicting priorities, no shared understanding of success).

I build throughout this phase. Prototypes in Figma, working code with Claude Code, design system components, interaction specs. AI is my daily production tool: it generates interface variations faster than traditional methods, helps analyze qualitative feedback at scale, and accelerates pattern recognition across large data sets. But AI doesn't replace judgment. 25 years of seeing what works and what fails is what makes AI output useful instead of just fast.

Frameworks (Jobs to be Done, Design Thinking, Lean Startup, Design Systems) are tools, not religions. I use them where they help and skip them where they don't. What matters is making better decisions faster and shipping the result.

Working Together

I Boundaries

I build capability, not dependency. Whether the engagement is 6 months or 6 years, the goal is making teams more effective, not indispensable.

I don't avoid hard conversations. If something isn't working, I'll say it. Directly, calmly, with reasoning. I've been on the receiving end of too much corporate euphemism to inflict it on others.

I don't optimize for looking busy. Some weeks involve intensive workshops and collaborative sessions. Other weeks I'm in the background reviewing work, asking clarifying questions, unblocking decisions. Value doesn't correlate with visible activity.

II What I Need From You

You have the domain knowledge. I bring design and product thinking.

You know your constraints (budget, timeline, politics). I'll work within them or tell you when they're creating the problem.

You want honest input, not validation. If you need someone to agree with every decision, we're not a fit.

Progress matters more than process. I'll use agile, lean, waterfall, whatever works. The methodology is a tool, not a religion.

III How We'll Work

I prefer working embedded with teams (remote or hybrid) over arms-length consulting. Better decisions happen in conversation, not PowerPoint decks.

I communicate directly. Weekly updates on what's working, what's not, what needs to change. No surprises.

I expect the same honesty back. If something I'm doing isn't useful, tell me. If priorities shift, tell me early.