The Data Stack Show - 155: Bringing Innovation to Enterprise Resource Planning with Emilie Schario of Turbine

Episode Date: September 13, 2023

Highlights from this week’s conversation include:Emilie’s background and journey in data (3:42)The problem of three-way match (8:56)Operational workflows and how data stacks solve them (13:16)Turbine’s solution as a lightweight ERP (14:05)Workflows and analytics (14:59)Consolidating information into helpful application (27:41)Challenges in operational workflows (32:19)Friction and hurdles in ERP usage (39:28)A solution for purchase order management (40:47)Turbine’s focus and limitations (45:26)Building a software that gets out of the way (52:51)Final thoughts and takeaways (54:25)The Data Stack Show is a weekly podcast powered by RudderStack, the CDP for developers. Each week we’ll talk to data engineers, analysts, and data scientists about their experience around building and maintaining data infrastructure, delivering data and data products, and driving better outcomes across their businesses with data.RudderStack helps businesses make the most out of their customer data while ensuring data privacy and security. To learn more about RudderStack visit rudderstack.com.

Welcome to the Data Stack Show. Each week we explore the world of data by talking to the people shaping its future. You'll learn about new data technology and trends and how data teams and processes are run at top companies. The Data Stack Show is brought to you by Rudderstack, the CDP for developers. You can learn more at rudderstack.com. Welcome back to the Data Stack Show. Kostas, we don't always get to have people back on, even when we plan to do that. But Emily's actually been a guest on the show before. She was head of data at Netlify. She was at GitLab previous to that. And then she spent some

time at Amplify Ventures doing all sorts of data stuff. So just really deep experience built. I think we had an entire episode based on the team structure that she implemented at Netlify because it was just incredible to see how their data team operated. And she started her own company. And what I'm really excited about is that Turbine, the company that she founded, deals with a space that we really haven't touched on a ton, which is sort of like the accounting inventory physical product side of the data stack. And this is an area that we've hit on a couple of times, but really we haven't covered it in earnest. And generally the tools that are used there are sort of the enterprise like erp type solutions

which anyone who knows what that means you know might shudder a little bit because from a data perspective and from an integration perspective it's pretty much brutal you know if you've ever dealt with it but what i want to do is have emily i mean she knows the modern data stack better than anyone and she decided to found a company focused on the ERP, which is sort of what most people would classify as legacy. And so I want to understand

from her perspective, what is the ERP and why is she trying to solve a problem in that particular space? And I think we'll learn a lot about accounting and inventory data as well. Yeah, 100 hundred percent, Eric. I think we are going to hear some very interesting insights from here.

We will definitely talk about the technology and why she ended up building a company around like ERPs, although she's coming, let's say, from the data space. But I really want to talk with her about ERPs. And the reason is because as a market has been around for a very long time, like ERPs are like very old concept. It's not something new. But it's been a very long time since we had someone trying to disrupt this space. Yeah.

And it's a huge market. So I really want to get both into like the technical side of things and discuss like a little bit about that, but hopefully spend more time in the business and the opportunity and the product space and try to understand what it means and why today is a good time to go and try to compete with Oracle. Right. Well, if you can be with Oracle and win, then you win. So let's go figure out how Emily's trying to do that. Emily, welcome back to the show. It's so exciting to have repeat guests.

And you were on quite some time back. And we're so excited to have you back on. Thanks, Eric. It feels like yesterday and also a million years ago at the same time. It really does, doesn't it actually? It's crazy how that happens. Yeah, years fly by. Okay, give us the background. So actually, maybe we start with like, what were you doing last time you were on the show? I think I was at Amplify last. I had just left Netlify. You had just left Netlify, you were at Amplify. I think that's right. So I was head of data at Netlify where I led all of the data org and a bunch of different people there who were really talented, some of whom you've had on the show in other capacities,

which is great. And then I left Netlify and I joined Amplify as a data strategist in residence. Yep. then I left Netlify and I joined Amplify as a data strategist in residence. And there I got to work with companies across the Amplify portfolio in a couple of different roles. So helping companies inside and outside of the data space with their strategic reporting and how they thought about metrics, helping them adopt weekly business reviews or monthly business reviews, depending on the stage of the business, and helping companies in the data space by reacting to marketing copy, to positioning. You know, as head of data for many of them, I was their target buyer.

So I got to react and work with them on things that made sense or didn't land and be that first line of reaction for them. It was a really great learning experience for me because what I really got out of the experience was this opportunity to connect with a number of founders in different stages of career and experience, but all of whom had identified a problem and got out to solve it based on their experience. And in a lot of ways, I got to follow in their footsteps. Very cool. Man, that sounds fun. Okay. But the big news is that you started your own company. I did.

