Max Junestrand: You Need The Willingness To Learn Faster Than Anyone Else

Legora 用 AI 自动化律师工作，18 个月内 ARR 从 1 到 1 亿美元，全球 3% 律师已成用户。

法律 AI 的难处，不在模型，而在你愿不愿意把公司当成一连串陌生题来做

Max Junestrand 是 Legora 的联合创始人。Legora 从瑞典起步，面向律师处理复杂法律工作。按他在台上的说法，公司从 2024 年 10 月 GA 到上个季度末，ARR 从 100 万美元增长到 1 亿美元，团队也从瑞典的 3 名工程师扩到全球 750 多人。这个数字很容易让人只盯着融资、名人广告和大客户。他讲的过程反而更具体：三个不懂法律的人怎样进入律师事务所，一家有 3,500 万美元现金的小公司为什么暂停销售六个月，以及一位 CEO 怎样在公司变大后继续学习。

这期回答了 7 个问题：

1. 不懂行业的创始人，怎样先获得足够具体的判断？
2. 对容错率极低的客户，为什么产品先于销售？
3. 模型还不够好时，产品团队应把赌注下在哪里？
4. 高速扩张时，招聘为什么要看成长曲线？
5. 多模型时代，客户到底需要“最强模型”还是别的东西？
6. 强竞争文化怎样避免变成互相甩锅？
7. 创始人的工作为何会不断换题？

被问到三个非律师创始人为何能做出法律 AI 时，Max 没有把答案归因于“外行视角”。他们早期确实很外行。第一次申请 YC，合伙人问服务哪类律师，他们回答："What do you mean? Are there different type of lawyers?"（什么意思？律师还分不同类型吗？） 这个回答让现场发笑，也让他们知道自己连市场的基本分类都没有摸清。

补课的方法很笨，也很贴近用户。他们从律所官网找邮箱、在 LinkedIn 上联系律师，约午餐了解不同业务领域，并提出支付律师的小时费。后来，他们进入北欧大型律所 Mannheimer Swartling 的办公室一起工作。法律服务的特殊之处是，事情做对通常被视为理所当然，做错却会受到惩罚。早期 AI 工具又常要求客户提供大量案例训练，换来的效果仍有限。GPT-3.5 出现后，团队才看到可用的起点。

这段经历给出的判断很窄：陌生行业可以进入，但“先做一个通用平台，再让市场自己解释需求”很危险。Legora 先把自己暴露在律师的工作、风险和语言里，才知道产品需要解决什么。行业经验可以后补，前提是创始人愿意持续把自己放进不熟悉的场景。

Legora 获得 Benchmark 的 951 万美元投资，三周后又完成 Redpoint 的 pre-Series A。Max 说，当时 10 人团队账上约有 3,500 万美元，甚至有一个月的利息收入超过客户收入。资金看起来充足，却没有改变他们对产品风险的判断。

他们在第一次董事会前决定冻结销售六个月。增长不能排在交付可信度之前，因为律师客户通常不会给第二次机会。"you only really get one chance to get it right."（你通常只有一次把它做对的机会。） 如果产品慢、流量上来系统宕机，或在客户的 Azure 实例上失效，后面的销售话术都补不回来。

这次停顿也迫使团队停止“全员投票决定做什么”的早期方式。功能被摊得太散，产品无法形成清楚的承诺。2024 年 10 月，约 25 人的团队写下产品 manifesto，把已学到的东西压缩成共同的取舍标准，然后重建产品并准备发布。销售冻结结束后，增长才开始加速。对高风险工作流，销售漏斗不能替代交付验证；先把一次交付做稳，才有资格把规模放大。

Legora 最早的赌注并不是自训一个法律模型。团队知道 2022、2023 年的共识是微调模型，Bloomberg Law 之类的公司也花了大量资金做专门模型；他们既没有那笔钱，也判断底层模型会持续进步。于是先做一件更靠近客户的问题：怎样把模型已经能给出的价值，交付到律师实际使用的环境中。

Max 的表述很克制："you need to build for the world today and maybe like one step ahead."（你得为今天的世界而建，最多提前一步。） 初代 ChatGPT 在法律任务上并不够用，且不支持私密对话和欧洲数据托管。他们最早的销售说法只是“像 ChatGPT，但符合欧洲合规要求”。它谈不上完整壁垒，却足以让团队进入真实工作流，和客户一起看到模型能力每次上升后能增加什么。

这意味着“等模型完美再做”会错过客户关系和使用场景，“只押未来能力”也会把产品做成演示。Legora 的做法是保留产品层的主动权：底层模型变好时，平台应能把新能力接到已有客户、权限和工作流上，而不是从头再卖一次。

