Claude Code changed what a PM can own. I use it every day to do things that used to go to engineering or get skipped: trace GraphQL calls, search the repo, run survey analysis on a schedule, draft tickets that already sound like our team. The setup is deliberate: built over a year with context files, standing instructions, and automated workflows. It's the most distinctive part of how I work, and the thing I most enjoy teaching other PMs.
Generic AI output is generic because there's no context. The trick — the only trick, really — is to invest in the context: a project folder Claude lives in, a CLAUDE.md it reads at the start of every conversation, a library of reference files capturing your team's voice and architecture, and MCP connectors so it can actually do things.
Once you've done that, Claude stops being "an AI chat" and starts being "a teammate that already knows the project, the team, and how you write." It drafts a ticket in your voice. It pulls release tickets via Jira and writes the release notes the way you would. It triages a Salesforce ↔ Hygraph integration question by reading the actual code. It synthesizes a folder of twelve interview notes and produces a themed write-up.
The investment in setup pays back inside a week. The longer you use it, the better it gets, because the context grows into a precise mirror of how you and your team actually work.
Everything related to Claude work goes here. Claude reads the file tree as part of its context, so a clean, predictable structure means it finds the right reference file every time without you having to point at it.
The single most important file. It sits at the root of the project folder and Claude reads it at the start of every conversation. Six sections — overview, folder structure, communication preferences, code style, workflow, integrations note. Iterating on it is the difference between mediocre and excellent output.
The context/ folder is where the magic happens. Markdown files that capture the institutional knowledge Claude needs to do high-quality work — what you'd brief a new hire on. Start with one. Add more whenever Claude misses something. After a few weeks you have a library.
Ticket structure, business-vs-implementation framing, word counts, section order.
Jira Cloud → HTML. GitHub → Markdown. Confluence → either. Set once, followed forever.
Integrations, key flows, terminology — Salesforce ↔ Compass ↔ Hygraph ↔ Auth0 ↔ Algolia.
Shorter, no bug fixes, business outcomes only. Different voice than the internal release notes.
Model Context Protocol = the connectors that let Claude talk to the systems your work lives in. Atlassian (Jira + Confluence), Bitbucket, the data warehouse, the CMS. Start with one — Atlassian alone unlocks 80% of the value for a PM.
The setup above is the boring part. Here's what daily work looks like once it's in place — the actual prompts I run, and what Claude does in response.
"Draft a feature ticket for adding [X] to the booking flow. The goal is [business outcome]."
Claude reads ticket-guidelines.md, applies my formatting strategy (HTML for Jira Cloud), reads product-architecture.md for context, uses a template from ticket-templates/, and saves the result to tickets/[name].html. I open the file, copy, paste into Jira. Done.
"Pull the tickets in the [date] release and draft release notes for Confluence."
Claude queries Jira via the Atlassian MCP, groups by Features / Improvements / Bug Fixes, applies my house style, saves to release-notes-drafts/.
"Draft the exec recap email covering the last three releases for leadership."
Same source data, totally different tone — Claude reads exec-comms-style.md and produces something measured, business-outcome framed, no bug fixes, no em dashes. Different audience, different draft.
"Read the interview notes in research/active/[topic]/ and synthesize themes."
Claude reads research-playbook.md for methodology, reads every interview file, extracts themes weighted by frequency and impact, writes the synthesis doc.
"Where does the booking-flow UI decide whether to show the lottery banner? Trace through Hygraph."
This is the one I'm proudest of. Claude reads our locally cloned repos, follows the GraphQL trace, finds the CMS-controlled config in Hygraph, and tells me exactly which content block is driving the UI logic. I now triage to root cause independently before engineering escalation.
My job got measurably better the day I stopped asking Claude what to do, and started telling it how I work.
Every time Claude does something wrong twice, add a line. Every time it nails something non-obvious, capture the rule.
The voice and style files are what make output sound like you, not generic AI prose. Feed Claude your product docs, your style rules, your team directory — quality jumps immediately.
Jira Cloud doesn't paste Markdown cleanly — use HTML. GitHub uses Markdown. Set this expectation once in formatting-strategy.md and Claude will follow it forever.
Don't try to wire up everything at once. Get one workflow working end-to-end before you expand. For a PM, Atlassian first.
"Draft release notes" is OK. "Draft release notes for the [date] release using my Confluence style rules, grouped Features / Improvements / Bug Fixes" is great.
Five guides, from “what even is this” to running your own automated workflows. Free to read, built to share.
Yes — the portfolio about how I use Claude was, in fact, built with Claude. It would have been a little awkward otherwise.
A PM who can take a portfolio from concept to shipped in a long weekend — without an engineer in the loop — is the demonstration, not the credential. Welcome to the new working set.