Invest Like the Best with Patrick O'Shaughnessy
· Karim Atiyeh, Patrick O'Shaughnessy
You now get a link that says, "Thanks for shopping at Amazon. If you would like to see your receipt, please click here." And you have to go to Amazon.com, log in, press a couple buttons, and eventually you make it to your receipt. So they made it harder over time to get those receipts. Pretty sure that we were running one of the largest scraping operations in the US at the time, going through, at some point, billions of emails per day and tens of millions of receipts per day. [00:00:00] S0: So what did that teach you? Both strengths and weaknesses, things that you would bring with you to Ramp, but also things that you would leave behind.
· Karim Atiyeh
[00:00:00] S1: I would say a lot of pragmatism in engineering systems, this idea that you're never gonna really build the perfect system, so you're better off building something quickly that will break in very predictable ways and you are able to recover from incredibly quickly. So the idea with Paribus was you start with the assumption that things will break, that you are trying to speed up the process of fixing them quickly when they break, as opposed to building the system that will never break. And it is very different from how I'd say most experienced engineers learn how to do engineering at larger companies, where you are trying to build a great system that will not break and that will withstand the test of time. And there's a beauty to that as well. But that's very different from the way we built things at Paribus. So the name of the game at Paribus is build it very quickly and make sure that it breaks predictably. And a lot of these lessons we certainly brought with us to Ramp with some nuances, obviously. I would say the first big split that we made at Ramp and the way we built product is there are parts of Ramp that we should build in a way that they will never break, and we gotta be very careful the way we built them. And experience in building those systems is very valuable. And there are other parts of Ramp where we need to iterate very quickly, assume that it's going to break, but we need to improve incredibly fast. And we split the product and engineering teams along that boundary relatively quickly. So anything that touched money, money movement, risk, falls in the category of you need to build it right and make sure it doesn't break and assume that you're not going to have to innovate that much, frankly, on it. You just need to build that system really well. And there are a lot of parts of Ramp where we've innovated a ton. Pulling receipts from a mailbox and trying to match them as best you can to the right transaction, if it works, it's amazing. If it doesn't work, it's whatever. No one's going to feel it, no one's going to see it. It's just that a receipt was a match. That's fine. No other company is able to match receipts nearly as good as we are. So it's okay if you are, let's say, optimizing any form or experience on the website. Well, the button is non-functional for a couple minutes, or the colors change, or the font is not correct.
· Karim Atiyeh, Patrick O'Shaughnessy
That's fine. Someone will complain about it and you'll fix it very quickly. It's okay. And to this day, there are little parts of Ramp that are probably breaking 10 times a day, and we're fixing them 20 times a day, and no one's really noticing. Especially early on, I think when you have customers that already perceive you as a small startup and a small company and may have some doubts about your capabilities, I often find it a much better way to build credibility with them and trust if things break and you fix them very quickly, as opposed to if they just don't care and don't notice anything about the product. One of my favorite things to do is just be very quick to respond when a customer brings up something that's broken, or we notice a subpar experience in the product. And we see it as a personal challenge: how quickly can we notice, and how quickly can we fix it? [00:00:00] S0: If I take that lesson away, in parts of the business when you're building a product that have minimal downside and high upside, you actually want things to be breaking. Otherwise you're not taking enough risk. Is that the— [00:00:00] S1: A hundred percent. I think it's very easy to fall into the trap of, well, we want to make sure that there are no bugs. What's one great way to make sure that you have no bugs? Don't ship anything, don't write any code. You will have no bugs. And that's the problem with that approach. So I think if you are solving for great outcome and great impact, you want things to be breaking. [00:00:00] S0: What was the craziest moment in the history of Paribus?
· Karim Atiyeh
[00:00:00] S1: Oof. There was a period of time, I think it was a couple weeks, where we were getting angry letters and cease and desist from multiple retailers. And we're getting these letters from notorious law firms that we had heard of. And we're a team of 12, 13 engineers fresh out of college, trying to google the name of the person sending us a letter or the name of their firm. Oh my God, this is a multi-thousand people law firm that represents the largest corporations. And my hunch was to send them an "I'm sorry" response. And I'm like, okay, we can't really do this. What do we have to do here? And the way we responded to it is just trying to explain in very logical terms what we were doing and why it was good for consumers and why they should care, which was really funny. But one of those crazy experiences was we get a letter from Amazon around how we were supposedly compromising the security of the accounts of their users. And I thought it was really funny at the time because a lot of the product that we had built was one, on AWS, and two, with the help of a lot of AWS architects in order to make sure that it was built as well as possible and as secure as possible for the users. So our response was great. We'd be happy to get on a call with your team that is helping us build this in the most secure way possible. And we got on a call with, I think it was either Andy Jassy or someone very senior on his team at the time when he was running AWS, to just go through our architecture and how we were building this. It seemed to me on the call that they were actually very excited about what we were building. I was like, this is really cool. We like this. And we ended the call with this understanding that AWS was actually really happy with us and that our problem was with Amazon Retail. It ended up getting resolved. But just as a really tiny company being attacked by the legal teams of really massive companies feels really, really scary at the time, but in a way, also validating.
· Patrick O'Shaughnessy, Karim Atiyeh
[00:00:00] S0: Is that helpful to be scared early because then you just get less scared each subsequent time that there's something major breaking? Does it just not phase you anymore? [00:00:00] S1: If you solve really scary small problems, the reward is scary bigger problems, and it never stops. [00:00:00] S0: There's this line. People talk about product-market fit as a stage. It seems like a more interesting stage is when is the first time that someone tries to kill you, like the story you just described. Do you agree with that? [00:00:00] S1: Oh, for sure. [00:00:00] S0: If you're analyzing a company, almost better to invest right after someone's trying to kill them and they survive? [00:00:00] S1: Oh, 100%. If you're doing anything that's correct or right, people are going to try to kill you multiple times. [00:00:00] S0: What's the key to not being killed?
· Patrick O'Shaughnessy, Karim Atiyeh
[00:00:00] S0: What's the key to not being killed? [00:00:00] S1: Perseverance. There are a lot of nuances there, but tell me. I think it's just to never give up. To some extent, I never see the possibility of us being killed as an option, to be honest with you. I'm constantly looking for the multiple ways that we can withstand a challenge and how we survive. And I see the risk when that happens as us endlessly talking about the options and not maybe taking enough action. So I try to get into gear really quickly so that we could just start acting on the ways that we will survive and not get killed. So when a challenge happens, I tend to look through all the ways that we succeed and maximize the chances that we do. And I think the companies that don't do that well tend to die because they spend a lot of time thinking and talking and not enough time doing, as opposed to because they don't see the options, frankly. [00:00:00] S0: What did you learn at the end of Paribus story? So you sold the business to Capital One. Why did you sell it? Lessons learned in selling a business. You made good money doing it.