SFG 41: Hightouch's CEO Kashish Gupta on activating data for personalization

‍

Hightouch is a composable customer data platform. It helps companies collect and sync user data into ad platforms, CRMs, email tools etc. Last valued at over $600M, Hightouch has over 600 customers, including the NBA, Spotify, Plaid, Calendly, and more.‍

‍

‍In this episode, Sandhya Hegde chats with Kashish Gupta, co-CEO and co-founder of Hightouch.
‍

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.

‍

‍

‍

Episode transcript
‍

Sandhya Hegde

Welcome to the Startup Field Guide, where we learn from successful founders of high-growth 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 Hightouch. Hightouch is composable customer data platform. It helps companies collect and sync user data into ad platforms, CRMs, emails, etc.

Last valued at over 600 million, Hightouch has over 600 customers, including the NBA, Spotify, Plaid, Calendly, and more. Joining us today is Kashish Gupta, the co-CEO and co-founder of Hightouch. Welcome to the Field Guide, Kashish.

So before we dive into the Hightouch story, I would love for our listeners to get a high-level overview of how the data integration space has evolved over the years, because I think It is really fascinating and not very well understood outside of the data engineering and analytics ecosystem.

And it's also a category that has always had some controversy with different founders having very strong feelings about how the category is described, who calls themselves a CDP, and who does not. So yeah, I'm very curious to get your analysis of kind of the past couple of decades, what has happened to this space?

How did it start? And, where do you think it is right now?

Kashish Gupta

Really happy to share. I think to start with, I'll just talk a little bit about what Hightouch does today and then dive into how the data space has changed over time. So today, we power marketing campaigns for some of the largest brands in the world, including, like you mentioned, the NBA, Spotify, but also PetSmart, GameStop, and other really large brands.

And what that means is that these brands already have data on their customers. And in order to best use that data, they want to run personalized email marketing campaigns or personalized ad marketing campaigns on that data. So we build their marketing team a platform where the marketers can log in and get direct access to that data.

And build personalized marketing campaigns using that data. And that could be anything from user journeys to segmentation to one-to-one personalization.

And I think probably every single person listening to this podcast has interacted with marketing that was at some point powered by Hightouch, because we are powering marketing for over 600 brands at this point.

Where we started was actually a very different place. So in 2020, we launched a product called reverse ETL. And this was the concept of getting data out of your database and into your SaaS tool of choice, like your marketing tool. And at the time it was unclear or abnormal for folks to do ETL out of the data warehouse.

 A quick history lesson is that data warehouses are very old technology. We've had these for a very long time. But just this decade, Snowflake, Databricks, and BigQuery have brought data warehouses to the cloud. So instead of having to manage data warehouses internally and hire a whole team of people to build a server rack in your office and manage the data warehouse, you can simply just log into snowflake. com and spin up a data warehouse in less than five minutes. How SaaS has changed over time is that people used to have these data warehouses and these ETL pipelines, which is Extract, Transform, Load. It's just the concept of copy-pasting data from one database to another database.

They used to build all these ETL pipelines in house, and they would maintain those pipelines between their different CRMs, their financial suites, their marketing suites, and their customer support suites. They would just send the data back and forth through these types of pipelines, and how the world has really changed is now there is a clear and consistent central layer in between. So now instead of just ETLing data back and forth, a lot of companies are relying on their data warehouse as a consistency layer that can store that data, and then you can‌ do the transformations inside that data. So people have been able to be less thoughtful about how that data is transported, and just really copy as much of that data as possible into the data warehouse and make sense of it in there.

So because of that change, it really frees up how people think about storing their customer data. You can simply just collect all of the data into one place, make sense of it afterwards, and then you can share it back with your SaaS systems. And now that we have this new paradigm where you have some central layer for data storage, that need arises where now you want to share that data back to Salesforce, or to Marketo, or to your other email CRM of choice. And that's where Hightouch was really born. We originally were just building reverse ETL, just getting data using SQL queries from databases into different SAS systems. And folks were using that system, that product for all different use cases. So sales teams were getting product data into Salesforce, marketing teams were getting customer interaction data into their email CRM, and advertising teams were retargeting customers that only purchased once and getting them to purchase more times. So that was a really simple product for data teams.

