The Anatomy of Ramp's Hyper-Growth | Karim Atiyeh Interview

1. Competing with a Day One Mentality

All right, Karim, we're going to start this conversation at the very end, which is today, because you have one of the most unique perspectives on what's going on in the world as this technology paradigm is shifting. You're not an upstart anymore. You're a big, established company, but at the same time, you run the company like an upstart, like it's day 1, and you're up against massive incumbents.

The reason I'm interested in this cocktail is that this is going to happen in every industry where there are big, stodgy incumbents that have been doing things a certain way for a long time. There are going to be fast, talented young companies that challenge them. I'm curious for you to detail what it's like to be in that position right now, where you're past $1 billion in revenue. You're one of the fastest companies ever to grow to that size in 5 or 6 years, and you're up against MX and companies like this. What does that feel like? What does the competitive battlefield feel like to you today?

It's very exciting. But even when you are describing us as no longer an upstart, I still haven't internalized this, to be honest with you. I think about the most exciting aspect of being a startup: You get to grow very fast, make decisions quickly, and move quickly. We're trying to maintain that as much as we can, and we do this by essentially breaking up all the different problems we're trying to go after and giving small teams full autonomy over these problems.

Every time I spend some time with a small part of the company, it does feel like they have full autonomy over the problem they're going after and the way they're building. With what's going on with AI advancements and the different ways that companies are starting to build, every company is trying to figure out how to adopt those new technologies and benefit from them. We're still in the phase where you have articles coming out every couple of weeks that are mixed. One week, some will say, "Companies are adopting AI but not seeing any benefit," and another week, you have an article from someone you think highly of or trust saying that their company has adopted AI in some part of the organization and it's had an immense impact on them.

So it's still early. It's obvious to me that the impacts of adopting the technology are transformative, but a lot of companies are still stuck in the very early phases. I would describe the first, very early phase as using those LLMs to do the same work you were doing before, maybe a little bit faster or more efficiently. If you're a developer, for example, you're using AI to help you write a little bit more code.

If you're not sure how to write the next couple of lines of code, you go to ChatGPT or an LLM and have it give you advice. You get some code, copy it, and paste it. Maybe you go a little bit further and start using these agents, where you describe your problem in English and use a Cognition or a Cursor. Then you get a lot more code written for you, and you're reviewing it. That's cool, but I think the next phase that we're entering—and the one that I'm seeing in our company—is one where you start thinking about these LLMs really as part of your product and programming them.

You're no longer writing the same code that you used to write with the help of LLMs. Your code is the LLM now. Your code is the LLM plus instructions and an infinite loop. You're essentially writing those agents. That's what it means, and we're in the middle of that right now.

Do you have a favorite example of that so far that you've actually deployed and is working?

Yeah, of course. I'd say the most obvious one is what we call internally our policy agent. Most companies have a travel and expense management policy. It's generally a document. Sometimes it's well written and clear, and sometimes it's not. It's essentially a document that you write to drive the behavior of people in the company and how they manage their expenses.

In the old world, people make transactions. Before they make the transaction, sometimes they'll go and check the expense policy, and sometimes they'll try to remember it from memory. They'll make a transaction, file an expense report, and some manager or someone on the finance team will try to make sure that the expense made by the employee actually abides by the rules of the expense policy.

It's very manual. Generally, the transactions are missing context, so there's a lot of back-and-forth between the people enforcing the policy and the people who made the transaction. It takes a lot of time. We've built our policy agent in a way that it has more context about the transaction than most people reviewing those transactions today. It's integrated with your calendar, it's integrated with your email, it knows your expense policy, and so on.

It has more context about the policy than any employee. It can run 24/7 as transactions come in and apply the logic of the expense policy against these transactions, deciding whether something is in policy or not, and do that a lot more efficiently than any human. So you have 24/7 live enforcement of your policy.

Not only that, but as it runs over time, it gets better at advising how to make the policy a little bit clearer or easier to interpret. Your policy becomes better and better over time. You essentially have this living, breathing text document that can evolve over time, guiding an agent that has access to tools like your calendar and email on how to classify transactions.

That same principle applies in so many different parts of the company. The good thing about expense policies is that most companies have them, but companies do all sorts of things that sometimes aren't written down and can be very easily automated by agents.

For example, when you receive an invoice as a company, what do you do? You do a couple of things. One, you make sure that the invoice isn't fraudulent. Maybe you make sure that you're being invoiced for a product that you've actually ordered and a product that you've actually received. You make sure that the price matches what you had negotiated.

There are a lot of steps that actually happen before and after any payment that a company makes, and most of the time they're not very well documented. A lot of the work that we're doing right now is possible because we have so many interesting customers using the product to run their finances. We can infer a lot of these policies through their behavior, and a lot of the policies that we're inferring are driving the next generation of agents that we're building.

I was with an old friend last week who was in town for—I think Visa had some sort of big conference in New York last week—and all the various players from your competitors and people in your industry were there. He told me that everyone there was bitching about Ramp taking all their customers.

I'm curious what you think the most common reasons are for that. When you're beating whoever it is, what are the most common attribution reasons when you study why a given customer is picking you over somebody else? It seems a little bit like a slowly-then-suddenly thing is happening with Ramp. You and I have talked about this offline, and I'm curious why it feels that way to you. I think it relates to the speed of product and everything else, but I want to hear it from you.

2. Winning with Consumer-Grade UX

I still go back to the early days and why a lot of people even picked us when we didn't have that much credibility or social proofing: our obsession with wanting to build a consumer-grade user experience for a business product.

You think about a lot of the business products that were built in the previous generation. They were essentially built for decision-makers. You think about building an HR tool or anything. Who's the decision-maker? It's that person on the team. Great. We're going to build it for them, pitch it to them, and convince them to switch to us. Once they do, we're going to care a lot less about them.

Then you end up with business software that's used at a company that maybe solves the problem of one decision-maker but makes everyone else at the company very miserable. You solve one person's problem, but you give everyone else at the company just a small paper cut every day. We wanted to reverse that.

There's a lot of business software that was built in that way, with no care for the user experience. When we set out to build Ramp, we wanted the user experience of an Instagram applied to business software. I would say design obsession has helped us a lot, as has polishing every single interaction and making sure that we only ask questions that are absolutely necessary. We want to prefill any form that can be prefilled so that you have as little work to do as a user of the product.

Over time, we got even better at this because we get even more data about how people want to use the product, and we can skip even more steps. That obsession over design really turned into an obsession over minimizing the amount of time people spend in our app.

I was going to ask what the process is to make that possible. If someone else listening wants to build a consumer-grade app in some other business area, what is the actual practice of doing that over and over and over again?

You keep looking at every interaction that you have with a customer, right? It could be an email, it could be a form, and then you ask yourself: How can I figure out the answer to that question myself without asking the customer? Or, if I'm telling the customer to do X, why can't I do it for them?

For example, I'm sure you've gotten one of those error messages from a product that you've used that will tell you, “Hey, Patrick, you tried to do X and it didn't work. You might want to try 1) retrying the payment or the transaction, or 2) changing your bank account details,” or something like this. Instead of doing this, we could retry it ourselves, for example. If we're asking you to change your banking details or to submit a piece of information, instead of just telling you in an email, “Go to our website and submit your information,” we could have a form right there that allows you to submit your information in the email.

There's always a way to skip a step and make it a little bit faster, and we're essentially always obsessing over that.

3. Divinely Discontent

I feel like this is rooted in your personal psychology. I was talking to our friend David before this, and he uses the phrase all the time: “Divinely discontent.” He told me the story of the day that you announced the $13 billion valuation round, which was, of course, an exciting moment in the company's history. He was with you, and all you were doing was screaming about problems in the product and the team, and things not moving fast enough—zero enjoyment on a day that you would have had a good excuse to be a little bit more relaxed. Instead, you were just pissed off about something and the product not being good enough. Can you talk about where that comes from for you? How long has it been like that?

There are probably 2 reasons for it. One is that a lot of the results that you are seeing today at Ramp are due to the efforts that we put in to solving the problems 6 months to a year ago. The current quarter was baked in a couple of months ago, so I always find it a little bit weird to celebrate lagging indicators.

I often think that they put at risk some of the very important work that we are trying to do today in solving the problems that we have today, because people might feel like, “Things are going amazingly well. We don't really have any problems.” That's not true. There are always problems and always ways to make things better, faster, and more efficient.

It's just like, hey, we're working on such important things, and if we don't realize that they're really important, we might mess up the next 6 months and the next year.