Tell us, first of all, how did that happen? Like, how did you, like, see the opportunity and then what led up to it? And then tell us what your company does. One thing I've come to appreciate over time is the value of seeing patterns over and over. We talk about this in data all the time, where whenever you're looking at a data set, like one of the first things you do is run summary statistics, because that's going to give you the chance to see, does this make sense? Where do I want to dig in? What are the things that don't look like they should, right? What's not on a normal distribution curve? Things like that. And what I got from working with a lot of companies in a short window over the time that I was working with the Amplify portfolio was the chance to essentially validate the ideas that I

had about patterns in the industry that had come from my prior experience. This manifested into a lot of different things, including like a blog post that's on the Amplify blog around for B2B SaaS companies, here's how you should measure your funnel. Here are the metrics for at different stages that you should be reporting on for your board meetings and just internally for companies. And one of the patterns that I saw over and over was that there's a use case for data tools that are oriented around or rooted in batch-based processing that are backwards looking. And then there's a different subset of tooling around operational workflows where data tools can try to solve the problem, but the people, the technology, all of that is, they're rooted in different systems. And what I found when I started digging into these problems, so three-way match being one of them, and we can

talk about what that is, is that companies feel like they have no other option but turning to spreadsheets to solve that, which is fine. Spreadsheets is better than nothing. But spreadsheets have their own set of problems, right? There's no version control. There's not like granular permissions. It's, you know, editor or not. not doing three-way match, doing it in a spreadsheet, or trying to get it reconciled once a month in a legacy system. It just wasn't working. So three-way match. Yeah. Tell us what three-way match is because that's a term that's unfamiliar to some of our listeners. Definitely. So three-way match is if you think about like your favorite shoe company, they're making leather shoes, maybe in the US, maybe abroad. They decide they need a thousand more shoes. So they're going to cut a purchase order to their supplier. The supplier is going to ship them the shoes, whether it's like on freight

or by air, whatever it might be. Those shoes land in a warehouse where they need to be received. And then they have to pay the supplier via an invoice. So there's a PO number for the purchase order. They arrive. Then someone needs a remit payment for like that PO number. Exactly. And so the three and three way match is the purchase order, the invoice and the receipt reconciling. Yeah, that's just and just to clarify, the shoes are just on a crate in the warehouse like that. Oh, yeah, that's We're not talking about selling anything yet. Right. Well, I mean, to the end consumer, there's been a transaction. But yeah, we're just talking about the shoes are in a crate in the warehouse. And so we have a three-way match

just between the manufacturer and the manufacturer in terms of supply chain and then the brand. Exactly. And I had seen this problem a couple of times, kind of became a little obsessed with it. And then when I was in business school, I read this article that from HBR that was like the only problem, the only solution to our three-way match problem is crypto. And I was just like, what? I mean, you know, independent of how you feel about crypto and whatnot, like, hopefully we can all agree that blockchain is just a distributed database. And if a distributed database can do it, why can't a regular database, right? So that was the original like inkling of there's something here, there's a thread I want to keep pulling. And I first said, cool, let's build this with the data stack and tried to piece together, you know, a data warehouse and some accounting integrations and proof of concept to make this

work in that system. And what I found was the timing mattered. So much of the way the data warehouse, the way the modern data stack operates today is still batch based. And what we're seeing, especially in large companies, is that like batch only scales to a certain point. And, you know, if you're getting an invoice for shoes because the supplier thinks they've been delivered, but you're not seeing that they're delivered, but payment is due on receipt. There's all these reasons where batch or any sort of lag didn't work in this particular case. If we were going to solve three-way match, we had to solve it in a way that like actually solved it, not in a way that just created new problems. And so lots of things about the data infrastructure didn't work.

And, you know, I saw it in three-way match and I could pull on my other prior career experiences and see that same pattern. So when I worked at Smile Direct Club, which is a straight teeth company, we had at the time the BI tool we were using was Periscope, which is now like Sisense for cloud data teams or some other name. But I remember our customer support team, the way we interacted with them was through this Periscope dashboard, like a customer health dashboard, right? A customer would call in, they'd say, what's your order number? They'd enter the order number and the dashboard would update. Yep. Pretty, I think, typical workflow, right? But because everything was

batch-based, almost consistently, we saw that if you had just placed an order 15 minutes ago, your data wasn't in the system. And so now here's customer support saying, I'm sorry, we can't find your data. I'm seeing the charge on my credit card. What do you mean? And so there's a subset of problems in the business, these operational workflows where the data stack has been the best tool to date, right? Like having that dashboard was better than not having that dashboard. But just because everything, just because we have a hammer in the data stack does not mean that every problem is a nail. Yeah, I love that.

