Data Council Week (Ep 3): Product Analytics the Right Way With James Greenhill of PostHog

Eric Dodds 0:05
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. Recording on-site at Data Council Austin. We are having a blast with the microphones set up in this side room and we’re grabbing all the cool people that we can find to come into record episodes. And today, we’re talking with James Greenhill from PostHog and he is the platform team leader there. And I’m super excited to talk with James, I think one of the things that I am really interested in is the what are the challenges that we don’t think about when you’re building a product analytics tool? You’re a data person building a data tool for people working with data. And I think that there are probably a lot of things that we don’t necessarily think about because product analytics on some level seems straightforward. You record some sort of instrumentation, and then you send the data through, and then you look at the data and figure out if this feature is working or not, right. But there’s probably a lot more under the hood. And some decisions that have to be made are probably pretty difficult. So that is what I want to ask James about. How about you, Kostas?

Kostas Pardalis 1:31
Two things. One, I definitely want to have a conversation with him about like the concept of platform sign like organization. It’s like one of these things like the platform themes, and as they arise as a way of like, organizing engineering, that’s like very interesting. And I’d love to hear about how it is implemented in Boss Hogg. And then, of course, learn more about the technology itself. And so hopefully, we will also have some time to talk a little bit more about product analytics in general, and what it means and where the problems are, and how you can do them properly. Because it’s really not like it’s one of these things that like everyone wants to do. And it gets messy very, very fast. So let’s see what we can learn.

Eric Dodds 2:18
Let’s do it. James, welcome to The Data Stack Show. We’re so excited to chat with you.

James Greenhill 2:23
Glad to be here.

Eric Dodds 2:24
We are actually on-site again at Data Council Austin in person. So so fun to record. And you are head of platform at Posthog, so we want to hear about that. But tell us how you got to that point. Where do you start your career? How did you end up working in data?

James Greenhill 2:39
Oh, yeah. So I’ve got a really interesting story for my career. Basically, I started out as a data analyst (data scientist, really) at Grooveshark forever ago.

Eric Dodds 2:47
No way! Man, I definitely remember Grooveshark.

James Greenhill 2:51
So basically join there, my entire initiative there was to make the data more or make the company more data-driven. So I reported directly to the CTO, Josh Greenberg, and had a bunch of initiatives, I had this newsletter called the short term that I sent out every week. But very quickly, it became apparent that we had to basically no data infrastructure at all, sort of scratching an itch started getting data engineering, just as to serve me, went down that track ended up with disgust for four years building up the data infrastructure there was actually originally hired there as a data scientist, okay, did the exact same thing. What’s funny about that was we started out with the VP of product, the entire suite of reporting was a Python script that hit a Postgres instance, that spat out static HTML on a cron job. So basically, my first thing was like, Nope, that’s gotta go. Set up a dupe, did all sorts of stuff for four years ended up converting that company like that was what we ended up monetizing. At the end of the day, we tried it a couple of things with like ad platforms. But basically, the data was the best thing that we had.

Eric Dodds 3:54
I remember. I actually was a discuss user and I kind of remember that. That was really interesting as a user.

