Building MotherDuck to a $400M Company

Jordan Tigani is the cofounder and CEO of MotherDuck, a data warehouse platform based on open source database DuckDB. They've raised $100M in funding from amazing investors like Andreessen Horowitz, Felicis, Madrona, and Altimeter. He was previously the CPO at SingleStore and spent 11 years at Google before that. He has a degree in electrical engineering from Harvard. 

Jordan's favorite book: The Master and Margarita (Author: Mikhail Bulgakov)

(00:01) Introduction
(00:08) Founding of MotherDuck
(01:12) The Philosophy of Shipping Products at MotherDuck
(05:02) Founding Story and Identifying the Market Opportunity
(10:57) Building the First Version and Overcoming Early Challenges
(12:23) Validating Customer Needs and Asking the Right Questions
(18:24) Deciding What Features to Prioritize and Exclude
(21:30) Positioning a New Product in a Mature Market
(27:36) Overcoming Challenges in Scaling MotherDuck
(32:29) Measuring Success of New Features in Enterprise Products
(36:20) Structuring the Organization for Effective Execution
(41:09) Preparing MotherDuck for the AI Native Era
(43:28) Rapid Fire Round

--------
Where to find Jordan Tigani:

LinkedIn: https://www.linkedin.com/in/jordantigani/

--------
Where to find Prateek Joshi:

Newsletter: https://prateekjoshi.substack.com 
Website: https://prateekj.com 
LinkedIn: https://www.linkedin.com/in/prateek-joshi-91047b19 
Twitter: https://twitter.com/prateekvjoshi 

Transcript

Prateek Joshi (00:01.702)
Jordan, thank you so much for joining me today.

Jordan Tigani (00:04.898)
Thank you. Great to get a chance to chat.

Prateek Joshi (00:08.302)
Let's start with Mother Duck, the fundamentals. So for listeners who may not be familiar, can you explain what the company does?

Jordan Tigani (00:19.16)
Sure, so we build a data warehouse based on the open source DuckDB project. We're kind founded on the idea that most people don't actually have big data, or at least if they do, they only process smaller amounts of it at a time. And so kind of a different architecture makes more sense for...

for running your data. So it's a data warehouse similar to Snowflake, BigQuery, Redshift. We can do a lot of tasks that you need to analyze data, understand, ask questions of your data, ask questions of what's going on in my business. And we can be super lightweight. We can scale down. We can scale up to sort of some very large sizes. Yeah, so that's basically it.

Prateek Joshi (01:12.818)
Fantastic and Duck TV obviously has gotten a whole bunch of traction and it's well known. So I want to spend the next next section just talking about shipping. So a lot of our listeners, they're mostly built a couple of products, they're shipping but shipping with velocity and shipping quality product is always a challenge. So I want to start with what principles?

do you use or what guides your philosophy of shipping at Mother Doctor? How do you think about it?

Jordan Tigani (01:49.576)
you know, I think we try to take sort of a mix of top down and bottom up. Like there's certainly top down strategic objectives and things that, you know, we have five, three to five kind of main things that we are driving towards, kind of at all times and everything that we're doing should snap to one of those. And they, you know, they may not always be the same importance. Kind of we, we stack rank, we stack rank those. And that's sort of where this sort of a lot of the top, top down direction comes from.

And then sort of the bottom up, it's like, we have these things we'd like to do. If they fit into those, if they fit into those kind of with the priority ranking, then we will green light. There's obviously some, the lights on, table stakes, you just sort of have to do. And then the other one is that we...

try to set deadlines. And so as a, you when I was an engineer, used to hate deadlines and I used to be like, oh, well, why do we need deadlines? We should just, you know, ship it when it's in. The problem with that is like, it, you know, it leads you to sort of fiddle and sort of tweak is like to get it perfect and like,

Prateek Joshi (02:49.426)
All right.

Jordan Tigani (02:59.244)
you know, sometimes actually having some deadline pressure is really useful at being like, okay, well actually this part is not actually necessary. And you kind of, the part where you start to rip things out at the end is actually really useful as well as to, you know, it can be also helpful when you want to kind of align with the other.

other groups in an organization. So it's not just an engineering driven organization. have to like, you have to communicate to customers. have to like be able to support what you're doing. You have to be able to sort of keep it, keep it up and running and have the right playbooks for SRE. And, you know, sometimes that feels like, well, it can feel like overhead when, know, for the, from the engineering mindset of like, Hey, I, you know, I this, this thing, I know how to do it. know how to build it. I'm just going to get it out there.

