技术创始人实战指南 | Startup School

cover

摘要

在本次演讲中，Y Combinator 的团队合伙人 Diana Hu 分享了技术创始人在初创公司不同阶段的关键角色与成功方法论。她首先厘清了技术创始人的核心定义：这绝非一个仅负责编写代码的“外包开发者”，而是需要在混沌中承担从前后端开发到运维、甚至 IT 支持等一切技术事务，并对公司成败负全责的合伙人。

演讲将创业历程划分为三个阶段以便按图索骥。在构思阶段，核心目标是在数天内极速构建一个可演示的原型，哪怕它只是一段脚本或静态页面，原则是避免过度建设，尽早获取用户反馈。进入构建最小可行产品阶段，创始人需遵循“做不可规模化的事”和打造“90分/10分解决方案”的原则，通过约束功能维度来换取极致的上线速度，并明智地选择基于个人熟悉度和迭代速度的技术栈。最后的发布与迭代阶段，重点在于利用硬数据分析和软性用户访谈来驱动向产品-市场匹配的螺旋式迭代，同时要学会在层出不穷的技术债、功能开发与缺陷修复之间取得平衡。Diana Hu 强调，在产品达到市场匹配之前，初创公司的唯一信条就是：快速行动。

正文

引言：何谓真正的技术创始人

我目前是 YC 的团队合伙人，此前曾作为联合创始人兼首席技术官创办了增强现实初创公司 Azure，该公司最终被 Niantic 收购。基于这段经历，我深刻理解如何将一个想法从零开始，历经原型设计、发布最小可行产品，直至系统扩展以承载数百万用户的全过程。本次分享将围绕技术创始人在不同阶段的核心任务展开。

首先必须明确的是，许多非技术背景的创始人常误以为，技术创始人仅仅是“找个人来帮我写个应用”。这种认知是完全不充分的。实际上，技术创始人是整个创业征途中地位对等的合伙人，这需要极高强度的投入与承诺。你不能仅仅将自己定位为雇员，认为某些任务“超出了职责范围”。作为技术创始人，你必须愿意做任何让公司成功所需的工作。

在早期阶段，技术创始人的角色在职能上很像一名主导开发者：负责将整个项目融会贯通并推向终点。然而，两者之间存在着关键差异。在一家初创公司，你无法像在大公司那样专注于单一领域；如果是软件开发，你可能需要包揽前端、后端、运维甚至网站设计与用户体验的全部工作；如果是硬件创业，你除了精通电子工程外，可能还得去熟悉机械结构。你需要亲力亲为，亲自与用户对话以洞察需求，倾向于构建“足够好”的解决方案而非完美的架构，并在信息不完备的情况下果断决策。你必须逐渐习惯技术债、低效流程以及略显混乱的代码，因为所有这一切都是为了达成一个目的：不惜一切代价让产品运转起来。

至于头衔是 CEO 还是 CTO，这取决于产品类型、行业属性及团队的整体规模与构成，我见过技术创始人承担各种角色。

第一阶段：构思与原型，在几天内完成

在第一阶段，你仅仅拥有一个关于构建产品的初步构想。此阶段的唯一目标，就是以最快速度打造一个原型，用于向用户展示和演示，这个原型甚至不需要完全正常运行。与此同时，你的 CEO 联合创始人需在这几天里密集安排用户会议，以便原型一完成就能立即投入测试。

核心原则是：在短短几天内完成构建。对于“一天内完成原型”这种看似不可能的要求，秘诀在于善用现有的原型设计软件，并保持方案极简。例如：

案例：Optimizely
这家公司是此阶段的典型例子。他们最初在 YC 申请的是一个全然不同的想法，一个 Twitter 推荐小组件，但该想法很快被验证不可行。创始人随即迅速拼凑出了一个新产品的原型：他们创建了首个可视化编辑器，用于进行 AB 测试。这个原型的实质就是一个托管在亚马逊云服务 S3 上的 JavaScript 文件，通过浏览器控制台手动运行测试。除创始人外无人能真正使用它，但这足以向目标用户——即负责优化网站的营销人员——展示其价值。其关键就在于，只用了几天时间完成构建。

