What Model Context Protocol (MCP) Means for Product Management

Something happened in the last six months that most product managers haven't fully processed yet.

Model Context Protocol — MCP — went from an Anthropic engineering project to a standard that Microsoft, Shopify, and dozens of other major platforms have adopted. And the implications for how product management works are more significant than most people in the industry are talking about.

I'm not going to oversell this. MCP isn't magic. But it is a genuine infrastructure shift — and product managers who understand it early will have an advantage that compounds.

Here's what you actually need to know.

What MCP Is (Without the Jargon)

Product managers don't need to understand how MCP works under the hood. But you need to understand what problem it solves, because it's directly relevant to how AI tools work in your product workflow.

Here's the problem MCP solves: AI models are incredibly powerful, but they're only as useful as the context you give them. Ask Claude or GPT-4 "what should we prioritize next quarter?" and you'll get a generic answer. But give it access to your strategy documents, your customer research, your competitive intelligence, your backlog, and your revenue data — and suddenly the answer is actually useful.

The old way to do that context-sharing: every tool built its own custom integration. Anthropic would build an integration with Notion. Then with Jira. Then with Salesforce. Every integration was built from scratch, maintained separately, and broke whenever the source system changed its API.

MCP is a protocol that standardizes how AI models connect to external data sources. Build an MCP server once, and any AI agent that speaks MCP can use it.

Mike Krieger, co-founder of Instagram and now Chief Product Officer at Anthropic, described it precisely: "For utility of AI products, it's three parts: model intelligence, context and memory, and applications and UI. The middle piece — context and memory — is what MCP is trying to solve."

He went further: "I've started saying things like, 'Guys, we're building this whole feature. This shouldn't be a feature we're building — this should just be an MCP we're exposing.' Once you start seeing everything through the eyes of MCP, everything becomes scriptable, composable, and usable agentically."

That's the shift. Not "AI has better features." It's "AI has real access to your actual context."

Why This Matters Specifically for Product Managers

Product management is, fundamentally, a context-intensive discipline.

Making a good roadmap decision requires synthesizing: strategic objectives, customer feedback, competitive positioning, technical constraints, stakeholder priorities, resource availability, and market timing. That's not a feature request. That's a rich contextual judgment call.

The reason AI assistants have been only marginally useful for product decisions — despite being genuinely impressive at many tasks — is context starvation. You ask for prioritization help and you get a generic RICE framework explanation. You ask for PRD feedback and you get comments that don't know your company's strategic context.

MCP changes this. When your AI agent has structured, live access to:

• Your strategy documents (what you're trying to accomplish this year)
• Your customer research database (what customers actually need)
• Your competitive intelligence (what the market looks like)
• Your existing roadmap (what you've already committed to)
• Your backlog (what's been requested)
• Your revenue data (what's actually driving the business)

...then the AI can give you answers that are actually calibrated to your situation. Not generic best practices. Actual recommendations grounded in your product's reality.

The Infrastructure Framing — And Why It Matters for How You Evaluate Tools

There's a positioning question that's going to become important for every PM evaluating tools in 2026: is this a product management application or a product management infrastructure layer?

The distinction matters because AI agents need infrastructure, not just applications.

An application is a UI that PMs interact with. You open it, you use it, you close it. It might be excellent at what it does. But it's not composable — your AI agents can't reach into it and use its data.

An infrastructure layer is a system of record that AI agents can access via structured protocols. Your AI assistant can pull from it, write to it, query it in real-time. It's the connective tissue between your human product decisions and your AI capabilities.

Most PM tools on the market today are applications. They were designed for humans to interact with through a GUI. MCP is beginning to expose what a world looks like where those same tools become infrastructure — where AI agents can connect to your product context the same way they connect to your calendar or your email.

This is why the platforms that are moving fastest on MCP adoption aren't niche AI startups. They're the platforms that understand they need to become infrastructure to stay relevant.

Shopify's CEO Toby Lütke was an early champion of MCP. Microsoft's Kevin Scott drove its adoption across the Microsoft ecosystem. These aren't AI researchers — these are product leaders who understand that the next generation of software value comes from composability and context, not just features.

What MCP-Ready Product Management Looks Like

Let me make this concrete. Here's what becomes possible when product management infrastructure is MCP-native:

Scenario 1: Strategy-aligned PRD generation A PM opens their AI assistant and says: "Write a PRD for the enterprise export feature." The AI doesn't just generate generic requirements. It pulls the current strategic objectives, checks what customers in the enterprise segment have been requesting, surfaces competitive context (does Productboard have this? What does Linear's version look like?), flags any conflicts with existing roadmap commitments, and produces a first draft that's already aligned with what the company is trying to accomplish.

This isn't possible without structured AI access to product context. MCP is what makes the structured access possible.

Scenario 2: Continuous competitive monitoring Instead of quarterly competitive research that's immediately outdated, an AI agent monitors competitive signals continuously — pricing changes, feature announcements, customer sentiment shifts — and surfaces them in context when they're relevant to a decision you're making. Not a firehose of notifications. Contextually relevant alerts.

Scenario 3: Prioritization that knows your constraints "If we shift the Q3 priority from the API rate limit feature to the SSO integration, what's the revenue impact?" An AI agent with access to your revenue attribution data, your customer contracts, and your engineering estimates can actually model this. Not perfectly. But with enough fidelity to inform a real decision.

Scenario 4: Stakeholder communication that adapts The CEO wants to know what you're building and why it matters for growth. The CTO wants to know the technical approach and sequencing. The enterprise sales team wants to know what's coming that they can use in deals. The same product decision, communicated in the right frame for each audience — with an AI that has enough context to make those translations accurately.

The Practical Question: What Should Product Managers Do With This?

A few concrete steps.

1. Understand what's in your context gap Ask yourself: if I wanted to give an AI assistant everything it needed to help me make a good prioritization decision today, what would I need to give it? Most PMs would need to share 5-10 different documents or data sources that currently live in different systems with no structured connection.

That gap — between the context you have and the context an AI can currently access — is where MCP-native tooling creates value.

2. Evaluate tools on composability, not just features When you're evaluating PM tools in 2026, ask: "Does this tool have an MCP server? Can AI agents access my product context through this platform?" The answer tells you whether you're buying an application or infrastructure.

3. Think about your product as infrastructure too If you're a PM building products in 2026, MCP also changes how you think about your own product's architecture. @Mike Krieger put it best: "We're building this whole feature — this shouldn't be a feature. This should just be an MCP we're exposing."

What functionality in your product should be accessible to AI agents through a structured protocol, rather than locked inside a GUI?

4. Get specific about AI use cases before evaluating tools "We want AI to help with product management" is too vague to evaluate anything against. Get specific: "We want AI to help with PRD generation. The AI needs access to strategy docs, customer research, and competitive intel to do this well." Now you can ask whether a platform's MCP implementation covers those data sources.

The Timing Window

Here's the honest reality: MCP adoption in product management tooling is early. Most PM platforms don't have MCP servers yet. The workflows I described above are possible today — PM33 was built with this infrastructure model from day one — but the broader ecosystem is catching up.

That's actually the opportunity.

The product teams that understand this shift now and build their product intelligence infrastructure with MCP-native tooling will have a compounding advantage over teams that wait until it's mainstream. The AI gets smarter because you've given it better context. Better context produces better decisions. Better decisions produce better products. Better products produce more revenue.

It's the same pattern I saw play out with mobile, with cloud, with data analytics. The teams that treated each of those as "eventually we'll need this" paid a steep catch-up cost.

Don't wait on this one.

PM33 is built as an MCP-native product management intelligence layer — connecting your strategy, research, competitive data, and backlog into a unified context that AI agents can actually use. Learn more at pm-33.com.