Building the AI-Native Analytics Function
What changes when analytical production is no longer the main bottleneck?
The organization built around the work
In the product analytics organizations I’ve worked in, the arrangement is familiar: a data scientist owns a product area. They become the analytical partner for its product managers, engineers, designers, and other collaborators. Managers coordinate across those areas, with additional layers as the organization grows.
The embedded data scientist holds a lot of context. They understand what the product is trying to accomplish, how people use it, how its data is generated, and which questions matter. They participate in planning, prioritize investigations, and challenge assumptions. Then they also do much of the work required to produce the evidence.
Consider an ordinary question: did a change to onboarding help new users get started? Someone needs to clarify what “getting started” means, find the relevant data, check how the change was rolled out, and choose an appropriate comparison. Then come the queries, data checks, analysis, charts, and explanation. A surprising result might expose a logging problem or send the investigation in a different direction. Follow-up questions generate another round of work.
That execution is not mindless. Working through the data is often how you discover that the original question was incomplete or the proposed method was wrong. But it takes substantial time, alongside the time needed to understand the business and work with people.
The embedded model brings those responsibilities together. It also ties analytical coverage to what each practitioner can personally carry out. Valuable questions can go unanswered even when the team’s data scientist is doing excellent work.
The organization was built around the need for context and judgment, but also around the cost of producing reliable analytical work in skilled human time.
A faster analyst is not a different organization
My work on DS Agent at Snap made me ask what changes when the person accountable for an analytical question no longer needs to perform most of its execution.
As we described in the Snap Engineering post, we built an analytical workspace around capable coding agents. The workspace supplies business and data context, reusable methods, and rules for handling uncertainty and showing evidence. The agent writes and runs code, inspects results, iterates, and produces findings for an analyst to review.
The analyst still sets the direction, supplies missing context, challenges the approach, and decides whether the evidence is sufficient. Agents can contribute to those activities, too. The distinction is that practitioners can delegate a substantial part of an investigation without giving up responsibility for its quality.
The organization around the analyst is a separate question. Giving an embedded data scientist more execution capacity does not automatically expand their domain, change how partners ask questions, or create time for additional relationships. They may still support the same decisions through the same meetings and request channels. Faster execution can make room for deeper investigations and previously neglected questions. Those are worthwhile gains, but they are not the whole opportunity.
AI-assisted analytics improves execution within an existing operating model. AI-native analytics also redesigns the operating model around that capability.
That means reconsidering how questions enter the system, which work needs direct human involvement, how findings earn trust, what knowledge carries forward, and where additional people are needed.
In the model I have in mind, practitioners remain close to the business. But the ability to investigate, monitor, and reuse analytical knowledge becomes a shared capability, rather than depending on each person assembling and executing every investigation separately.
An established team can make that transition, just as a startup can build a conventional function despite having agents available. The distinction is a design choice, not a company category. AI-native also does not mean fully autonomous: the operating model has to account for agent limitations as deliberately as their capabilities.
The bottleneck moves to turning understanding into actions
Suppose a team becomes much faster at investigating questions. It could simply move the queue from “waiting to be investigated” to “waiting to be understood.”
A practitioner who delegates execution may still need substantial time to assess assumptions, discuss results with a partner, or resolve a disagreement about what they mean. An organization can have more answers without being better equipped to use them.
Engineering, product management, and design can also be reorganized around agents. What makes analytics particularly interesting to me is that its output is often a claim about an uncertain world. A query can run successfully and answer the wrong question. A reproducible result can still fail to establish why something happened. A persuasive explanation may be one of several consistent with the evidence.
Making analytical answers easier to obtain therefore increases the importance of distinguishing what is known, what is plausible, and what remains unresolved.
Agents should help with this as well: prioritizing findings, assembling evidence, and connecting related investigations. The human role should not become reading everything the machines produce. The practitioner should focus on important unresolved questions, the quality of the evidence, and the work of helping partners act on it.
The constraint can shift from how much analysis we can produce to how much trustworthy understanding we can turn into action.
That could increase, rather than reduce, demand for analytics. Questions previously too costly to investigate may become worth asking. The opportunity is to expand what the company can understand without proportionately expanding the burden on its people.
Analytics becomes continuous and cumulative
I would want an analytics function that keeps investigating important questions while its practitioners focus on the decisions that need their attention and that does not forget what it learns when an investigation ends.
Agents could maintain coverage of established questions: revisiting experiments as evidence accumulates, investigating meaningful changes in customer behavior, and checking whether earlier conclusions still hold. The practitioner would help set that agenda, rather than personally initiate every investigation.
Imagine a software company where activation declines among new API users. A workflow checks the data, and an agent locates the movement, retrieves related investigations, and prepares possible explanations. The first explanation, weaker sign-ups from a new acquisition channel, fits the headline number. A check against the metric’s definition, added to the workflow after an earlier mistake, points elsewhere: a recent integration may have changed the starting point of the activation funnel. The practitioner and product lead can start by testing whether the experience has worsened or the measurement has changed, rather than starting with an unexplained number.
The organizational payoff is that useful investigation has already happened before someone asks for it. Partners can get routine answers through predefined workflows, while the practitioner concentrates on unresolved questions and consequential decisions. The same system could surface gaps in what the team is measuring or assumptions it has not revisited.
Just as important, that work should improve what comes next.
A company can repeatedly pay to rediscover its own knowledge. People change teams, earlier work becomes hard to find, and the reasoning behind a conclusion gets separated from the chart that survives.
I would make capturing and retrieving that knowledge part of doing the work. In the activation example, the finding should travel with its evidence and caveats. A correction to the metric or investigation method should improve the next run. If the team takes action, the system should help track the outcome. A future practitioner should inherit that context, not just a folder of reports.
This requires trusted definitions, review matched to the consequences, and retained knowledge that respects privacy and retention limits. An old finding needs its corrections and caveats; being easy to retrieve does not make it true.
That changes what a practitioner can take responsibility for. They can remain accountable for a broad area without personally carrying every investigation from beginning to end.
The staff-level mindset becomes an operating model
A manager at Facebook once described progression between senior individual-contributor levels to me partly in terms of scaling impact through automation. The idea was not simply to produce more work personally, but to make your expertise useful beyond the work you could perform yourself.
That is the mindset I would build this function around.
A week in this role would still involve substantial business partnership. The practitioner would discuss upcoming decisions with Product, Engineering, and other teams, clarify what evidence could change those decisions, and work with agents to turn ambiguous problems into investigations. They would examine consequential findings, connect observations across areas, and help partners interpret uncertainty.
They would also act on gaps the investigations reveal. Missing instrumentation might require work with Engineering. A question the available data cannot resolve might call for an experiment. A recurring misunderstanding might require a better definition or a change in how partners use the analytical system.
Some problems would still require getting directly into the data or code. Delegation is not a reason to become detached from how evidence is produced. The practitioner needs enough technical and methodological depth to recognize a failure, investigate it, or bring in additional expertise.
Time to improve the system would be part of the job: evaluating new capabilities, resolving missing context, addressing recurring failures, and turning useful investigations into repeatable workflows. This does not mean building every tool ourselves. It means owning how the pieces support the work.
Good analytics practitioners already exercise judgment and influence decisions. The change is the balance of their time and how broadly their expertise can be applied. Product and other partners still own their decisions; the analytical owner is responsible for the quality and relevance of the evidence informing them.
AI does not invent the senior IC impact to scale expertise through systems. It expands the work to which that impact can be applied.
Add people for the remaining bottleneck
I would look at where work is waiting and why, rather than treating more demand as an automatic reason either to hire or to insist that agents can handle it. Repeated requests for an established metric might call for better self-service. Important decisions waiting for someone who understands the domain might call for another analytical owner. Persistent data problems might make an analytics engineer more valuable than another generalist.
At our hypothetical software company, consumer and developer products might eventually need separate analytical owners. The customers, decisions, and partner relationships could require more attention than one person can provide. Those owners would still share methods, knowledge, and controls rather than each rebuilding an analytical system. That shared layer needs an explicit owner, too. In a small function, it can be part of the analytical owners’ jobs; a larger one may need people whose main responsibility is the capability itself.
The team could organize around broad, coherent decision domains rather than automatically assigning a person to every product slice. Whether that produces a smaller or flatter organization depends on the work. What changes is the reason for adding people.
For an established team, the transition may be harder than the end state. A product lead who has had a dedicated data scientist will reasonably ask what they are losing, and a promised workflow is not an answer. Routine requests should move to supported routes only as those routes prove reliable, with a clear path to a person when the system cannot resolve something. The embedded practitioners hold the domain knowledge the shared capability needs, and they are often the natural candidates to own the broader domains.
This requires authority to prioritize. If every partner can independently commit the function to urgent work, faster execution will not resolve the conflicts. Leadership has to back the priorities, and Analytics and Engineering need a clear agreement about who owns the data systems and their operation.
Continuity and independent review matter, too. Can someone take a vacation without important work stopping? Is another qualified person available to challenge a consequential recommendation? Documentation supports those responsibilities; it does not supply the missing human capacity.
Hire for the work and accountability the current system cannot reliably and sustainably cover.
That includes developing practitioners. A senior-only model would avoid the question of how people acquire the expertise it depends on, and some of the execution we delegate is work through which practitioners learn to recognize mistakes and understand data. Less repetitive production could make room for more deliberate apprenticeship, in which developing data scientists take on wider responsibility as their understanding grows rather than becoming the sole safety check on unfamiliar automated work. That only happens if experienced practitioners have time to teach. Developing talent is part of building the function, not a cost the system should try to eliminate.
The same applies to sustainable workload. If the model works only because its owner reviews reports every evening and maintains infrastructure on weekends, those hours are part of its operating cost. They cannot be omitted when we claim that the function scales.
The right response may be more people, better systems, or fewer commitments. The objective is useful analytical coverage that the organization can sustain, not the smallest possible team.
The opportunity — and the experiment still to run
What excites me about this direction is the possibility of a function that covers more of the business, retains more of what it learns, and spends less effort repeatedly reconstructing the same answers.
For a company establishing its first analytics capability, I would not start by building a platform. I would hire an experienced practitioner who can partner with leadership, do the analysis, and shape the workspace around it, rather than a junior expected to supervise agents alone or an infrastructure specialist with no decisions to support. A few things need to be true before agents can help much: access to the data that matters, agreed definitions for the handful of metrics leadership actually uses, someone with authority to set analytical priorities, and clarity about who maintains the underlying data. The first months should answer real questions for a small set of decisions while building those definitions and methods, so the system grows out of useful work rather than ahead of it.
An established team could test the same principles within a bounded domain. In either case, I would ask whether the system provides better support: useful evidence sooner, attention to neglected questions, fewer repeated mistakes, and follow-through on recommendations. Review, corrections, maintenance, and coordination all belong in that assessment.
The same test should be allowed to narrow the proposal. If reviewing and correcting agent work absorbs most of the execution saved, if the data cannot support reliable investigation without constant repair, if broad domains leave owners too thin to understand the business, or if more analysis does not change decisions, the design needs to change there. A failed pilot is evidence, not proof that a team was insufficiently AI-native.
My experience with agentic analysis is the starting point for this proposal, not proof of its full organizational outcome. But I think it is enough to question whether a familiar staffing model should remain our default.
The next analytics organization should be designed around the decisions it needs to support rather than the work its people used to have to do by hand.