Okay, so tell us about Turbine. So what is, so this is the, at least we see the tip of the iceberg of the problem, but so how does Turbine solve it? Yeah, so Turbine is the lightweight ERP for companies that manage physical inventories. Love it. Okay, let's dig into a couple things here. So I'm going to go, I'm going to rewind a little bit and ask a couple of questions.

So one is you, there's a, we know you well enough now on the show to know that you don't, you're not flipping with your words. So operational is a very buzzword-y term in the data stack space, and it's most often attached to analytics, but you use the term operational workflows. Can you describe the difference? And my guess is that it has to do with the dashboard versus some other data process. But can you describe the difference there? Because my sense is that that was an intentional phrase. Definitely. So if you work at any company that's managing inventory, there's this category of people who have operations in their job title. And you can think of them as get shit done-ers.

Can I say that on the podcast? Of course. So, you know, these are the people who are just doing whatever the problem in front of them around getting inventory in, getting the problem, getting the customers problem solved, getting inventory to the customers. And ops is a loaded term. Definitely. Sure. People like the ambiguity.

Some people don't like the ambiguity. Reprocess inside of a company. Yeah. But when we think about driving operational workflows, I think of it as not just passing information around. If you think of a sales ops or a marketing ops or a web ops org, almost always that's just these are the people who are responsible for integrating our tooling. Yeah. Moving information into a place where someone can make a better decision. Exactly. And when we talk about operational workflows, we're thinking about it in terms of what are the things that you need to do to get your job done? So things like cutting a purchase order to a supplier, knowing the right amount to cut based on what you've already negotiated, based on when you're going to run out of inventory, based on the lead time. Things like cutting a manufacturing work order so that taking the raw inventory that you've already got and turning it into finished goods and inventory that you can sell to your customers. It's digging into problems in your supply chain with late shipments, right? Like

so much of what data and analytics does is making it really easy to do the work in the trenches day in and day out makes total sense okay next question and i'm this is like terminology definition i guess is what i'm doing here but let's talk so that was super helpful and i love that like the difference between sort of summarizing views or decision-making based on what's happening versus we have pallets of things that are coming in and out of warehouses and people need to understand how to do their job in terms of managing inventory makes total sense. You mentioned ERP. Can we talk about that term? So Costas and Brooks, correct me if I'm wrong. I don't know if we've

actually discussed ERPs sort of as like platforms on the show yet. So this is very exciting because we love talking about things that we haven't covered in detail before. My guess is that a lot of our listeners are probably downstream consumers of ERP data, right? Like you're getting a load from some sort of ERP system, especially those that are familiar with any sort of company that deals with physical items. But just to level set us, what is an ERP? Can you just give us like the three minute, like 101 on an ERP? Because in terms of operational workflows, I think that's a really important concept. Great question. The first thing, an ERP is an enterprise resource planning tool, or most often you'll hear people say enterprise resource planning system.

That's what ERP stands for. And there is a couple of ways to think about the ERP. It is meant to be the system of record for a company. This idea that everything that happens in an organization goes through the ERP. The ERP market to date has been traditionally dominated by legacy players that are old, clunky, difficult to use. We won't drop any names here, but people don't talk about ERPs on Twitter as a category of software they love. And so when we say ERP, we recognize that there are many things

that people expect from an ERP. But I would broadly put them into two categories if we're going to make it really simple for people who don't know what an ERP is. The first is around accounting. So if you think about the life cycle of a business, they usually start on like a QuickBooks when it comes to accounting.

And then at some point, they reach start on like a QuickBooks when it comes to accounting. And then at some point, they reach too much accounting complexity. Could be for any number of reasons, but too many foreign subsidiaries, too much currency changes, whatever it might be. And they move to a more advanced system. And that is oftentimes a point in which they'll move to an ERP. The other workflow that people expect from their ERP is around supply chain. And the running joke that we hear and tell with our customers is that your ERP is supply chain software that your CFO makes you use because, yeah, it's supply chain software that your CFO makes you use because it's financial and accounting technology first and supply chain

second. And with Turbine, we've actually shifted that where we're focusing on serving the supply chain really well and integrating with accounting so far. Totally makes sense. I love that. I'm still laughing about the CFO comment, but anyone who's been close to it knows. Can we talk about the term lightweight? So use a lightweight ERP. And again, I think anyone who's been a downstream consumer of ERP data coming into any sort of data store that you have to layer into analytics, you probably feel the weight of your words, Emily, that this tends to be enterprise, tends to be clunky, tends to be sort of difficult. Why is that? And why, you know,

