What making an AI my CTO taught me about being a PM

I built a tiny side project called Scrawlface: draw a scrawl, drop some eyes on it, and a face emerges from the chaos (pareidolia). I built it specifically to have something real to point an AI coding agent at. I'm moving into agentic AI product roles, and the fastest way to learn is by doing. What I didn't expect was how much it would teach me about the parts of PM work I'd been getting away with doing badly.

At first, working with an agent felt like flow. You say "add this," "fix that," it happens instantly. A few days later, the agent has no memory of why anything was built the way it was. Half-finished ideas sit in the code. There's no record of what got decided. The real problem isn't whether the AI can write good code. It mostly can. It's whether you stay the person running the product, instead of the person who started the conversation and then drifted.

With a human team, someone usually fills the gaps for you. Vague specs get clarified in Slack. Undecided scope gets nudged in standup. With an agent, nothing fills the gap. You feel it immediately.

I wrote a CLAUDE.md file at the root of the repo. A standing brief for whoever, or whatever, opens the project: what the product is, how the stack works, how I want decisions made. The line I keep coming back to: "I own the product and user outcomes. You own how it gets built." That's the contract.

On top of that, I built a compressed version of how I'd run a real team: capture fast, explore before building, turn that into a readable plan, execute against it, review the work, fold in outside opinions, document what changed.

The part that matters most is the gap between explore and execute. Exploration produces a markdown plan file with checkboxes and a progress percentage. That's where I show up as the PM, push back on what I don't like, before anything gets built. Same gate I'd want before an engineer starts coding from a one-line Slack message.

An AI agent doesn't carry context between sessions. If a decision isn't written down, it didn't happen, as far as the next session is concerned.

The plan file isn't a to-do list. It's the project's memory.

When I ran a full layout redesign, the plan ended up with a critical decisions section: why the canvas got sized one way, why a simpler fix broke the proportions, what got added mid-build that wasn't in scope. None of that lives in the code. All of it lives in that file. When the session got cut off halfway through, picking it back up needed no re-explaining. The file remembered for both of us.

That's the thing I'd tell another PM: the plan isn't documentation of work that already happened. It's the interface you're actually managing through.

The layout redesign went through the full process. Most of what came after was small: remove the download button, remove a counter nobody needed. Those didn't need the full ceremony. I said "remove it," and it happened, including parts I hadn't thought to check, a mobile toolbar grid, a leftover localStorage entry, an event handler still wired to a button that no longer existed.

Nobody throws a party for a deleted button. But clearing it out felt better than half the features I've shipped. Deciding what not to have is a real decision. It's the easiest one to keep deferring when nothing's actively broken. With a human team there's a real cost to asking someone to spend an afternoon on a button nobody's using. With an agent, that cost is basically zero, and the excuse goes with it.

Early on I ran the full eight-step process for everything, even the tiny stuff, because the workflow said so. Wasted ceremony. "Remove this button" doesn't need an exploration phase. Small changes go straight to execution now. Explore-and-plan is for anything touching layout, data, or more than a couple of files.

The other thing: I skipped documentation after the first big change, and the next session started colder than it should have. CLAUDE.md and the plan files are the only long-term memory this setup has. If I don't keep them current, I'm the one who loses the thread. I only noticed that once the thread was already gone.

Working with an AI engineering team didn't teach me new PM skills. It mostly removed the slack that let me get away without the old ones.