The other one is that I feel like if things were good and we didn't really have problems, I wouldn't know what to do with myself. What are we doing here if the job's actually done? The good thing is the job's never done. We could always push it further and do better. There's always more time that could be shaved off of every single user interaction experience.

As I'm talking, I'm visualizing these charts that I'm sure you've seen. Every time I look at them, I get a bit frustrated by the amount spent in the U.S. on healthcare in total or on education. You see these charts that have been going up every decade for the past couple of decades, where we spend more and more, and a lot of people would say that the outcomes are not necessarily—they're probably better, but they're not as much as you would expect given the spending.

4. The Vision for Ramp

If you dig in a little bit deeper, where's all that spending going? It's very obvious that it's just being wasted on administrative BS and things that don't move the needle, right? It's not being spent on more training for doctors or healthcare providers. It's not being spent on more training for teachers and better educational outcomes. It's being spent on a lot of bureaucracy and BS that doesn't move the needle, and I think a lot of that is what we are trying very hard to reduce at Ramp. We want to play a big part in accelerating that.

I want to learn more about how you bake this into the culture. It seems like this is maybe the central tenet of the Ramp culture. There's a funny story I heard the other day—or, actually, it's just literally right over here. Another founder was telling me about the experience of selling his product to Ramp, which is a customer now, and the last thing that happened was whoever was buying it, some random person at Ramp, said, “We'd like to do it, but we won't do it until you've confirmed that you are a Ramp customer for your business.”

Yeah.

It seems like there's this bite at the edge of the spear at all parts of Ramp, and obviously you're hammering this into people. How do you do that? Describe the process of keeping the culture focused on that tenet.

5. Building a Culture of Mutual Accountability

What I like about this is that from the very start at Ramp, we tried to create a culture where people have mutual accountability to each other, as opposed to a top-down culture where you have accountability to your manager. People want to do well because their peers, their colleagues, and other teams depend on them.

That creates a culture where sales cares a lot about product, product cares a lot about sales, marketing cares about finance, and vice versa. I'd say that's probably where this comes from: We all need to be selling our products. We all need to be making the customer experience better. We all need to be advising our product builders on what we're hearing from customers so that we can take their feedback into consideration.

The most important filter for the interviews I used to do early on, and still do to this day, is: If this person was starting a company and I was looking to join a company, would I join them? Would I start a company with that person if circumstances were different? That's the only bar. If I had to summarize my interview, it would just be that.

That comes from the ability to persevere in the face of challenge and continuously solve hard problems, because at the end of the day, a company is just a collection of people solving problems together, one after the next. They keep getting more difficult and bigger, and the question is how much can you endure, and for how long?

The best way to do that very well is to be on that journey with people who are very aligned—aligned on the values, the mission, and the journey that they're on. There are always going to be more problems. The job is never going to be done. Hopefully, we're enjoying solving those problems together for a very, very, very long time.

6. Origin Story: Growing Up in Lebanon

To rewind the clock a little bit, if we were writing the book Karim's entrepreneurial journey or something, what do you think would be the prologue? What would be the opening scene?

It would certainly have to start in Lebanon, in Beirut, which is where I grew up. I grew up in a very interesting period of Lebanon's history because I was born right at the end of the civil war.

If you rewind the clock a lot in Lebanon, you'll see that it's always been periods of peace followed by some form of conflict and war. I was born in 1989 or 1990, and I spent the first 16 or 17 years of my life there. It was a relatively calm period, with always spurts of conflict but nothing really major. You could tell growing up there that a lot of the previous generation was scarred from the war, and everyone was kind of living on edge.

In other words, I'd say a sense that things are very ephemeral and could disappear very quickly was in the air for my parents. It was, “You're going to have to do the best you can so that you maximize your chances of getting out of here and getting into the best school that you can, so that you can get a visa and build a better life for yourself abroad.” That was very important.

I was living with that stress hanging over my head in a country that was constantly exposed to all sorts of risks. I've learned to live with external risk very well.

You're 16-ish. Maybe tell the first story of coming here—what you were doing and who you met. You know, I love your personal story. What happened when you were around 15 or 16?

Even before coming, I would trap myself in libraries in Lebanon and just find books and magazines that I was interested in. I still remember opening up science magazines in particular and just looking at the latest advancements and discoveries.

Every time I'd look at a new discovery that was made, it was scientists at MIT or researchers at MIT. The name MIT just kept coming up as a place where a lot of incredible engineering discoveries were made, and as a result I was fascinated by MIT as a school.

Then I looked around my high school, and there was 1 person a couple of years ahead of me who had gone to study at MIT. So I reached out to them and asked them what it was like and what a good way would be for me to expose myself to the type of work being done at MIT. Did they offer any summer science programs?

That's when I heard about a summer science program that was hosted at MIT called the Research Science Institute, or RSI.

I ended up looking into that program and applying, and came to MIT in 2006, a year and a half or two years before college, for the Research Science Institute, which was a very transformative experience. It was my first time in the U.S. by myself for an extended period of time. I had come as a tourist with my parents, but I think I had only come to Disneyland once. I was on my own with another 60 or 70 students, all brilliant and incredibly talented.

Even before coming to the program, we had to pick what our research subject or topic would be. I had picked computer science at the time, thinking, “Great, I’m going to learn a lot more about it,” and it turned out that the expectation was that I would do computer science research, not learn about computer science. That’s where I was essentially put under a lot of stress: I not only needed to do some research, but I also needed to teach myself a lot more in a very, very short period of time.

I ended up working at this small startup off of the Kendall subway stop in Boston, called Virage. At the time, Virage was buying lots of video news feeds from all over the country. They’d buy the news feeds of the local ABC station in Texas, for example, all over the U.S. They’d buy all those TV news feeds, convert the speech to text, and then classify the text using Markoff chains.

A lot of the techniques we were using were essentially the ancestors of what LLMs rely on. It was a lot of the best technology available for doing natural language processing at the time. My research project involved training these models much more efficiently than they were being trained. The technology was very nascent, but it was a very cool experience.

7. The First Company: Paribus

I guess the best part about it all is the friends I made along the way. Some of my best friends to this day I met through RSI.

Maybe you can zoom forward to Paribus—starting Paribus, why you started it, and what the original idea was. It’s this interesting—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, and the business lessons that you’re learning. What are the key lessons that you learned in that chapter?

Paribus was an interesting one. I started Paribus with Eric, the 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 and both incredibly busy at work. We were buying a lot of our supplies on Amazon online. We were essentially doing a lot of online shopping.

Eric noticed after a trip that the price he had paid for a flight at the time was very different from the price that someone else paid. He noticed that there was a discrepancy in the way items were priced online. We were very lucky, in a sense, because that was around the same time that data science was starting to become a function that was very key for really everyone, but online retailers in particular were starting to employ data teams and dynamically price their items to try and maximize revenue.

I was in consulting at the time, a little discontent as well. I guess that’s maybe the recurring theme: I kept feeling that we were put on these projects with really smart, very ambitious people to do a lot of manual work that could be done a lot more efficiently with software. 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 were pricing for a number of people spending time on projects. No one really had the incentive to minimize the time spent on projects and just maximize the value.

Even then, I found myself writing 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. 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.

You could do this with VBA. The programming language really doesn’t matter. You can open a web browser, get to the right page, pull the price, and do it in a loop. That was the first version of Paribus, when we were trying to figure out whether there was a business there—whether prices were changing quickly enough that there was enough money to be saved for customers, and whether there was a business model there.

Clearly, there was. Even in the first month that we were tracking prices, we not only noticed that prices were changing, but that the rate at which those changes were happening in that one month in 2014 was increasing over the course of the month. That trend essentially never stopped. We quickly realized that there was a business there. Prices were changing incredibly quickly.

At the same time, all online retailers had some form of promise to their customers that if prices were to drop or change, there was a best-price guarantee or a price-match guarantee. 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’ve bought them.

With Paribus, we just automated all of it. The idea was, “Well, all these retailers have armies of data scientists working for them to—”

Price discriminate.

To price discriminate. We’re going to arm the rebels, essentially. We’re going to build the best technology possible for consumers to try and minimize the amount of pain in their online shopping experience and maximize the amount of revenue, or the amount of money, that they can recoup after the fact by holding retailers accountable to their guarantees.

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 proposition of “Click a button, save money, it’s free,” that’s a pretty great value proposition. It grew incredibly quickly. Within the span of a year, I think we were approaching 1 million users. It was growing very fast.

The experience of building it was incredibly challenging because, unlike Ramp or 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, first, didn’t want us there; second, were changing their pages all the time; and third, were heavily incentivized to make it harder for us over time.

