编者按：这是静远学习 YC 视频《How to Build and Succeed as a Technical Founder》（Diana Hu，YC 合伙人）时整理的中文文字稿，经授权原文照登。讲的是技术创始人怎么从想法一路造到 PMF：构思期、MVP 期、发布后三个阶段，每段都有 YC 真实公司的做法。对一人公司经营者来说，这是一份可以直接对照自己现状的检查清单。英文原文与视频时间戳见出处链接，此处不表。

视频一：How to Build and Succeed as a Technical Founder技术创始人的建造与成功之道

00:00开场与自我介绍

欢迎大家来到"技术创始人如何构建并成功"，这是一场 Startup School 演讲。先简单自我介绍：我是 Diana Hu，目前是 YC 的合伙人（group partner）。在此之前，我是 Escher Reality 的联合创始人兼 CTO——那是一家为游戏开发者构建增强现实（AR）SDK 的创业公司。我们最终被 Niantic 收购，我在那里担任工程总监，负责整个 AR 平台。所以，关于怎么把一个东西从只是一个想法、做到原型、再上线一个有点"胶带糊起来"的 MVP，然后走向产品市场契合（PMF）、把系统扩展到数百万用户——这些事我算是懂一些。

这次演讲分三个部分：第一，技术创始人的角色是什么、他们是谁；第二，在每个不同阶段该怎么构建——构思期（只有一个想法）、有了初步验证后构建 MVP 并推向上线、以及上线之后向产品市场契合迭代的阶段；最后我会用一小节讲技术创始人的角色在 PMF 之后如何演变——这部分不会展开太多，因为在座 Startup School 的同学大多处于早期阶段。这场演讲的内容汇编自我与众多 YC 技术创始人的交流——来自 Algolia、Segment、Optimizely、WayUp——很高兴能把他们的经验和例子分享给大家。

01:55什么是技术创始人

有时我会听到非技术创业者说："我需要找个人来把我的 app 写出来。"这是不行的。技术创始人是创业全程的合伙人，需要极高强度的投入——你不只是一个写代码的。技术创始人做什么？当然要主导产品的大量构建工作——同时也要和用户交流。

一个常见问题：团队里有技术创始人，那谁当 CEO、谁当 CTO？答案很微妙——取决于产品类型、所处行业、团队的整体构成。我见过技术创始人当 CEO 的、当 CTO 的，也有担任其他各种角色的。

早期阶段这个角色长什么样？很像"主力开发"（lead developer）：如果你在公司当过主力开发，你负责把项目组织起来、构建出来、推到终点线；或者像开源项目的主要贡献者——所有技术决策都由你做。但和主力开发有几个关键区别：

你得干所有技术活。做软件：前端、后端、DevOps、官网、UX，甚至包括 IT——比如开通 Google 账号。做硬件：也许你只懂电子线路、只会用 EagleCAD，那机械部分也得学起来。当然，干所有技术活的同时，你还要和用户交谈，获得迭代所需的洞察。

你还要建立"够用就好"胜过"完美架构"的偏向。在大公司，你可能因为完美架构受到奖励；在创业公司不是这样。你要偏向行动、快速推进，习惯在大量信息不完整的情况下拍板决策。你会与技术债、低效流程、大量丑陋代码共处——基本上，就是各种混乱。

说这些是想说明：技术创始人为公司的成功全力以赴，这意味着为了让它跑通，什么都肯干。如果你是打工的，"这事不归我管 / 不在我的薪资范围里"或许说得过去——在这里行不通。你必须去做。

04:39阶段一 · 构思期：尽快做出原型

第一阶段是构思期——你只有一个想做的方向。这个阶段的目标是尽快做出原型，唯一的焦点是：做出一个能拿给用户看、能演示的东西——它甚至不需要完整跑通。与此同时，你的 CEO 联合创始人会在接下来几天里找到一批潜在用户，安排会谈，等原型一好就演示给他们看。

