How I Work

I solve problems at three levels: Product, Team, and Organization.

Most design and product challenges aren't isolated. A stuck roadmap isn't just a planning problem. Low team velocity isn't just a process problem. When features ship but outcomes don't improve, that's not a design problem. These are system problems.

I operate across three altitudes, moving between them based on where the actual constraint lives. Whether working as an embedded team member or transformation consultant, the approach is the same:

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 altitude 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). Often it's an organization problem (conflicting priorities, no shared understanding of success).

I use AI extensively here. For rapid prototyping and concept validation, AI generates interface variations faster than traditional design tools. For user testing, AI helps analyze qualitative feedback at scale and surface patterns human review might miss. For business and organizational analysis, AI processes stakeholder interviews, strategy documents, and meeting notes to identify contradictions and missing context. This doesn't replace human judgment. It accelerates pattern recognition so we spend time on decisions, not data processing.

I use tools and frameworks where they're useful: Jobs to be Done, Design Thinking, Lean Startup, Design Systems, OKRs. But tools don't solve problems. Decisions do. My job is helping teams make better decisions faster.

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.