Everybody’s talking about MCP: Lessons from builders at Miro, Atlassian, and beyond

Below is an edited transcript of the conversation. Quotes have been lightly condensed for clarity. 

APIs have existed forever. What does MCP actually unlock that APIs couldn't?

Gunjan: In the past, you had to understand the API for each tool, spend your already-scarce dev resources to build those different integrations, and if one requirement changed — say, rather than just reading something you had to write something — you'd go back and make the change and wait six weeks. That was the cycle: it was slow, and it was expensive.

With MCP, there are servers being provided by the providers themselves, and you're just expressing your intent. Your velocity of building is just accelerated very, very quickly. You're moving away from defining specific calls to an action and instead describing what you want. That's where agent orchestration, actually assigning work to agents, becomes possible. Without that, it was just impossible.

Kosta: APIs connect tools, but someone still has to click things and make sense of it all. MCP lets agents read context across tools and act inside them, at a scale no individual could match.

What did you actually build with MCP, and what does it do?

Michelle: I built a triage that connects the Pendo MCP with the rest of the org data for my organization. It’s my everyday morning wake-up. What do I need to know before I talk to anyone? Before I watch any session replays, which ones are most important? What happened yesterday?

It tells me what certain people did, based on a group I set up around our customer success managers. It flags standard activity, potential issues to watch, data spikes, different volumes to look at, wins to celebrate. I can also ask it which sessions I should watch before reaching out to any CSMs. It surfaces things like: heavy content review sessions, lots of rage clicks and dead clicks, significant frustration events, power users in a brief creation workflow. That's a product director's morning brief, built in an agent, running on a daily schedule.

Kosta: We fed a customer discovery call transcript into Claude and generated a PRD directly on the Miro board. From there, we mapped out a user flow, added reference screenshots, and captured notes, all in one shared space. Once the team aligned, I dropped the board URL into Claude Code. The MCP understood the context and generated a working prototype that reflected what we'd aligned on. We showed it to stakeholders and validated with the customer the same day. A year ago, that kind of speed wasn't possible. Now, anyone can go from a customer problem to an aligned solution in a matter of hours.

Gunjan: As PMs, we're juggling a lot, and one of the most important jobs is knowing what customers are asking for: what they like, what they don't, how they're using the product, and what's happening in recent sales conversations. That research used to take hours. I built an agent in Rovo. I gave it access to my sales tool, Google Docs, Calendar, GitHub, Jira tickets, Confluence pages, meeting notes, Hotspot leads. When I ask it to help me prep for an upcoming meeting, it uses all those tools and produces a comprehensive report in minutes. Things which used to take me hours now take minutes, and I walk into the room significantly more confident.

What did you get wrong when you built your first MCP server?

Francois: We made a big mistake: we exposed the tools as really low-level primitives. What we said was: if you have a question, call this endpoint and pass your question. If you want to reformulate your question, use this endpoint to reformulate. The problem is we were giving too much power to the LLM. So then the model was deciding when to use which tool, and actually, they tend to not use a tool. If things are smart, they'll say: "You know what, I can figure this out myself."

For example, if you ask "show me my top 10 customers,” that's very ambiguous. The LLM would just find its own definition and call Spotter to get the answer. And if you asked the same question twice, you might get a different answer. It was hallucinating in the sense that it would define "top" based on whatever it thought was most relevant for a banking dataset: sometimes savings account, sometimes credit account. 

We now provide tools that bring all the intelligence with them. We don't let Claude bring his own intelligence, because we know our data and we have more context than the model does. We control it through our semantic layer, so every time you ask a question you get the same answer, grounded in all the context we have.

Michelle: That's exactly why I used all the SQL queries in my instruction layer. These are the definitions. This is what it means to be "top" in our data. The people querying don't always know what exact word to use or what the field name is, so that level of explanation was necessary for our internal data.

How did you decide what to expose first — and how do you decide what not to expose?

Kosta: It's not one-size-fits-all. At Miro, we started with validated use cases and strategically narrowed down what we wanted to focus on. When we built the MCP server, engineers were really the ones adopting it most. So we built around engineering workflows, specifically the problem of agents writing thousands of lines of code and it being really hard to visualize what they're doing to steer them. We focused on that, and on how you take the team's intent and pass it to code generation. That prevented us from going too broad too early, which would have confused both the agents and our go-to-market narrative.

Michelle: We started with a single agent and went from there. We also started with what was easiest and most trustworthy. We wanted to make sure users trusted the tool before we said "we're going to handle this end to end for you." We want the user to still be in the driver's seat, with guardrails in place, before we say we can handle all these tasks automatically. That's been the slow growth process.