And over time, we've been just lucky to work with larger and larger companies who want to give their marketers places to log in and interact with the data and so that's really what we've been building for the last few years and we call that a composable CDP.

Sandhya Hegde

Makes sense. Really excited to see how kind of the CDP space evolves over time. But maybe going back to 2018, what was the, origin story of Hightouch? Because you had mentioned that you had‌ started the company with a different idea at the time.

Kashish Gupta

 That's right. So maybe this is not a well-documented story. But we've had‌ six business ideas total during the time that we've been operating and we really found product-market fit for Hightouch in 2020. So in 2018, we started first working on a travel company and it was‌ effectively Gen AI in the early days before it really existed.

So we were a Slack bot that would book your company's corporate travel. So instead of messaging someone within your company, you would message the Slackbot. The Slackbot would book your travel, hotel, and rental car, and it would expense everything on Concur all for you. And it would be via conversational UI. And the exciting thing was that we had a really strong customer demand for that product. We were signing up like hundreds of customers a week, doing hundreds of thousands of dollars of bookings per week, and we had done Y Combinator for that product in 2019, May. And at the time, I was living in a group house with both of my future co-founders, Tejas and Josh.

Both of them were working at a company called Segment, which was probably what one would consider the original CDP, the original customer data platform. And I convinced Tejas to leave his job at Segment which was, I would say, probably a quite high-paying job and difficult to convince him. But convinced him to leave and join me on this travel company, and the only real thing we had not figured out was how to make money. We had figured out how do we get customer demand, how do we build the product, but we just didn't have a good economic model. And so when COVID eventually happened in 2020, we were forced to pivot out of the travel space, which was a blessing in disguise because we didn't feel that we would be able to make any sort of like long-term revenue within travel. And that's around the time in 2020 after COVID happened, our other co-founder, our other future co-founder, Josh, was working on another business as well. We were both working out of the same group house, so he was working on an IOT business and then Tejas and I were working on the travel business, and we felt that we'd always wanted to work together. Both companies were pivoting at the same time during COVID, and so we felt like it was the perfect time to join up as a three-person team.

Sandhya Hegde

It's fascinating. And so you also mentioned you had six ideas. Once you decided to pivot away from travel, what was the process of landing finally on this idea of like reverse ETL? What else did you explore? And how did you decide to pick this one?

Kashish Gupta

So this is a lot of founders call this pivot hell. We‌ had a lot of fun during this ‌ period of time. It was a lot of exploration and a lot of fun. So we started off, we had two ideas within travel. We shut those down because of COVID. And then, we ‌ first started in customer success. Because we had already had a lot of experience building on top of Slack. We were building a customer success platform entirely based on using Slack to communicate with your customers. We then pivoted over to dashboards because our customers were saying, Hey, I‌ don't even know what my customer support staff is telling my customers.

I just need a clear place to view what the customers are saying. So then we built a dashboard for that. Then the customer said, Hey, now I can see the communications, but I‌ don't know any metrics about my customer. I don't know what they're logging in, how many users are in the workspace, what product features they're clicking on. So can you please help me find my user data? And at that point we were confused because we had thought that this data problem of surfacing up user data was mostly solved and that people had good access to data, but we realized that was pretty much only the cutting-edge startups and even the cutting-edge startups had problems.

So we pivoted again into showing a customer dashboard that was meant for surfacing up user information and quickly found that if you're a early-stage company. then you‌ still need someone to aggregate all this data for you in one central place. But if you're a later-stage company, you've already done this in your data warehouse. And so you've centralized some amount of data in your data warehouse. You maybe not have cleaned it. You may not have made it useful yet, but it's there and you simply need to surface it back up. And so we've made the hard decision that if we wanted to grow quickly with early-stage companies, we could be that aggregator and that dashboard.

