Product Managers, Stop Carrying Water for Your AI

You're already using AI to help you write. Alignment docs, sprint reviews, stakeholder updates. You open Claude Code, paste in or @ reference some context, and start working. The output is good. The process still isn't.

Before you ever get to the writing, there's an hour of assembly. You pull up Jira to check what shipped and what's blocked. You scan Slack for the conversation that changed the plan on Wednesday. You open your calendar and meeting notes to remember what was actually decided. You dig into GitLab to see what merged. Then you take all of that, bring it into Claude, and ask it to help you synthesize.

You're still the middleware between your tools and your AI. It feels like you work for it. We need to flip that.

The Level-Up

The shift I want to walk you through is connecting Claude Code directly to your sources of truth. Instead of you gathering context and feeding it in, Claude reaches out to Jira, Slack, Google Workspace, your meeting notes, and your repo on its own. It pulls the raw material and does the first pass of synthesis. You come in at the point where your judgment actually matters, not at the point where you're copying and pasting between tabs.

I've written before about choosing tools that my tools can use. My own setup leans on CLI tools because of personal preference. I have command-line interfaces wired up for Slack, Google Workspace, Jira, and more. But the particular tools matter less than the principle. What matters is that your AI workspace is connected to where the real information lives. For most people, especially those working in VS Code, MCP servers are the most accessible way to do this.

Before I walk through the setup, let me show you what this actually looks like in practice. Two scenarios from a PM's week where connected tools change the work.

Scenario 1: Sprint Planning

It's Thursday afternoon. You need to prioritize work for the next sprint. Right now that means pulling up three or four tabs and piecing together what matters.

With your tools connected, you start a Claude Code session with a prompt like this:

Use Granola to pull my meeting notes from the past week, especially the product review and leadership sync. Use Slack to check #product and #engineering for discussions about customer pain points, technical debt, or priority shifts. Summarize what's been discussed and where the organization's attention is focused heading into next sprint.

That's it. Plain language. Claude reaches into your meeting notes, Slack history, and email threads, then synthesizes what's been discussed into a picture of current priorities.

From there, you follow up:

Now use Jira to look at our backlog. Which tickets align with the priorities you just identified? Are any of those tickets missing context from the discussions you found? Flag any backlog items that have been sitting for more than two sprints but now align with something leadership emphasized.

Claude surfaces tickets that relate to a strategic conversation but don't reference the decision, or backlog items that suddenly matter because of a priority shift.

Then you push into the proposal:

Draft a sprint plan based on what you found. Prioritize based on the signals from discussions. Flag tickets that need their descriptions updated before they're ready to pick up. Identify any gaps where a conversation happened but no ticket exists yet.

Claude drafts the proposal. You push back, reorder, add your judgment about what's realistic given team capacity. Claude updates the tickets that need enrichment. You walk into sprint planning with a proposal grounded in every discussion your team has had. And sure, you're good at your job. That's what you do every week. But you didn't have to bleed through the manual collation of data sources and you could instead spend the time pressure testing the overall shape of the sprint.

Scenario 2: Mid-Sprint Course Corrections

It's Tuesday of the second week. The sprint is in flight and you need to know where things stand before your afternoon check-in.

The Jira board is your source of truth for what's in progress, but the real status lives in the conversations around those tickets. You open Claude Code and prompt:

Use Jira to pull all tickets in the current sprint. Use Slack to check for activity related to each ticket over the past three days. Use Granola to pull standup notes from this week. Which tickets have active discussion? Which ones have gone quiet? Did anyone flag a blocker in standup that hasn't been captured in Jira yet?

Claude surfaces a picture you'd normally spend 30 minutes assembling. Two tickets are on track. One has a dependency that came up in Wednesday's standup but hasn't been logged. A scope question was discussed in Slack that changes the estimate on another.

You follow up:

Draft a sprint status summary. For each ticket, include what the board says and what the conversations say. Call out any gaps between the two. Recommend adjustments for our check-in this afternoon.

