The original spark for Analytics at DoorDash came from a simple question: “How do we know if a market launch is going well?”

At first, I thought this was a measurement problem.

We needed better metrics, better dashboards, and a consistent way to compare performance across markets.

Those things mattered. But they weren’t the hardest part.

The real challenge wasn’t measurement. It was decision-making.

We needed a shared definition of good performance. We needed to understand which outcomes mattered, which inputs teams could control, but most importantly, we needed to identify what leaders should do when performance moved off plan.

The question wasn’t simply “What should we measure?”

It became: “What decision are we trying to make, and how can data help us make it better?”

That question eventually became BizOps. Later, it evolved into Analytics.

What is Analytics?

People often ask me what an Analytics team does. My answer has stayed remarkably consistent: Analytics exists to help the business make better decisions and improve measurable outcomes.

Most Analytics leaders would probably agree with that statement. The challenge isn’t defining the purpose of Analytics. It’s building a team—and an organization—that consistently operates that way.

A useful Analytics team answers questions, builds dashboards, analyzes experiments, and makes information easier to access.

A great Analytics team goes further. They help define the problem, bring a point of view on the decision, and stay involved long enough to learn whether the decision worked.

That’s what I mean by owning the outcome.

It doesn’t mean Analytics owns the business result on their own. It means Analytics shares responsibility for the quality of the decision by ensuring the team:

• Asked the right question.

• Used the right evidence.

• Understood the relevant trade-offs.

• Made a clear decision.

• Learned from what happened next.

Four questions behind every Analytics request

I've found that nearly every Analytics request becomes better after answering four questions.

1. What decision are we trying to make?

Dashboards, analyses, and forecasts aren’t decisions. They’re inputs into one.

Before starting the work, identify what someone will do differently as a result of the answer.

2. What outcome are we trying to change?

What does success look like for the business or the customer?

This prevents teams from optimizing a convenient metric without understanding whether it drives the result that actually matters.

3. Which levers can the team control?

Teams cannot directly control every outcome.

They can usually control inputs such as pricing, targeting, product experience, selection, incentives, staffing, execution quality, or the pace of investment.

Good Analytics connects those controllable inputs to the outcomes the business cares about.

4. What action could follow from the answer?

What would we do if the metric is above a certain threshold? Below? Inconclusive?

If every answer results in the same action, the analysis may not be necessary.

These four questions may sound basic. But answering them changes the nature of the work.

From the requested output to the desired outcome

Imagine a GM asks for a market-launch dashboard.

A request-driven approach starts by asking, “Which metrics should go on the dashboard?“

An outcome-driven approach starts somewhere else: “What decision does the GM need to make?”

Perhaps the real decision is whether to expand the launch, change the launch strategy, or pull back the current investment.

That leads to a different set of questions:

• What outcomes define a healthy launch?

• What early indicators predict those outcomes?

• Which inputs can the local team influence?

• What would cause us to expand, intervene, or stop?

• How quickly should we expect each indicator to move?

• Who owns the next action?

The team may still build a dashboard. But the dashboard is now part of a decision system, not the final product.

Most Analytics requests hide a more important decision.

The most valuable work often begins when someone is willing to go one step beyond the original ask.

Earning the seat at the table

Analytics earns its seat one better decision at a time.

The goal isn't to be invited to every meeting or copied on every planning document.

The goal is to become so valuable that teams don't want to make important decisions without you.

You bring facts.
You bring business context.
You identify risks and tradeoffs.
You challenge assumptions.
You recommend a path forward.

Over time, consistently improving decision quality earns Analytics a place in the conversations that matter most.

It's difficult for Analytics to have the greatest impact when they’re engaged too late in the decision-making process. Common patterns include:

• Sizing an opportunity only after it has already been prioritized.

• Validating a plan once the strategy is largely set.

• Reporting on performance after the most important decisions have already been made.

This usually isn't the result of anyone intentionally excluding Analytics. Rather, it is the byproduct of the way many organizations work.

A request comes in. Analytics responds. The immediate problem gets solved.

Over time, Analytics becomes highly effective at supporting decisions, but has fewer opportunities to influence them.

Changing that operating model doesn’t happen by declaring that Analytics works differently.

It changes by repeatedly demonstrating that involving Analytics earlier leads to better plans, clearer decisions, and stronger outcomes.

Putting this into practice

Before discussing hiring, organizational structure, culture, measurement, or AI, you first need to agree on the role Analytics is expected to play.

This is the first principle: Analytics exists to help the business make better decisions and improve measurable outcomes.

And it changes everything: how you hire, how you organize and develop the team, how you measure success, and how you use AI.

That is what this series explores: what world-class Analytics looks like, how to build it, and how the function needs to evolve.

A couple of years ago, our team was asked a question that sounds simple but is very hard to answer: What is actually happening in local economies?

Not the national average. Not survey-based data that comes out on a lag. But what are people actually buying, at what price, in which neighborhoods, in real time, and how is that changing?

DoorDash has a unique lens into that question. Every day, people use our platform to buy meals, groceries, household goods, and everyday essentials across thousands of cities. That gives us a view into local commerce that is both broad and highly granular.

But having the data is not the same thing as knowing what to do with it.

The harder work was deciding which questions were worth asking, how to answer them consistently, and how to build something useful enough for researchers, policymakers, journalists, and local leaders to actually use.

