The Data Stack Show - 152: Three Steps To Enhance Product Analytics with Ken Fine of Heap

Episode Date: August 23, 2023

Highlights from this week’s conversation include:Ken’s background and journey to Heap (2:32)Heap’s problem-solving approach (8:19)Auto-capture and its significance in the marketplace (13:03)Providing qualitative context: sessions and surveys (16:23)Collection and storage of data (25:42) Challenges of real-time data collection (26:40)The true gap in the market today (37:39)Consolidation and aggregation of data solutions (41:58)Simplifying the data stack (47:32)A different approach in engineering and software development (51:12)Skills and Stages in Company Growth (55:58)Final thoughts and takeaways (1:02:52)The Data Stack Show is a weekly podcast powered by RudderStack, the CDP for developers. Each week we’ll talk to data engineers, analysts, and data scientists about their experience around building and maintaining data infrastructure, delivering data and data products, and driving better outcomes across their businesses with data.RudderStack helps businesses make the most out of their customer data while ensuring data privacy and security. To learn more about RudderStack visit rudderstack.com.

Welcome to the Data Stack Show. Each week we explore the world of data by talking to the people shaping its future. You'll learn about new data technology and trends and how data teams and processes are run at top companies. The Data Stack Show is brought to you by Rudderstack, the CDP for developers. You can learn more at rudderstack.com. Welcome back to the Data Stack Show. We are talking today with Ken from Heap. He's the CEO at Heap. And Costas, I remember when maybe, I don't know if it's when Heap came out, but I remember really early days, Heap was a player in the product analytics space.

And one of the things that was really unique about Heap was that they offered auto-track capabilities, right? So instead of sort of, you know, anyone familiar with tracking data on a website or a product or whatever, you sort of instrument events and sort of track those, whatever, right? And Heap, you know, it's like, almost like Google Analytics, where you just install the script and it just collects all of the data,

every single user interaction, but as raw data, you know, that, you know, you can visualize, there's, you know, it's in your browser or whatever. And that is so interesting to me because having been in and around the space for a long time and even interacted with some auto-track functionality, it's phenomenally difficult on a number of different levels. And Heap seems to be the only one who sort of emerged from the analytics, you know, fray

who actually still does it, you know, and seems to be the only one who sort of emerged from the analytics, you know, fray, who actually still does it, you know, and seems to do it really well. I know this little background, but that's fascinating to me from a user experience standpoint, from a technical standpoint, from a cost standpoint. I mean, I just want to know how they did that. So that's my burning question. How about you? Yeah, Autotrack is very interesting. It will be interesting to hear from him

the story behind it. I mean, for me, first of all, we have outside of the technical conversation that we can have with him or the product conversation, we have also a very interesting person in terms of personal, professional journey. We have a also like a very interesting person in terms of like personal, like professional journey, right? We have like a person who did like crazy.

I mean, he left like the Navy to go and get into like technology. That was before the dot-com bubble, built companies, went public, ran public companies, and ended up going back to startups again. So it's one of these very rare, extremely rare cases where we have a founder

who has done the whole journey from beginning to end. And I think it will be very interesting like a founder who has done like the whole journey from beginning to end. And I think it will be very interesting, like to ask a few questions about that journey and ask him to share some learnings with us. 100%. Well, let's dig in and talk with Ken. Let's do it. Ken, welcome to the Data Sack Show.

Very excited to chat. Thank you. Great to be here. All right. And well, let's start where we always do. Your career actually started working on submarines, which is absolutely fascinating. So take us back to the beginning and tell us what led you to HEAP. Sure. I'd be happy to do so. So to chart the path to HEAP, probably the best place to start is college. So I studied engineering in college when I was a young kid, was trying to figure out how to pay for college. And one of the methods for me or avenues for me was a military scholarship. So I went to college on a Navy scholarship and then served within the Navy

as an engineer and a physicist as part of a team of people that designed propulsion systems for submarines. So during that time, learned how to work in team environments to solve complex technical problems. These problems were complicated enough that you couldn't go off by yourself in your cube and to your desk and figure it out. Loved doing that. Decided once my journey was complete with the military that I wanted to learn more about building companies that were based on technology-based companies and products. So my wife and I got in our car.

We lived in Washington, D.C. I worked at the Pentagon back then, and we drove to San Francisco, sight unseen. And I've been here ever since. I ended up going to business school out here at Stanford, and then have now spent the last 25 years in primarily B2B SaaS companies, all high growth, venture backed. And the common theme has been companies that are doing something interesting with large sets of data and applying some type of algorithmic IP on top of the data to help extract nuggets of value for the users. So that's a little bit about me and my

journey and what took me eventually here to Heat. Yeah. Fascinating. Okay. I do have to ask, did you ever get to go onto the submarine or were you just designing the propulsion systems? Because, you know, people say they're cramped. I guess the new ones are a lot better than they used to be. Oh, no, I went to go, I went to see on submarines, got to see the work that we were doing. And I got to go to the shipbuilders' locations where they built the submarines. So a big part of my life was back in D.C. at the Pentagon doing design work, but then we'd get out and go to Newport News Shipbuilding, electric boat where they built submarines and inspected and designed and test the work we did. We'd also get to work with the sailors themselves that operated these systems. These systems were remarkably complicated. So part of my job was to