Francois: You really need to think about where you want to leverage intelligence. Do you want to delegate to the LLM? In some cases, that's perfect. But in our case, because the data is so sensitive, we had to design it the other way around. It's much more than MCP per se. It's really about embedding the agentic side of it.

As for what not to expose, it comes back to your semantic layer. That's where you specify which tables you want to expose, who has the right to do what. In the old world, the dashboard was the guardrail. An analyst controlled which visualizations went on the dashboard. Now that dashboards are going away and people want to speak directly to the data, the semantic layer becomes the new control point.

How do you get your team to actually change how they work?

Kosta: It comes down to two things. One is mandate: it's not even just up to me. Company leadership needs to decide it's important. At Miro, it's broadly understood that we want to accelerate adoption, especially with how fast the market is moving. But mandate alone is not enough. So we're also investing a lot in enablement. We have AI Product Guilds, Slack channels where people can learn from each other, live sessions. As leaders we also need to model the behavior. I'll vibe code a prototype and discuss it with my direct reports. They get inspired — and a lot of times they're the ones inspiring me. They're close to the metal. They're building really amazing stuff.

Gunjan: We genuinely need to give these tools a shot. Explain what we want them to do and believe that they'll get there. The models of today may not fully get there, but the models of tomorrow definitely will. So a leap of faith, trying without aiming for perfection, was the aim. And you have to keep going back and trying. Today Claude Code is really good. Tomorrow something else might be better. Every six months, go back and try these tools because they might have unlocked something they couldn't do before.

What does success look like for your MCP tooling? What's the north star metric?

Gunjan: Very soon, I think we'll stop delineating between a user and an AI user. It's mostly about workflows. How many you're powering, and how they're accelerating. A team that punches out 100 tickets and hosts five scrums a month, with agents writing 100 PRs every day, you probably want a scrum every day to manage and control what's happening. Your KPI becomes: number of workflows orchestrated in your systems, irrespective of where the front end of that experience is.

Kosta: We're looking at it like any other product. We're seeing nonlinear growth in MCP adoption, both in terms of people using it and how much they're using it. But we're really trying to understand the workflows. What are people using it for? Are they being successful? Are they returning to use it again for those workflows? We're seeing real stickiness now, especially with things like code visualization. We’re still looking at how people use Miro overall, not just MCP. It's both.

If users are getting value from your product without ever opening your UI, what does that mean for your business?

Kosta: I'd flip this. If agents are doing the work, where do teams go to understand and steer them? Most AI tools are a black box. We think a lot about where you go to align those agents, how you make sure they're doing the right thing. For us, that's an opportunity, not a threat. Miro was built for team collaboration. That doesn't change. The team just got bigger.

Gunjan: Your moat is what you build. If someone else can rebuild your product faster than you can defend it, then yes, reconsider. But if you can double down on your moat and say "this is why people use our product and this is the best outcome for them," you can really focus. Being customer-obsessed gives you the right to ask your customers to stay with you. If they're happy with what you're providing, they will.

Francois: For us as an analytics tool, the user experience is super important. You need to be able to drill down, visualize, change things. The nice thing about MCP apps is you don't have to choose anymore. Power users can still go deep in the product. Business users can ask one question and get a chart right inside their agent. It's coexistence, not competition.

How is the product management function actually evolving?

Michelle: I'd love to stop writing Jira stories — and actually, AI is writing a lot of them for me now. But you still need the brain. What gets better: less rework, fewer bugs, because the context is retained and what you missed last time you won't miss next time. We're not spending as long on spikes. How much time did we spend reading API documentation to figure out if something was even possible? Within five minutes you can get that answer. Maybe no more spikes.

Kosta: Agents are picking up more of the execution and nitty-gritty work. But the real PM craft (the problem framing, the alignment, the communication) is more important than ever. You don't want agents running wild and deciding what to build. Nobody wants that world. So product people need to step up more, think more about the craft: problem framing, curating context. The role is shifting away from execution and toward higher-leverage activities.

Gunjan: The guardrails that held people back before: "I can't write code," "I don't understand the syntax,” those are gone. So problem identification is a big deal in the new era. Connecting dots is a big one too. AI is not going to connect dots for you. You need to see what problem to solve, what problem exists. And taste is a very difficult skill to build, and that hasn't changed. Doesn't matter what technology comes and goes. Spending time understanding what good is, in an experience or a product, that still matters a lot.

Ready to get started with Pendo MCP? Check out our prompt library, and get set up for free.