But if we wanted to grow in enterprise and be something that people grew into rather than grew out of, we would have to build something that integrated with data warehouses and surfaced up that information where people wanted to see it. So those enterprises were telling us that we already have this data, so please integrate with my data warehouse like Snowflake. And we don't want to see this in a new dashboard. We want to see this in Salesforce and other places where our users already live. And that's really where the reverse ETL idea was born. So really every single step of the way, the customers kept telling us that what we were building was cool, but not the most important thing.

And they told us what the more important thing was, and we just kept pivoting. And even when we had this idea for data warehouse to SaaS type integrations, even then we were still not able to sell the product until we asked a very important question. We went to customers or prospects and we said, Hey, is this idea interesting to you? And they were like, yeah, we love this. And then we asked them, all right, do you have other things that you want to build even before you build this? And they said, yeah, we have five more responsibilities and this is going to be six months from now. So then we would ask them, okay, so who in your company would care about this even more than you?

And every single one of those business users would say, hey, talk to my data team. I think my data team would care about this now rather than six months from now. And so that's‌ when we found Product Market Fit. It's when we had the exact same product, but we changed our persona. We found the data teams. They said, Hey, give me a SQL UI. And if you let me write SQL queries into your product, I can use this tomorrow. And that's when we started getting one user setting up the product per day. And only after we started getting one user setting up the product per day, which was around February of 2021, that's when we said, alright, this is product market fit.

It was even after our Series A, to be very honest. But that's when we felt like we had hit true product market fit.

Sandhya Hegde

It's fascinating. I'm curious, could you share a little bit more about some of your early design partners and what were examples of the feedback that you still remember today that kind of shaped the product strategy? And also helped you maybe differentiate from all the other possible ways to accomplish this task, right?

Because it's not like this was technically impossible. It's just that there was no one elegant, simple way to do it, but there have always been a lot of janky ways to do it. So I'm curious, how did you think about, okay, what is the delightful product and what was some of the feedback that shaped that?

Kashish Gupta

 In the early days, we would get so many questions like can't I just use Zapier to do this? Can't I just use Tray.io to do this or Workato? And the users really did lead us to differentiation, and we were‌ quite shocked that this kind of product had not been created before.

So early days the feedback that we got was, so we were‌ trying to build the marketer's UI first, instead of the data UI. We were trying to build a user segmentation builder. It would be very point-and-click, almost like natural language, and it would not require any sort of technical skills whatsoever.

So the very first piece of feedback that we got was, Hey, I can‌ do a lot more in this product if you allow me to write SQL queries and just pull any sorts of abstract data. So what the users really taught us is that regardless of UI, there's a core abstraction here that's very interesting.

Which is getting SQL queries to pull relational data, which is always going to be some tabular format, and syncing that to some SaaS tool, which is oftentimes not going to be some tabular format, but using some API, it's going to upload to JSON or whatever. And that conversion process is SQL to SaaS was going to be our core primitive that we were going to be able to do for so many different use cases. And so our early design partners were companies like Retool. We had the Norwegian daily, weekly newspaper. We had a healthcare company in New York, and then we had a company out in Brazil that was doing like some sort of like customer support tooling.

Sandhya Hegde

How did you end up with that oddly diverse mix of early customers?

Kashish Gupta

So it was extremely shocking how ‌diverse they were and how similar their use cases were. Some of them came from the YC community. Others came outbound. And the Norwegian newspaper, we‌ met through HubSpot. So we had been talking to HubSpot's sales rep, and that person was trying to, sell HubSpot to this newspaper, but they couldn't get data into HubSpot.

So they asked us, Hey, can you get data into HubSpot for me? And if so, we can help you sell it to this company. So it was even since the early days, we had the partnerships motion and that outbound hustling motion. And so in the early days we were really getting most of our design partners through network of network, cold outbound and just LinkedIn messaging people to give us feedback on the product. And oftentimes, the person that would give us feedback would then introduce us to their data person. And that data person would take it as this is a real product and I can‌ go use this thing.