在此阶段，需要规避的常见错误包括：
1. 过度构建：认为用户必须看到一个能体现全部愿景的完整 MVP。
2. 迟迟不与用户沟通：不敢展示那个用“胶带”勉强粘合在一起的原型，但请接受这一点，因为你将获得宝贵的反馈。
3. 固守错误想法：当用户反馈显示方向有误时，无法舍弃原有的坏主意。

第二阶段：构建最小可行产品，为发布冲刺

当原型获得足够多的用户兴趣验证后，便进入构建一个能够真正运行并上线的 MVP 阶段。其目标同样是快速构建并发布，理想情况下应在数周内完成，而非数月。此阶段构建的 MVP，目标在于获取用户真正使用你产品的“承诺”，最理想的承诺形式是让他们付费。

在此，一个常见的疑问是：既然有热度，是否应该立即招聘人员来加速开发？我的建议通常是，作为初次创业者，不宜在此阶段招聘。原因有两点：
1. 拖慢上线速度：从陌生的人才库中寻找并招聘优秀工程师通常需要一个月甚至更长的时间。
2. 错失关键洞察：产品会持续演化，如果核心模块由创始人以外的团队成员构建，你将错过对自身技术栈形成深层理解的机会，那些可能蕴含金矿的细微洞察也将与你失之交臂。

案例：Justin.TV / Twitch
Justin.TV 的 MVP 完全由四位创始人中的三位技术创始人构建，他们各自精通不同领域：Justin 负责 Web 端，Emmett 负责所有数据库相关工作，而 Kyle 作为一名无畏的工程师，专攻视频流传输中的棘手难题。这便是你需要的团队模式：每个人都能独当一面，各自负责一个关键部分。

MVP 构建的关键原则

原则一：做那些不可规模化的事
你需要寻找巧妙的“捷径”来快速发布，避免构建“自动化”的系统。例如：
* 避免构建自动化用户引导流程，而采用手动编辑数据库的方式添加用户和数据。
* 作为创始人，亲自在前线提供极致的客制化支持。
* Stripe 案例：当 Stripe 发布其支付应用程序编程接口时，网站极简，但后端完全绕过规模化方案，依靠创始人手动处理每笔支付请求并填写银行表单。

原则二：打造 90/10 的解决方案
此概念由 Gmail 的原创始人 Paul Buchheit 提出。核心思想是，发布的第一版永远不是最终版，大部分代码最终都会被重写，这很正常。你要做的是将大量特性推迟到发布之后，并通过限制产品在有限的维度上运行来换取速度。这些维度可以是特定场景、有限的数据类型、单一的功能集、特定的用户群体、有限的设备数量或地理区域。这种约束能力恰恰是大公司难以模仿的，也是初创公司初期的超级力量。

技术栈的选择

在选择技术栈时，需要在产品需求和个人专长之间找到平衡，以实现最快的交付速度。我的核心建议是：
1. 选择你熟悉且能快速上手的：不要为了学习一门“酷炫”的新编程语言而将其用于初创公司。
2. 选择有利于迭代速度的技术：快速构建 MVP 的最佳方式之一是大量使用第三方框架与 API 工具，例如，用 Auth0 做认证，用 Stripe 做支付，用 React Native 做跨平台开发，用 AWS 或 GCP 使用云基础架构，用 Webflow 搭建落地页，用 Lambda 或 Firebase 实现无服务器后端等。过去，许多初创公司甚至在发布前就因从零构建一切而耗尽资金，切勿重蹈覆辙。