That’s the work my team has been doing.

More specifically, this work has been led by Abhi, Anita, Cheryl, and Eli, with many others across the Analytics team contributing quarter after quarter to shape the methodology, pressure-test the findings, and turn the data into something people outside DoorDash can actually use.

One of the things I’ve always believed about great analytics teams is that the best ones don’t just answer the questions they’re given. They have a point of view on which questions matter.

The Cheeseburger Index is a good example.

It came out of a discussion about how to create a simple, intuitive proxy for local restaurant pricing. Something that could make price differences easier to understand. Something a journalist, a policymaker, or a curious person in Lincoln, Nebraska could look at and immediately grasp.

That is often what good analytics looks like. It’s not always about finding the most sophisticated answer, but finding the clearest one.

Here’s what the Q2 data shows:

• Everyday essentials remain essentially flat this quarter, with the range of household goods down just 0.6% overall compared to Q1 2026 across all categories. The largest mover in that category is diapers, down 2.4% this quarter.

• Some grocery prices have recently started climbing, even as the broader grocery basket remains below year-ago levels. Egg prices helped drive prices down substantially in Q1 2026, but this quarter avocado and milk prices are back up by 12.4% and 8.3%, respectively.

• The Restaurant Price Index and Cheeseburger Index both continued to rise at the pace of inflation, up 3.2% from this time last year, even though the underlying cost of a cheeseburger’s ingredients rose just 0.6%. This points to broader operating-cost pressures — energy, rent, and other overhead — as the likely driver of restaurant inflation, rather than commodity food prices.

One of my favorite parts of this project is exploring the city-level data.

There’s something genuinely fun about pulling up the rankings and seeing where different cities land, and how often they defy expectations. Take Austin, for example: while many people think of it as a city that’s getting more and more expensive, it ranked #1 on our Cheeseburger Index for affordability this quarter. As someone who has enjoyed meals at Whataburger and Hopdoddy Burger Bar, I know a great burger meal can be found there, and the data shows it.

The local variation is real, and it’s bigger than most people assume. Once you start looking at it city by city, the national average stops being very interesting. I’ve always preferred looking at the distribution over focusing on an average.

We’re still building. There are questions we want to answer that we can’t yet. There are categories we want to add. There are new ways to make this data useful to the people studying local economies and making decisions in their communities.

But I am proud of what the team has built so far.

The State of Local Commerce report is not just a data release. It is an example of the kind of work I think great analytics teams should do: take messy, complex, highly local data and turn it into something people can understand, trust, and use.

If you are a researcher, policymaker, journalist, or local leader using this data, I would love to hear what is useful, what is missing, and what you wish we could answer next.

The full Q2 dataset and city-level breakdowns are at: https://about.doordash.com/en-us/state-of-local-commerce

Subscribe now

I relocated to the Bay Area in the spring of 2015 to start my new role at DoorDash headquarters, a former animal hospital in Palo Alto. My role was undefined, my roadmap unwritten, and my title had been changed in our HR system to “Swiss Army Knife” by one of the engineers. It was a joke, but it was also accurate.

As I wrote in Part 4, I called the function BizOps after reading Dan Yoo’s description of similar teams at Yahoo and LinkedIn. The idea resonated immediately: generalists dropped into ambiguous business problems, figuring out what was going on, solving what they could, and then handing things off once the work became more repeatable.

That was exactly what DoorDash needed at the time. I did not set out to build an Analytics function. I was trying to answer the most important questions the business had, one at a time.

I had no formal background in analytics. No statistics degree, no data science training, and no SQL skills when I started. That didn’t matter; I just started.

The first thing I did was ask for all the data we had on business performance. Most of it sat with Finance and had been compiled for fundraising purposes. We had a few dashboards in Chart.io, built by two ops managers who knew SQL.

I spent my first week doing what I could: dissecting cohort retention curves in Excel. An engineer would pull a CSV file with the raw data, and I’d manipulate it from there. INDEX MATCH was my best friend. It was inefficient—not as inefficient as VLOOKUP, but inefficient—and I knew it. But any time I wanted a different cut of data, it required going to an engineer. Even less efficient.

So I spent two weeks heads-down teaching myself SQL. I completed 3 online trainings (my favorite back then was the one written by Mode) and then moved on to real data. I challenged myself to rewrite the queries powering various Chartio dashboards to see if I could get the same answers. I wrote queries, pulled data, and checked whether the results matched. If they didn’t, I tried to debug on my own, and if I was completely stumped, I would sit down with the original authors for help.

Creating a source of truth.

Before we could set goals, we needed to understand our performance at a more granular level. I started setting up dashboards to track the basics: order volume, new consumer acquisition, cohort retention, merchant selection, delivery quality, unit economics, etc.

It sounds obvious now, but at the time, even getting everyone aligned on what we should measure was a meaningful step. I created the DoorDashboard, which we emailed to the whole company each morning so everyone could see the prior day’s performance. We were growing quickly, launching new markets, and learning in real time which inputs moved the business.

DoorDashboard in 2015. It was simple, but it gave everyone the same daily view of the business: growth, profitability, reliability, and quality.