run classes and teach people about these systems and then go to sea and see them operate. So I was fortunate that I would do that for shorter periods of time. I get to eventually go back home and sleep in my bed in DC, which my wife was happy about. Yeah. Yeah. I went to sea and, and also to the shipbuilding location. Very cool. Now I may be drawing too close of a connection, but it seems like that experience, did that influence the way you thought about customers, right? I mean, in many ways, the operators of the submarines, you know, in some ways are a customer of what you were designing and building. Did you take a similar approach when you got into software? In a way, I mean, effectively, if you look at my role, I described it as being an engineer,

being a physicist. I mean, that was the technical part of what we did so i was technically designing products if you will but if you really look at the actual work that we did it was part engineer part product manager like there there weren't product managers in that world so basically the engineers we were the product managers oh interesting so we were out with our customer i mean it's got a different environment. They're not actually buying products in that environment, but we're out with our which are the commanding officers, officers of submarines and the people in the, who are actually, you know, operating the submarines, ensuring that we understood their requirements and what they

needed to operate and to do so quickly and safely. And then we'd bring that learning back and say, all right, here are the things we need to do with our technical requirements. And then eventually we'd bring them back out and test our products with them to confirm that they work. So you can think of that as almost the equivalent of user testing. We were PMs, we were designers. I didn't know it at the time. We were designers and we are engineers as well. Sure. Absolutely fascinating. Well, before we go any further, could you give us just an overview of Heap? I just want to orient the listeners to what Heap is, what it does, and what problem we solve. You bet. So Heap is a digital insights platform.

So essentially what we do is we help our customers understand the digital journeys of their customers. So what are people doing within a web application or mobile or other, and then quickly identifying the opportunities for improvement. So that's in short what we do. And we make those services available to companies within multiple different industries and multiple different sizes from very small, higher growth, digitally native businesses, all the way up to very large, venerable enterprise companies that were started long ago, not digital, and have since transformed their business to work with a digital footprint. I know Heap's a big company and you serve a wide variety of different types of customers. Is there a particular set of personas or a persona and you serve a wide variety of different types of customers. Is there a particular set of personas or a persona that you serve who's performing a particular job function or is it sort of all over the board? The persona and the map, if you will, that we serve across a company has evolved over time.

So one way you could think of it is anyone whom you would characterize as a, we call them digital builders. You see anyone within an organization that is responsible for the performance and efficacy of some digital experience. So the actual titles that would commonly show up as

would be product manager is certainly common, and that would be more than half of our persona usage would be there. Marketers, very common, particularly when they're responsible for customer acquisition, digital customer acquisition. We're also finding now that customer success, customer support are common users as they try to decipher what's going on with their customers. And then if you think about this, if I were drawing this on a whiteboard as like a hub and spoke, you could think of all those business owners that I just named as spokes. One of the things that's evolved over time with the advent of Databricks and Snowflake are the centralized data and analytics teams. And we find that they have become consumers, a lot of the data that we capture, and they will look at it in different ways and do different types of manipulations than, let's say, a

product manager would. So now we tend to work closely with that centralized team, the hub, as well as those different business owners, the spokes. Yeah. Fascinating. I want to ask about the approach. So the analytics space is fascinating in general because it's been around for a long time. There are some gigantic incumbents and there are any number of ways to solve the problem. And so as I think about it, if you put this on a spectrum, you have maybe more blank slate type solutions. So this is just a tool that allows you to write SQL on top of warehouse data

and produce some basic visualizations. I mean, it's almost like a blank slate, right? Here's a BI tool and here's an empty dashboard. You need to write SQL and fill it on raw data. Then on the other end of the spectrum, you have, let's say, Google Analytics, for example, right? I mean, you can change some things, but largely here are your charts and this is what you get. What is Heap's approach? Because arguably there's value for different use cases on either end of that spectrum and there's sort of everything in between. So where does Heap land? That's a good question. It's one that we've thought about a lot at Heap. And I'll answer it in two ways or with two different frameworks.

The first, I'll start with the hub and spoke model that I just described. So in part, I believe the answer to that question, Eric, depends upon which of those persona you're trying to enable. So the way we've approached it at Heap is there's a particular solution that we provide for the hub, the data teams at the center, that's a little bit different and the philosophy is a little bit different than that which we provide to the business users, let's say a product manager or a marketer. So the way to think of Heap and the way we approach this is we have three basic elements to our solution framework. The first is how we capture data. And that's core to Heap's uniqueness and differentiation in the marketplace. So we have an approach to capturing data that the market refers to sometimes as auto capture or auto track.

It was a big part of how the company was founded, took years and years to get that technology to really work well. And you can think of it as like a digital vacuum cleaner. You install Heap, the vacuum turns on, we're inhaling massive amounts of data, which is basically every digital interaction, every click, every swipe on a mobile device, and then bringing that into Heap

and then saving it as long as the customer would like us to save it and making it available in real time. So think of that as piece one and that piece we can send to either the hub or the scope so centralized data team they want that data set we'll send it to them and then they could do a lot of complex manipulations with it or we can send it to the spoke to a product manager or a marketer now if we send it to a product manager the marketer they need to be enabled.

They're not data scientists or they're not usually data scientists. So that leads to pieces two and three of our framework. Piece two, one of the things that we learned, and this was something we implemented more when I joined and worked on and started working when I joined, is that capturing everything, or maybe put differently, everything is a lot.