James Greenhill 4:02
Well, we were basically the largest. We were all over there and we’ve been they basically still are, but at the time, it was like peak total us. And we had the largest Google Analytics account that Google Analytics had really, yeah, we had 1 billion uniques with 10 billion page views a month, which was pretty great. I used to joke with people like it was great for recruiting because I was like, Hey, you could join this company and have by far the most unique sport engineer than any other company out there, for sure. But yeah, like we basically it started out originally as like how to understanding how people use the product. And then it was like, Okay, well, maybe we could turn this into an app platform or using this data. And then finally was just like, well, actually, we have a really good persona, just from people like we’re scattered throughout the internet. We know what people kind of want get on, we can bundle that up into nice personas that we can kind of help people target better with and so that was four years of my life. And then I ended up being like, Okay, well, I kind of want to play with product engineering whenever to Silicon Valley. But actually, I went to a company that was acquired by Silicon Valley Bank, standard treasury, a closure shop of all things. Did product engineering did the worked on the integration for enough? I don’t know if you know Stripe Atlas, it’s basically this product that allows you to spin up a company with like a Delaware C Corp and all this stuff. It’s a great product. But we were one of the partners for the banking side. And so I helped build out the backend for that. Really fun. Well, working in banks really tough, very, very slow-moving, also kind of wanted to get back into data. So ended up back over as are actually I started really interesting. I ended up at Uber working on the self-driving cars. So yeah, the autonomous cars so I was at Erie teach you and basically handling the real-time telemetry coming from the trucks. So the idea there, the goal was, we had these cars driving around, but they really weren’t getting utilized very well. They were breaking down for various reasons. And we wanted to understand why and how we could improve the utilization the fleet. And we did that via real-time analytics, pretty much. And so I worked on building that out, which was a ton of fun, really interesting. But then we bought jump, and I’m a cyclist at heart. Like I love cycling. One of the reasons why I live in San Francisco, it’s just like perfect weather all the time for cycling. Yeah. But basically, I was like, Yes, I definitely want to help here. I believe in the mission, really fun and the products fantastic. And I would use it every day. So I went over to jump, basically led the integration of the jump infrastructure into Uber’s infrastructure, throwing over old pipes for getting like usage data into and built out a team doing that as well as doing reporting for cities. So it was kind of a quid pro quo with jump, like the entire license that we got to operate in cities was in exchange for data. So we would go to a city and be like, hey, like, we would love to launch jump in your city. But an exchange like, we know that this is like you want something back from us. But so what we’ll do is we’ll tell people like where people are riding. And you can use that to develop your infrastructure. Where Yeah, it was super like, that’s a neat, like public/private partnership. Yeah. And it was really good cities loved us for that because it was very difficult to get otherwise. Strava actually did this as well later in their career. But yeah, it was, it was really cool to see cities like say, Yeah, we would love to understand where we should be putting bike lanes based on where people are actually biking. That’s really helpful.

Eric Dodds 7:09
It’s like the cow path theory, right?

James Greenhill 7:12
Yeah, it’s exactly that. So it’s very organic is very dairy-driven, which is like surprising for cities, but I love it. The other thing was enable, like one of the generally as part of getting the license, they would want to serve underserved areas as well, like enabling people to move city. Sure. And so that was a way for us to show prove that we were doing this. Yep. Which was really, really great. And then after that, we ended up about two and a half years ago getting like through a deal moving everything over to lime and lime to scooter company on these big scooters. Yep. So I started looking around for companies and I found God PostHog, so PostHog, the story there is really interesting. I basically saw them. I basically, I basically saw them on GitHub, and I started them like basically showed up on Hacker News, I’m sure in fact, I remember that. Yeah, launch the one. Yeah, totally. So basically, I saw them on Hacker News. I saw it like started on GitHub. Yep. And James Hawkins, the co-founder likes to procrastinate. And one of the things he does when he procrastinates is he looks at the GitHub stars to see like who’s liking three bow.

Eric Dodds 8:12
That’s such a wonderful founder procrastination.

James Greenhill 8:16
Oh, yeah, he does the same thing. The other thing that he does when he procrastinates is like, checks LinkedIn, just networks. That’s what he does, not whatever he’s supposed to be doing at the moment, which is really great for growth, really great for networking. But anyways, he was like, hey, you work at Uber. Do you mind looking at a product and maybe doing an investor reference call or something? And I was like, yeah, well to like, I’m a huge fan of the product already. This is absolutely something I would use at Uber. If I was like trying to instrument product analytics. It’s something that I’ve been doing forever. Like, if you were to ask me, like, the one thing that I’ve done, like 10 times over my career is like, you walk into a company, they’re like, We don’t have any data. And what are you gonna do with the data? Well, we’d love to make a funnel. We want to understand like, how were Pete like, that’s what everyone wants to understand what the app is like, are our people entering my app? How are they converting to being a paid user? Where are they having good and bad experiences? And how can I like, allocate my resources to improve the experience? Yep. So we had done that we had actually done like a code yellow at Uber with jumped because the experience was kind of shoddy. And certainly it was, we had some VIP users who were using the product, they’d be like, Why isn’t this thing working? So we did this, like, all hands on deck, like build out a funnel thing? Sure to understand, like, where people were having issues. Yep. Anyways, I was a huge fan of the product. I did a couple investor reference checks. And then I was like, You should hire me. And the rest is basically history. I no book there. I leave the platform team, basically, with the infrastructure side and the ingestion side. So it’s making sure that we collect events that no events are lost, that they show up into the data warehouse on time, and that the entire stack is easily deployable, either on Cloud for us or for our customers who want to host it on-prem TLDR.

