CLAUDE.md for Product Managers: How to Give Claude Code Your Product Context

CLAUDE.md for product managers is the configuration layer that gives Claude Code persistent knowledge of your product, users, competitive landscape, and current priorities — so you stop re-explaining your context every time you open a new session.

Every CLAUDE.md guide you've read starts the same way: "Use TypeScript strict mode. Run tests with npm test. Follow ESLint rules."

That's the developer version. It's valid. But if you're a PM using Claude Code, none of that helps you.

You need Claude to know your product, your users, your competitive landscape, and your Q2 goals. You need it to stop being a brilliant stranger who asks "can you tell me more about your company?" every single session.

"I spend a lot of time creating projects in Claude and ChatGPT to give LLMs all the context they need to help me with research. Understanding how to build contextual layers that can take repetition out of the equation would help me focus more on strategy."

— Senior Content Manager at a 20-person marketing agency

That's what this guide is for. The PM version of CLAUDE.md — and the system-level thinking that turns Claude Code from a generic assistant into a PM who already did the reading.

What CLAUDE.md Actually Is

CLAUDE.md is a markdown file that sits in the root of your project folder. Every time you start a Claude Code session, Claude reads it automatically. No prompting. No pasting. No "here's some context for you."

Think of it as the onboarding doc you'd hand a new PM on their first day. Except this PM reads it instantly, remembers everything, and never needs to be told twice.

For developers, CLAUDE.md contains build commands and code conventions. For PMs, it contains something more valuable: the strategic context that makes every AI output actually useful.

Most PMs stop at context files. The best setups go further — working principles, self-correction, and review systems built into the configuration.

The Five Context Files Every PM Needs

CLAUDE.md itself should stay lean — under 200 lines. It's the index, not the encyclopedia. The real depth lives in five separate context files that CLAUDE.md points to.

1. company.md — Who You Are

This file answers: "What company is this PM working at, and what matters to them?"

# Company Context

## Who We Are
[Company name] — [one-sentence description].
[Stage/funding]. [Team size]. Founded [year].

## Mission
[One sentence: the specific problem you eliminate
and for whom]

## Business Model
- [Primary plan]: [price] per [unit]
- [Secondary plan]: [pricing structure]
- [Trial/free tier]: [details]