You review, add your read on what's worth escalating versus absorbing, and walk into the check-in with a clear view of the sprint. All the impact. A fraction of the burnout.

The Common Thread

At the end of either flow, you should have a very passable first draft. Think of it as output from a bright, capable junior PM who has read every document and every thread but lacks the full context of your company. They don't know about the conversation you had in the hallway after the leadership sync. They don't have your intuition about which engineer is quietly struggling or which stakeholder is going to push back on the timeline. But they've done the legwork.

That's your starting point. You layer on the hallway conversation, the politics, the instinct that comes from years in the role. The draft becomes yours through the workshopping, not through the assembly. The hours you used to spend on tactical data gathering become available for the strategic work that actually needs a human brain.

These two scenarios lean on Jira, Slack, and Granola because that's where the relevant data lived. Yours might look different. If you need to know what actually shipped, GitLab lets Claude interrogate commits and merge requests directly. If the strategic context lives in a Google Doc or an email thread, Google Workspace gives Claude access to those. The scenarios change based on where your pools of data are. The pattern stays the same.

Now let me show you how to set this up. If you want the vision without the wiring, skip ahead to "Where This Goes."

A Note on IT and Permissions

Some of these connections require approval from your IT team. The Slack MCP server needs a Slack app installed to your workspace, which most orgs gate behind admin approval. Google Workspace connections may require your admin to authorize a third-party OAuth app. Granola's enterprise tier has MCP disabled by default until an admin enables it. And on a managed corporate laptop, you may need IT to install the developer tools (Node.js, Homebrew) that some of these servers depend on.

Others are lighter. The Atlassian MCP server uses OAuth with your existing Jira permissions, so if you can log into Jira in the browser, you're likely fine. GitLab's built-in MCP server inherits your existing authentication. And there are alternative tools that sidestep the app-install requirement entirely. slackcli, for instance, connects to Slack using your browser session rather than a bot token, no workspace app installation needed. My original setup referenced it for exactly this reason.

I respect the work that IT departments do. They have a very hard job, and their mandate is to make sure nothing bad happens. My mandate here is to help you make good things happen. I'll leave the distance between those two positions for you to navigate responsibly.

What is MCP?

Real quick, MCP (Model Context Protocol) is an open standard that lets Claude Code connect to external services. You configure a server for each service, authenticate once, and from that point Claude can reach into that system whenever it needs context. Think of each MCP server as giving Claude a login to one of your work tools.

You add these connections with a single command in the terminal. Claude Code stores them in a config file and automatically connects to each service when it starts.

Setting Up Your Cockpit

I'm going to walk through five connections that cover a typical PM's data streams. The specific tools here are Slack, Google Workspace, Jira, GitLab, and Granola. If your stack is different, the pattern is the same and I'll point to alternatives at the end.

For each one, I'll cover what you need before you start, how to configure it, and what you can actually ask Claude once it's connected.

Every setup step is a single command you run in your VS Code terminal (open it with Cmd+backtick on Mac or Ctrl+backtick on Windows). After adding a server, type /mcp in the Claude Code chat panel to verify the connection and complete any login flows.

Slack

What it connects you to. Your team's conversations, channel history, and threads.

Prerequisites. You'll need to create a Slack app in your workspace. Go to api.slack.com/apps, create a new app, and add these bot token scopes: channels:history, channels:read, chat:write, reactions:write, users:read, and users.profile:read. Install the app to your workspace and copy the bot token (starts with xoxb-). You'll also need your Team ID, which you can find in your workspace settings.

Setup. Run this in your terminal:

claude mcp add slack \
  -e SLACK_BOT_TOKEN=xoxb-your-token-here \
  -e SLACK_TEAM_ID=T01234567 \
  -- npx -y @modelcontextprotocol/server-slack

What you can ask Claude. "Summarize the last week of conversation in #product-updates." "What did engineering discuss about the migration in #platform this sprint?" "Were there any blockers raised in #standup this week?"

Google Workspace

What it connects you to. Gmail, Google Calendar, Drive, Docs, and Sheets.

