The 90th episode of Datacast is my conversation with Kashish Gupta, the founder and co-CEO of Hightouch.

Our wide-ranging conversation touches on his education at the University of Pennsylvania studying Computer Science; his learning about venture capital at Bessemer Venture Partners; his first startup Carry that went through Y Combinator; his current journey with Hightouch building a data activation platform; lessons learned creating the Operational Analytics category, pivoting through various startup ideas, identifying design partners, hiring talent, fundraising; and much more.

Please enjoy my conversation with Kashish!

Listen to the show on (1) Spotify, (2) Apple Podcasts, (3) Google Podcasts, (4) TuneIn, (5) iHeartRadio, and (6) RadioPublic

Key Takeaways

Here are the highlights from my conversation with Kashish:

On His Upbringing

I credit a lot of who I am to the high school that I went to. It is probably the best free public education I could have ever received and better than any private school I could have attended. I went to the Gwinnett School of Mathematics, Science, and Technology, which was started in 2007. When I joined in 2010, it was very new without any stats, but the whole focus was around STEM subjects. Growing up, I always wanted to study science, so it was a no-brainer to join that school. Over time, the school got ranked the second hardest school in the US. It taught me to focus on the process rather than be results-oriented. The thirst for learning was instilled in me at a young age.

My dad has always worked with a computer, making it easy for me to get into engineering. I wanted to become a mechanical engineer during that timeframe and work with my hands. That obviously changed over time, but it was my intro to engineering.

On His Education at UPenn

The good or bad thing about UPenn is that people are very professional. Penn is meant to be a school that does not teach you theory. It teaches you how to do things in the real world. For me, I started off learning business in order to start a business at Wharton. However, it turned out that Wharton does not teach you how to start a startup. Their version of business is meant for Fortune 500, a very different type of mentality from the startup mentality. After about one year, I more or less stopped taking Wharton classes and started taking only classes in the engineering school. They were much more interesting, intellectually stimulating, and in the realm of startups (because if you learn computer science, you can build and start anything).

During my undergrad, I dual majored in business and computer science but always had much more of an interest in the computer science side. What tipped me over was when I went to Penn Apps (the world’s largest hackathon) for the first time and saw what people were doing with CS (which were some of the most fun stuff you could do). They were developing end-to-end applications (rather than scripts) and hacking them together so quickly. It was inspirational because it showed me that pretty much anything I imagine can be put into paper and developed physically.

For my MS degree in Robotics, I took the majority of classes in Computer Science. Out of those, I enjoyed databases. I am not the best developer, especially compared to my co-founders. But what I can do is understand databases pretty well. My fundamental thinking is that if you can understand a database, you can understand the entire architecture of an application because the database informs the rest of the application. Besides that, I took classes in brain-computer interface, natural language processing, computer vision, and more. I felt like I understood the fundamentals of how ML works and how to turn something with too many data inputs into a more discrete-sized input variable for a neural network.

On Internships Lessons

I interned at a healthcare startup, a hedge fund, and a small tech startup. The majority of my learnings during those internships were soft skills. For example, at the hedge fund, my boss told me to tell him what I wanted out of this internship in my first week. If I do not ask for anything, I will not get anything. I learned pretty early that going into something like an internship, I should have an intention at the forefront. That intention could be meeting people, making friends, finding mentors, learning something new, etc. It does not necessarily need to be contributing something meaningful to the company.

I was living in New York for another internship, and that experience made me think that what I had was never enough. When you see people in New York, they always have more money than you, look better than you, and are cooler than you. One time, me and my coworker were on the rooftop of the building we were working in and found the rooftop beautiful. At the same time, all these other rooftops were just a bit higher than ours, and we wanted to be on those. That moment clicked with me. The race is never going to end. High school is a race to get into the best college. College is a race to get the best job. Every job is a race to get promoted or get a better job. But at the end of the day, it does not matter how you compare yourself relative to other people because there will always be people who are better off and have more privilege than you. It is only useful to compare yourself to where you used to be. For me, there has been a monumental change in where I grew up and where I am now.