And then I think as the, as the company grows, you sort of realized that like, you know, you know, if you surprise people, in your company that like you ship something, then, you know, something was, something was probably, probably wrong. And it doesn't mean you can't move fast. You can't like make quick decisions. Like, you know, Hey, for example, you know, we, had the opportunity to like, be one of the first companies in the Vercel, know, in native integration, the Vercel marketplace. That sort of meant that we had to make a bunch of.

move people around, prioritize, prioritize this thing. But the marketing team wanted to know that, this is going to be available in Brazil. We needed to have documentation and end to end and how this works and what happens if somebody has an error and connecting all the billing, all sorts of billing questions can come up. You can't make some of these decisions in a vacuum, at least after a certain point.

When you get started, sure, fine. Just sort of blast it out and get it done. anyway, it's a long answer, but think setting, tying to big strategic goals and then setting deadlines and using that to prioritize.

Prateek Joshi (05:02.354)
Right. That's amazing. Going to the early days, I'm going to founding MotherDuck. Now, Snowflake is a big company, many customers, and there are data breaks. There are so many big companies doing something in data warehousing. So in the early days, how did you identify a need or an angle of attack and what inspired the founding of MotherDuck? And also perhaps

How did that translate to V1? Meaning, hey, these are the things we need to pack it and ship to get the early customers interested.

Jordan Tigani (05:41.726)
so kind of, I've been working on, you know, data warehouses for data analytics for a dozen years. and I worked in the early, early days of BigQuery and kind of stuck with that for a decade. I was in single store for, for a couple of years. And, and one of the things that I, you know, has started to notice was just that like.

you most people didn't have huge amounts of data. Like even at BigQuery, you know, you think BigQuery, it's like giant data. And it's like, no, actually people, most people are using BigQuery because it's easy. It's just simple. It's, know, like pay as you go. Like it's, you just fire off a query and it runs. And there was something really powerful about that. And it also seemed like everybody was out chasing giant, still chasing giant data. Like, you know, the big data meme, you know, was kind of...

still what people were focusing on. And, you know, it really hit me when, you know, there was this like benchmarking war between Snowflake and Databricks and, you know, Databricks said, Hey, we have the fastest TPC DS benchmark result. And Snowflake said, no, no, no, no, we're faster. And then Databricks said, no, no, no, you're cheating. like, it was just like, you know,

You sit on the sidelines and you you can popcorn, it's like, ha ha. But one of the things that I noticed was the data size that they were using was like 100 terabytes. And so 100 terabytes is like, you know, so it's not just the total data set, but the queries that they're running are like, are close to that size. And when I was in BigQuery, we had some of the largest customers in the world. We had Walmart, HSBC, Equifax.

Home Depot, you know, giant, giant customers and nobody was running queries at that size. Literally, nobody.

Jordan Tigani (07:33.014)
And so it's like, so, wow, everybody else, like the big players are all focusing on trying to solve these hard problems at the scale that nobody has. That certainly that leaves kind of an opportunity to like, you know, cause not all the problems are solved in the, the sort of the smaller scale, the use cases and the smaller scale of data. And it's like, okay, if you were really going to focus on those customers and the people that have kind of normal size data, you know, would you build things the same way?

and would you have the same problems and what could you do differently? so noticing that, for example, networks have gotten faster, laptops have gotten faster, servers have gotten bigger. So kind of the whole reason that people build these scale-out distributed systems like BigQuery, like Snowflake, like Redshift was because the servers were small and you couldn't fit what you were doing on a single machine.

And nowadays, like the Gravitron instances on AWS are 192 cores, and I think half a terabyte of memory. And this is a commodity machine. So there are very few workloads you can't fit in that amount of hardware.

And so kind of just spending all this energy kind of to split things up and to do these, you know, build these distributed systems is sort of like, it slows you down by orders of magnitude. Like I remember in single store, like amazing engineering team. And so we built like this sort of distributed transaction stuff, like, which is really, really hard. It took probably an engineering decade to do like, you know, just several people working on it and like,

lots of moving pieces. But like the reason you have to do that is because you have all these different machines and each one can fail and replication problems and you what happens when this restarts and like on a single node system it's just so much so much easier and you can move faster. I think at the end of the day the people like that win

Jordan Tigani (09:35.058)
you know, companies that win and the technologies that win are the ones that can move fastest. And, so I really thought, Hey, there's an opportunity here to kind of build something differently, be able to move really fast. You know, we recognize duck DB kind of was, you know, this academic, you know, a couple of academics that created it. It seemed like, know, what, at the time, like what differentiates this between, you know, duck DB and some random thing somebody, somebody created to, you know, because they're, you know, to write a paper.

And one of the things that we noticed, they had a blog post about time zones. And in BigQuery, it took us like five years to actually do time zones because there's just so many really, really horrendous details and problems. like, everybody can use UTC. But the fact that they had solved this and solved this so well and had that attention to detail is like, no, this isn't just something that somebody is building to write a paper.

