Startup Foundations: Interview with Christina Gilbert

Christina Gilbert is a co-founder of OneSchema, a Y-Combinator backed startup working on data importing tools for SaaS companies. OneSchema was a part of the YC’s S21 cohort, and ever since has been gaining a lot of traction, supplying a well-researched product, that solves many pain-points for “system of record” companies that deal with extensive databases.

Christina talks to us about the customer base or OneSchema, and delves deeper into the features of their product. She also speaks on the process of finding her co-founder, Andrew Luo, and the origin story behind OneSchema.

We discuss the challenges of building data import tools and the future roadmap for OneSchema, including building multi-file data migrations. Christina also shares her thoughts the value of going through Y Combinator and how it’s been helpful in getting their first customers for OneSchema.

🎧 You can listen to the entire conversation here. 🎧

Greg: Tell us what you're working on with OneSchema.

Christina: OneSchema is a tool for customer success and post-sale teams to help them get data into the right format for import into their SaaS platform. We also have a version of the tool, which is used by product and engineering team so that they don't have to build a CSV importer and customers can self-serve their own data setup.

G: What does your typical customer look like and what kind of data are they importing? What does a typical migration look like from one vendor to another?

C: Pretty much any SaaS company that we call a "system of record" SaaS company. This might be something that looks an ERP or CRM, over the course of working on this company I've been shocked by how many companies there are out there that exist for basically CRMs or ERPs for different verticals.

We've had conversations with everything from SaaS for pest control services, SaaS for old folks homes. It is actually really surprising, just the breadth of the types of companies that exist.

So, to your question about what does the data migration look like? Basically, the customer will be using some older system to start their data. Maybe it was an On-prem CRM, maybe it was an in-house system. Maybe it was one of our customers' competitors. And they will export a bunch of CSV files from that system. And they need to be configured and reformatted into the correct schema so they can be imported into the new system.

Typically, it's a really painful process. It involves a lot of sending files back and forth between the customer and the customer success manager. A lot of iterative uploads as they look for errors. And the importer is telling them that there is an error on line 62 and they're having trouble finding it until the data is finally setup. It's one of the things that slows people down the most about customer onboarding to SaaS products, of course there's training and building integrations and all those sorts of things, but the customer's not seeing any value in the product until all the data is setup.

OneSchema helps make the process not only faster, so instead of it taking 90 days for your customer to get started with your product, maybe more a week or two weeks. And just making the process a lot less painful for everyone involved, really being able to learn about the product and spend time getting value from it instead of having their head in CSV files for month.

G: So, take us back to the beginning. How did you first get the idea? How did you find your co-founder? How did you decide to work together? What made you really want to work with Andrew?

C: Andrew and I go way back. We studied computer science together at Stanford. We weren't super close friends then, but he actually went to middle school with my best friend. And as I was looking to leave Google, which was my previous role as a product manager there, I was telling her I was looking for a co-founder. She said, "Oh, do you remember Andrew Luo? He's looking for a co- founder too." And we just had a fantastic skillset match. He was an engineering manager at this company called Affinity. They're a CRM for VCs. He was an overachiever and graduated a year early to start working there. So, he had quite a lot of experience. And I had a background in product. The idea for the company came from Andrew's background. Andrew, when he was working at Affinity, one of the projects that he owned as an EM, was building out their data importer.

And this was the kind of project that it took multiple iterations for his engineering team to get right, was because they would build one layer of it realized that it was a very complex problem, build another layer, another layer, another layer. And it was the sort of thing that felt a never ending problem for the team. And there were leaders on the team that were saying, we don't understand why this is something we need to build out. We would rather be focusing on our core technology, which is helping investors be more efficient with their workflows. Can't we just buy a data importer. We talked to a bunch of other companies that looked similar to Affinity and they all said exactly the same thing. This has been a huge challenge for us, building and maintaining these importers is something that we have no interest in doing. We would love if you would provide a solution. And OneSchema was born, that's what we've been building ever since.

G: Tell us what your ideal state is for the company, say two, three years out from now. What features do you hope to have built? How do you plan on scaling the business?

C: I think a really interesting direction for this product that is a very thorny and unsolved problems is multi file data migrations. Today if you need to do a single file, it's not the best workflow, but you can tell your customer here's the template and then do the back and forth. But for a multi file data migration, where you're validating relationships between tables, how are you going to explain to your customer what a join is and why they have a joint key error. When the example would be something like they have an accounts table and a contacts table, you can't import a contact that is not linked to an account and an account is missing.

I think that there's an opportunity around building self-serve importers that can do simple multi file migrations. If you have a 20 file migration, I don't know if I think that will ever be self-serve. But I do think that the tooling for that's not great. Today it's an Excel workbook that you try to stick into your system eight times and it will throw different errors related to the different tabs. And it takes a really long time.

G: Or it's a data analyst writing a bunch of SQL.

