从零创办开发者工具公司，靠这一个公式炸场了【实操视频】

大家好，我是尼古拉·德赛涅，YC的合伙人。在此之前，我曾是Algolia的联合创始人兼CEO。Algolia是一款搜索工具，数百万开发者用它来为应用和网站打造出色的搜索体验。今天我们要讨论的主题是开发者工具以及如何创办一家开发者工具公司，因此这个案例非常契合。接下来我们将探讨：首先，创始团队如何组建以及如何找到创业灵感；其次，如何从原型起步构建最小可行产品；最后，深入分析开发者工具的市场策略，包括销售与营销。但首先，什么是开发者工具？开发者工具是帮助程序员构建产品的软件，涵盖范围非常广泛。

从编码、测试、调试、文档编写、部署到运行，涵盖了开发者工作的方方面面，这是一个非常广泛的范畴。你可以想到集成开发环境（IDE），比如VS Code；还有像Stripe、Twilio或我所在公司Algolia这样的API服务；库和框架，比如React、Node.js或LangChain；甚至基础设施或云服务，比如AWS或Vercel。还有众多其他工具，如Docker、Terraform、Datadog、GitHub。你懂的，这个领域非常多样化。在YC，我们支持过许多这类开发者工具，数量达数百个。我们已经有两家上市公司：GitLab——开源GitHub，以及PagerDuty——最初只是一个简单的告警系统，如今已被半数Fortune 500公司使用。此外还有很多其他公司。

你可能知道Stripe、Docker、Heroku、Superbase、Segment、Postdoc、Apollo、Airbyte，当然还有Algolia。我们从他们身上学到了很多。现在让我们深入探讨，从创始阶段开始。首先，你需要一个创始团队，而开发者工具的关键在于你要为开发者构建技术产品。显然，你自己必须是开发者。我们大多数开发者工具的联合创始团队都是开发者团队。开发者工具的一大优势在于，开发者每天都在使用这些工具。因此，当你构建开发者工具时，本质上是在帮助自己完成产品构建的过程。让我们退一步，快速讨论一下什么是好的和坏的开发者工具创意。

作为开场白，我想先告诉各位，随着LLMs及人工智能的全面兴起，如今要准确判断某个想法是好是坏确实变得异常困难。那些曾经被视为糟糕的、如同沥青坑般难以脱身的旧想法，如今借助LLMs的力量，反而可能获得成功。有些想法确实比其他想法更具挑战性。开发者们每天都要处理他们并不真正喜欢的工作，比如编写文档、质量保障和测试。这些领域自然成为他们想要为他人解决问题的切入点。但问题在于，并非只有他们想到这些，由此产生的同质化竞争异常激烈。这就是为什么市场上充斥着大量同类产品。你真的想为其他开发者打造下一个质量保障工具吗？嗯，这我可说不准。

另一种理解方式是构建时与运行时概念的区别。文档、质量保证、测试等都属于构建时概念，这些是你在构建软件时使用的工具。这类概念大多属于"锦上添花"——即使没有它们，你依然能完成产品开发。而更有价值的是运行时概念。为什么？因为在运行时阶段，这些工具会变得至关重要，属于"必备品"。例如，如果你押注于某个API，当它宕机时，你的产品根本无法运行。正因如此，运行时概念更具关键性，也是开发工具领域更优的创业方向。这类运行时概念的另一个优势在于使用量增长——客户规模越大，通常对你的产品使用需求就越高。这意味着你的利益与客户增长完全一致。

以Stripe为例，如果他们的客户卖出更多产品，他们就能赚更多钱。大家都开心，这个模式好得多。另一个可以快速提及的类别是库和框架。这些可以创建，通常是开源的，但变现难度很大。比如Pandas，想从中盈利非常困难。这类创意的一种变现方式是提供托管服务，比如Next.js和Vercel。最后我想谈谈LLM与AI趋势这个观点。实际上，随着世界的变化，涌现出许多新的开发者工具，这非常棒。能为这些构建LLMs的公司开发工具，实在令人振奋。