this is a real system and they do it right. so we've been big on DuckDB and I think that has really paid off for us. You kind of mentioned what was the, you asked what was the, what did the V0, what was the requirement that we had to build? So we really wanted to have DuckDB running in the cloud, be able to fire off a query and have it just run and like not have to worry about spinning up things, spinning down things.

Prateek Joshi (10:57.169)
you

Jordan Tigani (11:02.394)
And we also built this sort of hybrid execution system which was a little bit harder than perhaps we needed it to be, but we also wanted to make sure that like, we had a lot of intuition around.

This is going to open up a lot of doors and open up lot of potential things and make a bunch of other things easier, but also made a bunch of things harder because you couldn't just fire off an API, the query that runs in the cloud is basically we take a query plan that runs locally, we split it into pieces, we run the pieces that need to run in the cloud and the cloud, and then we synchronize. So there's some hard stuff we had to build.

It is paid off, just took a little bit longer than you otherwise would have expected.

Prateek Joshi (11:52.366)
What questions did you ask your early customers to validate the need? Because you're building a product for technical users, database, you're selling to people who are, as a developer, are just, we scrutinize more, we're more picky in our products that we choose and buy. So for somebody out there building a product for technical users and developers.

early stage founders, what can they ask? What questions can they ask to validate the need?

Jordan Tigani (12:23.438)
So I think there's actually two sides of the question. What did we ask and what can we ask? Some of the early founders and I, we were really immersed in the...

in the business and then sort of the market. And, know, I'd been product manager for BigQuery and head of product and engineering for single store. like, and kind of really like had a lot of like comparative knowledge. This is what works. This is what people are asking for. Had talked to lots and lots of customers.

so I think one of the things, you know, the, the first thesis that we needed to validate was like, you know, is this whole big data thing, important? Like, do you have big data? Who's got big, who's got big data? And so that, like, that was,

Like as we believe that if people don't have big data, then something smaller would be something that worked and was targeted at kind of the size of data that people had and could open up new opportunities for that data where it was going to be useful.

You know, I think we talked to a bunch of people, but it was less, I mean, I think there's a bunch of startups get created. you go around, you ask questions and you kind of find pain points and you kind of, you know, build something that will address those pain points. I think there's good things and bad things about that. The good thing is like, you know, if you find a hair on fire problem and you can solve that, you know, people are going to be willing to just sort of, you know.

Jordan Tigani (14:03.276)
you know, say, please take my money and, and they're willing to put up with, you know, a startup that, you know, has not, you know, doesn't have super polished technology. on the other hand, you're at the risk of like somebody else solving that problem or that problem going away. You know, sometimes that problem is in between two systems and one of those systems just sort of moves to the left a little bit. And, and it, you know, that need goes away. and it's also kind of tends to be niche as a raw, as opposed to like solving a broad category of problems.

And so, you what we're doing is we're solving sort of data warehousing problems and it's sort of like, Hey, you know, people have a data warehouse. They understand what a data warehouse is. There's budget for a data warehouse. Like there's it's not a winner take all market. you know, like people use snowflake, but not everybody uses snowflake and people, know, people use click house to people use like there's, you know, there's

People are open to new technology if it works well and is different and is differentiated and can work better in their use cases. So I think it was a little bit differently than I think a lot of when they get created. The other thing is, in just terms of asking people questions and sort of, and...

know, designing your roadmap or designing what you're building based on like the things you're asking, asking users. it's often to me, I find it's often like, you know, as the, as the product person, the CEO or the founder, you know, and talking to customers or potential potential customers, it's, you're not, you know, it's, it's, you're more like a doctor than a, I know a therapist, like you're like,

You know, you go to a doctor and you like, have a cough, like the doctor doesn't say, okay, you know, I'll give you a, you know, cough suppressant. they're like, Hey, you know, what's, what's actually going on? You've got, you've got COVID or you've got, you know,

Jordan Tigani (16:05.582)
strep throat or you've got, you they diagnose kind of what the underlying problem is rather than just sort of treating the symptoms. It's really tempting to like, to just treat symptoms and be like, hey, you have this problem. Like, all right, you go and ask me to do this and I'm to go do this. Then you ask me to do the next thing and you go do that. And what the problem is, each customer asks things in a different way. First of all, they don't always know what they really want.

they may ask you for like, you you to build something in a certain way. If you go do that, that may not actually solve their problem, but also there's a good chance it won't solve the next person's problem. And so you kind of want to dig in and you understand what's actually going on and then apply.