这里的原则是：以"天"为单位快速构建。有人会说："Diana，几天做出原型？不可能吧。"一个办法是借助原型工具，并保持极简。软件公司：用 Figma 或 InVision 做一个可点击原型。开发者工具公司：也许就是一个下午写出来的脚本，在终端里跑起来。硬件公司（硬科技）也可以：可能要多花点时间，但关键是 3D 渲染图——把产品的前景展示出来。我的例子是 Remora，它用车载装置帮卡车捕获碳排放——仅凭那张渲染图，就足以让用户对产品兴奋起来，尽管这是硬科技。

再给几个早期原型的例子。Optimizely 是 YC 2010 冬季批的公司，他们的原型几天就搭了出来。为什么这么快？他们申请 YC 时是完全不同的想法——一个 Twitter 推荐小部件——结果没跑通，而且很快发现了原因。联合创始人 Dan Siroker 曾负责奥巴马竞选的分析工作，当时他被叫去优化一个筹款页面，心想：咦，这可以做成一门生意。于是他们飞快地拼出了第一个可视化 A/B 测试编辑器——其实就是放在 S3 上的一个 JavaScript 文件。在 Chrome 里按 Cmd+Opt+J 打开开发者工具，手动跑 A/B 测试。当然，除了创始人没人能用，但足以拿给目标用户——营销人员——看，并让他们兴奋起来。前后就花了几天。

另一个例子是我自己的创业公司 Escher Reality。因为我们做的是更偏硬科技的东西——在手机上跑计算机视觉算法——我们花了几周搞定。有一个 AR 演示摆在眼前（就像你刚才视频里看到的），比口头解释、比手比划容易太多了；销售和讲解都变得简单很多。

07:41原型阶段的常见错误

别在这个阶段过度构建。我见过有这种偏向的人跟我说："可是用户看不到那些地方""这还不够好""这个原型展示不了完整愿景"。这恰恰是错误——以为自己在这个阶段就需要一个完整的 MVP。不需要。

另一个错误是没有尽早去和用户交流、倾听用户。你会不好意思展示这个随手拼出来的"胶带原型"——没关系，硬着头皮上，你会拿到反馈。还有，就像 Optimizely 的故事：创始人对自己的想法太执着，当用户反馈明确表示"这不是我想要的"时，错误就在于不肯放下坏点子。

08:27阶段二 · MVP 期：做到上线；要不要先招人？

想象你的原型演示给了不少人，兴趣足够。那就进入下一阶段：构建一个真正能用的 MVP，推向上线。这一样要快——理想情况是几天到两周，有时是几个月，但对大多数软件公司来说，理想状态是"周"这个量级（硬件和深科技公司例外）。这个阶段的目标是：做出能让用户承诺使用的产品——最理想的承诺就是付费。这也正是原型的用处：你在构建的同时，CEO 联合创始人继续和用户聊、演示原型，甚至提前拿到"做好了我就用"的承诺。

插一段题外话，因为创业者一兴奋就容易问："大家看了原型都很兴奋，要做的太多了——是不是该先招人？"第一次创业的人会想："天哪，需求验证了，大家想要——我是不是该招人帮我一起建？"这要看情况，但它实际上会拖慢你上线的速度：从陌生的人才池里招工程师，找到一个好人要一个月以上，而且在这个前景未明、一片混乱的阶段很难招到人，它只会让你更慢。更隐蔽的问题是：它会让你失去亲自沉淀产品洞察的机会。产品会不断演化——如果是团队里的别人在构建，你就会错过那些关键学习，而金子可能就埋在里面。当然有例外——等东西建得更完整些再招人是可以的——但在现阶段依然困难。