But even with my (now) intermediate-level SQL, not all the data I wanted was accessible in our dashboarding tool. I still frequently required an engineer’s help. And one of our early engineers, Peter Tseng, believed in what I was trying to do and offered to help me help myself.

Peter was genuinely interested in data science and put together a small syllabus to teach me the basics of Python for data analysis. It was just enough to be dangerous, which was exactly what I needed.

He introduced me to pandas, NumPy, and seaborn. The first script I wrote pulled cohort retention by city and visualized it as a triangle heatmap in aqua. It was beautiful.

That was a real unlock. And yes, for anyone wondering: our Substack logo is a little homage to those early cohort heatmaps.

Once I could see the data the way I wanted to, I stopped asking what was happening and started asking why. Why was retention increasing in one city and declining in another? Was it affordability? Selection? Quality? The launch strategy? The consumer mix? I read through consumer feedback, looked at trends by segment, and began identifying themes.

Each insight generated new questions. Each question led to a new analysis. Each analysis created new metrics we needed to track. The cycle didn’t stop—and honestly, it still hasn’t.

Building from zero.

For a while, I was the entire Analytics team.

A typical week might involve setting goals for a new market launch in the morning, digging into consumer retention in the afternoon, and making sense of consumer complaint data at night. There was no roadmap. The roadmap was whatever problem seemed most important to the business that week. I was, as I said at the time, a one-woman Swiss Army Knife playing whack-a-mole with an endless supply of business questions. It worked for a while, until it didn’t.

I knew things had to change when the problems started outpacing me and my skills. We needed geo-level pay optimization for Dashers. We needed to understand density, supply, demand, and unit economics with more precision. We needed simulations. The questions were getting harder, and they required skills I simply did not have—especially deeper statistics and stronger technical depth.

So I started hiring—deliberately, and for complementary skills. My strategy was simple: hire people who could do things I could not. I did not want a team of people who looked exactly like me. I wanted people who spiked in different areas and made the team collectively stronger.

While our strengths were different, our mindset was remarkably similar: we were entrepreneurial, pragmatic, curious, and deeply committed to helping one another succeed.

Barrett had a background in computer science and much stronger Python skills. David had a background in statistics and experience with logistics networks. Ryan had strong SQL skills and a consultant’s approach to problem-solving. Preston brought depth in machine learning and a teacher’s mindset. Hiring people whose strengths complemented my own was one of the most important decisions I made.

Much of what I know about data science, I learned from my own team. I still believe that is one of the most underrated forms of professional development available to any leader: surround yourself with people who are excellent at things you are not, and be humble enough to learn from them.

For a while, we used our real problems as interview questions. The cohort retention SQL query—the one I had struggled to write myself—became our standard coding exercise. The selection intelligence model was used as a case study. If a problem was hard enough to teach us something about the business, it was probably useful for understanding how a candidate thought. I’ll write more about hiring in future posts, but this was the beginning of my philosophy.

That was how the team grew: one business problem, one skill gap, one hire at a time.

When the team outgrew me.

In the early days, people came to us with questions, and we answered them. That worked when the company was small and everyone knew everyone. The first few people on Analytics each had their own reputations. The work spoke for itself.

But as DoorDash grew, the stakes got higher. That model wouldn’t scale.

As we got bigger, analysis started happening outside our team—by operators, by finance, by product managers. Some of it was good. Some of it wasn’t. I remember several instances of analysis reaching leadership that sounded confident but didn’t hold up under scrutiny. That was a problem. Bad analysis could lead to bad decisions. We needed a higher and more consistent bar. That was when I started to understand that Analytics could not just be a team that answered questions. We had to help define what good analysis looked like across the company.

The team shifted from a group of generalists dropped into whatever problem was most urgent to a set of more permanent business partners who could go deep on a particular part of the business. Instead of bouncing from problem to problem, people began developing real context in areas like Dasher supply, consumer retention, merchant selection, and customer support.

We stopped being the team that answered questions and started being the team that owned outcomes alongside our business partners. Those relationships changed the work. People stopped coming to us only when they needed data. They started coming to us when they needed a thought partner.

That shift did not happen because I announced it. It happened one project, one recommendation, and one hard conversation at a time.

However, not every structure we tried worked.

At one point, we experimented with separating product analytics and business analytics, one supporting PMs and the other supporting GMs. In theory, that made sense. Product teams and business teams often ask different types of questions. In practice, we ended up with two people working on similar problems simultaneously, each from a different angle. So we rethought the structure and created a single analytics role that had to bridge both. It was messy for a while. But as our partner teams became more aligned on our north star goals, it started to work.

We had a similar approach to our team structure as we did with our product culture: test and iterate. We would build what the business needed, and then, as the company changed, we had to ask whether the structure still made sense. Sometimes the answer was no.

More teams reporting to you does not automatically mean you are more important.

This was a hard lesson, one that took longer to fully absorb.

In the early days, when I saw a gap, I built the thing to fill it. Data Engineering, Business Intelligence, Machine Learning, Data Product, and Experimentation—at different points—all got started within the Analytics team because the business needed them, and someone had to get them going.

That was the right thing to do at the time. But not every function we started was meant to stay.

I remember when our VP of Engineering came to me and said he thought Machine Learning Engineering (MLE) should move into Engineering. My first reaction was no. Not because I had a principled argument, but because it felt like losing something: team members, scope, and a piece of what I’d built.

