Taimur Abdaal, CEO and co-founder of Causal, on the future of the "better spreadsheet"

So now we have lots of different settings on charts and it’s not the easiest thing to use. And now that BI is becoming more important, we're starting to build more of a coherent framework or set of abstractions for visualizing data that's still really flexible. That's an area where we didn't do too much upfront thinking, but we initially got things pretty good on the rest of the product.

The "better spreadsheet" category that Airtable created has given us some interesting up-and-coming startups like Causal, Attio, Equals, Row, Clay and more. How have you seen the evolution of this category and what's its future look like? What's worked / what hasn't?

There's definitely lots of interesting stuff in the space. I've personally used Attio and Clay a bunch, I was actually using Clay today for some stuff, and I think they're really strong. Where we've seen a lot of horizontal tools struggle—horizontal general spreadsheet type tools, spreadsheet with some bells and whistles let's say—there's been a bunch of those over the years that have come and gone or started with that and pivoted. 

A lot of them struggle to find an initial core use case or core market that they can sell to, and reach some kind of escape velocity and actually generate some revenue, get some customers, and then build out from there. Equals seems to be executing well within the traditional spreadsheet paradigm. They have some nice bells and whistles on top, like dashboards and data connections. But now, it seems like there's a bunch of other companies doing the same thing, very high-performance, browser-based spreadsheets with direct integrations into data warehouses and stuff like that.

I don't really know how it'll play out, I don't know too much about the go-to-market for these companies or what use cases they're focusing on. But for example, I know Attio is very much focused on the CRM type of use case. Clay is focused very much on outbound prospecting and data enrichment types of use cases. I tend to be more optimistic about slightly more narrow tools. It’s a lot easier to just do anything. 

If we hadn't found FP&A as this focus to get us off the ground, maybe we wouldn't exist right now. All of these tools, they have to find some initial market to start off with. Maybe Airtable is a counterexample—I know they’ve always catered to this long tail of random stuff that you have to do—so I might be wrong. It's easier to imagine the Attio's and the Clay's doing really well, it's harder to see or predict how it'll play out among the handful of browser-based spreadsheets with data connections and stuff like that.

When we talked 2 years ago, you said you considered Causal to be a horizontal tool with FP&A as the first go-to-market use case. What's your view on that today?

That pretty much holds, and what you said is basically correct. We're still mostly in the FP&A stage of our journey, but we're starting to do BI as well and general reporting. One of the main learnings for us over the last 12 months has been that the market for what I call BI—or just reporting—is probably 10 times bigger than the market for financial modeling or financial planning. 

Basically every company needs to report on their numbers—the crucial thing is that at any point in the year, any company will need to be reporting on their numbers—whether it's the ARR reporting, whether it's their burn and runway or that kind of stuff. But the planning and the modeling for these smaller companies tends to be a lot more cyclical, where maybe once or twice a year they're going to rebuild their model or set up a budget or something like that.

One of the things we hear a lot from users is like, ‘oh, this looks great, next quarter or six months from now I'm going to need to build our model and then I'll use Causal.’ 

We're starting to now think about, okay, how can reporting be the landing use case where no matter what time of year someone signs up, they could become a Causal customer for reporting, and then maybe six months down the line, they need to build a model, or they need to build a budget, and then they can expand their contract to do some of the more planning type stuff.

On the product end, what goes into shifting Causal into a BI tool as well as an FP&A tool? You talked about how the primitives mostly work, but I'm curious about any other detail you might have there.

It kind of depends on the data source. People who use us as a BI tool on top of their data warehouses, we can pretty much do everything they need. For example, you can replace Metabase with Causal for that. Right now, it's not packaged in a way that it would be really obvious how to do that. 

If you are a Causal power user, you'll understand, ‘oh, okay, I could actually move my Metabase stuff over.’ But if you don't already know how Causal works, it won't be obvious. A lot of the move into BI for us would just be about packaging the same concepts and having the right on-ramps to get started quickly.