You're capturing literally every single click and every single action. That could be overwhelming to a product manager or a marketer or a customer success manager. So what we have done to accommodate that is we have built from the ground up a set of data science capabilities that are natively built specifically to interrogate these massive data sets and look for evidence of user struggle. Anything that looks like there may be a reason to believe that a user is struggling to go from point A to point B, and A and B are defined by the product, the user. So, hey, I'm trying to understand this journey. We've created technologies now that hunt literally like digital flashlights.

They hunt through these data sets and they look for some evidence that, hey, something seems either really bad or really good. And over time, our heuristics become progressively more sophisticated. And we surface that to the business user and say, hey, we're going to shine the flashlight over here. Maybe a spot that you may have expected to be searching in, or maybe something completely out of your purview, maybe a blind spot. So now you've got a source of truth and data that gets sent to the centralized data team, gets sent out to the PMs and the marketers. Then you got the flashlight that helps you identify what to look at.

And then the third of three parts to our philosophy and model are, okay, once you shine a flashlight at something, essentially what we're doing is we're identifying a friction point or perhaps a success point, but you don't really know what's going on there. You just know it's something probably worthy of attention. That leads to part three for us, which is to provide qualitative context. By that, what we'll do is we will serve up a personalized playlist of sessions or videos to watch. So now you can say, okay, what's going on at this point of friction?

And we will serve up the sessions. We'll fast forward to the point of session that you should be looking at. And then we're also integrating within application surveys. So you can read, you can get sentiment and emotion around those friction points.

So essentially now we're building this broad digital insights platform. But to your question, we serve, let's say, a centralized data scientist in a way that's a little bit different than how we would serve a product manager or a growth marketer. I'll pause there. Yeah. I mean, the first thing that really strikes me about this approach is that it's, let's call it a suite-based approach.

And so maybe the most blunt way to put it would be that in each of those categories that you described, there are entire companies who just focus on that single problem. That's right. And so interested to know the thinking behind the suite-based approach. Like, you know, I mean, the data capture to the different personas makes a lot of sense. But yeah, can you explain the suite-based approach? I don't know what you call it. That's just my term.

Yeah, sure. I think a suite is certainly a fair way to describe it. You know, like many companies, we refer to it as a platform. So our digital insights platform. So the approach and the thinking behind it is this. As we, so Heap originated, if I were drawing here, I draw a little Venn diagram

and I would draw as one circle product analytics. So that's one part of the data analytics stack often. And that's classic, you know, analyzing journeys and where people get stuck. And that's where Heap was born. So if you do, if you had to go look up a report, an analyst report and product analytics, you'll see Heap there. And you got another circle in the Venn diagram would be session replay and associated tools there. And there's organizations that grew up with. And then the third of three circles I would draw would be voice of the customer or within application feedback, you know, basically capturing commentary.

So, you know, those are three important and heretofore distinct, you know, different ways to understand and interrogate what's happening digitally. And I, in a previous life, was a head of product at Medallia, a voice of the customer business. So I understand that space well. So the observation from Heap was we started in product analytics. And of course, you know, we started in product analytics and of course, we use our own product and we observe our customers using our product. And here's what we observed.

People would use Heap and then eventually, hopefully, they would find something that's worthy of understanding better. They'd say, okay, something's happening here. There appears to be either an issue, meaning a lot of people are getting stuck or the conversion rate is low in this journey, or perhaps it's really high. Wow, look, people are flying through this use case, but we don't know why. You do not have any qualitative context. So people would leave Heap. So if you will, you know, log out of heap or step out of heap and move into a session replay tool or go over into a voice of the social sites trying to find something match up this pain point, this friction point with these quotes or with these sessions. So then we started to interview our customers

and we found they were doing the same thing. And then either, or they had tried it and it was so onerous that they stopped doing it. So we developed a point of view that, okay, the way the industry started was these were hard enough problems that they required separate companies. From almost a Darwinian standpoint, they shouldn't do it all at once.

But now we've reached a point where I think the actual optimal solution, it actually is a one plus one is more than three, where you need context. You need some way to identify friction points with analysis. And then you need to quickly and seamlessly be able to understand the context of the friction point that you're observing, which is largely watching a session, watching an experience and then hearing sentiment. So the way we approached that was through acquisition. So we then said, all right, we're very strong in this product analytics category. We've got great technology there. Let's go find a company that we believe has excellent best-in-class technology in one or more of the other areas with compatible, integratable code and a strong team. And we did that by about a year ago now,

acquiring a company named Auricic they were strong in session replay they were strong in within application feedback that team came to heap great technical capabilities and we've now been integrating that into a single platform last comment and part of our philosophy is we're not trying to replicate every feature in a session replay platform or every feature in Qualtrics or Medallio or pick the market leaders and voice of the customer. We're looking at the subset of things that we think provide mutual context. So that you have a, you know,

truly the ability to interrogate a data set and get the context of the things you're finding quantitatively. Fascinating. I want to go a little bit technical and jump back to one of the first things that you made a comment about, the first category. So auto-capture or auto-track. And this is interesting to me as a user because when this came out, you know, I remember, you know, testing heap out very early on, a number of other players had auto track auto capture solutions. And it's a pretty gnarly thing, because, as you said, it's a lot of data. You know, it's, you know, you're definitely going to get something that you want. But you're also going to get a lot of things that you don't know if you want. And then certainly a lot of the tools, most of the major players in the market have abandoned it.

