SFG 21: Barry McCardel on data collaboration

‍

In this episode of the Startup Field Guide podcast, Sandhya Hegde chats with Barry McCardel, CEO and co-founder of Hex about the company's path to product-market fit. Hex is a data platform that allows teams to streamline their entire workflow using collaborative notebooks, BI, and docs. Hex offers data scientists the ability to work together to deliver their insights and empowers both business users and data analysts to quickly find the answers they need to do their jobs. Today, the company has over 500 enterprise customers. 

‍

Be sure to check out more Startup Field Guide Podcast episodes on Spotify, Apple, and YouTube. Hosted by Unusual Ventures General Partner Sandhya Hegde (former EVP at Amplitude), the SFG podcast uncovers how the top unicorn founders of today really found product-market fit.

‍

If you are interested in learning more about the topics we discuss in this episode, please check out the Unusual Ventures resources on identifying early adopters, building a product roadmap, and hiring an early-stage team.

‍

TL;DR

‍

Identifying the opportunity: Barry and his co-founders realized that there wasn’t a collaborative solution for modern data teams to share their work and interact with other members within their organizations. The existing solutions were fragmented and made sharing difficult. 

Founding insight: Hex’s founders set out to build a collaborative platform that offers data scientists the ability to work together to deliver their insights and empowers both business users and data analysts to quickly find the answers they need to do their jobs.

Prototyping a solution: While Hex’s founders had a big vision, their initial product focused on allowing data teams to share and communicate their work. They built a prototype that allowed users to take a Python notebook, input parameters, and then publish it. 

Iterating to product-market fit: Early customer feedback help the Hex team realize that customers wanted an end-to-end workflow that would allow them to do all their work within Hex’s platform.

Process for finding product-market fit: Barry advocates for a process called “commitment engineering” which involves finding people who feel a problem acutely and asking for non-monetary commitments like feedback sessions or testing a prototype. It's important to validate foundational assumptions early rather than spending six months building in a hole and then trying to sell it. In discovery calls, founders have to become comfortable with ending meetings if they find that a prospect is not completely interested or ready to adopt their solution.

Product-market fit changes and evolves: Hex is continually being adopted by customers who are not strictly on data teams. As its customer profile grows, the company’s notion of its product-market fit will need to adapt to the shifting needs of these new customers. PMF is not a milestone, but something that needs to constantly evolve depending on who is adopting the product.

AI strategy: Hex's AI strategy is focused on empowering people working with data and allowing them to focus on creative work while partnering with AI to abstract away tedious tasks

‍

‍

‍

Episode transcript

‍

Sandhya Hegde:

Welcome to the Startup Field Guide, where we learn from successful founders of unicorn startups how their companies truly found product-market fit. I'm your host Sandhya Hegde and today we'll be diving into the story of Hex. So launched in 2019, Hex is a modern collaborator platform for data teams. Hex has over 500 paying customers, primarily data scientists and analytics engineers who really love this product. They can use SQL, Python, R, or even just drag and drop some templates. They can do everything from building simple dashboards to complex applications on top of their data that anyone else can interact with and build on. So love from this user community is so strong that despite Hex not technically being a unicorn yet, I just had to get Barry McCardel on this podcast to ask him everything about how his team has built Hex. Barry, welcome to Field Guide.

Barry McCardel:

Welcome. I'm honored to be a pre-unicorn exception. Thank you for having me.

Sandhya Hegde:

Well it's 2023, not 2021, so-

Barry McCardel:

That's right.

Sandhya Hegde:

...the bar is different.

Barry McCardel:

...these days.

Sandhya Hegde:

The bar is now do you have 500 paying customers? Not what silly VCs like us have valued the company.

Barry McCardel:

Yeah. Yeah. All right, cool. I'm glad to be here.

Sandhya Hegde:

All right. So Barry going all the way back to 2011, you started your career officially as an Excel jockey at PwC. What was that like? And help us connect the dots from there to you saying, "Okay, I'm going to start this company called Hex." How did it happen? What was the original insight behind Hex?

Barry McCardel:

So I had no idea what I wanted to do in undergrad. I was at Northwestern. There were a lot of things to explore and try. I actually spent most of my time producing concerts and speakers. So not a super clear throughline, but I did get really involved. I took this class in social network analysis. This was like 2009, 2010. So it was social networks as a concept and that idea of that being a thing to analyze in network science was really taking off and it was really cool. And I actually wound up spending time in a lab, a research lab there called Sonic where we did a bunch of... And no one really called it data science at the time — that hadn't gotten super in vogue — but basically data science on network data. So these could be networks like you think of a social network like Facebook, or we even studied things like research collaboration networks and healthcare networks.

