- Sar's Scatter Brain
- Posts
- Reducing the experimentation cost by supercharging integrations
Reducing the experimentation cost by supercharging integrations
My chat with Shensi Ding, Cofounder of Merge
Today’s Scatter Brain is brought to you by AngelList!
AngelList Stack is for startups that want faster fundraising, cleaner cap tables, and high interest banking, all in one place. Scaling companies such as Abound, Harness Wealth and Syndicate migrated from other vendors in less than a week with zero legal fees to gain an unfair advantage in managing their back-office. Learn more by signing up here.
I used to work in the online food ordering world, and most companies in that world inevitably end up building integrations to the POS systems that the merchants use to become a system of record for a business. I was heavily involved with that godforsaken project. It is such a big engineering and operational nightmare. The maintenance cost of these integrations sneaks up on you. It’s mission-critical but annoyingly hard to scope, build and maintain. And that has created a category of middleware companies that do just this and offer what I like to call aggregator APIs. Typically, these APIs go after specific verticals like insurance or e-commerce. When I discovered Merge had taken a different approach, I got intrigued and decided to reach out to Shensi, the cofounder of Merge.
In this conversation, Shensi and I talk about :
Rationale behind the multi-sector approach to building integrations
Implications of focusing on customer personas versus categories
Trade-offs in building direct integrations versus using Merge
Misconceptions & wrong analogies
Complimenting the ecosystem development mandate of partnership teams
Benefits of starting the company during the pandemic
Hiring as a way to curate culture
Evolving role as a cofounder
In the end, there’s a new section where I asked Shensi’s team to come up with questions for her. My most compelling takeaway was how a multi-category approach could enable companies to try out product ideas they would never have if they had to build integrations from scratch for adjacent problems to their core product.
Sar: I love how your company’s Twitter account posts great nerdy developer-oriented memes.
Shensi: Well, thank you for reaching out! I have followed you on Twitter for a long time, so when I got your message, I was like, wow, this is so cool.
Sar: When I first found you, I went to your website and hovered on the product section on your homepage. And my instant reaction was, “holy shit, that’s lots of integrations across categories!”. You cover accounting, payroll, project management, and applicant tracking system. Why go after so many buckets? My impression has been that each of these software categories is deep enough for you to spend a lot of time just churning on integrations. You guys clearly disagree! What was the thinking behind the approach that you guys took?
Shensi: My cofounder Gil and I came from startups in different industries that also had to integrate with different categories. I was in cybersecurity, and we had to integrate with ticketing systems. Gil was in recruiting tech, and he had to integrate with Applicant Tracking Systems. However, the problem that we were running into was fundamentally very similar.
Because of that, we realized that this problem applies broadly across all B2B companies. We also noticed that most B2B companies had to integrate with multiple categories. It was pretty rare for a company only to have to integrate with one category. And if that was the case, why not just use one vendor for all of them?
When we did some TAM analysis on what it would look like to focus on one category, we thought the scope was pretty small. There are just not enough companies that you can potentially sell to if you only focus on one category. We’re starting to see that prove out in the market.
In addition, when you only focus on one category, you get distracted and build many other features that aren't focused on your core customer and problem. You start building random things like insights and dashboards for a different use case and problem; the next thing you know, you’re selling to a different persona.
The team members who are impacted by integrations don’t give a shit about any of those features. We wanted to stay focused on exactly who our customer was and who was mostly impacted by integrations: the developer and customer success. We were in stealth for around a year, just focused on creating a great product.
Sar: I find it quite interesting that you brought up being focused. I realize now that Merge’s dimension of focus is the customer persona and not the category. When I look at the vertical-specific plays in your market, the focus is on the vertical, and the use cases constrain you in that vertical, so you have to branch out to different buyer personas to find growth. Your specific insight is that there is a lot of upside in staying focused on the customer persona and the boring technical plumbing.
Shensi: Yeah. Building integration is a massive pain, and maintaining it is worse. How can we help with the maintenance of those integrations? And then how can we help with the complete visibility of what is going on with those integrations and ensure that engineers don't have to get involved and a customer success team member is fully empowered to manage them after the integrations go live?
Sar: Why do you focus specifically on empowering the customer success teams? How do they engage with what you do? Also, isn’t that at odds with what you mentioned earlier about not wanting to get into dashboards and insights? Isn’t that a different, non-technical persona?
Shensi: A lot of people think that the burden of integrations is only on engineering teams, but the day-to-day maintenance of these integrations is also heavily owned by customer success. If you build integrations in-house, engineers and customer success teams have to work together to maintain and monitor those integrations’ health continuously.
We mostly interact with customer success teams once the integration with Merge is live. Our tools enable them to independently look into why a field is returning a certain way or why a Linked Account is no longer syncing without having an engineer look into it. This isn’t at odds with our focus on developers because customer success teams have always been involved in the success of integrations at B2B companies, regardless of whether you’re using Merge or building in-house. The difference is that with Merge, the developer can trust that Merge can provide a lot of insight into what is going on - something they would be responsible for if they had built these integrations in-house. Empowering customer success teams means we’re solving the integration problem for B2B companies, which is very different from building tools for accountants or risk analysts.
Sar: Are there any ideas or hypotheses you had in the early days about product development or strategy that have proven untrue or inconclusive so far?
Shensi: We built our documentation in-house. We believed that as an API company, our product is our documentation, and because of that, we wanted to have full control over the experience. I love our documentation. It’s a beautiful user experience that makes things easier for our engineering team when we have API updates. However, it’s inconclusive how much customer value our in-house documentation has generated, although I believe it is a clear indicator that we take all parts of our product seriously. Why would you outsource that if you’re an API company and your documentation is the first way your customers interact with you?
Sar: I have seen and worked at companies with dedicated teams of engineers to build these integrations in-house. Returning to having a horizontal approach to this integration problem, what's been the most surprising learning about how customers use your APIs from different software categories?
Shensi: We couldn't see until we expanded to multiple categories that companies that used us for one category came up with new ideas because they knew they could use us for the other category. Because we made many categories available, they are considering how to use multiple categories to launch new products.
We've seen some pretty interesting use cases that we didn't expect previously because our approach opened a lot of creative juices. They may have wanted to launch a new recruiting product or ticketing feature, but they didn’t have the resources to build all these integrations. Swag companies have started integrating with Merge because of our HRIS, ATS, and CRM integrations. That has unlocked new use cases and ideas for them that previously would have been too costly and time-consuming to pursue.
Sar: Ah, that’s interesting. As you bring down the integration cost, you also bring down the experimentation cost. Building new integrations from scratch to test new ideas is how many ideas die internally. It’s just not worth the headache because you must go through another dance of figuring out how to build internally or run a process to find a new vendor that supports the new software category you want to get into.
Shensi: Yes, exactly. I love your framing. I’m going to use that!
Sar: Merge is a connective tissue between API providers and your customers. How do the API providers feel about you?
Shensi: We complement their partnerships team because we make it easier for other companies to integrate with them and create an ecosystem around their product. Their product is the source of truth, and it becomes impossible for their customers to move off of them when every other vendor they use is integrated with them. While partnerships teams previously would have to wait for their potential partners to allocate engineering resources for 3+ months and keep asking them to integrate with their API, the integration process is expedited through Merge.
Sar: Let’s talk about the product experience of your customers. I imagine it is a Plaid-style experience where you have companies instead of individuals logging in using an embedded UI. Instead of getting access to information from external systems on a specific individual for private consumption, the companies pull in company information. Is that the correct way of looking at it? Where do you fall on the spectrum of fully owned, branded UI embedded in customer products to being an invisible player?
Shensi: That is the correct way to think about it. We only sell to B2B companies that have to offer integrations to their customers who want to connect data for an entire company. We do not sell to consumer companies that need to pull an individual’s data. We are fairly hidden, and our customers can select a white-label version of our Linking Flow.
Sar: Do you think of having a branded experience as a strategic asset to work towards in the future?
Shensi: I don’t feel strongly about it, and we haven’t seen material benefits from having a branded experience yet. Time will tell!
Sar: Talk about the read and write access you enable for your customers using a few examples.
Shensi: We support read and write access across all categories. A few read examples include expense management companies like Ramp integrating with Merge’s HRIS API to smartly auto-provision credit cards for new and terminated employees and FP&A companies like Causal integrating with Merge’s Accounting API to read transaction data. A use case for writing common data through Merge is sourcing platforms like Ripplematch integrating with Merge’s ATS API to create applications for sourced candidates.
Sar: You mentioned economics of scale earlier, and we talked about how the customers might have overlapping use cases across multiple categories. Talk about how you have chosen the categories you have so far. What are some considerations?
Shensi: We started with HRIS and ATS software because we wanted to signal to the market that we would be cross-category. HRIS was broad and relevant for many companies, but it wasn’t always urgent for companies to have these integrations. Gil previously had experience with ATS integrations, and we wanted to prove that we could learn and launch a new category that we didn’t have experience with. We chose ATS integrations because it requires deep industry knowledge and is a feature required for all recruiting companies. ATS has significantly more data than HRIS, and we wanted to be able to build for scale early on.
The two categories complemented each other well, and we were able to start selling both categories to quite a few customers before continuing to expand to additional categories. Based on customer feedback and market pull, we expanded to Accounting, CRM, and Ticketing. These categories had a lot of overlap with our existing categories and allowed us to help our current customers with more use cases.
Sar: Yeah, so there’s a clear expansion opportunity. With every new API integration, you're exposing an API partner to your entire customer base. You are biased, but what are some scenarios where integrating directly with one of your partners makes more sense for your customer than going through you? Does it depend on the level of customization or depth of the integration your customer might want? How does that calculus work?
Shensi: Haha, I am biased, but there really is no reason to because we still have so many tools related to maintaining integrations that you would have to build in-house!
Even if you build the integration with an API provider directly, you have to allocate engineers to recreate all the tooling that Merge offers to help your customer success team maintain these integrations. And now, your customer success team has to know how Merge works and how the internal tools work for the direct integration you just built. If you don’t build these tools, your engineers must continuously focus on maintaining the integrations.
Sar: I do want to push back here. Try making the strongest case you can to argue against yourself! Also, what are those tools? I’m curious about what sort of things you have to build if you have category-specific things.
Shensi: We offer logging, issues detection, and linked account sync monitoring tools. We generally try to target features that benefit all categories or will try to modify them to be that way. My best argument is that if you're a founder who doesn't care about your product, your customers, saving money, or generating revenue, you should build in-house :)
Sar: Ha, okay! What's the most commonly held misconception about what Merge does?
Shensi: Many think we are HR tech because they see we have HRS and ATS integrations. Many also think we are like Zapier or Tray.io and assume we do workflow automation because they’re more familiar with that category of integrations. The integration space is very nuanced.
Sar: Do you like the idea of a collection of Plaid for verticals rolled up into one? I imagine you don’t because it removes all the nuance.
Shensi: Haha, I agree; there are a lot of details that are missing there. We’re very different in that we only focus on B2B companies. Whenever we integrate with an API provider, the assumption is that we are pulling data for the entire org.
Sar: What conventional wisdom about growing a unified APIs business do you disagree on?
Shensi: I don’t think there’s much conventional wisdom in the industry yet. Many people questioned us when we first started because we wanted to be cross-category, and I have always strongly disagreed that a winner in the space could just focus on one category. As mentioned earlier, that’s started to prove out this year.
Sar: Talk about the last difficult decision you made that you are still nervous about.
Shensi: We’re actively hiring for several very senior roles, and we’ve had several shiny resumes pop up. It’s always scary to reject these people when their resume is amazing, but when you know it’s not going to be a fit, you have to trust your gut.
Sar: You started the company during the pandemic. Looking back, are you glad about the timing?
Shensi: We started during COVID when there was nothing to do except work. We were able to move quickly because of in-person collaboration and communication. We became very close and knew we could trust and rely on each other. If you start a company now, so many things are going on. There are these meetups, dinners, and tech weeks. Back then, we focused on building the best product possible, and doing that with minimal distractions was incredibly valuable for our company's start.
Sar: Are there any counterintuitive lessons you have learned about hiring people and creating culture?
Shensi: Many people talk about “culture” and focus more on creating a good culture with existing team members. Through starting Merge, I’ve gained more conviction that hiring is the only way to curate your company’s culture. You can’t change people.
Since we’re 100% in-person, I get a lot of questions about why we chose to go with this route. People will always ask me, “do you lose high-quality candidates because they aren’t willing to move?”. The answer is yes. But the benefits of finding a high-quality candidate who is also excited by the opportunity to be a part of an in-person community far outweigh the losses of not being able to hire those other candidates. We hire for retention, and we have a lot of natural filters in our interview process. Around 2.5 years in, we still haven’t had any regrettable terminations.
Sar: What do you mean by “hiring is the only way to curate the culture”? I have never heard that framing before.
Shensi: I think many people talk about culture in how people interact with each other and how they feel about their work. But the best way to guarantee that people will treat each other with respect and support is to hire inherently respectful and supportive people. The best way to ensure that your team is motivated to make the company win is to hire ambitious people who want to care about a mission. You will never be able to make someone care, but you can hire someone who cares, and it’s up to you as a company to ensure that you surround them with similarly motivated people so that they continue to care.
Sar: Yeah, that makes sense. And I agree. How have your roles as cofounders changed over the past six months? Have you struggled with anything as the company has grown?
Shensi: We’ve gone from coding, selling, and adding new integrations to mostly focusing on managing and mentoring our team members, doing much more external work with marketing, and hiring senior talent. I sometimes struggle with this transition since I love being with our team and being in the weeds, but I’m very fortunate that our team can own things independently. Coding gives you immediate gratification, while my work now takes longer to play out.
Sar: When you closed your seed round, I’m sure you had a vision for where you would be in a couple of years. Additional financing round, over 50 teammates, and dozens of integrations later, what are you most proud of today? What about the company and the industry you wish had changed or evolved more quickly?
Shensi: I am extremely proud of the team we’ve hired and that we have maintained an in-person culture. Gil and I were intentional with our culture and curating a team that would be kind to each other, high-performing, and deeply invested in the company. The industry could always change faster and better understand how unified APIs vary from other integration providers. Still, I’m grateful and excited about how much change has already happened.
Editor’s note: I asked Shensi to ask her team what questions they would want her to answer here. We will end our conversation with those questions.
Merge team: What qualities do you look for in a new member of the Merge team? How do you screen for it?
Shensi: How someone answers questions about their work history says a lot about them. I will ask candidates about their previous companies and why they’re leaving. Are they leaving because they’re just looking for anything new? Are they looking specifically for an earlier-stage company? Are they looking specifically for a company in our space? Are they only interviewing with Merge? How do they feel about their work usually? The words someone chooses tell you a lot about their intent. Negativity is the best way to know that someone will bring everyone else down and will change from caring very quickly.
Merge team: When did you first see that Merge would work as a business? When did you know you found product market fit?
Shensi: I knew Merge would work as a business when we would talk to prospects about the idea and do a demo, and they were SO EXCITED about it. We did user research with over 100 companies and continued to get validation from prospects as we were building the product in stealth. We were confident that customers would love our product when we had a production-ready product.
Recent conversations :
AngelList Stack is for startups that want faster fundraising, cleaner cap tables, and high interest banking, all in one place. Scaling companies such as Abound, Harness Wealth and Syndicate migrated from other vendors in less than a week with zero legal fees to gain an unfair advantage in managing their back-office. Learn more by signing up here.