I knew moving MLE into Engineering was the right decision for the company. It gave that team the right technical home, the right management structure, and the right path to scale. It also made me better at my job, because it freed me to focus on what I was uniquely positioned to do. But it took me longer than I’d like to admit to fully internalize that lesson: more headcount does not automatically mean more impact.

Sometimes, giving something up is exactly what allows both the work and the leader to improve. I’ve tried to carry that lesson forward every time I’ve faced a similar decision since.

Analytics became more than a team of problem-solvers.

We started as generalists, jumping into whatever problem mattered most. As DoorDash scaled, that wasn’t enough—we also needed a consistent way to measure the business. Analytics became the company’s scorekeeper, defining metrics, building dashboards, and creating shared visibility into performance.

One important milestone was the creation of the Weekly Business Review (WBR). Early on, I pulled the data each week and assigned red, yellow, and green grades to each metric. It was a thankless job. Every leader thought their red should be yellow, and every yellow deserved to be green. But the exercise forced the organization to answer fundamental questions: What are we trying to achieve? How will we measure it? What does success actually look like?

While that brought discipline, it wasn’t the right long-term relationship between Analytics and the business. Being the company’s scorekeeper positioned us as the referee—evaluating performance after decisions had already been made.

Analytics earned a reputation across the company for sound judgment and the ability to solve hard problems. Even in our role as scorekeepers, people knew we cared about impact, not just accuracy. That credibility enabled the team’s next evolution and transformed how we worked with our cross-functional partners.

We stopped thinking of ourselves as the owners of the metrics and started acting as co-owners of the business problems. Instead of simply measuring outcomes, we helped define goals, shape strategy, pressure-test tradeoffs, and work alongside Product, Operations, and Engineering to achieve better results. Success was no longer something we reported on; it was something we helped create.

I remember Tony asking in meetings, “Has Analytics signed off on this?” That question stayed with me, not because it meant Analytics had veto power, but because it meant people believed the decision would be better if we were in the room.

That was when Analytics stopped being a collection of talented problem-solvers, or even the company’s scorekeeper, and became a true partner in building the business.

What I’d tell my earlier self.

If I could go back and talk to the younger version of myself, with no SQL skills, no team, no roadmap, and a “Swiss Army Knife” job title, I’d tell her this: do not let the absence of a credential, title, or prior experience stop you from trying.

Relevant experience matters less than you think. What matters is whether you are willing to figure things out and learn from the people around you.

I could not have articulated all of that in 2015. At the time, I was just treading water—trying to answer the next question, build the next dashboard, hire the next person, and identify the next problem.

But somewhere along the way, that undefined role became a career.

The path wasn’t linear, but it turns out the squiggly line was going somewhere after all.

This brings my career journey series to a close. Not my career, hopefully, just the series.

In the coming months, I’ll be sharing a more practical series on what it takes to build and lead a world-class Analytics team—hiring, structure, culture, measurement, and the role of AI in all of it.

I considered going back to finance. By then, the markets had recovered, and it seemed like a logical option. But deep down, I knew it still wasn’t the right long-term fit for me, and it felt like moving backward rather than building on everything I had just learned.

Around that time, a classmate of mine became a General Manager (GM) at Uber and described the role as a “CEO of your city.” It sounded like a great opportunity to combine the entrepreneurial spirit I loved with the support of a larger team. I was intrigued and wondered what other roles like this might exist.

Finding DoorDash was a little accidental.

Although I never raised any venture capital for GiftSimple, I had met a few folks at various VC firms. Jamie Bott, who was a talent partner at Sequoia Capital, first introduced me to Tony Xu. It was April of 2014, and Alfred Lin had signed a term sheet to lead DoorDash’s $17.3 million Series A funding round. DoorDash was looking to expand beyond Silicon Valley and needed its first General Manager to launch new markets.

At the time, almost no one knew what DoorDash was. I lost count of how often people thought I said I worked for “Jordache,” the 90s denim brand.

The interview process was informal. My first call with Tony took place while he was walking the streets in LA, visiting merchants ahead of the planned summer launch. I completed a take-home exercise analyzing some market data in Excel and had a video interview with co-founders Stanley and Andy, where we talked basketball and compared DoorDash’s assignment algorithm to a zone defense! In those days, Tony personally interviewed and reference-checked every hire. I received an offer pretty quickly after that—you don’t need many interview rounds when the final decision-makers are already involved. The process is much more structured now, but at the time, it reflected the company’s stage: small, fast, and founder-led.

Ultimately, I decided to join for two reasons:

First, I was impressed with Tony. He had a long-term vision for what he wanted to build—a local commerce platform—but was able to get down to the lowest level of detail about what needed to be done today, tomorrow, and next month. He had the unique ability to zoom in and out as needed, and he was incredibly smart yet humble. I met many founders at Wharton and while working on GiftSimple. It was rare to find someone who could operate at both levels so naturally.

Second, the opportunity sounded exciting. I would join as the first GM, head straight to Los Angeles to help launch the market, and then continue launching cities until I found one I wanted to run longer term.

Launching a market meant doing everything.

The job was all about hustle and rapid execution in those early days. There wasn’t much data to analyze, even if we’d had the time to try. Instead, it was a lot of trial and error—throwing ideas at the wall to see what worked.