And then apply pattern matching, especially if you can sort of get down to like, these people have two different, these people have two different, very different problems. And when you can solve those two different problems with one thing, that to me, that's the most exciting thing when you're like, you realize that you're, you're, you're, you're onto something. You know, I think, you know, an example in, in mother duck was, you know, we, we had, you know, some people having problems, some of them were having problems with,

Jordan Tigani (17:19.758)
running larger queries and some of them were having problems using, doing certain kinds of data updates, larger updating data. And really the problem was, so the thing that they were asking for was like, instances or for the updates was like, hey, we need you to fix like the Parquet update. Really the problem was that DuckDB at the time wasn't great at.

out of core execution, which meaning sort of like there's some things you can do which sort of all are in memory and they could blow up memory. And the changes were to fix how DuckDB worked, you know, without out of core execution. So we worked with the DuckDB Labs team to like, you know, kind of make sure that that stuff, that stuff all got in and like, and so that ended up solving those problems. But the kind of the two problems that people were asking for,

necessarily the things that were related to even solving the problem. You kind of have to sort of dig in and diagnose.

Prateek Joshi (18:24.108)
When people are building like a net new product, there's a lot of information coming your way, your own experience, your earlier companies, you talked to potential customers. Now you're talking to your users, your customers. So how do you decide what

goes in and more importantly what features like what needs to stay out like what's a distraction because in the early stage if you haven't done this before get overwhelmed and you're like my god I'm gonna include all the features and hopefully something will stick so how do you more importantly how do you decide what to leave out

Jordan Tigani (18:58.782)
I think this is where setting a deadline can help. so like in the early stages, we set a couple of deadlines. were like, Hey, we like for this board meeting, we want to have a demo for this, this, you know, this, at this time, we're going to have, you know, our, our, you know, first alpha or first, you know, release where we're going to give it to customers. We wouldn't hit beta at this point. And, and that just sort of helps you because it's like, okay, I would love to add all of these things, but like,

but we can't. And it's like, and so you're, and she kind of have, have to have this sort of, this moment where you're like, I know this is important and I would feel embarrassed to not have this in it, but it won't work at all if we don't have this other thing in it. So we kind of need this thing and this is, this has got to go in and this other thing that we're going to be embarrassed about not having. Well, it only ha you know, you

you only need it in these small use cases and we can have that be a fast follow. like, and so it's just, it's a, it's sort of a time-based prioritization. You know, you kind of use, you you stack rank things, work on the things you can. There's obviously a point before which you can be like, you know, sometimes, you know, you, you just, you know, you can't, like, you can't ship something useful in, in, know, without some of these other things, but sometimes you just sort of like,

I mean, and that's helps you set up by setting deadlines. You know, it's like, well, it should take us this long. Like, like, like in three months, six months, nine months, like we should have been able to solve this problem. so like, we need to get something, we need to get something out and it sort of gives you, it can give you kind of a kick in the pants to be like, well, you know, you just, we gotta, we just gotta, gotta, gotta figure it out.

Prateek Joshi (20:52.442)
And when you are building a product like databases, obviously, they've been around for a long time, and they'll continue to be around for a long time data warehouses, some managing data that work is going to be there forever. So when you're building a product, where it's a mature market, people know what it is, and you're presenting a new thing. So how do think about positioning this when you talk to a new customer? They don't know you and

they, frankly, there are too many people fetch them. what advice do you have for people to position the thing they're building, which is new?

Jordan Tigani (21:30.186)
so it's a great question because, know, you're going into a mature market with a new product and your product is not going to have the same number of features. It's not going to be as reliable. It's not going to be, you know, as, you know, make as much sense, as, somebody else's. And so you, first of all, you have to be, you have to have some sort of differentiation. You have to have some, some like,

affirmative reason to choose the product that you're building versus what the typical one is because like, know, take it, know, it's like people used to say, you know, nobody gets fired for choosing IBM these days. It's like nobody gets fired for like choosing whatever is in AWS or, you know, if there's a standard. You can sometimes, you know, jump on the, you know,

cool tech bandwagon, you think there's a lot of tailwinds with DuckDB and people were excited with DuckDB and sort of like, hey, you know, we are the, you know, kind of the DuckDB cloud database and that, you know, that got us to, got people to, to, to pay attention. The other thing is, you know, the area of the market we went after was, was it, felt a different area of the market than other people like we're typically, you know, focusing on.

Like when I was in Google Cloud, it was enterprise, enterprise, enterprise. And the bigger the enterprise, the more we cared about it. And like Snowflake, it's clear that they're going after the giant customers that are gonna spend tens of millions of dollars or more on the product.

