Jordan Tigani on Reinventing Old Tools for New Market Needs

Jordan Tigani, Cofounder and CEO of MotherDuck, built over a decade of experience at Google during the advent of big data and large data processing. As he realized that traditional tools were not keeping up with the pace of technological advances, he decided to revamp the pieces to build a better data analytics machine.

I sat down with Jordan to discuss taking learnings from a major corporation to his own startup, building data tools for companies of all sizes, and sharing perspectives on how to frame your fundraising approach.

Tell us about your time at Google.

I started at Google in 2009. I went there because I was excited about big data and their ability to do large data processing. Google was way ahead of everybody else at that time. Previously, I had worked at an AdTech startup. We had our pixel on something like 10% of pages on the internet at the time; we were processing what was considered massive amounts of data. I knew that big data was a thing. Even small startups can work with large amounts of data. You can’t process it well using the traditional tools or the tools that people are used to. We needed a new set of technologies to chop things up into pieces, process them, and reassemble them. At this point, MapReduce had been out for several years. Google was moving past it. I had an inkling that there was a better way of doing things than with MapReduce. I figured the best way to dig into that would be at Google.

Were you on the Google team developing BigQuery? When did you decide to move in another direction to build MotherDuck?

Yes. We had been told to build a data marketplace. But with that amount of data, you would have to wait forever to download. So we wanted to use SQL. We wanted to be able to move the compute to the data, rather than the data to the compute. So telling us what you want to do over the data and what answers you want from the data created a really nice way of running the compute via SQL. That’s where BigQuery got its start.

I started noticing that most people actually didn’t have big data—and the ones who do tend to only use a small portion of that data. People might have ten years' worth of logs, but might only be looking at the past seven day’s worth of history. The systems that we had bent over backward to build were highly scaled-out systems that glued a SQL interface on top. It seemed like overkill.

First, the size of the data and the workloads that people actually had were just not that big. Second, the machines at the time were actually quite small, but nowadays, they are orders of magnitude larger. Third, it used to be that laptops and workstations were highly underpowered. Nowadays, I’ve got a Mac M2, and it’s incredibly powerful. While I’m waiting for a query to run somewhere in the cloud, my laptop can sit there idle. If I utilized that local compute, flying through data and drilling down highly reactive dashboards starts to become possible.

Those are the pieces. The last piece is DuckDB, which is an analytics engine. It’s a library you link into your process that enables you to start easily writing queries. It’s been around for a couple of years and keeps getting better. It’s taking the data world by storm. So we’re building a cloud-hosted DuckDB as a service, essentially a data warehouse based on DuckDB. DuckDB is a single node that scales up. We can also scale it down to virtually zero, which is great if you’re building applications.

The other thing is that, with the way we’re building it, the client is always DuckDB. Whenever you’re using MotherDuck, there are two DuckDB instances running. One is local. If you’re running on a laptop, it might be running in your browser. If you’re running a BI tool, there’s also a command line interface. We also run that on the server. We can cache results and then query data out of those results. We can join against local data. There are a bunch of interesting things we can start to do when you have this hybrid execution system.

How much of your energy right now is focused on engineering versus issues relating to customers, users, and market growth?

A lot of it is still focused on engineering and the product. Often, I get pulled into other areas. When that happens, I realize engineering and the product are not getting done the way I want them to. We have extraordinary engineering and product people, but we have to maintain clarity on how we’re going to do things like organizations or billing models. There are a lot of hard questions and things you have to drill down. That requires knowledge of the technology as well as knowledge of the customers and how other companies are doing these things.

It’s also trying to build things in a way that is not just replicating the existing art. If you try to build a clone, there’s no point. You’re going to be chasing what someone else has built and will be continuously trying to figure out what comes next. You need product intuition and a belief about where the world is going. Then, you can build a product that meets those needs. That isn’t always the same product that customers are asking for. That’s one of the tricky things. We spend a lot of time talking to customers to figure out what they need and what works for them. But if you use that as your total north star, you just end up building the thing that they used last and not the thing that they’re going to use next.

You’ve been able to leverage major career accomplishments in big markets. What are some things you’d say other founders need to get right?

When I started out, I had no idea what I was doing. There was so much I didn’t know. I talked to a bunch of founders. I found this network of people I could reach out to who would jump on the phone with you, even though they were running their own large companies. That was super surprising. They would jump on a call immediately and spend 45 minutes talking through things.

But the advice I was getting from these founders was all over the place. It wasn’t like, “Okay, go do X. Go work with this type of firm. Raise this amount of money.” Some founders would tell me one thing, and others would say the opposite. For example, there were two big things I kept hearing. The first was to raise as little money as you think you can get away with. That way, you don’t have to dilute as much. You can always go back and get more if you have a good VC. The other was to raise as much money as you can because the only time you’re actually vulnerable as a founder is when you’re raising. If you control the board and you’ve got money in the bank, you can do whatever you want. Both things are good advice for different founders and for different companies. But you have to figure out what kind of founder you are and what kind of company you’re building.