AI Product Development Team

I built it the way I'd structure a real product team. Each agent owns one part of the lifecycle and nothing else.

An orchestrator sits at the front. I tell it what I want in plain language and it works out who should do it, in what order, and writes the brief for each step. From there the designer takes discovery, definition and design, the part where research turns into a concept and a PRD. The builder takes that and writes the actual code, tests and deploys.

The marketer handles launch and go-to-market, though that's the leg I've leaned on least so far.

The point isn't that one model does everything. It's that each agent has a narrow job and a clean handoff, the same reason a real team splits work by role. A designer thinking like a designer beats one generalist prompt trying to hold the whole thing in its head.

These are the six phases I organize everything around: discover, define, design, develop, deploy, then measure and learn. Two decades of product work and the arc is always the same. On the system side, every skill the agents use is mapped to one of these phases, so work always has a place to land. The diagram looks linear, but in reality the phases overlap constantly. This is not a waterfall. And it's a loop, not a line: what I learn in measure and learn feeds straight back into the next discover.

On top of that, I run it proto first. Before the heavy define and design work, I get to the fastest possible prototype that makes the idea concrete. You could always throw together a prototype quickly if you knew how, but it was a dummy, clickable and hollow. The difference now is that the agents build a real, working version almost as fast, so what people react to is the actual thing, not a facade.

Here's the part people get wrong: I don't hand the prototype over and watch people use it. The prototype is there to carry a conversation, not to be tested. First I walk through how the person actually behaves day to day, not how the official process says they work, where it hurts, and what they're really trying to get done. The needs and the real problems surface right there, in their own words, before the prototype is even on the table.

Then I bring it out: if you hold this against your own experience, could it work? That's what opens the real conversation, with internal stakeholders and with actual customers.

Only once the direction holds up do I go into the detail: the specs, the precise definitions, the proper build per phase. Doing it in the other order is how teams spend months specifying the wrong thing in high resolution.

This is the same shape as my Growth Concepts work for clients: get to a working prototype fast, then validate the direction and the real needs before anyone commits to the full build.

There's one rule I won't drop: agents don't hand off to each other directly. When one finishes, the result comes back to me, and I decide what happens next.

It's slower than full automation, on purpose. It's the gate that stops one agent quietly building on top of another's mistake. If the designer got the concept slightly wrong and the builder runs with it, you don't find out until you've built the wrong thing. The human check between steps is cheap. Rebuilding is not.

Underneath all of them sits the same foundation as the rest of my setup: the Second Brain in Notion and a library of more than a hundred skills the agents draw on. So a "designer" isn't a blank model, it's one that already knows how I work before it starts.

The orchestrator plus the human gate is the actual product here. The individual agents are almost the easy part.