Eric Dodds 9:51
Yes. Okay, so I’m going to ask one question then, Kostas, I know you have a ton. Did you have to come in and build the analytics funnel for an analytics company when you came into Posthog?

James Greenhill 10:02
Surprisingly, no. It was the first time I did not have to do that it was built originally, we had to rebuild it. But there was already a funnel. It was just built on Postgres. It was just a little slow. It was good for like small, small installs, but we should have to do it eventually.

Eric Dodds 10:14
Yeah, totally. It’s always funny, and we talk about that in what we do as well. It’s like, you sometimes you have like a cobbler shoes type situation, especially in the early stages where it’s like, that’s awesome. Alright, Kostas, I’ve been monopolizing, so please.

Kostas Pardalis 10:28
Oh, it’s fine. It’s fine. You’re doing an amazing job, as always. So let’s talk a little bit about lactose, we’ll go into the product screech lately, while these leads, and like how different compared to the other, like solutions are out there?

James Greenhill 10:43
Well, the main thing is we’re open-source. There’s not really any product analytics out of the box that handles open-source product analytics, like, especially at scale, like we’ve heavily tied or we’ve met the farm, I like to say on ClickHouse, and it’s been really great for us is what Yandex used for metrics, which is like their Google Analytics. And so it’s very used to scale and it, it works great for us, it’s relatively easy to host our stack locally. And other than that, like we have a bunch of the I think something that is a little different from most of our competition is that we’ve tacked on a lot of extras onto it, because we believe that like, it’s kind of like the entire thing that we see with like the modern data stack currently, which is like everything lives in your warehouse, and you’re able to, like leverage that data in the warehouse to power other tools, other data tools. So we have a feature flagging suite in there, and experiments based on that. So those are all powered by the data that you put into PostHog. So if you omit a bunch of data, you can say like only use this feature flag only enable this feature flag for this product, if the user is like a high-frequency user, or uses this specific thing, or as part of this group, you can go super deep with that, like you can based on properties that are on the user or properties have their own events. So like we’ve made it so that like there are all of these 10 tangentially related products that are powered by the data that you send PostHog, but are kind of separate products by themselves. Yeah. So that’s, that’s another like between those two, I’d say that those are two primarily primary differentiators between other products.

Kostas Pardalis 12:07
That’s amazing. If I want to use PostHog, where’s the data stored? Is the data like stored in something, whether it’s allergies, translate that’s appropriate for being built by PostHog? Or is it something where I kind of use like I thought, smartly whole data warehouse

James Greenhill 12:26
Porque no los dos. Basically, yes, you can do both. By default, it goes into ClickHouse where the schema is kind of like blessed by us. And that schema is always changing. Oops, changing slightly as we tried to make it a little bit more performant. And leverage ClickHouse features a little bit more as they come out. But we also have a feature that allows you to kind of tee off all of your events, from the flow into a data warehouse of your choice. So as the events come in, you can say like it doesn’t impact the flow into ClickHouse at all. So our product keeps going. But like let’s say you want to use that to augment the data that you have in your own warehouse, whether it be on GCP, or BigQuery, or Snowflake, or Redshift, or Postgres, or wherever you want it like we you can basically, we the way that we do that is via plugins, and you can build these plugins yourself. So if you’re someone who uses like DB two, for whatever reason, and you want your data to be in dB two, you can do it. You just need to have that plugin, and put it into a repo and point your Posthog install to it.

Kostas Pardalis 13:19
Why do we even have like product analytics in general? What’s so special about the product itself in terms of the analytics we power? That’s one but we assume is why do we need special stores for the data?