Going door-to-door signing up merchants? Check.

Running twice-daily Dasher orientations? Check.

Writing handwritten thank-you notes to consumers to slip into delivery bags? Check.

Interviewing candidates for the open roles on the local team? Check.

Breaking down boxes and taking out the trash? Check.

Learning how to optimize Google Ad campaigns? Handing out promo codes at Santa Monica Pier movie nights? Unpacking boxes of doorhangers we’d hang in neighborhoods while doing deliveries? All done.

It was relentless, gritty, and wildly energizing.

We worked seven days a week, often crashing on air mattresses in the office or inexpensive Airbnbs. My first night in LA was spent in a tiny Venice apartment overrun by two cats and an unbearable stench. It was so bad that one teammate opted to sleep in the office on cardboard boxes instead. After pleading with Airbnb, we got a new place—only to discover it was crawling with ants. A quick trip to Ralph’s grocery store on Lincoln Ave for cans of Raid solved that problem, and we got back to work.

After launching LA and leaving the market in the hands of the permanent local team—shout out to Casey North—I moved on to Boston.

Boston would introduce three new challenges for us: the Eastern time zone (our team had only operated on Pacific time), cold weather (it was the fall of 2014), and bicycles (until this point, DoorDash was 100% car delivery). Boston was different.

I spent seven months in Boston, including the snowiest month on record in February 2015.

Back then, we were only open for lunch and dinner. We closed from 2 to 5 p.m., and ran Dasher orientations in our office. During dinner, from 5 to 10 p.m., we rotated manning our dispatching tool. We manually assigned Dashers to orders while our engineering team worked to build vehicle type into the assignment algorithm.

We had competitions over who could get to 0% lateness. I took this seriously and often won, which I’m sure will surprise no one who has worked with me. But the part I found most interesting was understanding why an assignment was good or bad in the first place.

I wanted to understand why.

We started manually scoring assignment quality and sending feedback to Rohan and the engineering team: where the algorithm was working, where it was struggling with bikes, and what seemed to be driving lateness. That tight loop between what was happening on the ground and what we could measure was my first glimpse of how I would think about analytics for the next decade.

I loved that part. In hindsight, that probably should have been a clue. I was most energized when there was a system to understand, a metric to improve, and a clear connection between the work and the outcome.

What caused lateness? What was in our control? Which actions actually moved the metric? Where was the bottleneck? How could we make the process better the next day?

The rest of the job was much less analytical and much more hustle. We woke up at 5 a.m. to stand outside various Boston T stations in the middle of winter, handing out KIND bars with promo codes to morning commuters. We took out the garbage to the dumpsters on Saturday nights and celebrated by playing dice games and eating ice cream in the office. In the evenings, we would send apology emails to everyone who had a late order. Every day was an opportunity to grow the business: sign new merchants, onboard new Dashers, acquire new consumers, fix whatever broke, and then do it all again the next day.

I was an average GM, but it wasn’t my superpower.

I worked hard, got the job done, and was willing to do whatever needed to be done. But the role—especially in those early days—did not play to my strengths.

The best early GMs were energized by the constant hustle: putting out fires, rallying teams, and making dozens of judgment calls with imperfect information. It was gritty, fast-moving work, and I had a lot of respect for the people who were great at it.

But what I gravitated toward was different.

I was more interested in zooming in. I wanted to understand the mechanics underneath the outcomes. Why was one assignment late and another on time? Which factors actually mattered, and which were just noise? What made one launch more successful than another? How could we compare Boston to LA or Chicago in a way that was fair and useful?

One of DoorDash’s operating instincts is to look beyond the averages and understand the outliers. That’s where I was naturally drawn. The exceptions were often where the best lessons were hiding.

I believe you can do almost any role reasonably well for a period of time, even if it is not the perfect fit. But eventually, you should seek out work that plays to your strengths. For me, that meant moving closer to the questions behind the work: what matters, how we measure it, and what “good” actually looks like.

The question that changed my career.

Around this time, Tony was managing several GMs and wrestling with a similar question: How do you hold GMs accountable when the markets they run are so different?

What does a “good” launch look like? Measuring GMs on raw activity was not enough. Signing restaurants mattered, but not all restaurants were equally valuable. Onboarding Dashers mattered, but only if we had the right supply at the right times and in the right places. Handing out promo codes mattered, but only if those customers actually ordered, retained, and helped build a healthy market.

At one point, Tony said something along the lines of, “I don’t know how to goal my GMs. Could you figure that out?”

That conversation changed my career. Instead of moving on to the next market launch, I moved into something much less defined: figuring out how to set the right goals, measure launch success, understand unit economics, think about Dasher supply, and identify the inputs that actually made the DoorDash flywheel work.

The role did not have a name at first. Around that time, I had read a piece by Dan Yoo about BizOps teams at Yahoo and LinkedIn—groups of generalists who acted like Swiss army knives, dropping into ambiguous business problems, figuring out what was going on, solving what they could, and then handing things off once the work became more repeatable.

That sounded a lot like what DoorDash needed. So I called my role BizOps.

The right move does not always look like a step up.

People often think about careers as a linear path: the next role, the bigger role, the one that looks more impressive on paper. This was not a promotion. I had expected to keep launching markets until I picked one to run permanently, but instead, I was joining Finance in a new role with no established team, no clear playbook, and no guarantee it would become anything meaningful. You could argue it was a step sideways. Maybe even a step down?