I also learned how to work with managers and collaborate on teams. I was lucky that I only worked for really small teams. I have never worked for a big corporation, and this is one of the biases I am trying to actively remove. I have never seen what a typical corporate structure looks like, what manager 1-on-1 looks like, what HR structure looks like, etc. Sometimes, employees would join Hightouch and ask tactical questions that I had never thought about, so I tried to get the context for where other people were coming from.

On Building His Passion For Startups

At Penn, it is quite easy to get drawn into working in industries like finance or consulting because there is so much money to be made. I was lucky to find a solid internship during my junior year at Bessemer Venture Partners. I thought: “What else can I do for the next year and a half that allows me to do something even more interesting than venture capital?” I figured out that was startups — learning to be a proper engineer and to start a company.

I traveled to Mexico City one summer after my internship. That trip was monumental. I met a friend who went to the MIT of Mexico to study engineering. She said that no matter what she does, she is going to become successful. Ultimately, she will be considered one of the best engineers in her country and do really well for the rest of her life. This was mind-blowing to me because I had never thought about the world in that way — like there is nothing that I can do to screw up. The base case is to do really well.

This is a great perspective because up until that point, I thought I did not have the privilege. But she made me realize that going to a good school like Penn means that I should figure out what is meaningful to me and what I am passionate about rather than working a job. I had the privilege to think about that kind of stuff, which my parents or many people do not.

On Learnings at Bessemer

As an analyst, my primary job was to source deals by talking to founders/CEOs, learning about their businesses, and pitching the VC partners on whether they wanted to invest. I was basically selling two sides — the founders on taking money from the firm and the partners on investing in the founders. That match-making process is quite difficult because partners will want to invest in what they want to invest in at the end of the day. You are much better off finding companies and industries they are already interested in. To be honest, venture capital is a game. There are certain things VCs want to hear, and if founders were taught to say those things, they would be much more successful at raising quickly (i.e., recurring revenue, retention, bottom-up growth, etc.).

My core thing at BVP was ML/AI investments. It was cool to be able to work on something I actually had more domain expertise than most people. People would bring me in and trust me to do due diligence on companies working on self-driving cars, voice transcription, etc. Looking back, some of the decisions I made not to invest were solid, and some I made to invest would have also been bad. There is no answer for being a good investor or a bad investor. People are correct that if you make multiple bets, then some will be good, and some will not be good. For me, it was an amazing experience getting exposed to the most number of ideas and startups as quickly as possible and seeing patterns of successful companies. Nevertheless, my heart was not in VC long-term because I felt like if I wanted to invest, I wanted to invest my own money and have complete control of the process rather than working at a fund.

Many founders have the mentality that all VCs just give them money at the end of the day, and there is not that much more to think about past that. I do not completely agree. Having a really good VC can be helpful, and having a really bad VC can be hurtful (since they can push you out of your own company and force you to make decisions you do not want to make). When calibrating on choosing a VC to take money from, you should calibrate on trust rather than more surface-level things like introductions to potential customers or specific hires. Those are temporary things people often help with in the first few months of making an investment, but then you are with this person for the next five years (which could be the lifecycle of your company). During that time, you want someone who gives you the benefit of the doubt, trusts you to make decisions, and supports you in those decisions. That is probably my biggest learning after working with a few different VCs for Hightouch.

On Moving to San Francisco

I wanted to move to San Francisco and find a software engineering job. At the time, I was searching for one in Atlanta, and it was pretty difficult to get introduced to companies so far away. After a few weeks of searching remotely, I decided to move to SF, couch-surf with friends, and meet people as a way to get into companies (hopefully startups). My parents were quite scared of it because I would not have anywhere to live or any money, but to me, it was way better than being at home in Atlanta.