in this world of the modern data stack where we have, you know, separation of storage and compute and all these amazing, you know, sort of modeling tools and everything, why is the ERP still heavyweight with all the incumbents? And I mean, just from my limited experience, most of the companies are still using these heavyweight tools. Many companies feel there's no alternative, unfortunately, to the dominant players. It's just like, oh, well, at some point you're going to bring in XYZ ERP that you've always heard of. You know, the question is just at what stage. Yeah, yeah, yeah. always heard of. You know, the question is just at what stage. Yeah. When we think about lightweight, there's a couple of ways that we try to live that out at Turbine. The first is around implementation.

So if you go asking people who have been around an ERP implementation what that looks like, they'll tell you like nine months to two years, depending on the size of the organization. And we have had 100% success rate with implementing in less than 45 days for our customers. So when we mean lightweight, we mean like, we want the software to serve your business instead of, you know, get stuck in this implementation window. Sorry to interrupt, but is that displacing other or is that net new? So these are mostly people who are switching

from other mid-market options or moving from spreadsheets. So not displacing these legacy systems. Okay, got it. That's still really fast though. Thank you. Yeah. And then, so that's kind of the first way we think about lightweight. The next part is really in terms of the software.

So an analogy that I like to use when it comes to ERPs is that like you get a cruise ship of features, right? It does a million different things. Yeah. Really, all you needed was a sailboat, right? It does a million different things. Really, all you needed was a sailboat, right? You need to get from point A to point B effectively. You need to send the purchase order. You need to do the three-way match reconciliation. You need to track your freight shipments as it's coming to you. You don't need to know your grandmother's uncle's cousin's widow's birthday. And sometimes it just feels like an ERP does so much more than

you need. And it can be overwhelming and confusing to users. So that's number two. And then number three is like lightweight in almost synonymous with delightful. And so one of the things we did when we were first getting started was a lot of customer discovery, right? Talking to people who have these problems, who are looking to get started, who are struggling with the pain points of existing market options. And one thing we found out, perhaps unsurprisingly, is that our power user is an Excel power user. They're very comfortable with keyboard shortcuts. And so one thing that we shipped early on was actually keyboard shortcuts to get around the app.

And what we see is our customers love that. When I can say, don't worry about memorizing that hierarchy of the nav bar, you can just command K and start typing the name of the page you're looking for and that will take you there. It's lightweight in that we're not implementing a bunch of, well, this is how it is software to you.

We're giving you software that is actually driving you forward. Yep. Love it. In terms of product direction, one question I have is what kind of drives, where do you decide where to trim? Like when you say lightweight, so when we talk about inventory and accounting, those in my mind are sort of the key things, right? Like if you screw those up, then nothing works, right? But it seems like a lot of the additional cruft

comes from like also trying to be a CRM and like a place where, you know, deal with all your customer records and all this sort of stuff, right? But help us understand where do you decide to trim things so that it can be lightweight without sacrificing sort of the core components? We spend a lot of time talking to customers. I mean it, like, right? Like they, we talk to people who are struggling, who are have these problems day in and day out. I'll tell you one person will call her Tracy just for ease of discussion. But Tracy, when we were first getting started,

I emailed Tracy all the time. And what would And what her job was for a long time, she would come into work in the morning and she's head of ops at a mid-market company, $10 million in revenue. She'd start her day by wanting to orient herself to what happened yesterday. So the first thing she'd do is log into Shopify and see how much they sold. And then she'd log into Amazon Seller Central and see how much they sold. And then because of some weird nuances on how Shopify orders are handled, that didn't always translate directly to changes in inventory. So the next thing she'd do is go log into another system to see what changes happened to inventory, what numbers were low, what needed to happen. So now it's 9.30 a.m.

We've already logged into three apps just to get data and no decisions or useful things have happened yet. But she also wants to know the status of her open purchase orders and freight shipments, or if there's been any communication from her suppliers. So she would log into the system that they use to that. So by 10 a.m., she's now logged into four or five different apps, not done anything useful, just orienting herself to what happened the day before. And one of the ways that we have been useful to her just like right away is that we were able to consolidate all that information into a single application. systems. We have support for most of the major retailers or different commerce platforms. We can consolidate all of that information in one place. So now instead of chasing information in a bunch of different systems, we've consolidated into a single view for the entire end-to-end supply

chain for her. Love it. Okay, I've been dominating the conversation as I normally do the first half. That's just, I think, how the show goes. So I probably need to stop saying that. I have one more question and then I'll hand it off to Casas. I can't help but ask, how many Tracys are out there

