Claude Code for Product Managers: the Setup That Turns a Chat Window Into a Colleague

Why your Claude setup fails before you write the first prompt

In short: An agent rarely fails because of the model. It fails because nobody told it what you're working on, how you work, and when a change is good enough. Those are three things you'd tell a new colleague in their first hour – and in most repos they are written down nowhere.

I see this pattern in nearly every product team I talk to. The coding agents are rolled out, the licences paid for, and the work still feels the same: you prompt, you correct, you prompt again. Product leaders usually put it like this – “my knowledge is spread across twenty tabs”. As long as that's true, an agent can't do anything but guess.

Greg Isenberg found a useful image for this in his walkthrough of the new Claude Code features: if you want an agent to behave like a colleague, you have to give it what you'd give a person on day one – a workspace, memory, a brief, a clear assignment, eyes, a review, a calendar and permissions. That isn't a marketing metaphor. It's a setup checklist, and every item on it is a file or a setting.⁴

My thesis for this piece: what separates a chat window from a colleague isn't a better prompt, it's a set-up workplace. Everything that follows is the proof – in the order I'd build it.

How to set up the workspace: one repo, three files, two folders

In short: The workspace is a repository. Not a chat history, not a Notion space. A place where versioned files live, where the agent can read and write, and where every change stays traceable.

As a product manager you don't have to touch anyone's code for this. A dedicated context folder inside the product repo is enough – or a small repo of its own next to it, if you prefer. What matters is that it sits where the agent already works.

Three files carry the whole thing. CLAUDE.md describes how you work. ROADMAP.md describes what matters right now. REVIEW.md describes when a change is good enough. Plus two folders: one for verbatim customer language – support notes, call transcripts, objections, quotes – and one for recurring assignments you'll later turn into routines.

The customer-language folder is the one almost everyone skips, and it's the most valuable. Once real sentences from real users live there, the agent stops building from your opinion and starts building from what the market actually says. That's the same mechanism we mean at Teklens when we talk about the Context Engine: not more intelligence, more dependable context.

You can have Claude create the scaffolding itself – with an assignment that supplies the business context: product in one sentence, buyer, pain, promise, current goal. One addition always pays: “Ask me for any missing context that would materially change the structure, and keep the first version simple.” That single line saves you the first clean-up round.⁴

What belongs in CLAUDE.md – and what belongs in a rule or a skill

In short: CLAUDE.md holds what should apply in every session: working style, conventions, project layout, commands. Anthropic recommends staying under 200 lines per file – longer files consume more context and reduce adherence.¹

The most important sentence in the documentation sits a little buried: Claude treats these files as context, not as enforced configuration. The file is read and Claude tries to follow it – nothing is guaranteed. To block an action regardless of what the model decides, you need a hook or a deny rule. That's the difference between “we wrote it down” and “it cannot happen”.¹

In practice: keep the working style short and concrete. Small, reviewable changes. A plan before editing when product behaviour is affected. Use the existing code style. Run the relevant checks after each change. Summarise at the end what changed, what was tested and what a human needs to review. Five points, not fifty.

What doesn't belong there: multi-step procedures and anything that only concerns part of the codebase. Procedures belong in a skill that loads on demand – how to cut one is covered in the piece on skill files as the next AI competence after prompting. Path-specific guidance belongs in a rule file under .claude/rules/ with a paths field, so it only applies when Claude touches matching files.¹

And one detail that matters day to day: contradictions cost more than gaps. If two rules conflict, the documentation says Claude may pick one arbitrarily. A short, consistent file beats a complete one that argues with itself.¹

Why plan mode turns a wish list into an assignment

In short: Plan mode is the moment the agent reads instead of writing. It looks at the project, reads your context files and presents its approach before touching a file. You get something to react to – and that is the entire point.

In this mode, the documentation says, Claude reads files and runs read-only shell commands but doesn't edit your source files. That isn't a courtesy, it's a separation of roles: think first, build second. For anything that changes product behaviour, I'd make it a habit.³

A plan-mode assignment should always ask for the same five things: which files change, the smallest clean implementation, the user experience, the risks, and what is intentionally left out. That last point is the most important. What an agent deliberately leaves out tells you whether it understood the assignment.

One addition is mandatory: “Read the context files first.” Without that line the agent plans from what it sees in the code rather than from what you decided. The plan then looks competent and misses the point – the most expensive kind of error, because it only surfaces at review.

