Dane Thompson 0:00:08.0:  

With me today we're going to have Ankesh Tyagi from Stripe. Real quick, myself, Dane Thompson, principal solutions consultant from Anaplan, working with our technology media and telecom customers. What is your role at Stripe today? 

 

Ankesh Tyagi 0:00:23.1: 

My background is spread across a few things. I started as a software engineer, worked as a financial analyst, and my career has converged to lead the intersection of finance and technology working for Stripe in so many different ways. Currently, I lead the enterprise planning practice at Stripe, along with related analytics, data warehousing and reporting. My team supports finance and GDM as a function for planning aspect, and we are looking to expand into more functions like marketing. 

 

Dane Thompson 0:01:07.0: 

I know we talked a little bit about Stripe earlier, but maybe for people who aren't as familiar with Stripe, maybe just a little bit about the company background and the industry that you work in, and also the concept of GDP and the internet. 

 

Ankesh Tyagi 0:01:18.9: 

Yes. So, at Stripe, from a philosophy standpoint, we think that the size of the pie is not set, and we believe in growth mindset, and the GDP of the internet comes from that place, that we can bring more and more businesses online and, essentially, expand the GDP of the internet, let the transactions be done more smoothly, and make it really easy to provide payment infrastructure for businesses whose focus is actually running their business, rather than worrying around whether they are receiving their payments and be able to pay their vendors, and so on. Actually, it happened so that Denise and I, we have worked together in the past, and it's a pleasant surprise to see her here.  

 

Dane Thompson 0:02:17.2: 

So, getting right into it, maybe summarize your journey with Anaplan at Stripe. The other piece about that, too, is what challenges or issues were you trying to solve by bringing Anaplan into Stripe? 

 

Ankesh Tyagi 0:02:29.6: 

So, from a Stripe standpoint, I started at Stripe roughly two years back, and at that time we were very focused on financial consolidation, looking at income statements, looking at some of our balance sheet quoting. Essentially, serving an FP&A function more specifically, and over the last two years we have expanded it across the finance domain, addressing, not only the financial statements, but think about the P&L items, the topline margin, OpEx, and going down to EBITDA, and even down from EBITDA, thinking about capital planning and supporting treasury as a function. So we have really expanded over the past two years, and now we do the majority of our revenue planning happens in Anaplan. All of our headcount OpEx and non-headcount OpEx, those things happen in Anaplan, and then we support capital plan for treasury and finance.  

 

Ankesh Tyagi 0:03:37.2: 

So, we are truly trying to materialize the connected planning vision with building these pillars, and it takes some amount of time. It really is a journey. We have been able to do it, to an extent, in finance, and we are starting to do that to an extent in GDM now, building territory and quota; building territory right now, and then quota subsequently. Some of the work that actually Denise had done at Stripe, and started at Stripe, that has worked as foundational for us, and now we are further along on the majority curve, where we are able to realize some of these benefits. 

 

Dane Thompson 0:04:27.2: 

So, you started out getting those foundational pieces in place, and you moved on to some other important areas of the business. What do you think are some of the key elements to the models within your process? Start with that. 

 

Ankesh Tyagi 0:04:45.1: 

I think the key components there are, we just look at it by components in our financial planning, and what components do we need to do correctly to land an effective annual and quarterly plan for our finance function. Largely, we look at it as big P&L items, as I mentioned earlier, and then we pretty much have models for those areas. We have a revenue-forecasting model; we have an OpEx model, where we do headcount and non-headcount OpEx forecasting; and then we also have free cashflow and capital planning models, which are all interconnected. Then, finally, we consolidate and service it up into P&L views and product margin views. Those are the critical components, and then, given the complexity of our business, we work very closely with the data science team, and we use ML a lot in generating forecasts, and then consuming into Anaplan sending it back. It's a bit circular, but actually quite informative, because things are connected and they are talking to each other. 

 

Dane Thompson 0:06:06.3: 

We've got a wide range of customers here today, in different industries, verticals, and everyone's trying to solve different problems. Everyone's industry and business is different. What are some of the things with Stripe that you built into your Anaplan models that you think are truly unique to Stripe, that you had to solve for? 

 

Ankesh Tyagi 0:06:24.3: 

