How I work · The product has become complicated

Turn ambiguity into a decision

Turn a complicated product into one agreed problem, a sequence of decisions, and a direction the team can judge.

When this is the job
A working product with competing priorities, or three accounts of what the problem is
How long it takes
A few weeks: the problem in a sentence first, then the sequence, then something concrete enough to argue with
What it asks of the team
One person who can make the decision, a few short conversations with whoever owns a piece of the problem, and one session to decide
What it leaves behind
An agreed problem, an ordered set of decisions, a tangible direction, and the reasoning in writing

The situation

The product works, and nobody can say plainly what it is for any more. Every release adds to it, and the roadmap is a list of requests rather than a position. Three people in the room have three accounts of the real problem, each partly right, which is why the conversation never resolves and the decision that matters keeps getting deferred: making it would mean telling somebody no.

That is the moment this page is about. Not a redesign, and not a discovery phase that ends in a deck: I get the problem stated in a sentence everyone recognizes, and put something in front of the room concrete enough to judge together. Clarity before commitment.

Where it has worked

One project where naming the real problem was the turn. The figures are the case study’s own.

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. Sitting with them and watching them work turned my assumption over: they knew every location code by heart, and what slowed them down was scanning through endless lists. Naming that changed what got built, and the cards were tested with the people who would use them.

  • 30%roughly, off the time to clear the board each cycle
  • 25%roughly, off wrong-vehicle dispatches

That reframing is the first thing I do on a complicated product. There it went on to become the build, which is the usual order: the sentence, then the sequence, then the thing to argue with.

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, with the screens →

How it goes, step by step

Four steps, each with something to show for it. The example under each one is drawn from the same example company, so the four add up to one story: a field-service business, eight years on one platform, three teams. Dispatch books the job, technicians close it on a phone, billing reconciles it after. The same job now exists in three places, and the roadmap holds forty requests and no position.

  1. Hear the problem from everyone who owns a piece of it

    Separately, and quickly: product, engineering, support, whoever fields the complaints. Where the accounts diverge is usually where the real problem is.

    e.g.Three accounts of one handoff. Dispatch blames the scheduling screen, technicians the phone app, billing neither.

    Adam at the end of a meeting table with a notebook open, listening to four people from different parts of the company, one of them mid-sentence.

  2. State the problem in one sentence

    One sentence the whole room recognizes, including the people it constrains. Most of the value is here: a problem everyone can repeat back stops being reopened every other week.

    e.g.One sentence the whole room can repeat. One job lives in three places and nobody owns the reconciliation.

    Three teammates at a table, one of them speaking with a hand toward the whiteboard behind them, which carries a single line.

  3. Sort what follows into an order

    What to decide next, what can wait, and what is a symptom of the first thing. A sequence, not a backlog. A backlog is what you already have.

    e.g.The shared job record goes first. The rest are symptoms of it, and eleven of forty requests come off the roadmap.

    Over a shoulder at a monitor: a column of six cards with one pulled out of line under the cursor, a hand on the mouse, a teammate in a small call thumbnail.

  4. Make it tangible enough to judge

    Flows, a working prototype, whatever the decision actually needs. A visible direction makes a far better conversation than another description of one.

    e.g.A prototype run on last week’s real jobs. The decision gets made against it.

    Seen from above: a phone showing a rough tap-through prototype, a printed one-page sheet, a pencil and three small sketched screens on cards.

What it asks of the team

  • One person who can make the decision, or get it made
  • Four to seven people who own a piece of the problem, for about forty-five minutes each
  • The product and the roadmap as they actually are, not as presented
  • One working session, about half a day, where the decision gets made

When it is one of the other three

Questions people ask

How long does it take?
A few weeks, not a quarter. The problem is heard from everyone who owns a piece of it, stated in one sentence, sorted into a sequence and made tangible enough to judge, and the decision is made against that.
Is this something you do alone?
No. The problem is heard from everyone who owns a piece of it, and the decision is made in a room with the people it constrains. What I do alone is the writing: the sentence, the sequence, and the reasoning behind each call.
What does the team need to give?
One person who can make the decision or get it made, four to seven people who own a piece of the problem for about forty-five minutes each, the product and the roadmap as they actually are, and one half-day working session where the decision gets made.
What does the team leave with?
An agreed problem, an ordered set of decisions, a tangible direction, and the reasoning in writing.
Where has it worked?
On a dispatch floor at Midwest Couriers, where the assumption I walked in with turned out to be the problem, and naming the real one changed what got built. The case study carries the figures.
Is this a role or an engagement?
A role, first. I am looking for a senior product design role where this is the work, in-house and remote, with a team that can hire in Minnesota. I also take select independent engagements, where the same steps run as a fixed piece of work with an end date.

On a team

The person who hears the problem in the first week is the person who writes the sentence, sorts the sequence and puts the direction in front of the room. The reasoning behind each decision is written down as it is made, not assembled afterwards. That way the next hard call is one the team can make on its own, without digging back to find out why things were decided.

If this is the job

I’m looking for a senior product design role where this is the work: in-house, hands-on, remote, with a team that can hire in Minnesota. A few sentences about what is happening with your product are enough to start. I also take select independent engagements.

Start a conversation

or write to adam@adamhickey.com