How I work

What I do inside a product organization

Four parts of the job. In each, the hard part is a decision: upstream, what should exist, and downstream, whether what was built is good enough. Coding agents don’t take either off my hands.

Turn ambiguity into a decision

The product works, and nobody can say what it’s for anymore. Three people hold three accounts of the problem, each partly right, and the decision waits because it means telling somebody no. So I:

  • Hear everyone. Every person who owns a piece of it.
  • Name it. One sentence the room recognizes.
  • Settle the trade-off. What’s given up, agreed in the room.
  • Make it real. Something concrete enough to judge.

Midwest Couriers · 450+ trucks

I assumed the answer was a map. I had not asked anyone who does the job.

Each dispatcher manages fifty drivers at once. Watching them work turned my assumption over: they knew every location code by heart, and what slowed them down was scrolling through lists.

  • 30%roughly, off the time to clear the board each cycle
  • 25%roughly, off wrong-vehicle dispatches
The Midwest Couriers dispatch view: orders on the left and drivers on the right, each on a live map of the Twin Cities, with one order’s details open over the map.
The full account →

Build the system everyone builds from

Four teams have built the same data table four ways, and nobody is sure which is right. The AI tools they build with see all four and generate a fifth. So I:

  • Find the repeats. What has been built twice.
  • Draw the line. What is shared, and what stays local.
  • Build the foundation. In design and in code.
  • Name the owners. Who can change it, written down.

SAP practice · 40+ enterprise apps

Nobody could say whether any of it was working, because nobody was measuring it.

Someone in the field might open four apps before lunch and relearn the layout each time. So we built one style guide and component library, with checks in the release process, and it kept working after I left.

  • About a thirdless time from design to development
  • About halffewer UI defects in production, quarter over quarter

More recently there is Sprout, a design system for Cargill. Its tokens live in the code, and it is also a Claude Code skill, so the team’s AI tools build from the same source the people do.

The SAP enterprise platform: one style guide and one component library across a suite of apps.
The full account → The design system behind this site →

Own an initiative end to end

An initiative that matters is funded and staffed with engineers, and it moves sideways, waiting on design decisions nobody is placed to make. I own its design from inside the team, in its standups and its repository, including the parts nobody volunteers for:

  • The research. Who uses it, and what they need.
  • The states. Empty, loading, error, and done.
  • The edge cases. What happens when the data is wrong.
  • The pull-request comments. Design review where the code is.

Nutrition Incentive Hub · USDA-backed, eight months

Grantees spent more time chasing paperwork than running their programs.

The network ran on old software, spreadsheets, and workarounds, and no two of them agreed. For eight months I led product design inside that effort, from the interviews to one portal that replaced all of it.

  • ~10 hrsto process a data request, down from 45 to 55 hrs
  • ~2×the grantees served, without adding analysts

It ended with a documented design system and a component library the team could extend without me.

The Nutrition Incentive Hub on a laptop and a phone: the program-finder site and a transactions-by-firm chart.
The full account →

Build to find out

There are ideas, sketches, and a demo or three, with pressure to make one of them real. Nobody can say which is worth building, because nothing exists that anyone can use. With coding agents, a working version takes days, so the job is judging it:

  • What comes first. The piece worth building before any other.
  • What it may claim. No more than it can do.
  • What happens next. Build it, kill it, or park it.

Lucy Learns · my own product

AI built working versions in an afternoon. I judged them.

A training app for my own household. The trainer’s handouts were written for someone sitting still, and practice happens in a hallway with a leash in one hand.

At first the app listened for spoken commands. That came out after a couple of real sessions, because Lucy heard every command as hers.

  1. The Lucy Learns splash screen: the app name in a tall serif above an illustration of a black Labrador and her person crouched nose to nose, with the build version below.

    01 Built for one dog in particular

  2. Lucy Learns home screen: the Calm Door Greetings track and today’s homework with a Start session button.

    02 Today’s session, already chosen

  3. End of session: ready for the next step, with the next level saved and the next activity queued.

    03 End on a win, next one queued

The full account →

On a team

The people who will own the work build it with me, and the reasoning is written down as each call is made. That includes the designers: I’ve mentored the ones who joined me at RBA, and a client’s production designer on Innovators Studio.

A foundation the team can’t extend without me is rented, not built.

If this is the job

I’m looking for a senior product design role where this is the work: in-house, remote, or hybrid in the Twin Cities, with a team that can hire in Minnesota. A few sentences about your team are enough to start.

Start a conversation

or write to adam@adamhickey.com