例子：Justin.tv 和 Twitch。起步时只有四位创始人，其中三位是非常好的技术创始人。MVP 就是创始人自己当软件工程师写出来的。魔力在于 Justin、Emmett、Kyle 各建系统的一部分：Kyle 成了那个无畏的强悍工程师，专啃视频流媒体的硬骨头；Emmett 包下所有数据库的活；Justin 做网页。这就足够上线了。（上线之后他们确实招了很好的工程师——但关键是他们完全不看简历，专门去找那些"异类"、被 Google 忽视的工程师——结果这些人非常出色，加入三个月内就扛起了大量视频方面的活。你要的就是这种人：招进来就能撒开腿跑。）

11:31原则 1 · 做不可扩展的事（Stripe）

原则一就是 Paul Graham 那篇经典文章《做不可扩展的事》（Do Things That Don't Scale）——用聪明的"歪招"快速上线。套用 Drake 表情包的说法：不要做自动化自助引导注册（automatic self-serve onboarding）这类东西，因为那意味着大量工程——可扩展的后端、自动化脚本。这些在某个阶段听起来很美，但不是现在。歪招可以是：手动引导注册——你亲自改数据库，一条条手动把用户、条目、数据加进去。而天平的另一端则是"疯狂客服"——站在第一线干活的，就只有创始人你们自己。

经典例子是 Stripe。上线时的网站非常简单：给开发者提供一个收款 API；而背后那件"不可扩展"的事是——创始人亲自手动处理每一笔交易，一张张填银行表单来完成支付。这足够让他们更早上线。

12:37原则 2 · 90/10 解决方案（DoorDash）

原则二是著名的"90/10 解决方案"，由 Paul Buchheit 提出——他是 YC 的合伙人，也是 Gmail 的原始发明者。第一个版本不会是最终版本——很多代码大概率会被推倒重写，没关系。把尽可能多的功能推迟到上线之后。说"90/10"不是让你留 bug——依然要够用——而是把产品限制在有限的维度上运行：场景、处理的数据类型、功能、服务的用户类型、设备数量，或者地域。想办法切分问题、简化它。这在起步阶段可以是你的秘密超能力，因为你动得快——大公司做不起这种事；甚至你自己的公司做大之后，法务、财务、销售团队都会让你慢下来。

几个例子。DoorDash 起步时一个下午就把它拍了出来——当时其实叫"Palo Alto Delivery"。菜单用 PDF，网站上的电话就是某位创始人自己的手机号；站点不是动态的，就是纯静态的 HTML、CSS 加 PDF——这就是他们的前端。后端？根本没建："后端"就是 Google 表单和 Google 文档，所有订单都在里面协调。连司机位置和送达时间追踪都没做——用 iPhone 上的"查找朋友"来跟踪每一单的配送。这就够了，他们就这样上线了。整个东西一个下午拼完。

他们做得最聪明的一件事：因为自己是斯坦福学生，就把服务范围限定在 Palo Alto。而反直觉的是，专注 Palo Alto 并把它做对，随着增长反而迫使他们在起步阶段就把郊区的配送和单位经济学跑对——之后才能复制放大；而竞争对手（比如 GrubHub）聚焦在大城市，结果单位经济学和运营一直没做对——后来故事怎么走的，大家都看到了。起步时的专注、把关键事情做对，会在后面长期回报你。

15:00原则 3 · 为迭代速度选技术栈

技术栈怎么选？在"对产品合理"和"你个人的熟练度"之间平衡，让自己能尽快交付。保持简单——别为了学一门酷炫的新语言而把它选进你的创业项目。选你足够熟练、用着顺手、能快速上线的东西。这就引出这条原则：为迭代速度选技术。

善用第三方框架、API 和工具，MVP 可以建得非常快——很多东西不需要自己做。认证有 Auth0；支付有 Stripe；跨平台支持和渲染有 React Native；云基础设施有 AWS、GCP；落地页有 Webflow；后端 / serverless 有 Lambda、Firebase 或托管数据库。过去的创业公司在上线之前就把钱烧光了，因为一切都要从零自建。别想着当"从零造轮子的酷工程师"——直接用这些框架。

