Search "Claude Code project management" and you'll find two different ideas. One is using Claude to manage your tasks: writing specs, breaking work into tickets, keeping a PROJECT.md. That's useful, and there are good skills for it. This post is about the other one: managing the work Claude does for you.
You have a team now
A year ago, an engineer's day was mostly writing code. Now, for a lot of us, it's this: three or four Claude Code sessions going, across two or three projects, each one doing a chunk of work that used to take a day. Claude writes the code. You decide what matters, keep track of what's in flight, notice what stalled, unblock it, and tell people what shipped.
That's a product manager's job. Nobody handed it to you, but it's yours, and most of us are doing it from memory and a row of terminal tabs.
The job, in four parts
1. Priorities. Decide what matters most this week, per project, and write it down. Without that, the session that gets your attention is the one that asked the most recent question.
2. What's in flight. Know the threads of work, not just the sessions. A feature is usually five or six sessions over several days. What you need to see is the thread: what's done, what's open, what's blocked.
3. What stalled. Loose ends are where the waste is. A migration half finished, a test that fails one time in three, a question you meant to ask the designer. They don't show up in git because nothing got committed.
4. What shipped. Finished work needs to be told: in standup, in Slack, in a review. Engineers are bad at this, and it gets worse when the work moves this fast.
A simple system that works
You can run this with a notes file:
- One list per project, grouped by thread. Each thread gets one line for where it stands and one for what's left open.
- A morning pass. Before starting anything, read yesterday's list and pick the two or three threads that matter most today. Resume those sessions (
claude --resume <id>works from any folder now). Leave the rest. - An end-of-session habit. Before closing a session, ask Claude "what's left open?" and add the answer to the list.
- A weekly check. Compare where your time went against the priorities you wrote down. If a side project took half your week, decide whether that was right. Either change the priority or change the week.
- Close threads on purpose. When a thread is done, mark it done, write one line about what it produced, and move it off the active list.
The weak point is obvious: it only works if you keep the list current, and the whole reason you're behind is that the work is faster than you are.
What's hard to see by hand
Two things are nearly impossible to track manually:
- Where the time actually went. You'll guess wrong. I did: when I measured my own last 30 days, my main company got 6% of my hands-on time, and a marketing system I'd call medium priority got half.
- Loose ends across dozens of sessions. They're in the transcripts, but nobody rereads transcripts.
Doing it automatically
This is why I built Shabash. It reads your Claude Code history and git on your Mac and does the product management part for you:
- sessions grouped into threads per project, with what's done, open and stalled
- a morning list of unfinished threads, where you check the ones that matter and press Start
- your stated priorities next to where your time went
- finished work turned into a Slack message, LinkedIn post or review, with the sources behind every line
You make the calls. It keeps the picture current. If that sounds useful, try the demo or join the waitlist below.
Related: how to manage multiple Claude Code sessions covers worktrees and agent view, the tools Claude Code gives you for the running part.