但这也是一个市场非常初期的阶段。所以一个显而易见的好主意就是LLM可观测性。嗯，这很明显，对吧？任何使用LLMs构建的人，都想知道自己的表现如何。他们希望能够评估这些系统。猜猜看？很多其他公司也有同样的想法。这就是为什么市面上有几十甚至几百家这样的公司。这并不意味着这是个坏主意，但我认为，如果你要进入这个领域，你需要清楚自己将如何差异化。或者，你打算如何击败所有这些竞争对手？好吧，这让我想到人们常犯的几个错误。第一个是等待完美的想法。你会等上很长时间。让我回到这些LLM可观测性的想法上。

我其实想鼓励你，如果你有这个想法，就直接开始吧。没关系。即使你一开始没能让自己与众不同，也没关系。你会在实践中学习，最终要么成功实现，要么改变想法。这就引出了我的第二个错误——在一个错误的想法上坚持太久。你可能没意识到，但YC孵化的公司中，有50%最终都从最初的创意转型了。这个比例相当高。对于开发者工具领域也是如此。最后，第三个错误是认为团队里必须有一个商业创始人。我知道我创建Algolia时就是这么想的。虽然我们最终以两位技术联合创始人的身份创立了Algolia，但我们确实动过这个念头：嘿，我们不懂销售，需要雇人或者找个懂销售的联合创始人。

不，实际上销售和学习销售你的产品比你想象的要简单得多。我们查过数据，74%的YC开发者工具公司只有技术型联合创始人，而其他类型公司中这一比例仅为45%。好了，既然你们有了团队和想法，该从哪里开始呢？其实只需要做两件事：构建产品和与用户交流。这两件事没有固定的先后顺序。你可以先与用户交流，因为他们能帮你判断初始想法是否可行；也可以先构建原型，从而获得更直接的用户反馈。说到原型，最关键的是不要过度设计，应该快速粗糙地完成它。

我知道这对一些开发者来说可能非常困难，尤其是那些以代码稳健性和可扩展性为傲的经验丰富的工程师。但事实是，在这个阶段最重要的是尽可能快速迭代。根据经验法则，我建议你做好心理准备：你写的代码中90%最终都会被丢弃。因此，这个阶段的目标就是尽快找出那10%真正有价值的部分。之后你只需要重构这10%的代码，就能避免浪费大量时间。当然，在迭代过程中，你需要与用户交流并获取反馈。完全可以直接向他们展示原型，千万不要等到产品完美无缺才行动。

尽早向用户展示原型并开始收集反馈，这最终会引导你打造出MVP，即最小可行产品。其中"可行"这个关键词至关重要——你必须为客户创造价值。与其面面俱到，不如在某个微小领域做到极致，为真正需要它的人提供十倍优质体验。专注细分市场完全可行。一旦拥有真正热爱你产品的真实用户，后续拓展就会水到渠成。以Algolia为例，如今它是功能全面的搜索引擎巨头，但创业初期，说实话它只是个升级版自动补全工具，功能极其有限。正是这个极简产品，凭借远超当时同类产品的卓越体验，赢得了足够多用户的青睐。

当我们开始演示产品时，其实没什么可展示的。说实话，我还记得第一个客户，第一次会面时，我用命令行演示了内容索引功能。那时我们连API客户端都没有，也没有管理界面，只有一个命令行工具，加上一个非常简单的搜索展示网页。就凭这些，我们签下了每月2000美元的合同。好了，既然你已经做出了能展示给用户看的东西，下一步就是和用户交流。我知道很多开发者、技术联合创始人其实性格内向，不喜欢和用户或客户打交道，也不喜欢销售。但你可能没意识到，做开发者工具时你有个巨大优势——你了解你的受众。

你就是受众，你本身就是开发者，你懂客户的语言，因此你最能理解他们。你会发现，这其实比你想象的要简单得多。不要等到产品完全准备好再行动。如果你想验证自己是否在解决一个人们愿意付费的真实问题，就应该立刻开始学习。那么如何找到这些用户呢？两点：主动接触和产品发布。我们先简单聊聊主动接触。开发工具类的创业者通常计划采用自下而上的推广模式，让开发者主动找上门来，试用产品并完成转化，或者让他们成为大公司里支持你的内部推手。但我要告诉你一个坏消息：现在还没人认识你。所以，要实现这个目标，首先得让人们知道你的存在。