Sandhya Hegde

 I'd love to maybe dig more into kind of the early founder selling process. I'm curious, how long did you just do founder selling? What was the kind of the, maybe the number of paying customers you reached and you're like, okay, it's time. We have a playbook. We need to hire somebody.

Kashish Gupta

Okay, I'll share two things. One is that we have a very important rule, which is that in the early days of the company, we believe that someone should always sell before they build. Instead of building for months and months or years, even having a very good idea of what the customer wants to buy.

Ideally, getting them to the point where they're even ready to buy. And then building quickly to catch up to customer demand. And it creates a really good feedback loop for engineers because the engineering team wants to serve customer demand. They don't want to build something abstract. That example I gave you for HubSpot. The HubSpot integration did not exist at the time when we sold it.

It was built overnight and our very first hire‌ lived in Hong Kong at the time, and so he built it overnight and then we finished it up in the morning and shipped it. So we really believe strongly that we should sell before you build. And the only way to do that is through founder sales.

Because it would be extremely difficult for someone else in the company to sell something that does not exist yet. And so we did founder sales for a lot less time than most people. I would say that the majority of companies will do founder sales for the first like 10 to 20 customers, maybe for the first year or two. Our situation was a little bit different. We only did founder sales for about six months. After that, we actually hired our first salesperson and we continued to do founder sales for the next two years, but we grew the sales team pretty quickly because we had felt that the market opportunity was limited in time.

So we had one direct competitor. They raised a series A. We raised a series A. We had felt that everyone was going to start going after this reverse ETL category very quickly. And we wanted to take all the air out of the room. And so we‌ hired our first salesperson at four paying customers.

Sandhya Hegde

I assume that even though you had identified it's this data team that has the urgent pain, given that a lot of the end applications is a go-to-market team, I assume it was still a multi-stakeholder sale. How do you think about Go to Market motion? What was it early days and how do you think it will evolve over time?

Kashish Gupta

Yeah, so you're totally correct. It was data teams, revops teams, and marketing teams, even in the early days, but the way it's evolved is that it was always inbound, at least for the first two years, and now there's at least some resemblance of like outbound and other pipelines. But in the early days, I think another thing that we did really uniquely is that we invested in marketing, like within Hightouch. So we hired a fairly large marketing team and spent money on marketing from the early days. Not on advertising, but in terms of organic. Community, blog posts, videos, that kind of stuff. And we had really felt that instead of talking about Hightouch, let's just talk about this concept called Reverse ETL.

It doesn't exist today. We can create a category out of it. And as long as we create a big enough category, at least some of that will come to us. And it turns out we were the only ones creating the reverse ETL category. Other folks were using other terminology. And so reverse ETL became quite synonymous with Hightouch in 2020, 2021, and even 2022.

2022 is when other folks started using that same term and now many folks claim to have it. But so that category creation is really what fueled our demand. And it fueled our demand from all three of those types of teams. And the cool thing was, is that by the time they came to the door, their timing aligned really closely with wanting to use the product.

And so we could do a pretty good job of letting some people use the product on day one and other people go through the sales cycle.

Sandhya Hegde

Got it. Makes sense. Really fascinating. Maybe moving on to the future. How has Hightouch's product vision evolved over the years? If you could share ‌about like where you see it going. And I would love both the bull and the bear case, if you will, just to understand also what keeps you up at night, right?

When you think about 10 years out, what are the things that you are looking for and risks that you would worry about?

Kashish Gupta

I have a perspective that some of the best companies in the world, the reason they become so great is because they don't have fear of building new things. There's other companies who will sell the exact same thing or build the exact same thing they've had for 10 years. And they're averse to change.

But I see companies around us that you would have never imagined them building in the adjacent categories nearby. And they've done it now. And they're going to continue to do it for many years to come. So I would say we are that kind of company. It's like what Parker Conrad calls the compound startup. And we believe that we can embody that as well, or even without hearing that, we were already embodying it. And we just realized it's very similar to what they're doing. So how the vision has changed over time is that previously by building Reverse ETL, we were doing this thing that we call data activation.