When we started building Paribus, Amazon still used to send receipts. You used to get a full, itemized receipt with the price of every single item that you bought. You don’t anymore. You now get a link that says, “Thanks for shopping at Amazon. If you would like to see your receipt, please click here.” You have to go to Amazon.com, log in, press a couple of buttons, and eventually you make it to your receipts. They made it harder over time to get those receipts.

I’m pretty sure that we were running one of the largest scraping operations in the U.S. at the time, going through, at some point, billions of emails per day and tens of millions of receipts per day.

8. Lessons from Building on an Unstable Platform

What did that teach you? What did building that teach you about both strengths and weaknesses—things that you would bring with you to Ramp, but also things that you would leave behind?

I would say it taught me a lot of pragmatism in engineering systems. There’s this idea that you’re never really going to build the perfect system, so you’re better off building something quickly that will break in very predictable ways and that you’re able to recover from incredibly quickly.

The idea with Paribus was to start with the assumption that things will break, and 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. 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. There’s a beauty to that as well, but that’s very different from the way we built things at Paribus.

The name of the game at Paribus was: build it very quickly and make sure that it breaks predictably. 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 in the way we built the product, is that there are parts of Ramp that we should build in a way that they will never break, and we’ve got to be very careful about the way we build them. Experience in building those systems is very valuable.

There are other parts of Ramp where we need to iterate very quickly and assume that they’re going to break very quickly. That’s going to break, but we need to improve incredibly fast. We split the product and engineering teams along that boundary relatively quickly.

So anything that touches money movement or risk falls into the category of, “You need to build it right, make sure it doesn’t break, and assume that you’re not going to have to innovate that much on it.” You just need to build that system really well.

There are a lot of parts of Ramp where we’ve innovated a ton, right? 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, right? No one’s going to feel it. No one’s going to see it. It’s just that a receipt wasn’t matched. That’s fine.

No other company is able to match receipts nearly as well as we are. It’s okay if you’re optimizing any form or experience on the website. If the button is nonfunctional for a couple of minutes, or the colors change, or the font isn’t correct, that’s fine. Someone will complain about it, and you’ll fix it very quickly. It’s okay.

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, 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’s a much better way to build credibility and trust with them if things break and you fix them very quickly, as opposed to them just not caring and not noticing anything about the product.

One of my favorite things to do is be very quick to respond when a customer brings up something that’s broken, or we notice a subpar experience in the product. We see it as a personal challenge: How quickly can we notice it, and how quickly can we fix it?

I take that lesson away as: in parts of the business where you’re building a product that has minimal downside and high upside, you actually want things to be breaking. Otherwise, you’re not taking enough risk. Is that 100%?

100%. I think it’s very easy to fall into the trap of, “We want to make sure that there are no bugs.” You know what’s one great way to make sure that you have no bugs? Don’t ship anything. Don’t write any code. You’ll have no bugs.

That’s the problem with that approach. If you’re solving for a great outcome and great impact, you want things to be breaking.

What was the craziest moment in the history of Paribus?

There was a period of time—I think it was a couple of weeks—when we were getting angry letters and cease-and-desist notices from multiple retailers. We were getting these letters from notorious law firms that we had heard of, and we were a team of 12 or 13 engineers fresh out of college. We were trying to Google the name of the person sending us a letter or the name of their firm, and thinking, “Oh, my God, this is a multithousand-person law firm that represents the largest corporations.”

My hunch would be to send them an “I’m sorry” response, and I was like, “Okay, we can’t really do this. What do we have to do here?” The way we responded was by trying to explain, in very logical terms, what we were doing, why it was good for consumers, and why they should care. It was really funny.

One of those crazy experiences was when we got a letter from Amazon about how we were supposedly compromising the security of their users’ accounts. I thought it was really funny at the time because a lot of the product we had built was, first, on AWS, and, second, built with the help of a lot of AWS architects in order to make sure that it was built as well as possible and as securely as possible for users.

Our response was, “Great. We’d be happy to get on a call with the team that’s helping us build this in the most secure way possible.” We got on a call with either likely Andy Jassy or someone very senior on his team at the time, when he was running AWS, to 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. They were like, “This is really cool. We like this.” We ended the call with the understanding that AWS was actually really happy with us, and that our problem was with Amazon Retail.

It ended up getting resolved, but as a really tiny company attacked by the legal teams of massive companies, it felt really scary at the time—and, in a way, also validating.

Is it 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?

We just—if you solve really scary small problems, the reward is scary bigger problems, and it never stops.

There’s always this line people talk about product-market fit as a stage. It seems like a more interesting stage is the first time that someone tries to kill you, like the story you just described. Do you agree with that? If you were analyzing a company, is it almost better to invest right after someone’s tried to kill them and they’ve survived?

100%. If you’re doing anything that’s correct or right, people are going to try to kill you multiple times.

What’s the key to not being killed?

Perseverance. Never giving 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 survive.

I guess I see the risk in those situations as us endlessly talking about the options and not taking enough action. I try to get into gear really quickly so that we can start acting on the ways that we’ll survive and not get killed.

When a challenge happens, I tend to look through all the ways that we can succeed and maximize the chances that we do. 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.

9. From Paribus to Ramp

What did you learn at the end of Paribus’ story? You sold the business to Capital One. Why did you sell it? What lessons did you learn from selling a business when you made good money doing it?

The Paribus story was very instrumental in us wanting to start Ramp, to be honest. At the time that we sold Paribus, we weren’t really looking to sell the business. We were looking for partners who could help us grow.

We thought about it this way: Paribus was really great and drove a lot of value for people who had shopped online in very predictable ways. We were looking for partners who knew, or could help us figure out, who had recently shopped online so that we could get in front of them, make a compelling pitch, and hopefully convert them into a user.

Who better for that than the credit card companies? They know exactly who made a purchase at Amazon, Walmart, or Jet.com at the time. We got to meet the team at Capital One and really enjoyed working with them. They were a lot more tech-savvy than most of the other banks, and that was the reputation they had, which was great.

We were in partnership conversations with them. Frankly, they were interested in building differentiation for the card product because, at the time—and frankly, to this day—a lot of consumer card products still fail to differentiate. They’re different versions of the same product, just marketed differently.

They were interested in differentiating through product and partnerships, and we were interested in figuring out who had recently purchased something at Amazon or Walmart. We were in partnership conversations with Capital One around the same time that we were getting a lot of these legal challenges.

It was clear that we needed more firepower, whether in the form of partnerships or capital, just to withstand the storm. Quickly, those partnership conversations with Capital One turned into acquisition conversations.

We became really interested because our visions were clearly very aligned with the Capital One team. They wanted to give us the capital, support, and funding to turn the antagonistic relationships with the retailers into friendlier relationships, and they had a lot of great relationships with those retailers. That was very interesting.

The most interesting part of those acquisition conversations was that we got to learn a lot more about the credit card industry, how it worked, and where the revenue came from. It was fascinating to see that, in the card business, they essentially put the product in the hands of customers. There’s no contract that anyone needs to sign. The more they use it, the more revenue you make, and you can just focus on making the product as good as possible so that they use it as much as possible.

It was refreshing. It was like, “Great. You just put this card in the hands of a person, and the more useful it is to them, the more they use it and the more revenue you make.” We started understanding that fascinating business model, and it felt very powerful to combine that card with the Paribus offering at Capital One. It just felt like a great natural fit.

After spending about 2 years at Capital One and growing the Paribus product, which is now called Capital One Shopping and includes some other features that I think are very valuable, we started thinking, “What’s next for us?” Both Eric and I were clearly not done with our entrepreneurial journey. We wanted a bigger challenge, and a lot of the idea for Ramp early on was: What if we built, frankly, something like Paribus for businesses?

It started with, “What if we built technology that helped businesses save as much money as possible?” That later turned into, “How can we build technology that helps businesses save as much time and money as possible?” Businesses, as we both know, tend to waste a lot more time than they do money. Those are generally interchangeable.

We set out to build Ramp, and just as was the case for Paribus, the card early on was a way to know what businesses were spending time and money on. If you know what tools they use and how much money they’re spending on them, you get a sense of how the business functions, what kind of business they are, and eventually where they are wasting both time and money and how you can help them save as much of it as possible.

This is still true to this day about Ramp. I’d say the biggest difference is that the scope of our ambition has gotten a lot bigger. We’re not only helping businesses with the money and time they spend on card purchases; it’s really all the spend happening across their business and all the workflows associated with it, starting with procurement, which you could describe as the workflows that dictate how a business makes decisions on what to buy, how to buy it, and how to negotiate for it, all the way to accounting for those transactions and reporting on them.

