Velocity over everything：Ramp 如何成为史上增长最快的 SaaS 公司

嘉宾：Jeff Charles ｜ Ramp 产品负责人｜领域：产品增长与团队管理

背景与引子

2020年，新冠疫情肆虐全球。大多数公司忙着裁员求生，而一家名为 Ramp 的金融科技公司却在悄然崛起。三年时间，他们从 10 个人的小团队，发展成为史上增长最快的 SaaS 企业——两年内 ARR 突破 1 亿美元，员工却不到 50 人。更令人震惊的是，他们用 3 个工程师、1 个设计师、1 个产品经理，三个月就做出了一个年交易额数十亿美元的产品。

这不是天方夜谭，这是真实发生在 Ramp 的故事。

最近，我与 Ramp 产品负责人 Jeff Charles 进行了一场深度对话，试图揭开这家神秘公司高速增长的密码。在对话中，Jeff 分享了他们如何用”Velocity（速度）“重构产品开发的一切——从招聘理念、团队组织、目标设定，到文化塑造和避免 burnout。这不是一篇关于某个技巧或工具的文章，而是一次关于如何从根本上重构团队运作方式的深度复盘。

如果你正在为团队效率低下而焦虑，如果你想知道如何让产品团队真正释放生产力，如果你想在不确定性中找到增长的确定性——这篇文章，值得你认真读一遍。

一、嘉宾是谁

Jeff Charles 是 Ramp 的产品负责人，在加入公司时，整个产品团队只有约 10 个人，其中 8 名工程师。在他的领导下，Ramp 完成了看似不可能的任务：在极短时间内先后推出了与 MX（上市公司）和 Expensify（上市公司）竞争的产品，并在不到两年内将 ARR 做到了 1 亿美元。

Jeff 并不是一个典型的”硅谷产品人”。他经历过咨询行业，做过解决方案分析师，亲眼见证过大型银行复杂的 IT 系统如何拖累业务。这种经历让他对”效率”有着近乎偏执的追求，也让他成为 Ramp 这台”速度机器”最合适的掌舵人。

他有一个著名的观点：任何用于计划的时间，都是失去的动手时间。在这次对话中，他会告诉你这背后的完整逻辑。

二、核心观点 TOP10

速度就是一切——速度是 Ramp 设计产品开发流程的核心，也是他们招聘、晋升和决策的最高准则。
单线程团队——每个关键项目只分配一个明确的目标，用最少的资源、最短的时间，全力以赴完成一件事。
隔离与保护——用”保护层”让核心团队远离混乱，不要告诉他们其他团队在做什么，直到他们找到产品市场匹配。
赋能而非微观管理——给出目标和背景，让最接近问题的人自己找到解决方案，这才能真正实现规模化。
宏大目标驱动团队——用市场对标物和设计愿景双重激励团队，明确告诉他们”我们要打败谁”比”我们要做什么”更重要。
质量随速度提升——反直觉的是，高速度反而带来高质量，因为你能快速迭代、快速修复、快速验证。
支持团队汇报给产品——每个客服工单都是产品的失败。让支持团队汇报给产品负责人，从根本上改变团队对质量的关注。
从第一性原理出发——不要模式匹配过去的经验，回到问题的根本，重新思考”应该怎么做”。
写作是最好的思考工具——在动手之前，先关掉电脑，拿出一张纸，把问题写在最上面，然后思考。
速度需要天才的支撑——Ramp 的速度背后，是 A 级工程和设计人才，他们站在天才的肩膀上。

三、关键洞察

洞察一：高速度不会导致低质量，反而会提升质量

这可能是最反直觉的发现。大多数人认为，快就会糙，慢才能精细。但 Jeff 的实际经验是：当你有了快速迭代的能力，你会更愿意尝试、更快验证、更快修正。一个需要等待两个月才能发布的团队，会倾向于把功能做得很”完整”，而一个每周都能发布的团队，反而会把功能拆小，快速获得反馈。Jeff 与 Nicole Forsgren（研发效能领域的权威专家）交流后发现，数据完全支持这个结论：速度越快的团队，质量指标往往越高。

洞察二：支持团队应该汇报给产品负责人

