From compile time to run time: the new architecture of customer insights synthesis
Synthesis is moving from ‘compile time’ to ‘run time’.
In software development, compiled code is translated into an executable format upfront. This requires a heavy lift initially, but allows the software to run almost instantly. Code changes require the program to be recompiled and redistributed. In contrast, interpreted code skips this upfront compilation step and is translated on the fly as the program runs.
For the last two decades, user research has operated as a compile time discipline. When a team wants to understand a problem, a researcher kicks off a project. They conduct user interviews, gather feedback, and manually synthesize qualitative data into insights—highlighting transcripts, assigning tags or codes, building affinity maps, and producing a static report or slide deck for their stakeholders in product and design.
Because synthesis happens at the time of the study rather than at the time of the query, these reports are produced on the researcher’s timeline, not the stakeholder’s timeline. A product designer might read a report when it’s published, but three months later, when they are deep in feature design and actually need that customer context, the report is stale or doesn’t match the decision they’re making. When researchers struggle to have cross-functional impact, I believe this is one of the reasons why.
AI enables ‘run time’ insights. When a designer, engineer, or product manager needs to make a decision, they can query a qualitative data warehouse directly. Models process the data on demand, synthesizing at consumption. Answers are more relevant, generated in response to a specific query and grounded in source material.
Another way to think about this is how energy expenditure is shifting. It’s moving from human labor (calories burned doing manual synthesis) during a research project to compute (inference and tokens) expended formulating an answer for a query. CX tools have been pitching a version of this for years: ingest support tickets, surveys, and reviews into a central system, apply NLP, and let stakeholders query it.
However, CX data is mostly solicited and transactional like NPS and verbatims and support ticket categories. High volume, but shallow. User research data is lower volume, deeper, and observational. Interview transcripts, usability tests. A data warehouse that combines both is genuinely new; a warehouse with just one type of data is not.
In any case, I do think that CX, User Research, and Market Research are all converging, and researchers who don’t engage will likely cede ground. The defensible position for user researchers is not to insist that research is a categorically separate data set, but to claim the methodological and generative layer on top of a unified data platform.
This is also why research-only tools (platforms that organize research data in isolation from the rest of the customer-signal landscape) are not the long-term answer. Keeping research data siloed in a tool used only by researchers and a small set of stakeholders replicates the limitations of the compile time model at the tooling layer.
A run time architecture only works if the data set is unified: interview transcripts alongside support tickets, sales calls, churn surveys, and product feedback, governed by a shared set of methodological principles. A repository that exists in isolation from the rest of customer signal may be useful for archiving past projects, but it cannot serve as the live, queryable foundation that the rest of the organization needs to move work forward, fast, while staying grounded in real customer and user insights.
Rather than tagging transcripts, organizing projects, and compiling research reports, researchers should start designing data ingestion pipelines, configuring guardrails, and embedding methodology directly into system prompts. By maintaining team-wide context for AI to leverage (like persona definitions, evaluative heuristics, product strategy), researchers ensure that run time queries executed by stakeholders are grounded in sound principles, and that peers get rigorous answers rather than just fast ones.
Dovetail is designed to let teams embed their methodology directly into the AI layer—codifying persona definitions, evaluative heuristics, and research principles so that every run time query is governed by the team’s standards, not just raw pattern matching. That customization is what addresses the legitimate concern about accuracy: the researcher’s expertise doesn’t disappear, it moves upstream into the system itself.
Additionally, in a run time world, maintaining a rigid, static tag or code taxonomy has diminishing returns. Sentence embeddings and Retrieval Augmented Generation (RAG) move us from static, browsable data structures to dynamic semantic ontologies. Manually maintaining folders, tags, and project tracking sheets is increasingly impractical at scale. Some metadata is still useful (e.g. enriching transcripts with account information from tools like Salesforce or Snowflake to help the AI weight and prioritize themes), and gives stakeholders important context, but the bulk of taxonomic work no longer pays off.
Once raw qualitative data from across an organization is opened up, encompassing everything from support tickets to interview transcripts and survey responses, it is more practical to treat storage, enrichment, and on-demand retrieval as an unstructured data lake. ResearchOps transitions from managing a static, siloed research repository with minimal peer collaboration, to working hand-in-hand with CX, Market Research, and other teams to govern an automated customer intelligence platform engine with a focus on compliance at scale: PII removal, data retention policies, and security guardrails.
Researchers gain the bandwidth to step away from maintenance, administrative, and evaluative to focus on deep, foundational, generative research. They can look at the macro-level patterns the data lake uncovers across quarters, driving long-term product vision and corporate strategy rather than chasing sprint cycles.
Finally, run time architecture does not replace dedicated, specific research. While AI can mine through data that reflects existing user behavior, it cannot observe the unprompted human nuances of ethnography or run a usability test on a feature that doesn’t exist.
—
Great products are not built by teams who guess. But they are also not built by teams who wait three weeks for research before making a product decision. Run time synthesis lets product teams ground every micro-decision in real user evidence at the moment they are making it by drawing on insights from a variety of sources and teams in a unified data platform. User research can then take on a more strategic role in the organization.