出海20多年，Rick讲创业团队不同阶段该招什么人
💡 2026年8月12日 18:35
查看公众号原文 ↗出海20多年，Rick讲创业团队不同阶段该招什么人
2026年8月12日 18:35
封面
大家好，我是哥飞。
很多朋友刚开始做出海，都是一个人找词、写页面、接支付、做推广。产品有收入以后，新的问题就来了：一个人忙不过来，准备招人，却不知道第一位成员该补开发、产品、运营，还是设计。
人招进来以后，问题还会继续变。两三个人靠默契能推进，到了七八个人，信息开始丢失；到了二三十个人，岗位越来越齐，决策反而可能慢下来。
一个人能力很强，也可能放错位置。需求还没验证，就先招来一批擅长执行明确任务的人，团队可能更快做出一堆没人要的功能；已经到了寻找 PMF 的阶段，却只增加执行手，所有判断仍压在创始人身上，人越多反而越堵。
2025 年 7 月，我们在成都办年中分享交流会。那天的现场和嘉宾主题，我在《哥飞的朋友们2025年中分享交流会成都站活动，大家都说很值！》里记录过。
活动开场介绍 Rick 时，提到他做出海已经二十多年。Rick 随后也说，这套团队建设经验来自他们二十多年的创业实践。他带的是工程师文化比较强的团队，这次只讲一个问题：产品开始招人以后，每个阶段该用多大的团队，又该找什么样的人。
Rick 在成都现场分享创业团队
招人之前，先判断团队正在哪一段
Rick 把创业团队的前期分成三段。
MVP 排在最前面。团队需要确认，用户到底有没有这个需求。
第二段是 PMF。需求已经存在，团队要继续找出用户愿意持续使用、愿意付费的产品形态。
第三段是护城河。产品已经找到一批用户，市场上也会出现更多同类产品，团队要把速度、技术、产品体验或者社区做成自己的优势。
创业团队的三个阶段
这三个阶段经常被混在一起。
有的团队连核心需求都没有验证，就先招了一批人补齐运营、市场、设计和管理岗位。人多了以后，每个人都要有事情做，于是功能越做越多，用户是否需要反而没人继续追。
也有团队已经跑出稳定需求，仍然用两三个创始人包办所有工作。客服里每天出现相同问题，产品形态迟迟不改，机会被日常任务拖住。
招人之前，可以先把当前最需要解决的问题写成一句话：我们还在确认需求，还是已经知道需求，正在寻找更合适的产品形态？产品已经成立，现在最怕别人复制哪一部分？
这句话说清楚，才知道下一位成员该带来什么能力。
两三个人做 MVP，每个人都得能往前多走一步
MVP 阶段，Rick 给出的团队规模是两到三个人。
这时的任务很单纯：找到一个真实存在的核心需求。可实际做起来，往往会反复失败。一个方向做了几周，用户没反应；换一个场景，仍然不对；三个人要一起决定继续改、换方向，还是停下来。
两三个人的小团队，最先要对齐的是目标。
同样说“出来创业”，有人想多赚一份收入，有人想把事情做成一家公司。项目刚开始时，这两种想法看起来不冲突。到了要不要继续投入、要不要拒绝短期收入、要不要招人的时候，差异就会放大。
Rick 提醒，早期目标没有说透，后来会直接影响产品形态，甚至走到成员分开。组队前不妨把几件事摊开谈：各自愿意投入多少时间，多久看不到收入会停，想做现金流项目还是长期产品，出现分歧由谁拍板。
MVP 阶段的团队配置
第二个要求是思维方式互补。
如果三个人都是工程师，讨论容易快速落到技术实现；如果都擅长营销，又可能先想着怎样卖。Rick 更倾向于让工程、产品、营销、设计等不同视角同时出现在早期团队里。一个人盯实现，一个人追用户为什么要用，另一个人看页面表达和使用感受。
互补会带来争论，所以团队还要能接受质疑。Rick 的团队做关键决定时，会专门找一个持不同意见的人，从反面追问：这个需求是真的吗？数据还可能怎样解释？如果竞争对手免费做，我们的判断还成立吗？
Rick 说的开放包含两层：愿意接触新的技术，也愿意听别人挑战自己的方案。关键决策前主动找反对意见，可以让两三个人在投入还小的时候，把被默契掩盖的问题提前翻出来。
讨论要帮方案查漏补缺。能把反对意见说出来，又不伤害彼此信任，早期团队才有机会在成本还小的时候改方向。
Rick 借用了一套人才分层模型。最上面一层的人，可以自己发现正确的问题，再想办法解决。MVP 阶段只有两三个人，他希望每个人都能做到这一点。
Rick 分享的人才密度模型
这套模型描述的是成员处理问题的方式。一个很强的工程师，如果只能等别人把需求拆好再执行，在两人团队里仍然会留下很大的空档。早期没有完整的产品、测试、客服和数据岗位，每个人都得看见职责之外的问题，再往前走一步。
AI 产品现在上线很快。代码和页面几天就能做出来，方向偏了，也会很快堆出一批没人用的功能。两三个人要随时检查，自己的验证有没有偏离用户正在解决的事。
人少的时候，岗位边界很难划得那么清。用户卡在付款页，写后端的人和负责页面的人都要把完整路径走一遍。谁先发现阻力，谁就先把问题捡起来。
Rick 反复强调，早期成员要能主动发现问题。招人时，可以拿当前项目里的真实难题聊一遍：对方会先补哪些信息，准备怎样做最小验证，结果与预期相反时怎么继续。这样比只问一遍履历，更容易看出他会主动往前走，还是习惯等一张完整任务单。
五到十个人找 PMF，靠口头同步已经不够
核心需求被验证以后，团队要找的是正确产品形态。
Rick 用 AI 编程举例。用户确实想让 AI 帮忙写代码，可产品应该做成编辑器、在线生成工具，还是命令行助手，不同形态对应的人群和使用路径都不同。需求存在，不代表第一版产品形态就对。
到了这个阶段，Rick 认为 AI 时代的团队大约需要五到十个人。放在 AI 普及以前，同样的工作也许需要十几二十个人。现在工程和内容生产效率提高，小团队能覆盖更多环节，但人数增加后，原来靠朋友默契推进的方式会失效。
Rick 在现场讲团队人才配置
新成员不知道创始人为什么选择这个方向，也不知道哪些原则不能牺牲。一个需求在产品、开发、运营之间传几次，最初要解决的问题可能只剩下一张功能清单。
两三个人都是熟人，讨论和分享会自然发生。团队到了五到十人，新成员陆续加入，原来的默契不会自动传过去。Rick 的团队会每周留出固定时间，让成员把最近学习的内容讲给其他人听，也会围绕一本书、一个产品或者一个问题共同讨论。
准备输出时，一个人要重新整理自己的判断；同事追问以后，还要补证据、找反例。客服听到的问题、运营看到的数据和开发遇到的限制，也会在这个过程中碰到一起。团队怎样做决定，慢慢就不再只存在于创始人的脑子里。
PMF 阶段的团队配置
Rick 给这个阶段的另一个参考，是让大约 30% 的成员具备主动发现问题的能力。假如团队有十个人，除了早期两三位创始成员，后面招进来的人里也要有人能质疑目标、重新定义问题。其余成员至少能够独立完成任务，或把复杂问题拆开解决。
这个比例提醒团队，扩张不能只增加执行手。五个人时所有判断都等一个创始人，到了十个人，创始人会变成最堵的一段。产品、工程或运营里需要有人看到数据变化后，继续追到用户场景，再提出下一步怎么验证。
PMF 还没找到时，每周都可能出现新的用户反馈。可以选一条流失明显、反馈集中或者付费犹豫的路径，让不同岗位分别说自己看到了什么。最后只留下一个要验证的假设和一个负责人，下一周再用结果检查原来的判断。
十五到三十个人建护城河，别急着把公司做重
产品形态跑顺以后，同类产品会越来越多。团队进入建立护城河的阶段。
Rick 列出的护城河包括开发新功能的速度、团队成员的能力、已经积累的用户，以及能持续互动的社区。团队要判断自己最有机会把哪一项拉开，再围绕它配置人。
技术团队可以靠更快的产品迭代形成优势；产品有了足够多的用户，使用规模也会抬高后来者的门槛。Rick 现场还特别提到社区：用户愿意在里面持续交流、贡献内容和反馈，产品与用户的关系就不只剩下一次购买。
在他的判断里，能持续互动的社区，往往比一次推广带来的访问更难被竞争对手复制。
这个阶段，Rick 给出的规模是十五到三十个人。团队需要强化产品能力，也要把长远目标拆成几个可以推进的阶段。运营和客服要会分析竞品与数据，开发要理解交互和用户需求，产品判断不能只留在产品经理一个岗位里。
Rick 对“产品思维”的解释也很具体：能判断市场，能看懂数据背后的逻辑，能结构化分析产品，还要把一个长期、复杂的方向拆成几个可以推进的阶段。团队扩大以后，这些判断要逐渐分散到不同岗位，不能每次都等创始人给答案。
护城河阶段的团队配置
人数增加后，一个很常见的动作是照着大公司补岗位。有人从大厂加入，习惯了每件事各有负责人，于是团队开始考虑绩效体系、专职财务、法务和更多管理层。
Rick 特意提醒大家，团队有了一点规模，也不要立刻补齐所有配置。新增一个岗位，会增加新的汇报、交接和协调成本。它解决的问题如果还没有频繁发生，组织就会先变重。
可以先列出过去一个月反复出现、已经影响收入或产品进度的问题。合同和合规每周都在卡项目，再考虑稳定的法务支持；财务复杂度已经占用创始人大量时间，再补专业能力。“到这个人数应该有了”并不足以支撑一次招聘。
Rick 希望这个阶段仍有大约 15% 的成员可以主动发现问题。三十人团队里，大约四五个人分布在不同岗位，持续判断产品下一步要解决什么。其他人把问题系统拆解并落地，团队才不会只剩下自上而下的任务分发。
他们会做竞品分析，也会复盘团队日常工作。一次功能延期，不能只停在“开发时间估错了”；要继续问，是目标不清、信息没有提前同步、产品方案反复变化，还是技术路径选错。原因找准，下一次才知道改流程、改方案，还是改人员配置。
Rick 会让运营、客服练习竞品和数据分析，让开发继续理解交互与用户需求。不同岗位都知道产品为什么这样做，日常工作里发现的问题才不会只停在各自的工单里。
AI 把执行变快以后，更难的是发现正确问题
Rick 在开头展示的人才模型里，中间层是能够独立完成任务、系统解决问题的人，最上面一层是能发现正确问题的人。
AI 已经能接过越来越多写代码、整理资料、生成页面和执行流程的工作。只会照着完整任务单交付的成员，能提供的增量会越来越少。能够从零散反馈里发现问题、判断问题是否值得解决，再组织人和 AI 去验证，更难被工具替代。
AI 时代更需要发现并解决问题
Rick 的团队会把这种能力放进日常讨论里练。每个人都要表达自己的判断，也要接受其他人的追问。看到一组数据，先把假设、证据和反例分开，不急着选择最符合自己预期的解释。
他用招聘程序员举过一个例子。团队先说清楚这个岗位进来要解决什么问题，再倒推需要哪些经验和能力。讨论从“会不会某个框架”回到工作结果，岗位要求也会具体很多。
遇到定价问题，团队还会从成本、用户得到的价值、套餐锚点等角度分别分析。几种答案摆到一起，再决定哪条路径更符合当前产品。
这种能力靠反复分析、公开表达和真实工作积累。思考框架只能整理已经掌握的信息；缺少行业知识和用户经验时，连该追问什么都很难判断。Rick 的团队要求成员持续学习、分享并接受追问，最后再回到实际产品里验证。会思考，也要有足够多的知识可以调用。
从一个人走向团队，可以先做这三次判断
如果现在只有两三个人，先把目标谈透。确认大家是在验证什么需求，各自愿意投入多久，遇到分歧怎样决定。这个阶段优先找思维互补、能够主动发现问题的人，不急着补齐岗位名称。
如果已经有五到十个人，把用户反馈、数据和跨岗位学习固定下来。每周选一个真实问题共同分析，让新成员理解产品怎样做决定，也让判断逐渐从创始人一个人手里分出去。
如果团队接近十五到三十人，先确认护城河来自哪里，再补能力。每新增一个岗位，都要回答它正在解决哪个反复发生的问题。保留几位分布在不同位置、能主动找问题的人，同时用复盘避免流程越加越重。
所谓招错人，经常是团队当前要解决的问题，和他最擅长的工作方式没有对上。这不等于能力不行。适合成熟流程的执行者，放进还在验证需求的两人团队，可能不知道该从哪里找问题；习惯个人救火的早期成员，到了三十人团队，也未必擅长把经验变成稳定协作。
Rick 的分享把招聘重新放回创业阶段里。两个人、十个人和三十个人没有一套通用配置。先说清当前要验证需求、寻找产品形态还是建立护城河，再定义下一位成员要解决的具体问题。
关于哥飞社群，大家可以看看下面这几篇文章：
650位朋友来到深圳，在哥飞的朋友们2026年中分享交流会里都学到了这些
一个词根、一个白天、175支交卷的队伍——“哥飞的朋友们”上站Hackathon深圳站侧记
我的4000人出海创业社群里，靠SEO赚到钱的人都做对了什么？
2025年快要过去了，这一年里社群朋友们都有哪些进步？有人月入万刀，有人两年百万刀
是时候给大家好好介绍一下哥飞的社群了，毕竟刚被二十年站长大佬夸过
如果大家对哥飞社群感兴趣，可以加哥飞微信咨询了解。
微信搜索框，输入 361079，点击查找 QQ 号，就能加哥飞微信了。
哥飞微信