创业公司技术创始人必备：这些坑千万别踩

[音乐] 欢迎各位参加本次创业学校讲座，主题是如何成为技术创始人并取得成功。简单自我介绍：我是戴安娜，目前是YC的集团合伙人，此前曾担任Azure Reality的联合创始人兼CTO。这是一家为游戏开发者构建增强现实技术的初创公司，最终成功退出并被Niantic收购。在Niantic期间，我担任工程总监，负责所有AR平台业务。因此，我对于如何将想法转化为原型、推出略显粗糙的MVP、实现规模化、达成产品市场契合度，以及将系统扩展至数百万用户的过程颇有心得。本次讲座将涵盖三个阶段：首先，技术创始人的角色是什么？他们是谁？

在初创学校的各个阶段，你们是如何构建产品的？首先是构思阶段，此时只有一个想法，你们刚开始着手构建MVP（最小可行产品）；一旦获得一些验证，就进入推出阶段，目标是迭代实现产品市场匹配。之后我会简要探讨技术联合创始人在产品市场匹配后的角色演变，但不会深入太多，因为初创学校中的大多数人仍处于更早期的阶段。我很高兴能分享这次演讲，因为它汇集了与许多YC技术联合创始人的多次对话和交流，比如来自Algolia、Segment、Optimal等公司的创始人。我很期待他们在这方面的见解和案例。好了，有时我会听到非技术创始人说……

我需要有人来构建我的应用，所以仅仅这样是不够的。技术联合创始人是创业全程的合作伙伴，需要极高程度的投入。而你只是个开发者。技术联合创始人做什么？他们当然主导产品的大部分构建工作，同时也要与用户沟通。有时我会被问到：技术联合创始人究竟是CEO还是CTO？这个答案很微妙，完全取决于产品类型、所在行业以及团队的整体构成，才能确定谁是CEO或CTO。我见过技术联合创始人担任CEO、CTO或其他各种角色。在早期阶段，技术联合创始人的角色看起来很像首席开发者——就像你在公司担任首席开发者时，负责规划项目、构建产品并推动其完成；或者像你在开源项目中作为主要开发者，做出所有技术决策。但与首席开发者相比，有一些关键区别：你必须处理所有技术事务，比如做软件的话，你得负责前端、后端、运维、网站、用户体验，甚至包括人工智能。

如果你在构建硬件，可能需要为Google账户提供任何东西。也许你只熟悉电子方面，并且会使用EagleCAD，但你也需要熟悉机械部分。当然，作为处理所有技术事务的一部分，你还必须与用户沟通，真正获取那些洞察，以便迭代改进。你会倾向于构建“足够好”的架构，而不是追求完美的架构，因为如果你在大公司工作，可能会因完美的架构而受到奖励，但在初创公司则不然。你会倾向于行动和快速推进，在信息不完整的情况下做出决策。你会习惯技术债务、低效的流程以及大量丑陋的代码，基本上就是一片混乱。而所有这些——

也就是说，技术创始人必须全身心投入你公司的成功，这意味着不惜一切代价让公司运转起来。如果你只是公司的一名员工，那就不够格。我有时会听到有人说：“哦，这个任务或这件事不在我的职责范围内。”不，在这里这样可不行。你必须去做，必须完成它。接下来关于如何构建第一阶段的环节是构思阶段，在这个阶段你只有一个想要构建的想法。这里的目标是尽快构建一个原型，唯一的重点是做出一个可以向用户展示和演示的东西，甚至不需要完全正常运行。与此同时，你的CEO联合创始人将在接下来的几天里找到一批用户，安排会议，在原型准备好时进行展示。所以，这里的原则是——

就是在几天内快速构建原型。有时我听到有人说：“哦，戴安娜，一天内做出原型？这似乎不可能，你是怎么做到的？” 其中一种方法是利用大量原型设计软件，并保持极其简单的设计。例如，如果你是一家软件公司，你可能会用 Figma 或 Envision 这样的工具构建一个可点击的原型；如果你是一家开发者工具公司，你可能只需花一个下午写一个脚本，然后在终端上运行；如果你是一家硬件公司，构建原型可能需要更长时间，但关键在于使用3D渲染图来展示产品的潜力。我这里有一个例子，是一家名为 Remora 的公司，他们帮助卡车捕获碳。

