Working with Claude Code as a Product Manager
In October 2025 I took over an entrepreneurship project that had drifted for two months. The team that had been on it was reassigned, and I was told to carry it with AI instead, with fractional support from a UX researcher and an engineer. Six months later I was running that project plus three adjacent tracks: an organizational training I co-authored, the portfolio behind this site, and a journal that keeps me current on AI and EdTech.
This page is the system I built to do that, and what it's teaching me. The projects themselves are on the Work page.
My role as a product manager keeps changing as I work. AI is useful to me as a thinking partner only as long as I hold on to my own product taste, so I use it to sharpen what I think, not to do the thinking.
What changed most is the timescales. A 10,000-document analysis that would have taken months came together in a week, once I had structured the extraction properly. A market validation experiment went live in nine days, and I shipped the execution on paid acquisition and landing pages for the first time. I can stand up prototypes at real fidelity with no designer.
The pain points
With fractional support and several models available to me, I had to spend my own attention on the problems that needed it. Claude Code could organize the work and draft at a speed I don't have. Getting there meant solving four problems, in this order.
The first was scattered context: giving Claude Code what it needed without copying and pasting meeting notes, Slack threads, and Drive documents by hand. MCP connectors solved it. I picked the four systems that would carry the most value: Slack for what's moving across the org, Asana for task state, Granola for meeting transcripts, and Drive as a one-way path for sharing out. The rules I work by now, no automated deletes and manual approval on anything that touches a shared system, came out of iteration and one bad day with a Drive sync script.
Every morning I spent up to 30 minutes re-orienting the model on where things stood. So I built a daily ritual: at the end of a session a /session-end skill drafts where we are, what got decided, what's open, and what's next. I review it, adjust it, and close. A CLAUDE.md points the next morning's session at those files. What makes this work is keeping the ritual every day, not the way Claude writes things up.
The project had split into three tracks: build, market validation, and a 12-week pilot. One session could no longer hold all three at depth. Each needed a different kind of help: market validation needed domain expertise, build needed something that could advise me on code rather than just write it, and the main instance needed enough distance to see across all three. I split the work into one scoped instance per track and kept an orchestrator with read access to their status files. I route between them by hand, which makes me the bottleneck and the quality filter at the same time.
Scoped instances accumulate. Each one I build now has a defined scope, its own context, and written criteria for when it activates and when it retires. The retirement half is the part I care about: when the project pivots I shut down the agents built for the old shape instead of leaving them running. It's easier to make that call honestly when the criteria were written down first.
The shape underneath all of this is simple. Other practitioners have arrived at something similar, which I take as a sign that it fits the work.
~/Projects/[project-name]/
├── CLAUDE.md
├── _status/
│ ├── current.md
│ ├── dates.md
│ ├── decisions.md
│ └── session-log.md
└── [project-specific work]Where the line sits
The hardest part of working this way, after deciding what's worth building, is splitting the work between the system and me. Where I've landed is that the system owns the operational layer, where speed and scale matter, and I own the judgment layer. I'm not writing production software. I'm building the machinery around the work and deciding what good looks like.
What the system owns
Holding context across sessions through status files, so every session picks up where the last one left off.
Scoped instances per track, spun up and retired as the work shifts.
Synthesizing across large document sets, transcripts, and archives.
Building working artifacts (landing pages, dashboards, deploys, instrumentation) with no engineering or design support.
Reaching into the tools the org runs on (Slack, Asana, Granola, Drive) and carrying the overhead: task updates, check-ins, leadership briefs.
Pressure-testing my framing before anyone else sees it.
What I own
Knowing what's worth working on. Six months of desk research had gone into the last product before anyone spoke to a user. Deciding what to validate first is the call I make.
Reading users for what they need, not what they say. In the founder pilot, the pattern that mattered showed up in how people actually behaved in the cohort. Nobody described it in an interview. I saw it happening and the design followed.
Writing the decision criteria before the evidence arrives. I set go, pivot and kill thresholds up front. They keep me honest when the read is ambiguous.
Holding the quality bar. A cold usability test of our discovery system failed. I didn't patch the screens that broke, I wrote the fix into the spec instead of into one throwaway view.
Turning evidence into a decision someone can authorize. The conversations that get to yes with leadership and partners are mine.
The clearest case was the pivot two sprints in. The system surfaced that a nine-day market test and a set of user interviews were pointing the same direction. The call was mine, and so was the part the system couldn't see: the opportunity that shaped the pivot existed only in conversations happening off-keyboard. That project is written up on the Work page.
What I'm still figuring out
I haven't built a way to think about cost. My job requires constant experimentation, I've access to any tool worth trying, and I'm not measured on tokens or subscriptions. That's a real privilege, and it's why the gap is still open. I know the variables: API spend, subscriptions and maintenance time on one side, outcomes produced and time saved on the other. Until I instrument cost per decision, I can't tell you whether this system is efficient or just well-resourced.
The same gap shows up one level up. The system tracks the work inside each bet, but I don't yet have a way to weigh bets against each other on desirability, feasibility and viability. As more ideas come out of the experiments running on this system, that's the next layer of judgment the operating model needs to hold.
What stays with me
In a week I synthesized ten thousand documents. I stood up a market experiment in nine days with no engineering execution support, ran a 12-week pilot with no operational overhead, and carried four tracks on fractional support with no overtime. None of that was possible two years ago.
What it points to is that the bottleneck in product work is no longer capacity. It's judgment about where to spend the capacity we now have: knowing what's worth validating, reading evidence honestly when it's uncomfortable, and explaining a choice so it holds up under pressure. None of that is work AI can do for me. What it changed is how much of it I can get through in a week.
Most AI efforts stall on adoption rather than on the technology, and the part of this that travels is the method: design the system, decide up front what good looks like, check whether people actually use it, and retire what doesn't earn its place. There's no template. What I built fits my project, my constraints and my gaps.