Throughout that process, I did not end up finding a job in software engineering. I was looking for an ML job, which looks for people more like software developers or with Ph.D. degrees. I was neither of those two. I did several interviews and could not find anything that was a good fit. During that time, I pitched a few different people on a travel company that I had. I did not want to start a company right out of college because I wanted to learn how software engineering teams work. I wanted to be a software engineer first before being a startup founder. However, what ended up happening was that I was talking to people about my travel startup idea and receiving great feedback. I let go of the job search because I found the first three or four companies that would be my end users.

On Starting Carry

I definitely did not want to be a travel founder. Travel is a tough industry to be in. Ultimately, what pushed me in that direction was a strong customer demand for our product. Carry is a Slack bot that people would install in their Slack workspace, and it would book all your company travel for you. Instead of having a travel agent at your company, you could just message Carry via Slack, and Carry would give you flights, hotels, rental cars, etc., and book all of them for you on the corporate card. It had a beautiful UX that people really liked. At the time, it was not automated at all. There were real human beings in the backend booking travel for you, but they were trained to provide a good user experience. In the beginning, it was just me, Tejas, and our first hire, Ernest, making all the travel bookings for our customers. I started Carry in October 2018 and worked on it for about 7–8 months before we raised any money. That period was very slow.

One of the biggest learnings during that period was our core value proposition — we were able to find Travel Agency Rates that we can give people over Slack. Traditionally, online rates are a bit more expensive than normal agency rates. That is how travel agencies make money (because they give you better rates). But, they only give you those rates over the phone, which gives them a leg up compared to online travel retailers. I called a bunch of travel agencies and found a guy who worked with me to start my own travel agency, which was an automated online travel agency. Through him, I was able to get access to unpublishable rates, which sometimes can be 20–30% off of airfare. We were saving people up to $1,000 on their airfare, and that was the core value prop if you use our travel assistant: you could book travel cheaper than buying your own travel.

We were trying to figure out different ways to scale that out. The only thing we could not do was to create a web app because then it would be like an online rate. As long as you do it over Slack or text messages, you can get around the industry’s unpublishable fares. I think someone will still do something cool where they will make these travel agency rates available to the general public through some private applications. We had much conviction in the business because we knew that we would always have an arbitrate in rates, where we could either save people money or make money on the delta of the rates.

On Going Through Y Combinator

I see YC as a great forcing function for growth. There are only two reasons why someone would want to do YC, and we did not squarely fit into either of them. One is because you need help fundraising, and two is because you need help breaking into the Bay Area ecosystem. If you are a founder outside of the Bay Area, it is a really strong way to have a network here and establish connections with VCs.

At the time, I had already been meeting VCs for several months, and Tejas had also known VCs for many years because he had been in the Bay Area for a while. We thought of YC as a way of meeting our potential customers and bootstrapping Carry quickly. That helped us raise our seed round shortly after YC and move to our subsequent growth stage. I have no regrets, but I definitely stand by fundraising being the number one reason why founders do YC.

On The Founding Story of Hightouch

In 2020, we were working on the travel company and had already wanted to pivot because we did not think travel was a sustainable business. Then COVID happened and, as a result, people completely stopped traveling. We had to make a hard decision to shut down the travel business, lay off a couple of employees (we gave them really good severance), and start completely from scratch on new ideas. At the time, Tejas and I were working on something related to Slack and customer success, while our housemate Josh was also pivoting his business in the IoT space. All three of us were thinking: what if we combine our businesses and do something together in either the customer success space or the data space?

We kept the cap table for our Carry Technologies Inc. business. We did not return money to investors and just continued because we had not spent a lot of our money. At that point, we had raised about $2.1M, with $1.8M left in the bank. We were extremely frugal throughout the lifecycle of that business. Since we have already fundraised, we would be able to go much faster and skip a lot of the ops work. We took the cap table and explored ideas in customer success. Each idea sort of led to the next idea:

• We started Hightouch as a customer success business, realizing that customer success workflows are already quite competitive (Gainsight, Catalyst, etc.). What if we instead do aggregation of communications data because a customer success team often wants to know what sales/support/solutions teams say to the customers but do not have a good view of all these different communication channels. Then Hightouch became a platform for aggregating all the communication with customers.

• We took that to market. We had many companies looking at it and expressing their interests, but ultimately, it is just not as important as their customer data. They wanted to know how many times their users were logging on, requesting help, or inviting new members to the workspace. Therefore, we decided to centralize customer comms and customer usage into a data centralization platform. Hightouch became a dashboard where users can type in a customer’s name and get all information about them. We used Powered-by-Fivetran to operate that product — using Fivetran’s SaaS connectors, bringing all that data into our database, and serving it to our users in real-time in the dashboard.

• But then we had two types of customers: Our startup customers loved our product. But our bigger customers (between 50–200 employees) already had a data warehouse, which does the job of centralizing data, and their own Fivetran subscriptions. Thus, we decided to focus on the mid-market, assuming people have a data warehouse as a pre-requisite for using Hightouch. We stopped using Powered-by-Fivetran and started using data warehouses and databases as our only sources. Our customers loved it. Compared to other BI tools, Hightouch got the data in front of the business users, who were living in their own CRM tools of choice (Salesforce, Zendesk, or Marketo).

• Then we said, instead of giving them the data and dashboard, let’s give them data directly in the tools they use. Hightouch ultimately became a product for getting data from a data warehouse into anyone’s SaaS choices. But that really happened throughout this iterative process of showing customers our product and getting their feedback on it. Each time, they gave us our next pivot. We could not have thought of those ideas from first principles without the feedback of those customers. Oftentimes, they just directly told us that our solutions did not make sense. It is good that we had strong-minded customers that showed us the way.

Both Tejas and Josh worked early at Segment. Hightouch is not dis-similar to Segment. Segment’s value props come from collecting data, storing the data, and sending the data to SaaS tools. Hightouch only does the 3rd part of those — sending data to SaaS tools. But it is pretty different from Segment in that we serve the data team and do this process in the best-of-breed way (rather than the full-stack way). While doing user research to understand what our users want, it was difficult for us to believe that Segment had not solved this problem already. But what we learned from a lot of enterprises is that: Segment works up until a certain point, and then it breaks because the data model constrains it. In Segment, you just have users and events on those users. You do not have a data model for past users. We realized that there are specific market segments where Segment does not work anymore. For example, if you are using a data warehouse, you do not want to use Segment as your source of truth because you already have Snowflake or BigQuery.

It was hard for us to let go of the full-stack model and believe in this whole data warehouse model. But because many of our users believe in the data warehouse model, that is how we ended up starting Hightouch with. We realized that the data warehouse will be the infrastructure that replaces a lot of SaaS tools you use today. If you currently think of Segment or Salesforce as your source of truth, we realize it is going to be something like Snowflake or BigQuery in the future, and no tooling is currently built on top of those.

On Pivots

After you do a couple of pivots, it gets incrementally easy to do more pivots because you are no longer married to the idea you are starting. For the first couple of pivots in travel, it took us a long time since we loved our idea. But the next few pivots were super rapid-fire because we expected there would be a pivot. We were no longer married to our ideas. It took about three months for us to go through 4 different ideas and land on Hightouch as it is today because we had way lower friction on changing our ideas.

In the beginning, we focused on how to make an idea work. As we did more pivots, we focused on how to validate that idea (whether this is a good or bad idea). I would encourage every founder to think about the speed of dis-validation: figuring out what you need to dis-validate your idea as fast as possible because the worst case is that you work on a startup for many years, and it will not go anywhere. You still want to be a believer, but you must get to the pulse of making decisions quickly on your business.

On Operational Analytics