who don't even have the benefit of logging into Shopify and who are actually doing a lot of things on paper, I would have to think that there are a lot of people working in a warehouse who are getting purchase orders and everything, and you sort of manage it in even more antiquated systems or manually entering things into ERPs. Is that, I mean, to me, that seems like just a gigantic market. they check off or adjust on and then they go sit at a desk and manually input it. And, you know, just moving those people from that to an iPad can make a world of a difference. If you've got software that's built for that, if you can manage permissions and you have audit logs and all those sort that sort of functionality, it can really make a difference. I think that's definitely an opportunity.

There is a hurdle to people who have always done it this way, right? And so it is easier to convince someone who's using spreadsheets the power of an app than it is to convince someone who's still stuck on their paper and clipboard. And so there's a little bit of a tricky balance to strike there. But what we find over and over is like, we just have to give you a ton of value. If we can make your life so much better that adopting Turbine is a no-brainer. That's where we win. Emily, I have many questions about ERPs, but before we get there, I want to go back to something that you said at the beginning. You described your attempt to solve the problem with the typical, let's say, like data stack,

right? With like data warehouses, detailing data around, and all that stuff. And you mentioned that one of the problems when you are working, like, in operations is, I mean, if we can use, like, the technical term, would be, like, latency, right? Like, how fast we can actually process the data from the moment that the data is generated at the source

until the point where we can act upon this data, right? And of course, okay, data warehouses traditionally were like built for reporting, batching. I mean, we're talking about like hours or days, and we are still okay with that, right? But my question, and the question arises from my experience with, let's say, a data stack. Outside of latency, what other problems

the data stack can bring, as it is today, when you try to solve these operational problems? Because I have a feeling that just as latency, probably there are other things that are not that obvious, but might be pretty dangerous, right? So I'd love to hear from you, like what other problems someone can face by, let's say, trying to solve the problem with like the modern data stack or any data stack.

So two come to mind. The first is around accounting principles and double entry bookkeeping. We can talk about that second. The second is this principle of the way we handle testing in the modern data stack is so often what I would call after-the-fact testing, right? If we think about, to use a pretty common example that I think most people will be familiar with, DBT tests, right? The very principle of ELT is you get the data in the warehouse

and then do your transformation and then test your transformation at the end, right? And what happens if your tests are working really well is they will catch the problems in the data. Hey, you've got a purchase order with a foreign key to a vendor that doesn't exist. But when we handle these in operational systems, it's like, no, you can't cut a purchase order

to a vendor that doesn't exist. And that's a very different approach to data quality, data integrity. And that's a luxury that we get in the data stack because we're not being used for operational workflows. And when we said, like, we're going to be operational workflows, Turbine is going to solve operational problems. We can't risk that sort of integrity. So that's number one. And then number two is around accounting.

And when you have to be careful when you talk about accounting, because if you get too technical, people's eyes glaze over like double entry bookkeeping and they just like go to blanks place. But so double entry bookkeeping has formed the basis of accounting for like 600 years. And accounting itself is like even way older than that. There's this meme. I can find it and even send it to you if you want to add it to the show notes but it's like of a ancient tablet like literally stone and in this tablet is this carved writing where someone's complaining about the quality of grain he got because he had ordered grain from some other vendor and And so double entry bookkeeping, supplier relationships goes back to, you know, the beginning of days. When it comes to

double entry bookkeeping, there are lots of articles online that are, you know, how to do double entry bookkeeping with Postgres or how to make a ledger out of some fancy database. But there are tools today that are built for that. There is a whole category of ledger technology, not in the blockchain sense, but in the Tiger Beetle fragment modern treasury sense that is purpose-built for double-entry bookkeeping and those principles. And the way that the data stack, the modern data stack, doesn't lean into those sort of referential integrity requirements, the way that there are better built or better purpose-built tools out there for accounting makes it not the best tool for the job if we're being super candid, you know. And I think one of the things that I would call out is

probably the last time I was on here, I would have said, yeah, the data stack can handle every problem you throw at it. And one thing I'd push people to do is, as we recognize the value of the technology, the things that our software can, any piece of technology, any piece of software can do for the business, we should also spend time reflecting on where it falls down and what it can't do and not try to shove square pegs in round holes because that's what we see in front of us. I want to ask you something about what you said. You mentioned like purpose-built solutions, right? You mentioned Tiger Beetle and other solutions out there.

And these are solutions that they are solving the problem, let's say, on what I would call the foundational layer, right? It's going to make sure that things that might happen on the hardware level are not going to affect, like, for example, your transaction, right? And things that you don't want to know about, like no accountant wants to know about how ECC memory works or you need... Concurrency and transaction writing.

