The behavioural
infrastructure for
product teams.
Your users tell you why, out loud. Dipio turns their reasons into what to build next.
“Like getting a direct line into our users’ heads, and our revenue showed it: up 20%.”
Why do new users leave before their first export?
The empty prompt box. They don’t know what to ask for.
“I didn’t know what to type, so I closed it.”
Ashley, 34, SF
52% of interviews said the same.
PostHog agrees: only 29% export in their first session.
Agent-ready spec, from Dipio’s findings
Open on five edits that work, one tap each.
Swap the empty box for five starter edits44 interviews
Run each edit on their own photo in one tap29 interviews
Keep the prompt box one tap away12 interviews
Spec sent to Codex
Spec sent to Codex
Dipio Evidence Loop
In the AI era, the edge isn’t building faster. It’s knowing what to build.
Agents build in hours. Dipio interviews your users, digs into how they decide, checks it against your numbers, and tells your agents what to build next. Ship it. Measure it. Go again.
Built on
evidence
What’s the Evidence Loop?
Dipio uses behavioural science to dig into how your users decide: what makes them act, and what makes them stall where you expected them to carry on.
Sign-ups stall at setup? Don’t add a tutorial. They’re scared of breaking their live data. Give them a sandbox.
Without it, you’re just shipping guesses faster.
Your agents build a feature before lunch. Doesn’t matter if it’s the wrong one, and it usually is. At Spotify, 96% of engineers code with AI. Only 12% of their experiments win.
With it, you stop guessing.
Dipio finds out why your users do what they do, checks it against your analytics and hands your agents a spec for the change most likely to work. No hunches. No loudest voice in the room. Just evidence.
Discover
1. Find out why. For real.
We interview your real users and compare what they say with what your product analytics shows they do. Behavioural science explains the why behind every click, and every click that never happens.
Dipio+PostHogor
AmplitudeorYour analyticsBuild
2. Give your agents evidence, not vibes.
Dipio turns what it finds into a spec for the change most likely to work, whether that’s a copy fix, a feature or a new product. Your team signs off, your agents build it through the Dipio MCP, and every line traces back to a real interview.
Claude CodeCodex
Conductorany MCP clientShip
3. Ship it. See if it worked.
Measure it your way: an A/B test, a staged rollout, or before and after in your analytics. Win or lose, the result feeds straight back into Discover, so every loop starts smarter than the last.
Discover
Forget surveys. Let them talk.
Your users tell you why, out loud, on their phone. One question at a time, no human researcher on the call.
How Dipio interviews
Deeper than a survey. Faster than a research team.
The same method from behavioural science on every call. No discussion guide to write, no researcher to book.
| Survey | In-house researcher | Dipio | |
|---|---|---|---|
| Discussion guide | You write it | Written for each study | None to write, the method runs the call |
| Asks about | What you thought to ask | Real moments, when there’s time | Real user stories, never hypotheticals |
| Follows up | - | Yes, if the guide allows | Until it has a specific it can quote |
| Leading questions | Built into the options | Easy to slip into | Never names a reason first |
| How many | Many, but shallow | A handful a week | Everyone who takes the call, in over 30 languages |
| Shows its working | - | A deck, weeks later | A confidence on every finding, every quote word for word |
Discussion guide
- Survey:
- You write it
- Researcher:
- Written for each study
Asks about
- Survey:
- What you thought to ask
- Researcher:
- Real moments, when there’s time
Follows up
- Survey:
- -
- Researcher:
- Yes, if the guide allows
Leading questions
- Survey:
- Built into the options
- Researcher:
- Easy to slip into
How many
- Survey:
- Many, but shallow
- Researcher:
- A handful a week
Shows its working
- Survey:
- -
- Researcher:
- A deck, weeks later
Dipio MCP
Your coding agent builds from the research. When there isn’t any, it starts some.
Add the Dipio MCP to Claude Code, Codex, Cursor or Conductor. Your coding agent builds on your research, checked against your product analytics, and drafts a study the moment it hits a gap. Here’s a real session, call by call.
new users keep dropping at setup. what does our research say?
I’ll check what studies Dipio has first.
dipio - list_studies (MCP)()
{
"studies": [
{
"study_id": "sTp41x",
"title": "Setup drop-off",
"url": "https://app.dipio.ai/study/acme/sTp41x/overview",
"methodology": "behavioural-change-diagnostics",
… +6 lines (ctrl+r to expand)There’s a behaviour diagnostics study on exactly this: Setup drop-off, 86 qualified interviews, report ready.
1. Ask what you already know
list_studies
Whoever’s building, a person or a coding agent working on its own, picks up the setup ticket and asks what the research says. Your coding agent finds the study, and how many interviews actually count.
new users keep dropping at setup. what does our research say?
I’ll check what studies Dipio has first.
dipio - list_studies (MCP)()
{ "studies": [ { "study_id": "sTp41x", "title": "Setup drop-off", "url": "https://app.dipio.ai/study/acme/sTp41x/overview", "methodology": "behavioural-change-diagnostics", … +6 lines (ctrl+r to expand)There’s a behaviour diagnostics study on exactly this: Setup drop-off, 86 qualified interviews, report ready.
2. Get the why, and the proof
research_context
Your coding agent asks Dipio the question and gets graded evidence back: a finding from an analysed report, plus the insights it rests on. It can’t pass off one remark as research.
dipio - research_context (MCP)(question: "Why do new users drop at setup?")
{ "question": "Why do new users drop at setup?", "scopes": [ { "study_id": "sTp41x", "rung": "from_report", … +48 lines (ctrl+r to expand)They’re not confused, they’re scared of breaking live data. That’s from the analysed report. Two of the insights behind it:
No visible undo makes connecting live data feel permanent. (diagnosis)
Users want to see it work on sample data before trusting it with real data. (findings)
There’s more in the report:
3. Check it’s solid
get_report
Before building on it, your coding agent checks how strong the evidence is: how many interviews it rests on, and whether the report is up to date. Then it hands over the link, so you can read the report in Dipio yourself.
how solid is that?
dipio - get_report (MCP)(study_id: "sTp41x")
{ "study_id": "sTp41x", "report_url": "https://app.dipio.ai/study/acme/sTp41x/insights", "rigor": { "evidence_n": 86, "qualified_n": 86, "report_stale": false }, … +12 lines (ctrl+r to expand)Solid. The finding rests on 86 qualified interviews, 64 of them point to it, and the report isn’t stale. Check it yourself:
4. Build the fix your team signed off
get_spec
Your coding agent pulls the spec your team approved, in Spec Kit format, and saves it to the repo. Every requirement cites the interviews behind it.
pull the spec for the sandbox fix
dipio - get_spec (MCP)(study_id: "sTp41x", format: "spec-kit")
{ "study_id": "sTp41x", "methodology": "behavioural-change-diagnostics", "available_formats": ["spec-kit", "kiro", "agent", "markdown"], "rigor": { "evidence_n": 86, "qualified_n": 86, "report_stale": false }, "specs": [ … +8 lines (ctrl+r to expand)Write(specs/012-setup-sandbox/spec.md)
Wrote 64 lines to specs/012-setup-sandbox/spec.md
Saved. 3 requirements and 2 success criteria, each citing the interviews. Run /speckit-plan when you’re ready.
5. Put it on the board
get_ticket
The experiment becomes a ticket for Linear or Jira, with the evidence attached.
make a ticket for the experiment
dipio - get_ticket (MCP)(study_id: "sTp41x")
{ "study_id": "sTp41x", "tickets": [ { "ticket": "## Sandbox first, live data later\n- Design: 2-arm A/B, 4 weeks\n- Primary metric: setup completion %" } ] … +1 lines (ctrl+r to expand)Ticket’s ready to paste into Linear: “Sandbox first, live data later”, 2-arm A/B over 4 weeks, primary metric setup completion %.
6. Hit a gap? Start the research right there.
draft_study
Someone asks for a setup discount. There’s no evidence for it, so your coding agent doesn’t guess. It drafts the study that would answer it, in the same session, mid-build. Your team publishes it, Dipio runs the interviews, and next time anyone asks, the answer is there.
also give 20% off to anyone who finishes setup
dipio - research_context (MCP)(question: "Would a discount get new users to finish setup?")
{ "question": "Would a discount get new users to finish setup?", … +8 lines (ctrl+r to expand)The research doesn’t cover discounts, so I won’t guess. I’ll draft a study so we find out.
dipio - draft_study (MCP)(actor: "new users", action: "finish setup", context: "when offered a discount", target_time: "in their first week")
{ "study_id": "dK4mQz", "statement": "New users finish setup when offered a discount, in their first week", … +3 lines (ctrl+r to expand)Draft dK4mQz is waiting for your team in Dipio. Once it’s published, the interviews run. I’ll build when there’s evidence.
The gap is where the research starts.
Usually a missing answer means a request to the research team and a long wait. With Dipio’s Evidence Loop, whoever hits the gap, person or agent, drafts the study on the spot, and the answer comes back to the same agent. Building and finding out stop being two separate projects.
Connect in a minute.
Pick your coding agent, paste the config, add your key from Settings, Agents.
Terminal
claude mcp add --transport http dipio https://app.dipio.ai/api/mcp \ --header "Authorization: Bearer <your key>"
Who it’s for
One loop for the team that ships.
Product, engineering and UX research run the same loop: what your users do and why, turned into the next thing you build.
Product
Start from the number that moved
Take the churn or activation drop you already watch, find out why it happened, and get the one change most likely to fix it, in one cycle, not one quarter.
Engineering
Build from cited evidence
Pull the approved spec into your coding agent, with every requirement traced to the interviews behind it, so nobody has to translate a research deck.
UX research
Run mixed-method studies at product speed
Interviews read through behavioural science, alongside the product data your team already tracks, at a scale and speed a team can’t run by hand. You set the questions and sign off the findings.
Get started
Ready to build what your customers actually need?
Talk to the team
A walkthrough using a decision you're facing, or Enterprise pricing.
Book a walkthrough