Finding PMF at dbt
Q&A with CEO/cofounder Tristan Handy
The early team at dbt on a fall retreat in 2018
What was the initial spark that inspired dbt / Fishtown Analytics?
I was a data person working at a data company. The trigger, really, was watching RJMetrics fail. One year all of our metrics were up and to the right; the next year things had degraded significantly. The difference was the new generation of technology and tooling that has come to be known as the “modern data stack”. Because RJMetrics had been built in a prior era with a previous generation of technologies and a different set of beliefs about the world, it just wasn’t as relevant in a world that included products like Amazon Redshift, Looker, and Fivetran (all of which were part of this shift for us in the 2014-2015 time period).
As the leader of a company that was succeeding and is all the sudden isn’t, you find yourself doing quite a lot of introspection across the leadership team. Many leadership teams exhibit this blanket optimism about the future, but we had to learn to see the future as it really was and deal with it. This had a few great outcomes. It allowed us to pivot the business into a successful exit, and it also laid the groundwork for dbt. I wouldn’t have been able to have all of the ideas that led to dbt in a vacuum on my own. I also wouldn’t have been able to attract incredibly strong cofounders without being surrounded by a ton of amazing people who were all going through the same experience together.
What excited you about the potential impact dbt could have? What gave you confidence that other developers would also believe in this dream?
Quite the opposite is true, actually. dbt started out as an internal productivity tool for Fishtown Analytics, the analytics consultancy that I started. I was excited about using it for myself, because I knew how much more productive it could make me in doing the work I was going to deliver for clients. But it required data people to work in a way that many of them were not yet comfortable with. Expressing all of their work in code. Using git. Thinking like software engineers. These were foreign concepts to nearly all data people at the time.
Because of my very hybrid background, these were areas that I was excited to take my own personal practice. But my belief was that there were probably not that many data people who wanted to join me along this journey. And so I didn’t start a business with an expectation that this product would take over the world. Over time as the dbt Community has grown and grown, it’s become clear to us that these messages really do resonate with a very large part of data practitioners and we’ve built an organization to support this wave of change in our industry. But we didn’t expect it to happen going in, and we didn’t create a company that required this to happen.
I think one of the mistakes that some founders make is to pursue a business strategy that only makes sense in a context of outsize success. The reality is, if you create a business that can only survive in this context, most of the time you will fail. And maybe from an expected value perspective that makes sense for investors and for the world at large, as a founder you only get a few shots. My belief is that founders should create more optionality for themselves by creating organizations that can be successful in a wide range of contexts, then learn more about the context you’re actually in and adjust over time. Don’t race towards an all-or-nothing future; there are a lot of states in the middle there that are much higher probability of success and will still be life-changing for you.
Tristan showing us his archery skills, at Sequoia’s annual Basecamp
What were the open questions you had about dbt, that you set out to answer?
My biggest question was around technical feasibility. dbt represented a dramatic change from the way that data engineering work had been done to-date. While it’s not that interesting to dive into the details of how the technologies differed, it was deeply counterintuitive to data engineers in 2016 that it would be possible to do all of their work in SQL inside of a modern data warehouse. Every consulting project I took on in the early days was a constant test of “is this even possible using these constraints?” And we kept finding that the answer was yes, yes, yes. We never ran into a situation where something that should be done in dbt could not be done in dbt.
How did you think through building the original MVP of dbt?
The core user experience of dbt hasn’t fundamentally changed since maybe ~80 hours of engineering time was put into the product. That’s it—two weeks of some very talented engineers’ time (and part-time at that!) created the core experience. The code was messy and the architecture was poor, but it worked with high reliability, it did thing it promised to do, and the UX was fantastic.
One of the things that I think that many founders don’t think about hard enough is just how minimum that MVP can be. What is the core thing that needs to exist where everything else can be stripped away? One of the things about starting as a consulting business was that it was intensely focusing. There was no funding, no hopes and dreams, just the need to earn money from clients. For us, that was a great way to force prioritization on what we knew really mattered.
Who were your initial users? How did you find them? How did they start to use dbt? How did you nurture this community?
Our first users were consulting clients whom we had trained on best practices by hand and written their original foundational code ourselves. This ensured that they really “got it” and made them into advocates from day one. They then advocated on our behalf and formed a small community around the product, hosting meetups and introducing us to other folks in their networks. The ongoing conversation happened in a community Slack channel, where folks were highly engaged. This engaged flowed not only from the fact that they loved the product—moreso it was because the product asked them to work in new and exciting ways and they needed a community of peers to learn from. Most conversations were not about the tool itself, they were about things like “I’m running into this problem…how have you folks solved similar problems?”
Tristan speaking at FF100 Founders Forum with Sequoia, where Silicon Valley meets Europe
When did you start to feel like you had product market fit?
There have been so many different stages to this. The first company who wanted to use dbt who wasn’t a consulting client. The first time we hit 100 companies using dbt. The first time we hit 1000 companies using dbt. The first time a Fortune 500 company wrote us an email saying “can you help me deploy this thing internally?” It’s a continuum, and the trickiest thing is, IMO, to respond to it on a continuum. The first time you get glowing feedback don’t just decide you’re off to the races and raising a Series A. Be skeptical, be paranoid. Continue asking yourself how it could all fall apart. This is the energy that will fan whatever the early flames are that you’ve kindled. Early growth doesn’t necessarily translate into lasting growth.
What advice would you give to founders as they are just starting out, inspired by an inkling of an idea, finding ways to validate customer interest, building an MVP and iterating to early PMF?
The most important resource you have is time. Your time as founders is just so incredibly important. You should be managing it more carefully than any other resource.
I don’t mean this in the way that most people mean it when they give you advice. Most people say “your time is value so hire people to do all of the non-strategic things.” That’s not what I mean. Instead, think of it this way. Calculate your personal burn. Figure out how to fund that as soon as possible. Ideally you could fund that in a way that is sustainable indefinitely. The minute that you know you can fund your personal burn indefinitely, you have all the time in the world. Every time you take on extra expenditures, make sure you understand how they’re impacting your timeline, and refuse to take on expenditures that negatively impact your timeline.
Innovation is impossible to perfectly forecast. The best thing you can do to ensure that you’ll build something great is to create the time and space to do so. If you create a context that forces you to try to sell something just “ok” you may be locally successful but you’ll never achieve the kind of outcome you were hoping for when you started.