Taimur Abdaal, CEO of Causal, on the primitives of financial modelling

One of our customers is actually an engineering team and they built a model in Causal to figure out how they should allocate their cloud spend. In trying to decide if they should go with Google Cloud or AWS, they created different parameters, requirements, and pricing for various kinds of products on both systems. By building that model out in Causal, they ended up changing the decision they were otherwise going to make. This saved them about a 100K a year on their cloud bill.

So, engineering, marketing teams, and particularly, performance marketing teams that are spending money on ads, need to undertake considerable modeling and forecasting to figure out how many leads they can expect to get if they deploy X dollars across these channels with these conversion and click through rates. Can they achieve their goal? It’s a lot of forecasting. 

Sales teams also need to forecast their pipeline and calculate commissions for sales personnel amongst other things which we hadn't really known until people just started signing up for the product and using it.

How much of a focus on FP&A is there with the core product today?

We still see Causal as a horizontal product and that's what we want to do with it long-term. At the beginning of last year, we really started going-to-market and actually just focusing on the FP&A use case. So, a lot of our messaging on the website was probably quite focused around FP&A. We just wanted to ensure that if an FP&A person came across the website, they’d take it seriously. Simultaneously, we don’t intend to put the self-serve people off thinking this is an enterprise FP&A tool because it is still very general. 

There's probably a lot of stuff we need to figure out in terms of messaging and positioning but our ambition is definitely to be a horizontal tool. We do have loads of users outside of FP&A and while basically all our revenue today comes from FP&A and that's probably going to be one of the biggest use cases going forward, we don't want to be pigeonholed into just finance.

Causal is unique as a product amongst other spreadsheet-like tools. From a product vision perspective, how did the idea for Causal take shape?

The initial idea for Causal was almost an aesthetic intuition emerging from the fact that we didn't think cells and cell references were the right building blocks for working with numbers on a computer. We had this pretty strong intuition that there was a better set of building blocks out there for doing very flexible, general, numerical work. 

Being perfectly honest, we were pretty naive when we started and didn't have any particular use case in mind. We didn’t know if mid-market FP&A teams would love this and in fact, we didn't even know that the acronym FP&A existed at the time! 

Causal started off in the same way that a lot of these very general tools start as and it took us about a year and a half of iterating to actually understand that mid-market FP&A was a great use case. 

We think Causal is something slightly more abstract than cells and cell references. In fact, it's somewhere between spreadsheets and programming, so you build models and by using what we call variables, you add more levels of detail to them. These levels are called categories and that’s how we started.

You mentioned three issues with Google Sheets and Excel models—the crazy references, the disconnection, and then, the lack of ability to present. How did you think about approaching those with Causal?

Our approach is different from other tools in the FP&A space. Causal is, first and foremost, a very general modeling and number crunching system—it's a very flexible modeling tool. So, anything you do in Excel in terms of number crunching, you can also do in Causal given the way we let you structure your models and handle formulas.

The first thing that we built was this modeling piece that eliminated cells and cell references and replaced them with our own building blocks — ”variables” (similar to programming).

Once we had that layer, it was easy to add the right bells and whistles on top including data integrations, dash-board functionality, version control, and permissions. 

No two companies or financial models look the same. So if you’re building just an FP&A tool, you do need to ensure it's completely general and flexible, so people can encode their business in your tool. That’s key. Part of the beauty of Excel and Google Sheets is that there's nothing you can't do in there. Any company that's considering an FP&A tool needs to be confident that they can build their model in the tool, even if it’s something really crazy or custom that literally no one else is doing.

This flexible modelling system is what we started with, and what we thing is the hard bit to figure out. A lot of the other companies in the space, however, took the opposite approach. They started with what we consider to be more low-hanging fruit— data integrations, for example. Once they pulled data in, they visualized it across charts, tables, and dashboards and got to the modeling piece last.

I think the modeling piece is the hardest, and it will be tough to almost retrofit this completely general modeling system into a tool that already has data integrations amongst other things. 

Our approach was definitely painful for the first year and a half since there were lots of iterations but now, we have a really great foundation where it's very easy for us to extend this. That might be a challenge for other tools in this space.

What comes to mind seeing folk in finance talk about Excel, which is so fundamental to a lot of people's world-view, is how they approach work. From your experience in finance or as a data scientist, how do you see and think about getting folk off Excel. Is that a challenging hurdle?