For example, right now, you can connect to your Snowflake or whatever data warehouse tool, we don't have a great SQL editor with syntax highlighting and auto-complete—we don't have that kind of stuff—so you’d have to just paste your query (that you've probably built somewhere else) and then you can pull the data in. A lot of the BI stuff is more about packaging things and providing smooth entry points to get started. 

Then also for other data sources, particularly for things like Stripe, things like Salesforce, HubSpot, what we've had to do is basically build very opinionated data integration. For example, next week we're launching our Stripe integration, and we've basically been working with about 20 of our own customers over the last couple of months to connect to their Stripe accounts, figure out how to turn that raw Stripe data into MRR numbers and all the kind of SaaS metrics and so on. 

That's just about us having a lot of domain logic to understand, ‘hey, these are the metrics people care about pulling from Stripe or from Salesforce. This is how people want to calculate them. These are the million edge cases depending on how someone set up their Stripe account for their Salesforce that we have to handle.’ That's just about really just a million paper cuts to gather the domain logic of those.

Last time you broke down the FP&A space into 3 categories: (1) tools built on Excel or Google Sheets (2) vertical FP&A tools and (3) horizontal tools and you slotted Causal into bucket 3. How has the market evolved since we last talked?

That's broadly still true. One thing that might’ve changed is that I feel like FP&A is becoming a slightly broader category than before. Now it's a bigger umbrella, it includes some stuff that rev ops teams might've historically done, it includes some planning and reporting that HR teams might've historically done, but that's broadly still true.

The other way that we think about the market, and we've touched on this as well, is the different segments that people are focusing on. 

One clear pattern is that most of the non-horizontal tools are very much focused on the mid-market, with a view to moving into the enterprise. We used to be doing that as well, but we're now moving down market. 

Since Pry and Finmark got acquired, I don't think there's any other sort of SMB or self-serve type of FP&A tool focusing on these smaller companies. I'm hoping that we can look back in a few years and say that this was some genius contrarian move from us. We'll have to see how things pan out. That's the other way to slice things.

I wanted to go back to something you said at the beginning about larger companies using Causal alongside the rest of their finance stack to do more complex modeling. I'd love to understand that workflow better. What tools are they using around Causal and what does it unlock that those tools don't? I'd also love to understand what the smaller customers you're focusing on are using? Is there anything besides QuickBooks and Xero, and what are they able to do that smaller companies aren’t able to do without Causal?

For the bigger companies, a lot of them already have some kind of enterprise planning tool. The most common one we've seen is Adaptive Planning, it's owned by Workday. There's another one called Anaplan. There's a few of these different tools and there's a few different pieces to every company's financial model or budget or plan. You'll have some plan for your headcount, you'll have some plan for your operating expenses, things like how much you're going to spend on software and travel and all that kind of stuff. Then you'll have a plan for your revenue, ‘hey, we're actually going to grow our top line.’

Now, the first two pieces, the headcount side and the operating expenses side, those are typically very similar across all companies and every company plans headcount in roughly the same way. You have a list of planned hires in different departments, blah, blah, blah. You're not doing anything too bespoke there. 

Same with operating expenses. Software, you might have a list of vendors that you're going to buy. For travel you might say, ‘hey, we do $100 per head per month.’ Every company is broadly using the same methodologies to plan and to budget for their headcount and their operating expenses. That's what the enterprise planning tools are very good at, often you need lots of layers of approval, lots of levels of detail, lots of hierarchies within the org of teams and sub-teams and so on—and they do that really well.

Now the revenue side, every business works very differently in terms of how to generate revenue and how they forecast this stuff. That's where you need something super flexible where you can do really complex stuff on the modeling side of things. 

For example, B2C companies often need to do cohort based modeling to see how their cohorts churn out over time and use that to forecast things. Companies often operate in lots of different geographies and stuff like that. That's where the enterprise planning tools are a lot weaker.

I would bet that every customer of Adaptive or Anaplan is still using a bunch of Excel and Google Sheets files to do the revenue side. What they do is they copy the output from that, and paste it into their Adaptive or Anaplan system just to get the budget in there. But those systems aren't really that flexible for writing formulas and building these kinds of models. 

That's why Causal is really good. That's the workflow for them, it's like, ‘hey, the more templated stuff we'll do in the tool and then the really custom revenue stuff we'll do in Causal and then transfer it over.’ So that's part one.

With regards to the modern finance stack that we're seeing among the smaller companies that we're focusing on, QuickBooks and Xero are basically the main players on the accounting side. QuickBooks seems to dominate in the US, ad Xero is a bit more popular in the UK and in Australia and New Zealand. 

In the last year or two, there have been a bunch of people who are now building new accounting systems, there's one called Puzzle that actually we integrate with. There's a couple of others as well. It’s very early days for all of these, so we'd hesitate to really recommend or tell people, ‘hey, you should use one of these new things instead of QuickBooks.’ But it's a very interesting space. There's definitely a bunch of companies to be built there. QuickBooks and Xero have dominated for a very, very long time, and it's hard to imagine them really innovating. I'm sure three years from now, if we chat again, there will be some next gen accounting system that actually a lot of people are starting to use. So that's the accounting side.

The other key pieces for people doing financial planning, are the payroll and the headcount side of their business, and there's a bunch of different HR tools like BambooHR and things like that. We're starting to see that a Deel is quite popular. A lot of people started using Deel just for international payroll or contractors and things like that. They actually don't have an HRIS built in. They can do payroll in any country. So Deel is very popular and that connects to Causal and a few other ones.

Then most people are using Ramp, something like a Ramp or a Brex for expense management. Pretty much everyone is using Stripe for payments, but it seems like Paddle is becoming more popular. A lot of people just sort of start on Stripe by default, but they don't realize that actually Stripe doesn't handle a lot of things that you need to do, managing sales taxes in every country that you have a customer in. Paddle, it seems to be a good player there, and we're starting to see some smaller companies using Paddle.

What have the key drivers of automation of the finance backoffice been? Does it happen at a specific layer, e.g., at the expense management layer or the book keeping layer or is it happening throughout the stack? Where is the most time being saved today?

Expense management and the bookkeeping associated with it, that’s where the biggest amount of automation has happened, because it's the most frequent activity that you have to do. 

Every day, multiple times a day there's going to be people buying stuff on corporate cards or the company paying for software vendors and stuff like that. And it's the kind of thing where automatic tagging and categorizing and just better administration tools can make a massive difference. That's saving the most time. 

Obviously, we try to save people a bunch of time by connecting directly into their accounting system or into the CRM or into Stripe. That typically saves people a few hours a month, or a couple of days a month depending on their workflow. The more administrative tasks like bookkeeping and tagging and categorizing, that's where automation has been the biggest.

A bunch of FP&A tools were founded circa 2019 including Runway, Pry, Digits and Finmark. Since we talked, Brex bought Pry, and Bill.com bought Finmark. How has consolidation affected FP&A? Do you see power in bundling FP&A with an expense management or bill pay product versus as a standalone company?

There definitely does seem to be some consolidation going on in the back office. Particularly for the HR tools, it seems like all-in-one HR tools are the direction things are moving in. Rippling has definitely been pushing that, and Deel is now trying to be this all-in-one HR plus payroll, etc. The thing about FP&A tools—and I might just be biased and maybe everyone thinks this about their own product category—but I feel like FP&A tools are complex in a way that, for example, a bill pay or an expense management tool isn't. It's hard to imagine a general back office, CFO office company, say like Ramp, from a product perspective it's hard to imagine them deciding to build an FP&A tool in-house, it would almost just be a completely separate thing that plugs into the rest of their products and data sources.

A company like Ramp would have a great distribution advantage and can do a lot of cross-selling if they, for example, acquired some FP&A company under their umbrella or had some kind of deep partnership with some sort of FP&A tool. But it's hard to imagine someone building that as the next product from bill pay or expense management.

I don't know how it's working out for Brex and Bill.com with their acquisitions, maybe going well, may not be going well. The acquisition route is how Workday did it as well. Workday had all this HR and finance type software and then they acquired Adaptive Planning, which is this behemoth planning tool. It’s hard to imagine someone that didn't start off in FP&A building a genuinely good FP&A product. It's very different type of product.

Causal hasn't launched an AI copilot or other AI features. What AI products, if any, are on the Causal roadmap and how do you see the value-add of AI for FP&A?

Our involvement with AI has mostly been about trying to reduce the time to value of the product. Now we have this flow where you can connect to your accounting system, our AI wizard then basically looks at your accounting data, your chart of accounts, your structure, and generates a V1 of your financial model with a runway forecast and some of the main metrics you care about. That's been pretty good for us, it's way faster than it was before if you're an early stage company just wanting to get set up with your first model in Causal. 

The other area where it could be a game changer is if you want to import an existing model from Excel or Google Sheets. A lot of our prospects, a lot of our customers, have existing financial models or existing budgets in spreadsheets, and they want to use Causal, but they want to rebuild what they already have in Causal as the starting point. When we started the company in 2019, all of our investors would give us this generic advice or something, but say, ‘oh, if there was a way you could just upload your existing model and you guys just turn that into Causal, that would be really good for onboarding.’ 

At the time we dismissed it as like, ‘dude, that's a whole separate product. We'd just be building this importing product.’ Whereas, now with LLMs, it might actually be 100x easier to build an importing process like that. That's actually something on our roadmap for the next few months, we're hoping to get something like that up and running.

There's going to be other general stuff. Copilot that helps you write formulas is a bit of a no-brainer, and Copilot that helps you make charts and things like that. But the things that are a bit more unique to us are that onboarding piece and that import piece.

Causal executed a high profile programmatic SEO strategy using AI generated content. What did you learn from that experience?

Ok, so I think this was in November or something. We accidentally had our five minutes of fame as part of this Twitter thread that it seemed like everyone was commenting on. I think Emmett Shear—in the two days he was CEO of OpenAI—also retweeted or commented on it or something.

Basically, the story behind this is that in the earlier days of Causal, we had a friend who was doing some part-time marketing stuff for us, setting up retargeting ads, setting up Google Analytics nicely, and managing a team of SEO writers who were writing blog posts. This was,I think, late 2020 into early 2021, maybe something like that. One experiment that he did was basically to see if GPT-3—which was actually in private beta at the time—could write some SEO content that can actually rank on Google.

The company was five or six people at the time, we were just going to market, we thought, ‘okay, there’s this idea. It could be kind of interesting.’ He got something together and generated a bunch of these SEO pages using GPT-3, and then we just kind of forgot about it. We were growing the business building product, etc., we weren't focusing on the SEO thing at all. And then after a few months, we started to see quite a big spike in our traffic, it was very exponential. 

We thought, ‘okay, this is kind of cool. This is kind of funny.’ We're still busy just focusing on the product and actually doing sales and that kind of stuff. From what we could see, we weren't getting tons of leads from this. It wasn't high quality traffic.

Again, it was just this random experiment in the corner of the company that was just kind of chugging along. Occasionally, we'd get a message from someone saying, ‘oh, I noticed a mistake in this article,’ and then we'd go and correct it. We did have the sense of like, ‘okay, yeah, there's probably a bunch of mistakes in a bunch of these articles,’ but it was very hard to prioritize going through and fixing this or whatever. We kind of just left this in the corner of the business, sort of chugging along.

Look, overall, it was kind of an experiment that just got a bit out of hand. It wasn't a major strategy of ours, and we weren't trying to—it did not really lead to the kind of signups or the kind of leads that we wanted. I think if we could go back, we just wouldn't have done the experiment. The average state of SEO is kind of slimy and dishonorable, in terms of how people approach it, and the AI stuff combined with that is very much, generally in the slimy and dishonorable category. I think it's much better to invest in genuinely good content written by real experts about topics, which is what we started to do now as we start to grow top of funnel. It was kind of this crazy thing that happened. It wasn't a big focus of ours. It was just this thing that we had going on the side.

If everything goes right for Causal over the next 5 years, what does Causal become and how is the world changed?

Our goal, if things go well in the next five years, is for Causal to almost become the other half of something like Notion, where Notion is the centralized place for creating and organizing anything to do with text and documents in a business (we use it that way), we want to build Causal into becoming the centralized way to create and organize anything to do with numbers and data in your business. That includes the spreadsheet stuff, it includes the BI stuff. 

I think we've done a good job on the spreadsheet half of that so far, and BI is the next frontier that we're going to be focusing on.

AI will probably shake things up. I don't think I'm a very good visionary in terms of being able to predict or think about, well, ‘this is what's going to happen as a result of AI,’ or something. Aside from the basic stuff that everyone's already thinking about like AI, natural language, to SQL or writing some natural language and getting some spreadsheet formulas or something. 

It’s easy to imagine AI working within the current paradigms of spreadsheets and BI. I don't know if AI will spawn some new paradigm of working with numbers on a computer, just some new kind of tool that we just haven't seen before. It's possible. But I think if I were a betting man, I would bet that we'd still have the current paradigms, just a bit supercharged with AI.

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.