⚠ 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 Senior PM who is actively experimenting with AI tools but remains genuinely unsettled about whether they are delivering substantive value. The dominant concern is not AI skepticism per se, but a methodological frustration: he lacks reliable ways to distinguish real quality improvement from faster mediocrity. He is critical of AI outputs that merely confirm existing beliefs rather than shifting decisions, and he flags workflow fragmentation (copy-paste between tools) as a practical barrier to ROI. A secondary, less-developed concern about junior PM skill atrophy rounds out his perspective. Overall tone is measured and inquisitive — neither enthusiastic nor dismissive.
Tell me what's top of mind for you on this topic right now — what are you wrestling with?
Right now the thing I keep coming back to is figuring out where AI is actually changing the work versus where it's just adding a step. Like, we've got people using Copilot for PRDs, using AI for synthesis after user research sessions — but I'm not always sure if the output quality is better or if we're just getting to a mediocre draft faster. That distinction matters a lot to me because if we're optimizing for speed but the thinking is shallower, that's a problem for a product team. So I'm trying to find ways to actually measure that, which is harder than it sounds.
What's the most important thing you need to understand or solve here?
For us, the core question is whether the AI tools we're adopting are actually changing how fast we can move, or whether they're just adding a layer of process that feels productive but isn't. We're a small team, so any tool that requires significant maintenance or prompt-wrangling overhead has a real cost. Right now I'm most focused on figuring out which parts of the PM workflow — synthesis, documentation, backlog grooming — genuinely benefit from AI assistance versus which ones just produce output that someone still has to fully rework anyway.
What does 'good' look like to you — and how far are you from that today?
For us, "good" looks like AI that actually fits into the workflow rather than requiring us to go to a separate tool and context-switch constantly. Specifically, I'd want synthesis happening closer to where we're already doing our work — like surfacing relevant user research insights when I'm drafting a PRD, not after I've already made the decision. Distance from that today? Probably a medium gap. We have some pieces — I'm using AI for research synthesis and draft generation — but the integration into our actual product development workflow is still pretty manual. I'm still doing a lot of copy-paste between tools, which kind of defeats the purpose of saving time.
What would change your perspective on this entirely?
That's a fair question. I think if I saw consistent, measurable evidence that AI-generated insights were actually changing prioritization decisions — not just confirming what the team already believed — that would shift how seriously I take some of the synthesis tools we've been skeptical about. Right now a lot of what I see is AI telling us things we could have figured out from a quick stakeholder conversation. If that changed, I'd pay more attention.
What question are you not being asked that you wish someone would ask?
That's a fair question. I think people focus a lot on where AI is saving time, but fewer people ask about what it's changing in terms of team dynamics — like, are junior PMs developing the same instincts they would have if they were doing more of the synthesis work themselves? That's something I think about but don't have a clean answer to yet.
"I'm not always sure if the output quality is better or if we're just getting to a mediocre draft faster. That distinction matters a lot to me because if we're optimizing for speed but the thinking is shallower, that's a problem for a product team."
Alex is a pragmatic, analytically-minded CTO who is actively using AI tooling (Copilot, OpenAI API) but wrestling with whether deployment is generating compounding value or just parallel experiments. His core concerns are: (1) integration — AI needs to fit existing pipelines, not create new surfaces requiring context-switching; (2) measurement — he lacks reliable instrumentation on time savings and is frustrated by anecdote-driven evaluation; (3) evidence standards — he discounts vendor benchmarks heavily and would shift investment priorities only based on credible third-party or peer-reviewed data from comparable environments; and (4) a slower-burn cultural concern about whether AI-assisted coding is degrading junior engineer development and debugging intuition. His tone throughout is measured and problem-focused — neither enthusiastic nor resistant. He is clearly engaged with the space but disciplined about what he considers valid signal.
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 tooling actually belongs in our engineering and product workflows versus where we're just adding it because there's pressure to show we're doing something with it. We've got developers using Copilot, we've got some internal tooling built on top of OpenAI's API, and the honest question is whether we're getting compounding value from that or just parallel experiments that don't talk to each other. The integration layer is what keeps me up at night — we're a pretty API-heavy shop and I want these tools to actually fit into our existing pipelines rather than exist as separate surfaces people have to context-switch into.
What's the most important thing you need to understand or solve here?
The biggest question for us right now is where AI is actually accelerating the team versus where it's just adding a layer of process that people have to manage. We've deployed a handful of tools — some internally built, some vendor — and the honest gap is that we don't have great instrumentation on actual time savings. I want to understand how other product orgs are measuring that, because right now we're largely going on anecdote and team sentiment.
What does 'good' look like to you — and how far are you from that today?
For us, "good" looks like AI that's embedded in the workflow without requiring a context switch — where an engineer or PM doesn't have to stop what they're doing and go talk to a separate tool. We're partway there with some of the coding assist stuff, but the integration layer is still messier than I'd like. The bigger gap is on the data side — I want AI that actually understands our internal context, our APIs, our data models, not just generic patterns. That's probably 12 to 18 months away if we're being realistic about the foundational work that still needs to happen.
What would change your perspective on this entirely?
That's a fair question. I think if I saw consistent, reproducible evidence that a specific AI tooling decision — not just AI in general — materially reduced defect rates or accelerated release cycles in an environment comparable to ours, that would shift how I prioritize investment. Right now a lot of what I see is anecdotal or comes from vendors citing their own benchmarks, which I discount heavily. Show me peer-reviewed data or a credible third-party audit from a company our size and complexity, and I'd take it much more seriously.
What question are you not being asked that you wish someone would ask?
That's a fair question. I think the one that doesn't come up enough is: what happens to your engineering culture when you lean heavily on AI-generated code? We spend a lot of time talking about velocity and output, but not much about whether junior engineers are actually learning, or whether the team is developing the intuition to debug and maintain what's being produced. That's a slower-moving concern, but it's real.
"The biggest question for us right now is where AI is actually accelerating the team versus where it's just adding a layer of process that people have to manage."
Marcus is in a pragmatic, diagnostic mode on AI adoption — neither enthusiastic nor dismissive. He has rolled out several tools and is seeing genuinely mixed results: some workflow acceleration, some friction added. His core focus is building rigor around measuring actual cycle-time compression rather than relying on subjective efficiency impressions. He estimates his team is roughly a third of the way to meaningful integration, with content drafting and research summarization as functioning use cases but deeper stack integrations still lagging. His most pointed concern — and the question he wishes someone would ask — is about accountability: how organizations decide which AI outputs are trustworthy enough to act on without human review. This suggests his underlying challenge is less about adoption enthusiasm and more about governance and quality thresholds.
Tell me what's top of mind for you on this topic right now — what are you wrestling with?
Right now the biggest thing is figuring out where AI is actually compressing work versus where it's just adding a step. We rolled out a few tools across the marketing team — some content generation, some analytics summarization — and the honest assessment is that adoption is uneven. Some people have genuinely built it into their workflow and they're faster; others are treating it as an extra review layer and it's slowing them down. So I'm trying to understand whether that's a training problem, a tool-fit problem, or just that certain use cases don't actually benefit as much as we assumed.
What's the most important thing you need to understand or solve here?
Right now the thing I'm most focused on is figuring out where AI is actually compressing cycle time on real work versus where it's adding a layer of process that we then have to manage. We've adopted a handful of tools over the last year and a half, and honestly the results are mixed — some things moved faster, some things just moved differently without being faster. So the core question for me is whether we can get more rigorous about measuring the actual time saved, not just the "this feels more efficient" impression people have after using a new tool.
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 consciously switch over to use. Like, the outputs show up where the work is happening — in our CRM, in our content tools, in campaign planning — without requiring a separate login or context switch. How far are we? Probably a third of the way there. We've got some solid use cases running, mainly around content drafts and research summarization, but the deeper integrations into our core stack are still pretty manual. There's a gap between what the tools promise and what actually fits into how the team operates day to day.
What would change your perspective on this entirely?
That's a fair question. I think if I saw a case where AI tooling meaningfully compressed the time between insight and action on something like campaign performance — not just surfacing data faster, but actually changing the decision cycle — I'd update my view pretty significantly. Right now most of what I see is acceleration of work that was already happening, not a genuine change in how we decide things. If the loop actually got tighter in a measurable way, that would shift how I think about the investment.
What question are you not being asked that you wish someone would ask?
That's a fair question. I think the one I'd actually want someone to dig into is: how are you deciding which AI outputs are good enough to act on without a human review step? Because right now we have tools producing first drafts, scoring leads, summarizing call transcripts — and the quality bar for "ship it" versus "someone needs to check this" is pretty informal at most places, including ours. It's less about whether AI saves time and more about where you've actually built accountability into the workflow.
"Right now most of what I see is acceleration of work that was already happening, not a genuine change in how we decide things."
Keisha is a pragmatic, thoughtful VP CS navigating real operational tension around AI tooling adoption. She is neither enthusiastic nor resistant — she is genuinely uncertain whether AI is reducing her small team's workload or redistributing it. Her primary concerns are: (1) whether AI health signals can be trusted over accumulated CSM relationship knowledge, (2) whether AI is surfacing net-new risk or just repackaging existing signals, and (3) a longer-horizon worry about AI-generated communications quietly eroding relationship quality in ways that won't appear in health scores until it's too late. She estimates her team is about 60% of the way to her definition of good, with meaningful gaps remaining in health score accuracy and manual reconciliation. Her tone throughout is measured, evidence-seeking, and grounded in team capacity realities rather than technology skepticism per se.
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 about our accounts I can actually trust enough to act on before a QBR. Like, we're pulling health scores together from product usage, support tickets, NPS — and some of our tooling now has AI summarizing account risk, but I'm not always confident the model has the right context about a relationship that my CSMs have been building for two years. So there's this tension between moving faster with AI recommendations and knowing when to override them based on institutional knowledge that just isn't captured in the data.
What's the most important thing you need to understand or solve here?
For me, the core question is whether AI is actually helping my team spend more time with customers or whether it's just adding another layer of tools they have to manage. We're a small CS team covering a lot of accounts, so capacity is always the constraint. Right now I'm genuinely uncertain whether the AI-assisted health scoring and summarization we've started using is reducing the cognitive load on my CSMs or just shifting where the work happens.
What does 'good' look like to you — and how far are you from that today?
For us, "good" looks like having a clear, reliable signal on account health before a customer tells us something is wrong — ideally 60 to 90 days of lead time before a renewal conversation. That means clean health scores, consistent engagement data, and CSMs who are spending their time on relationship work rather than hunting down usage stats. Where we are today? Probably 60% of the way there. The data infrastructure is better than it was two years ago, but we still have gaps where our health scores don't fully reflect what's actually happening with a customer's adoption. A CSM will tell me an account is fine and then the health score says something different, and reconciling those two things is still more manual than I'd like.
What would change your perspective on this entirely?
If I saw AI actually surface a risk I would have missed — not one I could have caught with a standard health score review — and that risk led to a meaningful save, I'd probably recalibrate pretty quickly. Right now most of what I see is AI confirming things my team already flagged through normal account reviews. The bar for me shifting my perspective is less about the technology and more about whether it's additive to my team's judgment or just repackaging what we already know.
What question are you not being asked that you wish someone would ask?
That's a fair question. I think the thing that doesn't come up enough is: what happens to the customer relationship when AI is generating the outreach? Like, my CSMs are using AI to draft QBR prep notes, renewal summaries, things like that — and the output is fine, but I'm starting to wonder if customers can tell. Not in a "they're offended" way, just whether the communication feels less personal over time and whether that erodes trust in ways that don't show up in health scores right away. Nobody's really asking about the downstream relationship quality question.
"Right now most of what I see is AI confirming things my team already flagged through normal account reviews. The bar for me shifting my perspective is less about the technology and more about whether it's additive to my team's judgment or just repackaging what we already know."
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?"