要做到这一点，除了主动接触并亲自寻找他们，别无他法。但你需要讲究策略。先从你的人脉圈入手，比如以前的同事或同学。然后逐步扩展，比如朋友的朋友。你可以利用领英（LinkedIn），在上面找到特定的联系人，但请务必个性化你的消息。不要复制那些营销人员发的内容。实际上，作为开发者，我敢肯定你讨厌这类消息。所以别重蹈覆辙。问问自己：你会乐意打开自己写的消息吗？再问问你的联合创始人或其他开发者朋友，他们会不会愿意打开你的消息、阅读你的邮件，并可能采取行动？不断调整优化，直到得到肯定答案为止。接下来，我们来谈谈产品发布。

你可以多次发布。这正是你应该做的，以吸引更多关注。我认为，对于开发者工具来说，最好的发布平台是Hacker News。Hacker News是一个由求知欲强的人组成的社区，其中许多人是开发者。Hacker News上有一个名为"Show HN"的板块，这是发布产品并收集反馈的理想场所。同样，就像你撰写推广信息时那样，请不要做营销，也不要试图推销你的产品。只需简单明了地解释你正在构建的内容中有什么新颖有趣之处。这会对社区产生很大的吸引力，他们会给你留下评论。请积极回应这些评论，不要置之不理。试着与提问的人互动交流。

有些人会成为你的黑粉，对你出言不逊。这时候你也应该回应他们，但你的目标不是说服他们，而是让其他读者看到你如何回应这些黑粉时，能被你说服。保持优雅风度。Segment就是个绝佳案例。他们直接在Hacker News上测试新创意，结果一炮而红。获得数百票和大量评论后，他们确信这个方向可行，最终将其发展成核心业务。另一个例子是Ollama。这家公司帮助企业在其自有设备上运行LLMs程序。最初只是Hacker News某条评论下的跟帖回复，却意外吸引到第一批用户。随后产品正式上线，在Hacker News上迅速走红。

他们又获得了数百个赞。他们知道自己找到了突破口，但并未止步于此。每隔几个月，他们就会再次发布新产品，每次都有新内容分享。这种持续迭代推动了增长，在社区中引发了巨大反响。Hacker News 是最佳发布平台。关于这部分，我想强调最后一点：你应该做那些无法规模化的事情。同样，你的目标是尽可能快速地从用户那里了解他们对产品的喜好。在这方面，Stripe 团队堪称典范。早期，Stripe 团队亲自拜访小型初创企业客户，帮助他们部署自己的产品——他们与客户并肩坐在电脑前，一起编写代码。

这不仅是确保用户对产品满意、甚至感到兴奋的好方法，也是尽早从用户那里收集宝贵反馈的绝佳途径。因此，如果某些做法能带来更快的学习速度，即使它们无法扩展规模也完全没问题。好了，接下来是一些需要避免的错误。请记住，目标是快速行动、快速迭代。所以，不要因为某个技术栈很酷或者你想学习它就去选择它。不，你应该选择你擅长的技术栈，这样才能尽可能快地迭代。其他我们提到过的错误包括：不与用户交流。请尽快获取反馈，这也意味着在得到反馈之前避免过度开发。

这里可能有个小细节要注意。要小心对待那些反馈，避免误解开发者的意见。比如，他们可能会说：“你应该把产品做出来。”但你别在意，你只需要知道他们是否愿意用你的产品以及原因。或者他们可能会告诉你：“嘿，这东西我一周就能搞定，根本不需要。”那又怎样？你自己花一周做出来不就行了。别放在心上，继续改进产品就好。有些团队犯的最后一个错误是过早招人。在早期阶段，你甚至不确定自己的产品是否提供了价值。请确保你确信自己正在做正确的事情之前，不要招任何人。接下来我们来谈谈市场推广。

