Invest Like the Best with Patrick O'Shaughnessy
· 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?
· 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?