凭借这个附件和那个渲染示例，足以让用户对他们的产品感到兴奋，尽管这是一项硬技术。因此，我给你举几个早期原型的例子。这家名为Optimizely的公司于2010年冬季参加了Y Combinator项目，他们仅用几天时间就搭建了这个原型。原因是他们最初向YC提交的是一个完全不同的想法——一个Twitter推荐小工具，但这个想法行不通，他们很快发现了原因。于是他们迅速拼凑出这个原型。这是因为创始人皮特和丹（丹曾负责奥巴马竞选团队的分析工作）回忆说，他曾被要求优化一个募捐页面，并想到这或许可以成为一家初创公司。因此，他们制作了一个非常粗糙的原型。

很快 together，它是第一个可视化编辑器，通过创建一个A/B测试来实现，这个测试只是一个存放在S3上的JavaScript文件。我只需在Chrome中按下Option+Command+J，然后手动运行A/B测试，它就能工作。当然，除了创始人之外没人能用它，但这足以向营销人员展示——他们是目标用户，用于优化网站——从而让用户感到兴奋。所以这个功能只用了几天就构建完成。另一个例子是我的初创公司Azure Reality。由于我们在构建更复杂的技术，必须让计算机视觉算法在手机上运行，我们在几周内就完成了。这比单纯解释和空谈要容易得多，就像你在视频中看到的那样，展示AR的演示让销售和解释变得轻松许多。那么，什么是……

原型设计阶段的常见错误：在这个阶段不要过度构建。我见过有人存在这种偏见，他们对我说："戴安娜，但用户看不到它"或"这不够好，这个原型没有展示完整的愿景"。这是创始人认为在这个阶段需要一个完整的最小可行产品（MVP）时犯的错误。另一个明显的错误是没有尽早与用户沟通或听取他们的意见，你会感到不适，展示这种随意拼凑的原型设计，这没关系，你会得到反馈。以Optimizely为例，另一个错误是创始人过于执着于自己的想法，当用户反馈显示某些明显的问题、用户不想要的东西时，却无法放弃糟糕的想法。好了，现在就是这样。

进入下一阶段。当你有了这个原型，与人们交流后发现有足够的兴趣，那么你就进入下一个阶段，即实际构建一个可行的MVP，以便推出产品。目标是基本构建完成并推出，这个过程应该非常迅速，理想情况下只需几天、两周，有时几个月，但对于大多数软件公司来说，理想时间范围是几周。当然，硬件和深度科技公司是例外。因此，这个阶段的目标是构建一个能让用户提供反馈的产品，理想情况下，这种反馈的表现形式是让他们愿意付费。而拥有原型的原因在于，当你构建产品时，你的联合创始人或CEO可以与用户交流并展示原型。

甚至在你准备发布产品时，还会收到使用它的评论。所以我要稍微岔开话题，因为有时候创始人会变得很兴奋，比如：“哦，我展示这个原型，大家都很兴奋，还有那么多东西要建，先招人是个好主意吗？” 事情是这样的：“好吧，我有了这个原型，大家都很兴奋，我要招人来帮我建它。”作为第一次创业的创始人，他会想：“哦天哪，哦天哪，产品有市场，人们想要它，这是个好主意吗？” 这真的要看情况。实际上，这会拖慢你快速发布的进度，因为如果你从一群你不认识的人中招聘工程师，找到合适的人需要一个月甚至更久，而且在这个阶段，情况非常模糊和混乱，很难找到合适的人，所以这会让你行动变慢。

另一个更隐蔽的问题是，你会因此无法形成对产品的某些深刻见解。因为如果你的产品是由团队中的其他人（而非创始人）开发的，你就会错失关于产品标签的关键认知——其中可能蕴藏着金矿般的价值，但并非由你亲手构建。当然也有例外情况，我认为当产品开发到更成熟的阶段时，你可以稍晚些再招聘人员。但在这个阶段，这仍然很困难。让我举个例子：Justin TV 和 Twitch 最初只有四位创始人，其中三位是非常优秀的技术创始人。在开发最小可行产品时，只有创始人以软件工程师的身份编写代码。Justin、Emmett 和 Kyle 分别构建系统的不同部分，而 Kyle 后来成为了一位出色的工程师。

SS工程师负责解决视频流媒体的棘手问题，Emma负责所有数据库工作，Justin负责网页开发，这些就足以让产品上线了。我的意思是，我承认他们上线后确实招聘了优秀的工程师，但关键在于他们非常不看重简历，而是努力寻找那些被T117公司忽视的“不合群者”，结果这些人表现得非常出色。阿蒙和戈勒姆就是两位优秀且从容的工程师，他们入职仅三个月就承担了大量视频相关的工作。你需要的就是这种能立刻上手并独立推进工作的人才。好了，现在回到构建最小可行产品的原则：第一条是经典的“做不具扩展性的事”原则，要巧妙找到突破口。

