⚠ Synthetic pre-research — AI-generated directional signal. Not a substitute for real primary research. Validate findings with real respondents at Gather →
Projected from interview analyses using Bayesian scaling. Treat as directional estimates, not census measurements.
Side-by-side comparison of sentiment, intent, buying stage, and decision role across all personas.
Complete question-by-question responses with per-persona analysis. Click any respondent to expand.
Jordan is a pragmatic, analytically-minded PM who has adopted several AI tools but remains measured and somewhat skeptical about their net value. The core tension is whether AI is genuinely improving output quality or merely accelerating the path to mediocre results. Jordan is particularly cautious about AI-generated research synthesis, wanting validation that it surfaces novel insights rather than just summarizing known information faster. The team is approximately halfway to Jordan's definition of 'good' — seamless workflow integration with minimal manual handoff. The most underexplored concern Jordan raises is not tooling selection but internal trust: getting engineers and designers to act on AI-generated research is a cultural and alignment problem that receives less attention than it deserves.
Tell me what's top of mind for you on this topic right now — what are you wrestling with?
Right now the thing I'm most focused on is figuring out where AI tooling is actually changing how my team works versus where it's just adding another step to the workflow. We've adopted a few tools — Copilot for the engineers, some AI-assisted writing for specs and PRDs — and the honest question I'm asking is whether the output quality is going up or whether we're just moving faster toward the same mediocre result. The other thing sitting in the back of my mind is around user research specifically — there are a handful of tools promising to synthesize interview data and surface themes, and I haven't fully trusted them yet. I want to validate whether what they're pulling out actually maps to what I'd pull out myself if I sat with the transcripts.
What's the most important thing you need to understand or solve here?
Right now the biggest thing for us is figuring out where AI is actually compressing cycle time versus where it's just adding another tool that someone has to babysit. We're a small team, so any friction that gets introduced into the workflow has a real cost. I want to understand which parts of the product development process — research synthesis, spec writing, prioritization — are actually getting faster in a durable way, not just in the first two weeks when people are excited about a new tool.
What does 'good' look like to you — and how far are you from that today?
For us, "good" means AI that actually integrates into the workflow without requiring the team to change how they work to accommodate it. Like, the tool should fit the process, not the other way around. In terms of where we are — I'd say we're maybe halfway there. We've got some solid wins around synthesis and drafting, but there's still a lot of manual handoff between what the AI produces and what actually lands in a doc or a Jira ticket in a usable form. That gap is where we lose time.
What would change your perspective on this entirely?
That's a fair question. I think if I saw consistent, repeatable evidence that AI-generated insights were catching things our user research was missing — not just summarizing what we already knew faster, but actually surfacing something we would have acted on differently — that would shift how much I trust it as a primary input versus a supporting tool. Right now it feels like it's mostly compressing time on work we'd do anyway, which is useful, but it's not changing the fundamental decisions we're making.
What question are you not being asked that you wish someone would ask?
That's a fair question. I think the thing people skip over is the cultural side — like, how do you get engineers and designers to actually trust AI-generated research synthesis enough to act on it? Everyone asks about which tools you're using or what's saving time, but the adoption and trust question inside the team is where a lot of the friction actually lives for us. Getting alignment on "this AI summary is good enough to inform a sprint decision" is a harder problem than picking the right tool.
"I want to understand which parts of the product development process — research synthesis, spec writing, prioritization — are actually getting faster in a durable way, not just in the first two weeks when people are excited about a new tool."
Alex is a pragmatic, analytically-oriented CTO in an active evaluation mode on AI tooling — neither enthusiastic nor dismissive. His central concern is distinguishing genuine productivity gains from added complexity and maintenance overhead. GitHub Copilot is the one tool he views as meaningfully embedded; elsewhere, adoption is ad-hoc and unsystematic. He is openly skeptical of vendor-supplied ROI claims and would be moved by peer-company internal data tied to metrics he actually manages (e.g., incident resolution time, onboarding speed). His most distinctive and underexplored concern is hidden integration cost — the engineering lift required to make AI tools work securely in an existing environment — which he feels is consistently overlooked in how vendors and analysts frame the conversation.
Tell me what's top of mind for you on this topic right now — what are you wrestling with?
Right now the thing I'm most focused on is figuring out where AI tooling actually fits into our engineering workflows versus where it's just adding another surface we have to secure and maintain. We've got developers using Copilot, we've got a couple teams experimenting with different things for documentation and code review, and I'm trying to get a clear picture of whether we're getting compounding value or just compounding the vendor sprawl problem. The governance piece is honestly the harder question — like, who owns the data that flows through these tools, what are our obligations, and are we comfortable with where it's going. That's what I keep coming back to.
What's the most important thing you need to understand or solve here?
Right now, the biggest question for me is where AI tooling is actually compressing cycle time versus where it's just adding another layer my team has to manage. We've got engineers using Copilot, product managers experimenting with summarization tools, and some ad-hoc stuff happening in between — and I don't have a clean picture of what's genuinely accelerating delivery versus what's becoming its own maintenance burden. That's the core thing I'm trying to get clearer on.
What does 'good' look like to you — and how far are you from that today?
For us, "good" looks like AI that's actually integrated into workflows rather than sitting as a separate tool people have to remember to open. The ideal state is where our engineers and product managers are getting relevant suggestions or automation in the context where they're already working — in the IDE, in Jira, in our internal docs — without having to context-switch to prompt something. How far are we? Honestly we're partway there on the engineering side. GitHub Copilot is pretty well adopted and that feels like the closest we've gotten to that embedded model. On the product and ops side, it's more scattered — people are using ChatGPT or Claude individually but it's not really systematic. That inconsistency is probably our biggest gap right now.
What would change your perspective on this entirely?
If we started seeing really consistent, auditable evidence that a specific AI tool meaningfully reduced engineering time on something I actually care about — not vanity metrics like "lines of code generated," but things like reduced time to root cause in incidents, or faster onboarding for new engineers — that would shift how I think about prioritization. Right now a lot of the claims are either anecdotal or come from the vendor, which I discount pretty heavily. Show me a comparable company's internal data, even rough numbers, and I'd take that seriously.
What question are you not being asked that you wish someone would ask?
That's a fair question. I'd probably want someone to ask about the hidden integration costs — not the licensing cost of an AI tool, but what it actually takes to wire it into your existing systems securely and maintain it over time. Everyone asks "what tools are you using" and "what's your ROI," but almost nobody asks "what did your team have to build to make that tool actually work in your environment." For us, that's often where the real effort lives, and it shapes whether we even adopt something in the first place.
"Everyone asks 'what tools are you using' and 'what's your ROI,' but almost nobody asks 'what did your team have to build to make that tool actually work in your environment.' For us, that's often where the real effort lives, and it shapes whether we even adopt something in the first place."
Marcus is a pragmatic, analytically-minded marketing leader who is actively evaluating — not advocating for or against — AI tooling within his team. He has rolled out several tools but sees uneven adoption and inconsistent productivity gains, and he is genuinely uncertain whether the review overhead offsets the time saved. He is approximately halfway to his vision of seamlessly embedded AI, with the primary barrier being variance in how team members use and get value from the tools. His perspective would shift with rigorous, cross-organizational throughput data rather than anecdotal enthusiasm. A notable and underexplored concern for him is organizational ownership: AI adoption accountability tends to fall through the cracks between functions, which he identifies as a root cause of inconsistency.
Tell me what's top of mind for you on this topic right now — what are you wrestling with?
Right now the biggest thing I'm wrestling with is figuring out where AI actually accelerates my team's output versus where it just adds a step in the workflow. We've rolled out a few tools — some for content generation, one for competitive intel — and the adoption has been uneven. Some people have genuinely changed how they work, others are kind of going through the motions. So I'm trying to get a clearer read on whether the tools are the issue or whether it's more about how we've implemented them and set expectations.
What's the most important thing you need to understand or solve here?
For us, the core question is whether the time our team spends prompting, reviewing, and correcting AI outputs is actually less than the time it would take to just do the work. We've adopted a handful of tools across content, research, and campaign ops, and the productivity gains aren't uniform — some workflows are genuinely faster, others have added a review layer that didn't exist before. So right now I'm trying to build a clearer picture of where the net time savings are real versus where we've just shifted the labor.
What does 'good' look like to you — and how far are you from that today?
For us, "good" looks like AI that's actually embedded in the workflow rather than something people have to go out of their way to use. Like, the output is usable on the first or second pass, not a starting point that still needs 80% of the work done on it. Where we are today — probably halfway there. The tools exist, people are using them, but there's still a lot of inconsistency in how different team members are getting value out of them. Some folks have figured out prompting well enough that it's genuinely saving them time; others are still fighting with it. That variance is what I'd most want to close.
What would change your perspective on this entirely?
That's a fair question. I think if I saw consistent, repeatable evidence that AI tooling was reducing cycle time on something like campaign iteration or content localization — not just anecdotally from one team, but across comparable organizations — I'd probably shift how aggressively we prioritize adoption. Right now a lot of what I hear is early-stage enthusiasm that hasn't been stress-tested across a full quarter. Show me the before-and-after on actual throughput, not just "we saved hours," and I'd take the investment case more seriously.
What question are you not being asked that you wish someone would ask?
That's a fair question. I'd probably want someone to ask more about the organizational side — like, who actually owns AI adoption within a product or marketing org? Because in my experience, it tends to fall between product, engineering, and whoever's most enthusiastic about it that quarter. The tooling conversation gets a lot of attention, but the accountability and governance piece doesn't, and that's where a lot of the inconsistency in actual usage comes from.
"The core question is whether the time our team spends prompting, reviewing, and correcting AI outputs is actually less than the time it would take to just do the work."
Keisha is a pragmatic, measured adopter of AI in customer success — neither skeptical nor enthusiastic, but results-oriented. Her primary concern is whether AI tooling reduces CSM burden in practice or simply relocates it. She has made genuine progress (centralized health scores, early churn signals) but sees too much manual interpretation still required. Her key unresolved question is where real workflow time savings are occurring in CS-specific contexts, not product or engineering. She would meaningfully upgrade her investment in AI if she saw documented evidence that AI-generated signals surfaced actionable, outcome-changing insights ahead of experienced CSM intuition — rather than confirming what CSMs already suspected. She also raised an underappreciated concern: that AI efficiency gains internally do not automatically translate to better customer experiences externally.
Tell me what's top of mind for you on this topic right now — what are you wrestling with?
Right now the biggest thing I'm wrestling with is figuring out which AI-generated insights in our health scoring are actually actionable versus which ones are just adding more things for my CSMs to look at. We've layered in some AI tooling over the last year and the team is using it, but I'm not always confident that what surfaces is moving the needle on retention. The other piece is consistency — I want my team preparing for QBRs and renewal conversations with a common foundation, and AI could theoretically help with that, but we haven't fully cracked how to standardize it without losing the context that individual CSMs have built with their accounts.
What's the most important thing you need to understand or solve here?
For us, the core question is whether AI is actually helping my team spend more time with customers or whether it's adding another layer of tools they have to manage. My CSMs are already stretched — they're handling 40, 50 accounts each — so if an AI tool requires significant upkeep or interpretation, it's not really saving time, it's just shifting where the time goes. What I need to understand is where the genuine time savings are showing up in workflows that look like mine, not just in product or engineering teams where the use cases are pretty different.
What does 'good' look like to you — and how far are you from that today?
Good, for me, looks like having a consistent, reliable view of account health that doesn't require me to manually piece together data from five different systems every week. I want my team spending the majority of their time on actual customer conversations and strategic work — not on building the deck or chasing down usage data before a QBR. Where we are today? Probably 60% of the way there. We've made real progress on centralizing health scores and surfacing early churn signals, but there's still too much manual interpretation happening. My CSMs are still spending time they shouldn't have to on prep work that I'd like to see automated or at least significantly reduced.
What would change your perspective on this entirely?
That's a fair question. I think if I saw a well-documented case where AI-generated health score recommendations actually prevented churn at scale — not just flagged risk that a CSM already knew about, but genuinely surfaced something actionable that changed an outcome — that would shift how seriously I take it. Right now most of what I see is AI confirming what experienced CSMs already feel. If the predictions got ahead of human intuition consistently, I'd pay a lot more attention to expanding our tooling in that direction.
What question are you not being asked that you wish someone would ask?
That's a fair question. I think the thing people don't ask enough is how AI tools are actually affecting the customer-facing work — not just the internal efficiency story. Everyone wants to know how product teams are using AI to move faster, but I'm sitting on the other side of that asking "are customers actually experiencing better outcomes, or are we just shipping features faster?" Those two things aren't the same, and from where I sit in CS, the distinction matters a lot.
"If an AI tool requires significant upkeep or interpretation, it's not really saving time, it's just shifting where the time goes."
Synthetic pre-research uses AI personas grounded in real buyer archetypes and (where available) Gather's interview corpus. It produces directional signal — hypotheses worth testing — not statistically valid measurements.
Quantitative figures are projected from interview analyses using Bayesian scaling with a conservative ±49% margin of error. Treat as estimates, not census data.
Reflect internal response consistency, not statistical power. A 90% confidence score means high AI coherence across interviews — not that 90% of real buyers would agree.
Use this to build your screener, align on hypotheses, and brief stakeholders. Then run real AI-moderated interviews with Gather to validate findings against actual respondents.
Your synthetic study identified the key signals. Now validate them with 150+ real respondents across 4 audience types — recruited, interviewed, and analyzed by Gather in 48–72 hours.
"How are product teams using AI internally — and where is it actually saving time vs. creating noise?"