So you have data, it's stuck in some database, if only you could activate it and make it useful to your marketing and sales team. Very simple concept, people love that idea. And it just you get addicted to the idea that I could use my data for marketing and sales, right? That fueled a lot of the early stage demand. As we get later and later into the market, what we find is two things. One is the desire for larger companies to self-serve that data. And often from marketing teams. Because they have thousands of marketers within the business. Different BUs, different marketing teams they sit on. Ad marketing and email marketing sit in different teams, different buildings.

And they all want to log into the same platform with the same database and run their campaigns. And so this kind of like multiple-team type platform where you can collaborate and you can self-serve that data is really where we're moving. And part of that is to give people a platform they own. So in the past, people have always delegated data ownership to their CRM or other types of companies, other types of vendors within their business. They don't really own their data. They can't really operate on it with full customizability. With the data warehouse, especially the cloud data warehouse, it is really owned. And they're able to now build very like custom workflows to their business without too much overhead.

And so with that, you're also able to build AI models on top of your data. You're able to build personalized marketing with ease. And Hightouch can‌ provide both of these two things right out of the box, too. So our customers will come to us and they'll say, Hey, I have all this data. Can you tell me what product to show my customer next?

So they just bought a suitcase. Maybe they should buy this next. Or for example, a large office goods company would come to us and they'll say, If someone just bought a gaming computer, can we make sure to show them a gaming mouse and a gaming keyboard right afterwards? These kinds of campaigns. They're truly AI.

They're really just data science. But we can power those from scratch. And so these kinds of higher-level interfaces is the direction that we're moving in. And so we have three areas. We have the reverse ETL area. We have the self-serve area. And then now we have this new area which is really driving user insight, telling you which customers to target, telling you what to say to those customers telling you which product to offer those customers.

So that kind of like recommendation engine and analytics is what's coming next. I think maybe as a fourth thing, we're also going much more deeply into the ad space. So traditional CDPs have really focused on email. And owned channels. I think for some reason they've had fear of going deep into ads.

And we've really gone as far into ads as I think we can go. So we help people both publish ad inventory to the ad platforms. So let's say you have 100 million users and you want to be able to sell ads against those. We help people do that. We help people with a live-ramp-like experience enrich their data using third-party data sources.

And so we are moving in the direction where there's probably going to be like an emails part of the application and as well as the ads part of the application. And those two teams will have like very specialized UIs. And the whole idea is that this is still very much in our vision of make data usable to marketers.

But the ways we do that are, like, much more customized to what that marketer expects. So are they seeing reverse ETL pipelines in the application, or are they seeing campaigns? The marketer is used to running campaigns, so they should be building campaigns within the app.

Sandhya Hegde

Got it. And you know what keeps you up at night? What do you see as the risks in terms of how this market evolves?

Kashish Gupta

 I guess currently the thing that keeps me up is just the amount of user uncertainty that's in the market. And the amount of claims that are being made in the market that are not entirely true. And I won't name names, but I think generally like what would be best for the user is if they had perfect information, right?

I have exact like here's exactly what this product does versus this one and here's what they're saying They can do versus they can‌ do And if you could have somehow clarity on exactly which product would solve your needs, you wouldn't have to go through these like year-long buying cycles. You would just use the thing and be successful.

So I think like perception and reality are very different and I wish users could just see reality as clearly as possible, but there's a lot of incentive right now for users not to see reality. Even very large companies will market their CDPs that might not be fully developed yet. And I just wish there was a crystal ball that we could give users so they could have that realization for themselves.

And in that, we would‌ not claim that Hightouch is the best solution every single time. And there's so many times we've told our customers, use a different product for this because they built a better specialized solution for you. A great example of that is if you want to do if you have a brick and mortar store, you sell goods in person through point of sale, oftentimes Amperity is a better solution for you because they're really good at in-person to online ID resolution.

