Rolling out Claude Code to a product team requires shared context architecture, standardized skill libraries, and CLAUDE.md configuration that ensures every PM — from day one of onboarding — works from the same product knowledge base and framework standards.

There are at least 20 guides for setting up Claude Code as an individual PM. We've read most of them. Some are good.

None of them answer the question that actually matters if you lead a product team: How do I roll this out to 3, 5, or 10 PMs — and make sure it actually works consistently?

That's a fundamentally different problem.

"Each member of the team uses AI in their own way. At best, we can share prompts and short pieces of context with each other, but it hasn't yet evolved into a structured workflow or an operating system that the whole team can rely on."

"We definitely need a way to streamline the knowledge that currently is just in my mind or in 5 different tools — Jira, Confluence, ProductBoard."

And it's the one we solve every day through our implementation work with product teams. This guide captures what we've learned.

Why Team Setup Is a Different Problem

Setting up Claude Code for yourself is straightforward. You write some context, install some skills, and start prompting. If your context is thin or your folder structure is messy, the only person who suffers is you.

A team magnifies every shortcut and every gap. Here's what breaks:

No shared context means no shared understanding. PM #1 describes your ICP as "mid-market SaaS companies." PM #3 describes them as "growth-stage startups." Claude gives both of them confident, contradictory answers. Neither PM knows the other's version exists.

Inconsistent frameworks mean unpredictable quality. One PM writes PRDs using Marty Cagan's value-and-risk framing. Another uses a feature spec template they brought from their last company. A third just asks Claude to "write a PRD." Your Head of Product reviews three documents that look nothing alike.

Onboarding starts from zero every time. A new PM joins. They spend 3-4 weeks building mental models of the product, the users, the competitive landscape, the team's processes. All of that knowledge already exists — it's just trapped in individual Claude sessions, Notion pages, and people's heads.

When a PM leaves, their knowledge leaves with them. Their Claude context, their prompts, their workflows — gone. The next person starts from scratch.

Team setup solves all four problems at once.

The Shared Context Architecture

Every PM on your team needs access to the same foundational knowledge. We use five context files. Each one is a markdown file that lives in a shared context/ directory.

company.md

The single source of truth for who you are. Mission, values, market thesis, company stage, funding, team size. This file answers the question Claude will silently ask in every conversation: "What kind of company is this?"

# Company Context

## Who We Are
[Company name] is a [what you do] serving [who you serve].

## Mission
[One sentence. What you exist to do.]

## What We Believe
### 1. [First principle]
[Why this matters to how you build product.]

### 2. [Second principle]
[Why this matters.]

