The AI User Researcher for Interviews and JTBD

User research is the discipline that turns gut feelings into grounded decisions, and it is also the discipline that gets cut first when a team is moving fast. Not because it lacks value, but because it is operationally expensive. An interview guide takes an afternoon to write. Recruiting takes a week. Conducting six sessions takes another week. Synthesis takes two days, if you are disciplined. By the time you have an actionable insight, the team has already shipped the feature they were going to build anyway. The result is a widespread professional habit of skipping discovery entirely and calling retrospective user testing "research." What product teams need is not a reminder that research matters, they already know that. They need the operational cost of research to drop low enough that it fits into a sprint rather than a quarter. That is the gap that ai user research tools promise to fill, and that is the gap that most of them fail to close because they treat research as a text-generation problem rather than an epistemological one.

Why the generalist approach fails at research

When you ask a generalist chatbot to help with user research, you get a version of help that resembles research without producing its substance. Ask for an interview guide and you get a template, generic questions that any product could ask, structured in a reasonable order, missing any grounding in the specific job your users are trying to do or the specific assumption your team needs to test. Ask for persona synthesis and you get a fictional character assembled from stereotypes rather than from the behavioral patterns in your actual user data. Ask for JTBD analysis and you get a lecture on the framework followed by some illustrative examples, rather than an actual ranked list of jobs derived from your interviews. The generalist has no method for the parts of research that matter most: designing questions around hypotheses, probing for underlying motivations rather than stated preferences, distinguishing signal from noise across multiple interviews, and translating raw quotes into actionable insight.

Dedicated user research tools, Dovetail, Aurelius, EnjoyHQ, solve the storage and collaboration problem. They give you a place to upload interview notes, tag quotes, and share findings with the team. What they do not give you is research expertise. They organize the material you already have; they do not produce the synthesis you need. A junior researcher using Dovetail is still a junior researcher with a better filing system. The analytical judgment, what jobs matter, which segments behave differently, where the persona splits, still lives in a human head, and on most product teams, that head is already overloaded. The tool problem and the expertise problem require different solutions.

The deeper failure mode is treating research output as a destination rather than a decision-support tool. A generalist produces an artifact, a persona doc, an interview summary, a list of insights, and stops. A skilled researcher knows that the artifact exists to change a specific decision. The right output format, the right level of detail, the right framing are all calibrated to the decision it is intended to inform. When the output is not calibrated to the decision, it gets filed, presented at a review meeting, and forgotten. That is why most companies have a "research graveyard", a Confluence page full of well-formatted insights nobody acted on. The problem was never a lack of research. It was a lack of research designed to be used.

What a user researcher actually does

A senior user researcher is not primarily an interviewer. They are a translator between the messy reality of how humans think about their problems and the structured vocabulary that a product team can act on. That translation happens in stages: scoping a study to test a specific hypothesis; designing questions that surface underlying jobs rather than surface preferences; probing during interviews to move past the scripted answer to the real one; synthesizing across sessions to find what is consistent, what varies by segment, and what contradicts the team's assumptions; and framing the output so that the PM reading it understands not just what users said but what the team should do differently. Each stage requires a different kind of expertise, and each stage is where most ad-hoc research attempts break down.

The Jobs-to-be-Done framework, specifically, requires a level of analytical rigor that most generalist approaches miss. JTBD is not a question type, it is an epistemological stance. The claim is that people hire products to make progress in their lives, and that understanding the job (the progress they are trying to make) predicts behavior better than demographic segmentation or stated preference. Producing a valid JTBD statement requires identifying the functional job, the emotional and social dimensions, the circumstances that trigger job activation, and the metrics the user uses to evaluate whether the job was done well. Getting that from a single interview is hard. Getting it consistently across a cohort, ranked by frequency and importance, requires systematic analysis that goes well beyond keyword tagging.

Meet Echo

