How Figma Is Building Self-Serve Analytics with OpenAI

Figma's partnership with OpenAI's Athena pilot program enables self-serve analytics by building organizational context, letting non-technical employees query

Organizational Context as the Bottleneck in Self-Serve Analytics: Evidence from Figma's Athena Pilot

Abstract

This synthesis examines a practitioner account of self-serve analytics deployed at Figma through Athena, a pilot program from OpenAI oriented toward building organizational context for analytical question-answering. The central claim under examination is that the binding constraint on analytical self-service in large organizations is not natural-language query generation but the availability of accurate, current organizational context: knowledge of what a given campaign is, what metrics bear on it, and how entities relate. The account reports that context enrichment allowed non-technical personnel, including marketing analysts and email marketers, to interrogate campaign performance without awaiting bespoke dashboard or metric development, and it identifies proactive analytics as the anticipated next capability. The evidence is single-organization, self-reported, and pilot-stage, and is accordingly treated as a hypothesis-generating observation rather than a validated result. Implications for semantic-layer design and evaluation practice are discussed.

1. Introduction

Enterprise analytics has long exhibited a structural asymmetry: the population of personnel with analytical questions substantially exceeds the population able to answer them directly. The conventional remedy is intermediation, in which a data or analytics engineering function translates business questions into models, metrics, and dashboards. This intermediation imposes latency measured in weeks or quarters, and that latency is often fatal to the question's value, particularly for time-bounded activities such as marketing campaigns.

The term self-serve analytics denotes the removal of this intermediation, enabling a non-technical employee to obtain a trustworthy answer without a human translator in the loop. Large Language Models (LLMs) have made the surface form of this goal tractable, in that natural language can be mapped to query syntax with reasonable reliability. The account synthesized here advances a different locus of difficulty, suggesting that syntax was never the principal obstacle, and that the operative constraint is organizational context: the situated, frequently changing body of knowledge about which entities exist, what they mean, and which measures legitimately apply to them.

The central question addressed is whether context-building, treated as the primary engineering object rather than as a precondition assumed to be satisfied, makes analytical self-service reachable for non-technical users. Section 2 establishes the conceptual framing, Section 3 analyzes the reported deployment, Section 4 extracts technical considerations, and Sections 5 and 6 discuss implications and limits.

2. Background and Related Work

Two framings situate the account. The first concerns the dashboard backlog as an organizational pattern. Because dashboards and governed metrics are artifacts that must be specified, built, validated, and maintained, demand for them is effectively unbounded while supply is constrained by specialist headcount. The resulting queue means questions are answered in order of prioritization rather than in order of decay, a mismatch that is especially acute when the subject of inquiry, such as a newly launched campaign, has a short decision window. A question answered after the campaign has concluded has materially less value than the same question answered during the campaign.

The second framing concerns context as distinct from capability. Prior waves of "ask your data a question" tooling largely addressed the translation step, mapping a natural-language string to SQL or a BI query. Figma's account implies that translation was not the limiting factor: a correctly generated query against an impoverished or stale semantic layer still produces a wrong or meaningless answer. Athena is positioned as addressing the upstream problem of enriching the organizational knowledge base, so that terms such as "campaign," "conversion," and the relationships between them are resolved correctly before any query is constructed.

3. Core Analysis

3.1 Context Enrichment as the Operative Mechanism

The reported mechanism is that Athena "builds context within the organization" by, for example, understanding a new marketing campaign and enriching the surrounding context. This is distinguished from, but analogous to, retrieval-augmented or knowledge-grounding approaches: rather than retrieving documents at query time alone, the system appears to accumulate and maintain a persistent organizational model that downstream queries draw upon. The practical effect described is that a marketing analyst or email marketer can ask how a campaign is landing and how it is contributing to customer conversion, and receive an answer grounded in that enriched context.

The significance claimed is not merely speed but a removal of a dependency: value is realized "sooner than waiting for someone to build a dashboard or metric." This reframes the self-serve analytics problem as primarily a context-maintenance problem. If the organizational model is kept current as new entities (campaigns, products, cohorts) are introduced, the query-answering layer can generalize to novel questions about novel entities without bespoke engineering for each one.

3.2 Scope of Self-Service Across Roles