But it was the right move because it was the right fit. It was work I was excited about, work where I thought I could add real value to the business, and work that pulled me closer to the questions I could not stop thinking about.

Looking back, it is easy to make the story sound intentional and strategic. It was not. Living it felt much more like a squiggly line: a failed bank, a failed startup, a GM role that was not quite the right fit, and then an undefined problem that eventually became a function.

That was the turning point.

I had joined DoorDash to be a GM. I stayed because I found the work that actually fit me—and because I got to keep working alongside some of the best operators I had ever met.

Coming up in Part 5: how that undefined problem became the beginning of DoorDash’s Analytics function.

In addition to writing the financial section for a business plan for fashionable bike helmets with my classmates, I was introduced to other entrepreneurs’ stories through case studies. An academic paper we read, The Accidental Entrepreneur: The Emergent and Collective Process of User Entrepreneurship1, showed me a different kind of founder—the customer-turned-entrepreneur. I learned that there are many types of founders.

I enjoyed the introductory class so much that I took a second entrepreneurship class. It was in this class that I dreamed up what would become my own company: GiftSimple, a social gifting platform. I grew up saving the money my family gave me on my birthday for some larger purchase I was working toward. I thought others might be doing the same, and I saw an opportunity to make an existing offline behavior easier online: pooling money for a meaningful gift for birthdays, weddings, graduations, and other celebrations. I started GiftSimple in my final semester of business school and decided to spend the following year seeing if I could make it work.

A Crash Course in Building

For the next two years, I had a crash course in starting a company. Nearly everything I tackled was brand new, but I was fortunate to have guidance from my brother Marc, who had product management experience, and folks he trusted, like Jason and Russell. I started by registering a legal business entity and acquiring a domain—simple steps that felt monumental at the time. It was my first time working with a designer on UI/UX wireframes or thinking about how to set up web analytics and tracking—there was a steep learning curve! When the site launched, the focus shifted to customer acquisition. I developed social media campaigns, authored content for the GiftSimple blog, and launched paid advertising through Google AdWords. I’ll never forget the thrill of seeing the very first listing from a customer I didn’t know—it was a small, shining victory.

By the end of the first year, we had built a base of roughly 1,500 registered users, but growth had stalled. Instead of seeking feedback from customers (or potential customers), I doubled down on marketing tactics to reignite momentum. In hindsight, this was a mistake because I hadn’t found product-market fit. It wasn’t until I started preparing to pitch venture capitalists that I could see the flaws through their eyes—what I loved about the idea was also its biggest weakness: social norms around gifting were more deeply ingrained than I had assumed. I spent another year giving everything I had to GiftSimple before ultimately deciding to shut it down. It was a bittersweet decision, but the experience was transformative and taught me lessons that no textbook ever could.

Entrepreneurship isn’t as risky as it seems.

When I first imagined starting a company, I pictured entrepreneurs draining their life savings and living out of their cars. While that may be true for some, my experience was different. I started GiftSimple while in school, leveraging university entrepreneurship programs and a modest amount of startup capital to get it off the ground.

And if that was true then, it is even more true now. With AI, the cost of trying has never been lower. You no longer need the same level of engineering, design, or finance support to test an idea. You can get an MVP to market fast, pressure-test assumptions, and learn whether something has promise before committing years of your life to it.

GiftSimple failed, but so did Lehman Brothers. Nothing in life is guaranteed. The risk of not trying—of never knowing—felt greater to me than the risk of failure.

People don’t always act how you expect or how they say they will.

Social norms around gifting are deeply ingrained. Asking for money feels acceptable for charity or a wedding registry, but for birthdays or graduations? People hesitated. Despite what users told us in research—things like, “I’d love to use this for my next birthday!”—their actions said otherwise. Changing long-standing behaviors is hard, and what people say and what they actually do are not always the same! This lesson has stayed with me: qualitative research tells you what people think they want; quantitative research tells you what they actually do. You need both.

Loving an idea doesn’t make it a good business.

I loved the premise for GiftSimple. It took an existing offline behavior and made it more efficient using the power of social networks. But my excitement didn’t mean it was a good business. Passion is powerful, but it doesn’t automatically translate into a viable business. The VC pitch process was humbling in the best way—it forced me to stress-test my own assumptions and see the idea as an investor would, not just as a founder.

Decisions need to be made faster—and metrics make that possible.

I held onto GiftSimple far too long. Looking back, I knew it wasn’t working after the first year, but my determination and love for the idea kept me pushing forward. The core problem wasn’t just stubbornness—it was that I never set clear metrics or milestones up front. Without them, I had no objective trigger to act on. There was no number I could point to and say: “We said X, we got Y, it’s time to make a call.”

I’ve realized since then that delaying decisions often stems from the absence of a forcing function. When teams lack a clear goal, it becomes too easy for decisions to stall. Setting clear goals at the outset creates the structure teams need to make decisions with confidence. It’s a lesson I’ve carried into every team I’ve built since.

Failure isn’t the end—it’s part of the journey.

When I finally decided to shut GiftSimple down, I felt like I’d failed. As someone who’s always been goal-oriented, it was hard to accept that I’d poured so much into something and didn’t achieve what I set out to do. It felt public and embarrassing.

