技术型创业创始人建议｜Startup School
技术型创始人很容易把技术卓越误认为是创业进展。精雕细琢的架构、打磨完善的代码库，或雄心勃勃的基础设施规划，或许都会让人感觉自己很有产出，但它们都无法证明客户需要这款产品。在这场 Startup School 分享中，Diana Hu 结合自己从增强现实创业公司 CTO 到 Niantic 工程总监的经历，以及其他 Y Combinator 创始人的经验，阐述了这一角色真正需要承担什么。
她的核心观点是：技术型创始人必须以学习为优化目标。在构思阶段，这意味着做出能让用户作出反应的东西。在 MVP 阶段，这意味着交付一款范围有限但可用的产品，并寻求真实的投入。产品发布后，则意味着将数据分析与直接交流结合起来，快速改进产品，并在技术妥协有助于公司发现可行市场时接受这些妥协。
技术型创始人是公司的建设者
技术联合创始人并不只是被安排去实现另一位创始人计划的人。Hu 将这一角色描述为一种高度投入的合作关系：技术创始人与伙伴共同对产品、客户和公司的生存负责。
这份责任带来了异常宽泛的工作内容。在早期创业公司里，技术创始人可能在同一周内编写应用代码、配置云服务、回复支持消息、修复办公室网络连接、访谈用户，并作出产品决策。狭窄的职位描述属于大型组织；创始人会在公司最迫切的不确定性所在之处开展工作。
因此，早期工程工作的正确目标并不是最高程度的技术复杂性，而是创造前进动力所需的最低限度技术。创始人需要的是足以检验下一个重要假设的产品，而不是为每一种假想未来预先准备好的理想化系统。
在创办公司之前先为想法制作原型
在构思阶段，眼前的目标是将抽象提案变得具体。原型让潜在用户有东西可看、可试或可讨论，比单靠口头推介更能产生可靠的反馈。
原型不一定需要可在生产环境运行的代码。软件团队可以使用 Figma 或其他设计工具来模拟体验。硬件创业公司可以展示 3D 渲染图。当技术可行性本身尚不确定时，对底层技术进行有针对性的演示，可能才是最有价值的产出。
Hu 以 Optimizely 和 Azure Reality 等公司早期的工作为例，说明了不同形式的验证。原型可以呈现一种直观交互来传达产品价值，也可以证明一项困难的增强现实技术确实可行。重要的是，它能应对一项有意义的风险。
常见的失败在于：原型已经足够好，可以开始与用户交流后，团队仍继续开发。创始人不断增加页面、边缘情况和基础设施，因为实施工作比向用户展示尚未完成的成果更可控。但这种拖延代价高昂：在团队了解自己是否解决了正确问题之前，投入就已经增加了。
围绕真实投入构建 MVP，而非追求完整性
原型有助于评估一个想法；MVP 则是一款可供发布的可用产品。Hu 认为，创始人在迈向这一阶段时，通常应该按周而不是按漫长的开发周期来思考。
MVP 的目标是获得比兴趣或赞美更有力的证据。理想情况下，用户会通过付费来显示投入。视市场而定，其他代价高昂的行动——例如投入时间、提供运营数据，或将产品整合进工作流程——同样可能具有意义。关键区别在于：一个人说某个概念听起来很吸引人，和一个人愿意为了使用它接受真实的取舍，是两回事。
创始人应当紧密参与这一过程。过早招聘一支庞大的工程团队，可能会拉开决策者与用户之间的距离，同时增加协调成本。早期 Justin.tv 团队后来催生了 Twitch，他们将初始系统的主要部分由创始人亲自分工完成。直接参与产品开发，让他们在业务仍处于成形阶段时就理解其约束条件。
早期亲力亲为并不是为了证明创始人可以永远做完所有事情，而是为了在每一条新洞见都可能改变公司方向时，保留客户证据与产品决策之间的短路径。
大幅收紧产品范围
Startup School 最有用的原则之一，是去做那些无法规模化的事情。技术型创始人通常受过消除人工工作的训练，但临时性的人工流程恰恰可能是早期产品所需要的。亲自为客户完成入门流程，或在幕后执行某项操作，可能让团队无需等到自动化具备合理性便能推出产品。
Hu 还提出了“90/10 解决方案”的概念：交付能够处理核心使用场景的受限实现，而不是试图覆盖整个问题空间。可以从多个维度缩小范围：
只支持一种主要用户类型。
只接受最重要的数据格式。
只服务一个地点或市场。
处理占主导地位的工作流程，同时推迟边缘情况。
用人工流程替代过早的自动化。
DoorDash 最早的产品就是一个令人印象深刻的例子。它起步于一个基础网站、轻量级的运营工具，以及仅限于一小片地理区域的服务。它并不像公司后来发展成的成熟物流平台，但已足以检验客户是否需要这项服务。
大型公司往往受制于既有系统、审核流程和广泛的客户预期。创业公司的优势在于能够界定一个更小的问题并快速行动。技术型创始人若以为自己已经在企业级规模运营那样来开发，就会放弃这种优势。
为迭代速度选择技术
技术栈选择很容易变成一场分散注意力的身份认同之争。Hu 建议平衡产品的实际需求与团队现有技能，然后选择能够快速发布和修改的最简单组合。
熟悉度具有实际价值。使用自己充分了解的工具，创始人能够更快诊断问题，并把更多注意力放在用户身上。当新技术能带来真正的产品优势时，它可能是合适的；但新颖性本身并不能帮助创业公司学习。
同样务实的标准也适用于第三方服务。身份验证、支付、托管、通信及其他常见能力，通常都可以通过 API 或成熟框架购买获得。从零开始重建它们会消耗时间，却未必能让产品形成差异化。
创始人有时会抗拒外部服务，因为他们担心未来的费用、限制或迁移工作。这些担忧可能确实存在，但必须与行动过慢的即时风险相权衡。一家拥有强劲使用量的公司可以招聘工程师、更换组件并优化基础设施；而一款技术上纯粹却没有客户的产品，选择要少得多。
通过发布开启真正的学习循环
发布 MVP 并不是产品开发的终点。它是公司获得更好证据，并开始向产品市场契合迈进的时刻。
Hu 建议同时使用定量和定性信号。简单的分析仪表板可以揭示采用率、留存率、转化率，以及用户在哪些环节放弃一个工作流程。对话和支持互动则能解释汇总数字无法捕捉的动机。任何一种证据形式单独使用都不够。
WePay 向 API 导向产品演变的过程，说明观察到的行为和客户反馈如何能重新指引一家公司。Segment 的多次发布展示了另一种模式：频繁发布创造更多机会来检验假设、发现需求，并从有效之处扩展。
这意味着，发布不应被视为一次单独的仪式性事件。它是一种持续的运营节奏。每次发布都会产生证据；团队解读这些证据，并决定接下来要改进、移除或测试什么。
为实现产品市场契合管理技术债
一旦客户开始使用产品，创始人就会面临相互竞争的需求。他们必须修复缺陷、交付用户请求的功能、维持系统运行，并处理初始开发期间积累的捷径。
Hu 并不认为技术债无害。相反，她将其视为一种取舍。当承担技术债能显著加快学习速度，或让公司更接近产品市场契合时，这样做可以是理性的。错误在于让工程清理工作脱离业务优先级，或者忽略那些阻碍用户获得价值的可靠性问题。
Pokémon Go 展示了一个极端案例：巨大的需求与显著的技术压力同时到来。它的发布问题很重要，但并未抹去底层用户反馈的强劲。对创业公司而言，这通常比构建一个强健却无人迫切需要的系统更值得面对。
工程团队也应与销售和增长团队紧密合作。面向客户的团队往往最先看到正在出现的需求，而工程师知道什么能够以低成本测试。双方协作可以将市场观察转化为聚焦的实验，而不会引入成熟企业的沉重流程。
从主要开发者成长为工程领导者
在实现产品市场契合后，技术创始人的角色会发生变化。此前，创始人可能亲自实现产品的大部分内容。随着使用量和工程团队增长，工作会扩展到招聘、沟通、技术方向和文化建设。
这种转变会减少不受打扰的编码时间。更多的人意味着更多的依赖关系、决策和沟通路径。创始人必须确保工程师不仅理解要构建什么，也理解公司如何作出取舍，以及哪些标准至关重要。
最终，技术创始人可能需要在两条大致路径之间作出选择。一条是继续深度参与架构工作，指导系统中最具影响力的技术决策。另一条是专注于人员管理和组织建设。合适的选择取决于公司和创始人的优势，但回避这一决定可能导致两项职责都得不到充分承担。
更大的教训是，这一角色应当随公司一起演变。起初，速度来自编写代码和直接与用户交谈。后来，速度越来越来自打造一支能够作出稳健决策、而无需让每个细节都经过单一创始人的团队。
运营原则：为了学习而构建
从原型制作、MVP 开发、发布到规模扩展，Hu 始终回到一个一致的优先事项：缩短一个假设与可靠证据之间的距离。
快速构建第一版原型，让用户能够接触这个想法。发布一款范围严格受限、能够赢得真实投入的 MVP。选择支持快速迭代的技术，即使第一版实现并非永久方案。发布后，解读行为数据和人类反馈。技术债若能推动探索，就有意识地接受它；随后，当可靠性和增长使这项工作成为必要时，再予以解决。
对技术型创始人而言，最难的自律或许在于认识到：代码不是公司。技术是团队检验市场、服务客户并累积所学知识的工具。因此，最好的早期系统并不是为所有可能的未来设计的系统，而是帮助创业公司抵达下一个重要真相的系统。
