AI can help a team make product decisions faster than ever. It still can't see what your users actually did, unless you give it access to the tests that show it.
Why ChatGPT and Claude don't know what your users did
It's frustrating to work with a tool that sounds confident about a product but has never seen a real person use it.
That is not because it is impossible for AI to know this. You could always copy a transcript or a set of findings into the chat, and then it would know exactly what happened in that one test.
The problem is what that requires. You have to know which test is relevant, find it, and paste it in every time a question comes up. Most of the time nobody does that. So the AI doesn't know, not because the evidence doesn't exist, but because getting it in front of the AI takes more effort than most questions feel worth.
Why user research gets stuck with one person
Most teams do not start with a lack of research. They start with a decision that needs to be made, a prototype that needs to be tested, and a few quick sessions that answer the next question.
Then the work keeps moving. More tests happen. More features land. More questions show up. At some point, the person who watched the sessions is the only one who actually remembers what happened.
That is not because sharing is hard. It is usually just because nobody stops to send the clip, and nobody has time to do the extra context pass when the work is already moving.
So the research remains with the person who ran the test. A few months later, even they have started forgetting the details.
An AI tool working only from a spec and a roadmap is in the same position as everyone else who was not in that loop. It does not have the information for the same reason most of the team does not: nobody ever handed it over.
How Userbrain MCP connects your user research to your AI tools
Userbrain MCP gives ChatGPT or Claude read-only access to what's already in your Userbrain account: tests, recordings and clips, transcripts, tasks and screenshots, and the findings Userbrain already generated.
The AI pulls from that existing analysis and only consults the full transcript when exact wording is required. The practical shift is simple: instead of manually finding a file and pasting it in, you ask a question and the AI searches across the research that already exists.
The point of connected research is not that the AI does the work for you. The point is that the AI helps you get back to the evidence faster.
That changes the workflow from “find the test, copy it in, and hope it helps” to “ask the question, find the relevant evidence, check the clip, decide.”
For product teams: from a confident answer to verified evidence
This is the most direct version of the fix above. Instead of a colleague having to remember what happened and explain it to you, you ask the AI, and it leads you back to the same evidence they would have shown you, if they'd had the time.
Before anything else, it's worth checking the connection is actually working. Ask something simple, like which test is most recent, and confirm a real answer comes back.
From there, a real conversation might go something like this. Start broad:
What are the three most important things we need to get right for people to trust and actually use this feature?
Then ask for the evidence behind the answer:
Please show me the clips. I want to see if this is really happening.
Now you are not reading a paraphrase. You are watching an actual person say the thing the AI just summarized, hesitate over the thing it flagged, or say out loud that they do not trust what they are seeing.
This can continue in the same conversation as the work moves:
Here's a screenshot of what we're working on right now. Based on
what we already know from testing, what should we address first,
and show me the clips that back that up.
Show me every tester who ran into this exact issue. I want to watch
the clips myself.
Every answer here can be traced back to an actual recording. If a claim sounds off, you do not have to take the AI's word for it. You go watch the clip yourself.
Consulting your research when a question comes up is useful. Using it while you're actually building is where it really pays off.
For marketing teams: validating your message against real customers
The same gap looks completely different from marketing's side of the building. A feature gets tested, product moves on to whatever's next, and what customers actually said about it rarely travels any further than the team that ran the test, not because anyone's hiding it, there was just never a natural moment to pass it along.
Marketing can close that gap without any research background, for the same reason product can: the analysis already exists, the only missing piece was a way to ask. Start with what's there:
Is there a test about [feature]?
Say two tests come back. Picking the one with more participants is a reasonable default. From there, the useful question isn't "summarize this." It's more specific:
How do customers describe [feature] in their own words?
Once that comes back, the real value shows up in the follow-up, and it's less about generating brand-new copy than about checking the copy or positioning you probably already have a draft of:
Based on that, what should we communicate, and what should sales be
ready to discuss? Use the customers' own language, tie every point back
to evidence, and clearly separate what customers actually said from
what you'd suggest doing about it.
That last instruction, separate the evidence from the interpretation, is worth using on purpose, not just here. It's a small thing to ask for, and it means you always know which part of the answer is a direct customer quote you could go check, and which part is the AI's own read on what to do with it.
Worth knowing: asking for people's "own words" specifically means the AI needs the actual transcript, not just the pre-generated summary, so this kind of question can take a little longer and use more of your usage budget than a general findings request.
It's usually worth it. What comes back is the actual language customers reach for, useful for checking whether a message you already wrote matches what customers actually said, or for catching a claim that sounds good but isn't really backed by the test.
And here's the part worth repeating, because it's the actual value, not a nice-to-have: every one of those findings still links back to the original video. If three or four people are independently saying close to the same thing, that's exactly the moment to watch the recording instead of trusting the summary.
Reading a paraphrase and watching a real customer say it land very differently, and the check takes thirty seconds. This isn't a side benefit of using AI for research. It's the reason it's safe to use in the first place: nothing here has to be trusted blindly, because there's always a real person on the other end of the link.
How to search years of old user research with AI
Some of the most useful searches don't start with a test name at all, just a vague memory.
Find the test with a participant who was an older man, a bit grumpy,
mentioned some background in software development.
No test name, no date, nothing exact, just an impression. The AI proposed a candidate. It was wrong. It kept looking, and it found the actual person, out of a participant pool running into the tens of thousands, from that loose description alone.
A bigger version of the same idea: over several years, informal outreach research had quietly built up, the same kind of question (how are you testing today, what's not working) asked to different customers and prospects, in different contexts, never planned as one study. Nothing tied any of it together. It just sat there as 55 separate tests, each one answering a small piece of a bigger question nobody had ever fully asked.
| One test at a time | Every test at once |
|---|---|
| Open each test individually | One question, across all of them |
| Search transcripts by hand | Pulled and collated automatically |
| Research quietly forgotten | Research becomes usable again |
Asking the AI to pull the transcripts from all 55 and bring them into one document for analysis used to mean opening every one of them by hand and copying evidence out one piece at a time. Connected like this, it's a single request, really the same fix from the very start of this article, just working backward across years of research instead of one recent test.
Check your own opinion before it becomes a decision
This is the same gap again, just internal.
A product person notices something in a design and has a strong opinion about it before checking whether the issue actually came up in testing. The usual path is to track down whoever ran the study and ask what happened.
Instead, the question can be direct:
Has anyone in testing noticed this issue, and did it actually cause a problem?
In one real example, the answer was: yes, it had been noticed, but it had not caused a problem.
That is the real value of this workflow. It catches assumptions before they become decisions.
It is less about winning an argument and more about reducing the number of decisions made on a hunch.
For sales teams: preparing before the questions come up
Sales usually learns what customers are worried about in the room, in real time, on a call.
A connected AI tool changes that.
Before a release, sales can ask what concerns already came up in testing and get a head start on likely objections instead of hearing them for the first time:
Based on this test, what questions or objections should sales be ready
for, and what is the evidence-based answer to each one?
That produces something closer to a prep sheet than a generic summary.
It also keeps current functionality and roadmap ideas separate, so sales is not caught promising something a tester merely wished existed.
Making user research accessible for the whole team
Everything above points at the same underlying shift: once Userbrain is connected through MCP, research stops belonging to whoever ran the test, or to a dedicated research team, and becomes something the whole company can reach directly.
That's not a new idea in UX research generally, teams have long been encouraged to pull in what sales and support already hear from customers, since those conversations surface real complaints and a real mismatch between how customers talk and how the team does. What's new here is that the same access now works in both directions: those teams can go straight to the evidence themselves, instead of relying on someone else to translate it for them.
| Department | What they might ask | What it's for |
|---|---|---|
| Product | What's still unresolved from the last test? | Prioritizing fixes with evidence, not a guess |
| Marketing | How do customers describe this, and does our messaging match? | Checking positioning against evidence, not assumption |
| Sales | What questions or objections should we be ready for? | Preparing before a concern comes up live |
| Customer Success / Support | Has this exact confusion shown up in testing before? | Knowing if it's a known issue, and explaining it with confidence |
| Anyone on the team | Has this already been tested? | Settling a debate or avoiding research that already exists |
None of this requires the person asking to have watched a single session. It only requires the account to be connected.
There's a second effect worth naming, beyond speed. A team that can reach real customer evidence on its own tends to end up closer to the customer, not just faster. Checking what a real person actually did, whenever a real question comes up, builds a kind of everyday empathy that a quarterly research readout never quite manages.
Where to start
This is the real shift: research stops being something you find later. It becomes something you can use while the decision is being made.
Your AI tool should have access to the user tests you already have, right where you work.
Pick one test, recent or long-forgotten. If you don't have one yet, Userbrain's trial includes two free testers, and its auto-create your tasks can turn any URL into a running test in seconds.
Connect the account to the AI tool already in daily use. Ask one question that actually matters to your work right now, not a test question, a real one. Then open the clip behind the answer.
That's usually the moment it clicks, not when the AI answers, but when the answer leads straight back to a real person saying it.