一些 CTO 可能会认为第三方 API 过于昂贵或无法扩展。对此，我的回应是，一个能成功解决规模化问题的公司，其早期技术选择并不像想象中那么重要。Facebook 最初是用马克·扎克伯格非常熟悉的 PHP 构建的，尽管 PHP 在极致性能与扩展性上存在局限，但当 Facebook 达到一定体量后，他们有能力自研 HipHop 编译器，将 PHP 代码转译为 C++ 以解决性能问题。这就是“大师级”的选择：为迭代速度而选择，并确信能解决随之而来的规模化问题。同样，WayUp 的 CTO 选择了自己熟悉的 Django 和 Python 而非当时更流行的 Ruby on Rails，这一决定并未对公司造成任何负面影响。唯一真正重要的技术决策，是那些与你对客户的承诺紧密相连的部分，例如你对外发布的 API。在我们公司，我们曾多次重写和抛弃代码，但始终维持对游戏引擎 Unity 的 API 层不变。

第三阶段：发布之后，迭代至产品-市场匹配

当 MVP 发布后，新阶段的核心目标是通过快速迭代，找到产品-市场匹配。

原则一：利用硬数据和软数据快速迭代
作为技术创始人，你需要建立一套跟踪关键绩效指标的仪表盘，但应选用如 Google Analytics、Amplitude 或 Mixpanel 这类简单工具，而非 Logstash 或 Prometheus 这类适合大公司的复杂系统。同时，在发布后继续与用户对话，将这两种数据相结合，以理解用户为何留存或流失，并发现他们遇到的新问题，从而指导迭代。

原则二：持续地发布
* Segment 案例：最初产品是课堂分析工具，这条路走不通。直到他们剥离并发布其后端的一个精简版本（也就是后来的 Segment），情况才发生逆转。留意他们惊人的发布频率：2012 年 12 月首次在 Hacker News 上发帖，反响热烈。接下来他们几乎每周一发布，在一个月内总共发布了五次，不断增加特性，从最初仅支持 Google Analytics、Mixpanel 和 Intercom，到后来根据用户反馈添加了对 Node.js、PHP 和 WordPress 的支持。这种持续迭代最终使他们成长为一家独角兽公司，并以超过 30 亿美元的价格被收购。

应对技术债与开发平衡的艺术

在产品发布后，你需要学会在构建新功能、修复缺陷和处理技术债之间做出审慎的平衡。此阶段，技术债是完全可接受的，你甚至需要习惯技术栈“在高温燃烧”的感觉。你的担忧应聚焦于推动产品-市场匹配的关键事务上。早期产品很多都是“千疮百孔”的：

此阶段常见错误

  1. 陷入“谷歌会怎么做”的陷阱：试图模仿大公司的架构和流程。
  2. 试图通过招聘来加速：这是一个需要仔细斟酌的决策，可能成为一个错误。
  3. 过度沉迷于修复与重构：将注意力从构建新功能、向产品-市场匹配迭代上移开。
  4. 不再从用户处获取洞察：作为技术创始人，你仍需深入一线，真正理解用户行为的原因。
  5. 只懂构建产品功能，而不懂构建增长技术：最佳的“增长黑客”手段往往源于工程师与销售、增长人员的协作。

最终阶段：产品-市场匹配后的角色演变

当公司成功找到产品-市场匹配之后，作为技术创始人，你才真正可以“穿上大工程师的裤子”，开始认真考虑哪些部分的技术需要为规模化而重写或重构。请注意，这一动作发生在匹配之后，而非之前。你将开始定义工程文化，并进行更正式的招聘。

在此阶段，你的角色将发生根本性转变。从领导小型工程师团队开始，你会逐渐面临沟通开销的问题：
* 当团队规模在 2 至 5 人时，你可能仍有约 70% 的时间编写代码。
* 当规模达到 5 至 10 人时，编写代码的时间降至 50% 以下。
* 当团队超过 10 人时，你可能几乎没有时间亲自写代码，而是需要决定如何组织架构，并选择是成为一位架构师类型的角色，还是转向专注人员管理的“技术合伙人”角色。

归根结底，如果本次演讲只能留下一个核心要义，那就是：初创公司的生命线在于快速行动。