## What Makes Us Different
- [Differentiator 1 — be specific about what competitors
  don't do]
- [Differentiator 2 — quantify if possible]
- [Differentiator 3 — focus on your actual gap,
  not aspirational positioning]

## Current Stage
- [Number] paying customers
- $[X] ARR
- [Revenue split or growth rate]
- [Team changes: hiring, constraints]

Keep it factual. Specific numbers over vague descriptions. "340 paying customers" beats "growing customer base."

2. product.md — What You've Built

This file answers: "What does the product do today, what's working, and what's next?"

# Product Context

## What We've Built
[Product type] with [X] core modules:
1. **[Module 1]** — [what it does, one line]
2. **[Module 2]** — [what it does, one line]
3. **[Module 3]** — [what it does, one line]

## Current Metrics
- Activation rate: [X]% (target: [Y]% by [date])
- [Retention metric]: [value]
- NPS: [score]
- Top support ticket: "[most common user complaint]"

## Roadmap ([Current Quarter])
- NOW: [Feature] ([specific improvement target])
- NEXT: [Feature]
- LATER: [Feature]

## Technical Constraints
- [Constraint 1 — anything that affects PM decisions]
- [Constraint 2 — known limitations, edge cases]
- [Constraint 3 — platform or integration issues]

The "Technical Constraints" section does the most work. Without it, Claude suggests features that hit known limitations and recommends solutions your stack can't support.

3. personas.md — Who You Serve

This file answers: "Who are the humans using this product, and what do they actually care about?"

# User Personas

## Primary: [Role Title] ([First Name])

**Demographics:**
- [Key responsibility — scope of their role]
- [Experience level]
- [Reports to — who they answer to]
- [Scale — what volume they manage]

**Jobs to Be Done:**
- [Functional job 1 — what they're measured on]
- [Functional job 2 — what keeps them busy]
- [Functional job 3 — what they report upward]

**Pain Points:**
- "[Direct quote or realistic pain statement]"
- "[Another pain — specific, not generic]"
- "[Pain that connects to your product's value]"

**Language They Use:**
- "[Their term]" (not "[your internal term]")
- "[Their term]" (not "[generic business term]")
- "[Their abbreviation]" (not "[formal version]")

The "Language They Use" section changes every output Claude writes. Without it, Claude defaults to "stakeholders" and "users." With it, Claude uses the exact terms your customers use — in copy, emails, interview scripts, everything.

4. competitors.md — Who You're Up Against

This file answers: "Who else solves this problem, and where do we win?"

# Competitive Landscape

## Primary Competitors

### [Competitor 1]
- **What they do:** [One sentence]
- **Strengths:** [What they're genuinely good at]
- **Weaknesses:** [Specific gaps, not adjectives]
- **Where we win:** [Concrete scenarios]

### [Competitor 2]
- **What they do:** [One sentence]
- **Strengths:** [Be honest]
- **Weaknesses:** [Be specific — "6-week implementation"
  beats "hard to set up"]
- **Where we win:** [When customers choose us over them]

## Our Positioning
[2-3 sentences: where you sit relative to competitors.
Not too enterprise, not too lightweight, not trying
to replace their entire stack — whatever your lane is.]

Be specific about competitor weaknesses. "Their UX is bad" gives Claude nothing to work with. "6-week mandatory implementation with a dedicated onboarding manager" gives Claude a concrete positioning lever.

5. goals.md — What Matters Right Now

This file answers: "What is this team focused on, and what have they decided not to do?"

# Goals & Strategy

## This Quarter's Goal
[Primary metric]: [current] → [target] by [date]

## What We're Shipping
- [Initiative 1] — [target date], [why it matters]
- [Initiative 2] — [target date], [expected impact]

## What We're NOT Doing (And Why)
- [Deprioritized item 1] — [reason: revisit Q3, etc.]
- [Deprioritized item 2] — [reason]

## Key Decision Pending
[What you're still figuring out — this helps Claude
ask the right questions instead of assuming]

The "What We're NOT Doing" section saves you from Claude suggesting the thing you explicitly decided to defer.

How to Structure Your CLAUDE.md

Now connect everything. Your CLAUDE.md is the routing layer that tells Claude where to find context and how to use it.

# CLAUDE.md

## About This Project
[Company] — [one-sentence description].
[Stage]. [Customer count]. [Key metric].

## Context Files (Read Before Any PM Task)
- `context/company.md` — Mission, stage, model, team
- `context/product.md` — Features, metrics, roadmap,
  constraints
- `context/personas.md` — Primary and secondary personas
  with pain points and language
- `context/competitors.md` — Competitors, strengths,
  gaps, positioning
- `context/goals.md` — This quarter's focus,
  what's shipping, what's deprioritized

## Current Focus
- This quarter: [Primary metric + target]
- Shipping: [Initiative + target date]
- Key metric: [What you're watching daily]

## How to Work With Me
- One recommendation, not options
- Use persona language from personas.md
- Reference competitors by name, not generically
- Flag assumptions — don't fill gaps silently
- Lead with the decision, then the evidence

The folder structure:

your-project/
├── CLAUDE.md              # The index — read automatically
├── context/
│   ├── company.md         # Who you are
│   ├── product.md         # What you've built
│   ├── personas.md        # Who you serve
│   ├── competitors.md     # Who you compete with
│   └── goals.md           # What you're focused on now

Five files and an index. That's the foundation.

Before and After: Why Context Changes Everything

"Every session I'm basically starting from scratch. I rebuild from zero again. I'd love a system where context carries over."

— Senior PM exploring AI tools for product work

Without context files, every Claude session starts from zero.

Without context:

You: Write a competitive analysis for our scheduling feature.

Claude: "Here's a framework for competitive analysis. Consider factors such as pricing, features, target market, and user experience. List your top 3-5 competitors and evaluate each across these dimensions..."

Generic framework. Placeholder competitors. You'll spend 30 minutes filling in the blanks.

With context files loaded:

You: Write a competitive analysis for our scheduling feature.

Claude: "Your scheduling module competes in a market with three alternatives: [Competitor 1] targets enterprise at 5x your price point, [Competitor 2] serves small teams but lacks multi-location support, and [Competitor 3] bundles scheduling inside a full-suite platform. Your positioning as the standalone scheduling layer for mid-market teams with an existing ATS creates a distinct lane. The exposure: [Competitor 1] just launched a mid-market tier directly targeting your segment..."

Specific competitors. Your positioning. Actual market dynamics. Ready to use in a stakeholder presentation without heavy editing.

The difference isn't Claude being smarter. It's Claude having the same context your best PM would have after three months on the job.

Beyond Context Files: What a PM Operating System Looks Like

Most PMs stop at the five context files and call it done. That's a solid foundation — but it's one layer of what's possible.

To see the gap, look at how engineering leaders configure Claude Code for their own work.

Boris Cherny, the engineering lead behind Claude Code at Anthropic, published his personal CLAUDE.md. It doesn't just list project context — it defines how Claude should think, learn, verify, and improve. This is the gap between a context file and an operating system.

Here's what stands out, and what each concept means for PM work.

Plan Before You Build

Boris's setup requires Claude to enter plan mode for any non-trivial task — three or more steps, or any architectural decision. If something goes sideways, the rule is explicit: stop and re-plan immediately. Don't push forward.

The PM translation: Before writing a PRD, building a roadmap, or drafting a competitive analysis, Claude should structure its approach first. What context does it need? What's the output format? What assumptions is it making? This prevents the most common AI failure mode: confidently producing something that misses the point.

Self-Improvement Loops

After any correction, Boris's CLAUDE.md instructs Claude to write the correction down as a rule that prevents the same mistake from happening again. The instruction is direct: "Ruthlessly iterate on these lessons until the mistake rate drops."

The PM translation: When you correct Claude — "we don't call them users, we call them operators" or "always check if this conflicts with Q2 priorities" — that correction should persist across sessions. A self-correction file tracks what went wrong and what to do instead. Every correction makes the next session better. Your CLAUDE.md doesn't just store context — it learns.

Verification Before Done

The engineering version: never mark a task complete without proving it works. Diff the behavior. Run the tests. Ask yourself if a staff engineer would approve it.

The PM translation: Before Claude presents a competitive analysis, it should cross-reference the claims against your competitors.md. Before a PRD goes to stakeholders, it should be reviewed from multiple perspectives — does the CTO see technical risk? Does the sales team see positioning gaps? Does the user advocate see adoption friction?

Parallel Perspectives

Boris uses subagents — parallel workers that each handle a focused task. One researches, another analyzes, a third validates. The main thread stays clean.

The PM translation: Instead of one Claude session doing everything sequentially, you can get parallel perspectives. A CTO review, a UX review, a sales review, and an executive review — each looking at your work through a different lens. The same way a real product review involves multiple stakeholders, your AI setup can simulate that before the actual meeting.

Opinionated Principles

The engineering CLAUDE.md doesn't just describe the project. It establishes principles: simplicity first, find root causes not workarounds, minimal impact. These aren't suggestions — they're operating rules.

The PM translation: Your CLAUDE.md should include working conventions that reflect how you actually want PM work done. "One recommendation, not options." "Use customer language from personas, not generic business terms." "Lead with the decision, then the evidence." These rules shape every output Claude produces.

What a PM Operating System Actually Includes

The five context files give Claude knowledge. The system-level configuration gives Claude judgment.

Here's what a fully built PM operating system includes beyond context files.

Core Principles Baked In

Instead of hoping Claude will be concise or opinionated, you encode it:

• Ground everything in context. Reference specific details — company stage, persona pain points, competitive gaps. Generic outputs are failed outputs.
• One recommendation, not options. State the best path and defend it. Alternatives only when the trade-off is genuinely close.
• Customer language first. Use the words from personas.md. "Users" have names. "Stakeholders" have roles.

These principles apply to every output — PRDs, competitive analyses, roadmaps, stakeholder updates. They're not per-session instructions. They're permanent operating rules.

Skills That Load Automatically

Rather than writing detailed prompts every time you need a PRD, competitive analysis, or interview synthesis, a PM operating system includes skill files that Claude discovers automatically based on what you describe.

Say "write a PRD for the checkout redesign" and the right skill loads — with a structured framework, your context files referenced, and output format already defined. You don't need to remember slash commands or prompt engineering. You describe the work, and the system routes to the right skill.

The folder structure:

.claude/skills/
├── prd-generator/SKILL.md
├── competitive-profile-builder/SKILL.md
├── user-interview-analyzer/SKILL.md
├── roadmap-builder/SKILL.md
└── ... (dozens more)

Six Reviewer Agents

Instead of reviewing your own work, you can set up multiple perspectives that challenge it before stakeholders see it:

• CTO/Tech Lead — spots technical risk and implementation gaps
• UX/Design Lead — flags adoption friction and user experience issues
• Sales/GTM Lead — checks positioning and competitive messaging
• Executive Reviewer — evaluates strategic alignment and resource trade-offs
• User Advocate — represents the customer voice in every decision
• Devil's Advocate — stress-tests assumptions and finds the holes

Each reviewer has a defined perspective, decision philosophy, and review template. Say "review this PRD as my CTO" and you get a structured critique from that lens. For Heads of Product managing multiple PMs, this means every PM on the team gets the same review rigor — without you being the bottleneck.

Self-Correction Across Sessions

A correction file — think of it as a learning journal — tracks what Claude got wrong and what to do instead:

## Corrections
| Date | What Went Wrong | What To Do Instead |
|------|-----------------|-------------------|
| 3/10 | Used "users" generically | Use persona names from personas.md |
| 3/11 | Suggested deferred feature | Check goals.md before recommending |

Every correction makes the next session better. Over weeks, Claude stops making the mistakes you've already caught. Your operating system improves with use.

A Folder Structure for PM Work

Beyond context files, a PM operating system organizes where research goes, where outputs land, and where strategy lives:

your-project/
├── CLAUDE.md
├── context/           # Your product knowledge
├── discovery/
│   └── inputs/        # Interview transcripts, research,
│                        survey data
├── strategy/          # Positioning, roadmap, competitive
├── specs/             # PRDs, feature specs

Drop an interview transcript in discovery/inputs/ and Claude can reference it. Put a competitor teardown in strategy/ and it shows up in future competitive analyses. The system compounds — every artifact you add makes future outputs richer.

How to Get Started

Start with context (free, 2-3 hours)

Copy the five context file templates from this article. Write your CLAUDE.md index. Add a "How to Work With Me" section with your working conventions. You'll have a solid foundation that makes every Claude session more relevant.

Get the full operating system

mySecond's PM Operating System gives you the full system described above — 70+ skills, six reviewer agents, self-correction, and the folder architecture — ready to use the day you download it. The /welcome skill automates context extraction from your website and existing docs, so you skip the manual setup entirely.

Browse the full skill library at mysecond.ai/skills or see the complete system at mysecond.ai/pricing.

Have it built for your team

For product teams that need a PM operating system tailored to their specific context, workflows, and operating rhythm — mySecond builds it for you. Discovery, implementation, and ongoing managed intelligence. The difference between a template every PM customizes individually and a system your entire team runs on from day one.

Learn more at mysecond.ai/services.

Six Mistakes That Waste Your Context Files

1. Putting everything in CLAUDE.md

CLAUDE.md should be under 200 lines. If you're pasting your entire product roadmap, all persona details, and competitive research into one file, Claude's attention gets diluted. Use CLAUDE.md as the index. Put depth in separate files.

2. Writing prose instead of structured markdown

Claude parses structured content more reliably than paragraphs. Use headers, bullet points, and tables.

Hard to parse:

"Our main competitor is an enterprise tool that starts at $1,200 per month and requires a 6-week implementation and they're SOC 2 certified but they don't serve companies under 500 employees which is where we come in."

Easy to parse:

### [Competitor Name]
- **Segment:** Enterprise (500+ employees)
- **Price:** From $1,200/mo
- **Setup:** 6-week implementation required
- **Gap:** Won't serve mid-market (<500 employees)

3. Letting context go stale

Your Q2 goals shouldn't still say Q1. Your competitor section shouldn't reference a product that was sunset six months ago. Set a calendar reminder: review context files on the first of every month. Fifteen minutes keeps everything current.

4. Skipping the language section in personas

"Language They Use" is the highest-leverage section in your personas file. Without it, Claude defaults to generic business language. With it, every output sounds like it was written by someone who actually talks to your customers.

5. Being vague about competitors

"Their product is hard to use" gives Claude nothing to work with. "Their onboarding requires a dedicated implementation manager and takes 6 weeks" gives Claude a concrete positioning lever. Specifics beat adjectives.

6. Not including current focus

Context files describe the landscape. But Claude also needs to know what matters right now. Your CLAUDE.md should include a "Current Focus" section with this quarter's goals, what's shipping, and what's explicitly deprioritized. This prevents Claude from suggesting features you've already decided to defer.

Frequently Asked Questions

What is CLAUDE.md for product managers?

CLAUDE.md is a markdown file in your project root that Claude Code reads automatically every session. For product managers, it's the routing layer that points Claude to your context files (company.md, product.md, personas.md, competitors.md, goals.md), sets your working conventions (how you want recommendations structured, what language to use), and establishes your current priorities. Beyond context routing, a mature PM CLAUDE.md also includes core working principles, self-correction mechanisms, and review perspectives — turning it from a context index into an operating system.

What should a PM put in CLAUDE.md?

A PM's CLAUDE.md should contain four elements: (1) a brief company description (one sentence, key metrics, stage); (2) pointers to your five context files — company.md, product.md, personas.md, competitors.md, and goals.md — with a one-line description of each; (3) your current focus (this quarter's goal, what's shipping, what's explicitly deprioritized); and (4) working conventions (how you want recommendations structured, whether to use customer language from personas, how to handle assumptions). Keep CLAUDE.md under 200 lines — use it as an index, not an encyclopedia. Advanced setups add core principles, skill auto-discovery, reviewer agents, and self-correction files.

How is a PM's CLAUDE.md different from a developer's?

A developer's CLAUDE.md contains build commands, code conventions, testing instructions, and architecture decisions — technical operational context. A PM's CLAUDE.md contains product knowledge: company mission and stage, user personas, competitive landscape, quarterly goals, and working conventions. The structure is the same (a markdown file Claude reads at session start), but the content reflects the PM's work — strategic context rather than technical instructions. The most sophisticated engineering CLAUDE.md files include workflow orchestration, self-improvement loops, and verification gates. The PM equivalent includes review agents, self-correction tracking, and skill auto-discovery.

What are the six most common CLAUDE.md mistakes PMs make?

The six most common CLAUDE.md mistakes are: (1) putting everything in CLAUDE.md instead of using it as an index to separate context files — Claude's attention dilutes when one file contains everything; (2) writing prose instead of structured markdown — headers and bullets parse more reliably than paragraphs; (3) letting context go stale — Q2 goals shouldn't still say Q1; (4) skipping the "Language They Use" section in personas — without it, Claude defaults to generic business jargon; (5) being vague about competitors — "their UX is bad" is useless, "6-week mandatory implementation" is a concrete positioning lever; (6) not including current focus — context describes the landscape, but Claude also needs to know what matters right now.

How long does it take to set up CLAUDE.md and context files as a PM?

Setting up CLAUDE.md and five context files takes 2-3 hours for the DIY approach. CLAUDE.md itself takes 20-30 minutes — it's a short routing document. Each context file takes 30-45 minutes: company.md is easiest (you know it cold), personas.md takes longest (ideally drawn from interview quotes and support tickets rather than invented). After setup, maintenance takes 15 minutes per month — updating after competitive moves, user research, and product releases. Alternatively, mySecond's /welcome skill automates context extraction from your website and existing docs, reducing setup to minutes.

What is the difference between context files and a PM operating system?

Context files give Claude knowledge — who your company is, what you've built, who you serve, who you compete with, and what you're focused on. A PM operating system adds judgment on top of that knowledge: core principles that shape every output, skills that load automatically based on the task you describe, reviewer agents that critique work from multiple perspectives (CTO, UX, Sales, Executive), and self-correction files that track mistakes so they never repeat. Context files are the foundation. The operating system is the full infrastructure.

How does the self-correction loop work in CLAUDE.md?

A self-correction loop uses a persistent file (sometimes called a napkin or lessons file) that Claude reads at the start of every session and updates whenever you make a correction. When you say "don't call them users, call them operators" or "always check goals.md before suggesting new features," Claude logs the correction with the date, what went wrong, and what to do instead. Over time, this file becomes a personalized rule set that prevents repeated mistakes. The pattern comes from engineering — Boris Cherny's Claude Code CLAUDE.md includes a self-improvement loop that works the same way for code.

What are reviewer agents in a PM CLAUDE.md?

Reviewer agents are separate configuration files that give Claude a specific perspective when reviewing your work. Instead of one generic review, you can get a CTO review (technical feasibility and engineering cost), a UX review (adoption friction and user experience), a Sales review (positioning and competitive messaging), an Executive review (strategic alignment), a User Advocate review (customer impact), and a Devil's Advocate review (assumption stress-testing). Each agent has its own decision philosophy and review template. You invoke them by saying something like "review this PRD as my CTO" — Claude shifts into that perspective and provides a structured critique.

Ron Yang is the founder of mySecond, the PM Operating System built on Claude. He's spent 15+ years in product leadership and now builds the infrastructure that gives PM teams leverage.