And it's very hard to have a focus on that and be able to say, know, okay, giant bank, going to, can give me $50 million a year. Um, like in order to win that customer, you have to be, you have to develop a lot of energy to that, to that customer. It's hard to do that. And at the same time, be like, Hey, you know, Joe, mom, pop startup, uh, I'm going to be really reactive to the things that you, that you ask for.

Jordan Tigani (23:39.414)
And so it's kind of going after the longer tail was a deliberate thing. It's not just because startups typically can do better at the long tail, but also because it allowed us to sort of get underneath where the, in the area where.

competitors weren't necessarily focusing on and didn't necessarily weren't guaranteed to have the big problem. The best product is like, know, if they're building something that's, you know, designed to work really well in enterprise, it doesn't mean that it's going to be easy to use. It doesn't are easy to set up or solve the problems of kind of the individual developer or the individual analyst or the smaller use case. As you can get in, you can start and then you kind of work your way up and they're sort of from a

strategy perspective, there's sort of like a counter positioning where, you know, it's very hard for them to be good at what they're doing, as well as be good at what you're doing. And so you can, you can basically kind of start to start to grow and come in underneath, particularly from like a pricing perspective, hey, if we can be less expensive, there's a lot of people frustrated about, about pricing, but so that's one area of differentiation that you can't just be, but you can't just like, you can't just be less expensive.

And you can't just be faster. Like I think there's the trap that I see people falling into, is, hey, we're going to be fast. Like, and the problem about that is like, is your, you kind of, your self-worth is defined in a relative value. And, and so somebody else can come along and be faster. And now you're like, well, I guess we have to figure out what we, you know,

Prateek Joshi (25:02.001)
Thank

Jordan Tigani (25:20.846)
actually we're gonna be, it's a little bit like high frequency trading. You see like high frequency trading, if you do it well, you basically can print money if you're the fastest. But if you're the second fastest, you go out of business. And so, I think it's a dangerous kind of trap to fall into. And you see a lot of people be like, hey, we're gonna be the fastest at X. Because the other thing is like fast is always,

Prateek Joshi (25:34.328)
Right.

Jordan Tigani (25:50.432)
is such a, even for something as simple as databases, like does it mean the lowest latency, good at joins, good at like dealing with low memory conditions, good at complex queries, good at like, there's just all sorts of good at lookups, good at mutations, or being able to use parquet files on S3, like there's all sorts of like variations and.

for performance and nobody's gonna be fastest at all of them because whatever architecture you choose is gonna optimize for certain types of workloads against other ones. anyway, sorry, that was a little bit of a rant, but there's something you often see. So you have to pick differentiation, you have to come up with something that's your own. And you know.

and there's also some pitfalls you can get into.

Prateek Joshi (26:50.13)
I think that's a great point because if being fast is your thing, you found a way to be fast, pretty sure somebody else is gonna find a way to be a teeny bit faster. So the thing that you're tying your hat on, it's not gonna exist anymore. So I think it's a very good point where you have to find out why you are 10x different along one dimension. So many dimensions, just pick one and be 10x just different. Nobody should be able to even.

it would be anywhere close to you. think that's a great point. Now, looking back at all these years, MotherDoc now it's a bigger company, customers, revenue, funding. What's been the biggest or most significant challenge in building MotherDoc to this stage?

Jordan Tigani (27:36.382)
you know, so I don't know how well this generalizes, but I think we did things in a different order than everybody else typically does things. And we had, you know, we were incredibly fortunate to like, you know, be in the right time, the right place with kind of the right team. You know, there was tailwinds with DuckDB. There was kind of excitement around, know,

Snowflake had been the biggest IPO in history and people are like, hey, they wanted to jump on the data bandwagon. And kind of I had been the most visible person at the most close, the closest competitor to Snowflake. And so we raised a lot of money right out of the gate. had, DuckDB was also kind of ascendant at that time. so...

you we were able to grow the team pretty quickly. so, you know, things that are hard for, you know, in a lot of startups, which is like, okay, you know, you got to build the initial V1 and, you you know, on scraps and then you kind of, and then you can hopefully raise and then you can build a couple, know, have a couple more people. You know, so.

We did things in different order. And the thing is when you do those in the traditional order, you kind of start to build up, there's muscles you start building up that can be dangerous in a company where you don't go through that sort of crucible to get to funding. Like, we had two years before we had any revenue.

You know, we had a product out, had a bunch of users, we had kind of a bunch of excitement, people knew DuckDB. But we were fortunate that we didn't have to have revenue. And so, kind of just, the hard part has been sort of like going back and making sure that we, you first of all, like, we don't take anything for granted. That's been...

