How I work · Ideas everywhere, nothing you can use yet

Carry the direction into something that works

From ideas, sketches and half-decisions to a working product real people can use, in real code, in days, and an honest build, kill, or park call.

When this is the job
Ideas, sketches, maybe a demo or three, pressure to make one real, and no way to tell which is worth it
How long it takes
Days to a working version in real code, and a few weeks of real use before the build, kill, or park call
What it asks of the team
One person who can kill an idea, the people who do the work today, and real inputs; engineers only when the call is build
What it leaves behind
A working prototype, what works and where it falls over, and a build, kill, or park call with the cost of the next step

The situation

The team has ideas. Sketches, a deck, half a decision, maybe a demo or three, and pressure from somewhere to make one of them real. Nobody can say yet which is worth building, who it helps, or what it would cost to run, because nothing exists that anyone can actually use.

Working software is the fastest way to find out. If a prototype that once took two weeks can now be built in two days, the question becomes whether you prototyped the right thing. That judgment is the job: closing the distance between the idea, the interaction and a working thing, with engineers for leverage rather than rescue. The speed you can now get anywhere; where AI helps the build and where it does not, I will say plainly.

Where it has worked

One product where the judgment, not the speed, was the work. Every figure is from the write-up it sits beside.

Lucy Learns · my own product

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

A training app for one household, built when a trainer’s handouts turned out to be written for a person sitting still, and practice happens in a hallway with a leash in one hand. One bet, tightly drawn: run the handouts one instruction at a time, and record enough that “is this working” has an answer. It reads the steps aloud by default and listens only on request, because the two cost different things and listening fails where practice happens.

  • Hoursfor the AI to build working versions of one tightly drawn bet, not mockups to imagine from
  • Weeksof real use before one of those features proved it could not earn its place, and came out

Every decision on that page is mine, and the write-up says which ones the AI made faster and which it never touched. That is the shape of the work on a team, with the team’s problem and the team’s people in place of mine.

  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: Level 1 cleared, ready for the next step.

    03 End on a win, next one queued

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 parts distributor whose inside-sales team still quotes by hand, with fourteen ideas on a list, some of them AI, and one budget.

  1. Find which ideas genuinely help

    And which do not. Most lists have one or two ideas that remove real work, surrounded by a dozen that add a slower way to do something that already worked.

    e.g.Two of fourteen survive contact with the work. The quoting desk and the returns triage.

    A laptop showing a shared screen on a call: fourteen cards in two rows with two of them marked, and a strip of five call tiles along the bottom, Adam at the end.

  2. Cut to one bet worth testing

    One use, defined tightly enough to build and judge. The demos that go nowhere tried to show everything at once and proved nothing in particular.

    e.g.One bet: draft the quote, leave the price alone. The chatbot everyone expected did not make the cut.

    Seen from above: a single one-page brief with a sketched phone screen and one boxed heading, beside a squared stack of index cards turned face down.

  3. Build a working experience, not a mock

    Something real people can use on real inputs, in real code, with the failure cases visible rather than staged away. AI-assisted tools make the build fast; a demo that only works on the happy path still tells you nothing you did not already hope.

    e.g.Built on last quarter’s real requests. A third of them are photographs of faxes.

    Adam at his desk in three-quarter profile, sharing his screen on a call: the laptop shows a phone-shaped app frame with the cursor on one green button, a scanned page beside it, and four small call tiles down the edge of the screen.

  4. Judge it honestly

    Build, kill, or park, with the reasoning and the likely cost of the next step. A prototype that talks you out of something expensive has paid for itself.

    e.g.Kept, with a limit written down. It drafts, a person prices, it never sends.

    A woman in a cardigan using the working thing on a phone at a table while Adam sits across the corner from her, notebook open, watching her rather than the phone.

What it asks of the team

  • One person who can kill an idea, including the one leadership expected
  • The people who do the work today, for about an hour each, and again when there is something to try
  • Last quarter’s real inputs, malformed ones included
  • One session at the end where build, kill, or park gets said out loud

When it is one of the other three

Questions people ask

How long does it take?
Days to a working version in real code, with AI-assisted tools where they speed the build, and a few weeks of real use before the build, kill, or park call. Building is the cheap part; choosing what to build and judging it is the work.
Is the prototype real software?
Yes. It is designed and built in real code on real inputs, with AI-assisted tools where they help, so the build, kill, or park call is made against something people can actually use.
What does the team need to give?
One person who can kill an idea, including the one leadership expected; the people who do the work today, for about an hour each and again when there is something to try; last quarter’s real inputs, malformed ones included; and one session at the end where build, kill, or park gets said out loud. Engineers only if the call is build.
What does the team leave with?
A working prototype, what works and where it falls over, and a build, kill, or park call with the cost of the next step.
Where has it worked?
On Lucy Learns, where the AI built working versions of one tightly drawn bet in an afternoon and weeks of real use made the call, and in the dispatch cockpit prototype, a working AI recommendation on synthetic data. Both are on this site.
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 one bet is drawn, built and judged as a fixed piece of work.

On a team

Whoever hears the ideas in the first week builds the prototype and makes the call. I design it and build it, in real code on real inputs, with AI-assisted tools where they speed the build, and building is the cheap part: the judgment is in choosing what to build and in saying honestly what it proved. Engineers come in for leverage when the call is build, not to rescue a demo that only ever worked on the happy path, and the reasoning behind the call is written down beside it, because the next idea on the list is one the team should be able to judge without me.

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 the ideas on the list and who they are meant to help are enough to start. I also take select independent engagements.

Start a conversation

or write to adam@adamhickey.com