How to cut a ticket that stays checkable in one diff

In short: A good ticket names the task, the scope, the expected user experience and the boundary. “Make the app better” isn't one. “Add name, email and company to the sign-up form, show a simple success state after submit, and stay within the existing design system” is one.

The measure of size isn't the agent's effort, it's your review time. A ticket is cut correctly when you can read the change in the diff without blocking out a calendar slot. That's an unfamiliar shift: ticket size used to reflect the team's capacity. Now it reflects your review capacity, and that's the new bottleneck.

This is exactly where the canonical rule we've repeated at Teklens for years applies: automate bad input and you just ship the mess faster. A vague assignment no longer produces a vague follow-up question – it produces two hundred lines of plausible-looking code. The effort moves from writing to undoing.

What a ticket additionally needs when an agent executes it is covered in detail in the anatomy of a Jira ticket for AI product management: context that otherwise lives in a developer's head has to go into the ticket. For the close, a fixed addition pays off – after implementing, run the relevant checks, then summarise what changed, what was tested and what a human needs to review.

Why an agent needs eyes – and review runs in two layers

In short: “Eyes” doesn't only mean a screen. It means the agent checks what it built – opens the app, clicks through the flow, reads the console, runs the tests and judges the result from the buyer's point of view.

For product work that's the difference between “loads” and “works”. A page can render flawlessly and still confuse. A form can submit and still feel wrong. A button can be visible and still be missed. Let the agent only edit files and you get technically correct work with no product judgement.

The review afterwards runs in two layers. The first is yours: you open the diff and ask three questions – does this match the ticket, does it match the plan, is anything surprising in here. Surprises are almost always where the risk sits. If an assignment was about a form and the change suddenly touches routing and the database, you want to know immediately.

The second layer is the check against your standard – that's what REVIEW.md in the repo is for. The most useful assignment here asks for a three-way split: must fix, should fix, okay to ship. Those three bands are why review doesn't become a second full-time job – they tell you where to look instead of making everything equally important.

What goes into REVIEW.md is up to you, but a few lines belong in every project: does the change match the current focus? Is it small enough to review? Does the main flow still work? Are there mobile layout issues? Are form errors handled properly? Is there any risk to auth, payments or production data? Was unnecessary complexity added?

What to hand over to routines – and where the permission boundary sits

In short: A routine is a saved configuration – prompt, repositories, connectors – that runs automatically. It starts on a schedule, via an HTTP call, or in reaction to GitHub events, and it runs in the cloud even when your laptop is closed.²

The first routine should change nothing. I'd start with a morning brief: read the customer notes and the open issues, write down the biggest recurring pain point, one product risk, one recommended task for today and one question I should ask customers. No code, no pull request, under 500 words. It isn't spectacular – but it's the kind of work nobody otherwise does, and it sorts the day.

One detail from the documentation you shouldn't skim past: routines run autonomously, without permission prompts. There is no mode picker and no approval during a run – Claude can use every tool of every connector you included, writes included. So when you create one, strip out everything the routine doesn't need. That's the second reason to start read-only.²

For interactive sessions the opposite applies, and that's where your real control sits. Permission rules are evaluated in the order deny, ask, allow, and the first match decides – specificity doesn't change the order. So a broad deny can't be softened by a narrower allow. If you say “no migrations”, that holds, even if another entry allows one specific migration.³

I'd draw the boundary itself in three zones and write it down once. Allowed alone: read, search the codebase, propose plans, run local tests, work on a branch, update docs, open a draft pull request. Ask first: install dependencies, migrations, authentication, payment logic, delete files. Human-owned: production deploys, decisions about customer data, billing, security-relevant changes. The third zone stays with a person, even when the first two run well.

Why the second agent costs more than it looks

In short: Parallelising is tempting and it works – but only when each session has its own clearly bounded assignment and a defined handoff. Without that you don't get a team, you get a pile of work to untangle in the evening.

The most solid data point here comes from Anthropic itself: their internal multi-agent system clearly beat a single agent, but used roughly fifteen times more tokens. More agents are therefore a cost-value decision, not progress in itself. When the overhead pays off and when a single, well-contextualised loop wins is covered in the piece on graph engineering and multi-agent workflows.⁶

