Invest Like the Best with Patrick O'Shaughnessy
· Karim Atiyeh, Patrick O'Shaughnessy
So they'd buy all those TV news feeds, convert the speech to text, and then classify the text using Markov chains. And a lot of techniques that we're using are essentially the ancestors of what LLMs rely on. Right. It's a lot of the best technology available for doing natural language processing at the time. And my research project involved training these models that they were using a lot more efficiently than they were. So very interesting at the time. The technology was very nascent, but it was a very cool experience. And I guess the best part about it all is the friends I've made along the way. Some of my best friends to this day I've met through RSI. It was a very fun experience. [00:00:00] S0: Maybe you can zoom forward to starting Paribus, why you started it, and what the original idea was in the Ramp story that will be written about one day in some book. It'll be a key chapter, I think, because of the people that come into your life, working together with them in a more formal capacity for the first time, the business lessons that you're learning. So my interest in Paribus is especially what are the key lessons that you learned in that chapter?
· Karim Atiyeh
[00:00:00] S1: Yeah, of course. Paribus was an interesting one. So I started Paribus with Eric, same co-founder as Ramp, obviously. Eric and I at the time were both fresh college graduates in New York, working at our first jobs, both incredibly busy at work. We were buying a lot of our supplies on Amazon online, and we were essentially doing a lot of online shopping. And Eric notices after a trip that the price that he had paid for a flight for his girlfriend at the time was very different than the price that someone else paid. And he notices that there's a discrepancy in the way items are priced online. And we were very lucky in a sense, because that was around the same time that data science was starting to become that function that is very key for really everyone, but online retailers in particular were starting to employ data teams and dynamically pricing their items to try and maximize their revenue. I was in consulting at the time, a little discontent as well. I guess that's maybe the recurring theme is I kept feeling that we were put on these projects, really smart, very ambitious people, to do a lot of manual work that could be done a lot more efficiently with software. And every time I would try to suggest that we write a little bit of software, I would get maybe a nod and, "Yeah, that makes sense." But the incentives just weren't aligned because the consulting firms are pricing for a number of people spending time on projects. So no one really had the incentive to minimize the time spent on projects and just maximize the value. But even then, I found myself running quite a bit of software during my consulting days, which is probably why the first version of Paribus that we built was essentially me writing VBA macros in Excel to track prices. So the very first version of Paribus was an Excel spreadsheet that had a set of SKUs and a job running in the background that would check the price of every single one of those items every day on Amazon. And you could do this with VBA. The programming language really doesn't matter. You can open a web browser, get to the right page, and pull the price and do it in a loop. And that was the first version of Paribus, when we were trying to figure out, is there a business there? Are prices changing quickly enough that there's enough money to be saved for customers, that there's a business model there?
· Karim Atiyeh
And clearly there was. Even in the first month that we were tracking prices, we not only noticed that, yes, prices were changing, but the rate at which those changes were happening in that one month in 2014 was increasing over the course of a month. And that trend essentially never stopped. So we quickly realized that there was a business there. Prices were changing incredibly quickly. And at the same time, all online retailers had some form of promise to their customers that if prices were to drop and to change, there was a best price guarantee or a price match guarantee. And the reason they do this is because they want to give their customers the confidence to just shop with them by default. Exactly, click that button, just do it. If something changes, we'll get it back for you. But they're also banking on the fact that no one really checks the prices of the items they buy after they bought them. With Paribus, we just automated all of it. The idea was, all these retailers have armies of data scientists working for them to price discriminate, and we're going to arm the rebels. Essentially, we're going to build a technology for consumers, the best technology possible, to try and minimize the amount of pain in their online shopping experience and maximize the amount of money that they can recoup after the fact by holding retailers accountable to their guarantees. And we did that incredibly effectively. And it was very popular, as you can imagine. If you're a customer or a consumer and you see a value prop of click a button, save money, it's free, that's a pretty great value prop. So it grew incredibly quickly. I think within the span of a year we were approaching a million users. It was growing very fast. And the experience of building it was incredibly challenging because unlike Ramp or unlike most tech companies, you are building a product on top of a very unpredictable foundation. We were building products on top of the websites of retailers who, one, don't want us there; two, are changing their pages all the time; and three, are heavily incentivized to make it harder for us over time. And when we started building Paribus around that time, Amazon still used to send receipts to your inbox. I don't know if you remember this, but you used to get a full itemized receipt with the price of every single item that you bought. You don't anymore.
· 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?