People have all their analytics and insights in some BI tools (Looker, Mode, Metabase) and perform some analysis on them. Operational analytics turns the analysis for the analytics into actual action. For example, you might have a marketing team that calculates churn risk or predict the LTV amount of dollars spent to acquire users. You might want to run specific campaigns on users that are at a high risk of churning or have a high probability of purchasing an item. Let’s say someone visits your website seven times. They download your E-Book and are about to download your iOS app. They have visited the pages three times and will probably buy your product. You want to send them emails for them to take that action. That is a good use case for taking BI data, giving the data into the hands of marketers, and letting them run re-engagement campaigns on it.

But usually, what happens is that analytics just gets stuck in the BI tool and does not get operationalized. For us, operational analytics is not doing analysis on your operations. It is taking analysis and turning it into action. The beauty of it is that if we can achieve it, then anyone (not just the engineers) will be able to take their analysis in their data warehouses and turn it into a campaign or workflow automation. We want to turn BI analytics into automation that powers different workflows: marketing, customer success, support, or sales workflows.

On Reverse ETL

Reverse ETL is a term created by our customers. It helps people understand what we do. If you think of ETL as getting data into a warehouse, you can simply think of Reverse ETL as getting data out of the warehouse. This need did not exist until warehouses were fast enough to power operational workflows. Traditionally, you have always thought of getting data into a warehouse and backing up all that data to get analytics out of them. Because the warehouse is a big, slow, and cheap place to store data, you did not think of it as an operational tool (the queries would take three or four hours to run). People usually run those queries overnight and get some dashboards in the morning that would show some metrics.

Now, there is a shift in users’ minds (which has happened only in the last year and a half), where they want to use data warehouses to power their workflows (thanks to companies like Snowflake and BigQuery). The queries would run in 5 minutes instead of 5 hours. That is why there is a need for Reverse ETL because you have already done the job of centralizing all your data. This is the first time you have had all your data across your entire company in one place (marketing, sales, product, engineering, etc.). The centralized source of that data was never fast enough to power operational workflows. But now that those two things have happened, the very clear next step is to get this data out and make it useful, rather than letting it stuck in the data warehouses. That is why Reverse ETL makes sense as a product and why customers have been asking for it in the past year.

A lot of teams build Reverse ETL in-house. Their data teams get tasked with bringing data into software like Salesforce or Facebook Ads. They write a Python script that builds Reverse ETL in-house and directly gets data from some database/data warehouse into their software. The only difference now is that we are providing a SaaS tool that’s hosted out-of-the-box to do that for companies (so that data engineers do not have to do this integration work themselves).

Hightouch product is very simple: It is a SQL UI that pulls data from any database or data warehouse and sends that data over to the SaaS tools. You simply map the columns in your data warehouse to the columns in your SaaS tools and maintain those sinks by checking for the changes in data (the ‘diff’), sending those diffs over to the end destination, and ensuring the data has been successfully linked. If not, we will retry and check for errors. Fundamentally, Hightouch is a data-sinking product.

We also have different deep integrations that are not just ETL. That is why we do not love Reverse ETL as a product name because it is a bit constraining. Reverse ETL sounds like you are just copying a table from one data warehouse into a table in another software. The reality is that you can power a lot more interesting workflows — building a Slack bot, creating a Zendesk ticket, making tasks in Salesforce, or assigning people to Asana projects. We want to talk to more users about how they think about Reverse ETL and bring more of these workflow-type use cases into the category of Reverse ETL over time. But it is a great shorthand for people in the data community to understand that Hightouch gets data out and ETL gets data in.

On Hightouch Audiences

Hightouch Audiences is a UI for marketers to access data without having to know SQL. Hightouch started as a SQL product meant for more technical users like data engineers to turn SQL queries into data pipelines. Over time, as we started talking to more customers, they said: “Hey, I would love to use your product, but I do not know SQL. How can I use it?” So we built the second interface, which has always been part of the plan. We actually launched something like this in early 2020 and turned it off because we found that data users were not excited about it. But now, we rebuilt it from the ground up for marketers. And the use case is that a marketer can make filters on top of existing data models.