但我知道有 CTO 会说："第三方 API 太贵了""太慢""撑不到规模化"。这事有两面。Sean Wang（一位开发者体验负责人）的那张梗图特别到位：最左边，刚学会 PHP 或 JavaScript 的新手直接拿它做了辆玩具车，"正经工程师"嘲笑新手——"PHP 不堪扩展""JavaScript 不行"；中间的"中位工程师"穿上大厂工装裤，开始"Google 会怎么做"：搞最优、可扩展的架构——Kafka、Linkerd、ROS、Prometheus、Kubernetes、Envoy、BigQuery、几百个微服务。好——这就是"平均水平"的技术创始人，而平均水平的创业公司会死。这结局可不好。最右边是"绝地大师"：眯起眼看，他的方案和新手看起来一模一样——也选了 PHP 和 JavaScript。但理由完全不同：不是因为他刚学会，而是他清楚——这样能动得快得多。

我想强调的是：如果你把公司做起来了、有了用户，"够好"的技术选型没那么要命——你完全可以靠工程能力翻盘。Facebook 众所周知是 PHP 写的，就因为 Mark 最熟它。PHP 当然扛不住规模化、性能一般——但当你到了 Facebook 那个用户量级，你可以用工程手段解决：他们做了自定义转译器 HipHop，把 PHP 编译成 C++ 来优化。这就是绝地操作。JavaScript 也有 V8 引擎，性能相当能打。

WayUp 是 YC 2015 年的公司，帮企业招聘多元化人才——一个面向大学生的求职平台。CTO JJ 在 UPenn 并没有正式读计算机或工程专业，他自学编程、做了几年自由职业才创办 WayUp。JJ——又是像绝地大师一样——为迭代速度选型：Django 和 Python，尽管很多同行劝他用 Ruby on Rails——2015 年 Rails 的热度按 Google Trends 是它的 10 倍。完全没关系，这没搞死公司。对他们这就是对的选择：动得快、东西出得来。后端也保持简单：Postgres、Python、Heroku——运转良好。

19:18唯一重要的技术选择：对客户的承诺

这一段总结一下：唯一重要的技术选择，是和"你对客户的承诺"绑定的那些。比如在 Escher，随着规模和阶段的变化，我们其实反复重写、扔掉过大量代码。但我们维持给客户的承诺在 API 层——在 Unity 和游戏引擎里的那一层——那是我不能扔的东西。其他一切都重写了，没关系。

19:44阶段三 · 发布后：迭代冲向 PMF

MVP 建好了、上线了。然后呢？发布阶段的目标是向产品市场契合（PMF）迭代。原则一：用硬数据和软数据快速迭代。硬数据——作为技术创始人，搭一个分析看板，跟踪核心 KPI。同样，分析技术栈也为速度选型：保持极简，Google Analytics、Amplitude、Mixpanel 之类。别上 Logstash、Prometheus 这种重量级家伙——它们适合大公司，不适合你现在的体量，你没有那个负载。软数据：上线后持续和用户交谈。把两者结合起来，搞清楚用户为什么留下、为什么流失，发现用户新的问题，然后迭代构建。

WePay，另一家 YC 公司：上线时是个 B2C 支付产品，有点像 Venmo——一直没起色。于是他们迭代。分析数据里，他们发布的 messaging 之类的功能没人用、无人问津；而当时他们最大的用户是 GoFundMe。他们也去跟用户聊——跟 GoFundMe 聊，发现对方根本不在乎这些 B2C 的界面，只要支付能力。于是他们发现了更好的机会：做 API，转向。而且践行"做不可扩展的事"——第一版连技术文档都没有，直接和 GoFundMe 一起把版本跑通。正是这版 API 起飞了，把他们带到了产品市场契合。

