A work-in-progress 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.
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's 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're not lazy. That's 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 doesn't have to know which tool holds the answer.
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's 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's the part I'd 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's 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 aren't aspirational principles — they're the conditions Research Buddy is built around, and the questions I run any AI-generated finding through before using it.
If not, I don't 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's exactly where the human review step goes.
A designer asks, "What do users struggle with in onboarding?" and finds research that already exists, instead of assuming none does.
A PM asks about NPS feedback on a feature and gets Insocial, Productboard, and Condens in one place — and then goes and reads the sources.
Research becomes something the org can reach for itself. It is still work in progress — Qlik integration is in flight, the trust framework is enforced more rigidly in some sources than others, and the role outputs will keep evolving as designers and PMs use them.