快速启动的技巧，秉承着在那些scale时刻做事的精神，以及Drake发布版本中，要避免像自动自助注册这类事情，因为这会增加大量工程工作——构建可扩展的后端、自动化脚本，这些在某个阶段听起来很棒，但并非当前阶段所需。而一个巧妙的做法可能是手动注册：你直接编辑数据库，添加用户、条目和数据。另一件疯狂的事情是定制化支持ppo，只有你——创始人——站在第一线亲力亲为，做那些不scale的事情。一个经典例子是Stripe，这是他们上线时的网站，非常简单：他们为开发者提供了发送支付的API，但在后端，那个不scale的部分，实际上是创始人手动处理每一笔交易。

起初，填写银行表格处理付款流程就足以推动他们提前上线。现在来看第二条原则——著名的"9010解决方案"，这个概念由YC合伙人、Gmail原始发明者保罗·布赫海特提出。记住：第一个版本绝不会是最终版本，大量代码很可能需要重写，这完全正常。将尽可能多的功能推迟到上线后实现。通过快速上线打造9010解决方案，我并非指制造漏洞，产品仍需达到合格标准。但你要将产品限制在有限维度内运作，这些维度可以是：使用场景、处理的数据类型、支持的功能类型、用户类型、设备类型或数量。

找到一种方法来分解问题以简化它，这可以成为你创业初期的秘密超能力，因为你能快速行动，而大公司无法做到这一点。即使你的初创公司发展壮大，你也会有律师、财务团队和销售团队，这些都会让你行动变慢。给你举几个例子：DoorDash 在初期只用了一个下午就搭建好了服务，当时他们其实叫 Palo Alto Delivery，他们用 PDF 作为菜单，直接把电话号码放上去——那个电话其实是其中一位创始人的号码。网站也不是动态的，就是纯 HTML、CSS 和 PDF，这就是他们的前端。他们根本没费心去搭建后端，所谓的“后端”其实就是——

st Google 表格和 Google 文档，他们用这些来协调所有订单，甚至没有构建任何东西来追踪所有司机或预计到达时间，他们只是用你 iPhone 上的“查找我的朋友”这个花哨功能来追踪每个配送的位置，这就足够了。所以这个系统是在一个下午内搭建起来的，他们就能上线了。他们做的一个非常聪明的事情是，因为他们是 Stanford 学生，他们将其限制在仅帕洛阿尔托运营，而反直觉的是，通过专注于帕洛阿尔托并把它做好，随着业务增长，这让他们从一开始就专注于在郊区做好配送和单位经济模型，这样他们就能完善这一点并做对，而竞争对手如 GrubHub 则专注于大都市，你现在也看到了结果。

故事的发展体现了单位经济模型，而运营难度远超预期，且未能妥善处理。有趣的是，初期聚焦并做好这些事，能让你保持专注、把事情做对，而这些努力日后会带来丰厚回报。那么现阶段，如何选择技术栈呢？关键在于平衡：既要符合产品需求，也要结合个人专长，以便尽快交付。保持简单，不要为了学习而选择炫酷的新编程语言。选择你足够熟练、能快速上手的工具。这引出了下一个原则：优先考虑迭代速度。此外，借助第三方框架和工具，可以非常快速地构建最小可行产品（MVP），你并不需要事事亲力亲为。

很多工作都可以借助现成工具完成，例如身份验证有Auth0，支付有Stripe，跨平台支持和渲染有React Native，云基础设施有AWS和GCP，落地页有Webflow，后端无服务器架构有Lambda或Firebase，托管数据库也有现成方案。过去，初创公司往往在还没正式上线前就耗尽了资金，因为他们不得不从零开始构建一切，从底层硬件做起。不要试图成为那种追求炫酷的工程师，非要自己从头搭建——直接使用这些框架就好。但我知道有些CTO会告诉我：“用这些第三方服务太贵了”或者“用XYZ太慢了，扩展性不好”。对此我想说，使用第三方服务确实有利有弊。

快速行动并不意味着这个梗有多妙。开发者体验负责人肖恩·王分享的这个梗，有趣之处在于：入门级开发者刚学会PHP或JavaScript，就像用它们搭玩具车；资深工程师会嘲笑新手说"PHP语言不行"或"JavaScript有缺陷"之类的话；而中等水平的工程师则会想："我要穿上大工程师的裤子，做真正该做的事"，然后构建最优解和可扩展方案，后端用上Kafka、Linkerd、ROS、AMA、Prometheus、Kubernetes、Envoy、Big Red或数百个微服务——这就是中等技术水平的典型表现。