Ramp 有一个非常独特的设计：客户支持团队直接汇报给 Jeff 这个产品负责人。他们的核心理念是：每一个支持工单都是产品的失败。如果产品完美运行，没有人会需要联系客服。这个逻辑改变了整个团队的关注点——支持团队不再只是”解决问题”，而是”帮助产品团队找到真正的问题”。结果令人震惊：拥有超过 40 万用户的平台，支持团队却不到 30 人。这种比例在行业内几乎是不可想象的。

洞察三：CEO 的职责是设定愿景，而不是决定路线图

Jeff 提到，Ramp 成功的关键之一，是 CEO 对产品的”不干涉”——他设定了愿景（帮助企业节省开支），但在具体如何实现这件事上，他完全信任工程和产品团队。这是一个说起来容易、做起来极难的文化选择。Jeff 见过太多公司，CEO 嘴上说”我信任团队”，但每个产品细节都要插一脚。这不是信任，这是控制。真正的信任，是允许团队用你认为”不够好”的方式达到目标。

洞察四：把 PM 的工作分散到整个团队

Ramp 只有 13 个 PM，却有超过 100 名工程师。Jeff 的解法不是让每个 PM 变成”超级 PM”，而是把 PM 的职责分散到整个团队——让设计师学会思考优先级，让工程师能够自己拆解任务、自己创建工单、自己推动项目。PM 的核心角色变成了：建立团队文化、保持团队专注、保护团队不受干扰、成为团队与外部的单一联络点。这种重新定义，让 PM 从”执行者”变成了真正的”赋能者”。

洞察五：招聘看的是”渴望”而不是”经验”

Jeff 在面试中最常问的问题是：你做过的最难的一件事是什么？他不是在考察候选人的成就高度，而是在考察他们如何定义”难”、如何面对”难”、如何从”难”中走出来。对于 Ramp 这样的公司，他需要的是那些”渴望胜利”的人——那些因为公司变慢、变官僚而感到不适，想要回到”建造和发布”状态的人。经验反而是次要的，因为 Ramp 的业务足够独特，任何过往经验都需要被重新校准。

四、精彩金句

“我们从不写工单。合同就是愿景和优先级，剩下的全部交给工程团队。”

这句话揭示了 Ramp 真正的赋能哲学。当工程师不需要等待 PM 创建工单才能开始工作，他们实际上能够移动得更快。PM 的合同是方向，工程师的执行是自由。

“任何用于计划的时间，都是失去的动手时间。”

Jeff 用这句话概括了 Ramp 的时间观。但这不是让你放弃思考，而是在说：不要把”思考”伪装成”计划”。真正的思考发生在纸上，而不是会议里。

“每一个支持工单都是产品的失败。”

这不是责备，而是一种根本性的认知重构。当支持团队直属产品负责人，当这个信念渗透到每个团队成员的日常工作中，质量就不再是一个指标，而是一种本能。

“我的工作就是不断重复。”

Jeff 说，当一个好领导本质上是”首席复读官”，不断重复战略、愿景、背景。他的职责不是创造新想法，而是确保团队记得那些已经对齐过的方向。

“加入 Ramp，就意味着签了一份隐性合同：我们优先考虑速度，而不是其他一切。”

Jeff 在新员工入职时就会说清楚：这里会有点混乱，我们会发布一些不完美的产品，我们不会为你准备好所有培训。这是透明，也是筛选。

五、实战案例

案例一：3个月做出 MX 竞品

当 Jeff 加入 Ramp 时，公司只有约 10 个人，8 名工程师。3 个月后，他们推出了与 MX 竞争的竞品。6 个月后，他们又推出了与 Expensify 竞争的竞品。这两个产品都是上市公司，市值数十亿美元。Ramp 没有复杂的审批流程，没有庞大的团队，只有单线程的目标、极小的团队、和极度清晰的授权。

案例二：Accounts Payable 的诞生

当 Ramp 决定进入应付账款（Accounts Payable）领域时，他们组建了一支超级小团队：3 名工程师、1 名设计师、1 名 PM。他们给出的目标也很简单：做出一个竞品来。3 个月后，这个产品上线了，今天每年的交易额已达数十亿美元。Jeff 强调，关键不是团队有多强，而是他们”不被干扰”——直到产品找到早期吸引力，他们不会告诉全公司这个项目的存在。