‍

So there's a lot of interesting stuff there and so I just got my eyes opened to this whole world of data stuff. I had always been kind of a nerd and it was really cool. I was starting to write some stuff in R. I was doing a bunch of stuff in spreadsheets. We had built some of our own software in this lab. I still had no idea what I wanted to do after college and consulting sounded pretty cool because as far as I understood it was like, hey, you get to go in, learn a bunch about these businesses and dive into data and try to generate some insights. 

‍

And so I went to a small firm that got bought by PwC, and I worked on a lot of airline projects, actually. It was really cool. It went really deep in how airlines work and there's all sorts of interesting data stuff, whether it was network scheduling and airport planning to wifi pricing for airplanes. And I was always the person on my teams that wanted to dive into the data and I love building a nice deck, slide deck, but I was always the Excel guy because I loved it. And I was setting up little access databases, like illicit access databases on PC towers I purloined and set up at our client site and I was going really deep on that and I was building these whole data apps basically in Excel with dropdowns and buttons and VBA. It was really the dark arts of Excel and I was shipping releases of these models. I was like, this is version 12.1 of the wifi pricing model and distributing it on thumb drives. It was very cute looking back.

Sandhya Hegde:

I mean it just, Excel is still the best no-code development tool ever-

Barry McCardel:

Yeah. It's great.

Sandhya Hegde:

It is so powerful and amazing.

Barry McCardel:

The first blog post on our site actually it's this, it's called Long Live Code. And it's kind of a little meditation on why Excel is so popular. I like to say is a low floor and a high ceiling, which is, you can go into Excel and just build a shopping list. You don't have to do anything technical really, but you can also build these insane data apps that I was building with calculations and regressions and all this stuff. It's very accessible and then you can just ramp and ramp and ramp in the same UI. And so fast-forwarding a little bit, I had a friend from college who was working at Palantir and I was describing what I did and he was like, "Hey, you're doing admirable work in Excel but we're a company that's like all we do and we build software for this."

‍

And I found that really appealing. So I spent about five years there. I got to work on and solve all sorts of interesting problems using data and working on very cutting-edge of data at a very interesting time, and big data and data science were becoming very hot and in vogue. And I met a bunch of wonderful people including both of my co-founders. I left, went to a healthcare startup in New York and I was puzzled that despite having a pretty modern data stack with a data warehouse, and dbt and a BI tool, that our data team was still doing a lot of work in one-off SQL scratch pads and Jupyter Notebooks floating around and Scripts and a lot of stuff winding back in spreadsheets. That was kind of funny to be back in building data apps in Excel.

‍

I was like, whoa, we're still doing this. So I actually started this journey of Hex as a buyer. I was shopping for something, I was like, certainly, someone has built this thing. Certainly, this exists. I had been in the Palantir bubble for a long time where we kind of just built our own stuff and weren't really aware of what was on the market and I couldn't find it. So I was going around all these friends on data teams and I was like, "Hey, what do you all use to solve this problem? What do you do?"

‍

And no one had anything good and what most people were like, "Hey, this is a problem for us too, but when you find something let us know." And so it took a while to turn the corner from being a buyer to a builder. But I got together with Glen and Caitlin who were two people I loved working with at Palantir, and we kind of took the leap because we were like, hey, if no one's solving this, maybe we are the people to do it. And so that was the very end of 2019. So we're about three years and four months or something like that into that journey now.

Sandhya Hegde:

Makes sense. And I'm curious when you said who is solving this problem, how would you articulate the heart of the problem? Because one thing I see is given how crowded the analytics ecosystem of vendors is, often when I meet a new founder starting up in the space, I have to tell them, "No, first you have to start really small. I'm going to ask you what the big vision is. But you have to start really small and do one thing incredibly well if you have a chance at standing out. Otherwise, no matter how good your product is, there's just so much noise in the ecosystem that it's going to get-"

Barry McCardel:

It's really tough

Sandhya Hegde:

So what was that one amazing thing you really wanted Hex to nail when you started?

Barry McCardel:

We had a lot of stuff in mind and I think you're touching on something very important, which is we had a big vision. We had a lot that we knew we could do, but it was trying to stay really focused early. It was hard, but it was worth it. We focused on one thing early on which was sharing and communicating work. We had this sense that one of the most painful things is a data scientist who might be doing your work in something like a Jupyter Notebook or a Python Notebook or Scripts was actually taking that and turning it into something other people could interact with and there were some things out there. There's some open-source projects that were like, hey, you can wire up a UI and publish a thing. But nothing that we felt was as easy and intuitive as we felt should exist.

‍