The scope of our ambition has gone from the mode of transaction—the card—to all the workflows happening before, all the workflows happening after, and all the time wasted as that is happening.

If I go back to day 1 of Ramp and this notion that you need a way to know what’s being spent, where, how, why, and by whom, talk us through the very first version of the product. A dumb investor at the time might have said, “What the hell do we need another credit card for?” There were lots of business credit cards. MX had a great brand, just to pick 1. There were more than just MX, but people loved MX. MX for Business was a huge business. Why do I need another card?

Bring us into the room where you’re talking about what literally to take as the first step, who to send it to, and why. The first couple of days are always so interesting: who raised money from whom, how you figured that out. The deep detail is fascinating.

I agree with you. They still have a really good brand, but at the time, that’s all they had. That’s still all they have. They have a good brand, and I guess you could log in and check your statement, but that’s about it.

Funny enough, our pitch in the early days, before we had officially launched, as we were looking for design partners and people to give us feedback on the product, wasn’t, “This is amazing and going to change your life.” It was, “This is not worse than MX, and you might as well give it a try.”

It’s a card. It works. It does all the things the MX card or any other business card will do. Because we had built direct trust with you, you had to trust that we would make it better for you over time.

Well, it was a terrible pitch. We went and essentially sold this to friends and family—people who trusted us not because of the product we had built, but because of their belief in our capability to improve the product over time.

These were people we had gone through Y Combinator with in 2015 with Paribus. My brother was also starting his company, and a lot of our friends were entrepreneurs in New York and in the startup ecosystem in New York. Those were our early customers. They were partners more than they were customers, frankly. They were design partners.

The first version of the product, or I guess the first differentiation we really built, pulled from some of the skill sets we had acquired at Paribus. It was a very robust integration with your email. You make card transactions, and a lot of the receipts go to your email. How do we tie these 2 things together as effectively as possible?

We were really good at parsing emails while preserving the privacy of your business emails. We had built technology that would identify the emails that were very likely to be receipts, extract those, identify purchases, and tie them to your card transactions.

That step alone actually saves a lot of time in the workflow of submitting expenses. You look at your statement and think, “Where’s the receipt for that thing?” We got very good at mapping receipts in your inbox to the transaction.

The next step was getting very good at essentially transforming the merchant identifier into human-readable text. You often look at these credit card statements and think, “What is that thing? It makes no sense. What is MCDX?” Then you realize, “Oh, that’s a McDonald’s identifier.” It’s like, “Okay, good. Why don’t we just call that thing McDonald’s?”

We built the technology to clean up the merchant names. We built the technology to map the receipts in your inbox to the receipts in your statement. Then we just kept improving the product 1 step at a time and taking it further and further. That was the very first version of Ramp: really good mapping of receipts.

As for how we thought about investors, Eric and I did not really want to raise at the beginning. Part of the reason we wanted to start Ramp was that it was something we could do because we had the right to do it. We were 2nd-time founders, we had some capital set aside, and building a business like Ramp required capital because you need to fund the receivables of your customers.

We had more capital than we did as 1st-time founders, and we had more credibility. We didn’t really need investors. The first investor we got connected with came about because, around that time, I was playing Fortnite with my brother and some of his friends. It turned out that there were a lot of other founders and people in the startup ecosystem that we were playing with, and 1 of them was Delian Asparouhov at Founders Fund.

He was, I’m pretty sure, on some sort of garden leave because he had left likely Khosla with likely Keith Rabois and was about to join Founders Fund. At that time, I was still at Capital One, still thinking about Ramp, exactly how it was going to look, and when we were going to leave Capital One to start the company.

I remember telling Delian, “I think I’m going to stop playing Fortnite. I need to start getting serious because Eric and I are starting another company.” He got very curious and told me that he and Keith had just started, or were about to start, at Founders Fund and were essentially looking to fund an idea just like this one.

I think he said something along the lines of, “I’m going to be in San Francisco next week. Why don’t you come and pitch us on Ramp?” I called Eric and asked, “What do you think? Should we do this? We don’t really need the investment.”

We both got really excited, particularly because Keith himself was a legendary investor and had had a legendary run. He was particularly knowledgeable about that space. He had helped start Square and was early at PayPal. He was uniquely positioned to understand exactly what we were trying to do, and we felt like he would be the perfect investor for our kind of business.

We were interested in talking to him more for the advice than the money, which is the best way to meet investors.

What have you learned about investors since Ramp has been— I would call it extremely successful at raising capital, but from the right people. Your cap table is an extremely impressive list of investors. How are you so good at it?

We don’t think of investors very differently from how we think of our employees. The difference is that you can’t buy Ramp stock on the open market. You can be a private investor in Ramp, or you can come work at Ramp, and these are the 2 ways that you’re able to get Ramp equity.

Employees invest their time and effort, and investors invest their capital or their piece of capital. They’re not that different. In the same way that we like to select employees who we think bring something to the table and can help us differentiate and push the envelope further, that’s how we think about our investors as well.

We think of it as a long-term partnership, and we think about what they can bring to the table. It’s very different for every investor. Some investors have expertise that they can help us with, and a lot of them have networks and great portfolio companies that we think can be great partners to us. We’ve always thought about it very similarly to how we think about interviewing great employees.

10. The Framework for Choosing Investors

So you could bring the best person into the company, but if you don't spend time with them to onboard them, figure out exactly what you want them to do, understand what their skill set is, and empower them to do the best work they can, you're not going to get a lot out of it. If you bring investors on board and don't nurture that relationship, get to know them better, and understand what they're really good at and how they can help you, you're not going to get a lot out of it.

We spend a lot of time obsessing over how to keep our investors aware of the business, how it's going, what challenges we're facing, and how they're best positioned to help us. We spend a lot of time educating them about the business and its challenges. I think it's a lot more powerful to do that over a long period of time so that they see the evolution, as opposed to reaching out to your investor once in a while when you need something.

It seems like historically there's been more demand for it than supply of it.

Yeah.

How much are you using that to drive them to help you between rounds in order to gain access to future supply of Ramp equity?

I realize that we're very lucky to be in a position where, at almost every round, there was a lot more demand from investors than there was supply. But I also see it as a great opportunity to make sure that a lot of investors we're excited about can often get a starting position in Ramp and build up the position that they're really excited to get over time.

We make that very obvious. It's going into the relationship one step at a time, and a lot of investors get some allocation in one round. As we build a relationship and they get more excited about the business, and we get more excited about working with them, they have an opportunity to invest in subsequent rounds. There's been a dynamic that really started at our seed round and still hasn't ended. Most of our investors—I think it might be all of them—have participated in multiple rounds.

What was the hardest round you ever raised?

It might have been 2022. Maybe that round was somewhere toward the end of 2022 or 2023. It wasn't because it was hard to raise the round. It was more because it was hard for me to make peace with the fact that maybe the valuations had gone down. But it wasn't so much that; it was more, why the hell would we raise when we don't really need the cash and the valuations are down? So what the hell is the point of that?

It's hard to say whether part of me thinks that I was wrong and part of me was like, I guess we'll never know. But the reason it was so interesting is that when things like that happen, especially in the private markets, a lot of external observers might have the perception that the last mark that the company had was at a time when valuations were not really anchored in reality. So what really is the mark today? No one really knows.

It ends up creating uncertainty for investors, employees, and everybody. There's an element of, hey, the valuation is what it is. Who cares? The act of raising a round only makes it known. It doesn't change anything about the valuation; it's just a price-discovery mechanism. So I think of that round a lot more as, great, let's just discover what the price really is and where the market really is, so we can set a checkpoint and start building from that checkpoint.

In retrospect, it was a hard round to get aligned on—the need to raise—but at the end of the day, we also saw it as, look, if we get great people and great investors on board who are excited about the journey ahead, who really cares where the checkpoint is? We've never really tried to maximize the valuation at every single round. That doesn't really matter. It's about the ultimate enterprise value that we can create, and I think that just comes from the sum total of the value we're creating for our customers.

To do that—to create that enterprise value—I'm coming back to this original algorithm that you laid out, which is this neat model: if you do a better job and make a thing easier to use, they spend more and you make more money.

Exactly.

So what were the next couple of turns of that crank? Originally, you were really good at receipts and something basic to save some time. What's your memory of the earliest explosive moment of customer adoption, and what was going on? What were you building? Just give us the next couple of turns of that algorithm.

