Ramp超高速增长的剖面|Karim Atiyeh访谈
- Karim Atiyeh对AI的核心判断是:大多数公司仍卡在第一阶段——用LLM把同样的工作做得快一点;Ramp正在进入第二阶段,即「你的代码就是LLM加指令和一个无限循环」。 已经落地的案例是一个接入日历和邮件的政策代理,全天候执行费用政策,掌握的「交易上下文比今天审查这些交易的大多数人都更多」;Ramp如今还在从客户行为中推断其未被记录的财务政策,以驱动下一代代理。
- 从TPV转向SaaS是数学逼出来的,而不是追逐潮流:随着企业复杂度上升,卡片消费会触顶,因此「我们捕获价值的机制……对大型企业失效了」。 这场内部曾担心的转型,转而通过软件收费加速了增长——付费产品让销售愿意主动推销,也让客户提出更多需求。至于代理该如何定价,他仍没有答案,并明确不认可按时间或token收费,因为这会「激励工程团队不要尽可能提高效率」。
- 多头逻辑的增长空间在于:Ramp在5-6年内突破10亿美元收入,部分细分市场转化率超过50%,但目前仍只占企业卡市场「不到2%」。 公司的目标也从卡片扩展到资金流动前后的每一个工作流,最终实现客户无需登录的「自动驾驶」财务。
- 反MX的切入点具有结构性:传统企业软件围绕决策者设计,让「公司里的其他人每天都遭受一点小小的纸割伤」;Ramp则反转了这一模式,也反转了卡片经济学——帮助客户少花钱,而不是用奖励诱导消费,押注钱包份额会随之而来。
- 值得借鉴的工程准则,是沿着「把它做成永远不出问题」(资金流转)与「可预测地出问题、快速修复」(其他一切)这条边界拆分产品。 「确保没有bug的一个好办法是什么?什么都别发布……如果你追求的是好的结果和大的影响,就应该让系统不断出问题。」
- 对于支付轨道和稳定币,他刻意保持中立:卡片成本很大一部分来自消费者奖励,而不只是Visa的分成;稳定币对消费者的价值主张也并不清晰,但如果代理成为支付决策者,支付轨道可能改变。 「至于最终运行在可能是ACH的轨道、卡片轨道还是稳定币上,我根本不在乎」——无论哪种方案胜出,Ramp都能获益。
- 给投资人的公司建设信号是:最好的买入时点,可能就在有人试图杀死一家公司之后——「只要你做的是正确的事,人们就会多次试图杀死你」;2022/23年的折价融资也被重新定义为纯粹的价格发现:「融资这件事本身,只是把价格公开出来」。
1. 突破10亿美元仍是挑战者——AI真正的阶段跃迁是「你的代码就是LLM」
- Patrick的框架是:Ramp是罕见样本——5-6年就实现10亿美元以上收入,成为历史上增长最快的公司之一,却仍以第一天的状态对抗MX等 incumbent。Karim坦言:「我到现在还没有真正内化这件事。」Ramp保持速度的机制,是把每个问题拆给小团队,并赋予团队「对所要解决的问题拥有完全自主权」。
- 他把AI应用分成两类:第一阶段是用LLM更快地完成旧工作——比如从ChatGPT复制粘贴代码,或者进一步使用「a Cognition或Cursor」这样的代理。Ramp正在进入的阶段是:「现在你的代码就是LLM。你的代码就是LLM加指令和一个无限循环」——LLM本身被编程成产品,而不是辅助产品开发的工具。
- 他承认公开证据并不一致——媒体每隔几周就在「毫无收益」和「影响巨大」之间摇摆——但他明确表示,「采用这项技术的影响是变革性的」;大多数公司只是还停留在早期阶段。
2. 政策代理:LLM成为产品的具体样本
- 他首先举的例子是:每家公司都有差旅与费用政策——「一份用来驱动行为的文件」——但执行依赖人工、发生在事后,还伴随着无休止的来回沟通。Ramp的政策代理接入日历和邮件,了解公司政策,并进行「全天候实时执行」,掌握的「交易上下文比今天审查这些交易的大多数人都更多」。
- 更具复利效应的是:随着时间推移,代理会建议如何把政策写得更清楚——让它成为「一份能够随时间演化、持续指导代理的活生生的文本文件」。
- 更大的业务机会在于:围绕一张发票,大多数企业动作——反欺诈检查、核对订购与收货、验证价格——「根本没有写在任何地方」。Ramp正在规模化地从客户行为中推断这些隐性政策,「我们推断出的许多政策,正在驱动我们构建的下一代代理」。
3. Ramp为何能抢走客户:纸割伤与消费级设计
- Patrick转述一场Visa会议上的信息:「在场所有人都在抱怨Ramp抢走了他们的客户。」Karim把原因追溯到最初的切入点——上一代企业软件围绕决策者构建:「你解决了一个人的问题,却让公司里的其他人每天都遭受一点小小的纸割伤。」Ramp想要的是「Instagram式的用户体验,但应用在企业软件上」。
- 对所有想做消费级B2B产品的人,他给出的可复制方法是审视每一次客户互动:「我能不能自己找到这个问题的答案,而不是去问客户?如果我要客户做X,为什么不能由我替他们完成?」自己重试失败的支付,把表单直接放进邮件里。设计上的执着最终变成「执着于尽量减少人们在我们App里花费的时间」。
4. 永不满足:为什么他在130亿美元估值当天大发雷霆
- David通过Patrick讲述:在宣布130亿美元估值的当天,Karim一整天都在对着产品问题发火。他的辩护是分析性的,而非情绪化:「本季度的结果几个月前就已经确定了……我总觉得庆祝滞后指标有点奇怪」——庆祝可能让团队误以为今天的问题不存在,进而「把接下来的6个月搞砸」。
- 更深层的驱动力来自美国医疗和教育支出的长期上升:结果或许有所改善,但远没有支出增幅所应带来的那么多——「钱只是被浪费在行政垃圾上……没有用来给医生提供更多培训……而是花在大量不改变结果的官僚流程上。」按他的说法,Ramp的使命正是攻击这类浪费。
- 另一个更让人意外的原因是:「如果一切都很好,我们真的没有什么问题,我都不知道该拿自己怎么办……好在这份工作永远做不完。」
5. 文化是相互问责——以及唯一的面试问题
- Patrick提供的一个细节是:一家向Ramp销售的创始公司被告知,交易不会完成,「直到你确认自己在公司业务中已经是Ramp客户」。Karim的解释是,Ramp依靠的是「彼此之间的相互问责,而不是自上而下的管理」——销售关心产品,市场关心财务,因此每个人都参与销售,也都会向产品建设者提供建议。
- 如果必须用一句话概括整场访谈,他会问:「如果这个人正在创办一家公司……我会加入他,还是会和他一起创办公司?」因为「公司就是一群人一起解决问题,一个接一个,而且问题会越来越难、越来越大——关键在于你能坚持多久,以及能承受多大的压力」。
6. 从贝鲁特到MIT:在无常中长大
- 故事从贝鲁特开始:他出生于「89、90年」,正值内战结束前后,在一代被战争「留下创伤……所有人都像是生活在紧绷状态」的人中长大。战争留下的底色是:「一切都非常短暂,可能很快消失」的感觉弥漫在空气里——尽力而为,拿到签证,离开这里。
- 约16岁时,他在2006年进入MIT的Research Science Institute(RSI),起因是他着迷地记录科学杂志上的每一个发现,发现它们都来自MIT。他原本选择计算机科学,以为自己会去「学习」这门学科,后来才发现学校要求他「做研究」,只能在压力下自学。
- 他在Kendall地铁站附近一家名为Virage的初创公司完成RSI项目:把地方电视新闻流转换成文本,再用Markoff链分类——「本质上就是LLM所依赖的祖先」——并训练这些模型以提高效率。按他的说法,项目最大的长期产出是朋友,其中一些至今仍是他最好的朋友。
7. Paribus:用Excel宏武装叛军
- 故事起点是:Eric——也是Ramp的联合创始人——发现自己买机票时支付的价格与另一个人不同,恰逢零售商开始招聘数据团队做动态定价。Karim当时是一个不满现状的顾问,已经在偷偷把软件塞进手工项目里;咨询行业按「参与项目的人数和投入时间」定价,实际上消灭了自动化激励。他把v1做成「Excel里的VBA宏」,每天检查一组SKU在Amazon上的价格。
- 关键洞察是,价格变化很快,而且2014年追踪的第一个月内还在加速;每家零售商都提供价格保护,但都「赌没人真的会检查」。Paribus把检查自动化:零售商有「成群的数据科学家」做价格歧视,「而我们要武装叛军」。
- 规模与脆弱性同时上升:一年内约100万用户,产品建立在这样的零售商之上——「第一,他们不希望我们在那里;第二,他们一直在改页面;第三,他们有很强的动机让事情变得更难」。Amazon后来完全停止发送逐项商品收据。某个阶段,Paribus成了「美国最大的抓取业务之一」,每天处理数十亿封邮件、数千万张收据。
8. 工程准则:可预测地出问题,并沿这条线拆分产品
- Paribus带来的教训是:「你永远不可能构建完美系统。更好的做法是快速构建一个会以非常可预测的方式出问题、同时能够极快恢复的系统」——这与大公司追求永不出错的工程理念正相反。
- 在Ramp,这最终变成组织设计决策:凡是触及资金流转和风险的部分,都按永不出错的标准处理,「假设你不需要在上面进行太多创新」;其他部分——收据匹配、表单优化——则快速迭代、允许出错。「Ramp有些小部分可能每天出问题10次,我们每天修复20次,但没人真正注意到。」
- 对小型初创公司而言,这种方式反而更容易建立信任:「如果东西出了问题,而你又能非常快地修好,那是建立信誉更好的方式。」他的原则是:「确保没有bug的一个好办法是什么?什么都别发布。连代码都别写……如果你追求的是好的结果和大的影响,就应该让系统不断出问题。」
9. 律师函、Amazon电话,以及为什么被围剿是买入信号
- 最疯狂的一幕是:一支只有12-13名应届毕业生的团队,开始Google那些给他们发律师函的几千人规模律所。最精彩的一封来自Amazon:Amazon指控Paribus危害账户安全,但产品是在AWS上、并在AWS架构师帮助下构建的。团队回应:「我们很乐意和帮助我们构建这套系统的那支团队通话。」随后接到一个电话,对方似乎是Andy Jassy本人或其团队中的高级负责人;通话结束后,AWS方面显然很兴奋,问题也明确属于Amazon零售业务。
- Patrick的投资假设是:比产品市场契合更好的信号,是第一次有人试图杀死你,而你活了下来。Karim回应:「完全正确。只要你做的是正确的事,人们就会多次试图杀死你。」他的生存机制是:「我从不把我们可能被杀死视为一种选项」——公司之所以会死,是因为「花了太多时间思考和讨论,却没有花足够时间行动」。
10. Capital One:意外出售,并发现卡片业务模式
- 他们当时并不是想卖公司,而是在寻找分发渠道:「还有谁比信用卡公司更清楚,谁刚刚在Amazon或Walmart购物?」与Capital One的合作谈判由此开始。Capital One希望通过产品差异化竞争,因为「消费卡产品仍然只是同一种产品的不同营销版本」;恰逢法律风暴要求Paribus拥有「更多火力」,合作最终转成了收购。
- 交易过程中最关键的学习,是卡片业务本身的模式:「没人需要签合同……用得越多,你赚的收入越多,而你只需要专注于把产品做到尽可能好。」Paribus后来变成Capital One Shopping;两年后,Karim又开始蠢蠢欲动。
- Ramp的创立逻辑直接延续下来:「面向企业的Paribus」——帮企业省钱;后来变成「省时间和钱」,因为「企业往往浪费的时间比浪费的钱多得多」。卡片和Paribus一样,主要是感知机制:了解企业把钱花在哪里,就能知道它们在哪里浪费。此后,「我们的雄心范围」从交易本身扩展到交易之前的一切——采购——以及交易之后的一切——会计和报告。
11. 「这不比MX差」——上线、Fortnite与投资人打法
- 最坦率的起步话术原文是:「这不是‘这太棒了,会改变你的人生’,而是‘这不比MX差,你不妨试试看’……这是个糟糕透顶的推销。」早期客户是YC同批创业者和他的兄弟——「与其说是客户,不如说是合作伙伴」。最初真正的差异化,是保护隐私的邮件解析:把收据与卡片交易匹配起来,并把「MCDX」这类商户乱码转换成「McDonald's」。
- 他们原本不想融资——两位创始人都是二次创业,手头有资金,而应收账款才是真正的资金需求。后来发生了Fortnite故事:他和弟弟的朋友们一起玩游戏,其中一人后来很可能是Delian Asparouhov,当时似乎正处于加入Founders Fund前的garden leave。「我想我不玩Fortnite了……Eric和我要开始另一家公司了。」这句话最终把他带到了很可能是Keith Rabois的人面前——后者拥有Square/PayPal履历,「非常适合理解我们究竟想做什么」。他们想要的更多是建议,而不是钱;这大概也是认识投资人的最佳方式。
- 此后他的投资哲学是:「投资人就是用资本付费的员工」——「你无法在公开市场上买Ramp股票……这就是你获得Ramp股权的两种方式」。因此要让投资人加入团队,持续向他们提供信息,并让有热情的基金在多轮融资中逐步建立仓位,「可能所有人都参与了多轮融资」。
- 最难的一轮发生在2022年底至2023年前后:难点不是融不到钱,而是很难证明融资的必要性——「我们其实不需要现金,估值又跌了,那到底有什么意义?」他的结论是:「融资这件事本身,只是把价格公开出来……它就是一个价格发现机制。」设定检查点,从这个点继续建设;「我们从来不是在每一轮都试图把估值最大化」。
12. 卡片经济学在规模化时失效——SaaS转型与代理定价难题
- 一个典型的land-and-expand案例是一家以所有事情都自己构建而闻名的航空航天公司:最初只采用卡片和API,「其他软件我们都想自己做」;6个月后采用AP自动化,随后又不断扩展,直到第2.5-3年左右,这种扩张模式「真正开始成形」。
- 纯TPV模式之所以必须结束,是因为Ramp希望客户少花钱——「帮助客户省钱的最佳方式,是让他们不要进行本来就不该发生的交易,而不是给他们积分」;但卡片消费「不会随着企业复杂度线性增长」。大型公司会通过账单支付和采购系统分流支出,因此「我们捕获价值的机制……对大型企业失效了」。
- 这场曾被担心会伤害转化率的转型,最终带来双重收益:软件收费「不仅没有伤害转化率,在很多方面反而加速了增长」;它激励销售主动推销产品,也让客户「更有要求、响应更积极」,形成免费产品永远无法产生的「市场反馈信号」。
- 仍未解决的问题是代理定价。他担心按代理使用时间或token收费的模式,会「激励工程团队不要尽可能提高AI使用效率……所以我不太喜欢这种模式。我还不太确定它最终会是什么样」。
13. 技术创始人看到汽车,其他人只会要求更快的马
- 他认为技术型建设者在这个时代胜出的原因是:客户通常只会要求「这里再加一个小组件、那里再加一个按钮」——这是福特问题;而「提出这项技术的人……能从产品角度看到更多可能性」,往往胜过领域专家。
- 第二个支点是:「没有领域专业知识与拥有领域专业知识之间的差距,从未像现在这么小。」他的玩笑准确概括了这一点:「我比过去任何时候都更像一个好医生,但我不是医生;我比过去任何时候都更像一个好律师,但我不是律师。」如今,没有采购或会计经验的工程师也能构建这些工作流的未来。
14. CTO接管市场:修系统,而不是改创意
- 触发点是对领先指标的焦虑,尽管「所有滞后指标都表现得非常好」:许多细分市场的转化率超过50%,变现能力也在改善,但两者都有硬上限;与此同时,线索生成正在放缓,而Ramp仍然只占「企业卡市场不到2%」。「转化率不可能好于100%。」
- 他强行改变了团队的思考方式:播客广告效果差时,过去的结论是「播客对我们不起作用」;他的结论是:「不,它必须有效,只是我们还没找到让它有效的方法。你找错了人,或者用了错误的形式。」同样的方法被用于直邮、付费投放、品牌和产品发布——把「Elon算法」应用于整个产出系统。
- 速度问题也被修复:从创意简报到品牌团队再到发布,过去任何事情至少需要2周;他重建流程,让创意从产生到面向世界只需「10分钟,而不是2周」。「我并不是带着‘我的创意更好’的想法参与其中……我只是想尽快把他们的想法放到世界面前」,从而增加尝试次数,也提高每次尝试的风险承受度。
- 按他的说法,纽约一块广告牌的成本约为10万美元,第二块要20万美元——「但修改已有广告牌只需1000美元」。「一块广告牌一周变7次,总计10.7万美元」,比两块静态广告牌花20万美元更能有效传递信息。
15. 注意力存在阿尔法衰减;持久差异化才是正解
- Paribus在付费媒体上的教训是:2014-15年前后,Facebook让视频广告默认静音播放,广告效果崩塌、价格变便宜,赢家变成了即使没有声音也能看懂的视频。他们的答案是:让Eric和Karim穿着香蕉服、手举文字牌。「效果非常好,持续了3-4个月,然后就失效了。」所有渠道优势都会衰减,因此要招聘那些痴迷于平台变化的人;SEO奖励机制不断变化,逻辑也一样。「速度非常重要。」
- 谈到品牌,他引用了Senra关于Dyson的一期节目——「为了差异化而寻求差异化」。每款金融App都停留在色轮的蓝色或绿色区域——绿色代表金钱,蓝色代表信任;唯一使用黄色的是Snapchat。「我们选择黄色的首要原因就是它不同。仅此而已。」回报来自可口可乐式的识别逻辑:「你远远看到一个红色罐子……就知道那是可口可乐」;如今,一张非常黄的广告或一辆黄色公交车也会被读作Ramp。Patrick的相邻抱怨则是反面教材:发布视频从Cognition的突破性作品,变成了没人看的「一片垃圾海」。
16. 招聘复仇者联盟:尖峰能力优先,速度优先于估算
- Paribus的招聘优势是「非对称信息」:他们无法给出高于Google的薪酬,于是寻找自己认识的、正在修读哈佛或MIT最难课程的大一新生——「第一年,如果你正在修那门课,而且成绩很好,那你就极其有才华」。代表人物是Calvin Lee:从一个月的1月实习中被招入,提前离开高中参加信息学奥赛,2.5年完成大学,后来在Ramp横跨工程、销售和前线部署工程。
- 他的面试方法不是10项清单,而是从简历声称候选人最擅长的事情入手,花几小时做研究,然后现场验证。重点看两个信号:「你有多会判断自己的能力」,以及这项技能究竟能延伸到多远。「你想考察一个人的事情越多,就越可能招到普通人。」他想要的是「复仇者联盟」——每个人都有清晰的超能力。
- Jeff的故事体现了他的速度原则:Jeff是Ramp的第一位产品经理,曾对团队没人用story point估算任务感到「震惊」。Karim提出「Shreddinger的估算原则」:「你可以非常精确地估算事情要花多久,也可以非常快地完成事情,但很难两者兼得」,因为奖励准确估算会激励人们把时间估得更宽。更大的判断是:「最佳实践流程是把你带向平均水平的好方法」;最快的人往往用「非常奇怪、非常不标准的方式」做事。
17. 支付轨道不重要,自动驾驶财务才重要——回报就是旅程
- 关于支付基础设施,常见误解是Visa的分成让卡片支付变贵;实际上,「大量成本以奖励的形式存在」,而美国消费者对此高度依赖。稳定币向商户承诺更快、更便宜,但「对消费者来说,它究竟有什么用仍然不清晰」。真正有意思的变化是:如果由代理完成支付,它们可能不在乎奖励,也可能按照另一套最大化目标「优化支付轨道」。他的立场是:「至于最终运行在可能是ACH的轨道、卡片轨道还是稳定币上,我根本不在乎」——无论哪种方案胜出,Ramp都能受益;而且在某些情况下,支付无法在周末或营业时间之外结算,「确实有点疯狂」。
- 他对2030年的愿景是:「我希望人们根本不需要登录Ramp」——就像汽车从纯机械驾驶,发展到车道辅助,再到坐在后排;财务也会实现自动驾驶。推动飞轮的是更好的模型,以及不断积累的行为数据:「我们可以从他们的行动和填写表单的方式中推断出大量意图」。
- 回看Paribus和Ramp,他过去总以为挑战结束后会有一份让人感觉很棒的奖励;现在的结论是:「奖励就是旅程……解决挑战的奖励,只是随着时间推移出现更复杂的挑战。」因此,应优先选择和谁一起解决问题。他最自豪的是人才——一名实习生今年夏天赢得国际物理奥赛金牌——以及人才的离开:「我希望Ramp成为他们今后唯一需要申请的工作」,即使这意味着所有人都会试图挖走他们。最后还有一个起源故事:他16岁时,黎巴嫩在RSI期间爆发战争;朋友Zach的家人收留了一个陌生人,为他标记餐食、准备零花钱、藏好钥匙——「他们已经把我当成家人了」。
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.