And Heap is really the only one that I know of that sort of emerged as, you know, a market leader who does auto capture. So what's the secret? Because I mean, it's a little bit gnarly to use or was like very early on, but I can't imagine what it's like under the hood from your standpoint. Yeah. It's a good observation. And I chuckle a bit because I reflect on my journey to join a heap. So I'll answer it in this way. from someone who was an executive coach of mine years ago and was also the executive coach of the founder and at the time the CEO of Heap. He said, hey, my previous company had been acquired and I

was thinking about what's next. He said, hey, what do you think about potentially looking at this company and working with Heap? I said, I know of Heap. Let me refresh my memory and took a look at the company at that time, which was 2018, 19. And my takeaway was I literally went to the website and thought, what an amazing data set. Like what an amazing thing having come from being a product manager and a head of product and at companies that were very data centric. So what an extraordinary data set. And at that time though, and this is going to be part of the answer to the question, the offering was quite different. It really was just the, if you think about the description I just gave the framework,

it was just the vacuum cleaner part. So it was just auto track or auto capture part. We hadn't built the rest of the platform yet. And it was a big part of the vision of the founders, which was, hey, there must be a better way to capture information than to be manually collecting it. So they spent a good six, seven years just working on the vacuum cleaner and the difficult parts. You said, you're right, it's gnarly when you get

under the hood. Difficult parts were one, how do you collect this size of data, this volume of data in an economically viable way, like without just tanking the financial metrics of your company? That was my next question. So as a little humorous anecdote in the early of Heap, I think our gross margins were negative. They weren't. Which is, that's a little bit scary in SaaS.

Yeah. So it wasn't that they weren't yet best in class, 70%, 75%, 80%. We actually, it cost us more to save the data than it did to serve a customer. But the team at that time was quite resolute in coming up with different data compression methodologies. And as our former CTO at that time said, hey, it was not one single breakthrough. It was years and years of attacking the problem to finally figure out how you get to a point now where we have very good margin structure and we can save that data. And then the other part of the technical problem was how do you do that while making the data actually available in real time, all that data? So it's not just you claim auto-capture,

but you want to do an analysis and you set up a query and it takes an hour. Like, no, it has to be there in real time. And how do you do it in a way where it's, you're respectful of privacy and security requirements if you want to serve large financial institutions and organizations like that. Sure. And how do you do it in a way that doesn't slow down the host application? So just a whole raft. So the learning was it's a full stack technology problem. It is not a feature you turn on.

You almost have to build from the ground up with that ambition. You don't retrofit, auto track, or auto capture. And it literally took a whole company, you know, five to seven years to get to a point where that was viable. Now to just fast forward, though, when I joined, there was still a problem, which was, okay, so we've made a lot of progress on how do you capture that data and store it in an economically viable way and in a way that respects PII. But you still had the issue of that's a lot of data for a product manager to interrogate.

And I came in, that's when I began to assert the point of view of, hey, let's move this company from being a vacuum cleaner to adding the digital flashlight and start building out the data science capabilities so that we can start to proactively surface the right insights. And then that took us to the next piece, which is, hey, now let's integrate session replay and within application feedback to provide the context. So it's this dual responsibility. You want to capture all this data so you have a source of truth.

So as you said, you're not missing anything because you're not sure what to collect, what not to collect, but then you have to provide an assist through analysis and data science to quickly find the needle in the haystack, quickly find the hidden gem so that you're not searching aimlessly and collecting data you don't need. Absolutely fascinating. What a story around the vision of the founders just committing to making auto capture work and then actually doing it over a multi-year period. I mean, anyone who's been involved in SaaS knows that's not just the technology that's dealing with investors, trying to grow

the business at the same time. I mean, I can't imagine. So what a story. Well, I've been holding the mic hostage. So Costas, please jump in. I know you have a bunch of questions. Yeah, yeah. Thank you, Eric.

So again, I'd like to go through the evolution of HIP since the day the company started and until today. And you mentioned already some very fascinating details about that, like the obsession of the founders on how to compress founders on like how to compress the data, how to store the data, how to manage the information from the infrastructure point of view, and how you go from there to the product. And that's where like the margins also start to appear, right? Like it's not solving a technical problem anymore.

It's also like solving like the customer problem. But it's been a while and it's been like a very interesting period of time, right? Like there are many things that happened like in these past, like 10 years, right? Like nine, 10 years. Especially like in this industry that has to do with data. So can you take us a little bit like through the journey of Heap together with like what happened in the industry together with what happened in the industry and how what happened in the industry affected also HIP and the decisions there on where the product and the company should go.

Yeah, it's a fascinating question. It could be a full day offsite, I think. But I'll give the short version, the concise version, and then we can dig in as you like. So I think the original vision at founding was not ultimately that different from where we are, meaning the idea was, hey, let's capture a source of truth and ultimately enable and empower the business users so that a high level has been a consistent compass for the company. I think that as far as how that has evolved and how it has in the context of the evolving data ecosystem is, I think, a few things. One, going back to the question Eric asked, I think it was a more challenging technical solve and then in concert with that business solve than anticipated.

It's like, this is a really hard technical problem and you've got to build a business in concert with that. So there was just a time, a duration of investment. But the initial focus was, hey, let's go after the product manager first, where we thought that was the primary landing persona, if you will. And then one of the things we saw in the industry over the last several years as Databricks started to, and Snowflake, and that whole world started to evolve, we saw, one, a change within organizations where now a whole new set of personas started to emerge, which were the centralized data and analytics teams,

