Breaking the Handoff

Every product team I’ve worked on ran the same assembly line: product decides, design draws, engineering builds, QA finds out. Context evaporates at every handoff — like telephone at a sleepover. By the end of the line, the detail is gone and all that’s left is one high-stakes decision. If it’s right, you’re really right. If it’s wrong, you’re really wrong, and nobody can tell you why.

Then AI made building cheap, and we got to find out what that actually breaks. This is the story we told on stage to the whole product and engineering department, at an all-team event in October 2026 — a PM, me, and two engineers, front end and back end. Including the parts that flopped.

Act zero: the flops

When AI arrived, we could suddenly build anything, each of us alone. So we did. I built a launch-monitoring app that lied to me for three weeks before I shut it down. A tool I handed to engineering looked like it saved their review notes — until we noticed it was a static webpage doing a very convincing impression of software. A teammate’s prototype shipped only after an engineer rewrote it end to end.

The pattern across every failure was the same, and it wasn’t the tooling: not everyone was in the room. Speed without shared context just produces wrong things faster.

Slide, Early AI adventures: four solo experiments and how each ended. A PM's survey studio shipped after engineering rewrote the code. My launch monitoring app lied for three weeks before I shut it down. A PM's compliance doc portal flopped, started too early without understanding the real problem. My automated UI review looked like it saved engineering's progress until we noticed it was a static webpage. Closing line: AI made it fast to build, but not everything worked, because not everyone was in the room. — From the talk: the flops board.

Act one: one idea, four hands

So on the next project — rebuilding how new agency partners get onboarded and reviewed — we tried the speed together. One idea moved through four sets of hands, and every hop took days instead of quarters:

Our PM didn’t write a requirements document; she built a working app. I didn’t annotate her screens; I rebuilt them — redesigned in code, polished in our design tool with our UI designer. Our front-end engineer then rebuilt the whole thing in the approved stack in an afternoon. And our back-end engineer hardened it into a real product: monitoring, deployment, maintainability.

Hand two: my redesign of the agency review screen, built in code. An agency's details, its agents, and finance and billing, with Deny Agency and Appoint Agency actions. All data is fictional; two document filenames are blurred. — Hand two of four: my redesign, built in code.

Hand four: engineering's hardening checklist, with Datadog, Deployment and Maintainable checked off, captioned A real, maintainable product. — Hand four of four: engineering’s hardening checklist, recreated from the talk.

One idea, four hands. Two of the four are shown here: hands one and three are the PM’s and an engineer’s work, and appear only with their say-so.

No step waited on a document. The artifact itself was the conversation — when engineering had questions, they pointed at a running app, not a figment of a spec. Three shipped milestones in four months, from a process that used to spend that long discovering its requirements were wrong.

The honest middle

Here’s what we admitted on stage, because it’s the interesting part: agency onboarding was still essentially one idea moving through the system faster. Every hand was its own rebuild. Context still had to be re-shared at every hop. We never tried a second direction — we got lucky with the first one. On an earlier project where we weren’t lucky, guessing wrong on the first direction cost half a year.

Speed is the unlock. But only if you use it to test ideas, challenge assumptions, and chart the course — not to build the first guess faster.

Slide: Speed is the unlock. But only if we use it to test ideas, challenge assumptions, and chart our course. — From the talk.

Act two: the build we didn’t start

The next project inverted the order. Instead of starting from “build the thing,” we started together from “what actually isn’t working for the people we serve?” Research first: watching users, reading support conversations, mapping the jobs the experience needed to do. Then prototypes — plural — exploring different possible answers, cheaply, instead of documenting a predetermined one.

We ended up with a genuinely compelling product vision. And then we did the thing I’m proudest of:

We didn’t build it.

Not because the prototypes failed — because everyone had enough shared context to recognize we were holding hypotheses, not answers. Building the full vision would have been a huge organizational bet: not just code, but ownership, maintenance, support, user behavior change. The old process would have shipped it on momentum. Instead we chose the smallest experiments that could tell us whether the bigger bet deserves to exist — while the question of where the long-term experience should live stays deliberately open.

Cheap code doesn’t make building cheap. It makes learning cheap — if you let it.

The line we closed on

AI didn’t teach us how to build faster. It changed how we decide what deserves to be built.

Old model: Decide → Design → Build → find out if we were right.
Now: Discover together → prototype multiple directions → choose a small bet → build → measure → learn → decide what deserves investment next. Repeat.

The delivery machinery that makes the “build” step this cheap — the governed AI pipeline — is its own story: see The Delivery System.