案例三：支持团队的结构重塑

Ramp 决定重新思考支持团队。传统做法是招聘擅长”处理工单”的人，然后衡量他们处理了多少工单。Jeff 的团队从第一性原理出发问了一个不同的问题：什么样的支持团队能让产品变得更好？他们招聘了不同类型的人——那些真正想要”减少工单数量”而不是”处理更多工单”的人。结果是一个极小但极其高效的支持团队，成为产品迭代的重要输入来源。

六、行动建议

建议一：给你的团队一个”单线程”任务

为什么要做：多任务切换是效率的最大杀手。当你同时推进 5 个项目，你的团队实际上在以 20% 的效率工作。

如何开始：选择你们最重要的一个项目，把团队中的其他干扰全部移除。告诉他们：“接下来一个月，这就是你们的唯一目标。“清除他们路上的每一个障碍。

能得到什么：一个快速验证的原型，或者一个真实的市场反馈。这比同时推进 5 个半成品有价值 100 倍。

建议二：建立”保护层”机制

为什么要做：每个团队都需要专注，但每个公司都有无尽的会议、汇报、临时需求。如果没有人保护团队，他们的时间会被一点点蚕食。

如何开始：指定”产品运营”角色来处理项目管理、工单管理、发布管理。指定”生产工程师”来处理 bug 和线上问题。让 PM 只负责最重要的事：方向和决策。

能得到什么：PM 从杂务中解放出来，有时间真正思考战略。工程师从打断中解放出来，有机会进入心流状态。

建议三：用”原型”而非”文档”来沟通愿景

为什么要做：文字文档需要大量阅读和解释。交互式原型让每个人都能直接”感受”产品在做什么。这大幅减少了沟通成本。

如何开始：让设计师花更多时间制作交互式 Figma 原型，用 Loom 录制视频演示。把这作为每个重要项目的标准输出。

能得到什么：团队对”我们要做什么”有统一的视觉认知。这比十页 PRD 有效十倍。

建议四：把”支持团队”纳入产品闭环

为什么要做：客服团队每天接触用户的问题，但大多数公司把他们的输入当作噪音而不是信号。如果产品团队不了解真实的用户痛苦，就无法做出真正好的产品。

如何开始：让支持团队的负责人每月向产品团队汇报”用户困惑地图”——用户因为不知道如何使用而产生的高频工单。把这些数据变成产品改进的优先列表。

能得到什么：产品质量的系统性提升，以及支持率的持续下降。这是衡量产品成功的另一个关键指标。

建议五：每天留出”深度工作”时间，关掉所有通知

为什么要做：如果你随时在线，你就没有真正在思考。真正的思考需要连续的不被打断的时间。

如何开始：在日历上锁定两个时间段，比如周三和周五早上 8-11 点。标题就叫”深度工作时间”。关闭 Slack、邮件和所有通知。用这段时间处理最重要的问题——那些需要你真正思考的问题，而不是应对别人的需求。

能得到什么：你会发现自己能够解决之前认为”太复杂”的问题。你的日历不再被别人的优先级控制。

七、我的总结

Jeff Charles 在这次对话中揭示了一个核心真相：Ramp 的成功不是因为某个秘密武器或某个天才创意，而是因为他们用”速度”重新设计了一切——招聘、授权、目标设定、团队结构、甚至对”失败”的理解。他们敢于用最小的团队挑战最大的市场，敢于放弃传统的产品开发流程，敢于把支持团队交给产品负责人。这些”疯狂”的决定背后，是一套完整的第一性原理思维和对”什么是真正重要”的持续追问。

速度不是目的，速度是让正确的事情更快发生的方法。当你的团队不再被会议打断，不再被工单拖累，不再需要等待批准，他们会发现自己能够完成的，远比想象中多得多。这不是乌托邦，这是 Ramp 已经验证过的现实。而你能做的，就是从今天开始，给你的团队一个单线程的任务，然后退后一步，看他们能飞多快。

📺 播客信息

发布时间：2023-08-06
时长：1小时16分钟57秒
播放量：55734 次观看
原版视频：『YouTube』