which back when Heap was founded, in many cases, just didn't exist. So now you've got a new group and a group that's quite influential. So they may or may not be the buyer for Heap. Sometimes they are, sometimes they're not. But they're a key influencer in trying to create homogenous and scalable data practices across an organization. So they became for us now a key partner in the process of, what do you want to talk about? Economic selling or just enabling the success of the organization.

And they became a consumer in that, in addition to starting, as I said, with the focusing on product managers, we learned like, okay, we're going to have to really evolve to this hub and spoke model because there's a desire in the part of some very sophisticated users to take the data, take our data, which they find to be very valuable, this source of truth on what's happening from a digital interaction standpoint. And they want to join that data with their own data, transactional data, demographic data, other signals.

So now we've spent a lot of time putting that data into a format that can be easily consumed by those teams that years ago didn't exist. So now you're a PhD data scientist working with a data engineer, connecting our data to other of their own data and then doing some really powerful analysis that would be beyond the scope of what you could do with heaps ui and what you would expect to see from let's say a product manager or a marketer let me pause there yeah i okay i would like to talk a little bit about, let's see, you mentioned two terms. You said, like, PM first, and you wanted, like, the strategy at the beginning was to go after, like, the PM persona, right?

But many times, like, when you talk, you use the term, like, business user, right? Which, obviously, like, is a much broader persona inside the organization. And it makes me like what happens in my mind is that the next thing that I think of when I hear the term like business user is BI, right? Like there's always, there was always the need since we had like technology out there, like to serve the business with some kind of like insights and reports and like all that stuff, like to help drive like the business. And that's like what I always think of like the business users.

So what I want to ask you, and this is like more of a question of trying like to time travel ourselves back to the beginning of the heap, not today. Was there a thought back in the minds of the people that what we are actually doing here is actually BI? And the PM is, let's say, our vector to get into the BI space because that's the opportunity today. But at the end, that's what we want to go and dominate out there. We want to become the next innovative solution of how business intelligence is delivered to the business out there. Or it was something else completely different to that?

That's an interesting question. I think we're, you know, BI is an interesting term and I'll share how we think about it and then we can dig into it. So I've got two comments. One, Kostas, you picked up on the, where I use the term PM

and then also use the term business user. So one, in the context of this evolution of digital experiences has evolved in a way where seven, eight years ago, we were focused on product managers. Now there's so many different persona that have responsibilities for digital experiences, marketers now, customer supports involved, customer success that we have evolved from that more narrow bullseye to a broader one. But as it relates to BI, here's where we draw the line. And not everyone in our space, I think, would draw it where we draw it.

We think there's one level of capability, which is more around, I'll call it standard performance metrics and dashboards. And when you say BI, or if you were at Heap in a product team meeting and you use the word BI, we would lean, we would infer that something more in that camp. Like, hey, give me the KPIs for this journey and where's it performant? And usually in that case, you can identify the steps in the journey you care about and what kind of conversion targets you have

and create dashboards for that. And certainly Heap can do that, but Heap is not uniquely good at that in our opinion. So we have decided we do not aspire to be a classic dashboarding BI tool, which by the way, is a very valid strategy. There are competitors of ours that have taken that strategy. The approach we've taken is that the true gap in the market, the true hole that's been out there is the ability for the, I'll use again the word digital owner, the people who own the experience to be able to, with very low friction,

interrogate that experience and find friction points wherever they may be. And often they live in places that you didn't expect. So unlike a B2 tool, which is more of a standard, along a journey, hey, what percent of people get to steps A, B, C, D, E, and F, we're almost helping people look around that and off the tributaries of that journey where you would have never thought to look. And we've got a system that's designed to hunt through all those journeys and surface the ones that matter. So perhaps in your definition, that could still be BI, but that's the separation we make. We're not going to be

a world-class executive dashboarding tool, at least not in the near term, but we are going to be best in class in enabling a digital owner to find what matters within his or her digital experience. Yeah, yeah. There is a reason I'm also asking,

and I'm being also a little bit provocative, to be honest, because in these past 10 years, there are many cycles in different tooling around data. We had the moment of BI in a way when Looker got acquired. And then suddenly everything went quite silent. And if you think about it, we live right now, like at the beginning of, I don't know, like, let's say like another revolution around like data and a lot of

things happening in pretty much every aspect of, let's say the data industry, if I can call it like that. But BI is still silent. Outside of like a couple of like companies that they are trying to figure out how to merge, let's say, the experience between notebooks and SQL or like dashboards and these kinds of things that still they don't get enough attention compared like to other things that are happening. Since what happened like with Looker and the consolidation there, like in the BI space, I haven't like at least heard something like happening and I'm like wondering like

where the next wave of like innovation is going to come there because there is like a lot of opportunity, right? Whenever like the fundamentals change, everything follows, right? So like visualization and the way like people like interface with the data is like very important. Anyway, that's just like to add, a little bit more context on my question here. But something else that I heard during, like, your conversation with Eric, you talked about, like, the difference between, like, the platform

and having, let's say, like, one platform that serves, like, many different, let's say, functionalities and having, a more disaggregated kind of like architecture. That's like, to me, like it's very interesting because if we again go back to the data industry, we'll see like this paradigm of like the modern data stack as it's like called, let's say, where pretty much what the data warehousing infrastructure for a company was like 20 years ago has been broken down into like very small pieces, right? And every piece of that is like a product category with, I don't know how many vendors, right?

