Claude Projects for Teams: What Works and What Does Not

Claude Projects work well for teams as a shared starting point: the same files, the same instructions and the same tone for everyone who opens a chat. They work badly as a place to run team work, because a project has no idea what is in progress, who owns it, or what changed since yesterday — and each person’s chats stay private unless they choose to share them. Most teams that get value from projects use them for what is true and stable, and keep what is happening somewhere else.

What a shared project gives a team

Sharing is a Team and Enterprise feature. According to Anthropic’s help page on project visibility and sharing↗ (opens in a new tab), a project can be public to the whole organisation or private to invited members, and invited members get one of two levels:

• Can view: see the project’s contents, knowledge and instructions, and chat inside it, without changing anything.
• Can edit: change the instructions and knowledge, manage who else has access, and contribute to the project.

The same page makes the point teams most often miss: your chats inside a shared project stay private to you unless you share them yourself, and a shared chat is a snapshot up to the moment you shared it. Admins can also switch project sharing off for the organisation, and on Enterprise plans for particular roles, as the page on controlling project sharing↗ (opens in a new tab) describes. Whether sharing is possible at all is covered in can Claude Projects be shared?; this post is about what a team should do with it.

What works

• One source for reference material. Style guides, product descriptions, API notes, policy documents: upload once and every member’s chat starts from the same copy, instead of ten people pasting slightly different versions.
• Standing instructions. “Write in British English, never promise dates, cite the section of the policy you relied on.” Written once by someone with edit access, applied to every chat.
• A shared vocabulary. Put the team’s glossary in the knowledge — product names, customer tiers, the internal words for things — and every chat uses the same terms, which makes drafts from different people easier to combine and review.
• Onboarding. A new starter with view access can ask the project questions about how the team works before they ask a person.
• Consistency across people. Two colleagues drafting replies to the same kind of customer get answers shaped by the same knowledge and rules.
• Room for a larger library. Anthropic’s overview of what projects are↗ (opens in a new tab) says paid plans switch to retrieval when project knowledge approaches the context limit, so a team library can outgrow what one chat could hold.

What does not

The limits all come from the same fact: a project is a workspace for conversations, not a record of work. That shows up in five ways.

1. No task state. There is no field for “to do”, “in progress” or “done”. A project cannot answer “what is left?”, because it does not know what was started.
2. No assignment. Nothing in a project says who is doing what, so two people can work the same problem in two private chats and find out at the stand-up.
3. Private by default. The useful work — the analysis, the draft, the conclusion — happens in individual chats that other members cannot see. A shared chat helps, but it is a copy frozen at one moment.
4. No history of changes. The help pages describe who can edit instructions and knowledge, not a log of who changed them and when. When the instructions change and answers shift, the team has to work out why from memory.
5. Knowledge drifts. Uploaded files are copies. When the real document changes, the project keeps the old one until somebody with edit access replaces it.

None of this is a flaw in projects; they were not built to be a task list. It becomes a problem only when a team tries to use one as though it were.

The split that works

Give each tool the question it can answer.

• The project answers “what do we know, and how do we work?” — reference files and standing instructions that change rarely and deliberately.
• The board answers “what is happening?” — each piece of work as a task, with a lane, an owner, comments and a history.
• Decisions go where they can be found later, with who made them and why, not in the middle of a chat only one person can open.

The habit that joins them is simple: when a chat produces something the team needs — a finding, a draft, a “we should not do X” — it leaves the chat. It becomes a comment on a task, a new task, or an update to the project’s knowledge. The chat is where the thinking happens; the board is where the result lands.

Wiring the project to the board

If your organisation allows custom connectors, Claude can read and update a board from inside the project’s chats. Then the project instructions can carry the rhythm, so nobody has to remember it:

## Work tracking
- Before answering a request about ongoing work, read the board and name the task you are working from.
- If the request is new work, create a task first: bug for a fix, feature for something new, enhancement for a change.
- When a chat reaches a conclusion, comment it on the task in two or three sentences, with any links.
- Never mark a task Completed; say it is ready and a person will move it.

The last line is worth keeping for a team. Claude can do the recording, but the decision that something is finished stays with a person, which keeps the Completed lane meaningful for everyone who reads it.

House rules for a team project

• Name one owner for the instructions. Many editors means instructions that contradict each other within a month.
• Date the knowledge files, and put the date in the file name. It makes a stale copy obvious.
• Keep work out of the knowledge. A status update uploaded as a file is out of date the next morning.
• Share a chat on purpose, when it holds something others need, and link it from the task it belongs to.
• Review the project monthly: remove what nobody uses, replace what has changed.

Where fenbs fits

fenbs is the board half of that split. A team board has members, and each member — a person or an AI assistant — holds a role defined by the company, so a client can comment without editing and an assistant can read without moving anything. Tasks sit in four lanes, To Do, Next Up, In Progress and Completed, and every change is recorded with who made it. When Claude acts on the board it appears in that history as “Claude via” the person who connected it. Decisions have their own page, with who decided and why. A board is not shared by handing out a URL: people are added to it with a role, and an assistant’s token can be revoked without touching the person who issued it.