Once we got in, the algorithm became: let's try to get our best estimate on how much total time is being wasted by customers and get that time down as much as possible. We think a lot about the value that we create for customers in terms of minimizing time waste. You look at time and money wasted: money wasted on transactions that shouldn't have happened, and time wasted on reviewing transactions or adding information related to transactions so they can be reviewed. You get the sum total of that time, and you start building products that minimize the time spent.

Can you predict what that transaction was for instead of asking the user for a memo? Can you get price benchmarks about what products cost so that the person doing procurement doesn't have to spend a lot of time doing research? Can you extract the information from an invoice that was received and account for it properly so that you don't have to spend a lot of time figuring out what accounting category a transaction falls into?

We kept mapping out the total amount of time wasted in all parts of the finance team that we touched, and we looked at that as the total addressable market. As we build products, we get more adoption, more customers get excited to use more of Ramp, and the total value that we deliver for them is higher.

There were points early on when you got customers that just didn't want to hear the pitch at all. They were like, "I'm really only interested in the card part. I'm really only interested in the cash back I'm going to get, and maybe the API that you offer."

I remember one early customer that I'm sure you're familiar with but that I sadly cannot mention. Just broadly, it's an aerospace engineering company famous for wanting to build a lot of everything in-house and a lot of its software in-house, with a healthy skepticism of external vendors. They weren't going to build their card product, but as a result, their perspective when they wanted to use Ramp was, "We're really only interested in the card. All the other software we want to build ourselves."

It was great that we offered an API because they said, "Fantastic. We can plug into the card that you've built, map it to our internal ERP, extract all the data we need, and we'll build all the software." The first 6 months rolled around, and they said, "Oh, we really like what you built there over the past couple of months. We want to try it." They tried that, and then said, "Oh, we really like what you've built around AP automation. We really want to try it."

Before you knew it, they were trying more and more of the product, driving a lot more value, and were very excited to roll it out not only to more users in their business but, frankly, to more of the finance workflows they were experiencing. That land-and-expand motion really started to become real, I would say, 2.5 or 3 years into the company, when it was no longer this cool-looking card with a nice UX that integrated with your receipts, but we were actually building AP automation software, accounting automation software, and so on.

11. Shifting the Business Model

How do you think about the transition from a business that's a total payment volume business, where you're basically making more money as more is spent on the cards, to something that looks more like a blended TPV and SaaS business? I know your SaaS revenue is exploding. Talk about that transition. Why go that direction? Why not just try to push it all through TPV?

It's a beautiful and very simple business model to be able to just put the cards in the hands of somebody. The more they use it, the more revenue you get, and you're essentially focused on building great software so that they're incentivized to use it. We actually want businesses to spend less. Unlike most other card companies, we're not here to put rewards in front of them that incentivize them to spend more. Our view is to build software that helps them spend less, and as a result they'll use your card and you get more share of wallet, but they're saving money.

They're saving money. The best ways to help them save money are to help them not make transactions that they should never have made, as opposed to giving them points and rewards. That's a beautiful model.

The limits of that model, though, are that the amount of money that businesses spend on cards does not scale linearly with the complexity of that business. Small businesses tend to run everything through cards, so it works well for small businesses. But as you mature, larger businesses tend to move a lot more of their purchasing and spending through essentially bill-payment and procurement systems, and not as much through cards.

If you try to visualize what card spend looks like in a business, let's say on one dimension you have card spend, and on the other dimension you have either the complexity of the business or the number of employees—however you want to chart it—it starts to plateau at some point. When you really think about what our real skill is at Ramp, we're really good at reducing the bureaucracy, complexity, and time waste in a company's systems and building software to do that. That has a lot of value for really large businesses.

So what this means is your mechanism for capturing value, which is a small percentage of card transactions, breaks for large businesses.

Because we drive a lot of value for them. We built a lot of great software for them, but we're not able to capture any of that value for really, really large businesses because our revenue mechanism is not scaling.

That's when we started thinking, “Okay, great. What is the right value-capture mechanism when most of our product and engineering teams are focused on driving value for these complex businesses?” And you're like, “Well, we need to be able to charge for software.” Frankly, if we are charging for software, it will also guide us better toward the right things to do, right? You get a feedback signal from the market that they're willing to pay for certain products because they get value from them.

That's when we decided to transition. There was a lot of fear when we did, internally, because you have this beautiful business model that's working really well, and everyone's a little freaked out that people might not be willing to pay for it. Is it going to hurt our conversion? Is it going to hurt our growth?

It turns out that not only did it not do that, in many ways it accelerated that growth because it incentivized our sales team to mention those products and talk about them. It also incentivized our customers to be a lot more demanding and responsive, and as a result, they helped us essentially guide our roadmap a lot better than if the product was free and no one cared about it.

A lot of our engineering teams' focus right now is on continuing to build these products that drive value for customers and capture value through software pricing and software revenue. In many ways, we're still trying to figure out the right way to monetize and price some of the agents that we're working on and building that drive more value.

I think a lot of companies are really trying to figure out: How do you price for work? How do you charge for work? And you have a theory.

You want to charge for the complexity of the task that the agent has been able to solve. You're starting to see more and more business models where you're essentially charging for the time that the agent is spending on a task or the number of tokens that they're using, which is fine.

12. Why the Best Builders Will Be Technical

I worry a little bit about that model sometimes incentivizing the engineering team not to be as efficient as possible with its use of AI, right? If you're a company charging for how much time the agent is spending on the task, are you not incentivized to just use lots of CPU cycles and not make it super efficient? I worry about that a lot.

That's why I don't really love that model. I'm not quite sure exactly what it's going to look like.

I'd love to ask you about a few of your general views on company building and the future. One of them that you and I have talked about before is this view that a lot of the best company builders will be very technical in this era.

Yeah.

Say more about that.

I think we're at an interesting junction right now. The best analogy that I can give is the Ford analogy: if you had asked people before cars what they wanted, they would have said faster horses.

We're probably at the juncture right now where you ask customers what they want from your products, and they'll say, “I want an additional widget here and an additional button there.” They don't realize that the car to their faster horse is possible. We as a company should be obsessing over what customers really want. It's like, well, they want to get from point A to point B, and what is the best way to get them there? It's to build a car for them.

If you ask the question, who even realizes that the car is possible and what it might look like, it's the people who came up with the technology for how an engine functions, what it's capable of doing, and what is possible. These tend to be more technical people in general, right?

I think technical folks are more likely to see the possibilities in terms of product than nontechnical folks. As a result, particularly right now, technical folks can be very impactful in other disciplines because they see the possibilities better than other experts might.

The other side of it is that the gap between not having subject-matter expertise in a domain, say, marketing, health care, or education, and having it is the smallest it's ever been. The only thing stopping you from getting that knowledge is your ability to learn and ask the right questions of an LLM that can help you become an expert a lot quicker than you otherwise would be.

I like to joke now that I'm a better doctor than I've ever been, but I'm not a doctor. I'm a better lawyer than I've ever been, but I'm not a lawyer. In practice, that means that when I'm having a conversation with my doctor, I'm a lot more knowledgeable and I know to ask the right questions. When I'm having a conversation with a lawyer, they're a lot more efficient and I'm asking the right questions.

13. An Engineer's Approach to Marketing

As a result, I think engineers who know what is possible can help us build the future of our product much better for our customers, even though they have not done procurement before, they have not done AP before, they have not done accounting before, et cetera.

You've extended that even to marketing. Could you maybe tell this story? Rewind time—I don't know, a year and a half or 2 years ago or something—you and I were talking about this, and you decided to go take over marketing as the CTO. You've had this experience since, which I find really interesting: what it's like to bring an engineer and an engineering team to a problem without domain expertise, in the same way you're just describing.

What did you do? Walk us through that, because it feels like that playbook might be usable by others in different parts of their business.

The funny thing about that is I think that was a time when all the lagging indicators were going extremely well. A lot of people were asking me at the time, “Wait, what do you think is broken?” Things seemed to be going quite well. There was no need for a change there.

I was looking at the early leading indicators and starting to see things like, well, we'd made our conversion really good. In a lot of segments, we were converting at more than 50%. That meant that if a customer had a conversation with a salesperson, there was a 50-plus-percent chance that they would become a customer within 30 to 60 days, which is incredible.

You're like, “Okay, conversion is getting really good.” We've gotten better at monetization, but conversion can't get better than 100%. There's some kind of upward limit. There's some kind of upward limit to monetization as well, like some percentage of the value that we're driving.