Yes, exactly. But at the same time, right, like you have this part that's all like from the technology with these systems. On the other side, there's something that you mentioned before, which has to do with like the experience that the user has, right? Like you have someone who knows very well how to use Excel. They know very well like the semantics of the business itself. And they have like tools that they've've been using all these years, right?

Taking them and asking them, for example, okay, I'll give you a prompt to a SQL database and now you can go and execute queries there. It might be very expressive, but at the same time, I don't think that this is going to make them more productive, right? And what I want to ask you is, we can get more into technical details of Tiger Bittles out there, but what I'd love to hear from you is the user experience part, right? What it means to go to these people that they are doing like a very stressful job because they have to act now that's

why they're called like operations right and give them tools that not only promise like efficiency but also deliver efficiency right and you have talked with many customers so what does this mean like what does it mean to build like a solution like that on top of data? Because that's exactly what accounting is, right? Like it's data, like working with data. But for this particular group of people. I frame it as building software that's working for you and not against you. And that seems so simple. You'd think like, why would anyone buy software that's working against you? But

so much of the existing options out there are clunky, difficult to use, and just don't have the ergonomics that people expect of SaaS nowadays. One of the phrases that I remember hearing early on before I'd even quit my job in doing these conversations with people about building or about how they use their ERP, one of the phrases that came up over and over was just, it requires too much clicking to do anything. And I think about that all the time

where it's like, how much must that clicking, must that friction be creating a hurdle for you? That's the thing that comes to mind when people ask you how you feel about your ERP. So I say that because that's where i think about it most directly is we're building software that's trying to make you better more efficient giving tracy 30 minutes 40 minutes back in her day you know that's piece of it yeah that great. Can you give us like a few examples, like even one example, like from all the conversations that you've had so far with your customers and like users, like things that as a person coming from the data world, like the data infrastructure world, that you were surprised by the way that like these people were doing their work.

We have a customer where, prior to using Turbine, each person on the ops team owned the relationship with the vendor directly. And so they would cut a purchase order, and those purchase orders weren't logged anywhere. And so there was no like internal system with the list of purchase orders or how much had been ordered or when it was coming in or when it would be expected in or how much you promised to spend. And what they found was it was just easier rather than trying to remind people to consistently cc an email address or add it to some spreadsheet or whatever. And with Turbine, instead, they were able to just use Turbine to cut purchase orders for them. So you could still own the relationship with your supplier, but you cut the purchase order in Turbine and send the email through Turbine. So, your supplier still gets the information you need. You're still managing your products. There's just also a log of what was ordered, what's been committed, what's been spent, what's coming in. And that level of visibility gives, you know,

everyone across that level of the business additional information. It also gives people in other parts of the business additional information, right? So now finance can plan for cash flow management in a slightly different capacity. The FP&A person can forecast and consider what's already coming in the forecast when we think about ordering more. That data can be combined with things like impending purchase orders to, or impending orders to large retailers to decide what else needs to be ordered. So there's a lot of pieces that come to play, come into play when you can just give people accurate information in a timely fashion to do their job. And for us, you would think like, oh, just establishing a

system around cutting purchase orders. That doesn't seem like that big of a deal. But if you've always just sent an email and that seems to be working, companies wait until things are almost too broken to fix them and they swing too far into the process piece. This is where again, lightweight comes in that we want to be just enough process for what you need, but not too much that you feel like you just implemented an ERP. Yeah. Yeah. A hundred percent.

So speaking about ERPs, it's okay. Like the term ERP is quite old, right? Like it's been around like for around for a very long time. And the industry has been building ERP also for a very long time. And one of the promises, what Gartner, I think, came up with a term, if I remember correctly, of the ERP as a category is that it should be, let's say, the operating system of the company, right, of the enterprise.

Now, that sounds like amazing in theory. In practice, and I think like anyone who has tried to build from a small team to a company, they know that each company is like a human being. It's different.

So it's really hard to go and create abstractions in software, right? That they can be applied from a manufacturing line somewhere in Germany where cars are built down to someone who's building software, right? And I think that was also, at least in the past, one of the reasons that these projects were starting always with a lot of hope, and then they took even years to implement in some cases, and the software became so clunky and so complicated, right? So how do you see this situation can be reversed, right? Like, how do you think that, like, Turbine can disrupt this problematic situation with this clunky software, huge complexity, and actually deliver, let's say, the vision and the dream of what an ERP should be, right?