James Greenhill 13:36
That’s a really good question. So the first one, like how is it different from like, how is product analytics different from analytics? And like, specifically for a sock? It’s a little different. Because with analytics, like Google Analytics, you’re really looking at like attribution you’re looking at how are people showing up at your app? It’s very good for marketing for product analytics, things like Mixpanel, or an Amplitude, or Heap is really interested in like, How are people using right, like, and are they having a good experience? And are they converting and retention, like are people sticking around, so they’re subtly different, but they really are different use cases, and different personas are going to use both of those products. Now for the storage layer. We did originally just use Postgres, and it worked really well. We moved on to like a data warehouse like you were saying, which we think is going to be a data warehouse in the long term, like so Click House is like an OLAP database that you might compare it with like a druid or a Pino, but I think the direction that is going in is probably going to end up more like a Snowflake in the long term. So you can host it, but the differences you can host yourself. And it’s actually kind of like Starburst, if you’re, it’s very, very similar. So I, it’s just our constraint, we would have chose to be or we would have entertained those other options a little more. But one of the constraints that we had when with choosing the warehouse was making it easy to deploy on-prem for a smaller company. So putting it in a Helm chart and shipping it is much easier with ClickHouse then it is with like the entire, potentially HDFS stack, which a lot of companies a lot of enterprises might have been more comfortable with but we really optimizing for just like turnkey efficiency with the product.

Kostas Pardalis 15:11
Make sense. Let’s talk a little bit about the capturing and collection. I’ve seen many times, and I’m sure Eric also has seen that, the first time that you tried to instrument you’re always like a hue.

Eric Dodds 15:26
I’ve never experienced that. Like, doing that 10 times every time.

Kostas Pardalis 15:35
What I find amazing that like people are like, okay, let’s just instrument everything like this. Like every possible instrument I can remember. Let me this shoe. It’s just noise. You have to you don’t know what to do.

Eric Dodds 15:48
It’s pure gluttony.

James Greenhill 15:49
Well, it’s hoarding. I call it hoarding.

Kostas Pardalis 15:52
And to be honest, like I’d have reached like the opposites Directorate. Where I’m like, let’s start from SaaS right now. Let’s see these commonly do something with beat and then let’s add another. I’m talking about that is because instrument like a product is one of those things that like you read like a lot of technology. Do we talk about why we need like specialized doorbells, like a specialized UI is like to do like the liquidating and bogus things. But you end up in a situation where like, all these might be completely wasted if you don’t move them and do these permutation rights. No. Harm home, like a brothel. So she’ll both like, understands how we should be approaching these off like both of the people out there and how we should build these instrumentation process and maintain it?

James Greenhill 16:47
You’re absolutely right, with people basically just kind of throwing everything against the wall and seeing what sticks in terms of instrumenting their app, I think, educating engineers on how what they should instrument, the app is like, step one, having a good taxonomy on what the metrics should be, what the events emitted should be is huge. And that’s something that we’re working on currently is trying to like, surface, what events are being emitted so that engineers know, like, oh, like, you don’t end up with the classic case of like, checked out, sale complete, sale, like all the events, all these events being emitted that mean the same thing, but are being emitted in different locations, with different terms, and so they’re not getting captured, right. So like the taxonomy thing is really, really a difficult thing. And I think over time, you’re going to find that engineers are going to be involved in this more and more. And as engineers are also becoming more product-minded, you’re gonna see them scratching their own itch, and you’ll probably see the hygiene of this go improve anyways. So they’re kind of two solutions to it. One is education. I’ve seen linting done on the front end where, like, as you change a metric, like something that’s being emitted, it’s like, hey, like, this is a new type of event you may be emitting? Are you sure you want to add this, like, Here are other things that are like maybe similar. So that’s, that’s one way of doing it. The other way of doing it is consulting on the back end, which is I feel like what we most people do, now, we’re just like, okay, like, We’ve all made mistakes. And if so, I’m just going to combine these all into one metric or one event category. I think catching it earlier is better, we’re going to push people towards that because you get more value out of it, I think you get a lot more engagement from the engineers that are implementing this. Because if you can get engineers bought in and make it easy for them to instrument the app, it’s you’re gonna have better metrics in general, like, it’s just a good thing. But yeah, it’s a problem.

Eric Dodds 18:30
I have a question on that actually, especially related to the way that you think about PostHog as a platform, and I’m thinking about this from the standpoint of having used whatever, tons of different product analytics tools, right. So even if you’ve done taxonomy before, and you start with like a pretty good taxonomy, things change, things grow, like the app itself changes, right, you try new things, right. And so there’s, there’s inevitably some sort of data drift, like, even if you work out pretty hard, right? It’s just the nature of the business. So what’s interesting is the basic product analytics tools, and like, the visualization components are built for sort of like a really clean taxonomy, which makes sense, right? And so there’s kind of this whole other feature set, actually, that some products do well, and some do really poorly, like product analytics products around like, Okay, if that happens, like, if you have drift, and you need to fix it, because like, Guess what, now your visualizations have problems, right? Yeah. How do you think about that feature set, because it’s sort of this like, hidden, but like, really critical thing? That’s like, pretty high. I don’t know. It’s hard to think about, like how you consider that feature set and a platform like Posthog.