And so the first version of Hex was actually very, very light on the editing front. In fact, the first thing we built was basically the ability to take a Python notebook that you already had, drag and drop it in, do some basic parameterization of it, adding input parameters, and then publishing it. And turns out that even just by itself was a quite appealing thing that solved a quantum of value for some early people. And we actually had some reluctance, I think, to let our vision and focus blow up too much. We were open even at the time, but maybe that is the four corners of what we do. Maybe there is this sharing layer. I think as we thought about the market and what we realized though, that sort of last mile was probably not big enough to build something to solve the depths of the vision we wanted, much less build a venture-scale business.

‍

And actually, there's some analogs to other markets where if you look at the design market, there was a bunch of companies for a while that were sort of like, well, we're going to be the last mile. You're going to do your work in Sketch, but then we're the last mile thing that you used to share and communicate your mockups. And those were real companies. Abstract Wake I think was one. There were others. Yeah, well Envision, yeah I mean and their lunches, breakfast, and dinners all got eaten by Figma, which was the place where people wanted to spend their time. So we felt like that last mile was a little precarious even though we did have some conviction that might be the place to start.

‍

And so it all sounds very rational, linear right now. There was a lot of angst for a few months of, ahh, what do we do? Where do we start? And it's like, I think you do have to pick a beachhead thing that you're like, "Oh, we're going to be good at this." And then provide a quantum of value and get into an iteration loop with customers. I think that's actually the most important thing early on is getting, we even call it commitment engineering loops. Getting into this give-get cycle with early users and customers is the thing early on I've come to believe.

Sandhya Hegde:

Got it. Could you share some numbers around it? So things I'm curious about is one, how long after you started the company did you have something in the hands of an end-user trying it on their own? Just the kind of sharing, collaboration functionality.

Barry McCardel:

We started full-time in December of 2019 and then I remember we had this trip to New York about three months later, so it was the end of February or something. And we built a first prototype, we'd gone just heads down and built this thing out. I remember this moment, it was so surreal. We went and visited one of our early design partner customers, just friends that I had known on a data team at a company in New York who we had convinced to try this thing out. And we went to sit down in this conference room for them to give their feedback on the prototype. And they were like, "Yeah, it worked." And I was like, "What do you mean?"

‍

They're like, "Yeah, yeah, it worked here." They showed me, they demoed what they were doing. They had feedback requests. And I was like, "What? It worked?" We tried to hide our surprise. And that was a fun moment. I think I remember getting in the elevator. Caitlin and I looked at each other and we were like, "Do we have users? What?" So that was a funny moment and so that was what, three or four months?

Sandhya Hegde:

To your point, getting that three months in is super valuable because it just accelerates all the other features, ideas you want to work on for the rest of the year.

Barry McCardel:

I mentioned this before, I can expand on it a little bit, but there's this concept called commitment engineering that it's not something I invented. Some really smart people I used to work with said this all the time, but I'm becoming an evangelist for it now, which is I think really early on, founders will often try to be like, okay, I've got my startup idea and I've got my product prototype and I'm going to go try to sell it now and I'm going to convince of people this thing. I think early on the most important thing to do is be the person who really understands the problem and try to find the people who feel that problem really acutely. And then you get into what I call this commitment engineering loop, which is the first thing you're asking for is not like, "Will you buy my software?"

‍

What these first people, the first thing you're asking for is like, "Hey, it sounds like you have this pain point. Would you take a half hour and do a call and just tell me about it?" And if they say yes, then great, you've started something. If they say no, you're like, this is clearly not a big enough pain point for them to take a half-hour and talk to you. That tells you something. It's an early signal even before you have a single line of code written. And then once you do have some code written, it's like, "Hey, will you take a half-hour and click around in a prototype with me?" And then you're testing that. Are they willing to give their time? Are they willing to make a commitment to you that's non-monetary? But they're giving you something because you're giving them something, right? It's a give-get loop.

‍

And you can ride that all the way through. You can be like, "Hey, great, well if I came back with another version of this in three weeks with that addressed feedback, X, Y, Z, would you do a 45-minute session and would you invite your boss or a colleague or would you use this for real for a day?" And you're just testing the whole way up. All the way up through, "Will you sign this contract?" But you can validate your way up and I think getting into those loops early and getting those feedback loops and just finding a way to validate, "Am I on the right track," is so important versus what you do see what some founders do. And it's a very common mistake, which is like it's been six months just building in a hole. And then you get out there and you start validating by trying to sell it. And it's like, well if you got some foundational assumptions wrong, you don't want to find that out that far in.

Sandhya Hegde:

Yeah. I think the other thing I'll want to point out to our listeners, especially about your approaches, you're not validating the idea by asking if someone likes it. You are validating it by asking for more commitment, right? It's really easy to have this really eager founder showing you your baby. It's really easy to be like, yeah, I have that problem-

Barry McCardel:

Looks cool. Looks great.

Sandhya Hegde:

I could see us using it maybe a few years. Yeah. Yeah. Right?

Barry McCardel:

Will you actually connect it to your data now? Oh no, no. We've got a lot going on, or not right now. It tells you something, right?

Sandhya Hegde:

Yeah, exactly. So I love the focus on commitment as the validation, not the words being used in response to your demo, right?

Barry McCardel:

Yeah. You have happy ears early. You want to know, you're like, "Hey, I want to hear that this idea, this thing is going to take the world over," right?

Sandhya Hegde:

Yeah. You have to remember you are biased and someone else is trying to be nice to you.

Barry McCardel:

Yeah. It's eternal and I've had so many moments in my career and even at Hex where that old age-old wisdom of you're the easiest one to fool comes in. You can convince yourself of almost anything. And real intellectual honesty, even if it's painful in the moment when you hear that the thing you've just spent a bunch of time on is not it. It's important. It's hard though. It's really hard.

Sandhya Hegde:

Yeah. I'm curious, what was the pattern in early adopters who leaned in versus those who leaned out? I'm assuming not everybody is like, "Yeah, I'm going to try this right now." Was there any underlying pattern that helped you crystallize who is the early adopter customer? Who is that persona? What are we looking for when we reach out to people?

Barry McCardel:

Totally. Okay, so data is a really big space and we discovered something, I think it's intuitive enough to say, but it took us some time to really crystallize it, which was the problem we were solving initially. Our early value prop is about this sharing and communication thing. And there were basically two classes of people we would talk to, we talked to the people that we'd be like, "Yeah, we'd talk about the pain point we were solving, sharing and fragmentation and sending around PDFs and screenshots of reports and all that." And there were people who were nodding, I would describe the problem and I'd just be getting head nods. And then there are people who are sharing, "Yeah, I don't know. I don't really share." And it was weird it was the thing we discovered is there are really two classes of people, there are people doing basically analytics, which even if they call themselves data scientists, I think analytics is a big part of the data world, which is basically you're trying to ask and answer questions to influence a decision and then there were people who were doing what I would broadly characterize as ML engineering, which is, "I'm iterating on a model that is going to run to make a prediction somewhere." And the former has a lot of problems around sharing and communication because you're trying to influence a decision. The latter was not a big part of their workflow and they were asking us for very different things. So I think early on we got confused honestly because we weren't thinking as clearly enough about this, which is kind of embarrassing because we had so much experience in this space and we were jumbling those things up and we were taking feedback from both, and putting them in the same hopper where the people in the ladder were asking us for basically a completely different set of things.

‍

And it took us, I think, a while to get comfortable just saying no or ignoring and putting blinders on. And I think as a founder, again, you have happy ears and you want every discovery call you do to be a great discovery call. And the person on the other side being like, "Yeah, I can't wait to use this." And I think as a founder, you have to get really comfortable in the first few minutes. If the person on the other side is like, "It's not clicking."

‍

Just being like, "Hey, you know what? I want to respect your time. I'll circle back if we get on this path." That's really powerful. I actually had a sales call earlier this week with a very large company that would be a great prospect for us as a logo where I was literally in the first 10 minutes I was asking them a bunch of questions and then I was like, "Okay, it sounds like this is not right for you." And we wrapped up the call and we all moved on with our days and you got to get comfy with that early on of having that focus.

Sandhya Hegde:

Right. Yeah, makes sense. I think one thing I really took away from what you were saying was that even though the title might be data scientist for these two different people, they might have the same exact title outside looking in. You are like, yes, this is the same customer persona. Right?

Barry McCardel:

Well, data science is such a funny thing. This is an aside. There's a lot of regret around data science even becoming a title because, it's just like, there's a lot of jokes around this that's like you are data scientists or data analysts who do the same thing in Python and it's a little reductive. Because I think a good data scientist is bringing a level of statistical rigor and insight into what they're doing. They're typically thinking about things like experimentations, sample sizes, forecasting. There are deeper techniques to bring to bear and certainly most data scientists are doing that. But I think a lot of those, if you survey data scientists, I think the majority certainly are effectively doing analytics. They're asking and answering questions to influence a decision, versus, I am training a deep-learning model that we're going to deploy behind an API endpoint to serve online predictions. That is a very different discipline, even if theoretically they're both querying data and charts are generated along the way.

Sandhya Hegde:

Makes sense. So going back to Feb 2020, which also momentous month and the history of the-

