哥飞记录的深圳产品年终分享中，Ben复盘了WaytoAGI与飞书多维表格两个10倍增长项目。文章详解了增长发生的前提条件：内容或功能提前准备就绪。同时分享了飞书的产品方法论，包括深度体验竞品、逆向工作法、用户共创与需求池排序，对产品经理、创业者及独立开发者具有实操参考价值。
Tags:大家好，我是哥飞。
Ben 在现场复盘了两个被他概括为“10 倍增长”的项目。
一个是 WaytoAGI：一场精准的内容合作，把已经积累的知识库推给了更大一批 AI 用户。
另一个是飞书多维表格接入 DeepSeek：相关 AI 功能在一两个月里增长约 10 倍，访问量一度让功能挂过三次。
去年 12 月的深圳年终分享交流会上，Ben 把这两次增长背后的产品准备讲了一遍。
Ben 做过豌豆荚和飞书产品，后来回到飞书做多维表格，也是 WaytoAGI 从 1 到 10 阶段的策划参与者。WaytoAGI 靠内容合作扩大访问，多维表格提前把新模型做成功能，用户进入产品后可以立即使用。两次增长走了两条路，也都建立在已经可用的内容和产品上。
10 倍增长之前，他们已经做了什么
WaytoAGI 早期已经积累了不少 AI 内容和社区用户，但还缺一次能触达更多精准用户的传播。
团队准备做直播时，拿到了一批 KOL 名单。里面很多人，Ben 自己都没有听过。他另外找到了在 AI 圈有影响力、受众也匹配的潘乱，邀请他来做主持。
邀请之前，双方并不熟，只是网友。Ben 先请潘乱看了一遍 WaytoAGI 的知识库，再发出主持邀请。对方看完后答应参加，直播内容后来又被同步到公众号和其他渠道。Ben 把这段经历概括为 WaytoAGI 的 10 倍增长。现场展示的是社区后来的整体规模，没有给出同一指标的完整起止数据，所以这里更值得看的是它怎样用内容合作把已有知识库推给更大一批精准用户。
主持人本身懂 AI，关注他的人也会使用 AI 产品。新用户进入 WaytoAGI 后，看到的是一个每天更新、已经积累了大量 AI 资料的知识库，可以继续搜索和阅读。直播带来了第一批集中访问，知识库里的内容决定这些人进来后还有没有东西可看。
飞书多维表格的增长来自另一条路。
团队在 DeepSeek 大规模爆火之前，已经把相关能力接进产品。Ben 在 DeepSeek R1 发布后，用 Cursor 花了两三个小时做出第一版插件并上线。春节期间 DeepSeek 爆火，团队随即继续补产品、办直播，邀请创作者演示真实用法。用户看完一个案例，马上就能进入多维表格做出自己的结果。
Ben 现场给出的数据是：相关 AI 功能在一两个月里增长约 10 倍，约 80% 的传播来自用户自发分享案例。流量放大后，功能挂过三次，远远超过团队原来的容量预估。
DeepSeek 刷屏时，多维表格不需要从需求讨论开始，现成功能可以直接加大投入。用户做出的表格和自动化案例又成为下一轮传播内容。WaytoAGI 也是一样：直播开始前，知识库已经积累了足够多的内容。
要提前完成这些准备，第一步是把已经跑出来的产品看够。
先看够，再决定做什么
Ben 在飞书做协作产品时，团队会把已经跑出来的产品系统看一遍。他们不只看首页和功能列表，还会收集更新日志、公开路线图和产品博客，找用户访谈，再把 Zoom、Airtable、Google 套件这些产品真正用起来。
Zoom 被团队发现后，很快就部署进会议室。大家连续使用，记录每天卡在哪里、哪一步特别顺、为什么愿意继续用。有些差异，注册一个账号、随便点几下按钮根本看不出来。
飞书后来把文档、聊天、会议和权限打通。在聊天里发出文档链接，权限可以跟着处理；在一个产品里，可以直接引用另一个产品的内容。用户少了来回切换和重复授权，这种连续使用中的差异，比多几个孤立功能更容易影响选择。
我之前写过一篇《如何做出好产品》。产品判断很难从一张白纸上想出来。把竞品的定价页、首次使用流程和更新记录摆在一起，再亲手完成一遍核心任务，才能看到用户为什么留下，又会在哪一步离开。
现在可以让 Deep Research 和 Agent 整理竞品更新、用户评价和公开路线图，但自动总结不能代替亲手使用。什么是真需求，什么只在介绍页里好看，最后还是要回到用户的操作路径里判断。
一个成熟产品里，功能永远做不完。Ben 举了传统表格的例子：它的使用人数很多，但和 Google Sheets 这类成熟产品相比，继续补几个小功能很难形成差异。飞书会先保证这部分稳定可用，把更多精力投入文档协作、多维表格和产品之间的连通。用户在每天的工作路径里能感知这些差异，投入才可能改变选择。
这个选择放到一个独立网站里，可以先把首次使用拆成四步：用户从搜索结果进来后能不能看懂，输入内容后多久拿到结果，结果值不值得保存或分享，付款前有没有足够信任。把每一步的退出和反馈记下来，再决定下一周改什么。后台里一个几乎没人打开的设置项，即使做得很精致，也不会改变网站的留存和收入。
比如做一个图片处理工具，首页最先要解决的通常是文件能否顺利上传、处理速度是否足够快、结果和用户预期是否一致、下载时有没有突然出现的限制。这里任何一步卡住，用户都会直接离开。至于账户页里能换几套主题、设置页有没有动画，可以等核心任务稳定以后再做。
小产品可以把“可感知路径”拆成一串具体动作。先列出用户从进入页面到拿到结果的每一步，再看哪一步退出最多、抱怨最多、耗时最长。资源有限时，先修这一步。下一次迭代仍然看同一组数据，确认修改有没有让更多人完成任务。
多维表格早期几次面临被砍。团队一开始不确定这个品类能不能做大，继续观察后发现，真实使用数据一直不错，接受它的用户也在增加，才把它保留下来。
个人开发者面对一个访问量还不大的站，可以先看有没有人连续几天回来、保存结果、主动反馈。这些动作说明某个任务真的在重复发生，可以继续追。访问不少，所有人用完即走，也没人愿意留下联系方式，就要检查用户是否只被标题吸引，页面里的结果有没有解决问题。不能只拿总访问量决定继续还是停止。
先写清用户结果，再让用户进来共创
Ben 提到了亚马逊的逆向工作法：先写产品发布时希望告诉用户的内容，再倒推需要做哪些功能。
如果一段产品介绍里只能写“功能很多、体验很好、用了 AI”，用户最后能得到什么还没有想明白。带着一份功能列表开工，开发越快，返工也可能越快。
飞书内部会把方案写成信息密度很高的文档。参会的人先读文档，直接在具体位置写评论；问题讨论完，会议就结束。产品经理不需要现场补齐方案漏洞，工程师也不用猜一句模糊需求到底是什么意思。
飞书早期有一段时间没有专职测试人员，产品经理和工程师要自己把功能跑完、自己发现问题。发布以后继续收集数据，再把做成和做坏的原因写进复盘。当初的假设和取舍留在文档里，三个月后数据不对，才能回头检查判断错在哪里。
这种做法还解决了一个常见问题：方案只有负责人口头讲得清，换一个人接手就不知道当初为什么这样做。文档里如果写了目标用户、核心问题、预期指标和舍弃的方案，开发时遇到分歧可以回到同一份依据，发布后也能把真实结果和原来的判断逐项对照。
没有专职测试人员的那段时间，产品经理和工程师必须亲手跑完整流程。谁提出需求，谁就要看到它怎样从页面入口走到最后结果。功能上线后出了问题，也很难把责任推给另一个岗位。这种压力迫使需求和验收写得更具体。
个人开发者可以把这套文档压缩成一页：用户是谁，他现在怎样完成任务，第一次使用要得到什么结果，哪一个数字可以判断功能是否有效。四项里有一项写不清，就先补访谈、截图或现有数据。等问题写具体，再让 AI 生成页面和代码。
飞书早期找的共创客户，包括被投资企业，也包括正在使用 Google Workspace、Slack 的用户。这些人已经有协作习惯，知道当前工具哪里不顺，也能够判断新方案有没有价值。
后来进入汽车、知识付费等行业时，团队再找对应行业的客户一起做。行业不同，组织方式、权限、审批和信息流都不一样。团队在办公室里模拟十遍，也比不上真实用户跑一次流程。
汽车行业会遇到经销商、门店和总部之间的权限问题，知识付费业务会关心课程、销售和学员信息怎样流转。产品团队如果只拿自己熟悉的办公方式设计，很容易把行业里的关键步骤省掉。找对应行业的用户共同试用，看到的是每天真实发生的审批、交接和重复录入。
第一批共创用户也不需要很多。三五个人愿意把完整任务跑一遍，价值通常高于几十份只问“喜不喜欢”的问卷。观察他们在哪里停下来、要向同事确认什么、最后还要导出到哪个工具，需求会比一句意见具体得多。
Ben 会先确定目标用户和目标需求。灵光一闪可以补充方案，不能直接进入开发计划。飞书早期还会给功能设渗透率目标：影响用户太少的功能，不会长期投入大量人力去优化小数点后的变化。团队先确认它影响多少人、是否位于关键路径，再决定继续打磨还是暂时放下。
个人开发者第一次找用户聊，不要先问“你想要什么功能”。做简历工具，就看他从上传资料到导出文件卡在哪里；做图片工具，就看他拿到结果以后还要去哪个软件继续处理；做 SEO 工具，就看站长每天在重复复制、整理和比较什么数据。
用户说“加一个批量功能”，可能是因为每天在重复同一个操作几十次。用户给出的方案不一定适合，他反复遇到的问题需要被记下来。
把反馈留下来，让需求自己排队
产品有了一批用户以后，反馈会越来越多。全部留在零散聊天里，几天后就找不到；只靠产品经理记忆，声音最大的人又容易占据全部注意力。
Ben 展示了一个持续运行的需求收集表。用户提交反馈后，内容会自动汇总；其他用户可以投票、评论，团队再根据数量和真实使用场景排序。
他提到两个投入很多精力的用户：有人累计提交了几百甚至上千条反馈；还有人把上千篇帮助文档看了一遍，整理出几百条意见。团队从这些反馈里发现遗漏，也能看到哪些问题在真实使用里反复发生。
多维表格的需求池可以按“+1”数量排序。排在前面的需求未必直接给出正确方案，但它能证明问题反复发生。团队先看有多少真实用户遇到，再结合是否阻断核心任务、是否影响留存或付费，决定怎样解决。
独立网站可以做一个轻量版本：在产品里放反馈入口，把问题统一收进表格，记录用户类型、出现页面、发生频率和付费状态。每周挑出重复出现的几项，回到页面和数据里验证。有人要求增加按钮，就看他是否找不到下一步；有人要求批量处理，就看他是否每天重复几十次相同操作。先确认问题，再决定方案。
需求池里还要保留没有立刻开发的反馈。今天只有一个人提出的问题，三个月后可能连续出现；某个付费用户反复遇到的阻断，也可能比几十个免费用户随口提的功能更急。记录时间、用户类型和使用场景，等信号积累起来再重新排序。
开发完成后，再回到原始反馈找那批用户验证。用户原来卡在导出，现在能否独立完成；原来每天复制几十次，现在节省了多少步骤。把回访结果记进需求池，团队可以直接看到：完成率有没有上升，操作步骤有没有减少，原来的用户有没有继续使用。
开发越快，越要少走错路
WaytoAGI 在直播前已经有每天更新的知识库，飞书多维表格在 DeepSeek 爆火前已经上线插件。一个准备好了内容，一个准备好了功能。集中访问到来后，用户都能马上找到下一步。
现在一个人做网站，页面和代码都能很快生成。但找到真问题、选出最该做的一步，再把它做到用户愿意回来、愿意付费、愿意告诉别人，花的时间并没有因为 AI 变少。
开工前，先找几个已经跑出来的产品，把它们的核心任务亲手跑一遍；把用户第一次完成任务的路径写出来；找几位真实用户，看他在哪里停下；上线以后，把反馈收进同一个需求池，每周重新排一次优先级。
当新模型、新平台或新渠道带来关注时，不用才开始猜用户要什么。产品已经能帮他完成任务，进来的流量才有可能留下来。
关于哥飞社群，大家可以看看下面这几篇文章：
650位朋友来到深圳，在哥飞的朋友们2026年中分享交流会里都学到了这些
一个词根、一个白天、175支交卷的队伍——“哥飞的朋友们”上站Hackathon深圳站侧记
我的4000人出海创业社群里，靠SEO赚到钱的人都做对了什么？
2025年快要过去了，这一年里社群朋友们都有哪些进步？有人月入万刀，有人两年百万刀
是时候给大家好好介绍一下哥飞的社群了，毕竟刚被二十年站长大佬夸过
如果大家对哥飞社群感兴趣，可以加哥飞微信咨询了解。
微信搜索框，输入 361079，点击查找 QQ 号，就能加哥飞微信了。
没有评论:
发表评论