Jordan Tigani (29:34.506)
incredibly important to me is that we like you can't feel like, hey, you know, we are we're flying high, we you know, we're better than anybody like, you know, like that's, that's an incredibly dangerous, you know, place to feel it never feel like, you know, hey, we have lots of money in the bank, or never feel like comfortable with the amount of money in the bank. Never feel like, hey, well, whatever, we can just hire some more people like, you know. So

maintaining sort of a mentality of scarcity, but then also making sure that, now we're selling, we haven't done this before, we have to get good at this really quickly, and we don't have the sum of the like...

the feedback mechanisms that we could have had earlier, had we started doing those in early days. So I would say that's sort of the trickiest part. it means that like, one of our VCs said, in a lot of ways, guys are a series B company, successful, you raise a lot of money, but in other ways, you're closer to a pre-seed company.

You know, and like, and, and they weren't wrong. And like, kind of, just, needed to sort of not be like, it's easy to, when somebody says that to be like, what do you mean? Like that's, that's bullshit. sorry, sorry, if I'm not allowed to say that. but then you're like, well, no, actually they're, they're, that's, they're, have a point. Like, what do I need to learn? What do I need to do? So I don't look like the pre-seed company and, and, and where do we have to get? And like, and so, you know, that's been.

That's been a challenge, but it's been fun. think we're plotting our own path and we're not trying to basically say we're gonna be just like anybody else.

Prateek Joshi (31:29.307)
One of the biggest challenges that the early stage founders, first time founders, they face is when you ship a new feature, it's like they ship it into vacuum because they just don't know what happened because if it's a simple example where it's an e-commerce site, you make a change, the conversion rate doubles, great, you know it worked. Or you got a consumer app and

you make a change and the average session time increases by 42%. Great. That's the thing you wanted to do. You did it and it worked. In enterprise, especially when you're selling a product to technical users or big customers, how do you measure the success of a new feature that gets shipped? Because you need that data to rally the team to do the next big thing. Because if you're like, oh great, thank you for shipping. I don't know what happened. It's just not very motivating. So how do you think about

measuring the success of every new feature that you ship.

Jordan Tigani (32:29.684)
so I think a couple, a couple of different ways, you know, the one is, you know, it's one of the reasons that we haven't gone after big enterprises because I've seen in the past, like when you do go after big enterprises, you can get into this, you know, like the, energy, you know, like somebody says, Hey, we will, you know, they, hold a million dollar check in front of you and be like, we will give you this million dollar check if you can build X, Y, and Z. And so you're on off and you build X, and Z.

And then, you know, the, you know, the next customer holds a million dollar check and you go, you go do that. And you, kind of feel like, okay, well, the stuff that we're doing is the stuff that we, what are the, anyway, just maybe in a different order, but very often that's not the case. And you can get into a spot where you're not, you don't actually really priding finding product market fit. are finding, you know, I think finding product market fit at Goldman Sachs or at, you know, bank of America, or at some big, some big enterprise, big enterprise or big company. And, um,

And that may not actually apply to anybody else. And so also by going after the long tail, we're going after lots of users, lots of adoption. And you can sort of see in a bit more real time, because we don't have long sales cycles. You kind of get to see how's the adoption going. So you can reduce the feedback loop time. On the other hand, you don't have these like, you

like, hey, these these three things, the deal blocker, you build those, I'll give you the check, this sort of like this big pot of gold at the end of like, they can validate those features. The other way that I think about building features, and especially for infrastructure projects,

is it's a little bit like chess. Like somebody defined, somebody wants to talk about like kind of the beginning stages of chess as you're not really going after it, you're, you know, attacking and trying to sort of win or take pieces on every, on every move. You're basically trying to establish a position on the, on the board and that has a position. It's a position of strength and moves that you take, you know, yes, they may get you closer to where you want to be. But they're also going to start to interlock together.

Jordan Tigani (34:35.02)
And I think a lot of the features that you do, you know, will, end up interlocking. And, know, if I can give an example of like, you know, we did, Vercell, you know, Vercell marketplace integration. mentioned that I mentioned that earlier as like, okay, so that's one thing. We get a certain number of signups for, from Vercell, that, you know, we could measure that as like, Hey, you know, you know, a hundred signups a week would be, would be our goal.

But on the other hand, there's also a case of this opens up an aperture of new users, new use cases. There's another feature we're working on, is PGDuckDB, which is sort of like this Postgres extension that can then talk to MotherDuck. So if you take that, you take also, okay, you know.

Prateek Joshi (35:16.818)
for it.

Jordan Tigani (35:30.752)
Also on Vercell there are these hosted Postgres providers. If we can get them to run pgDuckDB, then...