Before I answer that, just a small thing. I think in the planning world, Excel and G-Sheets, these are like social media, everyone has their truth, but no one can agree on what the truth is, and Anaplan helps solve for that. It brings those processes in. What we have built for Stripe, specifically, of late, is our revenue forecasting is incredibly complex, and for, not in a naïve way, when you are doing your first Anaplan model, you do a rookie mistake of putting every dimension in a module and think about it I need all these intersections. That is not the case with us. We truly need a ten- or twelve-dimensional model to be able to look at our revenue at that cut and be able to see are we performing well or not. That is something unique to Stripe. I have worked in other companies where I have been involved in revenue forecasting, but it is never truly as dimensionalized as it is at Stripe. Actually, we are among the early adopters of Polaris, and initially, we had some hiccups in adopting it, but now we are at a very good place where we are utilizing it effectively. Our model is incredibly huge, with 4.3 trillion sales. This has been one of the weaknesses of Anaplan in the past, but now it's becoming a strength that we can connect it with not-so-sparse model with a sparse model, and truly have it in one place.  

 

Dane Thompson 0:08:12.2: 

Yes, that's kind of a good segue, because we can talk about being an early-adopter player, and that's been really powerful for you guys. Anyway, it's really important to be able to have all those dimensions. Obviously, revenue is important to every company, but why is it so important to be able to do that analysis for Stripe? 

 

Ankesh Tyagi 0:08:26.4: 

So, for example, it's one good thing to say that our mission is to increase the GDP of the internet, and it's another to operationalize it, and just think about if our vision is as ambitious, we do need to look at that GDP of the internet sort of a size by two dimensions, and bringing the tactical details to it. We do not only care about whether or not payments are growing in certain areas; we do care about what type of a pricing model, what region it is, what payment instrument it is, and there are several other dimensions that go into it. It is practically not possible for us to do it in G-Sheets. Just think about our model, there's 4.3 trillion sales, so it's impractical. In the past we were doing a lesser dimensional view of it in G-Sheets, and trying to address those business questions, and we were challenged, truly. We had to do different views in G-Sheets to address and answer questions, but in this way, we are able to put them in one place and truly be able to answer those questions in one place. 

 

Ankesh Tyagi 0:09:49.5: 

This is where having one dataset in one place has helped us a lot. We have, literally, 250 charts, 248 to be exact, in Anaplan, to decipher all of these trends, and a whole team of analysts analyze these trends and ask questions about whether these trends are making sense, or there is something more to be done, or something needs to be corrected. That just was impossible before.  

 

Dane Thompson 0:10:21.0: 

Well, you mentioned earlier, obviously, that you started with finance and you moved on to opening up to other areas of the organization such as sales. Maybe talk about moving from finance to that sales planning, what that process looked like for your organization. 

 

Ankesh Tyagi 0:10:37.3: 

So, we have been on a journey, and looking at this honeycomb, I always say that this is the competitive advantage of having a platform like Anaplan, because one thing can connect to another, and it becomes a truly informative ecosystem for you, and as I think it's a coincidence that we have Denise here, the headcount planning was actually started when Denise was at Stripe, and we started it for some of the areas focused on GDM, expanding it to the broader organization, and since then, we have been attempting things on GDM side, but with not as much rigor or diligence. Now that we have some of the foundations done correctly with headcount planning, this time around we have very little true territory, and we are in the process of building quota model, and having a true source of GDM headcount and ability to say this is my correct headcount, this is the correct profile of my sellers, and then having to intersect that with territories, etc., that has unlocked a lot of value for us, and we are on that journey. Literally, our '25 planning is starting this week, and we will see some benefits of it over the next few months.  

 

Ankesh Tyagi 0:12:18.2: 

Closed-loop marketing is another one which I have done it in the past, and it is truly insightful when done well. Where your marketers can come in, they can plan your bottom-serve marketing activities, and provide you insights as a finance team to look at what activities are being planned, what are the budget values, etc. Then you can send it to your EIP system or purchase requisition system, and bring the data back from GL into Anaplan again. That's the beauty of it; that connected thing will keep coming back, integrating Anaplan with other applications is relatively easier, and you can exchange data very easily, and that bring a lot of value, so we are in the process of building a proof of concept in marketing. 

 

Dane Thompson 0:13:13.9: 

So, obviously, one piece of connected planning was simply just the data moving back and forth through models, but there's also the other aspect of the people aspect, the collaboration, the communication between those different teams. How do you think that the collaboration has changed now that you've rolled out these other use cases between finance? What are some of the different decisions being made today that maybe weren't being made before as a group, for example? 

 

Ankesh Tyagi 0:13:38.8: 