Absolutely. If you look at the innovation in the ERP category over the last 40 years, it really mimics what you're saying. So we have these category of legacy generalized players where there hasn't been much innovation. And we have these very domain-specific ERPs where there's been a ton of innovation. So whether it's in education, whether it's in car parts, there are these single vertical ERPs that do what they do exceptionally well. And that's where the technology has gotten better over the last 40 years. When we think about turbine, I think it's true that you have to solve one problem really well

before you can kind of go out and solve them all. And my vision is certainly to go out and solve them all. But today we're focused on companies with physical inventories. The piece that we don't say about that, you know, when I give you the soundbite or the elevator pitch is like, I don't include, but I really don't want to work with companies that have a cold chain right now. Cold chain, which is refrigerated supply chain, has its own category of complexities that you have to solve. And I don't think the product is there yet or we're ready for that yet.

And so I think as a early stage founder, part of my responsibility to my customers, to my company, is to be honest with myself about where our own limitations are and who we can serve and who we can't. So a trap that a lot of early stage companies fall into is just saying yes to anyone who will give them money and being distracted by those things. Whereas if you were just a little bit more willing to say, no, that doesn't serve our purpose. It's not in our ICP. We wasted time there. You can have a much more effective strategy for building and growing the product and the company. Now, there's also the reality of sometimes you got to do what you got to do to pay your bills, right? Sometimes you got to do to bring money in the door and get you to whatever the next milestone is. And so there's definitely a trade-off there. But staying focused on your

customer, on your ICP, and what problems you can solve, will be able to solve, are interested in solving, are all super core to how we go from here to the vision. And the way I talk about it with my team is that, you know, we've got this huge, big vision. We didn't even get into touch the iceberg on in this conversation. But one thing I've been really focused on is, okay okay we know what our short-term roadmap looks like we know what the big vision is there's a dot in between and the more I can clarify for myself for the team what's in that dot the more effective we can be at serving our customers and at serving our customers really well. I love that.

Makes total sense. And I think it's also great advice, not just to founders, but I think to anyone who is trying to build something. All right. One last question before I give the microphone back to Eric. So, okay. We talked about let's say the issues that someone encounters when they try to like to use like a data stack to solve this problem and the need to

have like a new type of like ERP system out there. My question is, assuming all these things, what is the relationship between this new generation of ERPs and the data stack, right? Like the data infrastructure that a company has. How do you see these two technologies coexist and amplify each other in the future. When I worked at GitLab, I wrote this blog post on the three stages of analysis. That you start with reporting, and I called reporting toll paying, right?

This is how, this is just reporting on sales pipeline. Yeah, you could do it in Salesforce. It's terribly painful. So let's just do it in the BI tool. And then the next phase is insights. And this is where you take data from multiple systems and combine them. And an example that I think I used in the blog post is actually around user retention. The customer information is coming from your CRM, Salesforce, whatever it might be. An example that I think I used in the blog post is actually around user retention, right?

The customer information is coming from your CRM, Salesforce, whatever it might be. And then your usage data is coming from a snowplow or rudder stack or whatever it might be. And that combination of information gives you new insights into the business that could not come from any other system. And I think of Turbine as being the same in a lot of ways. So you are still going to want to combine your supply chain financial operations data with your usage analytics or with your CRM data or with your manufacturing quality system or whatever it might be. And so there's still a place for the data stack. It's just allowing companies to go from requiring that reporting level of information to letting everyone be more impactful by giving them the chance to go directly to insights.

Makes total sense. All right, Eric, the microphone is yours again. All right. Man, this has been fascinating. I love that we cover these sorts of broad subjects on the show. My question is actually maybe more, I guess you could classify this under personal or

sort of like your personal journey, but you've led data teams and been involved in data teams in multiple different contexts, advise data teams. And now you're leading a company that's building software that deals with data. And so I know we're close to the end, but maybe what are one of the top one or two things that are really different about being a leader who's running a company who has to deliver software that deals with data as opposed to being someone who is delivering data products inside of a company using a lot of other people's software? That's a good question. It's so hard. And I don't know that I've gotten the chance to sit back and reflect in a way that gives a really satisfying answer.

How about this? Let me ask you this. What do you enjoy about leading a company that's building a data product as opposed to just sort of getting your hands dirty in the data every day? Like what's most enjoyable to you about that? I really love talking to my customers. And my data point every day, the data points that I collect aren't ones and zeros and spreadsheets. It's when Nicole, who I met with this morning at one of our customers, can say, here's my workflow, here's the pain point. Like that is the data point is that conversation. And a couple of years ago, it was trendy to talk about how data teams need to think about combining with like qualitative UX teams and explore how we can combine like

