Résumé (PDF)

Work

The good stuff

Five projects, biggest first.

  1. Off-cycle hotfix releases: 4+ per week before, 0–1 after.Before4+ per weekHOTFIXHOTFIXHOTFIXHOTFIXAfter0–1 per weekHOTFIX

    Four hotfixes a week is not a release schedule.

    Status: 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%.

    • Off-cycle hotfix releases: 4+ per week → 0–1
  2. Before: every item got two reviews, and a third depended on unreliable answers. After (planned): AI-answered screening sends each item only to the reviews it needs.BeforeitemreviewreviewreviewAfter (planned)itemAI-answeredscreeningreviewnot needed

    Everything gets reviewed twice. Does it need to?

    Status: 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.

    • 95% accuracy gate before anyone relies on it
  3. In one release, the triage workflow reviewed 114 items and recommended 16.114 items16 recommended

    Ten workflows, seven dashboards, zero copy-paste.

    Status: 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.

    • 75% less sprint reporting time
    • 114 items reviewed → 16 recommended for acceptance testing
  4. Redesigned record panel: a visible grayed-out submit button and an ‘Unsubmitted Draft’ status.StatusUnsubmitted DraftSubmitvisible, grayed out

    What do you mean it was never submitted?

    Status: Shipped

    People thought they’d submitted records they never had. With a strict budget and borrowed developers, I ranked two apps’ backlog by user pain and shipped the smallest fix for each, starting with that one.

    • 2,000+ users
    • Questions down approximately 50%
  5. Before: requests bounced around email. After: one form routed them automatically.BeforeAfterformrouted

    You get an email, you get an email, everyone gets an email!

    Status: Shipped

    Our highest-priority requests lived in messy email chains. I swapped them for a structured form with automated routing, and it handled 1,000+ requests by the time I left.

    • 1,000+ requests

The complaint is rarely the problem.

Everyone was right that it hurt. The cause was usually somewhere else.

  1. What people said: “Another hotfix this week?”
    What was actually wrong: Nobody had a clear picture of what was going into each release, or what risk each ticket carried.
    What I bet on: Track it. Then an AI review that runs on my rules, with people making the calls.Release Risk Review →
  2. What people said: “Reviews take forever.” (the #1 complaint in a lab-wide survey)
    What was actually wrong: Screening answers were too unreliable to use, so every item got two reviews by default, and the third was hit or miss.
    What I bet on: An AI that answers the screening questions, trusted only after it clears a 95% accuracy gate.AI Review Routing →
  3. What people said: “Which team has room?”
    What was actually wrong: The answer lived in hundreds of tickets. My first fix, a spreadsheet, needed four manual data pulls every refresh.
    What I bet on: Read the sources people already keep up to date instead of adding a new one.AI Toolkit →
  4. What people said: “My record was submitted, right?”
    What was actually wrong: A hidden button and a “New” status that looked like success.
    What I bet on: Three small UI changes, not a redesign.Lab Review System →
  5. What people said: “Can you expedite this?” (by email, missing key details)
    What was actually wrong: No standard intake and no tracking for urgent work.
    What I bet on: Structured intake with automated routing.Expedite Request Intake →
  6. What people said: “Our clients can’t afford us.” (about three paid late or stopped paying)
    What was actually wrong: Small clients took just as much work as bigger ones (brand talks, iteration, outlining, building) for a fraction of the pay.
    What I bet on: Fewer, bigger clients: mid-size firms with budget but no in-house design or dev team.Tech Handoff Market Pivot →

Smaller stories, same habit

Strategy

Our clients can’t afford us.

Strategy · Tech Handoff · 2021–2022

Small clients kept paying late or not at all. I pitched a pivot to mid-size firms with budget but no in-house design or dev team. The company still targets them, and still asks for my advice when it needs it.

Pivot adopted; still the company’s target segment

Status: Adopted · still the target segment Read the case study

A two-by-two chart of budget versus having an in-house team. The pivot moved from small businesses with little budget to mid-size businesses with budget but no in-house team, skipping large companies that already have IT.budgethas an in-house IT / design teamsmall localbusinesseslarge companies“they don’t need us”mid-size businesses:has budget, no team

Analyses for leadership

  • “Done” isn’t done.

    Analysis · current role

    I audited the tracker against the actual code and found 3 features marked complete that had never been built. The plan changed from “verify and close” to “build.”

  • The cost of changing your mind mid-project.

    Analysis · current role

    I found 20% of work items were sent backward in the workflow at least once, and reworked items spent up to 9 times longer than normal in testing. UI-heavy work kept bouncing back. Now devs and I work through the design from the start, so small fixes happen before code review, while they’re cheap.

  • Why the outage happened.

    Analysis · current role

    I traced a production outage to two changes that shipped before a service they depended on. We got a quick hotfix out and held a retrospective.

Tools from the internal toolkit

  • What’s actually stuck?

    Internal product · current role

    A blocker map that groups every flagged item by what’s blocking it (another task, a product decision or an outside vendor) and highlights flags that have gone stale.

  • Which number is right?

    Internal product · current role

    Status numbers kept drifting between the leadership slide, the wiki and the tracking sheet. Now one workflow updates the slide and the wiki from the sheet, then checks that all three agree. Used across 5 initiatives.

  • Never the person who built it.

    Internal product · current role

    Picking who presented at sprint demos wasn’t consistently fair. Now a workflow picks the work worth demoing and rotates presenters. The team sees it as fair.

  • Gut feel, now with weights.

    Hiring · current role

    Interview panels needed a consistent way to score candidates. I built a weighted rubric, plus scenario questions drawn from the skills that matter most, so every panelist scores against the same yardstick.

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

I build things on my own time, too.

So I know what I’m asking engineers for. This site (rebuilt with AI in about 3 days), a Rails app built in 5 days and a senior capstone that isn’t a Pokémon card inventory.

See the side projects →

Autumn’s pencil sketches of the HirePurpose app screens.
Sketched data model for Room Reserve: rooms, reservations and customers.RoomsReservationsCustomers

Let’s talk before one of us closes this tab.

I’m looking for a product manager role, ideally on an AI product. If that’s your team, email me.

Color theme