But over time, I’ve learned that failure isn’t something to hide from. Everyone experiences it in one way or another, and trying to avoid it only limits your opportunities. Failing at GiftSimple taught me that what matters most is what you take away from the experience and how you use it to grow.

What I took away was an operator’s mindset: a bias for action, a respect for data, and an instinct for when to move fast versus when to slow down and get the precise answer.

Those instincts didn’t come from a class or a framework. They came from two years of building something real, watching it struggle, and making hard calls with imperfect information.

As I’ll try to show in future posts, this setback didn’t just build character. It gave me an edge in analytics—and a set of principles I still apply in my work today. In a very real way, that failure became part of the foundation for what came next.

Coming up in Part 4: how I joined DoorDash as its first General Manager, and what I learned about building from zero.

I remember taking my father’s business cards, using Wite-Out® to remove his name, and replacing it with my own using a typewriter! I then moved up the ranks and asked the bank’s President for his business card so I could do the same—I was always ambitious! I made photocopies, cut them out, and handed them to people around the office. Even then, I knew that one day, I’d be a boss! However, I never thought I’d be leading a global analytics team.

From that little girl to a young adult, my career ambition remained the same. Fast forward to college. I attended Cornell University as an undergrad, and after graduation, I spent a year in capital markets before achieving my goal of becoming an investment banker at Lehman Brothers.

Unlike many others, I enjoyed my time in banking. I was an Analyst working in leveraged finance. Focused solely on debt issuance, I liked that this team allowed me to work across many industries, including consumer, retail, gaming, hospitality, technology, media, and healthcare. I learned how to pick apart companies, to always read the footnotes of financial statements (that’s where the good stuff is!), and became a pro at building financial models in Excel. I felt lucky to be surrounded by smart and highly motivated people, most of whom were quite nice.

At 23, I had access to CEOs and CFOs of Fortune 500 companies, and while I did my fair share of book-binding and coffee runs, I learned a lot from my interactions with these intelligent and accomplished executives. I learned that even in the same role, different executives could have widely different approaches. I gravitated towards the “operators,” specifically the ones who wanted to get into the details and knew their numbers cold. I found the Analyst role to be well-defined and a good fit for someone like me: able to function on little sleep, had a keen eye for formatting errors, and wouldn’t give up until all model errors were resolved. I was fortunate to experience the “heyday” of banking with lavish closing dinners and golf outings. And I admit the excess was fun. I remember flying from a deal-closing celebration in Vail, Colorado, directly to a golf outing in Scottsdale, Arizona, and thinking about how surreal my life seemed compared to my friends back home. But I also experienced the darker side - being asked to pick up a designer dress for a client’s mistress and being so exhausted from repeated all-nighters that I had to sneak a power nap in the stall of the ladies’ room, resting my head on the roll of toilet paper.

The problem brewing—besides the impending 2008 financial crisis, of course—was that I didn’t like my bosses’ jobs. Banking has a very clear career path, and this is comforting to folks who like to know the rules. But, if you don’t like where that path leads, there aren’t many alternatives. I didn’t think much about it at the time; I was enjoying my current role, and I was loyal. I decided to stay on for a third year at Lehman Brothers and go straight into the Associate program. After committing to the program, I had the opportunity to work from our Hong Kong office, and in 2007, a lot of deals were happening in Asia. So I packed my bags, ready for a new experience in China. The work was the same, but the environment was different. For the first time, I stuck out as “different.” I didn’t speak the language or look like I belonged. It was an adjustment initially, but I enjoyed my time in Hong Kong. I embraced being an expat, learning how to say “Mosque Street” in Cantonese and finding the most efficient route to work down the Mid-Levels escalator system. My time in Asia also sparked a passion for travel that continues to this day.

In the summer of 2008, I came back to a country where things were very different from when I had left. Bear Stearns had collapsed, the financial markets were depressed, and layoffs at Lehman had been ongoing. After completing the Associate training program, it was recommended that I rejoin my former group, where folks knew me, instead of starting my rotation in a new group. A few days later, Lehman Brothers went bankrupt and was bought by Barclays. What I remember most about the fall of 2008 was the overarching sense of anxiety around the office. The days were dull—no deals were being done—and there was so much uncertainty. Without work, all you could do was focus on the unknowns and take long lunches. Would we have jobs tomorrow? Health insurance? Who would be laid off next? Banking was no longer fun (or lucrative).

As the layoffs continued, only a handful of junior folks remained. It seemed inevitable that my name would be called at some point, and I started to think about what I would do if that happened. I thought of going to another financial institution or into private equity, but if I could even find someone hiring, I still had lingering doubts about whether this was the right long-term career for me.

What did I want to do when I grew up? I had no idea. I needed time to figure it out. So, I decided to take the socially acceptable “break” known as going to business school!

I attended The Wharton School at the University of Pennsylvania and naively thought that I would experience something akin to divine intervention while sitting in one of my classes, suddenly realizing my destined career. This did not happen. I took classes in marketing, sports management, operations research, strategy, and international finance. I tried consulting for the summer, but nothing fit. On a whim, a classmate of mine, Davis Smith suggested I take an entrepreneurship class, where the main project was to write a business plan for a startup idea. He already had an idea, and I would be responsible for writing the financial section. I was still trying to figure out my interests, and while I didn’t think that was entrepreneurship, I signed up for the class anyway.