Yeah. To the point that like the data professionals out there, they have started like experiencing like fatigue around that. Like, how do I choose what I'm going to use here? Like, it's just like crazy, right? And my feeling, and I'd love to hear your opinion on that, is that we will start seeing a reverse in this paradigm and start seeing things coming together at some level at least.

Not necessarily like everything would be a huge monolith, but some things will come again together. What's your opinion on that? And how do you feel like this platformization, let's say, of HIP was actually also affected by this whole experience of disaggregating the whole data infrastructure over this past couple of years? Yeah. Yeah, interesting. So here are my thoughts, and I'm going to take your question, Kostas, and I'm going to also link it to the current macroeconomic environment. and times of consolidation and aggregation.

So I think we've gone through a period up until, let's say, about a year ago where there's a lot of investment in technologies, capital going into companies like EAP, developing, in many cases, point solutions. So lots of different ways of contributing to the patchwork quilt of, and the case where I live, the data stack, the modern data stack, our digital analytics data stack, our digital analytics data stack. And what I see now is I think now we're going to be shifting into a period for some period of time of seeing natural points of aggregation, consolidation, where there are adjacencies that make sense and where because of the macroeconomic pressures, it doesn't support the same number of smaller point solutions who are all trying to make a kind of a very localized value proposition.

It's just not sufficient. There's not sufficient demand. the idea around, okay, there's a set of solutions out there that are quantitative, meaning they take data, they do analysis, and they give you some type of quantitative output that says X percent of people or users move across this journey in this way. And then there's another set of solutions out there that are qualitative in nature. When I say qualitative, they are giving you information for human interpretation, such as, hey, watch this session or watch this experience or read these quotes. When I was at Medallia, that's quantitative analysis applied to qualitative content. And I think what we're

going to see going forward is the consolidation and aggregation of quantitative and qualitative. And then we're seeing data science and AI starting to sit on top of that set of quantitative and qualitative data to provide synthesis. So we start to bring those together. It makes total sense. Okay, one last question about the industry, and then I'd like to change the theme a little bit. So Heap was part of like let's say a

wave of companies that they came out of the sas revolution let's say right like was the time that like of sasification let's say of the world right yeah and we had heap we had mixed panel we had heap, we had mixed panel, we had ambling queued, right? Yeah. I'm mentioning like these three because there is like a common pattern there. In terms of like the persona that is addressed, like all three of them, they tried like to go after like the PM. They need like for product people to have like insights, track data from mobile was also like, like this enormous amount of data coming from mobile at that time. So Amplitude went public. How do you see this group of companies? What's the

future, let's say? And by the way, I don't see, and I'd love to hear your opinion on that, because that's going to give us, let's say, the bridge to the next questions. It's not that going public ends the journey, right? So it doesn't mean that because Amplitude made it to the public markets, it means that they have figured out everything, right? Right. They are still trying to do that. So there's like, everyone's trying like to figure out like their unique value proposition there. But where are these, let's say category of products going to based on like your experience

and okay, obviously like with the amount of bias that you can have being like the CEO of one of these companies, right? But it would be great to hear hear how you see the things for this category of products. Yeah. Also a good question. So my thought, I mean, I'll bring my answer back to the previous theme around natural points of aggregation in the space. So I believe there'll be pressures in this space in part because it's better for the user and more economic for the buyer, particularly during a time of macroeconomic pressure to bring together some of what historically a heap or an amplitude and a mixed panel have done in the category often called product analytics and quantitative analysis with what other companies have done

in the area of qualitative and session replay and voice of the customer. And I think what you're going to see is pressure to bring those into single platforms so that customers do not have to have multiple purchases, multiple products. So that's expensive. And then for the user, it's cumbersome, as I said, because you're floating, you're basically trying to piece together a puzzle of digital journey. What can I get out of Amplitude or Mixpanel or Heap? And then what do I get from these other platforms? I think you're going to see constant pressure to bring together, again, this kind of classically quantitative analysis with qualitative.

That's piece one. The other pressure I think you're going to see is pressure from the marketplace to, pardon the pun in advance, but to decrease the friction of finding friction. It just needs to be easier to collect the data and interrogate the data. And if you're looking at total cost of ownership as a customer, you're looking at the whole thing. You're looking at, you know, not just what happens once I have the data. Well, how do I get the data?

And let's say in the case of you picked mixed panel amplitude, that's usually a separate solution. So it's you need mixed panel amplitude and something else to collect the data to give to them. Then you've got them to do the analysis. And then you've got, as I said, probably some qualitative tools to understand it. So you're trying to simplify that data stack and decrease the investment you need to make in your own internal resources, your own engineers to piece that together. I think that's going to be the nature of the pressure that we see in this and we see in this market. Yep.

Makes total sense. That's like some great insights. All right. I have two, a little bit more personal questions. Okay. And then I'll give the microphone back to Eric. First, I was listening to you, like, telling your story about, like, how you started with being, like, in the Navy, doing engineering there, and then moving into, like, Silicon Valley and, like, into, like, building, into building software businesses. And being a person who has gone through the transition of being an engineer and then trying to get into business,

and I know the struggle that an engineer can have because engineers, especially good engineers, that they are solving real like real complex problems right like they need to build like a very structured and a very let's say uh predictable way of thinking right like there is a cause and effect there there is a system and we need like to define the system and make sure that there's no like dimensions that we haven't, like, understood well, right? And put, like, into, like, our designs. Yeah.