Max 把早期招聘失误说得很直白：团队曾迷信简历上的大厂标识，内部把它叫作 “Y-intercept”。一个人也许起点很高，但如果成长曲线没有继续向上，在指数扩张的公司里很难跟上。后来他们转而找愿意高强度工作、上升空间大的人。

他给出的例子很具体：Legora 目前最好的销售员 23 岁，没有销售背景，大学毕业后进入公司，卖出了超过 1,000 万美元的 Legora 产品。公司规模到约 500 人之前，Max 面试了所有非工程岗位的候选人；现在则面试 director 及以上岗位。高频面试的作用是先把什么样的人会留下来讲清楚，之后团队才能靠这套标准自我筛选。

他们把文化压成三个词：Lean in、fight for excellence、grow together，合起来是 LFG。这个口号也会劝退一部分来自成熟公司的管理者。Max 承认，瑞典文化里的谦逊让年轻人更愿意说话，但如果因此不相信自己能赢，也承受不起高速增长。这里的取舍并不温和：公司需要能合作的野心，而不是靠知名履历制造安全感。

当主持人问模型越来越多会怎样影响 Legora，Max 没有给出“统一使用最强模型”的答案。客服场景常要算延迟和单个工单成本；复杂诉讼则更愿意为更强的推理能力支付更高 token 成本。同一家公司内部，两类客户也会提出相反要求：有人希望让复杂模型长时间工作，有人要求更便宜的开源模型。

所以他们早期雇了很多律师，其中一部分时间面向客户，一部分时间把真实用例写进评测。Max 把这项能力称为核心肌肉："the ability to evalu use cases"（评估具体用例的能力。） 逐字稿里的 “evalu” 是口语转写留下的不完整词，但它指出的动作很清楚：团队要比较成本、智能程度、时延和可用性，而不是跟着单一榜单换模型。

Legora 还发布了 Lora Bench。令他们意外的是，SpaceX 的 Grok 在自家基准中表现很好，尤其考虑成本；但当时还没有完成相应的数据处理协议，不能立刻提供给客户。模型分数、合同边界和系统稳定性必须一起过关。对有大量律师同时使用的平台，算力合同也不是采购细节，系统中断会直接打断客户工作。

Legora 从竞争者更大的位置追赶上来。Max 不想让团队把注意力都放在对手身上，但也不回避竞争的作用。"you don't want a lot of side questing."（你不希望大家各自跑去做一堆支线任务。） 竞争给团队一个容易理解的共同方向，关键是把“赢”落实到同一件产品和同一组客户问题上。

公司目前让所有人知道每月目标。规模只有三人时，团队每天只想把结果做到最大；到了 750 人，沟通开始成为会坏掉的部分，目标和内部信息必须更明确。工程师在假期仍会投入自己想攻克的问题，销售、产品和工程也会围绕功能与竞争方案做比较。

Max 对这种文化加了一个限制：它是团队运动。赢了要一起庆祝，输了也一起承受，然后立刻讨论怎样扭转，进入 solution mode 而不是 blame mode。速度和竞争欲可以带来推进力，前提是团队不会把一次失败变成某个人的污点。否则，信息会在组织里变慢，产品也会跟着变慢。

从 100 万美元 ARR 管销售，到约 1.5 亿美元 ARR 招募管理团队，Max 认为这不是同一份工作。"I need to re-qualify for the job as CEO of Lora every quarter"（我每个季度都得重新证明自己配得上 Legora CEO 这份工作。） 他也要求高管团队接受同样的变化：过去能管好小销售团队的人，不会自动适合更大的收入规模。

这套要求不只针对管理。Max 说 CEO 被低估的一项技能是讲故事，因为你得先说服自己，才撑得住高强度工作；随后还要让员工、投资人和客户相信同一个方向。另一项没有消失的能力是响应客户反馈的速度。即使公司已接近千人，客户电话里出现具体问题，团队仍会把问题丢进产品频道，问能多快解决；同时又得防止每个新反馈都让产品来回摆动。

他的标准很明确：创始人要承认下一题还没做过，然后为那一题重新学习。创业把不舒服的次数压得很密，能否持续承担这种不舒服，决定了人和公司能学多快。

这期最连贯的主线，是把增长从结果倒推回一组具体能力。第 1 条里的冷邮件和驻场，让团队知道律师真正怕什么；第 2 条的销售冻结，把这种理解变成一次可承担的交付；第 5 条的用例评测，保证模型更新不会脱离客户的成本、合规和稳定性。它们都在处理同一个问题：在变化很快的技术上做产品，不能把判断外包给融资、模型排行榜或行业声望。

第 4 条和第 6 条讲的是组织如何承受这个节奏，第 7 条则把同一要求放回创始人身上。对正在做 AI 产品的人，这不是要求复制 Legora 的增长速度。更实用的问题是：眼前最不确定的一件事，能不能先找一个真实用户、一项可测的工作流和一次不靠叙事的交付，把它学明白。