我的 2025
有了孩子以后，就能更敏锐的感受到时间的变化，比如三个月前进了幼儿园的托班，这一年长高了一个头，学会了不用尿不湿大小便。如今回望这些看似无比琐碎的细节，曾经都在某些时间段牵动着我们的内心，构成了我们的烦恼和喜悦，最终又变成了他的成长，清晰的勾勒出这一年时间的变化。
那么，让我们慢慢展开我的 2025，古法写作，想到哪写到哪，提前感谢你的耐心阅读。
关于一然#
2-3 岁之间，小孩子的自我意识逐渐形成，做事倔强。比如虽然掌握了勺子吃饭，但是一定要大人喂。到了托班却被老师神奇的驯服了。我们问老师你是怎么做到的？老师说，只是在喂饭的时候说自己手很疼，一然就体谅了然后开始自己吃。
那一刻我突然意识到，小朋友天然具有很强的同理心，他们没有丰富的语言能力，却能够灵敏的感知成年人的情绪来理解世间万物。长大成人的我们，都会披上厚厚的铠甲，不容易被 ego 情绪困扰，却也丧失了这份敏锐。
自从九月入托以来，第一周就得了肺炎，过程坎坷，但是一然逐渐适应了幼儿园的生活，出勤率也稳步提升。过程中跟老师接触的多了，对幼儿园也有了新的认知。这是一个一走进去就会能量满满的地方，每个孩子和老师都互相提供高情绪价值，同时也带动家长参与，每一个节假日都要给孩子精心准备同时也看到惊喜；这也是一个需要小心翼翼时刻敬畏的地方，每个孩子都是一个家庭的中心，不容有失，人生中第一次为儿子赔礼道歉也让我印象深刻。
同样是一份工作，如果让我去当幼儿园老师，我自问没有这份耐心。但是转念一想，我们也跟一然说"爸爸妈妈去公司工作，你去幼儿园工作，大家都有自己的工作"。大家都在彼此的岗位闪闪发光，这也是社会的美妙。
结束了微软的旅程#
今年还有一个很大的变化，那就是结束了微软的这段旅程。两年前入职的时候感觉自己要好好沉淀一下，至少待五年以上，没想到短短两年左右的时间就要告别，虽然很不舍，但是天下本就没有不散之筵席。
关于为什么要离开，理由很多，最主要的还是中美地缘政治问题带来了不安全感。《反脆弱》书里写到的：
“风会熄灭蜡烛，却能使火越烧越旺。”
— Wind extinguishes a candle and energizes fire.
这个世界的随机性在疫情发生后正在不可避免的越变越大，唯有折腾才能反脆弱。
一封短短的离职邮件我写了好几天，其中有几段浓缩了我所感受到的这里的文化、思维底色、以及可爱的同事们互相尊重、幽默、体面的协作模式。对于这段旅程，我只有感激。
感谢我的老板们，让我看到了一个 20-30 年经验的 Manager 是如何用 “Coach（教练）” 的方式指导工作、关爱人、以身作则，同时有自己独特的能力，与团队互补。冬天清晨五点半亮起的 Teams 头像是连接中美团队的桥梁，技术讨论时无关职级的争论是对技术的纯粹热爱。
还有那些才华横溢、触及技术职场天花板的 IC 架构师，我见证了他们怎样从一份详尽的设计文档一步步带领团队、落地出真正的产品。从潜在用户规模、技术架构、成本分析、再到阶段性里程碑的清晰定义。他们能精准甄别出什么是不重要的，以及做事情的合适时机。他们是我的 role model，他们张弛有度，但更重要的，始终保持真实的自己。
我也很幸运的参与了两种完全不同的微软产品模式，我也很幸运的参与了两种完全不同的微软产品模式，一个是在每年营收数十亿美元的成熟云服务之上叠加功能，看到了技术之外“创新者的窘境”，新功能的上线往往优先考虑的是对已有产品的影响，团队超过一半的精力要投入在处理安全补丁、迁移/升级系统、CI/CD、可观测性上，从立项到验证功能用户体验的流程被拉的无限长；另一个是从零到一的新云服务，体会了“follow-the-sun” team 24 小时跨时区高强度协作五个月快速上线的极致迭代速度，原来美国团队也是可以疯狂加班甚至不睡觉的（主要还是美国的印度人）。
回想起来，那段日子常常睡眠不足，一天二十四小时都有项目组的同事在工作时间。但是当我在 Redmond 总部办公室被 Maxim 邀请喝他珍藏的 whisky，在深夜听 Tom 跟我畅谈比利时的民俗风情，这一切已经超越了工作的得失，一切都是美妙的。
而这构成了工作真正的意义——它不仅仅是一份关于 Growth 和 Impact 的答卷，更是一段与有趣的灵魂同行的旅途，做自己喜欢同时又对社会有价值的事。
在未来的工作中，我也将提醒自己，在满足基本的物质生活标准时，践行这条标准，然后不计得失的全情投入。
AI Agent 元年#
在微软工作最后这大半年，有机会从零到一构建 AI Agent，近距离全面的了解 AI 和大模型。不得不佩服大老板 Bilal 的远见，在 24 年底，哪怕整个部门的产品线没有 AI 合适的切入口，还是毅然通过 SRE 的角度切入。他的 kick-off 文档里写道，哪怕最后产品失败，但是这让整个团队掌握了 AI 相关的技能，这也是成功了。显然，大半年后，我也因此受益。
我的 2023
家里的领导前段时间参加了妹妹的婚礼，昨天看着婚礼的视频突然有感而发地说，“我看待婚礼的心境经历了四重转变，小时候参加婚礼只知道有好吃的，对到底发生了什么茫然无知；随着逐渐长大慢慢懂得了爱情，开始对婚礼充满期待；直到轮到自己的婚礼，才发现竟然累的有些麻木，只是为了完成那个仪式；再后来有了孩子，看着别人的婚礼，才看到那是一份家庭和责任的承诺。”这段话说在 2023 年的最后一天，也是 2023 年的投影，折射出了我们的变化，有身体上的疲惫，也有心智的成长，更重要的是，我们有了自己的孩子，一切的重心都开始围绕着他转动。
我的 2023 不算太糟，事实上我心怀感激，你看，对于一个父亲来说，没有什么是比看着孩子一点点成长、而家人都还幸福健康更幸运的了。即使周围环境再差，心情也差不到哪去。关于孩子，我写了几封信给未来的他，也记录了这段时间的经历，有兴趣的朋友可以看我的公众号“一然琐记”的历史文章。以前一直想，如果有一天离职了，一定要花一个月时间去全世界旅游，这样才能补偿我工作中的全情投入。结果当现实真的来临时，时间是足够了，不过我的选择还是用来照顾孩子，还有读书。有妥协的成分在里面，但是我也没有觉得太过遗憾。我逐渐开始理解从带娃和工作的平凡生活中找寻快乐，全情投入的生活也不再需要“补偿”。
带娃的过程常常让我得到很多新知，比如说我特别喜欢跟我家娃玩躲猫猫游戏，他每次看见我都会手舞足蹈露出灿烂的微笑。心理学上说人在婴儿时期还不具备万物恒常的感知，眼前不见的事物都以为消失了，所以对每一次相见都分外惊喜。随着人们长大，逐渐对每一次相遇都习以为常。再后来看到了那么多人世的悲欢离合，才又明白过来哪有什么万物恒常，每一次重逢都值得珍惜和惊喜。
再比如说，我亲眼见证了小朋友不断的练习、试错，逐步学会了人生中一样又一样的“大动作”，翻身、坐起、后退、前进，对于家长来说往往比孩子还激动。小朋友们心里没有放弃的概念，累了就趴一会，实在急哭了过一会也就好了。只要看到新鲜玩具在前方，就能被自己心中最原始的“兴趣”驱动着勇往直前。没有过不去的坎，也没有给自己定义所谓“成功”，玩到了就高兴一会，再接着找新的玩具。这不就是巴菲特所说的内部记分卡吗，成年人才这么在乎外界的眼光，小孩只为自己快乐。
2023 年我自己最大的收获也是这个“内部积分卡”，或者说做真实的自己，去体验自己的人生，而不是活在别人的眼光里。于是就没有再统计自己这一年读多少本了，最喜欢的是刘震云写的《一句顶一万句》，看似写的是家长里短、盘根错节的琐碎，实则是人情练达、生动通透的人间百态，看完让人唏嘘感动，于荒诞幽默中触及灵魂，不经意间就仿佛看到了自己周遭的生活。 这一年最喜欢的电影是“长安三万里”，让我想起高中时期那段大家争相以背诵古诗词为美的日子，还有我可爱潇洒的高中同学，哪些翩翩少年在类似军事化管理的校园里，背诵着将进酒、长恨歌以此为乐，真是回不去的美好。
2023 自然也留下很多遗憾，还有一些故事还不能说，也就罢了。
我的开源十年
很幸运，自己从最早在 Github 接触开源到如今也已经有十年多时间，经常有同学问我开源该怎么玩，这次就借着这个契机，回顾一下我这十年的开源旅程，也跟大家聊聊我对开源的理解。
从小白用户到开源贡献者#
在我心中最早埋下对开源认识的种子是 2011 年，那时候读了刘未鹏的经典博文“怎样花两年时间去面试一个人”，发现原来 Github 和开源对找工作有这么大的帮助。然后把博客里推荐的大部分书读了一遍，其中有两本最让我心潮澎湃，一本是硅谷创业之父 Paul Graham 写的《黑客与画家》，里面提到黑客作为一帮全世界最酷的软件工程师，就是通过学习开源代码不断成长的；而另一本是开源运动领袖 Eric S.Raymond 写的《UNIX编程艺术》，里面描绘了大量实用的软件设计哲学和案例（包括著名的 KISS 原则），更让我震撼的是通过开源赋予软件强大的生命力从而起死回生的故事。如今十几年后回过头来再看，这两本书依然可以称之为了解开源文化的必读书目。
那时候种下了对开源向往的热情，遇到相关的事情就会非常积极参与。2013 年的时候开始在学校实验室接触开源 CloudFoundry，那时候 Docker 还没有流行，分布式系统的软件部署非常困难，甚至要从对接虚拟机（VMware VSphere）的 API 部署操作系统镜像开始，熟练工从零开始部署一整套也要好几天时间。那时候实验室给我安排的任务就是简化这个部署流程、缩短部署时间，因为系统最终是要商业化交付的，所以部署还要做到高可用，保证一定的稳定性。
现在想来这还真是个不错的任务，为了编写自动化脚本，我梳理了 CloudFoundry 整体的架构、各组件的功能和作用、不同组件之间的依赖关系、以及实际管控和数据链路的依赖和运转方式，让我对整个系统有了全面的认识。这也给了我很好的启发，让我之后每次熟悉新的开源项目第一步都会采用同样的方法：
- 1）参与开源的第一步是阅读项目文档了解其架构、组件作用和依赖关系，并且实际部署起来玩一玩、看看管控和数据链路如何流转。
很快 Docker 就流行起来了，大家都看到了软件领域将迎来巨大的变革，一时之间起来了数十家创业公司。当时的华人创业圈子为了体现自己的技术优势，一个很好的办法就是比拼在 Docker 社区的 commit 数。我们学校实验室也投入其中，当时的基本策略就是看见 “Good First Issue” 就冲上去认领，因为通常这些任务就是项目维护者给新人入门的最好引导，带着问题学习是参与了解开源的最好方式。让我觉得神奇的是即使 Docker 那么火，大家都跃跃欲试，只要有人宣称要贡献某个功能，大家都礼貌的等待，就算你一时间没有解法，大家也愿意耐心的讨论，而不是粗暴的说“放下，我来”，直到后来我才清晰的明白其中的道理：
- 2） 开源是一个高度注重名誉的社区，你的言行举止需要礼貌得体，而给对方荣誉（credit）就是最好的回报。
当时内心也非常胆怯，看源码遇到问题总是自己先研究半天，直到翻遍了所有文档也得不到答案，才敢抱着试一试的心态冲到 google groups 论坛上去问。结果遇到一帮 Google 的技术大拿耐心的回答我这个小白的问题，这确实给了我惊喜。让我后来也乐意拿着刚学来的知识去回答别人的问题，一来二去就跟圈子里的大神们熟悉了，这也让我理解了什么叫“社区”：
- 3）不要害羞，勇敢的提问，大胆的参与到社区里面，对于社区而言，活跃的出现很重要。
虽然我当时 Go 语言都没完全掌握，但是成熟的 Docker 社区有着完善的文档，足以让一个小白都可以照着文档从头开始把环境搭建好实现代码贡献。我记得我当时给 libcontainer 仓库（后来改名 runc ）提的 Pull Request 歪歪扭扭的基本每一行都被项目作者 Michael Crosby 提了修改建议，最后改完我知道他花的时间一定比自己直接写完这个功能要多的多，但还是不厌其烦的欢迎外部贡献者，这让我第一次萌生了对开源项目维护者的敬仰之情。这也让我看到了开源社区的另外一面：
- 4）把重复的事情自动化、把重复的问题文档化，把更多的时间和包容留给新来的人。
一时之间 Docker 越来越火，但在当时的中文社区相关的技术资料仍然稀缺，学校实验室跟 InfoQ 比较熟，作为早期参与开源贡献的我们就这样机缘巧合地成为了社区早期的布道师。当时的想法也很纯粹，因为写文章投稿能拿稿费，就使劲写文章并且打磨到让编辑满意。有意思的是当时 InfoQ 还老拖欠我稿费，作为学生的我自然是厚着脸皮不停去要。这也是后来我才明白为什么他们老忘记给我稿费，文章投放获得的影响力回报要远比几百块稿费值钱的多，大多数其他投稿的技术人员都不是为了稿费。对于参与开源而言，写文章布道真是歪打正着做的最对的事情了；
云原生技术（2） - Helm Chart 如何做金丝雀发布？
本文作者： 王易可
Helm 持续交付的挑战#
Helm 设计之初就为了保证其简单易用，放弃了复杂的组件编排。所以在应用部署时， Helm 是一股脑将所有的资源交付到 Kubernetes 集群中，期望通过 Kubernetes 面向终态的自愈能力，自动化的解决应用的依赖和编排问题。 这样的设计在首次部署时可能没有问题，然而对于具备一定规模的企业生产环境而言，就显得过于理想化了。
一方面，在应用升级时一股脑将资源全部更新很容易因为部分服务短暂的不可用造成整体的服务中断；另一方面，如果软件存在 BUG，也无法及时回滚，很容易将影响范围扩大，难以控制。在某些更严重的场景下，如存在生产环境部分配置被运维人工修改过，由于 Helm 一次性部署会将原有的修改全部覆盖，而 Helm 之前的版本与生产环境可能并不一致，导致回滚也无法恢复，形成更大面积的故障。
由此可见，当具备一定规模以后，软件在生产环境的灰度和回滚的能力极其重要，而 Helm 自身并不能保证足够的稳定性。
如何针对 Helm 做金丝雀发布？#
通常情况下，一个严谨的软件升级过程会遵从类似如下流程：大致分成三个阶段，第一阶段升级少量（如 20% ）的实例，并切换少量流量到新版本，完成这个阶段后先暂停升级。经过人工确认之后继续第二个阶段，升级更大比例（如 90% ）的实例和流量，再次暂停等待人工确认。最后阶段将全量升级到新版本并验证完毕，从而完成整个发布过程。如果升级期间发现包括业务指标在内的任何异常，例如 CPU或 memory 异常使用率升高或请求 500 日志过多等情况，可以快速回滚。
上面就是一个典型的金丝雀发布的场景，那么针对 Helm Chart 应用，我们该如何完成上面这个流程呢？业界的典型做法通常有如下两种：
- 修改 Helm Chart，将工作负载变成两份，并分别暴露出不同的 Helm 参数，在发布时不断修改两份工作负载的镜像、实例数和流量比例，从而实现灰度发布。
- 修改 Helm Chart，将原先的基础工作负载修改为具备同样功能但是具备灰度发布能力的自定义工作负载，并暴露出 Helm 参数，在发布是操纵这些灰度发布的 CRD。
这两个方案都很复杂，有不小的改造成本，尤其是当你的 Helm Chart 是第三方组件无法修改或自身不具备维护 Helm Chart 能力时，这些方法都是不可行的。即使真的去改造了，相比于原先简单的工作负载模式，也存在不小的稳定性风险。究其原因，还是在于 Helm 本身的定位只是一个包管理工具，设计时并不考虑灰度发布、也不针对工作负载做管理。
事实上，当我们跟社区的大量用户深入交流以后，我们发现大多数用户的应用并不复杂，类别都是诸如 Deployment、StatefulSet 这些经典的类型。所以，我们通过 KubeVela( http://kubevela.net/ ) 强大的插件机制，联合 OpenKruise （https://openkruise.io/）社区做了一款针对这些限定类型的金丝雀发布插件。这款插件帮助你不做任何迁移改造，轻松完成 Helm Chart 的灰度发布。不仅如此，如果你的 Helm Chart 比较复杂，你完全可以针对你的场景定制一个插件，获得同样的体验。
做不可复制的事情
关于创业，做不可复制的事情很重要。
- 如果你做对了，用户会蜂拥而至，如果没有，说明市场不存在。
- 创业公司关门通常不是VC关，而是创始人自己放弃了。
- 获得用户：坚持出去获取新用户，1）不要懒、也不要害羞；2）不要忽视复利的增长。
- 让早期的用户足够开心。
- 创始人往往是工程师，不具备客服意识，不太懂得如何让客户开心。
- 创始人往往会忽视单个用户，担心不可复制。但实际上这恰恰是创业公司的优势，苹果再也不可能给每个用户发一个手写的感谢信了，但是早期的创业公司可以给每个客户提供独到的服务。
- 极致的体验。 “Insanely great” by Steve Jobs。不是你的产品极致的好，而是“成为你的用户”这件事情本身体验极致的好。 * It’s not the product that should be insanely great, but the experience of being your user. The product is just one component of that. For a big company it’s necessarily the dominant one. But you can and should give users an insanely great experience with an early, incomplete, buggy product, if you make up the difference with attentiveness.
- 种子用户：寻找那些还没有足够选择的早期用户，可能是你的朋友、其他创业公司、或者一个小众领域，这些人会给你开放、会给你足够的反馈，因为他们没有那么多选择。
- the best early adopters are usually other startups. They’re more open to new things both by nature and because, having just been started, they haven’t made all their choices yet. Plus when they succeed they grow fast, and you with them.
- 免费咨询，当 B2B 公司向你征求免费咨询时，他们知道自己越界了，所以会对你非常感激，当你的咨询按小时收费时，他们就会改变预期，希望你做任何事情。
- 手动：为了快速启动，有些环节手动代替自动化也不是不行。
- 无论是盛大的启动仪式还是很牛的合伙公司partner，对startup都不一定有效。
- It’s not enough just to do something extraordinary initially. You have to make an extraordinary effort initially. Any strategy that omits the effort — whether it’s expecting a big launch to get you users, or a big partner — is ipso facto suspect.
KubeVela 1.4：让应用交付更安全、上手更简单、过程更透明
KubeVela 是一个现代化的软件交付控制平面，目标是让应用的部署和运维在如今的混合多云环境下更简单、敏捷、可靠。自 1.1 版本发布以来，KubeVela 架构上天然打通了企业面向混合多云环境的交付难题，且围绕 OAM 模型提供了充分的可扩展性，赢得了大量企业开发者的喜爱，这也使得 KubeVela 的迭代速度不断加快。
1.2 版本我们发布了开箱即用的可视化控制台，终端用户可以通过界面发布和管理多样化的工作负载；1.3 版本 的发布则完善了以 OAM 模型为核心的扩展体系，提供了丰富的插件功能，并给用户提供了包括 LDAP 权限认证在内的大量企业级功能，同时为企业集成提供了巨大的便利。至今为止，你已经可以在 KubeVela 社区的插件中心里获得 30 多种插件，其中不仅包含了 argocd、istio、traefik 这样的 CNCF 知名项目，更有 flink、mysql 等数据库中间件，以及上百种不同云厂商资源可供直接使用。
在这次发布的 1.4 版本中，我们围绕让应用交付更安全、上手更简单、过程更透明三个核心，加入了包括多集群权限认证和授权、复杂资源拓扑展示、一键安装控制平面等核心功能，全面加固了多租户场景下的交付安全性，提升了应用开发和交付的一致性体验，也让应用交付过程更加透明化。
核心功能解读#
开箱即用的认证和授权，对接 Kubernetes RBAC，天然支持多集群#
在全面解决了架构升级、扩展性等挑战之后，我们观察到应用交付的安全性是如今整个业界亟需解决的难题。从接触到的用户案例中，我们发现许多安全隐患：
- 大量用户在使用传统 CI/CD 的过程中，会直接将生产集群的 admin 权限嵌入到 CI 的环境变量里，只对最基本的交付到哪些集群有一定的权限分离。而 CI 体系通常也会被密集的用于开发和测试，很容易引入不受控制的风险。中心化的管理加上粗粒度的权限控制，一旦 CI 体系被黑客攻击、或者出现一些人为误操作，很容易产生巨大的破坏性，后果不堪设想。
- 大量 CRD 控制器依赖 admin 权限对集群资源进行操作，且没有对 API 的访问进行约束。虽然 Kubernetes 本身具备丰富的 RBAC 控制能力，但是由于学习权限管理门槛较高、且与具体功能实现无关，大多数用户并不真正关心其中细节，通常只是选择默认的配置便投入生产使用。灵活性较高的控制器（如能够分发 Helm Chart），很容易成为黑客攻击的靶子，比如在 helm 中嵌入一个 YAML 脚本窃取其他命名空间中的秘钥。
KubeVela 1.4 中加入了认证和授权能力，且天然支持多集群混合环境，对于每一个 KubeVela 的平台管理员而言，他们不仅可以细粒度的定制任意的 API 权限组合、对接 Kubernetes RBAC 体系，将这些权限模块授权给开发者用户，严格限制其权限；还可以简便的使用 KubeVela 平台预置的权限模块，如直接授予用户某个集群的特定命名空间权限，授予某个用户“只读”权限等，极大的简化了用户的学习成本和心智负担，全面加固了应用交付的安全性。对于使用 UI 的用户，系统针对项目可用的资源范围和类型自动完成底层授权并严格校验，从而使得业务层 RBAC 权限与底层 Kubernetes RBAC 体系打通并协同工作，做到从外到内的安全，不在任何环节扩大权限。
云原生技术（1） - 如何从代码到制作并发布一个 Helm 包？
Helm 是什么？#
云原生领域应用打包和分发的事实标准，Helm Chart 通常包含 Docker 镜像及其基础设施配置，能够把一个 K8s 生态的应用完整封装，并且在另一个 K8s 环境正常的运行。
为什么 Helm 会流行？#
核心功能有两点：
- 对复杂的 Kubernetes YAML 做了打包和抽象，简化为少量参数。
- 给出应用的概念，并给出了完整生命周期解决方案：制作、上传（托管）、版本化、分发、部署。
真正让他流行起来的原因是：
- 踩准了时机，当时（2018年） K8s 生态对 YAML 深恶痛绝但是苦于没有好的工具，快速形成了丰富的生态，如今已经有 1000+ 开箱即用的 Helm Chart: https://artifacthub.io/
Helm Chart 解决了云原生应用交付所有问题了吗？#
没有，这个问题以后会逐步回答，今天的重点是怎么玩好 Helm。
如何从源代码开始制作一个 Helm 包？#
准备工具#
- git
- docker
- helm
- velad
- kubectl
从代码到容器镜像#
Helm Chart 是对 Kubernetes 资源的打包，所以制作 Helm Chart 的前提是需要对 Kubernetes 的常用对象和容器镜像有基本的了解。如果你对这些概念不熟悉，可以直接跳转到如何部署 Helm 包 一节。
【转载】王慧文清华产品课Allen修订版
这篇文章是虎牙产品经理旁听王慧文在清华的产品经理课程总结的文字稿，内容非常完整，也很精彩，读完受益良多。
原文在这里 转载的原因：
- 原来的网站不是太稳定，经常无法访问（不是被GFW，而是502那种）。
- 原来的图片也没有了，我就索性去掉，找了一些链接代替。
第一课 前言#
一、成功和失败的产品#
一般来说在一个领域里一款产品的成功对应着无数产品的失败，根据老王个人的经验，成功和失败的比例大约是1:30，失败的原因多种多样，有些啥都没做对，有些作对了一部分，这里列举的失败案例主要讲做对了一部分的，准确说算是“成功的失败”。
- iPhone vs. 诺基亚
现在的诺基亚手机业务没了，只有通信业务了。2000年左右诺基亚是手机行业里最牛的品牌，直到2007年iPhone登场。
- iPod vs. MPMan
MPMan是韩国公司生产的全球第一款MP3播放器，iPod并不是行业首创，甚至比国内的爱国者MP3播放器都还晚些，事实上今天大多的成功案例都不是行业内的第一款产品。
- 微信 vs. Kik
微信是模仿Kik的，甚至不是第一个模仿Kik的，前面还有米聊、TalkBox等产品，但是微信是最成功的。
- 搜狗输入法 vs. 智能ABC
智能ABC在没有搜狗输入法的时代是比较好用非常主流的，但有了搜狗输入法之后大家觉得智能ABC太不好用了。
- Chrome vs. IE
IE和前面的案例比并没有那么失败，毕竟仍然还有很大使用量。但这个案例比较特殊，在Chrome开始做的时候，主流操作系统是Windows，IE是Windows自带的浏览器，所以Chrome要打败IE是非常非常难的，因为需要用户主动下载Chrome，考虑这个因素，Chrome是非常成功的。
几乎在每一个大行业里，最终取得成功的通常都不是第一家。Google也不是第一个，甚至当时有业内人士认为Google的创始人没有搞清楚行业情况，他们认为搜索引擎这个行业格局已定；Tesla也不是第一个做电动车的，第一辆电动车应该在100多年前就有了。不是第一个这说明技术可能已经不是瓶颈了，而真正关键的原因是产品经理（笑）。
二、成功的产品经理#
- Neil McElroy（经济学专业）
11.png
Neil是人类历史上第一个产品经理，他是宝洁的，原来是做品牌做广告的，但觉得宝洁的运营有很大改进空间，所以他提出应该设立一个岗位对产品的成败负责任，推动设立了产品经理这个职位，后来他就成为了宝洁的总裁，还做过美国国防部部长。
- 乔布斯
大家对乔布斯最耳熟能详的成功产品是iPhone，但他和沃兹第一个搞出了个人电脑PC。在此之前，电脑是给军队和企业用的，最强的电脑公司是IBM，所以当时的电脑非常贵，乔布斯和沃兹觉得电脑非常好但是买不起，于是他们两个自己搞出来了，沃兹负责开发，乔布斯负责销售，Apple II大获成功，图形化界面是他们率先普及的。
被苹果赶走后乔布斯投资了Pixar，做动画片《玩具总动员》那个，因为乔布斯认为Pixar做的事情非常有前途，所以不断投钱成为了Pixar的老板，Pixar后来被迪士尼收购了。后来Apple收购了乔布斯的NeXT，他回到苹果，把苹果死马当活马医，当时PC行业最强的是Dell，有人让Dell的老板给乔布斯一个建议，Dell的老板给的建议是把苹果解散把钱还给股东。乔布斯在他整个人生里都是非常有创新力的人（Elon Musk有可能会超越他，乔布斯可惜英年早逝了）。
- 张小龙
张小龙的第一款产品是Foxmail，第二款产品是QQMail，第三款产品是微信。当然现在微信已经不能算是一款产品了，现在微信里有微信支付、二维码扫描等各种各样的功能，是多种不同产品功能的融合，且融合得非常好。张小龙现在是国内的产品大神，强档推荐龙神的分享每隔一段时间读一遍。按照惯例现在应该讲搜狗输入法的产品经理（马占凯），但由于人在现场，就不讲了,以免他太骄傲😊
- Pichai
这个人没有乔布斯那么多成功的产品经历，但他有一个很特殊的地方。乔布斯虽然做工程师水平一般般，但毕竟是会技术的，张小龙更是工程师出身，Foxmail就是他自己写的，而Pichai是学冶金工程的。浏览器相当于是一个小型操作系统，所以浏览器是非常有技术含量的，所以Pichai做成了Chrome是非常有意义的一件事。Pichai现在是Google的CEO，Google是一家搜索引擎为主的公司，他们还有很多其他的优秀产品，比如他们有安卓、Youtube、Google Map，所以按常规来说，创始人退休应该从搜索引擎业务线里选一个人做CEO，但选了Pichai这个Chrome业务线且不懂技术的人，所以Pichai能成为CEO是一件非常牛的事。
三、如何看待这门课程和产品经理这个职业#
老王希望自己这门课能讲得深入浅出，以至于高中刚毕业的学生都可以听懂这门课，所以这门课没有专业上的门槛。宝洁是做日用品的，在技术上属于化工行业，Neil McElroy是学经济学的，所以做好产品经理和专业不太有关系，成为一个好的产品经理，世俗的标准有很多，最根本上是和本人的三观有关，个人的三观要和这个领域相匹配，如果三观不匹配，这个人可能能做一段时间，但不会有太高的成就。
产品经理是一个需要终身学习的职业，想学一门专业的技术，一段时间后就只用好这门技术，或者专业能力只局限在一个领域，就不容易做好产品经理。产品经理是一个跨领域的专业，需要解决很多新的问题，如果固化自己的知识体系和发展方向，就不太可能在产品经理这个领域有太高的成就。