And I bet that building propulsion for, like, submarines is, like, to the extreme of these problems, right? Like, you have to be very, how to, like, detail-oriented. Like, you deliver something and this something needs to work, right? Like, you cannot send your sailors down, like, into, like, the water something needs to work, right? Like you cannot send your sailors down like into like the water and as MVP, right? Oops, it doesn't work. Okay.

Let's iterate on it. Like, no, you can't iterate on that. So I'd love to hear like how you experienced that transition from being, let's say in South, like a serious, let's say engineering South like a serious let's say engineering environment going to the MVP to the extreme of like fake it till you make it kind of modality that like software gives us the opportunity to have right because it's safe to make mistakes there like no one is going to die in many cases at least, not always. So I'd love to hear how you experienced that and how you did it because it's hard.

It can be mentally painful. Wow, that's an awesome question. I don't think I've ever been asked it before and I have a point of view on it. So you're right. So in my first life designing propulsion systems, the whole organization, the whole culture was very different than Silicon Valley in the sense that people's lives actually were at stake. Like it was real. It was not hyperbole. If we made mistakes, people could get hurt.

This is nuclear technology being operated on a submarine at sea. As a result, we had incredibly high standards for technical quality and lots of processes. You can call them forms of quality assurance, I suppose, but lots of reviews and ways of inspecting our work to decrease the likelihood that we made a mistake. So, and to put that in context, when I worked at that first job, I think the time from beginning the design of our product, which was a submarine, to launch was a decade and years to launch your product. And then when I came, so now fast forward to your question, I came out here and wow, okay. First of all, for the most part, lives aren't actually at stake.

I mean, someone's not going to be injured when they're using most B2B SaaS platforms if there's an issue, perhaps in some, but most not. And the need for speed and agility and iteration was much different. So my learning there came at my first company. I was at this company, Financial Engines. It was founded by a professor that I studied when I was at Stanford Business School. And the learning there came through failure. So we started ultimately being a successful company in the first several years. We started as a B2C platform and had some really interesting ideas for features and capabilities that came from his research that ultimately were not out, when you're in the blueprint stage and need to be hyper agile.

And you need to be basically testing before you write code. So a lot of that's more mainstream today, but it required a change in culture, attitude, skillset, a complete revamp of our whole product development process to kill all the waterfall stuff that was in existence back then. And then it basically turned on its head. So it did require for me to almost reinvent myself because all the things that had worked for me for so many years actually not only wouldn't work for me, but could create the opposite outcome.

You know, could drive an organization to be too slow and too rigid and unable to be successful. Yeah, 100%. Okay. That was like a super interesting. All right. My last question, and then I'll give the microphone back to Eric. So again, it's a question about like your journey. You've done pretty much everything that someone, let's say, can achieve, like

as part of like being an entrepreneur. You started companies from scratch, went public, had to be part of running a public company, and then went back to a private company. People usually, especially people who haven't done that, probably they think that this is a very linear thing. The holy grail is to go ring the bell and then you're done. You retire, blah, blah, blah, I they think that, like, this is, like, a very linear thing, right? Like, the holy grail is, like, to go ring the bell and then you're done. You retire, blah, blah, blah, I don't know, like, whatever. Then you are, like, you did it. But my intuition and, like, okay, I haven't done it, but, like, that's how I think about it based on your example,

is that, like, things are not as linear or simple as we would like to think. So can you share, because you have, like like a very unique experience with that, right? Can you share like some insights on that? Like what's, I don't know, anything that you find like interesting to share with the people there from just like, what's the difference between like being part of a public company or like starting a company or what made you personally from being like in a public company going back to a private company? Anything that you think like could help anyone who is starting a company or like just like

being interested in entrepreneurship? I'd be happy to. I have developed a point of view on that. So I would characterize it this way. So the first big chunk of my career, like it is for many people, was more organic, meaning I didn't sit down with my guidance counselor when I was 15 and said, I'm going to go serve in the Navy and I'm going to go to Silicon Valley. Obviously, that would have been an unusual map to know ex-ante. But

here is the learning, the point of learning for me, and then the direct answer to your question. So when I got to a point in my journey where I was at this company, Financial Engine, as they were public, and it was time for me to decide what to do next. I guess it could, to your point, could stop working, could go on to another large public company and continue the journey to something larger. Or I could start a company or go to a growth stage company. And here was the learning that I came to by talking to a number of people. And then I decided to make an explicit or intentional part of the rest of my journey. And the learning was this, that there were two things that I was solving for. One was a learning that the types of skills that you need to be successful, effective as a, regardless whether you're an individual contributor or a

leader in companies at different stages are actually different. It is different being in super early stage, call it pre-product market fit, pre-revenue growth. That skill set, I think of as a detective skill set. Your job is to find, the market calls it today, product market set. You're on a mission and you're interrogating and hypothesizing and experimenting and finding hints and signal. And that's a really unique and powerful and hard to come by skill set. There's another skill set that I'll call growth stage, which is, hey, there's something here. Like we have something repeatable, maybe to a certain, not to different degrees, but we have some level of a product that can be offered in a certain way, like with a value proposition that

people purchase and then they use to a degree of success, now we need to improve and scale that. That's a different set of skills. I mean, it's not that there's no overlap between the skills, but it is different. And then that set of skills starts to get into pattern recognition. Like, you're growing so quickly that it helps to have developed some notion of what does it look like to have a SaaS company with professional services? Or what is it like to sell to a large enterprise or to do product-led growth? Like having seen it before matters. So my learning was this, that led me to actually go from a public company back to smaller was I decided I needed to make