## Market Thesis
[What bet are you making about the market?
Why now? What's changing?]

Keep it under two pages. If your company.md reads like an investor memo, it's too long. Claude needs orientation, not a pitch deck.

product.md

What you've built, what's live, what's coming, and the technical reality. This file prevents Claude from hallucinating features you don't have or ignoring constraints that matter.

Include: current feature set, key metrics, technical stack (briefly), roadmap priorities, known limitations. Skip the marketing language — this is an internal reference, not a landing page.

personas.md

Who you serve, described in their own words. Not demographics tables. Not marketing segments. Actual pain points, jobs to be done, and the language your users use when they describe their problems.

## Primary Persona: [Role]

### The Reality
[2-3 sentences about their actual day-to-day. What's hard.]

### Jobs to Be Done
- [Functional job — what they need to accomplish]
- [Emotional job — how they want to feel]

### Pain Points (In Their Words)
- "[Direct quote from interview or support ticket]"
- "[Another quote]"

### What Success Looks Like
Before: [Current state]
After: [Desired state]

The "in their words" part matters. When Claude generates copy, PRDs, or research synthesis, it pulls language from this file. If the language is generic, the output is generic.

competitors.md

Your competitive landscape, updated regularly. Who you compete against, their strengths, their weaknesses, where you win, and where you lose. This file feeds every competitive analysis, positioning exercise, and strategy discussion your PMs run.

Structure it as one section per competitor: what they do, pricing, strengths, weaknesses, and your win themes against them.

goals.md

What the team is trying to achieve this quarter. OKRs, revenue targets, key initiatives. This file keeps Claude's recommendations grounded in what actually matters right now — not generic best practices.

Without goals.md, Claude gives advice for a hypothetical company. With it, Claude gives advice for your company, this quarter.

How CLAUDE.md Ties It Together

The CLAUDE.md file sits at the root of your project and tells Claude how to use everything else. For a team setup, this file does three critical jobs:

Points Claude to the context files. Claude auto-reads CLAUDE.md at the start of every session. It needs to know where the context lives and what each file contains.
Sets team-wide conventions. How you write PRDs. What frameworks you use. How you structure decisions. These conventions live in CLAUDE.md so every PM session inherits them.
Defines what's shared vs. what's personal. Team context is shared. Individual working notes, drafts, and scratch space are personal.

Here's the structure that works:

# CLAUDE.md

## Context Files
Read these before any PM work:
- `context/company.md` — who we are, mission, market thesis
- `context/product.md` — what we've built, roadmap, tech stack
- `context/personas.md` — who we serve, in their words
- `context/competitors.md` — competitive landscape
- `context/goals.md` — this quarter's priorities

## How We Work
- PRDs use [your framework] structure
- Decisions are documented in `decisions/` with rationale
- We write for [persona name], not generic "users"

## Skills
All PM skills live in `.claude/skills/`. Run `/prd-generator`, `/competitive-profile-builder`,
`/roadmap-builder`, or any skill — they all reference the shared
context automatically.

The Folder Structure That Works

Here's the directory layout we implement for teams. This comes from real engagements, not theory.

pm-os/
├── CLAUDE.md                    # Team-wide instructions
├── context/
│   ├── company.md               # Shared — one source of truth
│   ├── product.md               # Shared — current state + roadmap
│   ├── personas.md              # Shared — user archetypes
│   ├── competitors.md           # Shared — competitive landscape
│   └── goals.md                 # Shared — quarterly priorities
├── .claude/
│   └── skills/
│       ├── prd/
│       │   └── SKILL.md         # Standardized PRD generator
│       ├── competitive/
│       │   └── SKILL.md         # Competitive analysis
│       ├── roadmap-builder/
│       │   └── SKILL.md         # Roadmap creation
│       ├── user-interview-analyzer/
│       │   └── SKILL.md         # Interview synthesis
│       └── [70+ more skills]/
├── decisions/                   # Team decision log
└── discovery/
    └── inputs/                  # Research data drop zone

What's shared: Everything in context/, all skills in .claude/skills/, the CLAUDE.md file, and the decisions log. Every PM clones or syncs the same repo and gets the full operating system.

What's personal: Working drafts, individual notes, scratch analysis. These live outside the shared repo or in a personal branch.

Skill Standardization: Why It Matters for Teams

Here's where the real leverage shows up.

When PM #1 runs /prd-generator, they get a PRD structured with the same framework, referencing the same personas, grounded in the same product context as PM #5 running the same command. The skill encodes your team's definition of "good."

This means:

A new PM doesn't need to learn "how we write PRDs here." The skill encodes it.
Your Head of Product reviews PRDs that follow a consistent structure. Every time.
Frameworks from Teresa Torres, Marty Cagan, and Gibson Biddle are built into the skills. Nobody needs to remember which framework to apply — it's already there.

With 70+ skills covering PRDs, competitive analysis, roadmap building, interview synthesis, stakeholder simulation, and dozens more workflows, your team gets a codified playbook that works the same regardless of who runs it.

This isn't about removing judgment. It's about removing variance in structure so your PMs can focus their judgment on the decisions that matter.

Onboarding a New PM: The 30-Minute Setup

This is where team setup pays for itself fastest.

Traditional onboarding: New PM spends 3-4 weeks reading docs, sitting in meetings, asking "who's our ICP again?", and slowly building a mental model of the product and market. They produce mediocre work for the first month because they lack context.

With a shared PM OS: New PM gets productive in 30 minutes.

Here's the actual setup:

Clone the PM OS repo (5 minutes). They now have every context file, every skill, and the full CLAUDE.md configuration.
Run the /welcome skill (10 minutes). This walks them through the context files, explains how the system works, and verifies everything is loaded correctly.
Run their first skill (15 minutes). Have them try /prd-generator with a real feature they'll be working on. They'll see the output reference their product, their personas, and their competitive landscape — context they didn't have to build themselves.

They're not an expert on day one. But they're producing work that's grounded in the team's actual context from their first session. Compare that to a month of context-building through osmosis.

Scheduled Intelligence for the Whole Team

Individual setup guides never cover this, but it's one of the highest-value parts of a team setup: automated intelligence that runs on a schedule and benefits everyone.

Morning briefings. A daily summary of what's happening across the product — metrics changes, competitor moves, user feedback themes. Runs automatically, results land in a shared channel or file.

Weekly competitive updates. Agent teams can monitor competitor websites, changelogs, and pricing pages in parallel, then synthesize changes into a weekly briefing. One run benefits every PM on the team.

Monthly metrics reviews. Automated analysis of product metrics with trend detection and anomaly flagging. Instead of each PM pulling their own numbers, the team gets a shared, consistent view.

The key insight: scheduled intelligence has near-zero marginal cost per PM. Whether you have 2 PMs or 10, the same competitive briefing serves everyone. That's the kind of leverage that only exists at the team level.

When to DIY vs. When to Get Help

"I am the only PM on the team. I should spend more time on research, but I'm sometimes blocked by writing documentation, PRDs, and other tasks I want to improve my efficiency on."

"Our team is engineer-heavy — I'm the only PM at the startup. These skills would help me keep up with defining what gets built by our engineers."

Here's the honest assessment.

DIY makes sense when:

You're a solo PM or a team of 2
You're comfortable with Claude Code and markdown
You have time to iterate on your context files and folder structure
You don't need MCP integrations with your existing tools

For solo PMs, the guides that already exist are solid. Download our skills, write your context files, and start working. The $499 PM Operating System gives you everything you need to get started on your own.

Guided implementation makes sense when:

You have 3+ PMs who need to share context and skills
You need consistent output quality across the team
You want MCP integrations with Jira, Linear, Slack, or your analytics tools
You don't want to spend weeks experimenting with folder structures
Onboarding speed matters because you're actively hiring PMs
You need scheduled intelligence (competitive monitoring, metrics briefings)

The difference isn't capability — it's time and consistency. A solo PM can afford to experiment. A Head of Product rolling this out to a team needs it right the first time, because re-doing the architecture after 5 PMs are already using it is painful.

What This Looks Like in Practice

Here's a real example from a team implementation. A 5-PM product team went from this:

Each PM using Claude differently, no shared context
PRD quality varying wildly across the team
New PM onboarding taking 3-4 weeks
Competitive intelligence stale within days of manual updates

To this:

Shared context files updated weekly
Every PM running the same skills with consistent output
New PM onboarding in under an hour
Automated weekly competitive briefings the whole team reads Monday morning

The total implementation took weeks, not months. The context files compound in value every day because every PM session draws from them and every update benefits the whole team.

Set This Up for Your Team

If you're a solo PM, grab the PM Operating System and set it up yourself. The skills are free to browse at mysecond.ai/skills.

If you're a Head of Product thinking about rolling this out to your team — that's what we do. We map your PM workflows, build the shared architecture, install and customize the skills, train your team, and keep it running.

Every engagement starts with a PM Workflow Discovery: we map how your team actually works today, identify where the time goes, and design the PM OS architecture with ROI projections. It takes two weeks, and half the cost applies to the build.

Want to talk about it? Book a call. 30 minutes. No pitch deck. Just a conversation about whether this makes sense for your team.

Frequently Asked Questions

How do you set up Claude Code for a product team?

Setting up Claude Code for a product team involves five components: (1) shared context files — company.md, product.md, personas.md, competitors.md, and goals.md — stored in a shared repository all PMs clone; (2) CLAUDE.md configuration that points Claude to the context files and defines team-wide conventions; (3) a standardized skills library in .claude/skills/ covering PRD generation, competitive analysis, interview synthesis, roadmap building, and other PM workflows; (4) a decisions log for tracking rationale; and (5) optional MCP integrations with tools like Linear, PostHog, Slack, or Salesforce. Every PM clones the repo and gets the full operating system in one step.

What is CLAUDE.md and why does it matter for PM teams?

CLAUDE.md is a markdown file that Claude Code reads automatically at the start of every session. For product teams, it serves as the routing layer that tells Claude where context files live, what team conventions to follow, and what's currently prioritized. When every PM on a team has the same CLAUDE.md pointing to the same shared context directory, every AI session starts from the same foundation — eliminating the inconsistency that happens when each PM uses Claude their own way.

How long does onboarding a new PM take with a shared PM OS?

Onboarding a new PM with a shared PM operating system takes 30-60 minutes compared to 3-4 weeks with traditional onboarding. The new PM clones the shared repository (5 minutes), runs the /welcome skill to verify context is loaded (10 minutes), and produces their first grounded output using a skill like /prd-generator or /competitive-profile-builder (15-20 minutes). They're not an expert on day one, but they're working from the team's actual context — not rebuilding it from scratch through weeks of osmosis.

What's the difference between solo Claude Code setup and team Claude Code setup?

Solo Claude Code setup is forgiving — if your context is thin or your folder structure is messy, only you suffer. Team setup magnifies every shortcut. Without shared context, different PMs describe your ICP differently and Claude gives confident, contradictory answers to each. Without standardized skills, PRD quality varies wildly. Without CLAUDE.md conventions, frameworks change depending on who runs a skill. The team setup solves these problems with shared architecture: one context repository, one skills library, one conventions file that every PM session inherits.

How much does Claude Code team setup cost?

For a solo PM or small team comfortable with Claude Code and markdown, the self-serve PM Operating System costs $499 one-time and includes 70+ skills and context file templates. For teams of 3+ PMs who need consistent output quality, MCP tool integrations, and don't want to experiment with architecture, guided implementation starts with a PM Workflow Discovery engagement — two weeks, with half the cost applying to the build.

Claude Code for Product Teams: The Setup Guide Nobody Wrote Yet