That's a good question, actually. So if you look at the revenue-margin honeycomb, and you look at the income-statement forecasting, in the past the income statement was in Anaplan, and the revenue-margin planning was a gamut of G-Sheets. Like, there were several people working with G-Sheets, and then at some point in the process they will say, 'Okay, agree upon a number, and input that into that model.' Now, the process is - and their forecasting process was in G-Sheets dropping comments for each other, 'I made this change, you made this change,' because it's high-dimensional, your forecast could impact mine, and mine can impact someone else's. So putting that in Anaplan and tagging those forecast inputs by users, enabling some of the comment functionality, integrating it with Slack channel, it has unlocked quite a bit which we weren't even thinking about solving. Our problem space was, how do I bring this high-dimensional model into a platform, and then all these added benefits have really changed how people interact and work through this. They know who made this change in the forecast, what was the context for it. In the comment section they dropped their workings. So, for example, they might still have some G-Sheet where they did some workings for their forecast, they can link it to that G-Sheet, 'This is the context for my forecast input,' and the collaboration is much better.  

 

Dane Thompson 0:15:20.4: 

I have to imagine the cycle time has probably been reduced, or at least you're spending more time on the analysis piece of the cycle, rather than just simply pointing data together. 

 

Ankesh Tyagi 0:15:28.8: 

Cycle time, certainly, and I would say to quote my F&S leader, he said that once we went live with those charts and trending capabilities, etc., he said it's a huge value and luck for my team. I am quoting him that value and luck aspect of it, because otherwise, the process was get the data somewhere in user table in the data warehouse, then try to pull together some charts, and try to make sense of those trends, so that problem area has been truly impactful. 

 

Dane Thompson 0:16:10.2: 

So, I think, again, you've gone through this many times before, going through this process of rolling out the use cases and so forth, but once you've gone through this process, it's kind of like, 'So what?' How do you know that you're being successful with this? What are some of the KPIs, what are some of the things that you're trying to drive as a business that you're either tracking or keeping an eye on as you role these use cases out, and how that's potentially improved within Stripe? 

 

Ankesh Tyagi 0:16:37.6: 

Again, I will index back to the revenue forecasting, and I will give more examples maybe from headcount. Revenue forecasting is such a complex problem for us, that earlier the bulk of our effort was going into wrangling the data and making things work with G-Sheets. Now the focus is on how do we improve the forecast, 'Here are the trends that are showing an anomaly. Maybe my machine-learning model is not intelligent enough to pick these up. What new context do I need to feed to my data science model to inform my forecast?' The conversation has shifted along the spectrum on the higher side of the value, and we are making progress on improving our forecast, and we do hold ourselves accountable, like a typical finance function, that we need to be within plus/minus two per cent for this, plus/minus three per cent for that, and we drag those metrics every quarter, ever annual budgeting cycle.  

 

Dane Thompson 0:17:46.5: 

Actually, out of curiosity, are you doing some of that reporting of KPIs in Anaplan itself, as well, or...? 

 

Ankesh Tyagi 0:17:52.9: 

No, we'd focus on those reporting KPIs in our analytics platform. That's another thing; Anaplan is so versatile that you can sometimes fall into the trap of solving everything with Anaplan. I have seen project management done in Anaplan; I have seen revenue operations, finance, marketing. It's quite versatile, but we have chosen a more flexible purpose, built an analytics thing for that purpose. 

 

Dane Thompson 0:18:29.8: 

That's actually a good question, leading to my next thought. The future state, obviously, we talked about close of marketing a little bit, as one of those use cases you're going after. I've got I guess two questions. What other use cases are coming to mind, and then, how are you as a team identifying those use cases in the first place? Are people coming to you to say, 'Hey I want to go after this'? Is it something that you'll have like a core team that evaluates these things? Walk me through that process of what's next, and how you come to those decisions in the first place. 

 

Ankesh Tyagi 0:18:59.1: 

I think now, we are at a place where we have a critical mass of activity happening in Anaplan, and there is value in getting hooked up to this ecosystem. Especially, if you are on some aspect of planning the spectrum, it's important to get hooked up here on the platform. So we are seeing both the index happening that sometimes we go out and spot opportunities that this might be an additional area which could benefit, and we are also having some of the business partners and business function leaders approaching us. Anaplan has been around for a little while, so a lot of folks have worked with Anaplan in their past roles, and they have benefitted from it, and they want to adopt that at Stripe as well. So, we have both things going on. 

 