关于市场进入策略，你首先需要思考的是商业模式。更具体地说，是否应该采用开源模式？开源已成为开发者工具的主要市场进入方式之一，并且确实能作为商业模式运作，许多公司已经证明了这一点，比如Databricks、Elastic、HashiCorp、GitLab。这些都是非常出色的公司。我认为，如果你正在开发库或框架这类产品，就必须采用开源模式。这是当前市场的普遍预期。开发者不会在非开源的新框架上进行开发。如果你处理的是数据，尤其是敏感数据，也应该采用开源模式。例如，新的数据库需要开源，或者与CRM或EHR中敏感数据连接的API也需要开源。

你可以选择开源，但如果你在开发其他产品，比如API或类似Bug追踪器的应用，可能不一定非要开源。在这种情况下，开源或许没那么关键，但仍可能成为你的差异化优势。开源有很多好处。你的客户是开发者。正如你所知，开发者更倾向于使用开源工具。它还能通过社区帮你提升知名度。同时，它也能成为你的差异化特点，比如你可以成为某个产品的开源版本。想想PostHog和Amplitude、Supabase和Firebase、Airbyte和Fivetran。这是个很好的策略。说到Airbyte，你还能从社区获得贡献。

以Airbyte为例，他们从社区获得了大量连接器贡献。但对此需要谨慎。大多数情况下，你不应依赖这些贡献，因为贡献质量可能达不到你的标准。而且你还得与贡献者打交道，这实际上可能比想象中更棘手。总体而言，我认为不应依赖社区贡献——真正优质的贡献其实相当罕见。最后一个但同样重要的优势是信任。这对企业级领域的大型企业而言至关重要。以构建开源电子健康记录系统的Medplum为例，我认为开源属性可能帮助他们将企业销售周期缩短了一年甚至更久。

然而，在创建开源项目时，有一件事你需要考虑——或许不必在初期，但很快就要面对。那就是变现。如果无法将产品变现，你就无法构建一家公司。即便在公司发展的后期阶段，你终究需要盈利。虽然变现方式多种多样，但了解常见策略总是有益的。常见模式包括提供托管服务或云服务。客户可以免费使用你的开源项目自行托管，但也可以付费让你代为托管，省去维护的麻烦。有时云版本还会附带团队管理等额外功能。另一种模式是采用开放核心架构。

在这种情况下，通常会有特殊版本，通常是企业版，包含开源版本不具备的高级功能，或者采用不同的许可协议。常见的企业级功能包括单点登录、审计日志、灾难恢复、服务等级协议等。最后，一些开源公司会为支持和服务收费。但我实际上不建议你走这条变现路径，因为这会促使你尽可能把产品做得复杂，以便收取支持和服务费用——这是一种不良激励。如果你的产品不需要太多支持，用户就会流失，不再续签支持合同。那么，如果你不是开源产品呢？

对于这些开发者工具，通常有两种模式。第一种是按使用量计费，比如API、Algolia、Twilio、Stripe这类公司，它们根据客户的实际使用量收费，可能还会提供阶梯折扣或企业专属方案。第二种模式是制定分层套餐，典型的就是"基础-进阶-旗舰"策略。基础版是自助服务选项，以极低价格解决开发者的基础问题；进阶版通常面向工程经理，他们更关注协作功能，支持团队使用且仍可自助操作；而旗舰版则面向更高层级，需要直接与CTO沟通。

一切都关乎安全、审计日志、灾难恢复和服务等级协议。在这种情况下，通常采用销售主导的方式。我们来谈谈销售。快速回顾一下我之前提到的内容：不要害怕主动联系客户。即使大多数开发者工具最终会采用自下而上的模式，并且严重依赖自然流量，但最初没人知道你，所以你需要从主动联系开始。创始人亲自联系客户的阶段就是你的起步方式。随着知名度提升，你才会获得自然流量。通常到那时你会获得更多自助服务线索。最终，你会组建销售团队来拓展大客户和企业级市场。那么，你该组建销售团队吗？我认为应该尽可能推迟这一步。先从亲自销售开始，不要过早授权他人。

