A metric moves unexpectedly. Conversion falls in one market. Actuals deviate from the forecast. Leadership asks why.
These questions rarely arrive on schedule, but they often demand a fast answer. Without a clear owner, they can pull multiple teams off their planned work at once. Product starts investigating. Operations pulls its own numbers. Finance has a theory. Data Science gets asked for a quick analysis. Before anyone has established whether there is actually a problem, several teams may already be answering the same question in different ways.
This is where BizOps became one of DoorDash’s secret weapons.
We built the function a little like an ER doctor for the business. The doctor first diagnoses what is happening and how serious it is. Most cases can be treated there; only a smaller set requires a specialist.
BizOps plays a similar role. The team investigates what changed, determines whether it matters, develops the root cause, and recommends what the business should do next. And in most cases, they can carry the problem through to resolution themselves.
Most of the questions BizOps handles eventually reduce to three things:
What is going on?
Why is it happening?
What should we do about it?
The leverage comes from getting through the first two quickly and credibly enough that the organization can spend its energy on the third.
The benefit isn't just getting an answer quickly. By resolving most unexpected questions itself, BizOps keeps the business moving without turning every new question into a cross-functional project.
From observation to action
Imagine conversion suddenly falls in one market.
There are many possible explanations. Maybe a product release introduced friction. Maybe supply deteriorated. Maybe the mix of customers changed. Maybe a competitor launched a promotion. Maybe there is a measurement issue. Or maybe the apparent decline is simply normal variation.
A good BizOps team should move quickly from symptom to diagnosis.
Perhaps the decline is concentrated in a handful of markets where delivery times have increased. BizOps traces the movement to a temporary supply constraint, works with Operations on the right response, and resolves the question without turning it into a larger analytical project. Or perhaps the decline begins immediately after a product change and is isolated to new customers. Now the right outcome may be to bring in Product and Data Science for deeper investigation into a recent product launch. Or perhaps the analysis shows that the apparent decline is within normal variation and no intervention is warranted.
In all cases, BizOps has quickly established what is happening, why, and what should happen next.
Those examples look different, but the underlying decision path is consistent: Is the movement real and material? Do we understand it well enough to act? And is BizOps the right owner for what comes next?
The point is not to route every question. Most should end with BizOps either closing the loop or recommending an action and helping drive it to resolution. Only the smaller set that genuinely requires deeper expertise should move elsewhere.
Without a shared diagnosis, organizations can spend surprising amounts of time just establishing what happened. Product looks at one dashboard. Operations pulls another cut of the data. Finance comes with a different metric. People debate whose number is right, whether the movement is real, and which explanation is most credible.
The organization burns energy on what is going on and may never get very far into why, much less what we should do about it.
BizOps compresses that cycle.
They do the analysis, reconcile competing explanations, align stakeholders around a shared (and accurate) view of reality, and help the organization move toward action.
That is why I think of BizOps as an investment in data-driven storytelling. Not storytelling as presentation. Storytelling as creating enough shared understanding that people can stop debating the facts and start making decisions.
The capability existed before the title
At DoorDash, this did not emerge from a clean organization-design exercise.
In the early days, I effectively played much of this role myself. I was a GM with a finance background, and much of the job was understanding how the business was performing, spotting what looked wrong, digging into the numbers, and figuring out what to do about it.
One of the early problems our CEO, Tony Xu, wanted to solve was understanding how our GMs were performing and holding them accountable. That led us to define the metrics that mattered, build ways to understand business performance, and help operators make sense of what the numbers were telling us.
The work was broad because the problems were broad.
As DoorDash grew, the data organization became more sophisticated. Data Science moved deeper into experimentation, causal inference, forecasting, and prediction. At the same time, the business kept generating high-frequency operating questions that didn’t fit neatly onto a planned Data Science roadmap.
Performance would move unexpectedly. An executive would have an urgent question. A new trend might cut across Product, Operations, Marketing, and Finance before anyone knew which team should own it.
The organizational names changed over time. The underlying need did not.
Someone still needed to understand how the business was performing, identify where we were off plan, explain unexpected movement, and turn that explanation into a recommendation while there was still time to act.
Whether that capability is called BizOps and sits in Analytics or lives somewhere else matters much less to me than whether someone clearly owns it.
BizOps and Data Science operate on different clocks
BizOps and Data Science can look similar from the outside. Both work with data, investigate ambiguous business problems, exercise analytical judgment, and should ultimately help the company make better decisions.
Their centers of gravity are different.
Data Science more often sits closer to evidence and measurement. Can we establish causality? How should we design the experiment? What can we predict? Can we build a durable model or decision system?
BizOps sits closer to company performance and execution. What moved? Why? Does it matter? What should we do now? Who needs to act?
The difference also shows up in the clock each team is operating on.
A Data Scientist may spend a few weeks designing, launching, and analyzing an experiment to establish whether a relationship is causal. BizOps may need to explain by noon why a market moved that morning and whether leadership should change the plan.
Both answers need enough rigor for the decision. They are simply operating on different timelines.
That division of labor creates leverage. Most unexpected business questions do not need to become Data Science projects. A strong BizOps team can resolve them quickly, while Data Scientists stay focused on planned work that requires deeper measurement, experimentation, causal inference, forecasting, or modeling.
When an investigation does reveal a question that genuinely requires deeper expertise, the handoff should be clear. Healthy overlap between teams is useful; duplicated ownership is not.
Great BizOps creates clarity, then builds leverage
Because the role is analytical, it is easy to focus heavily on technical skills when hiring for BizOps. Those skills matter. But they are not enough.
The strongest BizOps people I have worked with are analytically sharp, commercially curious, strong communicators, and unusually comfortable operating without a stable roadmap. The business itself creates much of their work. A competitor changes something. A market suddenly underperforms. A forecast misses. Leadership changes the plan. A metric moves for a reason nobody expected.
The roadmap changes because the business changed.
People who thrive in BizOps can walk into that ambiguity, determine what matters, create structure around the problem, and develop a point of view without waiting for someone else to define every step.
They do not simply send the chart. They explain what the chart means, what matters, and what they think the business should do next.
But a strong BizOps team also should not answer the same question from scratch forever.
Part of the job is recognizing which questions recur and building the tools, data, and operating mechanisms that make them easier to answer the next time.
Take the question: Why did conversion fall in this market?
The first time, BizOps may investigate manually, cutting the data by geography, customer segment, supply conditions, acquisition channel, product surface, or other relevant dimensions.
If the question keeps recurring, the team should codify what it learned: standardize the metrics, automate the common diagnostic cuts, create alerts for meaningful deviations, and establish a playbook for what to investigate next.
The next time conversion moves, the team starts several steps ahead.
That is how the function becomes more valuable over time. The team is not just answering questions faster. It is improving the company’s ability to understand itself.
How to know whether you need the capability
I would not start with company size or fundraising stage. Instead, look at what happens when the business surprises you. At the level of an individual question, I find two dimensions especially useful: how important or urgent the question is, and whether it already has a clear owner.
BizOps adds the most value when the question matters but ownership is unclear. If an important problem already has a clear owner, that team should generally lead. And lack of ownership alone does not make a low-priority question a BizOps problem.
That helps define when BizOps should step in on a particular question. To determine whether your organization needs the capability more broadly, I would ask four questions:
Who owns the operating picture of the business? Someone should know what is moving, where the company is off plan, and which changes deserve attention.
Who owns the initial diagnosis when something unexpected happens? Important questions need a place to land before several teams start investigating independently.
Who turns the analysis into a recommendation? Identifying what happened is not enough. Someone should be responsible for helping the organization decide what to do about it.
What happens when the same questions keep recurring? Someone should be turning repeated investigations into better metrics, diagnostics, monitoring, and operating mechanisms so the company gets faster over time.
If the honest answer is “whoever happens to be available,” you probably already have the need. You just haven't assigned ownership.
Early in a company’s life, that does not necessarily require a formal BizOps team. A founder, Finance leader, operator, GM, or Analytics leader may be able to perform the function.
Eventually, that stops scaling.
There are too many markets. Too many products. Too many metrics. Too many decisions.
At that point, nobody can reliably hold the operating picture alone anymore, and the capability needs deliberate ownership.
The secret weapon
The payoff from a strong BizOps function is not usually a dramatic analytical artifact.
It is that the organization works better.
The company notices that performance is drifting before the end of the quarter. It feels like you can finally see around corners. Leaders spend less time debating whose numbers are right. Three teams do not independently investigate the same movement. Data Science does not get pulled off its roadmap for questions that can be resolved elsewhere. Recurring questions become easier to answer. And the business spends more time deciding what to do than arguing about what happened.
The best BizOps teams solve a large share of the questions that come through the door, align the organization around what is actually happening, and build the tools that make the next question easier to answer. When a problem genuinely requires deeper expertise, they know when to bring in the right team.
That is why I think of BizOps as a secret weapon: it helps the organization get from “what is happening?” to “what are we going to do about it?” faster.
Acknowledgments: The ideas and writing are mine, but current and former teammates shaped them by challenging my thinking and helping evolve how we built and ran the Analytics team. Special thanks to Matt Heitz and Ben Dearborn, the global BizOps leaders who have helped me build this function over the last decade. Also, to my Chief of Staff, Anita Chan, for brainstorming, editing, and AI wizardry on the images, and to ChatGPT and Claude for serving as editorial critics.