Demo-led validation, charging from day 1, selling to AI-native companies, and finding resilient co-founders w/ Gil Feig @ Merge

We're doing a special in-episode feature with our friends and sponsor Unblocked. A lot of tribal knowledge is actually scattered across all of these systems. And so when you connect through MCP, what you get is access, and which is not the same as context. That's like understood, reconciled, and delivered at the exact right moment. Stay tuned for later in the episode, Dennis Pilarinos, founder and CEO at Unblocked, explains why MCP's rules and skills give access to information but not understanding. And how a context engine pre-computes what agents need to get their jobs done more efficiently. What doesn't matter from day one is the actual dollar amount of what they're paying you. But it's more signaling, the fact that they are willing to pay you for your services. It shows a few things. One, like I mentioned with lean methodology, people try to appease you. It's very easy for them to say, "Yeah, we'd love to test this product." And when you go to them and say, "Do you want to test it now for free?" They're like, "Sure, send us log in details." They're unlikely to engage. They might engage. You know, I just, it's not real signal for you as a founder. It's not the signal you need. What you need is someone to tell you, "No, we're not going to pay you for this." And you'd be like, "Well, why?" And to get to the point that they will pay you for it. Welcome to Engineering Founders, the show for Engineering Leaders Making the Daring Leap to start their own company. Gillfie, co-founder and CTO at Merge is joining us. We discuss an expansive list of topics. For example, we get into finding resilient co-founders who can handle the trough of sorrow. We talk about reimagining the lean startup methodology through demo led validation. Why charging for products from day one is the ultimate validation signal. Gill also shares frameworks for selling to AI native companies, mental models for road map trade-offs, and how to stay relevant as model capabilities shift. We also talk about why you should just skip or avoid completely hiring brilliant jerks and focus instead on hiring company builders. Let me introduce you to Gill and Merge. Gillfie is the co-founder and CTO of Merge, and Merge helps companies like Mr.L, Ramp, and Perplexity integrate thousands of external apps into their products and AI agents. Previously, Gill was the head of engineering at UNTAPed and worked as a software engineer at Wellfront and LinkedIn. Enjoy our conversation with Gillfie. Gill, all to say welcome. Thanks for joining us on the show. It's Thursday. How are you doing? It looks like a beautiful day in San Francisco. Yes, I am doing incredibly well. I think my internal state of being matches the weather in San Francisco tonight, so I'm excited to be on here. That, to me, screens just alignment. When you can get the weather to just be entirely aligned with how you're feeling and what's going on, that's the best. Those are good days. I love that. Well, to settle a bit of context, our conversation is going to be pretty widespread. Things around generating and testing ideas, category education and overcoming objections, selling into AI companies and founder-led sales and how it was intersect. But I want us to start off at the beginning with your story at Merge. I was wondering if you could bring us back to the moment where you started to recognize this problem and started to really crystallize this idea that Merge was an interesting opportunity to pursue. Absolutely. Yeah. It was definitely, I would say almost a sudden moment. I definitely did not think when I was graduating college that I was going to be starting a enterprise API integrations company. But we ran into the problem and it was so acute that we were like, wait, we have to solve this. So basically, take things back. I met my co-founder, freshman year of college. We were best friends from freshman year onwards. We were a class president and vice president together. So we show the week of work while together. But after school, we kind of slow ways professionally. So Shen and Cima co-founder went into finance, did investment banking and private equity. I went straight to tech. I worked at LinkedIn, Wallfront, and then a startup called Untapped, which was a recruiting platform. I led the engineering team there. And one of the big things that we had to do was natively integrate with all the different applicant tracking systems. So think greenhouse lever work day. And then we started selling to oil companies in the Midwest. And they wanted isims to lay out smart recruiters. All these platforms that I had never even heard of. I had 15 engineers on my team. And they were all at some moments just fixing integrations or adding new features to them. And I was like, we can't triple the number of integrations we have brutally painful. And me and my CEO had a lot of arguments over it. And then my co-founder now co-founder, Shedsey was in cybersecurity at that point. And they had to integrate with ticketing systems like Gira, Sona, but also Curator, Splunk. And what we realized was the pain was was common, even though we were in very different verticals. We were building in different categories of software and integrating with different categories of software. We found that B2B companies in general have to integrate with all the competitive products in a vertical because your customers can be using any one of those. So while we were building it, I was experiencing the pain from the engineering side of actually building that system internally. Shedsey was seeing it. She was chief of staff to the CEO from the financial side. And I was really crushing their business. So we decided to tackle it and stir merge. We started with just a couple categories. And at this point, we spent seven different verticals of software. We have new AI products. But we're all about now just getting integration data to companies as quickly as possible. So there's a few different things to deconstruct here. I want to jump into the co-founder story first because this is a particular interesting launch. You knew each other previously within college and then sort of came back together. So what did that look like to come back together and decide to do this together? Were you sort of catching up and realizing that you were facing similar problems with different patterns of industry? And we're like, we should do something about this or bring us into that moment. Yeah, so I think for a long time, we would be down to start a company if the right idea came around. We were not set on doing it with the wrong idea. We didn't want a small-tam market. Yeah, we there were a lot of busy sort of things there. And Shensi also lived in New York while I was living in San Francisco. But she moved out to San Francisco to join the Cybersecurity Company. And we would just meet up every few weeks for lunch or for dinner. And we were, I can remember it vividly. We were sitting at a sweet green. We were like pushing the wee hours. They were like clearly wanted us out of the place. And she looked at me, my co-founder, and she was like, pardon my friends, but like you look like shit. And I was like, I feel like it. We cannot build these integrations. It's causing fights. We're losing business. And that was like that moment where she was like, wait, this is so similar to what's going on here. And then from there, we just started brainstorming. How did you know that you would be good fit as co-founders together? So I think we were really fortunate to have worked together through a lot of constraints. Like I mentioned, we were a class president and VP, which I still view as our number one claim to fame. But while we were there, we had to do a lot under really sort of, I would say restricted resources, both in terms of people and financials. Like one of the big ones we did was we needed to pro a sort of senior event. And our budget was under $2,000 for 600 people. And we ended up throwing a wine tasting. And it was all about being resourceful. Like you can't even afford the wine with six, $3 a person. So we partnered with all the local wine shops. We had them come in, they sent their people for free to act as sums. And then they just like brought all the way. But anyway, the point was we saw that we had worked through that together. We saw we had worked through so many other things together. You know, I think we both were the type of people who were action oriented. I had started other side projects that could have become businesses with people. And I felt like I was always carrying the weight. And I think when working with Shenzu, it was the first time where I was like, I almost feel like I need to be doing more weight when you have that feeling. That's the best because we drive each other to do more to contribute. And like when you're building a startup, especially at the beginning, there is literally nothing more valuable than hard work. What I love about this is so what I'm trying to understand, like trying to do is like figure out, Okay, if I wanted to recreate this, like how would I, how would I do this? And like there's a couple categories that come to mind as you're sharing this. Like the constraints are like working together under constraints can be a really big pressure test. So the time constraints, the resource constraints in terms of people and money. And all those creates for different pressures. And I love that because it does like force, you know, the types of conversations that maybe mimic some of the co-founder conversations that happen later on when you're facing a deadline. You've got to meet a thing for investors or you've got a customer that says, give me this thing tomorrow. And it's like 9 p.m. and you got to figure that out. So like if you were to recommend for somebody how to recreate this, maybe for a different context who didn't meet their person in college. Like how would you like try to hack that or like how would you try to put that together and kind of create some of those patterns that can help you assess fit. Yeah. So what I would do is think to people you've worked within your career, I personally don't recommend anyone for a shot of college to start a company. I just don't what I would do is not necessarily opt for the best engineer you've ever worked with or the best just skill level. You want to find the person who showed a lot of passion behind everything they did because it doesn't matter how good someone is if they lose steam or lose passion. They're just not going to pull their weight at a start up and it's all about needing drive needing to care about every single thing every single customer says to you and action that or or you know take it to heart and figure out how that plays into your plan. So to me, it's think about the people you've worked with and think about the personality types. They should be good at their job too, but find someone that you're like, you know, in five, 10 years from now. Do I still want to be with this person working building every day? Do I have faith that I'm not going to resent them for not pulling their weight, which I think is one of the leading causes of co-founder breakups? If you don't have one of those people who's actually, you know, willing to go start a company at the exact time you are, I think you need to search for that and do a trial period. I have friends who have done this and it worked out well because they found pretty quickly like, hey, these people are not necessarily for me. So start on whether whether it's the business you plan on starting full time or just you know iterating on some ideas with that person. See how how attached they become to it. See if that's the right energy that you want to be working with because once you're in its marriage and there's not really any getting out without serious pain. I like the idea of the trial. There was one sort of like modality. We had a different founder come and share with us and it was this idea of like they did like a weekend hackathon where they're like, okay, we're just committing to this weekend long test and you know, we're going to have to work really late hours and then those conversations make really hard design decisions was sort of trying to mock up some of the time pressure. And they said, well, you know, they ended up co-funding the company as that person. And so I do I really like that trial period and whatever structure that that looks like I think that's really great. Yeah, exactly. I think I think you can do it in any way you want, but just like spend some time working through and spend some time seeing how that person reacts to pressure right like if your goal for that weekend hackathon is like we want to launch something by the end of the weekend. We are going to commit to that. We are going to do it and see how they react to that. And I think what you call that about resentment and not pulling weight. and that being like the number one cause for why co-founders don't work out. I think it's probably such an important thing to have in the front end of like, - Yeah. - How would you deal with resentment? And like, could you get ahead of that? And so I think the flag there, I think it's really, it's really powerful. - And personally, I know multiple co-founders who have started to build up that resentment and at that point, I don't know anyone who's recovered from it. - Yeah. - The stakes. (upbeat music) - We're taking a quick break for a special feature. Breaking down the role of context in the shift toward AI-driven development with our friends and sponsor unblocked. Dennis Polarinos, founder and CEO at Unblocked explains why MCPs, rules and skills give access to information but not understanding. And how pre-computing context helps agents get their jobs done more efficiently. - When an agent queries an MCP server, it can actually get three results. It stops at the first possible answer. It doesn't know which source is necessary authoritative or what might contradict each other. What it'll end up doing is something called satisfaction of search. I get a part of the answer or something that looks like it's the answer. And I go away taking that snippet or that fragment and try to come up with a solution. But it isn't the actual end-to-end solution. And so that is one of the biggest things that we see is that a lot of tribal knowledge is actually scattered across all of these systems. That's like understood, reconciled and delivered at the exact right moment. And so as you add more and more connectors, you're actually contributing to that problem. It will basically find something that looks like the right answer. And they like, okay, let's go explore that path. Doesn't come to the right conclusion, goes all the way back up, tries the next one. There's no reconciliation or conflict resolution. Skills and rules file have that same kind of ceiling, right? They encode what you already know. They can't capture a PR change that changed the convention or decisions that weren't documented or the constraint that exists like in a thread that's like six months old. Unblocked isn't another source to query. It basically pre-computes all the context that you might actually need. It's able to look and to end across all these different data sources such that you get the right answer that has been deconflicted and that the agent can move on with its next step without having to like go down these rabbit holes. As a developer, what you get is the benefit of not having to spoon feed these agents all this information. It is able to pull together information from Slack and Confluence, and JIRA and DataDog in century in an efficient way so that the agent doesn't spend time burning a bunch of tokens, burning a bunch of wall clock time in order to get to the solution faster. We run this experiment, we see our customers do this all the time. They'd ask the agent to do using Unblocked and they'd ask the agent to do it without using Unblocked. Almost every single time, depending on the complexity of the task, the Unblocked result is far more efficient in terms of literally wall clock time. Give your coding agents the context your best engineers have. Your agents can read code, but they don't know how your team works. Rules and MCPs give access to information, but not understanding. That's why you still have to tell them where to look and what to look for. Unblocked gives your agents the history, conventions, and decisions behind your code so they can generate mergeable output without the back and forth. It automatically services the right context for every task, so agents stay on track without the setup tax or the correction loops. Ship faster with AI outputs that actually reflect how your system works. To get started, go to getunblocked.com/elc. That's getunblocked.com/elc. What I wanted to have into next is your personal shift from this identity as head of engineering to then co-found a company. What was that shift like for you? What were some of maybe the mindset changes or I guess the biggest shifts that you had to make to become sort of in charge of everything and responsible and own everything? Yeah, so what's interesting is I think a lot of the sort of role, building the product and developing which is all that your company is when you're small, that was the same. At the beginning, we weren't performance managing people, maybe a little bit, but that wasn't a big part of the role. I think what I found was actually there was a lot of overlap with an high level IC position at the beginning, but what also was very true in surprising to me was that patterns repeated. Everything that happened at my previous company happened at this company and my co-founder said happened at her company too. I think we were able to really apply what we had seen and what we had done, which is why I say, don't start a company right out of college. It's not that you need 10 years, but get a couple of years because you just see so much in that short amount of time. So I think that was really, really interesting. It was just like how many patterns we saw as the company scaled that definitely changed a lot. And I think I almost started to build a lot more empathy with my old founder. And Chancy can say the same thing, right? When you look at a founder, you look at them and you're like, okay, they have to make a lot of top decisions, but maybe they're kind of an asshole or they're kind of whatever you feel about them. But I think once you go and do it, you start to understand what drives a lot of that. And you start to just see the insane amount of pressure and the insane amount of. And experiencing that firsthand, I think gave me the chance to reflect on what I had seen previously. My previous founder was under an insane amount of stress and then combined that with like how did it come off when he reacted to certain things and learn from that. And I can't say that I'm perfect. Like I definitely have had pad moments of acting in a way I'm not proud of, but I think there's also a lot that I took in and now I can say like I handled the situation very well. I got the same outcome I would have wanted. And I also kept the team really happy and engaged through it. One of the questions that we kind of asked in the wrap-up question is like how do you deal with stress, but I think this is sort of a different slice on that question, which is like in understanding that like dealing with that insane amount of pressure and then interacting with your team and trying to figure out next steps, goals, like decisions. What are some of the practices or things that you're trying to do to help you process that pressure? Or I guess like maybe do different than what you've observed in the past. Yeah, I think for a while, like one of the big things I tried was just served attaching for a little bit. Like hey, can I have this weekend of not thinking about the problems that are going on? Or like can I have an actually found that that didn't, that didn't really help because they was just brushing things to the back of my head and it just bubbled up as like anxiety that I just didn't even know why it was happening. So I think instead like I'm much quicker to action things now. I don't let things sit on my plate. I don't let them also like just candidly walking. I know that's crazy, but you see it all over tech Twitter. Walking is like one of the most beneficial activities you can do. It's equivalent to intense cardio if you do like an hour a day. So that's been really helpful as well. The secret of walking, there should be like a whole founder series around like the secret life of walking and ideas. I don't know, I think it'd be it'd be fun. I want to get into the ideation part of this because I think there's kind of a parallel journey here that's fun to explore. Like you and Sean see like coming up with this idea together and then sort of the way that you approached it. And then now like there's a lot of things changing like you've made a lot of really interesting meaningful pivots with Merge over the last few, I guess, year or a few months. So be kind of cool to de-construct both, but maybe we'll start at the beginning. So like what did it look like to land on and align around the original idea for Merge? We'll start there and then we'll expand. So one of the first things that we did was we had to do a lot of research. We had built these products in our previous companies, but we wanted to validate that this was what the general market wanted and not what our two companies wanted. So we followed Lean methodology, which is sort of old, I would say 15, 20 year old methodology around starting tech businesses mostly. And what it says is you should talk to 100 potential customers before you start building because you'll get really good indicators of what people are looking for. And it talks a lot about like, you know, people will try to appease you. They are flattered to be on a call with someone who's starting a company and they want to just make you feel great and gas you up. And I think we definitely saw a lot of that. But we also saw a lot of genuine interest and we saw a lot of people like, I will pay you a ton for this, but I don't believe that you're capable of building something like this. So I think that that was really cool because we were like, these people are being honest with us and they're nagging us at the same time. So that was great. And when we actually then went to launch the product, what was great about all of this was out of the hundred 12. We're ready to start immediately. And that may not sound like a lot, but of course, companies love to say, yes, we're interested in this. We're interested in this. We knew all along. We're not going to get even close to 50%. We're expecting a very low percent to actually convert. And we were a product also that required entry sources. We still had 12 immediately stop what they were doing and start using it. It became so clear how acute the problem was for everyone at that point too. I think we were really fortunate actually that what we were building was literally what we had built at our previous companies. Maybe first slightly different categories and a little bit more flexible and built to be embedded in other people's products versus building it for ourselves. But we had built this system. We had seen it work. And so we knew what to execute on right off the bat. And one of the things that we kind of decided was we are going to have to build integrations for years to come. And we have to build them in a lot of categories that we're not even thinking about now. So let's start with a really solid foundation that just basically lets us launch new integrations very quickly. So we built a whole system for doing that. We spent about a month before we ever launched. I had been building recruiting integrations and Chensei had been building ticketing integrations. And the first step was like, what is the tam of that market? Not big enough to really start a category. By defining company, the next step was like, OK, how do we expand the tam of what we're trying to solve here? And that was, we should power all integrations, not just recruiting and not just ticketing. How do we go about doing that? So that meant reaching out to companies of all types, we essentially found companies that just had integrations and got on calls with them. And our questions were more broad and they were more open-ended. And we definitely didn't ask anything leading. I think that's a pretty common one. If companies are using this for HR, why wouldn't you use this for accounting? That's a really bad question. That's just like, you're almost like making them feel bad about not giving you an answer that you're hoping to hear. And they sense that. And they'll answer you the way you want to hear it. So what we say to them is, obviously, HR is really easy accounting. It's going to be almost impossible to build this sort of thing. Why do you think that is? And we almost led them in the opposite direction or gave them very generic question because we wanted the dirty truth. And that's how we did it. So some of these patterns worked. And you never were talking about, if you were to go through this process again, it would look different now. which is based off of the situation that we're in. So I was wondering if you could maybe talk us through a little bit of like, if you were to redo this lean startup methodology, this process of talking to customers, doing research, like how might it look different now with some of the new ways that the new patterns that are emerging? - Yeah, it should be renamed from the lean methodology to like the skinny methodology at this point. You just have to do so much less. And note it away, it's because you're a friend investment in building out an MVP is low now. And in fact, like when this was first conceived, it was even higher than it was when we started merge, right? Because you didn't have open source libraries, you didn't have plug-in play APIs, you could use to solve big chunks of your business and shrink together like Legos. And now with AI, it's just even easier, right? Like you vibe code something in 10 minutes. So I would say much more opting towards have a working prototype pretty early on because any feedback you get, you just feed to your vibe coding tool and it's gonna just update it to match that, you know, where you're thinking that product's going. So I would lead with a lot more demos when I get on calls. I would still try to do some blind research because I actually think AI in a lot of ways guides you to build things you were planning on building and maybe makes the experience worse. So I think what I would say is maybe bring that number down to 10 to 20 and start using prototypes much earlier. - There's a few other elements that I don't want to get into. So the feedback in curting faster iteration, so then how would you design sort of like that feedback engine to sort of iterate on the MVP? Like would you be then like sending call notes into like your preferred vibe coding tool? Like would you be structuring that data in a different way than like that like building out like more structured tickets? Like what's this hypothetical model look like to like really rapidly hack on the MVP in the scenario? - Yeah, I think like I think that the human element of starting a company is so important still. And so I think that like internalizing the notes and everything that your customers are saying is really important. Personally, I wouldn't change my methodology there because if I'm just feeding all the feedback I have dumping it all into, you know, lovable or having something summarize it and then dumping that into our vibe coding tool, I just think like you as a founder never build a real attachment or understanding of the space and product. And so I view it more as a tool rather than a way to sort of outsource your thinking. So for me, I would personally try to glean the insights on my own. I might then ask for additional whatever whatever the AI, you know, says that it's picking up from notes. And then I would probably be a little bit more explicit again with that UI should be changed too. So again, whether that's consulting AI and saying based on this feedback, what changes should I make? And then also combining that with your own thoughts and what changes to make and then more so directly telling the vibe coding tool what to do. So you mentioned converting to a paying customers and talking about charging for merge from day one. How did you do that? And like what would create success for that? And like I guess why is charging from day one like a critical part of that strategy? And then like how do you make sure you can get to that point to like really get clear validated signal? So I think what doesn't matter from day one is the actual dollar amount of what they're paying you. I think that can increase and there's a lot of work you can do there. But it's more signaling the fact that they are willing to pay you for your services shows a few things. It's very easy for them to say, yeah, we'd love to test this product. And when you go to them and say, do you want to test it now for free? They're like, sure, send us log in details. They're unlikely to engage. They might engage. I just it's not real signal for you as a founder. What you need is someone to tell you, no, we're not going to pay you for this. You'd be like, well, why? And to get to the point that they will pay you for it. So money is a signal more so than a dollar amount than it's said to your bank account. All that being said, you don't want to start out super low and then try to raise your prices to a reasonable amount. So what I would say is like, if you do want to have early on sort of partnerships, you should still aim for a higher amount. But you can do work things in there, offer them unlimited for the first year, no caps. There are ways, ways you can give them that beta test or deal while also both signaling to yourself and to potential future investors that people are willing to pay real money for this product. And the element of this that I want to get into-- you're talking about the context that merge of entering into was that it was going to require engineering resources of the people using it. And so that creates like this interesting dynamic where you're sort of considering that on the front end. So can you maybe like describe that context and what's hard about designing a product that then is going to require engineering resources? And then how do you help like bridge and make that easier or like really clear for the value that they're going to get from that type of product? It's funny. We would have companies sometimes come in so hot. Like sales is screaming at us. And if we don't offer 100 integrations by next week, our product is going to go under. Reminds me a lot of both my previous company. But yeah, we sell to often product and engineering teams. They have to road map us. They have to find time. And it can be brutal to get slaughtered in there. It's super painful. They'll get on the phone with us and tell us, this is the biggest problem we've ever experienced. It was a screaming at us. And then when it comes time to actually go implement or actually go do it, oh, we don't have engineering bandwidth for the next 12 months. So that's why one, I think, getting payment is really important because again, like words or words. But that was a big part of it. I think the other thing is making it really stupid simple for them to onboard. And fortunately with AI, that's a lot easier now. It was tough for us because engine needed bandwidth. They actually had to set aside product road map. They potentially needed to cancel certain projects or ship things back. And that made it hard to get our timing to align with theirs. But once we, you know, launched our new AI agents that essentially have plug-and-play props that you can paste into your code base, we can ad merge to anyone's code base almost immediately with AI. So I would say like, if you're now selling to ad teams, where there's some level of implementation required, start thinking very early on about how AI can automate implementation. Because it is, for enterprise sales, it's one of the biggest problems you'll run into. One of the things you're not talking about was like one of the objections that would oftentimes come up is we can build this ourselves. And it was much more of like a build versus buy sort of conversation. I was wondering if you'd talk a little bit about like, how you solved for that. So how you overcame that objection, both in like those sales calls, and then also structurally within the product and some of the strategies that you were doing outside of those sales calls. - Yeah, so I think first and foremost, it's all about value. And so if someone says we can go build this themselves and then they go build it themselves, and it's fine, you're probably not building the right product just to be honest. Like, you know, if it's like just the biggest enterprises in the world build it, and everyone else is only surviving, great, like then you could be onto the right track. But I think what you really need to see from people on calls is we need this product. We've tried building this or we, this problem brings very true to us and we just can't solve it on our own. Or, you know, like we always say, you know, we have this sort of phrase here, they always come back and that's, you know, a lot of companies will say, we're gonna go build this in-house and we're like, okay, go for it. And they always come back. And that's just a sign again that you're building the right product. They go in, they try it and they realize everything. All that being said, of course, we try not to let them go. We have a very deep, at this point, a very developed built-out sales process that runs through all the pain points, all the features that are there. You gotta value sell them and just kind of let them know, like, hey, you're so convinced that you can go build this in-house, this is what it's gonna take from your end. Are you sure you wanna go do this? If that answer is like, what it's gonna take from your end is going in vibe coding exactly what we're selling, then that's not gonna land well. But if it's like, we know for a fact that what we've built is just way too complex, it understands deep context of organ, whatever it is, that's where you're kind of in the right place. I wanted to bring up the Mark Benioff Quotive. If I were founding the company now, what would we build in this whole idea of like the current market fit is fleeting? I think right now, more so than ever, in a lot of these different things. And so like, as you're talking about this sort of build versus by conversation that people have, saying, I'll go build this ourselves. And like, if they're saying that and they're going to do it and they're going to do that, you're probably not building the right thing. So part of my, I think, to connect those questions in like this Mark Benioff Quotive, is like, how do you really get down to the root problem so that it's in the category of people can't just build it on their own and vibe could have really fast. Like, how do you make sure that it's at a class of problems where you know you're solving in a more complicated space that they can't just build on their own. And then I think threading that to, if I were founding the company now, what would I build and how are you thinking about this Mark Benioff Quotive, like in the context of a lot of things going on right now. I'm trying to like help understand, you know, how to help people identify if you are in the right problem space so that that doesn't happen, that you are in fact building the right thing and overcoming that like build versus by objection. Yeah, so I think candidly your customers will tell you and I don't want to say that you have to build inherently the most complex product. We see as much as we all, you know, completely shit on these thin LLM wrappers, like a lot of them have taken off and brand carries them a lot of the way too. So I don't want to say that it's necessarily, you know, like if you're not in the most complex product space that can't be replaced by some vibe coding tool, really quickly it's not going to succeed, but I think your customers let you know really fast on the calls. You can feel it, you can feel the need and the want for your product versus we're really trying hard to push this product into their organization. I think it's really looking out for all of that. And yeah, we, it's something that we have to do every day here at Merge. I think we think of product mega fit as extremely fleeting just because we had it yesterday. Doesn't mean we have it today. And we constantly, you know, think about Merck Benioff's quote that basically says, if we were starting this company today, what would we build? And that's what you should be building at every moment in time. And so we think about that a lot. And we have Merge Unified APIs. They were not built to be the context layer for AI. But they've kind of become that a lot of AI companies popped up, they've been demanding it. And we took a step back and we said, if we were building Merge Unified right now, it would likely be more focused on being a context layer for AI. So how do we then expose this data in the most ideal way for AI companies? And what's interesting here is I actually think there's a different paradigm at play here, which is not just can we vibe go this, but how fast can we get to market? It's a space race right now. Whenever there's a major industry shift, like what's going on with AI, things that people maybe wouldn't have paid money for five years ago, all of a sudden become something that people really need to be their competitors and get to market fast. But then of course, on top of that, you have to continue adding value to remain relevant. What does it look like to revisit that question? Because I think the Merge Unified APIs story is such a powerful example of something that was already there. This question comes up and it totally changes the trajectory and moves in a really powerful way that's then rapidly growing and serving these types of companies that are building out a lot of really exciting things. This is kind of a lame way to sort of undersell. what's been going on. going on in terms of the AI space race. So what is it look like to surface that conversation with the team and then to make these like pivotal decisions that are going to send you down the way of like merge unified APIs optimizing that for AI. We just talked to a ton of AI companies that were using us and we were like, what are you doing with the data? Understood their flow and there was something in common. They all tended to pull data, pull the full data set. They would then vectorize and embed that in a vector DB and build retrieval to actually search across a lot of that data. It's extremely relevant for enterprise search for sort of smarter knowledge based agents. We see it quite a bit. And so for us, it was like how much of the work that they're doing can we eat? Like can we just absorb a lot of that flow? Can we surface that data? Can we inject that directly into a vector database for them? So what we haven't necessarily done every single piece of that yet, that's how we're sort of evaluating like how do we become the perfect piece and make it very clear that this product was built specifically for AI companies, even though it wasn't original. I'm trying to synthesize like because I think the pattern of this is so powerful. So talk to a bunch of people, find what connects them, build that, the question of how much of that work can we eat and then do it really fast. It's also sort of like the underpinning thing is like you have to match the speed of the people that are consuming these products. Yeah, that's exactly right. They want to move incredibly quickly and that's why having value of like this adapter is exactly what you need. Let's them just onboard get up and running really quickly and that time to market is everything right now for them. And then I think going back then to the other piece of speed is like automating as much as possible like the integration of that, like removing that as much as possible. So it's like the speed from identifying this product is a solution to them actually using it, like collapsing that to be as fast as possible is all part of it. Right. And I think this doesn't only apply to technical products, right? You don't have to be selling to an engineering team to use AI for implementation. You know, like say you're building an agent platform and you when they come in, you don't want to just have no agents available for them so that you want to boot to that experience. Build an agent that scans their website and understands everything they do and reads their careers page and then just suggests some agents for them at the beginning. I just think having that experience like ready to go using AI these days is really powerful and everyone should be doing it. I want to get into a little bit more with the details of like what it's like to sell into an AI company. And you know, part of me I'm going to ask that question, like, oh man, like I'm also asking like, oh, are all companies AI companies now or is this like a specific class of companies that like their AI native but they're powering sort of the AI infrastructure and like these are the specific ones that you're serving. So if I'm like oversimplifying this like, I'm sorry, but I think like the big question is like, how do you sell into AI companies? Or like, what are the distinctions in the differences that you've noticed from like maybe merge used by three years ago to then the companies that you found that are using this that are powering a lot of the AI infrastructure? Yeah. So a few things AI companies have a lot of money. So they spend a lot of money, but they expect real services in return. They are smart. They're on top of things. They hire the best engineers in the world. And so you need to you need to provide real value for them. But if you have it, they will move faster than probably any company you've dealt with previously. They just make quick decisions. They want to launch things. They want to get them out to market. Like I mentioned, it's a space race. And so if you view them as one of the competitors in a space race, it's all about values on to them. How can we let this company know that they're going to become a market leader by having what we have to offer? And that's, you know, to be honest, like we, we have AI companies, they use us for our connectors and you look up the reviews and you look at and they just win hands down, right? And so I think I think having that under our belt now helps for later cases as well. So my advice selling to them is sort of sell them on that value, get in early with a fast growing platform. And so you can rise with that logo. Something that was really valuable for us pre AI was we sold some logos when they were small that we could tell we're on a good trajectory. They grew really fast. And then we had them as a logo on our site. If you had gotten perplexity earlier, if you had gotten open AI, that's a tough one. But open AI early as a customer and had that logo, imagine the other logos that then come into follow because they see that you're powering a lot of AI companies. And so we talked about like selling the value to them. Like when you approach those conversations, like what would be like the core things that you really, you really center on that like are critical for then those decision makers go back and make it like a fast easy yes. Yeah. So so basically dig into their problem, whatever's associated. So for us, right, these companies need integrations. And we asked them like tell us about what your experience has been building them so far. Explain why you're on this call with us. Like we just really want to understand you get them to spill all of their pain points before you start really value selling because then you can hone in the value, right? Every product can offer value in a million different ways. And so for us, would we have a company tell us like we don't have enough engineers or our engineers hate working on this or we would we want to focus on other things or whatever it is. That's what we then hone in on. So we don't have enough engineers. Great. We we prepare a deck that's just a ton of information around the amount of time savings they have by not using merge around how you don't even need a technical resource. It's basically just like tying in very deeply with the problems that they're describing. The other thing you should do early on is be willing to to build whatever they need. AI companies are excited about that, right? They're not looking for some established market leader because there aren't a lot of established market leaders that do a lot of the things that they need. So what they want to know is like, hey, do you solve our problem now and will you continue to solve our problems into the future? And so as a founder getting on the call and being like, hey, look, founder to exact get whatever company, like I want to let you know that this deal means a lot to us and we will build the product that you all need. And that end point that you're talking about, like that piece of functionality, I'll have that done for you by Monday. That's the type of thing that is a really good indicator for a new startup. Can you talk a little bit about like how you as a founder approach and or filter those types of requests? It's about how you navigate that in terms of like being able to navigate like the tradeoffs like on your roadmap versus what they in like a sign engineering resources to it. Yeah, I mean, I think that's a that's sort of a later company question because like I think if you have really a built out roadmap before you're 10 people, like it's just like not necessary. We had a bit of a roadmap and we had some tasks but like we were we were working 14 hour days, which is like what you need to be doing at an early stage startup. So features were coming in and they were getting pushed out the next day, right? We were moving incredibly fast. We didn't have a lot of customers that we needed to worry about breaking anything for. We could just pull things down, put things up. There were no nose at that time unless it was a target we didn't want. We built anything anyone asked for. I love this idea that like filtering is a later stage company problem. And yeah, really especially with AI now, it's like there are no excuses like a customer mentioned something you you hang up that call. It's already built. Yeah. Well, it makes you think of like you know, some of the narrative is around the product expectations that like we're on expand with people now based on how faster companies are moving in terms of releasing new features. And I feel like as a founder, like when you're jumping in, you have to match that that speed and pace and like the ability to take feedback and apply it to what you're building is just so much faster now. So if you're not accelerating that type of way, then like that's probably a pattern that like things aren't going to work out. Yeah. And one thing I will add by the way, because I do want to I do want to be really clear building anything customers are asking for. It does not mean they're like go build this piece of shop and you're like, yeah, we'll go do that. It has to be relevant to the product. It has to be directionally where you're going and makes sense for what you're doing. But you know, if you're like, oh, that's just such a P12 for us. We were going to do that next year. No, do it now if that customer wants it. Yeah. So I want to talk about all this like also in this context is we're also in this operating context that I think a lot of people are they're looking to push the company further and further operating in a really lean way. And so hiring is becoming a different pattern in terms of what you hire for first, the types of hires that you bring on, what they then kind of work on, and what's the type of leverage that you're looking for with those those early hires. And so I think what I'm curious about is how you're thinking about some of these like early hires in terms of like what capacity you want them to build like where are you trying to get levered early on? And how are you thinking about some of some of the earliest hires in this context where you're working with these companies that have really fast urgent demands that you know you need to meet. And then on top of that, then it's just an exciting time. So like how do you think about like buildings early capacities? Yeah. So the first thing I think you need to do is lay out what your expectations for your employees are going to be those should be hard work. I can't state this enough if you're thinking about starting a company and you think you can work eight hour days where you think it's okay for your team to work eight hour days, you're just likely not going to be successful. I think candidly you can go in that way and if you start to see some success, you're going to get forced to work harder anyway. But that's why for us, always a front very clear with the team. You're joining a startup. We expect you to work hard and we want you to get rewarded because of it. But I think that's number one is being really upfront. I think the second piece is optimizing for passion. We know brilliant jerks. We've made mistakes. Like I think some of the biggest hiring mistakes we've ever made were we don't know, but this is the smartest person we've ever interviewed and they'll do really good work here. Those were our biggest mistakes because culturally they affected everyone else. They were brilliant jerks and we wanted them out. And they were the quickest people to get let go from the company. So I think, yeah, you want to optimize for passion as well. You want to optimize for people you want to be working around. You're going to be working together a lot. If you are in person, which I would highly recommend, you want to make sure that person is willing to come to the office every day. I think those are sort of the basic checks from there. You obviously go into skills analysis, but you need good people. You need company builders. You need people who know what a startup is like or can describe to you what they expect to start up to be like. You know, I kind of want to talk a little bit more about like where you're shifting focus to now in like the future of merch. Like when you're thinking about what comes next for you all like where are you looking towards? And I guess what are the changes that you're starting to focus on in optimize around? It's all AI. It's all we think about. We are powering tons of AI use cases. So I think the hard part is no one knows where anything is going. And you know, one day, yeah, we always see all these Twitter posts or ex posts that are like, if you're not using this brand new model, then you're 12 years behind. And then like next week, ever to go, that thing was crap. No one used that anyway. So I think there's just there's just like a lot of a lot of phomo, but it's real. It's because things are changing so fast. So I think adaptability is really key for us. We set out this year and we have goals, right? Like we set to the team. We want to launch certain AI products. We want to continue to build out certain categories of our unified API to serve AI companies. And we want to do a bunch of other things. But most importantly for the entire team here is this is the year of experimentation again. We we are constantly going to be re-evaluating product market fit, finding new ways to sell to the market. And so experimenting a lot, being willing to be scrappy, willing to shut things down, that's really what we've said to the team. And I think it's been really effective because already, you know, halfway, what happened? We're halfway in the January. - Yeah, exactly. Halfway into January, everything's changed since I was away from the holidays. So I just, yeah, we keep coming up with new things and we take advantage of AI to move as quickly as we can. - So when you're thinking about this theme of re-evaluating product market fit continuously, is there a certain, do you ritualize that? Or is there a process around that? Or is it just a concept part of the conversation like at a weekly cadence, like everybody's questioning the assumptions, like the operating assumptions going on? What does that look like? - Yeah, so candidly, we do have product market fair, right? We're selling faster than everyone with AI, it's been amazing, I think we don't believe that that just comes for free. I think it's been a lot of work from our teams and to make us really work well for AI use cases. So I think this concept re-evaluate and does have to be constant because when you think about it, like it's very easy for all of us, people, humans in general, are inherently lazy and inherently prefer comfort. And so we want to sit every day and come in and say, okay, my routine is like, come in, I check my emails, I tend my meetings, I do whatever. It could be really tough to what I like to say, like groundhog, like pick your head up out of the ground and look around at the state of the field that everyone else is in and say, like, I don't like how we're doing that thing. So we've done a few things here. One, we have a weekly meeting now called our hot takes meeting and you say anything, it's encouraged to say anything. And we also have a hot takes channel on Slack and you can go in there and literally be like, I want to shut down our core product and here's why. And it's judgment free, but it just gives people the chance to share with us on their mind because those are the most valuable thoughts. And we've had some really, I would say, incremental changes come out of that. What I was gonna ask was, you were talking about LinkedIn or Twitter and somebody saying, if you're not using this, like you're going to be left behind, like, I am right now in the place where I like when I go on LinkedIn, how do you filter the signal from noise right now knowing that re-evaluating and constantly thinking about how to shift and adjust in the shifting landscape is so critical. So how are you filtering some of the signal from the noise here? My biggest realization and maybe a hot take has been that no one causes incremental any form of changes in AI better than new AI models. We see this with someone built that open source cursor competitor, it's open source, but they built it. It's 250 lines of code, right? And it works incredibly well. But you go on Twitter and like cursor is all the way. I think ultimately it's waiting for model updates and testing things yourself. That's how we do it. We just basically test out each model as it comes out. And if we sense new capabilities, we reevaluate what we can then build given that. We also of course, there's what the market is looking for. So that's a tougher one. So it is very trendy. We've been seeing context graphs. But then everywhere it's all people are talking about. I wrote a context graph article. It was kind of the right of passage. And then there's the hot takes like, actually, I had someone posted this recently. I don't think that there will be a single trillion dollar context graph company in the next 20 years with hot takes about it. You kind of need to not necessarily follow the consensus view. But for your own opinions, be a sense where you're seeing models go based on what you think is possible or is going to be possible. And where you see people starting to trend towards. Because actually like Andy Racklet from Benchmark has a quote that I love about how the best ideas are non-consensus, right? If everyone on Twitter is saying that this new model or like, the context graph is the important space to be in. You're too late to be starting something with context graphs. So you want to find something that's non-consensus. I think that's some really great inputs to start to queue into. Yeah, we've got some rapid-fire questions. So first question, founder resources that are most helpful for you. So Twitter, I know that's lame, but it's actually so great. You just see so many other stories and so many other things. There's hacker news. There's a lot. I would say follow a lot of the tech publications. That's what you really stay up to date. And then seek a mentor. I think that's really, really important. Just find another founder or another person who you look up to that you can go to. The founder, journey, even with a co-founder is incredibly lonely. I think if you are a solo founder, there's just no way without having someone to go to. Next, grab a fire question. We're talking about trends a little bit. I think there's some interesting hot takes there. So I think I'm expecting a good hot take here as well. What's a trend that you're seeing or following that's interesting or hasn't hit the mainstream yet? Maybe so maybe it's the ongoing success and debate between MCP and RAC. It's somewhat hit the mainstream, but this idea of like, why for years did we pull this data into vector databases when we can now do live API lookups and let the agents do that? I think you're seeing pushback now from the security community. Being like, no, it's insecure to not use MCP. MCP has some safeguards built in. And then everyone pushes back. I think it's actually insecure. And I would say that one, I'm really interested to see where it shakes out. It's really relevant to merge as a business, of course, which is why it's top of mind for me. But it's one of those things where you just see like these extremely hot takes on Twitter that are like, if you are building RAC, your entire family's gonna pass away 'cause you made the wrong decision. And then it's like, if you're using MCP, and it's like, no, everyone's using both still. I love that. I love calling that out. This particular argument I think describes the type of industry whiplash that we're experiencing. It's like in like the course of a month, it's like you optimize your business around one thing and then the whole industry conversation was like, you did it wrong and now your business is gonna fail. And it's like, woof. And then it's like, and then it's like, oh no, a new model came out. And now everything that everyone has ever built is useless. Like, we're start over. (laughs) I think that's great. Final question, Gil. Is there a quote or mantra that you live by or a quote that's been resonating with you right now? I don't know if I can recite the specific quote, but it comes from just a lot of inspiration from founders and viewers book with. And I said it during this, but it's really important and that's hiring for passion. Hiring is the most important thing you'll do in your business. And if you hire the wrong people, you will fail. People make the business. So hire people who are gonna put in as much as you are as a founder or close to as much. And you're just your chances of success rapidly soar. I think that it's a powerful way to sort of reorient people around making some of those early hires and closing our closing up for conversation. Gil, thank you. This has been a ton of fun. And covering just through so much of the merge story in such a rapid amount of time, I just really appreciate it. So thank you. Love this speed talk and thanks so much Patrick. I appreciate you having me on. If you're listening to this and you're wondering, how can I connect with other engineering leaders in my city? Pull up your phone right now and go to elc.community. Click our chapters page. You can see that on the menu on the left. Find your local chapter and click join. We're hosting virtual and in-person events all the time. And this is the best way to help you get involved. Expand your network in your city and support your leadership and career growth. So pull up your phone. Head to elc.community. Join your local chapter and get involved. A huge thank you to all of our local leaders who make community happen. And thank you for listening to the Engineering Leadership podcast. [MUSIC PLAYING]