It's challenging for different types of people. 

In those early days of Causal before we started focusing on FP&A as a core use case, we were talking to everyone—investment banks, private equity firms, consulting firms etc. One of the main reasons that we didn't go with any of those kinds of companies as our initial market was that it just seemed too hard to switch these people away from Excel, then. They'd perhaps be happy to adopt something like Causal once it already had a lot of traction and became a mature product. But they wouldn’t be the early adopters.

What we found was that at high growth companies, typically VC-backed startups, once these got to a set certain size—usually around 100 people, maybe series C-ish in terms of stage—then, the pain points of Excel actually got pretty tangible. A lot of finance teams would be spending literally one or two days every single month just pulling in data from their accounting system and data warehouse, manually comparing budgets for marketing expenses, checking the actuals, noting the differences across months. 

The data integrations and automations are where we can demonstrate very tangible ROI. Once companies get to a certain size, we can literally save them two days a month using just our data integrations and automations. Having that as a starting point makes the whole thing an easier sell.

The value of the rest of the product is very real, but harder to quantify. The way we let you build models is 4-5x faster than Excel, our readable formulas reduce the chance of human error, and the way we let people present and collaborate improves engagement and aligned across their team. It’s harder to put a dollar value on these things, but this is where we think there’s real differentiated value in Causal.

One obvious comparison that comes to mind is with Airtable and its very spreadsheet-like interface. Yours is different. Do you see a resonance there? Are there lessons learned that you would take away from Airtable?

I think Airtable's great. I'm a big fan. However, we're a little different from them in the sense that I think there's broadly two different kinds of things that people are doing in spreadsheets. 

The first is what I'd call ‘general productivity’, where you might need to make a list of things or manage some business processes or build some internal tools. Airtable’s doing an amazing job at this ‘general productivity’ set of use cases for spreadsheets. 

The other half of spreadsheets however, is really about working with numbers. It's about doing calculations, visualizing data, forecasting, and planning etc. We are really just concerned with that second bucket.

While we do have a spreadsheet interface now, that was one of the things that took way too long to figure out. We used to have an old interface that looked more like cards, where we had little blobs for each variable. I don't know if you remember that. So, people who weren't coming from Excel really liked it because it was simple and easy to get started. 

However, those that were coming from Excel just couldn't take it seriously. They’d look at it and think “There's no way my really complex 20-tab Excel model is going to be in these little blobs.” We took a year and a half to figure this out and be taken seriously by the finance people and those used to Excel. We realized we needed a similar interface to help with onboarding, for example. 

As people started building more and more complex models in Causal with hundreds of variables and multiple dimensions within them, a 2D grid of numbers seemed a pretty good way to represent that information. It took us a while to make it look like a spreadsheet. In fact, the main interface does look like that now. 

Lots of people told us from day one that it was an interesting idea but wondered why we couldn’t make it look like Excel. I think we had a lot of ego caught up in things at the time so our response was that we were trying to replace Excel; we weren’t a spreadsheet. There may have been a bit of emotional attachment that lingered too long there, but now, we do have a spreadsheet in place.

Let’s tap into your expertise on how teams use Excel and spreadsheets. How does Google Sheets fit in? Is it a solution for some of the early issues with Excel? How do you see that?

I think Google Sheets is great. I still use Google Sheets almost every day for something or the other even if it’s just making lists of things.

The problems that Google Sheets solve on top of Excel revolve around collaboration, where it’s much easier to share a live file with someone. You don't need to send them an updated version because it enables version control plus live sharing. 

What it doesn't solve, however, is everything that results from the wrong set of abstractions of having cell and cell references. Formulae in Google Sheets are no more readable than in Excel nor is it easier to pull in elements from data sources and automate components around that. Visualization is still a challenge.

What’s your take on bringing data into Causal and processing it there? What’s different besides using extensions to bring that into sheets or whatever people can hack around?

The way data integrations work in Causal is that we don't really see Causal as a data processing tool. We pull in the data in a very niche and structured format, so the main data sources that finance teams care about are the accounting system or the ERP. 