大多数初创公司都会倒闭，所以这并非好结果。另一个有趣的现象是，当你观察那些"绝地大师"级别的开发者时，会发现他们选择的解决方案看似相同——比如都选了PHP和JavaScript，但选择理由截然不同。并非因为他们刚学会这些技术，而是他们意识到这些工具能大幅提升开发效率。我想强调的是：如果你成功创办了一家公司，获得了足够多的用户，技术选择就没那么重要了。你可以通过其他方式解决问题——就像Facebook最初用PHP构建，因为马克对该语言非常熟悉。虽然PHP性能不算顶尖，但当你达到Facebook那样的用户规模时，总有办法解决性能问题，这正是他们后来所做的。

他们开发了一个名为Hip Hop的自定义转译器，将PHP编译成C++以优化性能——这堪称绝地武士的智慧之举。即便是JavaScript，也有V8引擎使其性能卓越，所以我认为这完全可行。WayUp是2015年YC孵化的一家公司，致力于帮助企业招聘多元化人才，同时也是一个面向大学生的求职平台。其CTO JJ虽然未在宾夕法尼亚大学正式学习计算机科学或工程学，但通过自学编程并从事了几年自由职业，在创立WayUp前就已掌握相关技能。JJ像绝地大师一样选择技术栈时，优先考虑迭代速度：他选择了Django和Python，尽管当时许多同行建议他使用Ruby on Rails。根据Google趋势数据，2015年Ruby on Rails的流行度是前者的10倍，但这并未影响他的决策。

那次事件完全没有击垮公司，我认为这对他们来说是正确的选择，因为他能够快速行动、迅速推进，并让产品尽快面世。我在后端保持了简洁：PostgreSQL、Python、Heroku，这套方案对他们来说效果很好。现在我来总结一下：唯一重要的技术选择，是与客户承诺直接相关的那些。例如在Azure，我们实际上多次重写并丢弃了大量代码，随着技术在不同阶段演进，但我们对客户维持的承诺是在Unity和游戏引擎层面的统一性，这是绝不能丢弃的。其他所有代码我们都重写过，这完全没问题。好了，现在进入第三部分：你已经有了MVP，构建并发布了它，现在要正式上线了。

在发布阶段，你的目标是通过迭代实现产品市场契合。因此，第一原则是利用硬数据和软数据快速迭代。作为技术创始人，要使用硬数据确保你已建立带有分析功能的仪表盘，追踪主要关键绩效指标。再次强调，为分析工具选择技术时要以速度为导向，保持极简，例如使用 Google 分析工具、Amplitude 或 Mixpanel，避免采用像 Lock Stash、Prometheus 这类过于复杂的方案。这些工具适合大公司，但在你当前阶段并不适用，因为你还没有那么大的负载。同时，要利用软数据——在发布后持续与用户交流，将两者结合，了解用户留存或流失的原因，并找出用户面临的新问题，从而进行迭代。

在构建过程中，我们投资了另一家YC公司。他们最初推出的是B2C支付产品，有点像Venmo那种模式，但问题是始终没能真正发展起来。他们不断迭代，通过分析发现，我们正在推出的某些功能（比如消息功能）根本没人关注、没人使用。同时他们发现，在众多支付用户中，最大的客户其实是GoFundMe。他们与用户沟通时，GoFundMe明确表示对B2C用户界面这些功能毫无兴趣，只关心能否顺利收款。于是他们发现了更好的机会——转型为B2B支付服务商，并彻底调整了方向。他们甚至没有技术文档，就与GoFundMe合作推出了第一个版本，而正是这个B2B版本真正起飞，帮助他们实现了产品市场契合。这个启动阶段的第二个原则是持续推出产品。Segment就是绝佳案例：他们最初做的是完全不同的课堂分析产品，同样经历了挣扎，直到推出仅保留后端功能的精简版（也就是后来的Segment）。看看他们惊人的发布次数——首次发布要追溯到[D000]年。