Barry McCardel:

I didn't realize it would be my last trip to New York for a while or trip anywhere for a while.

Sandhya Hegde:

But we'll get to that point later. So walk me through the rest of 2020. At what point did you just say, "Okay, what we no longer want people to upload notebooks into Hex, we want all the work to happen in Hex." What was that transition and how many end users or customers did you have at the time when you started going deeper into the product roadmap?

Barry McCardel:

Well, just a handful. We were reluctant to blow up our scope too much. I think the abundance of ideas we had actually made us a little paranoid where we were like, there's all this stuff we can do. Because you got to remember we'd spent five years together at Palantir, building. Palantir has built a huge number of different analytics and data surface areas. So we had seen plenty of data points in terms of all the things one could build. And Hex is not a reflection of any one thing at Palantir, but we had a sense of there's a ton that one could do in this space and focus being important. In fact, that was the lesson I took away from Palantir, that focus is really important because there were moments where we did or didn't have that. It was very clear to us when we were talking to these early customers.

‍

I remember one conversation, in particular, where all the feedback was on the editing experience and we were like, "Well, would you ever just want to keep editing this in Jupyter?" And the guy was like, "No, Jupyter sucks." And I was like, "Well that's a little strong. Tell me more about that though." And because I was a big Jupyter fan for a long time, I still am. But he got into it and he was telling us about his whole workflow and it was like, "Oh okay, I can see why your takeaway from this workflow is that you are looking for something to actually..." We had created a good experience for him on the last mile and he was like, he wanted that goodness permeating further forward. So that was just all the feedback we were getting basically was around that and I had been a user of DEV notebooks for a long time and probably 10 years into using some form of a Python notebook now.

‍

I think we had always had this feeling of not wanting to build a notebook company because I had always felt like notebooks weren't a market and I still don't. I think notebooks aren't a job to be done or a problem to be solved, they're a format. It'd be like saying "I'm building a text editor." You're like, "What kind of text are you editing?"  If we were going to take this on, I think we wanted to make sure we were being focused and disciplined on what we thought this could look like.

‍

And we had a really clear picture of what we thought an actually much better end-to-end workflow for these things could be. It was just a lot to bite off. I think it took us a little bit to get confident. There was almost a moment. I remember this feeling of, we didn't choose this life, this chose us. It was like the pole was there, we have all this knowledge, we have all this experience. All right, I guess we have to do this. And I'm obviously glad we did because I think we've been able to bring a lot to it. But it took a lot of pull from users to almost drag us there. We weren't pushing it and I think that's what made it feel authentic and ultimately built our confidence.

Sandhya Hegde:

And what did the customer profile look like in your first year? So was it mostly smaller teams, smaller startups? Did you have larger companies already?

Barry McCardel:

Yeah, all smaller companies. I think in data there is just, maybe this is intuitive to everyone, but I think it's perhaps a little underappreciated. In data, being able to actually connect to your customer's data is just everything. It's like the sun and the stars and the moon. You can get a little way being like, "Alright, just upload a CSV," but you're not getting any meaningful revenue on the back of CSV uploads. So we had known that in fact, we had worked in the most paranoid data environments in the world at Palantir where getting access to customer data was often a matter of years of trust building. That was very important to us early on.

‍

So we just focused on early startups and tech companies that typically are a little more permissive in terms of that where there weren't a lot of baroque processes. Now it's very different. We are working with large companies, we have a lot of public companies as customers, we have built out a lot, whether it's SOC 2 to private VPC deployments to SSH data connection. We built a ton around that but early on, if we had to go and build all of that stuff just to iterate on product-market fit, we would not be where we are.

Sandhya Hegde:

Makes sense. So two follow-up questions there. One, you started a company post the warehouse becoming strategy, especially companies like Snowflake, but people trying to standardize on this idea of, "Okay, we want all of our data unified in a warehouse so that we can figure out what to do with it later." Was that a tailwind for Hex? How did you experience that?

Barry McCardel:

Oh, yeah. It's the tailwind for Hex.

Sandhya Hegde:

And two, I would say, given that, that is something small startups don't necessarily do, right? A 10-person startup might not have done the warehouse unified data thing yet. So I'm curious about that tension because you're talking to small companies, but you want to leverage this warehouse tailwind. How did that play out?

Barry McCardel:

Yeah, well first I think that that is the tailwind for Hex. I think this modern data stack where you're bringing your data together, you have the Snowflakes of the world, the BigQuerys of the world. You've got dbt and Fivetran. And when I started my career in data, say 10 years ago or longer, the idea of going to a single place to go find a bunch of clean ready-for-analysis data about your business was preposterous. When I was in consulting in airlines, the way I got data delivered to me was like, you literally go down the hall on the 13th floor to find Tom who's got access to the MySQL thing, who can pull you an extract once a week in CSV that then I can go to. And then at Palantir, we had all these customers who 've got 18 different data lakes and a lot of different databases.