Then that's sort of another, okay, this is a great, great option, but you tie that together with the Vercel and now all of a sudden you kind of have these like new things that, okay, somebody's already in Vercel, they have Postgres, now they can use, they can use Mother Duck. That like multiplies the impact. And so I think a lot of features, you know, should not necessarily be taken in isolation, but they can, you know, they need to be taken in sort of like, how do they, how do they open the aperture? How do they, how do they combine with the other things that you're building?

to kind of get to the point that you want to be, even if like that feature may not move the needle on its own.

Prateek Joshi (36:20.388)
And to build a company that can build and sell velocity, you need a good org structure. how have you structured your company? And also more importantly, what was the thought process behind structuring the company in a specific way?

Jordan Tigani (36:38.254)
So we started with a super senior engineering team. We had three or four people who would have been considered kind of director level at Google or Snowflake, Facebook, et cetera. But they were ICs. so whereas you might have, if we just had one of those, one of them would have been sort of the op.

obvious choice for a CTO, but we had three of them. And so that made it a little bit weird because then if you were to hire a head of engineering, do those, the people report to the head of engineering and like, so that was tricky from the start. We basically had each one of those as technical leads of different areas. And, you know, we kind of grew that way and then we eventually hired a head of engineering.

somebody that I'd worked with before and who was also kind of similarly very, very senior, but also kind of knew how to build organizations. And sort of the deep, deep technical was not as important, although this person didn't have a PhD in compiler, so is very, very deeply technical. But also it wasn't going to be like, hey, this is the architecture we need to build. This wasn't the reason to hire that wasn't because they were going to drive the kind

technical direction. had plenty of people who would do that. Then obviously you need other, you tend to start with engineering, then you need other pieces. Product, we started with a DevRel, somebody who had a DevRel experience, head of DevRel at Databricks, so kind of very awesome DevRel.

And cause we were doing really like, how that person be our lead marketing. Cause like developer marketing, you know, when you're selling to a technical audience, you know, you kind of, they don't like to be marketed to. And so starting with somebody who really knows how to connect with developers was, was important. And, know, they've kind of turned into a great marketers as well. you know, the other, you know, customer success was another area where, I had seen it looker.

Prateek Joshi (38:38.002)
Okay.

Jordan Tigani (38:53.772)
this customer success organization they built, was extraordinary, called the Department of Customer Love, which is like one of the reasons that people liked Lookers because their support was so great. Like they just, they made their customers feel like, like Looker had just sort of wrapped their arms around them and just sort of give them a big, you know, made the like, we're going to make you successful. And so we hired the person who created, created that to lead our customer success departments, which we call the hatchery, you know, we're helping our, helping our, you know, customers learn to fly with our, with our technology.

incubating them and all that stuff. And, you know, had to build a sales team and, you building a sales team is tricky. But anyway, so like we have, I have four different meetings. So one is like, we call it corp. The goal was to call it something boring. So people wouldn't be like, well, why am I not in corp? It's like, hey, we're solving all the boring problems so you don't have to think about them.

Prateek Joshi (39:41.846)
You

Jordan Tigani (39:46.86)
And those are essentially my directs, they're of departments. We have EngStrategy, which is sort of these sort of super senior engineering leaders and head of product and head of engineering and kind of like, what are we building? Why are we building it? they're, know, bounce ideas off like, and, you know, I expect my ideas to get shot down and like, and, you know, but just try to hone what we're building and the order that we're building in.

There's go to market strategy, is we ever go to, know, like sales, marketing, head of growth, et cetera. That's just how are we, how are we selling? How are we going, going to market? And then back office, which is sort of like operations facilities, like, you know, how are we, you know, what's the.

you know benefits and you know things things like that and kind of dealing with dealing with people with people issues and i think that that works that works pretty well because you know corp can tie it all together and then kind of the the different areas are are all are all separate

Prateek Joshi (40:48.562)
Perfect, that's wonderful. And I have one final question before we go to the rapid fire round. How are you preparing MotherDog for this AI native era we're entering? Are you changing anything or perhaps you're already structured to address all the needs of your customers? How are you thinking about that?

Jordan Tigani (41:09.23)
Um, so, you know, we kind of have a multi multifaceted approach. You know, one is, you know, obviously how do we, how do we use it? How do we use AI to do what we're doing better? And so that means, you know, co-pilots and stuff like that. But it also means like, um, you know, I think there's, opportunities to use AI to help improve the support process, uh, help the documentation process. Um,

not necessarily customer facing AI things, which can be annoying, but things that could give superpowers to our support folks to be able to find things that they find and answer questions that they need really quickly. Then there's the stuff that's going into the product and being able to give our customers superpowers on data and...

