The Question
When MCP started appearing everywhere in AI product conversations, my first instinct was: Should Encatch have one too? But that turned out to be the wrong first question.
A more important question would be where and how our users would benefit from having this addition? This led me through an interesting journey with MCP, exploring its possibilities, and figuring out where it could genuinely add value to Encatch.
The Decision
Encatch helps product teams collect and manage user feedback through in-app feedback forms and shareable forms. A product manager can gather responses, and use those to identify patterns and opportunities.
Now, to answer the question, I dug deeper into the current usage patterns.
While we provide AI assisted capabilities which help end users build forms from scratch using just a prompt, it still however, requires the user to enter Encatch, navigate through the application and land on the relevant page.
This led us to an assumption:
Product managers may want to interact with their feedback through the AI tools they already use, instead of constantly switching between multiple platforms.
Because we were still at an early stage, we didn't have enough customer data to validate these assumptions directly. So we treated them as hypotheses rather than fact.
We wanted Encatch to meet our users where they are already comfortable. And that’s what led us to the decision to build Encatch MCP.
But how?
Competitor research helped me understand how other products were approaching MCP. One common approach was to expose existing API functionality as MCP tools. From a product perspective, we had to ask whether exposing an API automatically created a useful user capability. We wanted to do better.
The Approach
The biggest mistake we could have made was starting with a list of tools to expose through MCP. Before deciding what the AI could do, I needed to understand what the user was trying to accomplish.
When we looked at the core tasks a product manager performs in Encatch, most of the use cases boiled down to three things:
- Create form
- Retrieve feedback responses
- Analyse the responses
These became the foundation of our MCP.
Simply put, we built the MCP with all the tools encapsulating the above 3 tasks.
The Challenge
At this point, we had solved the obvious problem.
Our assumption was that once the MCP was built and connected to an LLM tool, ease of use would be a given.
But while using the feature myself, I observed that while I can build an entire form from scratch without having to actually enter the platform, previewing it real time still posed to be a challenge.
Certain LLM tools have restrictions around their in-app browsers, which meant that the browser would not automatically reflect the changes being made through the MCP. An end user would have to manually refresh the browser page to review the changes. This would break a user experience.
The Alternative solution
This led us to an alternative solution. We used Convex to facilitate push based refresh, which freed the user from laboriously doing it from their end. This was a good reminder that building the capability is only one part of the problem.
The real question is:
Does the capability result in a good experience for the user?
Finish line
We have now reached the end of development and moved the MCP to LIVE.
The next question is much more interesting:
How does user behaviour change now that Encatch can be accessed through an AI tool?
We explored the possible use cases and built what we believe is a useful starting point. But it is still too early to determine whether our original hypothesis was correct.
Will users actually connect the MCP? Will they use it repeatedly? Which capabilities will they find useful?
And, most importantly, does it actually make their workflow better? It's to be determined whether it is creating enough value for users to change their behaviour.
Conclusion
Building the Encatch MCP started with what seemed like a fairly simple question: “Should we build an MCP?”
But the more useful question turned out to be: “What problem would an MCP solve for our users?”
Instead of starting with the technology and figuring out what we could expose, we started with the user's workflow and worked backwards. And now that we've shipped, the next phase of the product journey begins: finding out whether our hypothesis holds true in the real world. For me, that's probably the most interesting part of building products.