MCP for Product Teams

Every PM on your team now has an AI tool, and each one is using it differently. One writes specs in Claude, another mocks up screens in Lovable, a third works in Cursor with engineering. They’re giving those tools different context and using different workflows, ultimately deciding for themselves what information the AI should rely on.

That flexibility works for the individual PM. Across a product organization, it creates inconsistency and drift.

Two PMs can ask about the same customer and get different answers because their tools have access to different evidence. A spec changes in a coding tool, but the roadmap never gets updated. Decisions made during design or development don’t always make it back to the original product record, so the intent behind a feature starts to separate from what actually ships. The team moves faster, but the work stops lining up.

That makes decisions harder to defend, too. When an executive asks why a feature was prioritized, what customer evidence supported it, or why the final product differs from the original plan, the answer may be spread across private AI chats, specs, tickets, and code comments. There’s no single record of the reasoning or how it changed along the way.

Your PMs should use the AI tools they like best. You just need to make sure that the team is operating from a shared product record that each of those tools can read from and write back to. MCP is how the tools connect. Productboard is the record.

This post explains how that works and walks through five ways product teams are using MCP with Productboard today.

What is MCP?

MCP stands for Model Context Protocol. It's an open standard that lets AI tools connect to other software. Once an AI tool is connected through MCP, it can read information from that software and take actions in it, such as creating a record or updating a field.

For product organizations, the important part is the shared context this creates. Instead of every AI tool operating from whatever a PM happened to paste into it, MCP can connect those tools to the systems where customer evidence, product decisions, specs, and delivery context already live. It can also send what happens in those AI tools back to the product record, so the record keeps pace with the work.

With Productboard, MCP works in two ways:

• Your AI tools can work in Productboard. AI tools like Claude, Claude Code, Cursor, and Lovable, plus other AI tools that support remote MCP connections, can connect to the Productboard MCP server. Once connected, they can read and edit specs, comment on them, and update their status. They can also create and update the rest of your product hierarchy, from objectives and initiatives down to features and subfeatures, along with companies and users. Each tool signs in with the person's own Productboard login, so it can only see and do what that person can, and admins decide which roles can use MCP. The MCP server is included at no extra cost on every Productboard plan.
• Productboard Spark can work with your other tools. Spark is Productboard's purpose-built AI agent. It can connect to tools like Amplitude, Linear, Notion, Slack, and Lovable through MCP connectors. It uses what it finds there to answer questions and complete work in Productboard. With some tools, Spark can also take action inside that tool. For example, Spark can start a Lovable project from a spec, and Lovable builds it into a working app..

Together, those connections let Productboard serve as the system of record while PMs keep working in the tools that are best suited to each part of the job. The context can travel with them, and what they learn or change can make its way back.

How product teams use MCP with Productboard

1. Analyzing customer feedback

Customer feedback is spread across support tickets, sales calls, surveys, and chat. The leadership problem isn’t only that some of it goes unread. It’s that PMs can end up prioritizing from different slices of the customer picture. One PM may have a support thread another never saw. Another may be working from a sales call or discovery interview that never made it into the roadmap conversation.

Productboard brings all of that feedback into one place through integrations and connectors. It comes in from Slack or Microsoft Teams, forwarded emails, call transcripts, and support tools like Zendesk and Intercom. Spark then analyzes it and pulls out what your team can act on.

Once the feedback is in, a PM can ask about it in plain language, referencing customers or segments by name without any special syntax. For example:

• What are the most common requests from enterprise accounts this quarter?
• What does this customer need from us right now?
• What should I know before my QBR with this customer?

When Spark cites feedback in an answer, you can ask it to link that feedback to a product, component, feature, or subfeature. The feedback then shows up as an insight on that item, so the customer evidence stays with the work it supports.

If leadership asks why a feature is on the roadmap, the team can trace the decision back to the customer evidence behind it instead of reconstructing the rationale from memory or private AI conversations.

Spark can also give you a more complete picture of your users by combining qualitative feedback with quantitative usage data. It can read usage data from connected tools like Amplitude or Pendo alongside customer feedback. This helps a PM size a feature request, for example by seeing which other accounts rely heavily on the related workflow.

The result is a more consistent evidence base across the team, even when individual PMs use different AI tools and workflows.

2. Creating prototypes and complete apps with Lovable

A written spec can look complete and still miss things you only notice once you see the screen. Those gaps, like a missing empty state, usually surface after engineering has started, when they're slower and more expensive to fix.

They can also create another kind of drift. The prototype evolves as the team reacts to what it sees, but the reasoning captured in the original spec stays frozen. A few rounds later, the design may reflect decisions that the product record never captured, leaving other teams and leaders without a clear explanation for why the experience changed.

MCP lets you make the spec real. Productboard connects to Lovable through Lovable's own MCP server, so it can create, read, and update Lovable projects directly from a spec in Productboard. This makes Lovable the first AI app building tool Spark can work in directly. Productboard is an approved client of Lovable's MCP server.

That gives PMs a way to test whether the written intent actually holds up once it becomes something people can see and interact with, while keeping the feedback loop tied to the original product context.

Here's how the workflow goes:

1. Write or improve a spec in Productboard with help from Spark.
2. Ask Spark to create a Lovable project from the spec. Lovable generates a working, interactive app from the spec.
3. Review the mock with your team and use it to pressure-test the spec. Is anything confusing? Does the flow reflect the customer problem you intended to solve? Did the visual version expose a missing state or assumption?
4. Add those missing details back to the Productboard spec to keep the intent accurate behind what you’re building. You can push those updates back into the spec directly from Lovable.

If your team already uses Lovable for quick designs, this means the first mock is built from the real spec, instead of from someone's summary of it. And as the mock improves, the product record can improve with it.

3. Building from a spec in your coding tool

Once engineering starts building, product decisions get made in code comments and chat threads instead of the spec, so the team loses the record of why they built the feature the way they did.

That loss of rationale becomes a leadership problem quickly. Engineering may have a perfectly good reason for changing an interaction or narrowing scope because of technical complexity, but if that decision never makes it back to the product record, the final product can look like it simply diverged from the plan. The next time a PM has to explain what shipped and why, the paper trail is missing.

MCP keeps the spec and the build connected. You can send a spec built in Productboard straight into a coding tool like Claude Code, Codex, or Cursor, and use it to build a working prototype. The coding tool reads the spec through the MCP server, so it starts from the same details your team agreed on. To send it, click “Open in” on any spec, and your coding tool opens with the spec already loaded and ready to build from.

This is why the connection to coding agents is so critical. Productboard doesn’t need to become the place where engineers prototype. It needs to make sure the context behind the work can reach that environment, and that important decisions made there can find their way back.

With MCP, the connection works in both directions. While the coding tool builds, it can add what it learns to the spec as comments or suggested edits. For example, if the prototype shows that the spec missed an edge case, that gap gets written on the spec where the whole team can see it. This way, the spec stays up to date even after the work has moved to another tool.

That helps preserve the connection between what the team intended to build, what it learned during implementation, and what eventually ships.

4. Keeping releases and roadmaps up to date

A roadmap is only as current as the last time someone updated it. The work keeps moving in code, tickets, and chat, but in most instances someone has to go back and change each status manually.

For a product leader, stale status is more than an administrative annoyance. It makes it harder to know what is actually progressing, where work has changed, and whether the roadmap being discussed with executives still reflects reality.

MCP removes that step. With the Productboard MCP server connected, the AI tools your team already uses can keep Productboard current as the work moves. They can update the status of features that have gone stale, and flag specs that are missing information so someone fills the gaps. That keeps everyone working from the same picture. It also keeps every connected AI tool's answers clean, because they all read from the same up-to-date data. Releases are a good example of how this works day to day.

Here's how Conor, one of Productboard’s PMs, runs a release:

1. In Productboard, the PM creates the release and finds the features that should go in it. They set each feature's status and dependencies. Then they ask Spark to point out missing information or gaps in the specs.
2. Next, the PM opens the same release in Claude Code through the MCP server. From there, they read the features, comment on a spec, and update each feature's status in Productboard.
3. At the same time, they draft the release announcement from the same list of features.

Because every step uses the same release record, product, engineering, and marketing all see the same status. Each tool wrote its updates to the same place.

For the product leader, that creates visible progress without forcing every team member into the same tool. The team can work where the work happens while Productboard remains the shared record of what is planned, what changed, and where things stand.

Permissions work the same way they do in the Productboard app. Each AI tool signs in as a specific person, so it can only change what that person could change by hand.

5. Bringing in context from docs and tools

A lot of product knowledge lives outside your product tool, in research write-ups, decision docs, tickets, and experiment results. An AI tool that can't reach those sources has to guess or start from scratch.

The risk grows as teams add more AI. If every PM manually decides which documents, tickets, and data to feed into a prompt, the organization ends up with multiple versions of product context. The quality of the output depends on what each person happened to include.

MCP gives Productboard that reach. When Spark connects to tools like Notion, Linear, and Hex, it can base its answers on what your team has already written down.

This is the other side of the shared context layer. Productboard can hold the product record without requiring every piece of supporting information to live inside Productboard. MCP lets Spark reach into the systems where that context already lives and use it alongside the customer evidence, priorities, specs, and decisions in Productboard.

Productboard's MCP connectors currently include:

• Docs and knowledge: Notion and Google Drive (Confluence can also be attached as a file source)
• Engineering and delivery: Jira/Rovo, GitHub, Linear, Trello, and LaunchDarkly
• Analytics and data: Amplitude, Pendo, and Hex
• Communication: Slack
• AI evaluation: Braintrust
• Prototyping & app building: Lovable
• Custom MCP servers your team adds

PMs can connect most of these on their own, right from Productboard’s chat interface, or request access when a connector needs an admin's approval. Admins can also add custom MCP servers for the whole team.

What MCP doesn't solve

MCP connects your tools, but it has limits. It doesn't decide what your team should build, clean up messy data, or set how your team operates. If you connect an AI tool to a disorganized feedback backlog and an unclear process, you'll get disorganized answers, just faster.

That's why it matters how well your information is organized, in Productboard and in your other tools, and why your team needs a clear product operating model. When customer feedback is tied to the work it affects and specs stay current, every connected AI tool starts from the same foundation. An AI agent like Spark can take on much of that upkeep, but your team still decides what matters.

Every new connection also gives an AI tool access to more of your data, so treat it like any new integration: decide who needs it and what it should be allowed to change.