quantitative data analytics with qualitative UX. And today, all of my data is qualitative, right? It's the conversations that I have with customers, with prospects, with our ICP, with intros, with people who understand this space, with people who have worked in this space for decades. There's a lot of ways that data pops its head into my work. It's just a very different kind of data where I know the row level information personally, instead of just looking at it in aggregates. Yeah, I love it. Well, Emily, always such a pleasure to have you on the show. Think about the question that I answered,

the first version of the question, and we'll have you back on for round number three. And we can start out with that one. That sounds great. Thanks so much for having me. I really appreciate it. Costas, what a fascinating conversation with Emily from Turbine. She's been on the show before, you know, GitLab, Netlify, Amplify Ventures, just knows the modern data stack better than anyone.

And it's amazing that she's going after the ERP space. I mean, you know, what do you think about when you think about ERP? Because I think about really gnarly ETL jobs and like transformations is what I think about because it's just like, you know, the APIs are horrible.

The schemas are horrible. The data types. I mean, just the amount of data type work that you have to do is insane. Yeah. I don't know, Eric. I think you might be surprised about what

is the first thing that comes to my mind when we are talking about ERPs. For me, it's mainly lawyers and very complicated contracts in order to just go and do a demo and the pilot with a customer because they are using... Oh, right. Because you actually built batch load jobs for ERP. Yeah. I mean, can we say names or the legal teams of these names can go after? I guess that probably is not like a bad idea for the popularity over there.

So, so yeah, it was NetSuite and for the customer like to do the demo, they needed to make sure that legally they are covered. So there was a lot of back and forth with the legal team to make sure that they were getting into problems with Oracle. Yeah, yeah. It's super interesting. I think one of the most fascinating things to me was, you know, this is really interesting because we talk about data so much on the show. We talk about data products and the way they interact with data, the way they solve problems around data. This was really interesting to me.

And I think a really good, I'm going to think about this a lot over the next couple of weeks. Emily probably knows more about data and data products than most people we've had on the show, right? Just in terms of the breadth, right? Like, of her experience. And when we dug in with her

on the problem that they were solving in the ERP space, she described it actually as a function of software getting out of the way of the user, right? She didn't actually, I mean, we did discuss data and we discussed some of the peculiarities of accounting and inventory data,

which is a very difficult problem and why incumbent ERPs that are these heavyweight, crafty tools still exist. But she kept going back to the customer. I mean, we kept harping on that and she just kept saying, I'm just talking to our customers and I'm asking how their ERP is getting in the way of them doing their job. And we're just building a tool that gets out of their way so they can do their job better. And like, sure, it's accounting data, it's inventory data, like their purchase orders. These are very challenging things, but she didn't, for her, it was actually pretty simple. Like, well, how do you go challenge the big incumbent ERPs? Like you just build software that gets out of the customer's way

as they're trying to do their job. And that was so refreshing. Yeah. And I think very, I think it actually is expressive of someone who's a very good leader and who can understand how to build what will become like truly great software one day yeah 100 i think like at the end no matter like what you are building like from i don't know like boring software that keeps notes for one person to going like building

rockets like at the end like if if you want like to succeed, you need to follow like these basic principle of talking to the customer and trying like to figure out how to build something better for the customer. We just keep forgetting that, like especially in tech, like many times we think that like, okay, if I come up with a new technology, that's all it takes. And actually, it's interesting because we've had this conversation with here before the actual recording about blockchain and ledgers. And that's exactly what happened there. We thought that, oh, if come up like with this new crypto technology and we expose all

this complexity out there it's so important and fascinating that like people will just like go and adopt it and at the end it didn't work like that right doesn't mean that like crypto cannot solve the problem it can solve the problem and maybe better, I don't know. Right. But the way the industry approached the problem was wrong. Like technology at the end is like just a tool, right? You need to go and do what Emily is doing. Listen, and again, and again, and again, and obsess with finding like the right solution for your specific customer. So I would suggest to anyone to go and listen to the episodes.

It doesn't matter if you're a founder or you're leading a team or you're building something anywhere. I think keeping that principle in mind is super, super important. And we can all learn from here. 100% agree. Well, thanks for listening. Really great episode. Check it out if you haven't.

Subscribe if you haven't. Wherever you get your podcasts, tell a friend. And we'll catch you on the next one. We hope you enjoyed this episode of the Data Stack Show. Be sure to subscribe on your favorite podcast app to get notified about new episodes every week. We'd also love your feedback. You can email me, ericdodds, at eric at datastackshow.com. That's E-R-I-C at datastackshow.com. The show is brought to you by Rudderstack, the CDP for developers. Learn how to build a CDP on your data warehouse at rudderstack.com.