On the first day, Professor Ethan Mollick asked the class how many people were interested in starting their own businesses at some point. Everyone’s hands went up except mine! He looked at me and smiled as if to say, “Challenge accepted.”

Click here for part three, the story of how I failed spectacularly as an entrepreneur. If you missed part one, you can find that here.

Subscribe now

I joined DoorDash over a decade ago as its first General Manager. I have no formal data science training, but today, I lead a global Analytics organization for a $40B+ public company. So, how did I end up here?

Tony Xu believes in superpowers and I don’t give up easily.

Tony believes that everyone has something that they’re uniquely good at. He encourages people to identify their superpower and look for opportunities to match that superpower with a company’s needs. He recognized my superpower before I did.

A few years into my tenure, I asked Tony why he hired me. It wasn’t surprising to hear that it was NOT my investment banking experience or my MBA. He used to tease a few of us early folks with MBAs about our Master’s degrees—which he also had!—because he saw a lot of resumés with similar credentials. What he found interesting about me was that I had tried to start my own company. Starting a company showed courage and demonstrated that I had the entrepreneurial spirit he was looking for in a General Manager (GM).

I’ll talk more about my startup, GiftSimple, and what its failure ultimately taught me about entrepreneurship and success, as well as my decision to join DoorDash and my experience as the first GM in subsequent posts. For now, we’ll start with my transition from the Operations team to Analytics. It was the spring of 2015, and after making it through the snowiest winter on record in Boston, I had hired and onboarded the permanent GM for the market. It was time to move on to the next city launch. During our conversation about which market I’d go to next, Tony noted my penchant for asking questions. With our future launch plans growing, we started to compile a launch playbook to establish what a good launch looked like. I asked a lot of questions and had a lot of opinions on how we should set goals for each launch.

I felt strongly that the goals for each market should be different—depending on factors like total addressable market and competition—and I wanted to set goals on the input metrics that the local teams could control. I had spent time trying to understand how the core fundamentals of the Boston launch—selection, quality, and price—drove growth. And I was determined to find a way to measure the ROI of our marketing efforts during the initial months of launch, so we could learn what tactics worked for the next one. Given all this, Tony suggested I pack up my suitcase, deflate the air mattress I’d been sleeping on in downtown Boston, and move to headquarters in California to help ask and answer these key questions, full-time.

Tony recognized that I could be more effective working across all geographies rather than focusing on one. He encouraged me to lean into my strengths: asking impactful questions, a love of complex problems, and a relentless drive to get the right answer. I saw an opportunity to both answer my own questions and uplevel the overall business by creating a new function. At first, I was hesitant to make the move, as the scope of the role was ill-defined and the goals unclear. The GM role was a known entity. Ultimately, what swayed my decision was excitement about the problems I’d be working on—and the promise that if I hated the new role, I could go back to being a GM. At the time. this felt like a major pivot, but in hindsight, it was a natural progression.

I called the new team BizOps (Business Operations & Analytics) after learning about a cool-sounding team at Yahoo and LinkedIn, through Dan Yoo. I was a jack-of-all-trades trying to identify and solve the most important problems for the company, whether that was setting the right goals for new market launches, digging into the drivers of consumer retention, or making sense of our customer complaint data. No matter the problem, I kept the “operator” mindset so core to DoorDash’s culture and focused on quickly driving business results.

I won’t pretend I had a grand vision for Analytics in the early days. That time was a chaotic scramble to solve problems, only to encounter new ones along the way. I was a one-woman Swiss army knife playing whack-a-mole with an endless supply of business questions. I got my first headcount when I showed Tony the backlog of work I wanted to get done—a list full of things that were also top of mind for him. For my first few hires, I wanted folks who were generalists, but who possessed complementary skills to me. Hiring folks who possessed skills I didn’t have was a key part of my success at DoorDash. Much of what I learned about data science, I learned from my team. I will talk more about my hiring philosophy and process in a later blog post, but I will say that I owe a lot of my success to the amazing folks who have surrounded me on the Analytics team over the years.

The complexity of the problems increased, requiring the sophistication of our analysis to increase in parallel. This meant hiring more specialists, including data engineers, machine learning data scientists, and statisticians. For me, success was always measured by impact, and I held my team to the same bar. I expected recommendations—not research—and that all of our work connects to a company goal we were trying to achieve. We used the power of analytics as a force to increase the speed and quality of our execution, and I believe this was a key part of DoorDash’s success in those fundamental years.

Today, I lead a 600+ person global Analytics team across DoorDash, WoIt and Deliveroo. As DoorDash, Inc., we operate in over 40 countries, worldwide. The team’s reach has expanded over the years—and the depth of our analysis has grown—but our goal to drive real business impact has not changed.

Over the last 12 years, I have been a GM and I have led teams across data engineering and business intelligence, experimentation, machine learning, data science, and bizops. My journey was not planned but came about organically as needs arose and opportunities presented themselves. I was intentional about never saying “I can’t do that” and replacing it with “How might I go about doing that?” —learning from the DoorDash value to “choose optimism, and have a plan.”

Click here for part two, how I started my finance career in the midst of the financial crisis.