产品观：从做技术产品到做业务产品
适用范围：产品经理、技术转型产品者、产品负责人、创业者、技术管理者，以及在 AI 时代希望理解产品思维、需求洞察、数据决策与内部创业的从业者。适用于产品管理、需求分析、用户反馈处理、数据驱动决策、内部创业等场景。
更新摘要（v2 · 2026-08 更新）：
- 结构化升级为 6 节骨架（导言 / 核心方法论 / 关键流程 / 工具与实战 / 常见误区 / 进阶延展）
- 原文为访谈重构叙事篇，无 AI 时代注解，本次补充 2026 年 AI 时代解读
- 本文无 Mermaid 图，以结构化叙事与表格呈现
- 将原文六大部分（创新产品之路 / 语雀两度生死局 / 产品经理三大能力 / 用户反馈不等于需求 / 数据与决策 / 内部创业与运营）重组进 6 节骨架
1. 导言
1.1 关于本文
从淘宝赛马的惨败，到"中国版 Pinterest"的遗憾收场，再到支付宝体验技术部的创建与语雀的两度生死——玉伯的产品之路，是一条从技术人到产品人的漫长蜕变。本文沿着时间线，聊透他的创新折腾、产品方法论，以及那些在数据与用户反馈之间走过的弯路。
1.2 2026 年 AI 时代解读
玉伯"技术是工具，产品是目的"的产品观在 AI 时代更加深刻。当 AI 让"做什么功能"的实现成本大幅降低，产品经理的核心能力（需求洞察、抽象设计、未来洞见）反而更加稀缺。AI 时代，产品经理要学会用 AI 辅助需求分析、数据决策，但"用户反馈不等于产品需求""数据不绑架决策"的原则依然适用。
1.3 全篇回顾
如果要用一句话概括这整段内容，那或许是玉伯自己说的那句——"技术不是万能的，技术只是工具，技术是产品的实现手段。"
从做技术产品到做业务产品，从"我觉得这个功能很酷"到"用户真正需要什么"，从看 MAU 兴奋到看自然留存率清醒——这条路，玉伯走了十几年。核心方法论可以浓缩为三个能力（需求洞察、抽象设计、未来洞见）、一个原则（弱水三千只取一瓢）、和一种心态（做工具还是得有良心）。
2. 核心方法论
2.1 创新折腾的三大收获
从 UED 到赛马，从赛马到 Pinterest，每一次折腾都以失败或遗憾告终。但这些经历并非白费，玉伯提炼出了三个关键认知：
- 技术是工具——"真正的技术深度可能在学术界和科研实验室，而在大厂里，所谓的技术深度往往只是工程成熟度。很牛的产品，往往并不代表用到的技术就很牛。"
- 做事需团队——很多事情单枪匹马是干不成的，需要有团队才有机会把一些事情做得更长远或更有可能性。
- 心态靠历练——"每次看到希望又跌下来，再次看到希望又跌下来，像过山车一样，这让自己遇事时变得比较冷静。"
三大收获概括起来：技术是工具、做事需团队、心态靠历练。
2.2 产品经理三大核心能力
能力一：需求洞察力——领域知识是地基
产品经理必须要有需求洞察力。需求洞察力的关键来源，是产品经理在特定领域的专业知识积累。领域知识的积累是产品经理具备需求洞察力的核心要素。此外，需求洞察力来自产品经理对用户的好奇，要对用户的用法能感同身受，要有一种灵魂出窍和灵魂附体的感受——"灵魂出窍"是跳出自身视角俯瞰全局，"灵魂附体"是钻进用户的身体感受他们的喜怒哀乐。
能力二：抽象设计能力——没有对错，只有理念
产品经理必须要有抽象和设计能力。你在做产品的时候可以洞察到很多用户需求，但你不可能每个需求都用一个产品功能去实现，删繁就简的过程，就需要抽象设计能力。拿语雀举例，在文档里设计了斜杠命令，这是一个功能抽象。抽象设计往往没有对错，内蕴的是产品设计理念。抽象是把需求化繁为简，而设计是化抽象为具象。
能力三：未来洞见与规划决策能力
产品经理需要有未来洞见和规划决策能力。面对纷纷扰扰的各种用户声音时，面对各种相关方的质疑甚至否定时，产品经理必须要能看见未来，能和核心团队成员一起有内心的笃定，同时面对各种短中期的利益时，能有取舍判断力，敢于说不，同时又能不伤着对方。
三大核心能力构成递进关系：需求洞察力解决"做什么"的问题，抽象设计能力解决"怎么做"的问题，未来洞见解决"为什么做"和"不做什么"的问题。
2.3 用户反馈不等于产品需求
面对这么多反馈，首先要分清楚两个概念：用户反馈和产品需求是两个东西，绝对不能直接把用户反馈当成产品需求。从用户反馈到产品需求还需要经过产品经理的专业转化。
更多用户反馈，反映的是用户使用过程中的情绪，反馈是用户情绪的一个出口。作为产品经理，非常有必要去看用户反馈。
2.4 XYZ 思维
很多时候，用户给的反馈，你以为是一个需求，其实不是，而是用户在给你解决方案。产品经理要学会 XYZ 思维：用户给你的是 X，你要去挖背后的 Y，甚至这个 Y 还是解决方案，你要继续挖 Z，你要挖到三四层才会知道原来用户是遇到了怎么样一个具体问题。
张小龙在《微信背后的产品观》里讲过，比如很多人都希望朋友圈有分组，挖到最后的需求并不是要分组，而是大家发朋友圈不想让部分人看见。在微信场景里，分组就不是最优解法，微信最终选择的解法是定向屏蔽。
2.5 "弱水三千只取一瓢"
做产品还要有个心态，叫"弱水三千，只取一瓢饮"。语雀每天也有几百人在教语雀做产品。这么多用户反馈里，能抽象总结出来的产品功能点往往非常多。是否都要去做？还要取决于产品团队对产品本身的思考和定位，同时还要考虑到团队的产研能力。每个交集下来，都是弱水三千取一瓢，最后从一瓢瓢里不断取下去，剩下的最后一瓢，才是当下需要去做的。
2.6 数据是辅助决策，不是绑架决策
曾经我们有一个运营同学，想做数据挖掘，想通过科学的数据分析之后，从一堆用户反馈里推导出语雀应该做什么产品功能。曾有一段时间迷信过这类数据，但最终发现这个方式不对，走过一段弯路。因为最后我们发现，数据的真正作用是辅助决策，数据一定不能绑架决策。
"做工具还是得有良心，这是一个感性判断。一旦看数据很容易短视，这让我后怕。最终我们的经验是，数据是辅助决策的，最终决策还是得来自于产品的清晰定位和团队的长期信心。"
2.7 佛学"业"的创业观
创业其实很多时候可分成两种思路。第一种创业思路，就是为了钱或者是为了创业而创业，很多人创业都是被上市故事绑架了，这种创业可以形容为"跳悬崖"，就是在玩九死一生的游戏。
玉伯自己的创业核心，还是回到"业"本身。"业"是佛学里面的一个概念，就是把自己内心想做的事情做完，同时你想做的事情也能帮到别人，这就是业。"创"就是创造，就是把业完成的过程。留在一个公司里，成为一个技术专家，通过大公司的平台去做自己想做的事情，这也是创业。
3. 关键流程
3.1 语雀两度生死局
体验技术部站稳脚跟之后，玉伯操刀了工具型产品语雀。2016 年从一个技术团队的内部孵化项目起步，到 2021 年蚂蚁成立智能协同事业部以独立 BU 运作。这五年间，它经历了两次差点被砍掉的生死时刻。
孵化期：2016 年，体验技术部有个创新产品孵化机制叫策马扬鞭，语雀是参与的项目之一，出发点是"让技术人写文档更简单"。到 2018 年在阿里内部语雀的 DAU（日活）破万，代表产品能孵化出来的重要节点。2018 年也因此被称作国内的"文档爆发年"。
第一次生死：2018 年 7 月，阿里确定要做钉钉文档，语雀把三分之二的人输送给了钉钉，成为钉钉文档的初始团队。语雀只剩下七八个人，团队非常灰心，但大家又很有信念。于是开始重新招聘，2019 年 4 月语雀商业化开始，算是又活了过来。
定位之争：为什么公司没有直接把语雀整体并入钉钉文档？玉伯不断向决策者阐释一个关键定位差异——"阿里文档是做 Google Docs，语雀是做 Confluence"。两者产品定位是不一样的。再加上语雀在内网已有大量用户量，内部不可能直接关停，最后才留下几个人。
感谢无招：钉钉负责人无招（陈航）觉得"钉钉也是从无到有、好不容易创新出来的，语雀也是，所以对创新产品，公司应该要更有耐心"。这句话保全了语雀的火种。
第二次生死：2020 年，阿里云想把语雀、钉钉文档等文档团队聚集起来成立独立的阿里文档事业部。这时无招急了，对无招来说文档是钉钉很重要的一部分，独立发展文档并不妥当，这使得集结起来做阿里文档的事情又黄了。无招间接又帮了语雀一次。
最终正名：一直到 2021 年 6 月，正式成立了智能协同事业部，以独立 BU 运作语雀，语雀才算变成公司的一块业务。在 2021 年之前，整个语雀团队都一直有身份焦虑。
3.2 知识库概念的推行
语雀的核心定位，并非一开始就是"知识库"，而是经历了一次重要的认知升级。2016 年确实是文档，借鉴了石墨文档。2017 年更多学习的是 GitHub——语雀其实就是文档界的 GitHub，GitHub 的核心是代码仓库，那么对应的文档仓库是什么？就是知识库。从 2017 年语雀就以知识库去定位。
3.3 比 Confluence 更灵活的结构化定位
语雀能在阿里内部流行起来，除了好用的 Markdown 编辑器之外，更关键的是它在知识组织结构上切中了一个痛点。Confluence 很容易知识僵化——"在阿里，大家可能都听过一个词叫拥抱变化，组织结构一变化，Confluence 的文档就很容易变成一个荒岛"。
语雀切的是更灵活的结构化组织这个点，没有像 Confluence 一样去做很大的一个目录树，借鉴了 Wiki 词条的组织方式，让文档之间都是平等的，文档树则通过目录编排去实现。这样在组织变化时，迁移成本会比 Confluence 低很多。
3.4 需求取舍：宁可开放 API，也不实现管控需求
集团内部各团队提出大量需求，但很多都被语雀团队拒绝了。最典型的就是很多团队都希望有个知识门户，团队可以做整体管控。语雀的做法是：宁可开放 API，让大家自己去基于语雀的 Open API 去定制包装，而不是我们去实现。因为每个团队的管理方式不同，只有需求方自己最懂自己的需求。
3.5 数据决策的关键流程
拉新拦截教训：曾经语雀焦虑用户增长，学其他网站做拉新，比如未登录时不让看，通过这种方式拉升注册用户数。从数据上看，用户注册数的确增加了，但时常有用户反馈不好用。后来把登录拦截去掉了。拦截虽然能带来短期注册上涨，然而用户的不爽，会影响产品的长期发展。
北极星指标：语雀目前最核心的两个指标，一个是付费客户数，代表有多少客户认可语雀；另一个是自然留存率，反映语雀的基础产品力。语雀确定这两个关键指标，花了大半年不断讨论才达成共识。
MAU 是虚荣指标：早期看 MAU（月活）、DAU（日活）等数据。语雀的 MAU 很早就过千万了，但后来才想清楚，如果付费客户数没上去，MAU 越高，成本越大。虚荣指标只是虚荣指标，并不代表产品的健康发展。
3.6 产品与运营关系三阶段
在语雀的发展过程中，产品和运营的关系经历了三个阶段的演变：
- 对立关系：产品团队专注做功能，运营团队专注推增长，偶尔因为优先级和资源分配产生摩擦。
- 一体化：产品团队开始理解运营的需求，运营团队也开始理解产品的定位和边界，双方围绕同一个北极星指标协作。
- "左脚右脚"：产品做出好的功能，运营把好产品推给对的人，用户反馈回来后再迭代产品，循环往复。这不再是两条平行的线，而是同一个人走路时的两条腿。
4. 工具与实战
4.1 创新产品之路：三次折腾
淘宝赛马：2010 年前后，淘宝发起"淘宝赛马"孵化项目。玉伯加入了一个社交方向的赛马项目。然而第一版 PRD 就花了一个多月，等到做开发时，人心已经有点不齐。最终玉伯选择了主动离开。赛马项目启动时每个人写了一个心愿，塞到信封里封起来，说等成功时再拆开来看——"现在回想起来，再也没机会拆开了。"
"中国版 Pinterest"：赛马失败后，玉伯想做"中国版的 Pinterest"。项目不算失败——后来项目里其他小伙伴选择出去创业，获得了投过 Pinterest 的投资人的青睐，杭州那家公司发展成了花瓣网。玉伯选择留在阿里。
来到支付宝：创新产品接连受挫后，玉伯来到支付宝的契机颇为偶然——支付宝首席架构师鲁肃在分享中反复提到了两次"前端"。2012 年 2 月，他到了支付宝。
"All In 无线"：三波人的选择：2013 年阿里喊出"All In 无线"，前端分成三波：第一波转 iOS，第二波跟着主管做创新业务，第三波是被剩下的。玉伯属于第三波，选择了留下来做既有的 PC 业务。正是这个"留守"的选择，为后来体验技术部的诞生埋下了伏笔。
4.2 Ant Design 的诞生：设计语言、开源、长期主义
Ant Design 的底层逻辑不只是"一套 UI 组件库"，而是"设计语言"这个在当时颇具前瞻性的概念。玉伯给 Ant Design 做了正式立项，确定前端负责人和设计负责人。做 Ant Design 也源自信心的积累——早期做过淘宝的 UI 组件库，"心里已经有了七八成把握"。
做 Ant Design 会一直强调长期主义，要有三五年的长期坚持，才有可能做出一点成绩。Ant Design 同时也是一张吸引人才的"饼"——开源的影响力带来了正循环：有人坚持做开源，开源做出影响力，从而进一步吸引更多人加入。
4.3 体验技术部：前端 + UED 的融合实验
2014 年，玉伯一边支撑业务，一边从零开始搭建 UED 团队，最终将前端与设计整合为一个叫"体验技术部"的团队。设计师和前端工程师放在一起产生了化学反应："这边不缺程序员，缺设计师，刚好互补。提升用户体验，跟前端的实现息息相关，跟设计师的设计也息息相关。两者一拍即合。"后来能做 Ant Design，跟设计师与前端工程师的化学反应息息相关。
4.4 已读未读案例：深入沟通后用户自己找到了答案
有一个语雀用户，很生气地反馈为什么文档发出来后无法看到有谁读了。对产品经理来说，这是一个"指定人群已读并提醒"的功能。后来玉伯跟他深入沟通，了解到原来他在负责公司培训，有些培训材料要提前发给学员看。玉伯建议他拉一个群用钉钉的已读未读来看大家是否已收到。后来这个用户自己研究出了更好的解决方案，用钉钉的消息标签功能来做。"有时候跟用户沟通，深入了解使用场景后，往往用户自己就能找到合适的解决方案。"
4.5 北大附中的惊喜
北大附中使用了语雀，除了常规的文档和知识库用法，居然用语雀的话题功能来组织同学进行线上辩论赛。参与的同学都很认真，正方和反方发言有理有据。在北大附中老师主动说之前，玉伯自己都不知道语雀还能用来干这件事。
5. 常见误区
5.1 技术深度 = 工程成熟度
误区：在大厂里谈论技术深度和广度。
正确认知：真正的技术深度可能在学术界和科研实验室，而在大厂里，所谓的技术深度往往只是工程成熟度。很牛的产品，往往并不代表用到的技术就很牛，两者有交集，但并不多。
5.2 把用户反馈当成产品需求
误区：直接根据用户反馈做产品功能。
正确认知：用户反馈和产品需求是两个东西，绝对不能直接把用户反馈当成产品需求。更多用户反馈反映的是用户使用过程中的情绪，是用户情绪的一个出口。要用 XYZ 思维挖到真实问题。
5.3 迷信数据推导产品功能
误区：用数据科学的方法从用户反馈中"算"出该做什么功能。
正确认知：数据的真正作用是辅助决策，数据一定不能绑架决策。一旦看数据很容易短视。最终决策还是得来自于产品的清晰定位和团队的长期信心。
5.4 追逐虚荣指标
误区：关注 MAU、DAU 等流量指标。
正确认知：虚荣指标只是虚荣指标，并不代表产品的健康发展。语雀的 MAU 很早就过千万了，但如果付费客户数没上去，MAU 越高，成本越大。要找到符合产品定位的北极星指标。
5.5 为了上市而创业
误区：为了钱或为了创业而创业，被"融资-上市"的故事绑架。
正确认知：很多奔着上市去的创业就是在玩九死一生的游戏。围绕营收去做很容易偏离本心。创业核心应回到"业"本身——把自己内心想做的事情做完，同时帮到别人。
6. 进阶延展
6.1 2026 年 AI 时代视角
AI 对产品管理的影响：
- 需求洞察：AI 可辅助分析海量用户反馈，但"用户反馈不等于产品需求"的原则不变，仍需要产品经理的专业转化；
- 抽象设计：AI 可辅助生成方案，但"抽象是化繁为简，设计是化抽象为具象"的取舍能力仍靠人；
- 数据决策：AI 让数据分析更强大，但"数据是辅助决策，不能绑架决策"的清醒依然关键。
AI 时代的产品经理，核心竞争力从"做功能"转向"需求洞察 + 产品理念 + AI 协作"，这正是玉伯产品观在新时期的延伸。
6.2 核心方法论浓缩
这条路的核心方法论，可以浓缩为三个能力（需求洞察、抽象设计、未来洞见）、一个原则（弱水三千只取一瓢）、和一种心态（做工具还是得有良心）。
6.3 延伸阅读
- 《超级访谈：对话玉伯》（极客时间）
- 本系列后续篇章：成长观 / 管理观
- 《学会提问》—— XYZ 思维参考
- 张小龙，《微信背后的产品观》
本内容基于《超级访谈：对话玉伯》重构整理，并补充 2026 年 AI 时代解读。适用对象：产品经理、技术转型产品者、产品负责人、创业者、技术管理者。