C: Yes. That is another workflow too. So, a really common theme when we talk about value proposition for our customers is how can we help take work from more technical, more data savvy team members and move it to less technical, less data savvy team members. So, what if instead of having a data engineer do these migrations for you, you could put it onto a member of your support team. Or again, depending on the level of data complexity, even put it on your customer.

And customer self-serve, a lot of our customers feel it's a better experience than having their support team do it just because the customer doesn't have to wait. They don't have to deal with it back and forth. It's really snappy for them to resolve the issues and the data if there's a really clean tool that educates them about what the problems are.

G: Yeah. They know their data better than you know their data. So, if you're dealing with outliers and edge cases and how to resolve them or normalize them, I think a self-serve tool would be much more effective and efficient.

C: That's exactly right. And what we see is the customer success team or employees of the company that you're onboarding to, they have knowledge of the data model. They understand the sorts of things that an importer is going to throw an error on. And the types of things down the line that if you import incorrectly will cause problems with your success with their platform. The customer then has context on the data. And so they know what should be done with missing fields or what they want the default value for a field to be.

And that back and forth process between the customer and the post-sale team often is bridging that gap between the knowledge of the data model and the knowledge of the data. So, our tool empowers people with the knowledge of the data to understand the data model in a simple way. So, they don't have to work with a person on it, through this really painful iterative process.

G: I think a lot of the tools that are emerging for working with data are going to empower a lot of people to work with large data sets in a way that hasn't been possible before. Because before you had to know how to probably write Python code, write advanced SQL or hive queries, if the data clusters in Hadoop and that was the only way that you could actually deal with data.

C: Yeah, that's definitely true. And it's interesting too, if you look at even the no code tools on the market that are more advanced spreadsheet, sorts of things like Trifecta. They all are for working with data that's intended to be sampled. So, they'll give you insights on aggregate level statistics about your data, but they're not good for doing things one off row edits. I don't even think in a tool like Trifecta, you could go edit a single record because they work on data in bulk. OneSchema serves a really particular use case, which is data cleaning, where you're expecting to clean data record by record.

Because each record is so important, you can't make a mistake with it. We first kind of realized this when we are talking to the customer success team in Affinity, if they messed up a record, that means that potentially somebody's most important deal isn't going to get migrated into the system. So, they have extremely high standards around making sure that the data migrations are high quality, run successfully. And we want to make sure that we empower our customers to do the same thing and build really robust processes around their migrations.

G: How did you end up getting your first users for the product? Did you talk to people you'd worked with in the past, run ads on the internet, launch on Product Hunt? What was the first paid users? Where did they come from?

C: YC was helpful with this. I think that we reached out to companies within the YC community that we thought were likely to have workflows like this. As well as talking to people that we know. Andrew and I have been living in the bay area for our entire lives. And so some of our earliest customers were people we know who had moved on to work at different tech companies, ended up talking to them about their workflows. I have that problem got them using and then ultimately pay for the product.

G: It's interesting. My first startup, which wears a security startup where we did bot detection software, I think three of our four customers were people I'd met in a bar by my apartment. I just randomly met them and talked to them. This is kind of what it's living in the bay area. It's very different from being in even a satellite tech hub.

C: It is really great. Andrew, I think for our first 10 customers, we would write each of them up on the whiteboard and we would label them inbound, outbound or intro. And most of the first 10 were inbound customers. They were mostly people from our network who had heard about our product in one way or another, and just had the pain point that we were trying to solve. Definitely a few outbound as well though. So, I would consider even within the YC community outbound, if I looked them up, reached out to them. And then investor intros were helpful as well, especially just when the product was so early and people didn't really have that level of trust with the company, at least having an investor say, hey, this company's legit. They can solve your problem, went a long way.

G: Did you raise money after doing YC demo day or did you raise some money already before doing YC?

C: Yeah. Our investors found us before demo day. I think that they were pretty excited about what we were doing and reached out. We launched on Product Hunt in July. And I think that a lot of customers and investors found us because that was the first time we had publicly released what we were working on. So, yeah, our lead investor, general catalyst, they preempted our round later in July that we had closed out our seed round a little bit before demo day.

Being in the YC batch definitely got us a lot of interest from investors. Especially after that Product Hunt launch. I think that people are really excited about YC companies. YC does have a lot of really great companies.

G: Do you mind going into details about kind of the outcome on Product Hunt? How many impressions did you get from Product Hunt in one day to your website?

C: The thing is when we launched on Product Hunt, we hadn't instrumented tracking around any of this stuff. We thought that we might get, I don't know, 10 signups or something. It was overwhelming. We got hundreds of people signed up on the form on our website for the product. I mean, not all of them ultimately ended up converting into meetings. I think some of them were just people who thought that there was a self-serve free trial on our website. Because I think that the CTA on our website even said free trial. But Andrew and I were so early in our company journey, we were just like, yeah let's put it out there. Let's see if we can get some people.

And we were like, oh my God, we should have prepared for this way better. We should put analytics in our website. We should have been running ad retargeting on everybody that clicked through to this. But it was pretty overwhelming for that first week. I mean, I didn't even have processes in place to automatically email people after they signed up for our website. I had to go through every lead manually and put them in a sequence to send them a few steps to follow up and get them to schedule meetings. So, yeah, learned a lot about automations I needed to set up for our website.