For example, the data team provides two data models to the marketing team to get the necessary data. But the marketing team needs to do a lot of filters on top of these models. You might say:

• Give me all users in the last 30 days that added a product to the cart and then did not purchase the product within one day.

• Then with those users, give me the skew of the product that they added to the cart so I can market them to the same product.

• You want to pull this as a table and sync it to Facebook Ads.

• Facebook can run an ad on all of these users exactly when they start dropping off your abandoned cart campaign or with the product they viewed but did not buy.

That is the kind of campaign you can run in Hightouch in under 5 minutes, which the marketing team usually has to go to the data team. These campaigns literally take weeks of work for someone to run. Now they can be run independently without the help of engineering. This allows marketing teams (as well as other teams in the company) that want access to the data to access it in a self-serve way. Then, they can take action on it by sending emails/ads or doing marketing operations on that data.

On The Modern Data Stack

Reverse ETL is the last mile delivery of data. ETL is pretty solved with Fivetran. dbt is an excellent tool for transforming data and maintaining data models in the data warehouse. The last remaining thing for the modern data stack is getting the data back out and into the operational tools where business users live. That is where Hightouch is and where we can provide the most value. It is a way of completing the modern data stack and providing the full feedback loop. Now that you have the data back in your operational tools, you have a full 360-degree loop in which data can be brought via Fivetran back into the data warehouse again.

Previously, the data warehouse was always at the right-most icon in a data stack diagram. There was no arrow out of the data warehouse. Now, we live in a world where the data warehouse is in the middle of a diagram, with feedback looping back into all the tools and back into the warehouse. It is an entirely different framework for thinking about how a data team sits within a company. Instead of post-processing data, the data team is actually sitting directly in operational workflows. A lot of engineers get excited about this, and so do we.

On Hiring

Founders should not be hiring employees based on their skillset. There is a ton of people with a skillset out there who might be down to join your company. But the two things that are really difficult to calibrate in an interview but probably matter the most are (1) how much care they take in their work and (2) how much they want to grow. For example, many engineers at Hightouch only have 3 or 4 years of work experience. Yet, they are growing like crazy. They have already become managers/tech leads and have taken on an insane amount of responsibility within the company. The reason for that is because they just really care about their work. They really enjoy it. They have a passion for being detail-oriented and taking care of customers.

If you care about the end customer, you want to give them the best experience possible. You will focus on quality, think forward about architecture, and look at ways to unblock them. It is not just the engineering team. For example, the sales team unblocks customers all the time by extending free trials or facilitating integrations. Everyone is on the same team to help customers. They are not focused on helping themselves, climbing the corporate ladder, or proving they are right. It is more like what we can gather from customer feedback that helps us improve the team as a whole.

On Finding Design Partners

Each customer wants a different thing, so you have to get good at recognizing patterns between market segments, verticals, or types of companies. Furthermore, each company has a different people structure that influences how they make decisions and think about Reverse ETL. So figuring out which advice to take in and which advice not to take in is important. Having enough design partners to get that feedback and draw those patterns helps a lot.

Originally, we actually tried to sell to marketing teams. It did not work because marketers have trouble understanding why they should buy our product versus other products in the market because they do not care about the data warehouse or understand why the data warehouse is the most important thing for Hightouch. Whereas when we talk to data users, this totally makes sense. They believe in the data warehouse. Learning that we should not sell to marketers and sell to data folks instead was a pivotal moment in our business. That allowed Hightouch to take off and find a product-market fit. The product did not change. It is just that the market we were going after changed from marketers to data people.

On Pricing

We used to do a pricing model based on volume, which did not make any sense. Most users cannot calculate how much volume they are going to do because they have not turned on the product yet. Many SaaS tools in the market have this problem, where they price based on the volume that allows customers to grow and pay over time. However, (a) customers hate it because they have to pay more as their business grows, and (b) they just have no idea how much they are supposed to pay because they do not know how much data they will send.