Echo is Tonone's dedicated AI user researcher, a purpose-built agent for the full discovery workflow from interview design through persona delivery. It is not a transcription tool or a quote-tagger; it is a research partner that brings the analytical discipline of a senior researcher to the work of understanding users. Echo knows how to design questions that test hypotheses, how to synthesize raw interview notes into structured insight, how to produce JTBD statements with rigor, and how to segment users based on behavioral patterns rather than demographic proxies. The operational cost of running a research cycle with Echo is a fraction of the manual equivalent, which means research becomes something you do before every major decision, not once a quarter.

Tonone's Echo is the AI user researcher that turns raw interview notes into structured JTBD statements, synthesis reports, and persona cards grounded in real usage data.

What Echo actually does

Designing interviews that surface real jobs

The echo-interview skill produces a complete, hypothesis-grounded interview guide rather than a generic template. You give Echo the context, what feature or decision the research is meant to inform, what the current team assumptions are, what segment of users you are speaking to, and it designs a guide structured around probing for underlying jobs rather than collecting feature opinions. The output includes an opening section to establish context and build rapport, a set of core questions that use techniques like the five-whys and switching-moment probes to surface the real job, and a closing section that validates the interviewer's interpretation back to the participant. Each question includes a note on what signal the interviewer is looking for, making the guide useful even for someone running their first interview. The echo-interview skill also flags leading questions and rewrites them into neutral form, which is one of the most common quality failures in interviews designed by non-researchers. The guide is calibrated to a target duration (usually 45 or 60 minutes) so you are not discovering mid-session that you have 20 more questions than time.

Producing scored JTBD statements from raw data

The echo-jobs skill is where the analytical core of Echo lives. You give it raw interview notes, transcripts, or synthesis notes from any number of sessions, and it produces a structured set of Jobs-to-be-Done statements: each one covering the functional job, the emotional dimension, the triggering circumstance, and the success metric the user applies. The jobs are scored by frequency (how many participants expressed this job) and importance (how critical participants rated it relative to alternatives). The output is not a ranked list of quotes, it is a synthesized model of what your users are trying to accomplish, at the level of specificity that allows a PM to make design decisions directly from the output. echo-jobs also identifies opposing jobs, cases where different segments of users are hiring the product to accomplish fundamentally incompatible things, which is often the diagnosis for why a product feels unfocused or generates polarized reviews. Getting that diagnosis from a human researcher requires weeks of analysis; echo-jobs produces it from the notes you already have.

Synthesizing feedback from any source into structured insight

Research does not only come from interviews. Support tickets, NPS comments, app store reviews, sales call notes, and community forum posts all contain user intelligence, and most of it never gets analyzed because the volume is too high for manual synthesis and the format is too varied for structured tools. The echo-feedback skill takes any collection of unstructured text, paste in a CSV of support tickets, a Notion page of sales notes, a batch of NPS verbatims, and produces a structured synthesis: recurring themes organized by frequency, representative quotes for each theme, and a severity assessment (cosmetic issue, friction, blocker, or churn driver) for each finding. The output is designed to be presented directly to a product team without further editing. echo-feedback also produces a "what changed" diff when you give it two batches from different time periods, the most reliable signal that a product change actually improved the user experience rather than just shifting the complaints from one area to another. That longitudinal view is something no tagging tool produces automatically.

Segmenting users by behavior and job, not demographics

The echo-segment skill takes the output of research synthesis, interview notes, JTBD data, behavioral logs, survey results, and produces a behavioral segmentation: groups defined by what users are trying to do, how they make decisions, and where they get stuck, rather than by age, company size, or job title. Demographic segmentation is the default because it is the easiest data to collect, but it is almost never the right input for product design decisions. The user who activates immediately and the user who churns in week two often have identical demographics and very different jobs. echo-segment builds segments that a PM can actually use: each one comes with a description of the job, the trigger that activated the segment's hiring decision, the key friction points, and the design principles that follow from the segment's priorities. It also identifies the highest-value segment, the one where the product's differentiated value is strongest and the job-fit is highest, which is the input Helm needs to build a focused product brief.