Dane Thompson 0:19:59.2: 

So I think just a bigger question, a lessons-learned type of thing, obviously, you've been using Anaplan for a long time, you're a current leader in this space. What are some lessons learned, and then also, just generally, what advice for people who are newer to Anaplan, maybe the first time implementing a use case, what would you recommend to them, and what ideas are...? 

 

Ankesh Tyagi 0:20:22.5: 

I would say two things. One, to truly approach it with a product mindset, that you are not shipping a platform, but you are shipping a product that you have built in partnership with your business users, and we invest a good amount of time putting that on paper, that this is your problem, this is how you solve it, and this is what we will deliver. So that is the first aspect of aligning with the folks, and then also we stay close to some of - whenever we are doing a big implementation we have a super-user group, or two or three people identified who will be the super-users in the future model, and work with them very closely as functional experts, truly to the detail, 'What sort of a grid view do you want? What sort of a chart do you want? How many clicks go into uploading this?' Those sort of details we tried to iron out. Other than that, it's also start bringing your own contextual knowledge, because you become an expert in this, how these things are connected, and informing those users, like what do you think about, for example, here, hooking up headcount planning, the GDM headcount planning and tagging, bringing that context and keeping them close to the execution process is what I would say it should do, and shouldn't do is, I would say don't fall into the trap of Anaplan can solve everything. It can solve a lot in the planning space, but don't try to solve for complicated reporting problems, where user inputs are not needed. That's where we have seen a lot of challenges from our side. 

 

Dane Thompson 0:22:21.9: 

I think at this point we're going to open up to questions from the audience. 

 

Keegan Musser 0:22:33.6: 

Hi. Keegan from Amazon Games. So you dangled a little carrot in front of us at the end, by mentioning some use cases which you didn't think were too compatible with Anaplan. Could you go into why you don't think those were a right fit? 

 

Ankesh Tyagi 0:22:50.8: 

I think I largely alluded to trying to solve analytics and reporting in Anaplan. It does have impactful reporting functionality that you can have nice-looking charts and very interactive user interface, but you will start running - it is not your data warehouse, and do not treat it as such. It's a far more valuable resource and versatile resource that you have, rather than having a data warehouse where maybe in a planning system I only want four planning scenarios, but for reporting I need, I don't know, eight or nine for different purposes, so that's the intent of my comment, because that's the peripheral area when folks find it impactful in planning. The next step is to report on it, and you can certainly do some amount of reporting in Anaplan, but it's not a tableau. It is not some other sequel interface either. Some folks want an Nth degree of flexibility in the data that they want. You can only serve it up in a few different ways. 

 

Audience 0:24:12.7: 

[Inaudible] 

 

Audience 0:24:25.9: 

I have two questions. Both are related together. So, one is about your revenue model value. You said the model was so big, and you are the one adopted the Polaris model, as well, so was it like a hyper model you moved to the Polaris to get into the ten-dimensions module, and stuff like that? That's my first question. Second question is related to how did you manage the performance, because if you have multiple dimensions and data, obviously, there will be some performance issues. How did you manage? Was there anything? If so, how did you manage? 

 

Ankesh Tyagi 0:24:59.0: 

The revenue model, we had solved for it in a classic hyper-model in the past. Last year we had solved for the revenue model in classic with just one year time horizon, and that was a hyper-model in itself, and we could not scale further. That was the cut-off. At that point, we evaluated Polaris, did a very contained POC to check out whether it will work, and we adopted Polaris because we wanted to bring in more dimensions, and we wanted to extend the time horizon of our forecast, and not keep it just 12 months. I believe that's the answer to your question for the first part, that, yes, it was a classic hyper-model in the past. Now it is a Polaris model. If you were to think about the size, it's lower than the hyper-model size now. So, how the data is stored in Polaris is different in classic, and you can change it up a little bit to bring your model size down. That's the value. The second part of your question, how did we manage the performance, I think a large aspect of it is we worked very closely with Anaplan operational excellence group when we were adopting Polaris, because Polaris, while it is still Anaplan, it had certain different areas that we were not educated on, so we learned some of those things.  

 

Ankesh Tyagi 0:26:39.6: 

We learned that a bullion is stored differently versus here, versus here. If we store it differently, we will save a space. So we worked as a partnership when we went live, and now we feel much more comfortable in those details. It has been working well. Initially, we had some challenges, but Anaplan has truly stayed committed to improving the platform, doing faster releases, and we see much more predictable performance now. 

 