We then interviewed ten customers and five prospects about potential pricing model ideas. Almost all of them landed on pricing per destination. Each use case in Hightouch is a destination. We settled on a tiered method, in which the first integration is free for life with unlimited usage. Then number two and three are bucketed, number four and five are bucketed, and so on. Customers do not have to decide every time they use a destination. They just have to make a decision upfront about how many approximately they want to use.

On Go-To-Market

We are really focused on building out our marketing and evangelism function. We have always grown in an inbound way via product-led growth. We have not made any outbound sales and do not plan for it. It is quite fun. We basically talk about our product, our use cases, our customers and launch different tutorials and products to tell more customers about Hightouch. We used to market primarily to data teams. Now, we also market to RevOps and marketers. We get to do these types of marketing campaigns that generate inbound and convert that inbound into sales. Most of our go-to-market initiatives are content-driven, community-driven, and evangelism-driven.

We are also very excited about partnerships. We have already partnered closely with Fivetran and dbt, the other two components of the modern data stack. We love working with them on co-marketing and co-selling because many customers ask for the three tools for their stack. We are looking to expand relationships with more partners (Hubspot, Iterable, Braze, etc.), basically SaaS tools that we can integrate with. The value prop of Hightouch is to make it easy to onboard onto those platforms. The friction of onboarding reduces dramatically for any SaaS tools you use, which is a huge value add for our partners and for us because we get new users.

On Fundraising

Founders should find someone who understands their space and believes in their go-to-market for that space. For example, we like working with Amplify and Bain because they do not tell us to go out and make a bunch of revenue. They let us focus on market leadership rather than revenue growth. For us, if we win this market, then we will succeed long-term as a business. Right now, we care about working with as many customers as possible, learning from their use cases as quickly as possible, and building the product as fast as possible. How often do you meet a VC who is focused on those things? Not very often. You usually meet VCs who push you to grow revenue from a few million dollars to $10 million. But that is not necessarily the right long-term goal because you might succeed in short-term revenue but will not win the market long-term. Finding those investors who are aligned with how you want to run your business is probably the most important piece.

Generally, people only meet investors through warm intros. That is honestly a sad nature of the industry, but a good way is to find a few angel investors who believe in you and get instructions through them. Then, you should also find a few founders who do different things than you but have raised before and get introductions through them. Most founders at the Series A and B stages already know most of the VCs in the Valley. They will be able to introduce you. Founders are inherently believers and optimistic, so they will be likely to help.

We are fortunate to have raised early rounds in 2020 because that funding allowed us to grow much more quickly and invest more heavily in our team.

Show Notes

• (00:43) Kashish shared briefly about his upbringing in Atlanta and his early interest in STEM subjects.

• (02:38) Kashish described his overall academic experience studying Economics, Management, and Computer Science at the University of Pennsylvania.

• (05:53) Kashish walked over the Machine Learning classes and projects throughout his MSE degree in Robotics.

• (09:02) Kashish shared valuable lessons learned from multiple internships throughout his undergraduate: data science at Implantable Provider Group, investment analysis at Tree Line, and product management at LYNK.

• (13:14) Kashish told the anecdotes that enabled him to realize his passion for building startups.

• (17:14) Kashish recapped his learning about venture capital from spending a summer as an analyst in early-stage deep-tech companies at Bessemer Venture Partners in New York.

• (22:09) Kashish shared learnings from his entrepreneurial stints at an early age.

• (26:12) Kashish talked through his decision to move to San Francisco after college (Read his blog post explaining how he moved here without a job and a home).

• (29:04) Kashish recalled his experience working on a project called Carry (an executive assistant for travel on Slack) with his friend Tejas Manohar and going through Y Combinator.

• (36:40) Kashish shared the founding story of Hightouch, a data platform that syncs customer data from the data warehouse to CRM, marketing, and support tools.