Fast reconnaissance before any research begins

Before running a research study, it is worth knowing what the team already knows, and what they think they know that might be wrong. The echo-recon skill takes the context of a product or feature area and produces a rapid intelligence brief: what the public user reviews say, what the support ticket patterns suggest, what the product's positioning implies about its intended job, and what questions remain genuinely open versus questions that are already answered by existing data. This is the step that prevents teams from running a six-week research study to answer a question that was already answered in the last NPS survey. echo-recon also flags the riskiest assumptions in the current product thinking, the ones where the team is confident but the evidence is thin, so the interview guide targets the decisions with the highest uncertainty rather than the questions with the most interesting answers. For teams new to structured discovery, echo-recon is the right place to start: it orients the whole research workflow toward the decisions that actually need to change.

A worked example

A B2B SaaS team wants to understand why activation is stalling for teams with more than five members. They have NPS comments, a few sales call notes, and some Intercom tickets but no structured research. They run echo-recon first, which identifies three recurring themes across the existing data and flags the riskiest assumption: the team believes the issue is feature discoverability, but the data suggests it might be a role-based access control problem. The recon output recommends a 45-minute interview study targeting team admins and members separately.

Echo then produces an interview guide via echo-interview. The guide includes separate tracks for admins and members with shared synthesis questions. An excerpt looks like this:

## Echo Interview Guide, Team Activation Study

### Opening (5 min)
- "Walk me through the last time your team started using a new tool together.
  What made that rollout go well or not?"

### Core probe, switching moment
- "Can you take me back to the moment you decided to try [Product]?
  What was happening that day?"
- Follow-up: "What had you been doing before that wasn't working?"
- Follow-up: "Who else was involved in that decision?"

### Job probe, admin
- "When you set up [Product] for your team, what were you trying to make happen?"
- "What would have to be true for you to feel like the setup was a success?"
- Probe: "How do you know when a team member is actually using it vs. just signed up?"

### Job probe, member
- "What's the thing you most need [Product] to help you do in your day-to-day work?"
- "Tell me about a time it didn't work the way you expected."
- "If [Product] disappeared tomorrow, what would you use instead? What would you lose?"

---
### Synthesis key
| Question            | Signal target                        |
|---------------------|--------------------------------------|
| Switching moment    | Triggering circumstance for job hire |
| Setup success       | Admin's functional job               |
| Disappears tomorrow | Revealed preference / job criticality|

After six sessions, the team feeds notes into echo-jobs. The output surfaces three distinct jobs, team coordination, individual task tracking, and manager visibility, with the insight that admin and member jobs are in direct conflict: admins want visibility, members want autonomy. That JTBD diagnosis reframes the activation problem entirely: it is not a discoverability issue, it is a role-design issue. The team routes that finding directly to a product brief in Helm rather than building a feature walkthrough that would have solved the wrong problem. The entire research cycle from recon to JTBD output took four hours instead of four weeks.

Echo vs the alternatives

Echo is not a transcription service, a survey tool, or a tagging system. It occupies the analytical layer of the research workflow, the layer where expertise, not tooling, has been the limiting factor. The comparison below maps where the alternatives fall short and where Echo fills the gap.

Tonone's Echo produces scored JTBD statements, behavioral segments, and synthesis reports from raw interview notes, outputs that require a senior researcher's analytical judgment, not just a better filing system.

Tonone's Echo echo-segment skill builds behavioral segments from JTBD data, groups defined by what users are trying to do and where they get stuck, not by job title or company size.

Install and try

Tonone is free and MIT-licensed. Install it once and all 23 agents, including Echo, are available in your Claude Code session. You pay only for the Claude Code token usage during work. Start with echo-recon on your current product area to see what your existing data already knows.