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.
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:
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.
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:
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.
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:
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.
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.
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:
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.
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:
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.
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.
