Résumé (PDF)

Product manager. Hands-on builder.

I figure out what’s actually broken and fix it, often with AI.

See the work →
Autumn Willard

A few things I’ve done

  • Four hotfixes a week is not a release schedule.

    In use

    Severe defects kept shipping because nobody knew exactly what was in a release. I started tracking it, then built an AI risk review that runs on rules I wrote. Severe defects fell ~85%.

    ~85% fewer severe defects

  • Everything gets reviewed twice. Does it need to?

    Approved · in build when I left

    Slow reviews were the lab’s top complaint. The real cause was a screening form nobody could trust: every item got two reviews by default, and a third hinged on answers that were often wrong. I designed the lab’s first AI review product to answer it, and got it approved for build.

    ~70–80% fewer manual reviews (projected)

  • Ten workflows, seven dashboards, zero copy-paste.

    In use

    Four engineering teams ran on hand-copied status numbers and one-by-one ticket reviews. I built them an AI toolkit, and it started turning up problems nobody had spotted yet.

    10 workflows · 7 dashboards for four engineering teams and their managers

See all the work →

How I think

The complaint tells you where it hurts. Not why.

Most of my best work started with somebody annoyed. At the lab, it was “reviews take forever.” The screening answers that decided who reviewed what were too unreliable to use, so every item got two reviews, just in case. So I went after the bad answers, not the reviewers.

I take the complaint seriously, then go find the cause. Usually that means walking the system like a brand-new user, reading the code or querying the data. It rarely means building the first thing someone asked for.

I’d rather be honest than impressive.

If a number is projected, I say projected. If a project hadn’t shipped when I left, I say that up front. And I say “we” when it was we.

How I work

Five habits, in the order I use them

  1. Find the problem behind the complaint. “My record was submitted, right?” turned out to be a status label that said “New” when nothing had been submitted.
  2. Size it with data. Before I pitch a fix, I want to know how big the problem is: a survey, reviewer comments, ~200 defects in a spreadsheet.
  3. Read the code before writing the spec. It’s how I found 3 features marked complete in the tracker that had never been built.
  4. Pick the smallest bet. Three small UI changes instead of a redesign. A form instead of a core-system feature. Ship the thing that fixes the problem now, and scope the bigger version next.
  5. Measure it, even when nobody else is. When my manager asked for our escaped defect rate, nobody was tracking it. So I built the tracking, then used it to find where the bugs came from.

How I use AI

AI does the legwork. I decide what it’s allowed to touch.

I build AI workflows for my own teams, and I wrote the evaluation plan for an AI that would have to be trusted with regulated content. Same rules either way:

  1. Do it by hand first, then make it repeatable. Every workflow I’ve built started as a task I did manually with the AI. The corrections I made along the way became the rules it follows.
  2. Keep a human in the loop until the AI earns more. A new workflow drafts, and I approve. My toolkit now updates tickets itself, but only after test runs showed its edits were right and didn’t break anything else. Where it slipped, I added a rule.
  3. Use the source of truth people already maintain. My capacity report reads the staffing spreadsheet managers already keep, instead of inventing a new one for them to forget.
  4. Verify before trusting. I compare workflows against a no-AI baseline, reconcile dashboards against my own hand counts and check the tracker against the actual code.
  5. Keep improving. Every tool has its own backlog, same as any other product. (One item on mine: a single run that handles the whole release week.)

See it in practice: how I ran this site’s AI build →

A loop of five rules: do it by hand first, keep a human in the loop, use the existing source of truth, verify before trusting, keep improving.1Do it by hand2Human decides3Use the existingsource of truth4Verify againsta baseline5Keep improvingback to the start

A little more about me

I live in Northwest Arkansas. Off the clock, you’ll usually find me hiking (or just outside), spending time with my kids or reading.

I still sketch before I spec, sometimes on the back of a handout during a meeting I didn’t strictly need to pay attention to. (Sorry, whoever was presenting.) And I build things on my own time. See the side projects →