Finding Early Customers | Barry McCardel (CEO) | Founder Confidential

I'm Barry McCardel. I'm the co-founder and CEO of Hex, and we are a collaborative data workspace that makes it easy for everyone to work together on data analytics and data science projects. And we're going to talk about how to find and land early customers. This is Founder Confidential. I started Hex to solve a problem I'd always had. I had spent my whole career in data as a user and builder of different types of analytics tools, and I found myself wanting in basically every role I was in something like Hex. I was in a position where I was really actively searching for something like it. I was actually started this journey as a buyer, and when I couldn't find something that fit my definition of what an excellent, amazing platform in the space would be, eventually it kind of clicked that, well, maybe it's on me to go make it. And so I got a couple of friends together and we started talking about it and So in a way, it was a reluctant journey to being a founder and CEO. I didn't set out to be this. It really came because of the idea and having a couple of brilliant people who were excited to work on it with me. Every software category is super crowded these days, and standing out can be really tough. The most important thing is really having a deep empathy and focus on the problem you're trying to solve and stand out as the team that understands that problem better than anyone else. For Hex, I would say that really has been the key. We've built a bunch of cool features and they're unique and they're exciting. But I think when people think about Hex and the brand we've built, it's a brand that really feels like we're coming from that community and that we understand because we have. We were the people that we're selling to. And I think that shows. And I think that that helps us stand out amongst a lot of other people who are trying to sort of do similar things. One of the hardest, most difficult parts of building anything new is finding your early users and customers. And a lot of people really struggle with this. They'll go and they'll try to take an early version of the product and go ask people, hey, will you use this? Will you pay for this? Right out of the gate. And a lot of times that's a recipe for spinning your wheels and frustration. And that's because the early thing isn't very good because it's early. No early product is great because it hasn't gone through those feedback loops with users. And if you come right out of the gate saying like, hey, would you use this? Would you pay for this? More often than not, even if they're intrigued, the answer's gonna be no. And I think the most important thing in that really early formative time is actually focusing on the problem you're solving. Our first paying customer was a direct-to-consumer business. They sell skincare products, and we knew someone who was on the data team there. And I had actually talked to them really early when I was just trying to figure out, like, is this even a good idea? Like, do other people really have this problem? And he was someone to raise his hand. It's like, yeah, this is, this is a real thing. We have this problem. And so when we built a first version of the product, it was really in partnership with him and his team and collaborating with them on, you know, is this something that would actually solve the problem for you? And as we iterated on, eventually it really clicked. You know, at the end it was actually a very easy conversation to turn them into our first customer. And so one of my number one pieces of advice to other founders and something that I wish we did even better early on was spend all of our time talking about the problem. Talk about it through blog posts, talk about it through podcasts, talk about it in your conversations with potential users, talk about it with potential investors or partners. You want to build a brand about being the person who understands that problem better than anyone else. If you do that, you're going to get people be really interested in working with you. They're going to be open to using an early version of your thing, iterating with you on it, and they're going to see past the warts and the deficiencies of the early version of your product because they're going to see the potential and be excited about how amazing it would be if you were able to get it to a point where it really solved their problem. One strategy that I found to be extremely helpful when building early products is something I call commitment engineering. Commitment engineering is the art of getting into feedback loops with early users by asking them to give something in exchange for getting something. And so when you're early in a conversation with a user, maybe you're just talking about the problem you're solving. And at the end of it, you can say, hey, I feel like I've really understood you've got this problem. This is something we're excited to solve. If I came back in a few weeks with an early version of something that solved that problem, would you use it? If they say no, then you're probably barking up the wrong tree. This is someone who's not that excited about the problem you're solving. But more likely than not, if you're on the right path, they're going to say yes, and you've created your first commitment engineering loop. And then you're going to come back with the first version of the product, the MVP, and it's going to have all sorts of issues, but they're going to have committed to clicking through it and they're going to give you a bunch of feedback. And at the end of that conversation, you say, hey, if I came back in another few weeks with a version of this product that, you know, addressed that feedback, would you do another half hour, but would you invite someone else on your team? You've asked for another commitment. And again, if you're on the right path, they're gonna say yes, and you've gotten another loop. And you can keep building these loops over time. You know, would you share something with your boss? Would you use this for a day instead of your old system? You can, these commitments can be anything, but they need to be meaningful because it's a way to test the commitment that the user or potential customer has to the thing you're doing. And the last commitment is, would you pay? Would you become a customer? And if you've been doing these commitment engineering loops on the way to that, that should be a really easy answer. You'll have shown them that you deeply understand the problem and you will have collaborated with them to build a product that solves it. And so that final step of converting them into a customer should be trivial. So I think finding those early customers and users is really hard, but focusing on the problem and building those commitment engineering loops is the way that it actually becomes really easy. One of the benefits of having spent effectively my whole career in this space is I think we had a really good sense of how Hex would come in both from a user and buyer standpoint. So we knew exactly the types of users who would be excited about Hex because we've been them. But we also knew a lot of the things that would appeal to the buyers, like the folks who might be leading a data team or the CIOs of companies, because we'd spent a lot of time talking to them over time. In past roles and as we got Hex going. And so for us, some of these things were quite intuitive and quite obvious. And again, I think just speaks to how important it is if you're starting a company, it's a huge advantage to be doing it in a space that you understand really well. As we actually started getting some early customers, one thing we found is we had new people just start showing up, which is, as an early startup, is a really strange experience. And we'd ask people like, how did you hear about us? And they would tell us it was a friend at another company or someone from another company just came to them and brought Hex with them. And that was enormously gratifying and I think speaks to the amount of trust and excitement we were able to build with some of those early customers and users. And so, you know, we didn't put a lot of energy into referrals or anything. It just started happening. And I think shows the power of what you can do if you build a product that really speaks to a population of people and that they really love. Our users and customers surprise us all the time. From very early on, I was shocked by the things that people want and built in Hex. It's a really flexible product and they would take it in all sorts of places and come up with all sorts of requests. And so I walk around in my head with a set of things that I think would be cool, but increasingly as the company goes on, they're less of the things that I had thought of ex ante and they're more of the things that our customers and users are telling us they want. From a roadmap perspective, we have a ton of big ideas that we're excited to go and build at any given time. We have things we've been talking about for months and years, but we really don't try too hard to build the perfectly sequenced roadmap of we know we're going to do this project and this project and this project and know exactly where we're going to be 3 or 4 quarters out. If there's anything we've learned, it's that ideas and features will get built when they're ready to be built. When we've really congealed around something, whether it's we finally feel like we understand what users are looking for and I can go write a spec, or a designer has finally found a seam in for how something should look or operate, we'll have these moments of sort of galvanization or, you know, energy kind of strike, and it— and that's when we'll really kick some of these projects off. So If you had asked me what our roadmap was 6 months ago, it would look different than the things we've actually done the last 6 months, and that's totally okay. We're still following our noses in terms of what users and customers are really excited about. I had a boss at a past job that I think caught me at a moment where I needed a lot of help editing and shaping the things that I was focusing on and understanding what I could really excel at. I owe him a huge debt of gratitude for always being honest with me, being supportive, but being really honest about where I was doing my best work and where I wasn't. Would not be where I am today without him. The best piece of advice that this old boss gave me was to focus on my strengths and not try to spend all my time being good at the things that I'm not. I think he made me feel like it's okay to really embrace the things that you're great at. And to— if you're not so great at some other things, that's okay. You don't need to pretend like you are. I think early on it's important to listen. When you've got an idea, you've got a company you're starting, you've got a product you're building, you want to tell the world about it. You want to tell those early customers, you want to tell those early users, you want to convince them how awesome the thing you're building is going to be. Those early interactions are really about listening. They're really about you building that understanding of the problem that they're solving and what you're there to do. And so avoid that temptation to speak before listening. Avoid that temptation to pitch before building that empathy. I think that's really, really important.