The person who has publicly pushed this furthest is Allie K. Miller. She describes a digital workforce of roughly 34 agents on a hub-and-spoke model: a chief of staff, the only one she speaks to, with six direct reports below, each with their own sub-agents. Her core point is the interesting one: the hub-and-spoke model matters, but the actual unlock is orchestration and documentation. Not the number of agents.⁵

The second part of her setup is the one I'd most readily borrow for product teams: she split project management in two. One agent orchestrates and reasons, a second watches and maintains memory – flagging drift from the goal, catching recurring issues, keeping records. A watchdog that produces no work of its own, but tells you what you wouldn't have thought to check.⁵

And that closes the loop back to the beginning. Both examples – Isenberg's setup checklist and Miller's workforce – say the same thing at different scales: the return comes from structure, not compute. The agents are interchangeable. The repo where context, standard and decisions live versioned is not.

That's exactly what Teklens builds as a product: a context that connects Jira, Confluence, code and mail and doesn't have to be rebuilt at every session start – a layer over your tools, not a replacement. Maintaining it yourself as files in the repo gets you a long way; the limit is where the context has to know the code itself.

Frequently asked questions

Recommendations

• Write the three files before you type the next prompt. Working style, current focus, quality bar. One page each is enough. Anything you'd otherwise re-explain every other session belongs there.
• Create a folder for verbatim customer language. Support notes, objections, quotes – unfiltered, not summarised. Without this folder the agent builds from your opinion instead of from the market.
• Keep CLAUDE.md under 200 lines. Procedures into a skill, path-specific guidance into a rule with a paths field. And review it quarterly for contradictions – those cost more than gaps.
• Cut tickets by your review time, not by effort. If you can't read the change in one diff, the ticket is too big. The bottleneck is no longer implementation, it's judgement about it.
• Start with a read-only routine. A morning brief from customer notes and open issues, no code, no pull request. When creating it, remove every connector the routine doesn't need.
• Write the permission boundary down once. Three zones: allowed alone, ask first, human-owned. Anything that must be binding belongs in a deny rule or a hook – not in a context file.
• Add the second agent only once the first delivers checkable work. Parallelism multiplies what already works – and equally what doesn't. Structure first, scale second.

Scope & caveats

• The details on CLAUDE.md, routines and permissions come from the official Claude Code documentation as of August 2026. Anthropic labels routines a research preview – behaviour, limits and interfaces may change. Check the current state before you build on it.
• The setups from Greg Isenberg and Allie K. Miller are practitioner reports from individual users, not studies. Miller's figure of roughly 34 agents and the role split of her digital workforce are self-reported from her own operation; they show what is possible, not what is optimal for a twenty-person product team.
• Anthropic's comparison of multi-agent and single-agent systems comes from an internal research eval, not from independent work. The token factor applies to that task class and can't be transferred to product work unchecked.
• We give no before-and-after numbers for Teklens here. Pilot evidence is in progress; until it exists, we describe the capability, not the effect.

Sources

Every external figure and quote in this piece – linked so you can verify it.

1. 1.Anthropic, «How Claude remembers your project» – Claude Code Docs (2026) ↗ – CLAUDE.md as context rather than enforced configuration, the under-200-lines guidance, rules with a paths field.
2. 2.Anthropic, «Automate work with routines» – Claude Code Docs (2026) ↗ – Routines as saved configurations with schedule, API and GitHub triggers; autonomous runs without permission prompts.
3. 3.Anthropic, «Configure permissions» – Claude Code Docs (2026) ↗ – Permission modes including plan mode; evaluation order deny, ask, allow, with the first match deciding.
4. 4.Greg Isenberg, «Claude Code New Features, Explained» – YouTube (2026) ↗ – The setup checklist for an AI employee: workspace, memory, brief, ticket, eyes, review, schedule, permissions.
5. 5.Allie K. Miller bei Greg Isenberg, «My top secrets to running an AI Agent Workforce» – YouTube (2026) ↗ – Roughly 34 agents in a hub-and-spoke model with a chief of staff; orchestration and documentation as the actual unlock.
6. 6.Anthropic, «How we built our multi-agent research system» (2025) ↗ – Internal eval: a clear lead for the multi-agent system at roughly fifteen times the token consumption.

Keep reading in the PM Lab

Related deep dives – from the same pillar and the adjacent phases.

Matching use cases from the library

From the article straight into practice: these use cases put the concepts to work with Teklens.