发布阶段的原则二：持续发布。典范是 Segment。他们起步时是完全不同的产品——课堂分析。类似的故事：第一个想法挣扎了很久没起色，直到他们把纯后端部分剥离出来发布——那就是 Segment。看看他们惊人的发布节奏：第一次发布是 2012 年 12 月——Hacker News 上的帖子互动非常高。这是产品市场契合的信号，他们很兴奋，全面转向。之后保持每周发布——大约一个月里连发五次——不断加功能、快速迭代。刚上线只支持 Google Analytics、Mixpanel、Intercom；靠倾听用户，加了 Node、PHP 支持，还有 WordPress……一路走到独角兽，最终以超过 30 亿美元的价格卖给了 Twilio。相当厉害。

发布阶段的最后一条原则：平衡"构建"与"修复"。你会进入一个有技术债的微妙状态——要在修 bug、加新功能、还技术债之间做有意识的取舍。我想说：技术债完全没问题。你要能忍受代码烧着的那种"热"。这完全 OK。要怕就怕对东西——怕那些挡在你和 PMF 之间的。有时那个渲染上的小 bug 在这个阶段根本不 critical。事实上，很多早期产品非常破。你肯定知道 Pokémon GO：2016 年上线时没人能登录进游戏——结果呢？一点没耽误它。我记得去年它还赚了超过 10 亿美元。

补充一点当时的技术背景：架构其实很朴素。Google Cloud 上一个负载均衡器，后端做 TCP 终结，HTTP 请求经 nginx 路由到一批 AFE（应用前端）服务器上处理。问题在于：用户连接要等到 nginx 那一层才被终结——而客户端还带重试机制。在那种天量负载下——上线第一个月，Pokémon GO 的活跃用户数就达到了 Twitter 花 10 年才到的水平，他们一个月就到了——当然会崩。基本上就是海量登录请求把自己打成了 DDoS。你上线的时候，大概就是这种体验。

24:33发布后的常见错误

第一：忍不住想"Google 会怎么做"（What Would Google Do）——这几乎是个注定的陷阱：按大公司的方式建系统，或者为了"动得快"去招人（这条更微妙一些，有时确实是错误）。第二：过度聚焦修修补补和重构，而不是朝着 PMF 构建功能。第三：不从用户身上挖洞察。我见过 CTO 说："上线了，我终于可以埋头专心写代码了。"大错特错。技术创始人的角色不是这样：你要全程在场，真正理解用户为什么留下、为什么离开——持续跟他们聊。第四："我们只要做产品功能就行"——你还需要为增长构建技术。事实上，一些最棒的增长黑客，正是工程师和非技术的销售、增长同事结对做出来的。

25:30PMF 之后：角色如何演变

假设你已经到了产品市场契合——然后呢？这时候你才真的可以穿上"大厂工程裤"，去梳理哪些技术模块需要为规模化而建。技术会崩——而因为需求太大而崩其实是好事（参考 Pokémon GO）。这时候才是你找出要重做、要重构的模块的时候——是现在，而不是 PMF 之前。你还要定下工程文化长什么样；这个阶段你的招聘会明显变多——第一批招的多半是你认识的人。

从这时起，你的角色真的变了，因为沟通开销出现了。你会发现角色在变形：带 2–5 个人时，你还有大约 70% 的时间可以写代码；5–10 人，不到 50%；超过 10 人，你基本告别写码了。你必须决定怎么搭组织结构——以及自己是留在"架构师型"的角色，还是转向"带人"的管理角色。

26:50总结

总结全场。第一阶段——构思期：目标是尽快做出原型，原则是以"天"为单位快速构建。第二阶段——构建 MVP（我想在座很多人在这个阶段或上一个阶段）：目标是几周内快速上线，原则是：做不可扩展的事、90/10 解决方案、为迭代速度选技术。第三阶段——上线后：前面所有原则依然适用，在此之上：目标是向 PMF 迭代。用硬数据+软数据（分析+用户访谈）快速迭代；持续发布；在构建与修复之间找到平衡——技术债完全没问题。忍受技术债烧起来的那股热，完全 OK。

如果这整场演讲只能带走一句话：创业公司靠快取胜。谢谢大家。