QuickBooks, Xero, NetSuite for example, are very structured systems and we know what we're getting from there. There's not much post-processing that needs to be done. Financial models of companies also typically bring in operational data, maybe from a data warehouse like Snowflake, maybe CRMs like Salesforce. 

We don't really manipulate that data once it's in Causal. What we do though is map that data into Causal’s abstractions. We have a concept called variables here. If you're a business, one of your variables might be revenue. That might be a single variable in Causal that has your revenue across different months of your financial model backward-looking and forward-looking. We can look at an accounting system that has an account code like 6,000–revenue, for example, and make it really easy for you to tell Causal that the 6,000 item from that accounting system maps to this revenue variable in Causal. Then, Causal knows which months have which values.

Once you have something mapped at the variable level, Causal can also understand extra levels of detail. Typically, in accounting systems, you might have something broken down by departments, so, there may be certain expenses coded for each department separately. You can create what we call a category in Causal with your different departments. Once that information flows through the accounting system, Causal knows how to turn those expenses broken down into multiple departments into variables and categories within it. 

We don't really post-process the data, we just know how to transform it into Causal's building blocks. That means that in a couple of clicks, you can connect your model to live actuals. Every month, you can hit refresh to pull in the latest numbers. You don't have to roll your formulae forward to say this number has now come in. You can start your formulae from the subsequent month.

We automate all of that and you can save different versions—a budget version at the start of the year, for instance, that you want to constantly compare against and track. We can also automatically enable those comparisons so you can see the actuals, the difference etc. All you have to do is just hit a button every month to do that.

You mentioned Series C or the 100 employee mark being a sweet spot. As companies scale past that, do you see Causal being a good example of modeling? Is there perhaps a natural break point where folk are looking to get a dedicated platform or this specific vertical use case?

Since most of the FP&A aspect of things ends up being quite custom for each company—and they will have very similar custom revenue and expense models—there's a need for very custom bits. We do typically see that companies, even as they go to IPO and beyond, need a really flexible modeling tool for the revenue and the expenses sides. Today, there are specific vertical tools for headcount planning, for instance, that just make that process really easy. Some companies have started using headcount planning tools like ChartHop. 

These are things that Causal would be able to integrate with to pull that data in. But for the core revenue and expense models, you can't have a tool with two verticals. It needs to have that full flexibility. So right now, series-C is our sweet spot, around 100-500 employees. We do have much smaller companies using Causal as well but for lots of different things. We have companies post IPO using Causal, too. We do scale up and down from that sweet spot, but it’s the 100-500 person, series-C-ish companies who we try and target, specifically.

Tell us a little about the dynamic of expanding within organizations for more use cases. With Airtable, we’d covered the idea that it may be replaced with a vertical-specific tool down the road. But in the time that it took to get there, many other use cases emerged enterprise-wide, so folk kept it. What’s it like for Causal? How many different purposes can folks use it for?

We see expansion happening in two different ways. 

The first is, when the finance team moves their FP&A models and plans into Causal. Typically, a couple of people on the FP&A team will go about building and editing these models and setting up the dashboards. They will want to share different parts of the model with perhaps 5, 10, or 20 others. Now, the CEO might be concerned with just a certain set of metrics or perhaps a high-level chart while the head of marketing might have their own view within Causal that sits on top of the financial model where they just look at the metrics. This pattern of a couple of people producing and subsequently, a group of different people consuming their own custom views on top of that is one way that we see Causal spreading within an organization.

In terms of other people finding different use cases, this isn't something that we've seen too much of going from FP&A outwards. But it's actually something that we've seen considerably moving in the other direction where maybe a marketing team starts using Causal for much simpler models and forecasts for the marketing side of things, and then, someone on the FP&A team or the finance team sees it and we upsell them. It could also be that the CEO is just building some small forecast for themselves and then, he sends it to the finance team. 

We see the use cases spreading more from other teams into FP&A now but hopefully, as we mature and grow, we'll also see it moving in the opposite direction.

Are there any metrics or numbers around product market fit that you can share?

At the moment, we have two sides to the business. 

The top down B2B side where we sell annual contracts between $18K and $36K a year typically, has about 70 customers. These are the FP&A teams at these mid-market companies. 

Broader than that, we have a few thousand monthly active, self-serve users engaging with the product for different things.

Are you seeing a self-serve to pay motion emerging or do folk in companies use it and then graduate to pay?

