Supporting External Data in Analytics
Sec. Research • Survey • Strategic Concept Testing • UX Research
Overview
A quick disclaimer: Please note that ServiceNow research is held to strict confidentiality standards, so this page focuses on approach and impact, not specific findings, data, or the product itself. A lot of the materials that, in other projects I was able to share, even if heavily blurred, I CANNOT do the same here. I'm happy to speak to more detail in person.
ServiceNow customers were already exporting large volumes of platform data (I'm not breaking any NDAs here, this is a publicly known fact). Sometimes this is done to combine it with data from other tools. So, the open strategic question was: should ServiceNow instead support bringing external data in?
The answer touches product strategy, licensing, platform performance, and how customers think about having "a single source of truth". In other words, not a decision to make on instinct.
This research helped shape the direction of what's now a one of the flagship capabilities within ServiceNow's data analytics suite, and (even years after) continues to be referenced in strategy conversations at the VP and executive level.
Team
• 1 Staff UX Researcher
• 1 VP Product Manager
• Multiple cross-team Product Managers
My Contributions
• Lead User Research, across all stages;
• See outcomes for additional contributions
Timeline
• Q2 2024
The Process
As always, I followed a 6-stage process: Kickoff, Planning, Preparing, Running, Analysing, and Sharing. In the next sections, I'll provide a brief summary covering the different stages.
Kickoff
During the kickoff stage , we identified the following:
• Stakeholders - who must be involved and/or notified?
• Responsibilities (related to the above) - who does what?
• What do we want to know? - e.g. Are we gathering foundational knowledge? or evaluating existing features?
• Why does that matter?
• What will we do with the information?
• Deadlines - how much time do we have?
• Target audience - who do we want to gather information from?
• Hypothesis / Assumptions - what do we think we know?
Planning
For this particular project, the initial ask from stakeholders was rather loose (as it often is) closer to a "do customers like this idea?" That's... not answerable as-is: it doesn't say against what alternative, and it doesn't separate "liking a concept" from "actually adopting it."
I reframed the single question into a structured set of research goals, which I'll summarize as:
Why do customers export data today? - If the real reasons don't match what this concept could solve, it misses the point entirely;
How do customers perceive the concept? - Not just positive/negative. Which segments are receptive, how do they characterize the concept; and how well it closes existing gaps in their analytics process?
What do customers expect from it? - e.g., What data types they'd want to bring in; what concerns they raise; among others ...
Based on the information gathered during the Kickoff phase, I proceeded to create a Research Plan to address our needs. This plan includes:
• Research Questions
• Methodology (including recruitment strategies)
• Timeline
• Potential Future Research
Once approved by all relevant stakeholders, we moved to the next stages.
Methodology
Secondary research first. Before collecting anything new, I reviewed analyst reports (e.g., Gartner, Forrester), platform contract and usage data, and prior internal studies. This wasn't a formality, it meant primary research time went only toward genuinely open questions, not toward re-confirming things the industry or even the company already knew. It also gave the concept survey a stronger foundation: questions could be sharper because they built on existing evidence instead of starting blind.
Concept testing survey, next. Given the goal was to size an opportunity and assess adoption risk (not just explore a concept qualitatively) the research needed signal across enough customers and roles to speak to patterns, not just individual reactions. A survey let the team see how perception and concerns can vary by role/category/segment and use cases. This matters, since stakeholders need directional confidence for an investment decision.
Throughout, stakeholders weren't left waiting for a final readout. I shared emerging signals as they came in — what we were seeing and what it likely meant — so the team could start reacting before the study formally closed.
Preparing
Secondary research kicked off with ResearchOps, who helped source third-party analyst reports (Gartner, Forrester, Tegus - they're the ones with initial access) alongside my existing search for internal research available on the topic. In parallel, I translated each research goal into its own block of survey questions; including a screener to route respondents by roles/segments (internally defined based on the results our previous research), followed by questions on: current export behavior, first reactions to the concept, and expected concerns. Question design leaned on the secondary research, so respondents were being asked about genuinely untested assumptions, not re-litigating what analyst reports already confirmed.
Running
Secondary sources were reviewed qualitatively and tagged by whether they supported, challenged, or raised open questions about the opportunity. This turned a set of external and internal documents into one structured view of the problem space, rather than a pile of disconnected reports. This exercise allowed us also to refine our hypothesis and survey questions.
The survey fielded to ServiceNow Platform Analytics users, through internal and external recruitment initiatives, reaching <an unexpectedly high number that I cannot share of> qualified participants, across a mix of technical, business, and leadership roles. This gave enough breadth to compare how perception and concerns differed by role, not just in aggregate.
Analysing
Secondary research was synthesized into a "supports it / challenges it / open question" view that directly shaped which survey questions mattered most going in. Once survey data came in, I applied a series of statistical analysis tests onto the results - ranging from standard calculations around the most common options selected, to more complex correlation, statistical significance, and factor analysis tests, comparing different variables, such as the level of agreement with specific sentences and the respondents business type/vertical, among others.
As our survey had some open-ended questions, I had also a considerable amount of qualitative data available. By using a lite-thematic analysis of those responses, I was able to identify some of the most common patterns and, given the benefit of the sample size, was then able to apply similar statistical tests to them, to evaluate their frequency and compare them with other variables.
Ultimately, I organized survey results in a comparable way to our secondary research. Around each research goal's implication for the product team, not just as raw response counts, so findings from both phases read as one connected narrative, not two separate studies.
Sharing
Results were presented to stakeholders and the product team through a formal research readout, plus a written synthesis report that emphasized the implications for the feature design (not just what customers said, but what it meant for the product strategy). Raw, anonymized survey responses were made available alongside the report for teams that wanted to dig deeper. The goal was making it easy for the team to act: less "here's what we found," more "here's what you should do about it."
It is critical to mention that, throughout the entire process, stakeholders were consistently and progressively informed on the status of the project, and incoming signals. Debrief meetings, communications, alongside detailed milestone summaries helped keeping stakeholders informed on the direction of the results. While formal research readouts are important - they should not always be the place for "surprising stakeholders".
Outcomes & Reflections
From an operational perspective, I:
Identified why customers export data: and whether my stakeholders' concept would meaningfully address it;
Surfaced key adoption concerns early, before they became expensive to fix post-launch;
Gave the product team a customer-validated case for investment, not just an internal hypothesis;
However, and perhaps more importantly, this research helped build the case for what's now one of the flagship capabilities in ServiceNow's data analytics suite. As mentioned earlier, even years after the study, findings continue to be referenced in strategy discussions at the VP and executive level.
As a quick reflection, I can safely say that this was one of the most impactful research projects. More than validating and informing my stakeholders' strategy it fundamentally supported the creation of a new business unit (and of course new product(s)), still in development - which naturally fostered new research and, ultimately, new sought-after product experience(s). Moreover, it is also a key example of how a vague request in the lines of "do customers want this", can be turned into actionable and highly impactful results.
© Tiago Gonçalves, 2026