那是他们的第一个帖子，你在Hacker News上看到参与度非常高，这算是产品市场契合的一点迹象。他们因此兴奋起来，转向了这个方向，并且每周都坚持发布新内容。在一个月左右的时间里，他们总共发布了五次。他们不断添加功能并进行迭代，增加了对更多工具的支持。最初发布时，他们只支持分析工具Mixpanel和Intercom，但通过倾听用户反馈，他们又增加了对Node、PHP和WordPress的支持。就这样持续发展，最终他们成为了一家独角兽公司，并以超过30亿美元的价格被Twilight收购，这同样令人印象深刻。现在，关于发布的最后一个原则，我想说的是：当你发布产品时，会进入一种有趣的状态，即你需要平衡技术构建与发布之间的关系。

在修复问题与新增功能或处理技术债务之间，你需要做出深思熟虑的选择。我想说的是，技术债务完全没问题，你得学会适应技术燃烧的热度，这完全没问题。你要害怕的是正确的事情，那就是朝着实现产品市场契合度前进。有时候，渲染中的那个小错误可能并不是你现阶段必须修复的关键。事实上，很多早期产品都非常不完善。你可能很熟悉2016年推出的《宝可梦GO》，当时没人能登录游戏，但你知道吗，这完全没有毁掉这家公司。事实上，直到今天，《宝可梦GO》去年收入超过10亿美元，这并没有毁掉他们。我来给你讲讲当时的背景。

在技术方面，其实非常简单直接。他们有一个负载均衡器，部署在Google云上，后端有TCP终止和HTTP请求处理，通过nginx将请求路由到不同的服务器，也就是应用前端（AFE），负责管理所有请求。问题在于，用户连接后，直到请求到达nginx才会终止连接，因此客户端会不断重试。当负载如此巨大时——事实上，我认为《Pokémon Go》在发布后的第一个月内，活跃用户数就达到了Twitter花了十年才达到的水平——当然会出现问题。基本上就是大量用户试图登录，导致系统崩溃。

现在稍微回顾一下Dito的进攻策略，12月左右是你们推出产品的时候。推出后常见的一些错误，我自己也犯过，让CTO Doge感到难过。人们很容易陷入“如果是Google会怎么做”的思维，然后试图像大公司一样建设或招聘，以求快速推进。这几乎肯定是个陷阱。有时我觉得这个问题更微妙，可能是个错误，或者另一个问题是过于专注于修复和重构，而没有构建功能来迭代实现产品市场匹配，也没有从用户那里发现洞察。有时我看到CTO们觉得“产品上线了，我可以埋头苦干，专心建设了”。但不对，作为技术创始人，你的角色非常不同——你必须参与到整个过程中，真正理解用户留下或离开的原因。

你必须持续与你的产品保持沟通，而我看到的另一个错误是，人们只想着为产品构建功能，却忽略了还需要构建技术来推动增长。事实上，一些最有效的增长策略是工程师与非技术背景的销售和增长团队合作实现的。现在进入最后一个部分：关于角色如何演变。假设你已经实现了产品市场契合，接下来会发生什么？这时，你才能真正穿上“工程大裤衩”，着手构建所需的技术模块，以应对增长需求。系统可能会因需求过大而崩溃——这其实是好事，因为崩溃源于需求过剩，完全没问题。以《宝可梦GO》为例，你会发现需要重构和优化的部分。记住，重构的时机是现在，而不是之前。

在产品与市场契合之前，你还需要决定工程文化的形态。这个阶段你实际上会进行更多招聘工作，很可能从带领小型工程师团队，发展到招聘第一批你认识的人。此时你的角色会发生根本性转变，因为沟通成本开始显现。当团队规模从2人扩展到5人时，你仍有约70%的时间用于编码；当团队达到5至10人时，编码时间会降至50%以下；而到了Beyond 10阶段，你可能根本没有时间写代码，必须决定如何构建组织架构——是继续担任架构师角色，还是转向更侧重人员管理的BP型角色。

总结一下，首先第一阶段是构思阶段，目标是尽快构建原型，原则是在几天内快速完成。第二阶段是构建最小可行产品（MVP）的过程，我认为你们很多人正处于这个阶段或前一阶段。目标是尽快在几周内推出产品，原则是：做那些不会扩展的事情，创建90/10解决方案，选择能加快迭代速度的技术。最后一点是，一旦你推出产品，之前关于90/10解决方案和做那些不会扩展的事情的原则仍然适用，并在此基础上增加内容。目标是逐步实现产品市场契合，因此你需要通过分析和用户访谈，利用硬数据和软数据快速迭代，持续推出产品，并在构建与修复之间找到平衡。技术债务完全没问题，要接受它。如果整场演讲只能记住一点，那就是初创公司要快速行动。谢谢大家。