Before You Build Your Next MCP: Think Like a PM

Great engineering teams build technically perfect MCPs that nobody uses.

Why? Engineers think in capabilities. PMs think in jobs-to-be-done. The result? Poor MCP UX that gets ignored despite being technically sound.

Capabilities vs. Jobs

The difference is fundamental:

❌ Capability thinking: "Here are our API endpoints as tools"

✅ Jobs thinking: "Here's the job users are hiring AI to do"

Technical completeness doesn't equal adoption. Users don't care that your MCP exposes every API endpoint perfectly. They care whether it helps them get their job done.

Start With the Job

Think like a PM before you write a single line of code:

Talk to users. What are they actually trying to accomplish? Not what your API can do—what problems are they solving?

Simulate their workflow. Where will they interact with your MCP? Cursor? ChatGPT? n8n? The context matters.

Design for progress. People don't want products. They want to make progress. Your MCP should be a tool for progress, not a catalog of API endpoints.

Example: The Monday.com MCP

Let's say you're building the Monday.com MCP. Here's the wrong approach:

❌ Expose every API call:

• get_ticket_by_id
• update_status
• list_all_items
• create_board
• delete_item

Technically complete? Yes. Does it help users get their jobs done? No.

Here's the right approach:

✅ Design for actual jobs:

• "Show my ongoing tasks"
• "Create weekly summary"
• "What's blocking my team?"
• "Update all high-priority items to in-progress"

Same underlying API. Completely different UX. The second approach anticipates what users are trying to accomplish and makes it simple.

State of the Art

Some teams are already getting this right:

Apify anticipates web scraping workflows. While you're prompting, it fetches relevant actors in the background. It feels like magic because it's designed around the job of web scraping, not around their API structure.

Figma speaks designer language. Their remote MCP includes extensive resources so AI can handle various user journeys seamlessly. They mapped design workflows first, then built the MCP.

Plan Your Tools Around Jobs

When you understand the jobs, you can design your MCP properly:

Tools should map to actions users want to take, not just API endpoints.

Resources should provide context AI needs to help users complete their jobs.

Prompts should guide AI toward common job patterns, not just explain what each tool does.

Think like your user. Map the jobs they're hiring AI to do. Then build your MCP around those jobs.

The PM Hat Makes the Difference

Before you build your next MCP, put on your PM hat. Leave the engineer hat off—just for a bit.

Map the jobs. Talk to users. Simulate workflows. Design for progress, not capabilities.

Then—and only then—put the engineer hat back on and build something people will actually use.