• (44:15) Kashish emphasized the importance of speed and execution around different pivots that led to Hightouch.

• (46:35) Kashish unpacked the notion of Operational Analytics, an approach to analytics that shifts the focus from simply understanding data to putting that data to work in the tools that run your business.

• (49:46) Kashish dissected Hightouch’s market-leading Reverse ETL, which is the process of copying data from a data warehouse to operational systems of record.

• (54:51) Kashish discussed Hightouch Audiences, used primarily by larger B2C customers, that allows marketing teams to build audiences and filters on top of existing data models.

• (58:09) Kashish explained how the “Reverse ETL” concept fits into the quickly evolving modern data stack.

• (01:00:26) Kashish shared how the Hightouch team prioritizes their product roadmap, given the high number of customer requests.

• (01:02:47) Kashish shared valuable hiring lessons to attract the right people who are excited about Hightouch’s mission.

• (01:05:13) Kashish shared the hurdles to find the early design partners and lighthouse customers of Hightouch.

• (01:08:06) Kashish explained how Hightouch prices by destinations, reflecting the value customers get from using the product and helping them predict costs over time.

• (01:10:32) Kashish shared upcoming go-to-market initiatives that he is most excited about for Hightouch.

• (01:14:36) Kashish shared fundraising advice for founders currently seeking the right investors for their startups.

• (01:17:47) Kashish emphasized the industry recognition of the Reverse ETL market.

• (01:19:47) Closing segment.

Kashish’s Contact Info

• LinkedIn

• Twitter

• GitHub

• Website

• Medium

Hightouch’s Resources

• Website | Twitter | LinkedIn

• Data Features | Hightouch Audiences | Hightouch Notify

• Docs | Blog

• Customers | Careers | Pricing

Mentioned Content

Articles

• “On Moving to SF Jobless and Homeless” (Aug 2018)

• “Hightouch Ushers In The Era of Operational Analytics” (March 2021)

• “The State of Reverse ETL” (May 2021)

• “What is Operational Analytics?” (July 2021)

• “Hightouch Has Raised a Series A!” (July 2021)

• “Hightouch Raises $12M to Empower Business Teams With Operational Analytics” (July 2021)

• “The Cloud 100 Rising Stars 2021” (Aug 2021)

• “What is Reverse ETL?” (Nov 2021)

Companies

• dbt Labs

• Shipyard

• Big Time Data

Book

• “The Hard Things About Hard Things” (by Ben Horowitz)

Notes

My conversation with Kashish was recorded back in August 2021. Since then, many things have happened at Hightouch. I’d recommend looking at:

• Kashish’s piece about Hightouch’s transition from Reverse ETL to becoming a Data Activation company

• Kashish’s recent talk at Data Council Austin about the current state of Data Apps built on top of the warehouse and the future as warehouses become even faster.

• The release of Hightouch Notify that sends notifications on top of the data warehouse

• Hightouch’s Series B funding of $40M back in November 2021

Finally, Kashish lets me know that back in August, Hightouch were only 25 people. Now, the company is 70-person strong!

About the show

Datacast features long-form, in-depth conversations with practitioners and researchers in the data community to walk through their professional journeys and unpack the lessons learned along the way. I invite guests coming from a wide range of career paths — from scientists and analysts to founders and investors — to analyze the case for using data in the real world and extract their mental models (“the WHY and the HOW”) behind their pursuits. Hopefully, these conversations can serve as valuable tools for early-stage data professionals as they navigate their own careers in the exciting data universe.

Datacast is produced and edited by James Le. Get in touch with feedback or guest suggestions by emailing khanhle.1013@gmail.com.

Subscribe by searching for Datacast wherever you get podcasts or click one of the links below:

• Listen on Spotify

• Listen on Apple Podcasts

• Listen on Google Podcasts

If you’re new, see the podcast homepage for the most recent episodes to listen to, or browse the full guest list.