and being able to ask things in English and text to SQL is notoriously bad, but there are actually some constrained cases where it can work well. So we kind of have put some things in the product, our own co-pilots and the ability to author SQL code and auto-complete and automatically fixing errors as we see them.

as well as giving you the ability to generate embeddings automatically and run an AI prompt over all the data in your database or in your query. So a bunch of those things, and then solutions is making sure that we kind of like.

educate people on how to use this because AI is like a lot of the things you can do with AI are relatively nascent and people are just starting to figure some of these things out. And if we can help provide documentation and examples, that can be also a way to get people to use it. then partnerships, making sure that we partner and have the connections and the connectors with line chain and open AI and other.

Jordan Tigani (43:19.79)
other technologies that people are using to build applications.

Prateek Joshi (43:28.568)
Fantastic. that, we are at the rapid fire round. I'll ask a series of questions and would love to hear your answers in 15 seconds or less. You ready?

Jordan Tigani (43:37.528)
Sure.

Prateek Joshi (43:38.258)
Alright, question number one. What's your favorite book?

Jordan Tigani (43:42.114)
I would say Master and Margarita. just my second date with my wife, we went to a bookstore and we each bought each other a book. That was the book I bought her. She bought me Our Man in Havana by Grant Green. And now she's an independent bookseller.

Prateek Joshi (43:57.65)
I love that book. It amazing and that made me look into Pontius Paras. It went on a history tour because I was is, anyway, that's the whole separate conversation, huge fan of the book and thank you for saying it because it rarely gets mentioned. So I appreciate that. All right, next question. What has been an important but overlooked technology trend in the last 12 months?

Jordan Tigani (44:24.27)
I think most of the times if they're a trend, they're not over.

Jordan Tigani (44:32.521)
say that you know that laptops keep getting faster and faster and more powerful and I think that hasn't really changed how people are doing things yet but I think it I think that's that's we're going to start seeing some interesting things there.

Prateek Joshi (44:46.084)
what's the one thing about data warehouses that most people don't get?

Jordan Tigani (44:52.91)
Most people don't get the importance of metadata. You know, hear a lot of talk about like the separation of storage and compute and like, and you know, these like these separate iceberg, you know, open storage systems versus like compute. The part in the middle that gets nasty is metadata and people are starting to figure that out with like, hey, well, what about the catalog?

That whole area is a mess. just because it's, actually that's where a lot of the hardest things, things go on. And it's just something that people, people don't necessarily realize.

Prateek Joshi (45:25.456)
What separates great products from the merely good ones?

Jordan Tigani (45:31.852)
I think it's the ability to basically take things away that people expect. It's like the iPhone is the canonical example where people thought you needed a keyboard and they took it away. And they realized that because if you take this away, we can then give you.

all these other things. know, Tesla, whatever you feel about Tesla, like they did some amazing things where they basically take all the buttons and stuff away. Everything's just a screen. like I think, and it, you know, it really can work.

Prateek Joshi (46:08.591)
That's fantastic. All right, next question. What have you changed your mind on recently?

Jordan Tigani (46:15.662)
I think Iceberg actually, I was not a proponent of that. was like, it's like, the problem that we're solving seemed like trivially solved by data warehouses. But I also kind of have recognized that like, hey, this is here and it's something and a lot of people are excited about it. And so kind of you need to have a good story around it.

Prateek Joshi (46:41.926)
What's your wildest prediction for the next 12 months?

Jordan Tigani (46:46.67)
Um, I know this may not be an exciting one, but it's like, maybe I feel like the data market is solidifying. And I think that. Unless there's something, you know, AI magic magic, um, there are going to be no great data companies started in the next 12 months.

Prateek Joshi (47:10.834)
All right, final question. What's your number one advice to founders who are starting out today?

Jordan Tigani (47:17.55)
I see a lot of people who kind of are putting like Legos together and like, Hey, we could put these two things together and like, and build a startup. And that's really hard. And I think, I think the most interesting startups are ones that have, you go against the, go against the conventional wisdom. So I would almost say take something obvious and then do the opposite, you know, and like, or at least validate the opposite. does, you know, can, you know, everybody says this is what's happening.

Startups are sort of default fail. It's like they're expected to fail, but it's like, okay, the conventional wisdom doesn't turn out. Where else, where would it end up? And because the conventional wisdom very often doesn't turn out the way people expect. And so kind of if you can have the thing that is different and you can have conviction around that, then I think you can build something pretty interesting.

Prateek Joshi (48:09.01)
Brilliant. Jordan, this has been a fantastic discussion. Thank you so much for sharing your insights, wisdom, and just like hard-earned knowledge on what it takes to ship products. So thanks again for coming on to the show.

Jordan Tigani (48:20.632)
Thanks, I enjoyed it.