Okay, the upward limit to how big our TAM is is a lot further because we're still, to this day, sub-2% of corporate card spend alone. It just felt like we were starting to slow down maybe a little bit in our ability to generate leads. While these two other things, in terms of conversion and monetization, were going really well, there's an upward limit to them. If we didn't figure out how to reaccelerate our ability to generate leads, we'd be in trouble today, right?

That was a year, year and a half ago, and I started obsessing over that problem. I guess I turned to maybe some sense of paranoia when everyone else around me felt like things were going great. For me, at the time, that was the problem: how do we make that better?

I'd say around that time there was maybe an attitude in marketing broadly of, “We would try things, and if they didn't work, we would maybe assume that, well, those things don't really work for us,” as opposed to, “No, they have to work; we just haven't figured out how to make them work.”

What's an example of that?

Let's say we would try to run an ad on a podcast and it doesn't work. We'd say, “Well, podcasting doesn't work for us.” My attitude would be, “No, you picked the wrong person to partner with, or you picked the wrong format for an ad.”

Why is the thing broken? It's not that the thing doesn't work; you haven't figured out how to make it work. Clearly, all these forms of advertising do work; otherwise, other good companies wouldn't be doing it. We just need to figure out what works for us and how to make it work for us.

That was the lens that we brought to everything: direct mail, paid advertising, brand advertising—all the different things in marketing, product marketing, and how we launch products. I went into it with the attitude of, “All right, we're going to fix the experimentation mechanism and the system through which we do work,” and in many ways apply the Elon algorithm to a lot of parts of marketing.

In a lot of parts of marketing, you'll need to work with the brand team to say, “Generate an image or an asset,” whether it's for a product launch or an ad. You want an image, an asset, some copy, and, as part of marketing, you tend to work with the brand team on those. The way it used to run before was that, for every single piece of content that you wanted to generate, you had to write a brief.

So you would write a brief to explain to the brand team what you’re trying to do. That brief would get reviewed by the brand team about once a week. The brand team would decide whom to assign it to based on skill set, and then you would get some output 2 weeks later, or maybe a week later. So that meant that no matter what you wanted to do in marketing, if you were working with a brand team, it would at the very least take about 2 weeks, which is crazy.

What if you need to work on something that should take 10 minutes or 20 minutes? It doesn’t matter. It’ll take 2 weeks for it to be in front of somebody, and then they’ll do the work for 10 minutes. With that kind of clock speed, it’s impossible to get anything done. While a lot of people would have gone into marketing with, “Okay, great, the way to fix this is let’s come up with a better campaign idea,” I went into it with, “Okay, let’s just look at the actual system that generates work and focus on how we can make that system as efficient as possible.”

I didn’t go into it with, “Oh, I have better creative ideas than the people on those teams,” because we have amazing people. I just want to put their ideas in front of the world as quickly and as efficiently as possible. That’s what I’m focused on. We have great creative people. They’ll still come up with the ideas, but when they have an idea and they want to put it in front of someone, I wanted that to take 10 minutes, not 2 weeks.

If we do that, we can take a lot more shots on goal. We could take a lot more risk with the things that we do because we know that if it doesn’t work out, we could try something else tomorrow. That’s really the type of attitude that we went into it with, and I think that’s helped us a ton.

Actually, I have another example that I love. You could think about billboard advertising. If you want to put a billboard in New York, let’s say it costs you $100,000. The funny thing with billboards is you don’t really get that much economy of scale. If you want to put another billboard, it costs you $200,000; you want to put 3 billboards, it’s $300,000. But if you want to change a billboard that you’ve already bought, it only costs you $1,000.

So that means that if you have 1 billboard in Union Square and you want to change it tomorrow, that costs you another $1,000. You want to change it after tomorrow, that’s another $1,000. You can essentially have a billboard in Union Square that changes 7 times in a week, and that’s $107,000. Or you can have 2 static billboards for $200,000. I would argue that 1 billboard changing 7 times in a week is a much more powerful way to drive a message and get a story out than 2 billboards, and it’s a lot cheaper.

A lot of the attitude that we brought in is, how can we find these hacks and ways to get more out of the systems that exist, where the creative is not really changing? I’m not trying to influence that, but the system through which we are doing marketing work is a lot more inquisitive and experimentation-driven.

I love that one side of the system is getting more at-bats, let’s call it. The other side of the system is, where are you getting hits? That feels also very complicated, especially when it’s podcast advertising.

Typically, what we’ve found in podcasts is the value: you just hear the name 4 million times, and then eventually, when you need to solve the problem, you’re like, “Oh yeah, Ramp.” That feels harder to measure than an ad on Facebook or something where the feedback loop is incredibly tight. You’re an engineer. I know you like tight feedback loops. How do you balance stuff that’s harder to measure and assign value to it?

You could either figure out what the exact value is, or you could think about it comparatively. The way we’ve thought about it in working with you, which has been amazing, versus, let’s say, working with another random podcast, is that I listen to your podcast a lot. I love it. I think a lot of people like me listen to your podcast.

I think a lot of our audience is people like me who are building businesses and obsessing over businesses. If we decided that we wanted to work with podcasters, who are the best in the world that we can work with who have the right audience for us? That’s the lens.

It’s more about targeting the right audience than it is, let’s say, a higher-level metric like how many clicks am I getting or how many views am I getting. It’s about getting the right views, and that’s the way to think about it for us.

So if you were to step back and describe, once more, holistically, the system that you installed, how would you describe it? If there was a diagram of the system that you came and installed in marketing to do everything you just described, what does the diagram look like?

It’s more about principles. It’s fast iteration cycles. It’s scientific, where there’s experimentation and feedback loops. It’s like: let the person who came up with, let’s say, the creative idea be accountable to that idea. It’s not done by committee. You don’t get to ask 10 people what they think and come up with a watered-down idea. You just do it, and if you do it well, you get credit for it. If you don’t do it well enough times, eventually you will no longer be at the company. That needs to be known. People have more skin in the game when they’re making those decisions.

Making sure that the tools that team has access to are not getting in the way but are empowering you is also important. We make a lot more use of AI tooling now in marketing than we used to. Today, if you want to put together an article on Ramp and you are, let’s say, on the SEO team or on the content marketing team, and you want to generate an image for that article, we have a tool that was built internally that allows you to generate an image that is on-brand within seconds.

So it’s quick experimentation, accountability with the person coming up with the creative, and tools that don’t get in the way but allow you to get your work done very quickly with as little dependency as possible.

Through this process, I love the billboard example. I’m curious what the next 3 are. What are the most surprising things you discovered about different channels or different ways of doing things? Anything else come to mind from the year of marketing adventure?

There are things that have always been true, let’s say, in paid marketing or what happens in social media. You get a lot of these concepts and patterns that work incredibly effectively in paid advertising for a very short period of time and then stop working. So it’s very important to always be at the forefront of what is happening there and why it’s working, until all the alpha starts being taken away and it stops working.

I’ll give you an example from the Paribus days, because I don’t want to give away all our secret sauce either. I think that was a very powerful one. When Facebook introduced video ads in the News Feed, I think in 2014 or 2015, that was a new thing at the time.

When they first introduced it, you used to scroll through your News Feed and the videos would just play immediately with the sound. People were really annoyed and bothered. Facebook then decided to make those video ads not play the sound by default. When that happened, the effectiveness of video ads on Facebook dropped drastically, so they got cheaper as a result.

But the videos that became really effective were the ones where you could tell what was happening essentially without the sound. One of our most effective video ads at Paribus, which we ran very early when that was starting to happen, was one where Eric and I were dressed in banana costumes holding signs with text on them.

It’s a great silent video because you look at that image and think, “What are these people doing dressed in banana costumes?” You’re holding signs with text on them, so you can tell what’s happening without having to listen, because you can read. That ad became very effective and worked very well for 3 or 4 months, and then it stopped working.

That is very true in online advertising. It’s moving so quickly, and the platforms that you’re doing ads on top of are changing so quickly. Being at the forefront of what’s happening and how you can get alpha is super important. We want to hire people who are obsessed with and aware of the changes happening with those systems.

That’s also true in SEO. Google, every once in a while, will publish articles about how they’re changing the way that they prioritize SEO to, for example, reward websites that load incredibly fast or reward websites that are very mobile-friendly. They do that every couple of months. So being aware of what’s happening and moving very quickly is super important. Speed is super important.

So this is happening everywhere. There’s so much vying for our attention that I’m really curious what you’ve learned about getting people’s attention. What are the principles of getting attention? Something that comes to mind is our friend Scott Wu at Cognition and his team did this amazing launch video when Cognition first came out, and there really weren’t many launch videos at the time.