事实是，如今公司里只有你能销售自己的产品。作为创始人，如果你卖不动产品，那别人更做不到。根据经验，我建议等到年经常性收入达到约100万美元时，再招聘第一位销售人员。即便那时，也要尽量招聘懂技术、至少理解开发者的人——因为开发者讨厌和销售人员打交道。我还记得Algolia最早那批销售员，他们主动把领英上的职位从"销售/客户经理"改成了"产品专家"。这样做的好处是，他们必须真正主导销售流程，必须对产品了如指掌。

所以这就像是一个很好的激励，促使他们改进产品，也是一个绝佳的方式，让他们能够接触到那些不想和销售打交道的开发者。另一个例子是PostHog。你知道吗，他们的CTO Tim同时也是销售负责人？不是业务负责人，而是销售负责人也是CTO。他把销售视为一个工程问题，这对开发者工具来说是一种很棒的处理方式。如果你想了解更多关于销售的内容，还应该看看Pete关于企业销售的演讲，那也是创业学校系列视频之一。那么，销售开发者工具和销售其他产品有什么不同吗？是的，确实不同。你不应该制作销售演示文稿。开发者不想浪费时间阅读销售演示文稿。你应该展示，而不是空谈。直接做演示就好。

我认为这是针对开发者工具的最佳销售策略。在Algolia，我们在年经常性收入达到1000万美元之前，根本没有销售演示文稿。即便是我们的专业客户经理，在销售时也只是直接进行产品演示，这种方式对所有人都更有效。你应该完全聚焦产品的技术层面。举例来说，Algolia主要向电商企业销售产品。我们发现，当买家是非技术人员且需要交钥匙解决方案时，我们通常（虽非绝对）会输掉交易。但当买家是技术人员，或者技术部门在决策中具有重要影响力时，我们的胜率会大幅提升。因此我们意识到，必须强化产品的这一特性。我们是一家API公司，而非提供交钥匙解决方案的厂商。

我们最终找到了理想客户画像，销售业绩也更好了。另外，在开发者工具领域还有一个普遍现象：大多数产品都是自下而上推广的。这意味着，即使在企业内部，很多人也会自行使用产品。因此，与其采用自上而下的方式直接推销产品，销售团队更应该先确认是否有企业员工已经在使用该产品，然后重点帮助管理层理解产品已经为他们创造了哪些价值，以及如果他们付费购买更多席位、功能或实际使用量，还能获得哪些更大的帮助。好了，本期视频最后一个要讨论的话题是开发者营销。你的目标是为产品创造大量曝光，从而吸引用户主动找上门来。

首先，你应该找到自己的社群。比如Hacker News、某个子版块，或是与你工作相关的Discord频道。但要注意，此时你的目标还不是推销产品。先提供帮助，把自己打造成专家。久而久之，人们自然会认识你、信任你的品牌和公司。这会在未来帮到你——当人们遇到相关问题时，第一个想到的就是你。频繁发布产品也很重要。我们之前讨论过Ollama的例子，但这对公司整个生命周期都适用。有些公司甚至设立"发布周"，取得了巨大成功。这对开源项目尤其有效。

Supabase 每季度都会这样做，把一整个季度的新闻集中在一周内发布，以尽可能制造声势。你还可以做其他事情。让你的文档成为一等公民。文档往往是开发者的事后考虑。他们更喜欢写代码，而不是记录代码。我认为文档绝不应是事后才想到的东西。它应该是产品的一部分。文档就是营销。这是人们与你的产品互动的方式。实际上，这是人们访问你的主页和定价页面后首先会去的地方。Stripe 和其他开发者工具已经在这方面提高了期望值。开发者变得非常挑剔。这是你应该投入精力的事情。

在Algolia，我们坚持一个原则：文档未完成，功能就不算真正完成。而且文档应该由开发者来撰写。你知道Algolia，即便我们组建了团队也是如此。后来我们成立了专门的文档团队，他们的职责并非替开发者写文档，而是帮助开发者写出更好的文档。比如他们开发了一个工具，能自动为已登录用户插入API密钥，这样用户复制粘贴代码后就能直接运行，让文档对客户更具实用性。说到开发者该做的事，我认为技术支持也应包含在内。你应该让技术支持成为营销的重要部分。你的用户都是开发者，对吧？