We've started seeing that a few of the companies who were early adopters of Causal—in 2021 or even in 2020—have grown and now have finance and other teams. Out of those 70, maybe five or six have been upgrades from self-serve users. 

The self-serve side of things hasn't really been a focus for us for the past 12-14 months as we've been going-to-market. However, going forward, I think that's really how we win in the medium- to long-term, even just within the FP&A vertical. There's a lot of low hanging aspects that we can cater to, to really convert those self-serve users eventually into paying and enterprise customers.

One thing we've noticed is that there are several FP&A startups now. Pry and Runway are the two big ones. Do you have a take on why so many folk are starting FP&A?

It does seem that almost all of our competitors started around the same time in 2019. To be honest, I think it was going to happen eventually. Most people who are building technology are pretty detached from the finance side of things and while there've been leaps and bounds in terms of the progress of tools and systems that engineers and designers have because they are the people actually building this stuff, the finance function, the office of the CFO, has just lagged behind. That’s because most programmers and designers just aren't exposed to that. 

It was inevitable that eventually things would catch up and people would start building better tools for finance though why it all happened in 2019, I actually don't know. But that does seem to be how it turned out.

What’s your opinion on where this technological transformation of the CFO’s office is going? What are some of the major trends you foresee?

Within the office of the CFO, there are a couple of things that are really clear. 

The first thing is that finance teams are moving away from being backward-looking. They are becoming much more strategic and proactive about helping people around the business make better decisions around strategy. 

The other part of that is finance teams don't want this information to be just siloed within them. They want heads of departments and other teams to engage with and contribute to this thinking, planning, and decision making process. 

Those are the two big trends that we're seeing where going forward, FP&A will almost become a bit of a misnomer because actually every team will be doing some FP&A while the actual finance team probably brings it all together. 

There's also going to be considerable automation which means that finance teams will eliminate manual activity that takes a few days every month and spend that time more proactively. That’s the shift we’re seeing in the office of the CFO. 

On the product side, the shift we’re really bullish on is that there's a big disconnect in the different tools that people use to work with numbers. There are BI tools like Looker and Tableau which take historical data or backward-looking numbers and let you visualize and slice and dice it. The point of looking at the historical numbers is to make decisions about the future, but since you can’t write formulae in Looker and Tableau, you can’t really use them for forecasting or planning. You then need a completely different tool, typically a spreadsheet, for all the formulae, forecasts, and projections.

We see people trying to do one job, which is using numbers to make better business decisions. But there are these two very disconnected tools—BI tools for backward-looking elements and spreadsheets for the forward-looking ones. 

What we're trying to do with Causal and what we've started seeing is that a lot of customers view Causal as a merging of these two worlds. It’s this all-in-one tool for everything backward-looking and then, forward-looking as well. Many of our customers are actually just using us as a BI tool that connects into their finance system without requiring much modeling or forecasting. They’re just visualizing things. However, when they do need to engage in that forward-looking activity and generate scenarios, we have that functionality as well. Our long-term vision is to really be this very all-in-one tool for anything to do with numbers—backward-looking, forward-looking—and to really blur the boundaries between what people currently see as BI versus multi.

Do you see the data warehouse becoming more central to the org or do you touch the data warehouse in a typical implementation?

We definitely touch the data warehouse for business enterprise customers. Usually, once they get to that 100 person mark, in addition to wanting to automate their finance stuff, they also start implementing a data warehouse and thinking about BI tools. Many of our enterprise customers integrate Causal with their data warehouse to pull in operational data, like cohort data for different customers and usage etc. All this won't live in a finance or an accounting system, so, we do touch that a lot.

It seems people are becoming more entrenched in the data warehouse concept so I don't really see that going away anytime soon. I think it's a good concept, a single source of truth for all the numbers in a business. However, for some reason, most companies don't actually consider their financial data as part of that. Most people then have the data warehouse for everything but their financial data. For that though, they'll have NetSuite or QuickBooks which is a little strange. Some of the more forward-thinking companies that we work with actually put their financial data in the data warehouse as well.

Is there anything else that you feel we've missed and that you'd want to talk about?

In terms of how we view the FP&A space, there's three different buckets of tools right now. 