Prerequisites. This one requires a Google Cloud project, which takes about 10 minutes to set up. Go to console.cloud.google.com, create a project, enable the APIs you need (Gmail, Calendar, Drive, Docs), and create OAuth 2.0 Desktop App credentials. You'll get a client ID and client secret.

Setup. Run this in your terminal:

claude mcp add google-workspace \
  -e GOOGLE_OAUTH_CLIENT_ID=your-client-id \
  -e GOOGLE_OAUTH_CLIENT_SECRET=your-client-secret \
  -- uvx workspace-mcp --tool-tier core

The --tool-tier core flag keeps the tool list focused on the essentials. Without it, you'll get every Google service tool available, which can be overwhelming. The first time Claude tries to use it, you'll authenticate through your browser.

What you can ask Claude. "What's on my calendar this week?" "Find the last email thread about the Q2 budget." "Pull the product brief from Drive and summarize the open questions."

Jira

What it connects you to. Issues, sprints, epics, and boards across your Jira Cloud instance. Also covers Confluence if you use it.

Prerequisites. You need an Atlassian Cloud account. That's it. The official server handles authentication through OAuth in your browser.

Setup. Run this in your terminal:

claude mcp add atlassian \
  -- npx -y mcp-remote@latest https://mcp.atlassian.com/v1/sse

When Claude first connects, it will open your browser for Atlassian OAuth. You authorize once and it respects your existing Jira permissions.

What you can ask Claude. "Show me all open P0 bugs assigned to the platform team." "What shipped in the last sprint?" "Create an issue for the onboarding redesign and tag it to the Q2 epic."

GitLab

What it connects you to. Repositories, merge requests, issues, milestones, and pipeline status.

Prerequisites. Install the GitLab CLI (glab). On macOS, that's brew install glab. Then run glab auth login and authenticate through your browser. The MCP server is built directly into the CLI, so there's no separate package to install.

Setup. Run this in your terminal:

claude mcp add gitlab -- glab mcp serve

It inherits your existing glab authentication, so there's no additional token configuration.

What you can ask Claude. "What merge requests are waiting for review?" "Summarize what merged this sprint in the core project." "Are there any failing pipelines on main?"

Granola

What it connects you to. Your meeting notes, transcripts, and meeting history from Granola.

Prerequisites. A Granola account. The free tier gives you access to the last 30 days of notes. Transcript access requires a paid subscription.

Setup. Run this in your terminal:

claude mcp add granola \
  -- npx -y mcp-remote@latest https://mcp.granola.ai/mcp

Authentication happens through your browser using the same email as your Granola account.

What you can ask Claude. "What decisions came out of last Tuesday's leadership sync?" "Find all action items from my 1:1s this week." "What did the team agree to about the timeline in the planning meeting?"

Not Your Stack?

The five tools above are one person's setup. MCP is an open protocol and the ecosystem of available servers is growing fast. If your stack looks different, here are the equivalents to look for.

If you use...	Instead of...	Look for...
Linear	Jira	Linear's hosted MCP server at mcp.linear.app
GitHub	GitLab	GitHub's official MCP server
Notion	Google Docs	Notion's hosted MCP server
Microsoft 365	Google Workspace	Community MCP servers (still maturing)
Fireflies or Otter	Granola	Check if your tool offers MCP support

And if you're not using Claude Code at all, the same MCP servers work with Cursor, Windsurf, and other AI coding tools. The setup commands will be slightly different but the principle is identical. Connect your AI workspace to your sources of truth, regardless of which workspace you've chosen.

The specific servers matter less than the pattern. Five commands and you stop being the middleware.

Where This Goes

What I've described so far is the first step. You open Claude Code, type a prompt, and it pulls the context for you. That's already a big improvement over doing the assembly yourself. But it's still manual. You're still the one initiating every session.

This is where the progression starts. First you save those prompts as reusable commands. Then you schedule them to run automatically. Then you connect automations together so the output of one feeds into the next. At some point you realize you've stopped grinding through the week and started building a machine. The connected tools are a humble but very important first step. Everything else builds on top.