James Greenhill 19:45
One of the things that we’ve kind of prototypes, it may be released pretty soon, I’m not sure it’s kind of like super alpha phase is the idea of trying to consolidate these and categorize them together. So it surfaces all different types of events that you’ve emitted with their like, their context and it tries it’s best to consult, like capture them together. So it’s like, well, these all look like sale events. So these are all page view or impression events. Yep. And then it kind of helps an engineer analyst, like or product person go in there and be like, oh, yeah, these are and then immediately that becomes one consolidated thing. Got it? But yeah, it’s a tough problem. And if you’re in a warehouse, I think the best thing to do would be to have some sort of like, I don’t even know if there is something out there like that. It’d be kind of like a data catalog or data management system, product that surfaces the dimensions for every column. So yeah, like, these are the events and like some sort of distribution of those events. And you could probably I imagined in every company see, like a some longtail of like garbled titles.

Eric Dodds 20:45
A lot of companies just fix that in SQL, right?

James Greenhill 20:47
Basically, yeah. Traditionally, that’s how I would do it. Like, if you were to pick me up and put me back in time it’d be like, well, there’s another Airflow job, or whatever.

Eric Dodds 20:57
Do you view those decisions as sort of unchangeable? Like you decide because that’s another big question, right? Like you decide that there’s, like, these particular events essentially need to be consolidated to represent like, one thing, should you be able to reverse that?

James Greenhill 21:17
Yeah, that’s a really good question. Typically, like going back and rewriting data, it sounds nice. I very rarely have seen this actually work. Yeah, people do it. Like going back and just rewriting data to fix these types of things. Usually, you end up with some sort of VLOOKUP, where it’s between these dates, and this Yavin name, like it equals this Yeah. Or find a term. So in that way, like, you’re not destroying any data, you’re just kind of like adapting it. Yep. I’ve seen that work. But it’s, it does get burdensome. It can get pretty heavy.

Eric Dodds 21:47
Yeah, it’s like one of those things where if your hands are on all the controls, like, you can kind of massage it. But like, from a product perspective, it’s when you’re like, on some level, you have to make some decisions for the end-user, right? Or you have to, like, give them options, which is like hard. So yeah, it’s super interesting.

James Greenhill 22:05
We don’t do this, but I really liked the idea of having the linter and being like, hey, like, before you even get it into production. It’s like, whoa, we think that this, this is either, like, Are you sure you want to admit this new type of event? Like, here are the other events that this might fall into. Like, that would be perfect.

Eric Dodds 22:20
It’s the angel on your shoulder.

James Greenhill 22:22
Yeah, exactly. Exactly. Or the blocker. It’s like, no, don’t do this.

Kostas Pardalis 22:27
Last question from me. So discussing all the instrumentation, and my goal, these may stuff we’re gonna talk with, do you think that we should start from the metric and an end goal, like, what kind of functions we should report to? Or to the opposite stops from the events?

Eric Dodds 22:44
Ooh, that’s a great question.

James Greenhill 22:46
That is a really good question. That’s a fundamental question. Ideally, we know exactly what we want to measure all the time. It’s our business. Yeah, exactly. Yeah. And we know everything. We know every hypothesis that we want to test from day one. Yeah, it I wish. But yeah, typically, I think you’re gonna end up with going in and being like, well, I have this hypothesis, let me instrument the app in this way and test it, and then you’ll get a risk, like a result. And you’ll be like, oh, cool, or, and then you’ll hopefully pull those events out. If you don’t need them anymore. Maybe you keep them in to track them over time. But yeah, I think typically there’s going to be some level of being proactive in your, in your metrics, where it’s like, yeah, obviously, you want to do sales impressions, stuff like that person clicks on the pricing page. And then you’re going to have very reactive stuff, which is like instrumenting, the app, especially for performance or for like, degraded, like experience issues, you’re gonna go and do deep dives and bits of your app and be like, Okay, well, I’m really heavily instrumented in this section, because we know like me, and maybe through your other project Analytics that section is where people are dropping off and having bad experiences, all of our client libraries for all these companies that do this type of thing, we’ll start to be able to capture that context automatically, kind of like a Sentry type of thing, we kind of do this on the front end, where it’s like if there’s a Sentry exception thrown, we can send an event to and says, hey, this person has an exception, we do session recording. And so you can see like the entire front start to finish for that session like recorded from the DOM, if you haven’t enabled, and it will be like the person had this issue here. And we’re prototyping, sending the console logs as well from the front end. So like the front end is kind of like in terms of like web, I think you’ll probably see that happening more where events are just automatically the reactive events are automatically captured. Because there’s just so much context is available. The backend, it’s gonna take a little longer, but I do think there will always probably be some amount of reactive event instrumentation happening.