And so everyone watched it and had this incredible reach. Now, literally anything that gets $10,000 of funding has a launch video. There are 10 million of them, and as a result, I personally literally do not watch a single one, no matter how big the company is, because it's just this sea of slop of launch videos. I just don't care anymore. So I'm curious what you've learned about the principles for getting attention in the first place.

14. The Power of Differentiation

It's funny. I was re-listening to one of David Senra's episodes on Dyson recently. A lot of the same principles we try to apply to this are reflected in the way that Dyson ran his business, which is seeking differentiation for differentiation's sake. We are always looking for ways to be different. The very first way in which we've done that really well—and a lot of credit goes to Diego and our design team, and to how they think about design—is that, in the very early days, we were thinking about what the right color for Ramp should be.

We were working with brand partners on it, and I remember this color wheel that you look at, right? You see all these companies that we aspire to be like and where they are on the color wheel, and all the finance-related apps are somewhere in the blue or green, right? It's green for money; blue is trust. There was no one in yellow. The only thing in yellow was Snapchat, a consumer company.

The primary reason why we chose yellow was because it was different. That's it. You could have argued at the time—and certainly some people did—"If you go yellow, you're not going to get anyone's trust, and you want to start with things that people associate with trust." It was like, "No, we are going to change that. If we do that really well, it's going to pay dividends for a very long time." And I think it does. You see a very yellow ad or bus, and you assume it's Ramp, right? That is what brand ultimately is.

If you're watching a movie and you see a red can in the distance, you might not be able to read Coca-Cola, but you know it's a Coca-Cola can. That's very, very powerful. So I think one way to grab attention is to seek differentiation, and with enough repetition, eventually you're like, "Okay, I see the pattern here."

15. Recruiting for Spikiness

You're a man attracted to extremes and differentiation. Talk about that same concept in recruiting, and recruiting for what you would call spikiness.

Yeah, I love this framework of hiring for slope and spikiness, as opposed to, say, people who check the box on 10 different things. We've applied that since very, very early. Even at Paribus, I remember one of the early things was, "Well, we're a small company with very limited resources competing for talent with the Facebooks and Googles of the world. We can pay them less money. We have less of a brand, and probably, in many ways, less large-scale problems to work on." How do we really differentiate?

There were a couple of things. One is, "I'm going to look for very spiky people in areas where I have asymmetric information." We were recent college graduates, and in some way we knew a lot about the people who had gone to the schools we had gone to, or the schools we had experience with—namely, Harvard and MIT for Eric and me. Not only that, we knew about a lot of the hardest classes that students were taking. So we could go and look at, say, a freshman in college, the classes they're taking, and the level of extreme talent in one area, and recognize that very quickly.

So it was less about, "What is your total GPA and your total sum of experiences and other interviews you've done throughout your 4 years in college?" It was, "I know that in your first year of school, if you're taking that class and got a really good grade in that one class, it must mean that you are extremely talented at math or computer science or whatever it is." We were looking for these spikes. There were a couple of ways we were looking for extremes: we were looking for freshmen when other companies were trying to hire juniors, and we were looking for people who had perhaps taken and excelled in very specific classes.

In my case, having gone to RSI and knowing how hard it was to get into RSI and the level of talent at RSI, I was looking for programs like it that gave you an early signal that someone was very spiky, even before college in many ways. One of the people we hired very early on at Ramp was—I mean, was Calvin Lee, who had interned with us at Paribus in January for 1 month. Not a lot of companies offer 1-month internships. He had less than 1 year in college, but clearly, even then, looked incredibly spiky, right? He had left high school early to prepare for the Informatics Olympiad. He ended up finishing college in 2 1/2 years.

We met Calvin very early on and built a very strong relationship. By the time he was graduating, we were actually starting Ramp, and he was one of our very first hires. To this day, Calvin, I think, has his hands in so many different things at Ramp and has gone from being an engineer to being on the sales team for a bit to running our forward-deployed engineering organization. While he's incredibly spiky, he turned out to be also very versatile in the company and one of my favorite people to work with.

That pattern certainly extended to a lot of the ways we've done recruiting early on. When I look at someone's résumé, I don't have a checklist of 10 things I'm trying to check the box on. I'm generally looking for what they're telling me in their résumé: they're really good at brushing up on that topic. If this is a topic that I'm not an expert on and I interview them specifically on that one topic, you're telling me you're great at something, so I'm going to see how great you actually are. You better be a lot more knowledgeable about it than me after doing a couple of hours of research.

There are 2 very strong signals from this. One is: how good a judge are you of how good you are at that actual thing? You're saying you're great at, say, poker, for example. Are you a great poker player? How good are you actually? Are you a good judge of yourself, or are you aware of the spectrum of talent in that field?

And 2, how far have you been able to take that thing? I'm a lot more interested in essentially assembling the Avengers at the company, where everyone has a clear superpower, than in a lot of people who just check the box on 10 things. The more things you are looking to vet someone on, the more likely you are to get average people, essentially.

Another thing that you and I have talked a lot about is speed—just pure, raw speed—which has been a theme of our conversation today. It's probably the most important thing, especially for young companies. Maybe you develop more structural Visa-like moats over time, but to earn that right, you just need to go ridiculously fast in the early days and iterate really fast in all the ways that you're describing. If you were giving advice to companies on practical, tactical things they can do to make their business go faster, what are your favorite things?

16. The Tactics of Speed

You want to shorten the cycle as much as possible between an idea and putting the thing in front of a customer. There are so many ways to do that. You could simply focus on, "Great, I'm writing code. How long does it take to get to production?" Within that, there's, "How fast do your tests run? How quickly can you actually deploy?" and so on.

I'll share a story on that, which is quite funny. The first time we hired a product manager at Ramp was our head of product today, Jeff. He came into the organization with some experience being a PM at another organization, and he looked at the way we were prioritizing work and cutting up chunks of work. He was a little bit appalled that we were not sizing the different levels of effort for the different tasks.

A lot of companies will do this: "There are 10 things we want to do. This one is 5 points and will take 5 hours, and this one is 1 point and will take 1 hour," and whatever. He was freaking out that we had no sense of—or were not really measuring—how long we thought things would take. He was trying to introduce that, and I got freaked out. I was like, "Why are you doing this, Jeff?" He was like, "Well, so that we can know how fast we're actually moving." I was like, "Wait, you don't think we're moving fast enough?"

He was like, "No, no, I think we're moving incredibly fast—faster than any place I've seen. I just want to measure it." I believe that there's a little bit of a Shreddinger's principle there, where you can get a lot of precision on how long things take, or you can do them a lot faster. It's hard to get both, because if you start to put a lot of importance on measuring in advance how long you think things will take and estimating them very exactly, you end up rewarding and punishing people who make the right estimates. So you incentivize estimates that are longer than they should take so that they can hit those estimates.

So it’s a very simple tactical thing that you could do, but it’s hard because you need a natural ability to understand how quickly it is to actually develop things. It’s hard to do that without expertise in the thing that you’re building. It’s hard for non-engineers to know how long an engineering task can take if you’re really good at it. It’s hard for designers to know how long a design task should take, et cetera.

It’s about not following a lot of the processes that other companies follow, because very often process gets in the way. I think best-practice processes are a good way to move you toward average in a discipline if you feel like you’re below average. But often, some of the people who are most extreme in how fast they move, or on any dimension that you’re trying to measure, tend to do things in a very odd, nonstandard way.

What’s your commentary on the sort of base-level players and infrastructure in and around this business, where people have talked about Visa and Mastercard as the best business model of all time, or something like this? The introduction of stablecoins and what Stripe is doing there, and things that Visa or Mastercard might be trying to do themselves—what are the interesting shifting sands to you that might affect how you build the business?

What opportunities might become available that haven’t been available in a long time? The worst idea you could have had for the last 50 years is to try to beat Visa at its own game. The network effects are too strong. What shifting sands loosen some opportunity, in your perspective?

That’s an interesting one. I think a big misconception is that the reason payments are maybe more expensive than some merchants would like them to be online is because Visa takes such a big cut. That’s not true at all.

One of the reasons that card payments might be a little bit more expensive for merchants in the U.S. is that a lot of that expense comes in the form of rewards for consumers, and American consumers are very, very attached to their rewards. It’s going to be interesting to see in what areas people are willing to give up any of their rewards in order to get, I don’t know, a differentiated experience in some way, and for the merchants to get cheaper payments.