G: You've had a pretty quick start and pretty quick traction with your company. Do you attribute that to doing a proper product discovery process before you started building?

C: Yeah, I think so. Andrew and I looked at a variety of ideas before we landed on OneSchema. Basically we were looking at problems that both of us had faced in our previous roles and talked to customer profiles for a variety of different things. We knew that we wanted to sell to software companies because we, just being based here in Silicon Valley, they're the type of company that we understand organizationally the best. So, we were looking at different functions within software companies. So, we looked [00:24:30] at the sales stack. We looked at the marketing stack as well. And I mean, once we started looking at this problem, it was kind of night and day than anything else we had looked at. Before we started looking at the CSV data migration space we would talk to two or three customers from the same customer profile and the pain points they were describing were just completely different.

But then as soon as we started looking at CSV data migrations consistently customer after customer, they would be highlighting the same pain points. And we're just a lot more excited about what we were building. So, it was pretty immediately obvious to us after a couple [00:25:00] months of doing discovery, that this was a better idea than the other ones that we had looked at. Though, hard to say what a different good idea would have comparatively looked like. Maybe we just got lucky because maybe in retrospect it was fortunate that all of our other ideas were really bad because the good one stood out a lot more.

G: How did you decide on a pricing model and have you considered doing something freemium where the user can try it out for up to a certain scale before they have to pay?

C: We have considered freemium. And the only reason that we haven't launched something like that yet is because we want to make sure that it's a good experience for customers who self-serve onto our product. Today we do an onboarding with each of our customers. We help them configure their templates and their validators. And we just want to make sure that everyone is aware of all of the features and the product that they would need to serve their use case.

Sometimes the templates can be a little bit specific and we don't have that much customer education around every single validator in the specifics of what it does, which today we are doing something that doesn't scale, which is just, we explain that to all of the customers. But in order to make self-serve work, I think we would need to put a lot more customer education into the product around the details of different data features.

As far as the pricing model goes, we are definitely still working through that. I remember I went to a talk NYC with some folks who have built some pretty successful companies and they were talking about the iteration of their pricing models on the path from zero to going public. And it was funny because they would say, oh yes on the ninth iteration of our pricing, we introduced X, Y, Z. And it is interesting how the pricing that they had at the end of their business wouldn't have been the pricing that would've been right at the beginning of their business. As the product evolves as the market evolves, different pricing models end up making sense. So, right now we typically do a platform fee with a usage based component around the number of files that you plan to push through the system on an annual basis. But who knows where our pricing will end up going over time?

G: So, you've had some success with things so far and you raised money from a prestigious VC fund. What are some things you wish you'd known about fundraising or product building that you know now?

C: On the product building piece, I think that the most important thing that Andrew and I got out of YC is the amount that they drill into you. Product market fit above all else. It is the only thing that you should be focusing on. Until you have it you can do everything else wrong and still succeed. If you have product market fit. And in order to achieve product market fit, the only activities you should do during your YC summer and for the rest of your time, you're building your company if you want to be successful, are talk to your customers, build your product and exercise. Whatever exercise means to you, keep yourself sane so you can talk to your customers and build your product. I think that advice in retrospect seems kind of obvious. Like obviously those are probably the most useful activities for building a good company. But I think that just being NYC and going to talk, after talk, after talk where they basically just riff on the same theme for three months, really drills it into your head.

That the thing to do is talk to your customers and build your product. So, I mean, Andrew and I really, especially during the batch, we just laser focused on that. Probably accumulated not so much tech debt, but I don't know organizational debt in other ways, because we were so laser focused on just doing those two activities. But it allowed us to iterate on the product really quickly. We've tried so many different features inside the product validation features, transformation features, different ways of communicating to users, what errors should look like, how to fix them. And just getting those reps in, I think has made the product so much better over time.

G: Yeah. Part of what makes a startup successful is the ability to ship updates quickly and learn from bailed experiments and also double down on the winning experiments.

C: I remember that the first YC office hours I went to with one of our partners, Reshma, I think the two questions I asked her were "Hey, Reshma, can we work out of the YC office in San Francisco?" and "Hey, Reshma, what do you think of the name OneSchema? Do you think we should pick a different name?" And I think she was like, why are you asking me these questions? These are the wrong questions to ask. These are not things you should be thinking about right now. You should be thinking about your customers and your product.

And I reflect on it. I look back at the end of YC, I was like, oh my God, I cannot believe I used my first 30 minutes with, Reshma asking her about a rebrand at that stage of the company because she's totally right. It's completely irrelevant to the success of our business. The thing that will make our business successful is solving a real business problem that our customers have. So, yeah, I think to me, that really just encapsulates this mindset shift that we went through over the course of YC of really laser focusing on the right things.

G: Cool. Well, thanks for joining us on the show and sharing what you're working on.

C: Thanks so much, Greg. Great chatting.