Wes Green 0:27:13.4: 

Hi. Wes Green with Adobe. We are also in the FP&A space, and quite along the same timeline as you all, and I'm wondering if you have any tips to help communicate to some of our external teams on metrics and unlocks, like hard, concrete metrics that you've gained by implementing so much connected planning. 

 

Ankesh Tyagi 0:27:38.7: 

We are starting to realize that benefit now, given we are becoming more and more connected. First of all, the easiest, very apparent benefit, is once the planning is done by different teams, the final submissions are practically a button-press. That revenue forecasting happens and they press a button, and it's sandwiched to the corporate model. Those are very low-hanging fruit from a connected planning perspective. From a metrics' standpoint, I will just extend on this example. If corporate [?finance 0:28:18.7] is looking at the revenue forecast and trying to understand the growth rates, etc., now they can look at a view within Anaplan themselves, rather than chasing a revenue analyst on a different team trying to get an answer what happened and why it is happening. So those are some operational gains, and from a KPI standpoint on the GDM side, given we have built the territory, we have built the headcount, we are starting to look at some metrics that Denise actually alluded to, coverage metrics, and some other metrics related to what percentage of our revenue is new versus existing, and that sort of lens is now coming in within the platform. Some of this was happening outside in a bespoke manner from sequel tables and some differently-done charts. Now it can happen more coherently in one place. 

 

[?Lindsey Facto] 0:29:32.3: 

Hi. I'm Lindsey Facto with Nike FP&A. You have mentioned utilizing ML as input into Anaplan, and then feeding data back out. I was wondering if you could elaborate a little bit more, like maybe through a practical example of how you've used both machine-learning or other advanced analytics with Anaplan in the planning process. 

 

Ankesh Tyagi 0:29:57.4: 

We have a forecast. In very simple terms, we have time series models that are used for our revenue forecasting at a different hierarchical time series. It's for forecasting our top customers at different cuts, by region, by different dimensions that I mentioned, and an ML model can only give you as much based on your past data, so we bring that forecast in, and think about it being 12 or 13-dimensional output that you need to look at. We take this output of this machine-learning model, put it in Anaplan, look at it in 248 charts, spread across ten analysts trying to figure out whether the trends are making sense or not, and then work closely with data science and say, 'Time series forecasting for these cuts do not make sense. What is the context going behind the model going up or down and breaking out of trend?' We also use some industry-level data, like Moody's, and some other macroeconomic data, because our customer base is practically all over the industries, and all of that comes together and acts as a feedback loop into each other to improve the forecast, but it is very candidly so. It's a very challenging problem. You are in some smaller way trying to forecast worst GDP, like, how well will the economy do? It's just a smaller portion of that. 

 

David Meyer 0:31:51.5: 

David Meyer with AWS. Here, 248 charts, 10 to 12 dimensions, that's a lot of dimensions. I get nervous thinking when I put a model with five or six dimensions in it. I'm curious, as you've had conversations with the business building out these models, assembling modules with these dimensions, if you have conversations around, do you really need 10 to 12 modules? Are these hard requirements? What does your business process look like that is demanding this level of technical rigor? Was there a point where they asked for 20 dimensions? How have you handled those conversations? 

 

Ankesh Tyagi 0:32:34.3: 

That's a really good question. Yes, when I heard the first time we need to look at our revenue for cash by 14 dimensions, that was my first question. Are you really managing your business at those cuts? If not, those are not dimensions, those are maybe unique to report on that, or do something else, but you don't need to forecast that, because you are not - the purpose of forecast is to change or improve behavior, and to be able to do that, those cuts should be meaningful. If no one is responsible for that cut that forecast is as good as garbage. If no one is held responsible, what good does it do? At Stripe, I think it's a mix of things at Stripe, growing truly at a good pace, and initially, at least, even now, one of our primary products brings the bulk of our revenue, and as it grows, the willingness to analyze it by different cuts has increased a lot, and different leaders have come in to manage those cuts. I think 14 was an answer, but actually it was not that, less a fewer as well, it was just 12 dimensions, where actually leaders are looking at it, so we couldn't cut it down further. However, I think some time in the near future, if we continue to grow, maybe we will need to break it out and say, 'These dimensions make more sense for product A, and this makes more sense for a subsection of this product.' That's how I see it evolving, because if it just keeps growing and you try to analyze it in one place, it's not scalable.  

 

Audience 0:34:28.9: 

[Applause]