But the stablecoin promise as it stands today for merchants is one where payments are maybe faster and cheaper, but it’s still not very clear what it is for consumers, or the people paying. At the end of the day, if you want to buy something, you just care about the price, how quickly it’s going to ship to you, the quality, and things like that. Do you really care how you’re paying, or what is happening behind the scenes? Not really.

In a way, I think a lot of the shifting sands around the underlying technology through which money is moving are very irrelevant to the people making payments. But what may become interesting is if you believe in a world where the individuals themselves are less involved in making the payments and you have agents doing that on their behalf. It’s, “Okay, help me buy that thing.”

Those agents might not care about rewards as much as you do, or they may help you make more optimal decisions. You could see a world where agents are deciding to optimize the rails and pick different ways based on some different maximization function that’s not related to rewards. In other words, if the decision-makers are shifting, the path that they take to make the payment might shift.

So it is interesting. Stablecoins are certainly very interesting. It’s kind of crazy that payments today cannot settle on a weekend or outside of business hours in certain cases. There’s no reason why payments shouldn’t be settling live, 24/7, all the time, and be very cheap. I think that will change.

But, to be honest, from our perspective at Ramp, we’re in the business of optimizing and speeding up the workflows of our customers. In many ways, I couldn’t care less whether that runs on likely ACH rails, card rails, or stablecoins.

Yeah.

Exactly.

You’ll be the beneficiary of whatever positive change.

Exactly. It’s exciting.

If we did this again in 5 years—we have an every-5-year tradition—and at that next increment we had the benefit of telling the most exciting possible version of the story that happened between now, 2025, and 2030, what do you think that looks like for Ramp?

It’s going to be a pretty funny one, but my hope is that people don’t have to log into Ramp at all, basically, is the way to think about it. If you really obsess over minimizing the amount of time that things take, today you’re having to log into Ramp and it’s taking 5 seconds, then it’ll take 4, and eventually it’ll take 0, and you’ll have a lot of your finances that are essentially self-driving.

One of the analogies I like is a bit of what’s happening with cars. You’ve gone from very mechanical cars, where you have to do everything and fix everything, and then you have things like lane assist and park assist—early signs that the car can assist you and do a little bit more. We’re getting very close to the point where you could just—I mean, with likely Waymo, you could just sit in the back, press a button, and go from point A to point B.

I think something very similar is happening in many areas of business. The one we’re focused on is all the workflows and decisions that happen before money is moved and after money is moved, and how you optimize these decisions over time. There’s this endless cycle and loop: You spend on something, something happens in your business, and if it’s good, great, you do more of it; if it’s bad, maybe you should minimize that.

You end up having that infinite cycle of making better decisions with your money and not wasting a lot of time in bureaucracy. I would love Ramp to be as self-driving as possible, and for people not to have to log into Ramp at all for that vision to come to reality.

Is most of it the infusion—I’ll call it—of intelligence, you know, AI basically building the chain as you’ve described, doing so many times? As an engineer, you’re always thinking in terms of what the increments are here, and then just attacking each one with intelligence, for lack of a better term.

I think that’s right. I would also add that there are indirect benefits of the models getting better that we benefit from ourselves as well, and the accumulation of more artifacts and data about how customers are using our product every day and for what reasons.

This allows us to infer a lot of what their intent is from their actions, the way they decide to fill out forms, and what they approve and don’t approve. The more our customers are using the product and deriving positive outcomes, the more we can learn.

As those models get better at reasoning over more complex tasks, we benefit from it. It’s a very exciting place to be in.

Can you tell the story about constraints that led you to become a good manager?

Oh, God. Yeah. There were some funny ones, but the most on-the-nose one was in the early days of Paribus. Eric and I were really the only 2 people working on Paribus. Eric, while having studied a little bit of computer science, wasn’t really a software engineer himself, so 100% of the engineering capability of the company was just me.

Then I went on a random skiing trip one day and, due to unfortunate circumstances, came back with a broken arm. I remember Eric looking at me and having that reaction like, “Oh, great. We’re now—what the hell are we going to do?”

Luckily, we had started working with a few junior engineers around that time. That was the first time I was forced to try to get better at delegating, managing, explaining concepts, explaining architecture, and focusing a bit less on the direct output that I could have myself. I had to focus a little bit more on how I could maximize the sum total of the output of the team as a whole.

It was very constraining to do that without an arm. I was trying to type as much as I could with my left arm, but I needed to be as specific as I could with as few words as possible, drawing diagrams and writing down some concepts. That was a very funny experience where I had to very quickly figure out how to delegate.

Well, back to our book on the story of Karim’s entrepreneurship journey. We’re just at a mile marker now. You’re only 6 years into Ramp, which is kind of crazy to imagine, given how fast you guys have scaled.

If I think back—maybe I’ll go all the way back to the start of Paribus and encompass the entirety of company-building that you’ve had so far, so a bit longer—how have your views on company-building, leadership, and management most changed across that period of time?

I used to go into challenges with the assumption that there was a reward at the end, that the reward would feel great, and that that was the intent and goal. I think the more challenges we’ve gone through and conquered or surpassed, the more I realize that the reward is just the journey, to be honest.

So, it’s made me a lot more intentional about doing the things that will help me enjoy the journey over time and enjoy all the challenges that come along the way, because the reward for solving challenges is just more complicated challenges over time. You might as well put yourself in a position where you’re enjoying these challenges as much as possible.

For me in particular, I think that has to do, more than anything else, with the people I’m doing it with. I still meet a lot of young, very talented designers, engineers, and builders in general, and they always have different answers to questions like, “What are you excited about?” or “What do you want to do?” Some people talk about the complexity of the technical challenge, and some talk about the mission itself.

There are different ways to answer that question, but the one I continue to go back to is really about the people that I work with. I feel very lucky that Ramp is such a multifaceted company in some ways, where we have to not only be really good at the engineering parts of it, but also the design, marketing, sales, risk, capital markets, and fundraising.

You get to work, as a result, with very spiky people in very different areas who are brilliant, and I love learning from them consistently. I want to put together great teams, solve that challenge, and win—and, more than anything, build the team that will help us consistently win forever, because I would like to build something that hopefully outlives us.

I would love for Ramp to be the last job that they ever have to apply for.

And that’s been very true for a lot of people. That can mean a lot of things, right? It can mean that people left and right will just try to approach them because they’ve been at Ramp. I think it’s very easy to want to try to avoid that by hiring people who are purely incredibly loyal, and I don’t think that’s a good idea.

I see it as a sign that we’re hiring the right people if we keep doing that. I’m excited to see the sum total of the amazing things that the people who have ever set foot at Ramp or worked with us will do over their lifetimes. I’m incredibly in awe of the talent that we have.

Even this past summer, one of our interns, while he was interning at the company, won a gold medal at the International Physics Olympiad. It’s incredible what some of the people at Ramp have been able to achieve. So, I’m very proud of that talent.

I think you know my traditional closing question. What’s the kindest thing that anyone’s ever done for you?

The thing that’s been most impactful on the rest of my life probably happened early on, when I was going through the Research Science Institute at MIT. I was 16, it was my first time in the U.S., and I was away from my family when war broke out in Lebanon. The airport was closed, and I had become really close with my best friend today, Zach, whom I had met at that camp.

We were together at the Research Science Institute, and he immediately told me, “Don’t worry about it at all. The camp is ending in a week. You can just come with me and be in New York. My family is amazing. I already told them about you. They’re very excited to meet you. This is going to be great.”

Little did I know—and I heard this later, a couple of years later, from Zach’s mom—that he had called his mom and said, “Mom, don’t ask any questions. My friend Karim is going to come live in New York with us as soon as the camp is done.” I think his mom couldn’t even be in New York around that time, and Zach had something else to do.

The day I met his mom, she welcomed me with open arms and told me that she would make sure I had a great experience staying with them. I showed up at their house in the city, and I remember being amazed at the door. They had hidden the key for me because they couldn’t be there.

I opened the door and went into the kitchen, and there were meals labeled for every day of the week. There was pocket money on the side in case I needed it for transportation, and a list with all the numbers I could call if I needed any help. I thought, “Wow, this is amazing. I don’t even know these people, and they’re already treating me like family.”

To this day, I think of Zach and his family as my second family in the U.S. We spend a lot of the holidays together, and they’ve really become part of my family in many ways. The fact that they were willing and able to do this very quickly for someone who was a stranger is, in retrospect, kind of crazy.

Pretty amazing story about a person who may be, or probably is, the best investor of his generation. Pretty wild, amazing closing story. Karim, thanks so much for your time.

Thank you, Patrick. It’s awesome.