two decisions. One was, what's the stage that I want to become good at? What's the skillset I want to reinforce? So I made a personal decision, which resulted in me not responding to a lot of inbound opportunities for jobs, was I want to get really good at growth stage. I like that stage. There's some low product market fit.

Now we got to scale it. So I'm going to hunt for that opportunity. The second is what's your functional area of expertise? Do you want to be great at product sales marketing? So think of that as like a X, Y axis. What's your functional bullseye? What's your stage bullseye? And then try to get really good at that quadrant.

That's, that was my learning. And that's why after the first company, I've done growth stage over and over again, trying to get better each time. Yeah, that's an amazing framework, by the way. And thank you so much for sharing that. It's going to be valuable for me also. So thank you so much.

Eric, all yours. No, that is an amazing perspective, Ken. I appreciate you so much. Eric, all yours. No, that is an amazing perspective, Ken, and appreciate that so much. We're right at the buzzer here. But one thing I'm really curious to ask you just on a personal level, you know, if you've worked, you have an interesting perspective, because as you said, at the very beginning of the chat, you know, all the contexts that you've worked in have been using some sort of AI layer to uncover insights from large datasets. And of course, you're excited about Heap, but what other new things out there excite you in the analytics space in general?

I mean, LLMs is sort of an obvious one, but you bring a perspective of 20, 25 years sort of doing this and have really seen the entire industry change. So I'm personally curious what things get you excited. Yeah, I don't mean to be underwhelming, but LLM, what's interesting about it rather than just picking it to me is, and the way we're looking at it, is the challenge and a big challenge in the data space, certainly for us, has been, it's essentially, it's the application

layer. How do you make, how do you enable people who aren't data scientists to make sense of data? And that's hard. It's really hard. If everyone had some combination of a computer science degree and a data science degree, you can just a bunch of data and query tools and say, knock yourself out. But that's not the world we live in. So we're looking at basically LLM as a way to enhance, amplify, assist, or maybe even eventually replace the classic UI layer today and just completely rethink how you interrogate datasets. So that's what our team is working on. And then the other for me I've mentioned is, I think the other trend is the world of hardcore quantitative analysis and just looking at journeys and nutrition rates and the world of qualitative context and user

testing and human judgment have largely been separate. They've been separate jobs. They've been separate tools. Companies. Entire companies. You're right. And I used to actually, I forgot about it, when I was a product manager, I used to give talks on the integration of Quant and Qual and say, hey, if you're a great product manager, it's just back then the tools were Quant was pull some log files and do some analysis, and Qual was go interview people. And by the way, I think interviewing people is great, but now technologies are arising. And I think the other trend you're

going to see if we fast forward a bunch of years is basically integrating those data sets together and extracting wisdom from the combination of the two. Love it. Well, Ken, this time flew by. Amazing conversation. Thank you so much for giving us a few minutes of your time. Eric and Costas, thank you very much for having me. It was great to be here. Okay. Fascinating show with Ken from Heap. Costas, I think my big takeaway was his answer to my burning question around Autotrack. And the story around the heap founders' commitment over a long period of years to actually make that a viable solution with all the engineering problems involved was a fascinating story, right? I mean,

you have security concerns because you're auto-capturing all of this data. You have severe gross margin problems because of the amount of data that you're actually collecting, right? And you have to put that somewhere. And so compression issues, and I mean, pretty wild. And then you actually have to make it usable for someone. And you're talking about, you know, truly a fire hose of data. They've done it really well. And that was just a great story. Of course, the engineering parts are interesting, but the commitment to a vision by the founders, especially the technical ones, was really a great story. I mean, definitely a must listen to.

Yeah, 100%. It was a very, like, extremely fascinating conversation that we had at many different levels. I agree about AutoTrack. And, you know, like, AutoTrack is, like, one of these very interesting problems because it's extremely easy to implement. I mean, at the end, like all you need to do is like just capture

every change on the DOM tree. Uh, but it's extremely hard to make it work at the end for the user. Yeah. Like it's there's like a huge distance between like the basic engineering work and what needs to be done on top of that in order to make this feature something that actually works for everyone. So that's one thing. The other thing that I keep from the... There are two other things that I keep from the conversation with him.

One is the part where we were discussing about this whole process of going to a market states in the past couple of years where like we had like this boom of like all these tools coming out there and how now we'll be getting into like an environment where we will see more integrated solutions instead of like all the different, like every possible feature being the product on its own. And he gave us like some very interesting insights there. And the other thing is what he, he talked about like the different types of people that are needed at different stages of the building of a company.

I think that resonates a lot also with the founders of HIP. And that part was extremely interesting. I'm not going to share more because I think like I'd like to listen to him, what he has to say. But that part was like very insightful for me. Yeah, I agree.

Also a great tidbit for anyone interested in what it would be like to be a product manager slash engineer for submarine technology. That was a really crazy story too. So definitely take a listen,

subscribe if you haven't, lots of great episodes coming up and we'll notify you in your favorite podcast app. Tell a friend and we will catch you on the next one. We hope you enjoyed this episode of the Data Stack Show. Be sure to subscribe on your favorite podcast app to get notified about new episodes every week. We'd also love your feedback.

You can email me, ericdodds, at eric at datastackshow.com. That's E-R-I-C at datastackshow.com. The show is brought to you by Rutterstack, the CDP for developers. Learn how to build a CDP on your data warehouse at rudderstack.com.