That's something they specialize in and no other CDP specializes in and we would often tell times, tell customers that. So we would love to build that kind of crystal ball of like just user certainty. And for that, I think we're going to need to know what people have built versus what they're marketing.

I think like what we're seeing in the market right now is when there's more confusion, then people will just take longer to make decisions.

Or potentially lose trust and CDPs have lost a lot of trust with their user base and we want to reverse that, but it's going to take some time.

Sandhya Hegde

 I'm curious, I think when it comes to like enterprise customers and dealing with sensitive customer data, it's always been really challenging to have a more product led motion. You need to get a lot of stakeholders in the room, sign NDAs. There's a lot of process involved, which also makes it harder to understand actual capabilities for perhaps the technical stakeholder in the room. How do you see that? Do you have an aspiration to figure out how to be even more product led? What would that look like for Hightouch?

Kashish Gupta

We have to play both sides, be able to manage that kind of like enterprise motion as well as the product. So what we do today is we encourage everyone to try it, to POC. So a lot of CDPs don't allow POCs because the POC itself would take many months. Our POCs usually take two weeks. And so we encourage every single person to do a free POC if they can. And often times they're doing that free POC with live data. So by the time the POC is done, they're‌ already implemented. And they can now ship this to production and just run their campaigns.

And so I think like to your point, right? Product does speak for itself. Especially with like our more lean InfoSec, given that we don't store any data. We can run these POCs much more quickly than others. And so I think you brought up a really good idea, which is that if we could build this muscle in the market, that the way I buy this thing is I always POC it. And then you choose from the vendors that run the best POC and have the best product in that POC. I think that would help people see that reality.

Sandhya Hegde

And I'll almost beg the question of okay, why are these companies not offering me a quick POC, right? What are they hiding?

And one of the other fascinating things about your team is you have a co-CEO arrangement and it's rare, like there are very few companies that make that effort at all, and very few companies that are able to sustain it.

I'm really curious what does being co-CEOs, what does the founder team dynamic look like at Hightouch, and what does it mean for you and Tejas to be co-CEOs? How do you handle it?

Kashish Gupta

 Yeah. So we've done this since the beginning of Hightouch and I would credit it to one of the main reasons that we've been able to be successful. So oftentimes like people will do a two co-founder split. So they'll say one person runs the technical side and one person runs sales and marketing.

And oftentimes that means that they have to optimize either sales or marketing. And it's really difficult to put a lot of strong thought into both of those two motions. We were very lucky because we had three co-founders, and all three of us were technical. And so we sat down and we said, hey, all three of us are technical, and we feel like we can build the engineering and product side of the company pretty well because we've done it before.

On the other hand, we‌ don't know how to do sales and marketing. And so that's when we said, okay, I think both Tejas and Kashish should do sales and marketing. And we need as much brainpower to figure that out as possible. As much time spent diligencing who to hire, how to manage them, what to do, what ideas. And we saw other founders around us also spending a lot of time on marketing in those days. So in the early days I was running marketing and Tejas was running sales, and we just did that split. So Josh was running product, I was doing marketing, Tejas was doing sales. And it was extremely helpful because we had the lanes of here's what we own.

And so I would source all the pipeline, Tejas would close all the pipeline, and Josh would have the product vision and serve all the demand. It was almost like a supply chain and it worked extremely well because we could have the three focus areas. And the cool thing is that because Tejas and I, we've lived together for so many years, we've been best friends for so many years, it's pretty easy for us to switch up our responsibilities and communicate.

So most decisions we make together, the three of us in the lanes that we've already had, we make final calls. So let's say there's a disagreement on the marketing side, but I run marketing, then I'll just make the call on that. And we've predetermined that I get to make that call, so it's not controversial.

And then, over time, as the need develops, we change up the responsibilities. So ‌, now Tejas runs marketing and product, and I run sales. And that's been really fun too, and it allows us to play to our strengths. And be able to focus on the areas that need the focus from the founders.

Sandhya Hegde 