Kostas Pardalis 24:39
Makes sense. I think it’s also like in McDowell. Hall mature, like the procession that goes on in the product eats like, I mean, the idea of you’re like, Can the lifecycle of the bullet and you’re gonna experiment with victim of it every day, like, yeah, like, you don’t have the luxury of truth that I’m gonna be like, Okay, let’s simplify what I’m doing.

James Greenhill 25:00
Totally. You’re too busy building a product.

Kostas Pardalis 25:03
Yep. I’m too busy building the product and not to be like, also almost like, we don’t know what they’re doing. Yeah, no, no, you’re right. When it says like to figure out what I mean, doesn’t make that much sense like the start of the week, like notes, bring us options, and then trying to test them. And like all these nice things when you have found your product-market sweetens the already rating on this week’s show. What some other I think, important points for everyone to keep in mind.

Eric Dodds 25:34
I think we’re at time, actually. I think you actually have to go, unfortunately. James, this has been such a great conversation. We should keep going and going because it’s so interesting. Thank you for sharing. I learned a ton. And what a journey you’ve had. So congrats on being a PostHog, and you’ve done some really cool stuff that benefited a lot of people riding bikes around cities.

James Greenhill 25:55
Yeah, I love it. I actually rode a jump bike and or no one bike in today, here. It’s like visiting an old friend.

Eric Dodds 26:03
I love it. Alright. Well, thanks for joining us.

James Greenhill 26:05
Awesome. Thank you. Thanks for having me.

Eric Dodds 26:07
My takeaway is that James brought back he worked at two companies that sort of took me back, which is great. So one is Grooveshark, which was sort of like, one of the sort of post-nap, the first big post-Napster ways to listen to music online for free, which is super interesting. And then discuss, which was a commenting tool. And it’s interesting now because I remember implementing, discuss using Disqus, like, whatever corporate websites, but also like my own blog even. And it’s so interesting, because with it sort of came about at a time when blog comments, were still like a very dominant form of social media and social conversation. And it’s interesting, so you had this huge spike. And it was amazing that they had the biggest Google Analytics account in the world for a time and I think discuss actually a shrunk a bunch because so much stuff, social conversations moved so that was just super interesting. Like, I think that experience was really fascinating. And I appreciate that he sort of like, he took me back to think about that sorts of things. But I also thought it was interesting, just the way that he described some of the ways that they have to make decisions around trade-offs, right, like, even questions like, should a user be able to change data? It shouldn’t be mutable or immutable? I mean, those are monumental decisions for any analytics tool. And they’re not easy questions to answer. I just appreciated his articulate thought on subjects like that. So how about you?

Kostas Pardalis 27:37
Yeah, I mean, I really enjoyed the conversation that we had about like product analytics, and like, the whole process, and like the advice that he had to give up, how to go and implement, like tracking, and don’t create a mess out there. So it’s always good to see like, how, like, these discussions were to get their standard, like, no matter what the product does, there are always limitations. And people also need like to think and like figure out like the best way to proceed and implement their tools. That’s one and the other is Click House again, I mean, without it’s all over, over like we had another discussion about the big house. And again, it’s like so, so interesting to see tools out there that are open source and they feel so many different products. That’s amazing. So yeah, that’s the two main things that I keep from there. And his love for biking. He loves biking.

Eric Dodds 28:39
Yes. He loves biking. He loves biking. All right. Okay, several more great shows for you from Data Council. Stay tuned, 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, Eric Dodds, at eric@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.