How to set up Claude Projects for your team (and what most people miss)

Most teams using Claude are doing it the hard way.

Every conversation starts from scratch. Each person has their own way of prompting. Outputs vary wildly. Someone writes a great brief with Claude, then nobody else can reproduce it. The company's been "using AI" for six months and has nothing to show for it except a pile of individual wins that never compounded.

Claude Projects fix this. They're persistent workspaces where you set context once, and it applies to every conversation that happens inside. Your company background, your tone of voice, your standard caveats, the specific way you want summaries formatted — you write it once, and everyone on the team benefits from it.

Here's how to actually set them up.

Step one: pick a single use case to start

Don't build a Project called "Marketing". Build one called "Writing customer emails" or "Drafting LinkedIn posts in [your founder's] voice". The narrower the scope, the easier it is to write instructions that actually work.

The biggest mistake is building a general-purpose assistant and expecting it to work well for everything. It won't. Specificity is what makes Projects useful.

Step two: write the custom instructions like a brief, not a list of rules

Most people write instructions like:

• Always be professional
• Use British English
• Don't make things up

That's fine but it's not what makes Projects powerful. What makes them powerful is context that Claude couldn't otherwise have:

• Who your customer is and what they actually care about
• What your product does and who it's for
• What you've tried before that didn't work
• The specific format you want outputs in
• Phrases or framings to avoid

Think of it as briefing a smart contractor on their first day. What do they need to know to do good work immediately?

Step three: add your documents

Projects let you upload files — your product documentation, your brand guidelines, your customer research, past examples of good work. Claude can reference these during conversations.

This is the difference between a generic assistant and one that knows your business. If someone asks Claude to write a feature announcement, and your roadmap and messaging doc are in the Project, Claude can actually write something accurate — not just plausible-sounding.

Keep documents current. Outdated documents produce confidently wrong outputs.

Step four: test before you roll it out

Write ten example prompts that represent real tasks your team would do. Run them through the Project. Read the outputs carefully. Are they consistent? On-brand? Would you actually use them?

Most Projects need two or three rounds of instruction refinement before they're ready to share with a team. That's normal — treat it like editing a brief, not debugging software.

What this looks like when it works

A customer success team at a SaaS company sets up a Project with their product documentation, common customer questions, and instructions on tone. When a new CS hire joins, they can start drafting responses on day one that are actually on-brand and accurate — instead of spending their first month learning the product before they can write anything useful.

That's the compounding effect. Projects aren't just about efficiency — they're about making the team's collective knowledge accessible to everyone, immediately.

---

Further reading

• Projects overview — Anthropic Support