开发者们讨厌与那些对自己支持的产品一无所知的一级支持人员交谈。工程师应该亲自做技术支持，这会带来两大好处。第一，你的用户本身就是开发者，当他们与能说"行话"的开发者交流时，满意度会大幅提升。举个例子，曾有客户联系技术支持，而负责支持的开发者仅用20分钟就修复了漏洞并完成部署。这种效率让客户惊叹不已，他们对产品赞不绝口。第二，这能帮助你的开发者更深入理解客户需求——因为他们在提供支持时，会切身感受到用户的痛点。

这正是他们成为更优产品的绝佳途径。再次以Algolia为例，我们直到拥有数百名员工后才组建了专门的客服团队，并且特意指派了最优秀的工程经理来负责。客服在我们这里从未被视为二等岗位。因此，开发者编写文档、处理客服工作——所有这些本质上都是营销。那么，你该何时组建营销团队呢？与销售类似，我认为创始人应当长期主导营销，甚至可能永远如此。说实话，即便在公司发展后期，我也没见过哪家开发者工具公司对拥有传统营销背景的CMO感到满意。为什么？

因为传统营销人员并不真正理解用户画像，也不了解开发者。只有开发者才能真正理解开发者。而开发者最讨厌被营销。请别侮辱他们的智商。你们自己就是开发者，应该明白这点吧？早期在Algolia时，我们要求团队里每位工程师每月完成一次"营销小任务"。这个任务可以是写篇简单的博客、在技术聚会上演讲，或是开发新的搜索功能。Algolia最成功的营销都出自开发者之手。我建议你在组建营销团队时，一定要确保团队中有大量开发者——只有他们才懂得如何与你的客户对话。

你可能会问，那开发者布道师呢？我其实很欣赏这个想法，因为这相当于把开发者纳入你的营销团队。但这个角色定义非常模糊，往往伴随着大量不明确的期望，导致难以衡量成效，也难以建立问责机制。因此我的建议是：先按兵不动，提升现有工程团队的效能，让他们承担部分营销或开发者布道工作。等到A轮融资或更晚阶段，再考虑招聘专职的开发者布道师。即便到了那时，也建议优先从内部或社区中选拔人才。比如，如果你的开源项目有贡献者，或是Discord社群中活跃且乐于助人的成员，他们就是最理想的开发者布道师人选。最后总结一下核心观点：现在就行动起来。

不要等待完美的想法，因为在构建产品的过程中，即使最初的想法并不完美，你也会不断实践、学习，最终找到最佳方案。如果迟迟不开始，你将永远无法取得进展。快速行动吧。请务必不要过度设计。你需要保持快速迭代的节奏，在构建过程中从用户那里获取反馈。早期阶段，粗糙、快速甚至有些混乱的做法完全没问题，之后再去重构真正重要的部分。多花时间与用户相处。如果不与用户交流，你根本无法真正了解他们的需求。向他们学习，做一些看似不具规模效应的事情。去他们的办公室，与他们共度时光。尽早发布产品。你可能看过我们很多视频，我们始终强调：尽早发布并不可耻。

如果产品不成功，人们不会记住你。但你能获得宝贵的反馈，从而引导你开发出人们真正需要的正确产品。在构建开发者工具时，你应该考虑将开源作为市场切入点。观察市场，观察其他参与者如何构建产品，并判断开源是否适合你。但不要轻易否定它，在做决定前要深思熟虑。别忘了，你是自己产品的最佳销售员，没有人比你更了解你的产品或受众。学习销售远比学习如何与开发者沟通容易得多。最后，你也是自己产品的最佳营销人员。

你懂开发者的语言，知道如何与他们沟通，了解他们活跃的社区和聚集地，也清楚如何触达这个群体。好了，我今天的分享就到这里。感谢观看本视频。如果你正在开发一款开发者工具，别忘了随时可以向YC提交申请。