‍

And this was really before columnar data warehouses were a thing. Fast-forward to now, and it's not a solved problem for every company in the world, but even really big Fortune 500 businesses, we talked to them, they're like, "Yep, we got cloud data warehouses. We're starting to adopt modern UTL tools. We've got a warehouse with these analytic tables." And now the question is like, "Well, what do we do with that and how do we empower people, and how do we make that easier?" I think the last few years, the story's been around data infrastructure. I think there are now all these new expressions of what you can go and do with that.

‍

Really small startups, they don't typically have that. And a lot of them when they're using Hex are maybe using Python to connect to an API or something to pull some data. But our sweet spot even early on was sort of what I would call scaling tech companies. You'd have people companies, 50 to 500 people was what we used to talk about. And those sizes of companies are standing up data warehouses. And again, 10 years ago the idea of a 50-person company having an enterprise data warehouse was like, "What are you racking and stacking servers for Teradata?" Now it's like, yeah, you just go and sign up for Snowflake and set up a Fivetran connector, and all the data's there and it is just orders of magnitude simpler for people to get their data in that type of pattern.

Sandhya Hegde:

So maybe pivoting a little bit to team building. So you pretty much launched your MVP, the same time the world was going into lockdown.

Barry McCardel:

Also raised a seed round when everyone thought the economy was going away, which was a very weird time.

Sandhya Hegde:

Very, very short window though.

Barry McCardel:

I chose the short window of panic to raise our First Round. So that was an interesting experience.

Sandhya Hegde:

What's been your approach to building a team? You have hired some people that I love very much. So I'm curious, how have you thought about building a team and especially building a good, connected culture while a lot of us have been remote and distributed?

Barry McCardel:

Yeah. It was interesting. There's a funny story. Our first employee started, it was March 6th or ninth or something like that of 2020. And we had just moved into this new office in San Francisco. We were so excited. We have this office — basically had two rooms that were really nice. And he came and I had set up a monitor and it's got his laptop. He was like, "Our first employee's here yay!" And we had one day in the office with him and then we were like, "Oh, we should probably work from home." So all of the early hiring, I think up through 15 people or more actually was done fully remote and distributed. We wound up with people all over the US and I think we've done a pretty good job on this. I don't think I have a silver bullet. I think in terms of a connected culture, I think we try to get together a bunch.

‍

I think in general, especially when you're remote and you worry about permeating best practices. When I'm at my best, I think I try to be really mindful and make sure I'm taking my time to highlight examples of what good looks like. I talked to some founders and they're like, "Oh I've got all these people and it's tough to feel like we're all in the same culture. I know what I'm going to do. I'm going to write a values manifesto and I'm going to send it around." And it's like, okay, we have that too. We have our handbook, it's public on the website, you can go check it out. We have values in there but I find that the most effective single thing you can do to calibrate a culture, and it is probably true in person or remote, but especially as you get bigger where you do have people just all over the place, regular shout-outs for what good looks like from you, the founder.

‍

And so just earlier this week we had a part of our product that was sort of very long neglected. It was never the most urgent thing, but it was always kind of a source of shame. It's like, this is not good. And one of our designers went and just redesigned the whole thing and she took the time to do it and it's beautiful now. I shouted that out in the company in Slack in our product channel because I felt like I wanted other people to see that. I both wanted to give her props because it was sweet. But the real motivation was, "Hey, I want other people to see that and be like, that's what good looks like here. That's what I should aspire to." And when I'm at my best, I try to do that a lot. I find that to be the one most important things, probably.

Sandhya Hegde:

Yeah. It all comes back to the storytelling and the stories that motivate us and make sense out of what's happening in the world. I've always told every founder I've worked with that you'll be surprised how powerful a tool storytelling is for building your business and how much difference that makes versus all the other things you're going to focus on because it gives you leverage across every single activity you are going to do.

Barry McCardel:

I think that's really insightful. I think that's really, really insightful. I think storytelling is probably most of the job as a founder if you really think about what you're doing, you're telling the candidate stories, telling customers stories, you're telling investors stories, you're telling your team's stories and that sounds like stories, fantasy stories, like no, you're telling a narrative of the way you see the world and different founders will do different amounts of extrapolation into the future on that. But yeah, I think that's very insightful. I think that's right.

Sandhya Hegde:

So speaking of the future, I would suspect that once you have built this X product, you have a data team that has built a bunch of applications, dashboards, they have done all their work in SQL or Python, but now they have built a surface area that's accessible to the rest of the company. How are you seeing Hex's user profile change? You have tens of thousands of users, 500 paying customers, what does the future of Hex look like in terms of the people who are a part of this community that you are betting on two, three years from now versus today?

Barry McCardel:

Yeah, I think the problem that we hear really consistently from customers is around fragmentation. I think people wind up doing work in a bunch of different places. Most of these tools aren't built for collaboration. Most of them have no sense of organization or governance or permanence. So you do some really great work and then you leave the company, it's like where did that go? And communication's really broken a lot of insights, live in charts and screenshots of charts and PDFs of decks in an email somewhere from three years ago. It's just not great. That is a big part of I think, the story and the pain that we hear from our customers. So when you think about that, that cuts across a lot of different workflows and users and use cases. So we were talking earlier about focus in the early days.

‍

I think it's actually just equally important now and something I try to put a lot of energy into. There's a ton of directions that people pull Hex in. We have people build all sorts of crazy stuff. On Twitter, I saw someone the other day built this 20 questions app using OpenAI like GPT three API. It's like you can build all sorts of stuff and that means that's awesome because it's a flexible tool. People will take it in all these cool directions. There's a pleasure and a joy and pride that we take in building powerful tools for creative people. I think it's really fun to build those types of products.

‍

On the other hand, it's very stressful because you wind up getting a lot of different types of feedback. We were talking earlier about different personas giving you different feedback. That is a problem today and I think I've tried to get really good at both making decisions on what we're going to focus on, but then making sure even what our salespeople know that when they get a request from a customer, I would rather them telling them, "Nope, we are not focused on that," than, "Oh yeah, that's on the roadmap," or whatever people wind up saying. So for us, one of the biggest changes in the profile is people just use it.

‍

The type of people who use it is different over time, which is early on in a customer will see the main people using Hex are the people with data and their job title, data scientists, data analysts, analytics engineer people on the data team, and then they share it out with other people and you wind up with this effect of, you have PMs and engineers and someone in case you and I talk to someone who just on the sales team who uses Hex, they know how to write some SQL and it's actually the best place to write SQL.

‍

That is really gratifying to see that sort of spread and it's very cool. Again, it does cause tension sometimes because the requests you're going to get from an ML engineer are different than the requests you're going to get from a product manager when they're using the product and knowing who to focus on and how to have a UX and a UI that is going to do a good job being that low floor, high ceiling is a very interesting challenge. I think it's a worthy challenge. It's something we enjoy, but I think if you're building in the data and analytics space, especially if you're building tools that have a lot of flexibility, you're going to have that same challenge. So, founders I think really have to be disciplined on saying no and as their team grows, also making sure that you're communicating that down through the port because you want everyone on the same page.

Sandhya Hegde:

I think this is a great example of how I think particularly for enterprise software, since you have a more complex customer journey, product market fit is not actually a milestone. You hit it and then you have to keep it and grow it and make it stronger and suddenly you have to think about, okay, different parts of your product for different parts of the market, especially if you're doing collaboration software. I think it's really a constant work in progress, not a milestone you hit and-

Barry McCardel:

In a space moving as fast as data, too. The thing that would've had PMF five years ago might not today, and as a founder, I think one of the hard parts is you're always trying to build the next feature, close the next deal, but you also have to hold in your head a sense of how things are changing. With everything happening with AI right now, there's even a new strata on that, which I think just a bunch of foundational assumptions are changing as well.

Sandhya Hegde:

Yeah, I'll take that as an invitation to put you on the spot about your AI strategy. I was trying to hold back, but I think the most fascinating thing is actually for me, the code generation, text-to-Python, text-to-SQL, of all the things that this thing does well that seems to be one particular and unexpected strength. So I'm curious how you're thinking about the future of Hex in that context.

Barry McCardel:

Yeah, so that's a great question. Our number one mission is empowering people working with data, and we think that people are going to stay involved in that for a while. I believe we believe that data work is fundamentally creative. I know you don't think of a data scientist when you think of a creative, you might think of an artist or musician or whatever, but if you think about a lot of data work, it is creating, you're forming hypotheses, you're exploring ideas, you're telling stories, you're building beautiful charts, you're taking some risks. It is a creative and stimulating endeavor. It also can be so frustrating and tedious because you're tracing down a missing parenthesis or fixing your Python dependencies. And I see AI in every domain as a chance to allow humans to focus on that creative, engaging, stimulating work that humans are uniquely capable of and to partner with AI to abstract away a lot of that TDM.

‍