The first comprises tools built on top of Excel or Google Sheets. So, there are DataRails, Cube, and Vena. These let you use your existing Excel or Google Sheet models while they sit on top with extensions, plugins, and extra functionality like data integrations or dashboards. That's one approach. 

The other approach comprises vertical FP&A tools like Mosaic and Pigment which are just for FP&A and finance teams to manage their workflows and do a little bit of modeling. However, finance teams are less focused on the modeling side of things, so, that's the second bucket.

We see ourselves in a third bucket, which is completely horizontal. Causal’s a very general tool for working with numbers, so we’re in the same ballpark as Excel and Google Sheets in that sense. The challenge that the spreadsheet extension tools face is that it's very hard to build a great product experience when you still have the underlying issues of a spreadsheet and stuff bolted onto that. That’s why we didn’t take that approach. 

The challenge of the vertical FP&A approach is that you're serving the FP&A team, but they will actually eventually need a completely flexible modeling tool. You might as well be horizontal at that point. 

Given that, we've taken this third way of being a completely general system in which there’s nothing you can’t do. Now we have to figure out how to position it for the FP&A and once that’s done, we must see how to position it for the next use case, the next customer type and so on.

Will you go deeper into vertical FP&A and build more for that specific use case or will you mostly focus on being horizontal?

From what we're seeing, in terms of product feature requests and the direction that we're getting pulled in by focusing on FP&A, it's actually pretty general stuff. There's nothing that people are requesting that is really specific to finance teams that wouldn't be valuable for other people in the business. 

One example of what we recently built is that once companies get to a certain size in the annual budgeting process, the annual planning process requires the finance team to request inputs from different departments. These inputs are along the lines of what their expected software spend or their headcount plan for the year may be amongst other things.

They want ways to be able to take their financial model, share a part of it with the head of marketing, for example so they can enter some numbers, too. The finance team then wants to be able to see what marketing’s tried to change and subsequently, improve or reject it. 

On its face, this is a very finance-specific activity around the annual budgeting process, but from a product standpoint, it’s very general. It's like, they want to be able to preview changes, improve or reject them when people change their models or dashboards. Pretty much all the requests that we get seem specific to finance, but actually solve a lot of problems and that would be useful for other people as well.

Do you think about competition from Ramp and Brex who are coming at FP&A from the forward-looking version of expense management?

I don't think we really see them as moving into the space. Fundamentally, a big part of the value that Ramp and Brex provide is that they sync with your accounting system. They aren’t trying to be the source of truth for this information but are a really great way to manage it. 

We used to use Brex and now we use Ramp. We actually partner with Ramp on a few different things, so definitely don't see them encroaching into the space. We see it as quite complementary where we could connect to Ramp to pull in information if that makes sense.

Is it in the complexity of FP&A and planning where customization becomes more important? Can you illustrate what that may look like for a company?

It varies by vertical. One thing that we see is that D2C ecommerce companies actually need to do a lot more custom modeling at a much earlier stage than others. 

Last year, when we were quite early in going-to-market, we were on Facebook and mostly targeting companies that were 100+ people in size. But the first ever $2K per month deal that we signed for Causal was with a 30-person ecommerce company. We were really surprised. They were 30 people but they already had NetSuite. Normal companies don't get NetSuite that soon, so we wondered, why are they willing to pay $2,000 a month for this tool? 

The reason is that there's a lot of modeling that needs to go into D2C ecommerce companies because the economics of their business is really important. If you sell a product, you need to have a sense of the demand for this product, and therefore, you need to have this much of it in your inventory at all times. So, you need to start ordering the equipment and the parts to manufacture that three months before. 

D2C ecommerce companies undertake such modeling much earlier. In fact, consumer subscription companies, also undertake considerable modeling earlier than enterprise sales companies because unit economics is critical for them and understanding customer cohorts in particular, is key.

This transcript is for information purposes only and does not constitute advice of any type or trade recommendation and should not form the basis of any investment decision. Sacra accepts no liability for the transcript or for any errors, omissions or inaccuracies in respect of it. The views of the experts expressed in the transcript are those of the experts and they are not endorsed by, nor do they represent the opinion of Sacra. Sacra reserves all copyright, intellectual property rights in the transcript. Any modification, copying, displaying, distributing, transmitting, publishing, licensing, creating derivative works from, or selling any transcript is strictly prohibited.