No, it goes to show how much ‌trust and good communication drives velocity, right? I think just the velocity of being able to make decisions everyone has bought in on. I think a lot of folks who do like short founder dating periods before they start companies together really underestimate the value of that.

Kashish Gupta

Yeah, I‌ totally agree. I have had a lot of friends that do that kind of founder dating period. I even struggle to say that is enough. I've only ever really worked with folks whom I would say are, like, very close friends before starting a company together. And even with Tejas, I lived with him for, I think, over seven months before we started working together.

And we had already started spending almost every single day together, talking every day. And becoming very close friends and I'd already seen him operate in his job and in other parts of his like side projects and so on. So yeah, I would‌ encourage other founders to take as long as possible before like a shotgun wedding.

And just being really sure that you want to marry that person because it is a marriage and you'll be spending as much time with that person, if not more than your partner. Yeah. And I think like it our setup is pretty creative. I don't think it will work for everyone. There's both pros and cons.

But I think like for what we needed at the time and what we need today, I don't think we would have gotten here without that setup.

Sandhya Hegde

Makes sense. Any advice for aspiring founders in 2024? You've had a really interesting five-year run finding product market fit on your sixth idea, post series A round, and you still have like a very hype-y capital market cycle you are seeing let's just call it a far less hype-y market cycle.

Yeah, I'm curious you've had a very interesting five years. What would be your advice to people thinking about starting a company in 2024?

Kashish Gupta

Yeah. Okay. So I have maybe so many things to say here, so I'll try to keep it concise. One advice that founders get that I disagree with is to start something where you have a clear advantage. So folks will say, Oh, you've worked in manufacturing before. So you should start a manufacturing company because you have a very clear advantage.

I strongly disagree with that. You should work in the thing that you have the most passion in because passion will drive your hustle. The amount of time you spend, the amount you think about it, and how much you're excited to wake up every day. The majority of founders succeed because of resilience. They don't give up. That's probably the number one reason.

And two, because they hustle, they figure things out. It is not necessarily the case that they've already understood their core insight, and they've applied that core insight to create some outcome. It's usually that they find the core insight during that process. So I think folks that are founders, are betting on themselves to figure things out, not on already knowing.

And if you believe you already know, then you are likely incorrect. And so yeah, this whole concept of start something where you have a key advantage, where you've done the thing before, and you can like, easily raise money because you have a core insight. I disagree with that. I would really follow your passion.

And I've seen now so many folks start companies where everyone was saying, you worked in fintech, go do fintech. But then they instead started edtech, and because it was their passion, they really stick to it. are doing well in that space, right? And I would say the same thing applies for us. We were doing something quite outside of our scope.

We eventually found ourselves back in the data space, which is something that we know well. But it was not on purpose. It happened because user demand led us there.

Sandhya Hegde

 Yeah I was saying very well said. I think, wherever you start, eventually you have to end up with some authenticity, an authentic insight and an authentic understanding of your customer, both of which require you to really love the space and be willing to spend day in, day out, like doing the work.

I think it's a privilege to also have just worked in the same industry as opposed to a requirement.

Kashish Gupta

Yeah. And no, it certainly helps, and I agree with that. But the counterexamples are plentiful, too. And then the other advice I'd give, which might be similar, is just folks are oftentimes thinking about what skills they need before they start a company.

Or what they want to learn.

So they might go learn about LLMs for 6 months or 12 months, or work in an AI company before starting an AI company. And I also disagree with that mentality of, here's like the list of things I need to know before I can start a company. Because when you get there, you'll realize there's so much more you need to know to succeed, and you'll have to learn a little bit on the job, right?

My belief is that people learn when the challenge arises, and when they see that challenge in front of them. And they learn the fastest in that scenario. I would say if you have conviction in something, especially like some place that you want to make change, decide where you want to make change, go tackle it and start now instead of starting slowly or starting later or starting after you have a certain skillset.

And, again, that I really think that you can see a lot of the most successful founders didn't necessarily have the credibility or experience to say that they can run a company, but when the need arose, they like learned enough to meet that need.

‍