The account specifies that the beneficiaries are non-technical roles, specifically marketing analysts and email marketers, rather than data engineers or analysts already capable of writing queries. This is a load-bearing detail: it indicates the pilot's claimed value is in extending analytical reach to roles previously dependent on intermediaries, rather than in accelerating the work of already-technical users. The summary statement that "OpenAI has unlocked the ability to deliver self-serve analytics across Figma" is offered as a general organizational claim, though no breadth-of-adoption or usage-volume data accompanies it.

3.3 From Reactive to Proactive Analytics

The forward-looking component of the account shifts from query-answering to proactive analytics, described as a capability where Athena would surface insights before a question is asked. This is a qualitatively different mechanism from the context-enrichment-plus-query pattern in Section 3.1, since it requires some process for identifying which emergent patterns are worth surfacing unprompted, absent an explicit question to anchor relevance. The account treats this as an anticipated future direction rather than a deployed capability, and no mechanism for how proactive surfacing would be triggered or filtered is specified.

4. Technical Insights

Several implementation-relevant considerations can be drawn from the account, with the caveat that the source material does not specify architecture, evaluation metrics, or failure modes.

• Context as a maintained artifact, not a one-time ingestion. The description of enriching context "around a new marketing campaign" implies an ongoing update process keyed to new entities entering the organization, rather than a static knowledge base built once and queried indefinitely. Systems replicating this pattern require a mechanism for detecting and ingesting new entities as they arise.
• Separation of context-building from query execution. The two-stage structure, context enrichment followed by natural-language query answering, suggests that the hard engineering problem is decoupled from the LLM-facing query interface. This is consistent with semantic-layer approaches in which a governed knowledge representation sits between raw data and the language model, though the account does not disclose what that representation consists of.
• Non-technical user framing as a design constraint. Because the claimed beneficiaries are non-technical staff, the system's answers presumably need to be interpretable without query inspection, which raises unaddressed questions about how trust, provenance, and error-checking are communicated to users who cannot audit the underlying query.
• Proactive analytics as an unsolved extension. The move from reactive to proactive surfacing introduces a relevance-filtering problem (what to surface, to whom, and when) that is categorically harder to evaluate than reactive question-answering, since there is no user-issued query against which correctness can be checked.

A material limitation is that no quantitative evaluation accompanies any of these claims: no accuracy figures, no adoption metrics, no comparison against the prior dashboard-based workflow, and no description of failure cases are reported.

5. Discussion

The account's broader significance lies in reframing the recent progress in LLM-based analytics tooling. Much public discussion of natural-language-to-query systems has emphasized the query-generation step, since that is the step most legible as an LLM capability. This account instead locates the bottleneck upstream, in the maintenance of organizational context, which is a harder and less glamorous engineering problem because it requires continuous curation tied to how an organization actually operates, rather than a model capability that can be benchmarked in isolation.

This reframing is consistent with a broader pattern observed across enterprise LLM deployments: capability gains from frontier models tend to expose organizational data and knowledge-management deficits as the new limiting factor, rather than model competence per se. If this pattern holds generally, it implies that the return on self-serve analytics initiatives will track investment in context infrastructure more closely than investment in the query interface.

A notable gap is the absence of any evaluation methodology. The account offers testimonial statements, including the claim that work plannable "over the next 1 year" can now be done "in the next 2 months," with no supporting measurement of what was planned, how progress is tracked, or how the counterfactual twelve-month estimate was derived. Such statements are plausible as subjective practitioner impressions but do not constitute evidence of a generalizable productivity multiplier.

6. Conclusion

The Figma account offers a single-organization, pilot-stage data point suggesting that self-serve analytics is gated less by natural-language query translation than by the availability of maintained organizational context, and that addressing the latter can extend analytical access to non-technical roles such as marketing analysts. The anticipated next step, proactive analytics, represents a materially harder unsolved problem of relevance-filtering without an anchoring query.

The practical takeaway for organizations considering similar initiatives is to treat context maintenance, not query-interface sophistication, as the primary investment target, while recognizing that the present evidence base consists of qualitative testimony rather than measured outcomes, and that claims of order-of-magnitude acceleration warrant independent verification before being generalized beyond this single pilot.

Sources

• How Figma Is Building Self-Serve Analytics with OpenAI - Original Creator (YouTube)
• Analysis and summary by Sean Weldon using AI-assisted research tools

About the Author

Sean Weldon is an AI engineer and systems architect specializing in autonomous systems, agentic workflows, and applied machine learning. He builds production AI systems that automate complex business operations.

LinkedIn | Website | GitHub