For most of my career the gap between an idea and a working product was an engineering team. I’m a PM. I think in milestones, user stories, and outcomes, not pull requests. I’ve written about how that gap closed for me, but only in pieces. Here’s the whole loop in one place, because it’s how I work now.
The short version is that I run the same process a small product team would run, except the team is me plus Claude Code plus a stack of tools wired together with MCP. The process didn’t change. The number of people it takes to run it did.
The examples below come from Ceres, the garden assistant I built for Kim. The loop is the same whether it’s a garden agent, an RSS reader, or a bird detector sitting on the back deck.
It Starts With a Spec, Not Code
The temptation with AI coding tools is to jump straight to “build me a thing.” That produces a thing, and usually the wrong thing. So I still start with a spec. What’s the problem, who’s it for, what does done look like, what am I explicitly not building.
Writing the spec is where I earn my keep. The model can write code all day. It can’t decide what’s worth building or what to leave out, and left alone it will happily build everything. The spec is me doing the actual product job before a line of code exists.
For Ceres that meant deciding it would not be a general plant encyclopedia. It knows what’s in Kim’s beds, what went in when, and what the weather has been doing. Everything else was a non-goal, and writing that down is what kept the thing from sprawling into a project I’d never finish.
The Backlog Runs Through Gitea
I keep my local-only projects in Gitea, and the piece that ties it together is the Gitea MCP server. That lets Claude read and write the issues directly. So the loop looks like this. I break the spec into issues. Claude picks up an issue, does the work, and updates the issue as it goes. I review, I reprioritize, I close what’s done and open what I found along the way.
It’s the same backlog grooming I’d do with a team, except the contributor reads the whole backlog instantly and never forgets to update a ticket. My job shifts almost entirely to deciding what’s next and whether what came back is actually right.
Who Does What
The division of labor is clear once you live in it. I own the problem, the priorities, the taste, and the call on whether something is good enough to ship. The tooling owns the boilerplate, the first draft of the code, and the tedium of keeping the tracker current.
That split is exactly the part of the PM job I always wanted more time for. The prototyping and the ticket hygiene were never the point. Problem selection and judgment always were, and now that’s most of what I spend my time on.
The obvious limit of running it this way is that nobody argues with me. There’s no staff engineer telling me the schema won’t hold, no design partner pushing back on the form layout, no second customer whose needs contradict Kim’s. That friction is most of what makes product work hard. What’s left is the part I can actually practice alone: deciding what’s worth building, and being willing to throw out something that works because it’s the wrong shape.
The Calls That Were Mine
Ceres has 82 issues in it now. The ones worth writing about aren’t the features. They’re the reversals.
I built Kim an editing surface in NocoDB and closed the issue with every box checked. Then I threw it out. On the free tier it showed her every infrastructure table with no way to hide any of them, and nagged about upgrading on every screen. More to the point, a generic database admin tool is the wrong shape for one person doing four specific things. I replaced it with purpose-built forms and kept NocoDB as my own inspection tool. The schema work from the first attempt carried straight over, so being wrong cost a lot less than it looked like it would.
Then I did the same thing again. Live sensor telemetry was supposed to live in a Home Assistant dashboard. It ended up as a page inside Ceres instead, because asking Kim to switch apps to find out whether her tomatoes need water isn’t a product. Two reversals pointing the same direction stopped being a coincidence and turned into a rule: off-the-shelf is fine for me, not for her.
The smallest decision is the one I like best. Sensor tiles grey out when a reading goes stale instead of showing the last known number. Nobody asked for that. But if a stale reading can still look green, then green doesn’t mean anything, and the whole dashboard is decoration.
Somewhere in the middle of all this I renamed the go-live issue. It started as “all phases complete, seven days clean data, backup validated, Kim onboarded.” It’s now “Kim using it daily, with confidence.” Those are very different bars and only one of them is a product bar. The rename took ten seconds and changed what I built for the next month.
It also worked. Kim opens Ceres in the morning while she’s planning the day, pulls it up out in the beds, and comes back to it in the evening. It’s how she tracks and manages the garden now, not a thing she checks because I built it. It’s also her informed guide. She asks questions with context and she sends photos for feedback. That’s the bar I set when I retitled the issue.
The eval harness is that same instinct pointed at quality. First baseline came back 17 of 21 and failed the gate. Three of the four failures turned out to be badly written test cases and only one was a real bug in the agent. That’s a better first result than a clean sweep, because a suspicious 100% on your own golden set mostly means you asked yourself easy questions.
None of those were decisions a model was going to make for me. It built every one of them once I’d made the call.
Doing It Again, and Again
Ceres isn’t the only one. Six projects in my Gitea repo are substantial enough to have milestones: the garden agent, a local voice assistant, a job-hunt pipeline tracker, a news reader, an engineering intelligence dashboard, and a bird detection system. Different domains, different stacks, same loop.
The reversals repeat at that level too. The news reader is on its third version. The bird stack started as two separate repos and got folded into one when running them apart stopped making sense. Some of my archived repos are archived because the second attempt was better, not because I moved on.
The part I didn’t expect is how much the loop cares who you’re building for. Ceres is for Kim, who never asked for a database and shouldn’t have to know there is one. JobSeeker is for me, so it can be sharp-edged. The engineering intelligence dashboard was for a persona I researched rather than one I live with, which is a harder problem than either. Same process, three completely different definitions of good, and that judgment is the thing that doesn’t come from the tooling.
What the Tooling Doesn’t Give Me
Claude Code writes the first draft and never forgets to update a ticket. It doesn’t carry a pager. It doesn’t have opinions about what we’ll regret in eighteen months. It doesn’t tell me I’m wrong.
An engineering team gives me systems judgment I don’t have, maintenance ownership I can’t fake alone, and disagreement I actually need. I’m not describing a replacement for any of that. I’m describing what happens to the PM half of the job when the distance between a decision and a running version of that decision collapses to an afternoon.
What I’d Bring Into a Team
Not the stack. The thing that transfers is that I can answer “what would this actually feel like” myself, in a day, instead of spending a sprint negotiating for someone else’s time to find out. That kills an entire category of argument: the ones where two people are defending guesses about a thing neither of them has used.
What doesn’t transfer is the speed. Eight engineers, a shared backlog, legacy code and a compliance review are a coordination problem, and coordination is where a real org’s time goes. The bottleneck in most teams was never code volume. It’s alignment and distribution. None of this fixes that.
What it changes is that the PM shows up to the alignment conversation with a working artifact instead of a slide. That’s a smaller claim than the one I see people making about AI and product work, and it’s the one I can back up.