And if you look at the way a software engineer uses GitHub Copilot, a lot of engineers on our team use Copilot. When you talk to them about it's like, "Yeah, well I don't have to worry about a lot of the BS that I had to before. It takes care of boilerplate for me. I am thinking at a higher level more consistently and that lets me move faster and explore things in more depth." We see that exact same thing with people using our AI features, which are, we call Hex Magic. Set of magic tools. It lets you generate, edit, debug, and explain code in your workflow. It's built directly into the cells where you're writing SQL or you're writing Python. Very importantly, we are not building some black box thing where a business stakeholder is going to roll up and be like, tell me an answer and it's going to spit out a perfectly formatted chart with explanations and built-out data pipelines behind it.

‍

I think in data especially, it can be dangerous to do that because there are correct answers to things and there are already enough problems with organizations getting two different answers for the same question. I think you want to make sure that if you're building something AI-assisted that, at least right now, you're keeping humans in the loop. So we actually have a rule as we're building these features of, “We don't run the code.” If you generate something in Hex, you hit the run button. And that's because we really see it as, "Hey, this is here to help you iterate." I think it's really interesting too to see the way people wind up using it. It's similar to other types of generative AI workflows. If you use ChatGPT or if you spend any time with the image generator, things like Midjourney or Stable Diffusion, you wind up working in this really iterative way.

‍

It's not a zero-shot, one-shot thing where you go, "What's the answer to this question?" The users who really find success with this in our product, and the way I wind up using it when I use it is, I'll ask a basic thing. I'll be like, "Number of customers broken down by tier. Okay, add revenue, add this, build a chart, factor this code out." It's an iterative process where you're partnering with it. That I think is what, getting that UX right is really one of the most important things I think to build an AI-driven product. It is not hard, I promise you. It's not hard to build a quick demo and there's a million of them now in the data space of asking a question and it will generate a SQL query. But it's much harder to understand what's the right UX for this. And then also have the data to know how to prompt these things accurately.

‍

Being able to take in context the rest of the project or the database schemas or past queries or past code or that past completions people have accepted or rejected. Getting all that right is also the really hard part so the models themselves are becoming commodities. It's how you package that up and build the right prompts and the right UX to allow humans to partner with this that I think will matter in this next generation of productivity tools.

Sandhya Hegde:

Yeah. And how do we create a future that's not an even worse governance nightmare than we already have today, right? This could easily become our version of news misinformation where there's like, okay, here's the image in my mind, right? There is a head of sales and head of marketing both pointing to their ChatGPT chart saying, "No, no, no."

Barry McCardel:

Well, they prompted it differently. The salesperson’s saying, "Why is the bottleneck top of funnel?" And the marketing person is, "Why is the bottleneck sales execution?" Yeah, you could probably tell a story for either of those things. That's why I think the data team-

Sandhya Hegde:

...team has not converted all my amazing MQLs.

Barry McCardel:

Tell me what the VP of sales... Yeah, yeah, that's right. That is why I'm a believer in the data team and the continued value of data teams. Even if you can have a bot that can generate some valid SQL that assumes that data teams are just SQL monkeys and I just don't think that's what they're there for. And I think that will actually become clearer in the same way that developers they're not there just to bang out TypeScripts. They're there to be creative and think and architect something. So it's a very similar thing I think we're going to see in every domain.

Sandhya Hegde:

Makes sense. Maybe wrap up with a quick last question. What would be your advice to 2023 new founders thinking about building data startups?

Barry McCardel:

Don't.

Sandhya Hegde:

Not allowed to say that. You can't just say don't.

Barry McCardel:

I think that we are at a point in data where you should assume there's exactly zero pure greenfield. I've talked to some founders and they're hunting around for the patch of grass that no one's ever stood on. And it's funny because even successful companies, the youngins these days don't even realize there were generations of data warehouse companies before Snowflake. There were generations of ETL companies before dbt and Fivetran. There are some old, old... Does anyone remember Ab Initio? There's no new ideas I think, and that's okay. That's actually, I think one thing you learn is that ideas are cheap. Execution rules the day. So I would think really carefully about what are the areas where you and your team have a unique license to execute.

‍

And what are the areas where you have unique insight and passion? And I think data was very hot the last few years. There were a lot of VC dollars and I'm certainly the beneficiary of that, that you could call me a hypocrite for saying this in fact. But I think just being like, oh, I want to start a startup in data. You have to realize that there are 80 other people with the same idea that have come before and are going to come after. And you have to really be honest with yourself about where you have unique insight or execution ability. That would be my advice.

Sandhya Hegde:

Very good advice and thank you so much for joining our show, I enjoyed this conversation so much. 

‍