An internal tool that puts six fragmented research and product sources behind a single plain-language query, runs qualitative and quantitative agents in parallel, and reformats the synthesised findings for whoever is asking — researcher, designer, or PM.
My role: I designed and built Research Buddy end to end.
A short walkthrough — posing a plain-language question, the qualitative and quantitative agents working in parallel across the connected sources, and the synthesised brief shaped for the asker's role.
Research data lives in six tools and nobody searches all six. Each department installed the tool that worked for them — so the research that already answers a product question is often invisible to the person asking it.
Research exists. It is been done. It lives in Condens, in an old SharePoint deck, in Productboard notes from six months ago. But finding it means logging into multiple tools, running multiple searches, and reading dozens of docs — so people skip it.
They are not lazy. That is an infrastructure problem.
Each source is owned by a different team — research, product, customer success, analytics — and stores a different kind of evidence. Research Buddy queries them in parallel so the asker does not have to know which tool holds the answer. Five are live; Qlik is still being connected.
Research team
Interview insights, session recordings, highlights.
Product team
Feature requests, user feedback, roadmap priorities.
Research / Product / CS
Survey responses, open-ended answers, form data.
Customer Success
Product feedback, NPS responses.
Everyone
Notes, presentations, decks.
Analytics / Sales
Churn data, business metrics, usage analytics.
Ask in plain language. All sources queried at the same time. Less tab-switching, no need to know which tool holds the answer.
Same data, returned differently depending on who is asking. A PM gets business framing. A designer gets pain points. A researcher gets evidence and methodology.
Qual from Condens alongside product usage data from Qlik, and product feedback from Insocial alongside feature votes from Productboard — in the same answer, not in seven tabs.
A qualitative agent and a quantitative agent run in parallel against the connected sources. A third agent — the Data Scientist — cross-references their findings, flags gaps and contradictions, and recommends follow-ups before the answer is shaped to the asker's role.
AI handles the volume problem well but misses the nuances. The split between what the agents do and what I do is deliberate, and it is the part I would defend hardest.
Thousands of Insocial product feedback responses — clustering open-ended comments, surfacing recurring phrases, segmenting by theme.
Large Typeform surveys — finding distributions in open-ended answers that would take days to read manually.
Demographic and product usage data from Qlik — relevant quantitative data with charts.
What the patterns mean — AI surfaces clusters; I decide what is a signal.
Writing conclusions — AI drafts; I rewrite after reading representative samples from each cluster.
Presenting to stakeholders — every claim I make is traceable back to a named participant or source.
These are not aspirational principles — they are the conditions Research Buddy is built around, and the questions I run any AI-generated finding through before using it.
If not, I do not use it. Research Buddy hardcodes this — every finding requires source, item name, and date.
Aggregation and pattern detection: yes. Deciding what patterns mean, writing conclusions, making recommendations: human.
If the answer is no, that is exactly where the human review step goes.
Product managers using Research Buddy kept saying they would rather talk to it than write to it. Taken literally that is a request for a microphone. Taken seriously it is something else: they know what decision they are facing, and they cannot compress it into a query.
Voice on its own does not fix that. Sending a transcript straight to retrieval produces the same weak query, only longer and with filler in it. So the design I am working on treats speaking and typing as two ways to fill one query object, with a confirmation step in between that is the actual feature.
A PM describes the decision in their own words: what they are weighing, what they have heard, and what they doubt. That is not a query, but it carries the decision, the hypothesis and the uncertainty, all of which a typed query throws away.
Buddy does not answer it. It plays back what it heard as an editable structure: topic, decision, doubt, sources, time window. Approving a query is far easier than composing one, which is the whole point.
Structured askers skip the microphone and fill the same fields directly, or type a sentence and get the same panel back for review.
Both paths converge on one query object, so there is one retrieval contract to maintain rather than two interfaces that drift apart.
One clarifying turn, where it costs least
My evaluation of TOPdesk's AI chat surfaces found that the largest single failure cause was answering a question that forks on an unknown detail, rather than asking. Spoken input forks more often than typed input, because it is vaguer. So when the topic resolves to more than one module, or the doubt is unstated, Buddy asks exactly one question before it searches. Putting that question inside the confirmation panel makes it cost a tap rather than a conversational round trip.
Three details that decide whether it feels good
Keep the transcript, collapsed. People want to check they were heard. They do not want to reread their own rambling every time.
Product nouns break transcription. Knowledge item, SLM, Insocial, module names. Topic fields need one-tap correction and a custom vocabulary.
Leave an escape. A direct send that skips the panel, or the scaffold becomes a toll on people who already know what they want.
There is a second-order benefit that decided it for me. Every confirmed panel is a labelled record of what somebody actually meant by their question, which is the evaluation set this tool does not otherwise have.
Research Buddy is built, running, and used by product managers, designers and researchers.
It is not instrumented, so I cannot tell you how many queries it handles or how much time it saves, and I would rather say that than invent a number.