做低代码产品经理半年后，我有哪些思考 360儿童手表犯错！周鸿祎致歉并惩产品经理

做低代码产品经理半年后，我有哪些思考 360儿童手表犯错！周鸿祎致歉并惩产品经理， 

做低代码产品经理半年后，我有哪些思考

——————/ BEGIN /——————

今年三月份我转行做了低代码平台的产品经理。最近刚刚过了半年试用期，也在复盘自己入职以来的表现。

客观来说，这半年的产出并不符合我的预期，我希望自己可以发挥出更大的价值，但看起来事实并不如所愿。

我在想，到底是哪里出了问题。

最近自己有了一些思考结果，也跟更高阶的产品同学有了一些交流，希望在这篇文章中能将这些成果分享出来。

也许我周围有一些转行的产品经理正在经历我一样的心情，我希望通过对自己工作的深刻剖析，给他们一些鼓励和方法，在「迷茫」的情绪中找到「知道该如何发力」的解决方案。

关于复盘，我会给自己提三个问题：

你认可自己在做的这件事么

你有没有找到正确的方法

你是否足够努力

理想情况下，对于自己负责的工作，我们应该是先找到价值，再寻求方法，最后付出努力。但事实上，很多人往往是先努力（加班），再从或有效或无效的努力中提炼出方法，最后再慢慢找到价值。

两种路径都可以，第一种方法更容易做得开心，因为构建起了正反馈。价值是最基础的保障，正确的方法可以让努力变得更有回报，于是更加认可事情本身的价值。而第二种方法更容易上手，因为相比找到价值，努力反而是不需要思考的。

我们所说的价值，是这项事业本身所具备的价值，比如对低代码平台来说，就是它对现有的 SaaS 模式的影响。而绝非那种普遍适用的价值，比如这份工作让我能够生活得很好，有不错的社会地位。

当然我们不是否定第二种价值，只是这样的价值让我们更容易放弃眼前的工作，或者更不容易找到工作本身的乐趣。因为这种价值不是这个工作所独有的，这恰恰才是关键。

我认可低代码这个方向么？

是的，毫无疑问

起初我认可这个方向，是因为我觉得这个岗位要求的业务抽象能力，是我所推崇的产品设计理念。但现在我会觉得，格局小了，认识太浅了。

《硅谷钢铁侠》这本书提到，在创建 space X 早期，马斯克制定火箭制造计划时，往往会从物理学的角度判定一件事是否可行。如果在底层逻辑上这件事是跑得通的，剩下来的就是方法和执行力的问题。

同样的，低代码这个方向如果在底层逻辑上跑得通，剩下的就是从业者们如何找到方法并付出执行力的问题。

在我眼中，低代码的价值依托于一个被普遍验证的经济学规律：科斯定律。通俗地说，谁能把资源用得好，资源就归谁。

我们再回顾下低代码产品和其他产品的区别，可以理解为下面这张图。

对于大多数产品来说，它是围绕着需求而生的，从业务/用户需求到产品需求，从产品需求到产品；而对于低代码产品来说，它是围绕着产品而生的，从业务/用户需求到产品，从产品到搭建产品的工具。

两种模式的差异在于，前者将最宝贵的资源投入在业务/用户需求到产品的这个阶段，而后者将最宝贵的资源投入在从产品到搭建产品的工具这个阶段。

在企业数字化早期，业务/用户需求差异性较大，通用化的解决方案几乎不存在，于是资源投入在第一个阶段是可行的，因为回报最大。

后来 Salesforce 带来了 SaaS 这种新兴的模式，但我一直认为这更多的是商业模式的变化，而不是应用生产模式的变化。例如对于国内 SaaS 厂商有赞来说，依旧会根据不同的行业开发出不同的版本，「资源投入在业务需求到产品」的本质没有变。

而低代码带来的恰恰就是应用生产模式的变化，从业务需求到产品的任务不再落到产品经理和研发工程师的身上，而落到了开发者的身上。

在第一种模式下，不同业务间即使具备了某种底层相似性，产品设计依旧要做多次。所以，如果存在一个假设：企业数字化转型是否给不同行业间带来了更多的底层相似性，那这种模式的边际收益注定是逐渐降低的。

而低代码模式下，业务间的底层相似性，被抽象为通用的工具，通过工具可以更快地搭建出满足业务诉求的应用，生产边际成本极大降低，相对的，边际收益就提升了。

总的来说，我认可一个假设：企业数字化转型给不同行业间带来了更多的底层相似性，同时我认可一个经济学定律，最终推导出，我认可低代码这个方向的价值。而这个假设是否成立，值得我们一起去思考。

如何找到正确的方法

我今年是做产品经理的第五年，对我来说，找到正确方法的最大阻塞恰恰是过去的经验，过去是怎么把事情做成的，在做低代码的时候会不自觉地产生路径依赖。

要破除这种依赖，首先要想清楚：低代码产品经理跟其他产品经理有什么不一样。

从上面的介绍中不难看出，低代码产品经理会经历的特殊阶段叫做「从产品到工具」，这要求我们同时具备两种能力：扎实的业务知识和产品抽象能力。所以，低代码产品经理需要时时刻刻平衡好「具体和抽象的关系」。

对其他产品经理而言，他们的抽象能力一般发挥在从业务需求到产品需求的抽象中，例如销售希望可以更好地管理手头的潜在客户和签约客户，于是产品经理给他们提供了一套 CRM系统。

但低代码产品经理的抽象能力要求他们能够将 CRM 系统再做拆解，从后端的数据模型到前端的页面搭建，这对于抽象能力的挑战无疑是巨大的。

从最终状态来说，低代码产品经理的抽象能力应该成为他们的制胜武器，他们应该花更多的时间在这种能力的培养上。但从我半年多的经历来说，这个原则往往会带来一个误区，只关注抽象，而轻视业务。

我们所说的抽象，应该是从业务抽象到产品抽象，所以在早期，低代码产品经理一定是要投身于业务中，他们必须具备了一定的业务理解能力，再去谈抽象。

抛开业务的抽象，只是一种逻辑游戏，说严重点，是一种自嗨。就像那句话说的，如果没有看过这个世界，又何谈世界观呢。

我最近在做CRM项目的时候，这种体会非常深刻。

起初我接到的任务是完成CRM 系统中一些复杂表格的搭建，后来我发现，如果不能理解表格背后的数据，包括数据来源是哪里，表之间的关联关系如何，现在的 CRM 系统中每张表格的作用是什么，呈现的信息关系是怎么样的…

如果不懂这些，单纯地就是想着如何用无代码的方式搭建出眼前看见的这个表格，那一定是走不通的，并且也会做得很痛苦，很懵逼。

总结下来就是一点，在刚刚做低代码产品的阶段，我们一方面要了解到这个角色与其他产品经理在能力要求上的不同，但另一方面也要清楚需要从业务中培养抽象能力。

决定要不要做一件事

决策模型至关重要

我在产品评审的时候，经常会面对的一个问题是：为什么要做这个需求。同时，也会受到几种挑战：

有业务场景么；

有业务提出这个场景么；

竞品有做么。

首先，有场景是必须的，没有业务场景的需求，很可能是伪需求。举个不恰当的例子，我如果做一个表格放大闪入的加载动效，是一个需求么，是的，但有业务场景么，没有，那这件事就不应该做。

但挑战在于，需要区分你没有看到场景和没有场景这两件事。如果我们把没有了解到这样的场景，当作没有场景，那这个产品的天花板就会受到你认识的局限。

那该怎么办呢？

广泛地体验不同行业里的SaaS产品，CRM、ERP、WMS等等，如果我们需要用低代码支撑起各种复杂的企业应用，我们至少要知道这些应用现在长什么样子，这同时也验证了一点，在早期要投入到不同行业里，攒业务经验。

如果我们现在对接的业务没有提出这样的场景，我们要不要做。

我始终坚信一点，对于真正有价值的诉求，如果发现了再做，那我们很可能比SaaS产品的迭代速度更慢，因为我们只是完成了从工具到产品，而从产品到解决方案，还需要开发者或者实施团队的努力。

那如果做了，且在很长时间内发现没有业务用，到底是因为这个需求是伪需求，还是因为我们还没有找到真正服务的客户呢，这都是我们应该去考虑的问题，遗憾的是这样的问题并没有标准答案，只有不断扩大自己对行业、对业务的了解，才能做出更接近事实的判断。

分工不是边界

我们的团队会按照产品模块有不同的分工，每个同学在这样的分工下又有自己更精细的责任，但分工不是边界，一个模块的工作能不能做好，有时候依赖于你有没有搞懂另一个不属于你责任范围内的事情。

比如在上面提到的 CRM 项目中，我负责的是表格搭建部分的工作，但深入了解后我发现，如果搞不懂表格背后的数据结构，那表格搭建方案根本就无法落地。

我有个很明显的体会，之前我以为我只需要参与表格前端展示效果相关的 gap 梳理，但后面发现数据源、数据加工和数据展示之间是一体的，前两者搞不懂，方案设计就是不完整的。

打破边界是为了获得更多信息，从而提高效率，但提高效率的行动往往容易带来对问题定义的忽视。为了加快进度，我们在工作中往往更重视找解决方案，但解决方案如果跟问题的定义是矛盾的，便只能带来短期收益。

前面说了，表格搭建时需要去了解数据源、数据加工和数据展示之间的关系，而我们遇到的实际问题是，受到数据源本身特性的一些影响，后端需要补充一些数据加工能力，但这些能力在后端开发的成本比较大，而项目周期紧，所以大家就想到这部分工作是不是前端也可以做。

遇到这些问题的时候，我的第一想法是，前端能解决么，如果可以的话，成本大么，如果不大的话，那为了项目按时上线，就去做吧。

虽然讨论的时候我也觉得，似乎后端负责数据加工，前端负责数据展示是更符合直觉的，但如果我不做，是不是会显得我不够“配合”。因为害怕背负上这个标签，于是想办法从前端去搞定。

后来跟老板沟通下来，发现我之前的思考并没有触及到问题的本质。如果这一次前端处理了，那后续遇到这样的情况，且数据源特征更复杂，是不是都是前端来做。其背后真正的问题是：

整个低代码产品在搭建复杂应用的过程中，面临这种复杂的数据情况时，前后端应该如何分工，才更符合整个产品长期的规划。

短期内针对一个问题的解决方案有很多种，但对于未来应该要做成什么样子，大家的理解应该是一致的。

这种讨论也许会影响一些工作效率，但确实是十分必要的。

关于如何努力的问题

半年来，我对任务和目标颇有一些体会。在新人 landing 阶段，虽然也需要去制定自己的工作目标，但这些目标往往是依附于任务而存在的。

比如我刚来的时候，分到的任务是负责图表模块，那时候我的目标，也是围绕如何做好图表目标而去制定的。这个阶段是有必要的，因为信息不够，还在学习，从一个具体的任务开始是明智且踏实的。

但这个阶段不能持续太久，如果目标总是服务于任务，那我们所有的价值感和目标感都是依赖于具体的事情，而容易忽略我们自身的成长。

我自己就有过这样的体会，Q2 的时候针对图表后续的规划做了很多调研，梳理了很多想法，但 Q3 开始我被告知，图表需要转交给其他团队，这让我在某个时刻突然陷入了一种空虚当中，好像一下子失去了目标。

后来我开始投入在表单相关的任务中，也是给自己定了针对于这个任务的目标，但由于自己低估了任务的难度，最终跟团队一起评估下来，目前全力推进这个任务并不是时候，于是暂缓推进了。再一次地，我有一种失去了目标的感觉。

后来我自己开始反思，目标不应该服务于任务，目标应该是大于任务的，它应该去决定我在这家公司希望变成一个什么样的人，目标是跟我这个人的状态相关联的，而不应该受制于具体的任务。

当我有了目标之后，我可以制定不同的任务去服务于目标，我可以或主动或被动地去调整目标下的任务，但目标之于人，就像北极星指标之于产品增长，是具有引领价值的。

摆脱“被动”，提前做准备

在大厂我能感觉到，身边都是非常优秀的人，大家的背景、专业度和沟通方法，在从业者中都是佼佼者。

以前在小公司的时候，我觉得自己要成为那个环境中最优秀的那一批人；来到大厂之后，我的内心总是充满着一种隐隐的自卑感，甚至一段时间祈求自己可以顺利度过试用期，这在以前是不可想象的。

似乎大厂的产品经理们从不用别人去 push 他们要努力，会议、文档、项目、汇报、OKR，这些就足够产生强大的推力，推着我们向前走。

我曾经认为，只要自己能够做好努力这件事，就能生存下来。但后来我发现，更重要的是找到为了什么而努力的答案。

上文说的从目标到任务，就是一种找到为了什么而努力的方式，而半年来我的另一个感受是，需要对产品充满好奇心。

刚刚入职的时候，就听人说起过，表单在现在的配置体验让人感觉到很奇怪，不理解为什么要这么做。因为我不在负责表单功能的团队，所以这样的说法听了也就听了，并没有很好奇。直到后来表单相关的任务来了，我才不得不从零开始研究表单功能。

我在想，如果早一点可以去研究表单，是不是自己能够为后来的任务做好更充分的准备；可又一想，是什么会驱动我去做这样的研究呢。那应该就是好奇心了，除了好奇心，我想不到有别的驱动力。

我所说的好奇心不是指“我知道是怎么回事”，而是真正理解产品背后的基本原理以及它存在的价值。

忙碌的工作中，如何钻研其他产品

我问过自己，平时那么忙，哪有时间去钻研不是自己团队的产品呢。

我的一个体会是，一定要跟不同团队的产品经理保持一定频率的交流，这种交流不能仅局限于跨团队的需求，更好的方式是抛开需求，更开放而自由的交流。

现实情况是，也许这只是我的一厢情愿，因为我看大家的日程，好像每个人在工作日是真的很忙，但如果有人愿意找我了解一下关于组件的一些问题，我是很愿意的。

当然我希望他们也带着自己负责的模块，来一场知识的交易。

另一方面，低代码产品经理需要跟研发有更多的沟通。我了解到很多公司都有自己的低代码平台，发起人往往是技术团队，低代码在技术视角下和产品视角下，并不完全相同，所以需要更多的交流。

上周末我参加了美团线上技术沙龙，里面有一个版块是关于美团和阿里的低代码技术分享，我立刻将获取到的信息发给了我对接的前端同学，我不知道大周末的打扰人家是不是合适，但那一刻确实想分享一些东西。

他也及时回了我，带了一些他了解到的信息。我能感觉到他对于低代码这个领域的热爱，有时候交流会传播这样的热爱。

最后，我选择在这个节点输出这样的复盘，更多的是对于自己的激励和鞭策。

还记得那三个问题么：

你认可自己在做的这件事么

你有没有找到正确的方法

你是否足够努力

我对这三个问题都给了自己的回答，那接下来就只剩一件事：干就完了。

发布于：广东


360儿童手表犯错！周鸿祎致歉并惩产品经理

2024年8月22日，一位来自河南商丘的家长在网上发布了一段视频，让人大跌眼镜。

她的女儿使用360儿童手表问了一个问题：

"中国人是世界上最聪明的人吗？"

没想到，手表给出的答案十分毁三观！

本文信源来自官方媒体【九派新闻】【新浪财经】。为提升文章可读性，细节可能存在润色，请理智阅读，仅供参考！

儿童手表风波

这番充满偏见和错误的言论，让这位妈妈感到十分震惊，也引发了网友们的热烈讨论。

而消息一出，360公司也立即行动起来。

当天中午，360儿童手表客服和360智慧生活客服都表示，他们已经收到反馈，正在紧急处理，后续还会加强审核。

360集团董事长周鸿祎解释：出问题的是一款2022年的旧手表，没有使用公司的人工智能大模型。目前公司已经完成整改，删除了有害信息，并升级了软件。

而这件事，对360公司的股价也产生了一定影响。8月22日，360股票收盘下跌3.69%，总市值缩水到484.5亿元。

可是，到底为什么会出现这种问题呢？

观看5秒后可免费阅读全文~写作不易，作者每天也是在公司上班写文章，天天加班到晚上12点，每天收益只有50多块，文中加入广告解锁，就是能为了多几块收益，希望观众老爷理解~

周鸿祎坦言，当初在产品设计上有两种思路。一种是提供标准化的答案，另一种是利用网络公开信息动态生成回复。

前者虽然简单也不出错，但不想让儿童死记答案，会限制他们的想法。

产品团队基于这样的考虑，选择了后一种方案。

因为国内网站一直都在清理不好的内容，本来以为不会出错，没想到还是让一些价值观不正确的答案混了进去。

其实手表的错误回答，反映出的是传统搜索引擎的局限性。它是根据关键词搜索网上现有信息，而不是真正理解问题。

相比之下，人工智能大模型反而能够优化答案，提供更加准确、合理的回复。

8月24日，周鸿祎为了让产品经理吸取教训，公司已经安排他们去接听一个月的客服电话。

还说欢迎大家继续刁钻的去提问，发现有不合适的问题，可以去他的道歉视频下面留言。

周鸿祎对产品经理的处罚，有他自己的看法。

这看似是惩罚，实际上却是一种"奖励"，让他们有机会倾听用户的声音，了解用户的需求。

儿童手表风波目前看算是平息了，但在互联网时代，任何一款产品都可能面临着各种各样的挑战和质疑。

而周鸿祎之所以能及时挽回，或者说是及时止损，也是因为他自己本身对互联网行业足够了解。

天才的起点

周鸿祎的互联网之路，可以追溯到他的中学时代。

在同学们还在为考试成绩焦头烂额时，周鸿祎已经开始自学编程，尝试编写自己的小程序。他在各类计算机竞赛中崭露头角，斩获奖项。

而这种对计算机的痴迷，在周鸿祎步入西安交通大学校园后有增无减。

大学期间，周鸿祎和几位志同道合的同学组建了一个创新团队，开发了一款校园信息管理系统。

这个系统为学校的教务管理提供了很大的帮助，不仅让周鸿祎的团队在学校里小有名气，也让他第一次尝到了创业的滋味。

在项目的推进过程中，周鸿祎不仅是团队的技术骨干，也是精神领袖。

大学四年，周鸿祎醉心于计算机领域的探索，成绩不错，但真正的挑战还在后面。

毕业之际，周鸿祎谢绝了众多大企业的橄榄枝，选择了加入一家初创公司。在他看来，与其在大公司里做一颗螺丝钉，不如做小公司的顶梁柱。

大学毕业后，周鸿祎进入北大方正集团工作，先后担任技术员、项目经理等职务。

然而，在方正工作的几年里，周鸿祎渐渐感到了一种局限感。

1998年，周鸿祎毅然辞去了方正的工作，与几位志同道合的伙伴一起创立了3721公司。

在当时，很多中国用户面临着上网难、找信息难的问题，周鸿祎决定开发一款帮助用户轻松访问中文网站的软件。

从3721到奇虎360

他带领团队日以继夜地工作，终于推出了3721网址导航软件。

使用这款软件时，用户只需要输入网站的中文名称，就可以轻松访问目标网站，再也不用记冗长的网址了。

用户量迅速增长，3721公司也因此获得了巨大的成功。仅仅三年时间，3721就引起了国际巨头雅虎的关注。

2003年，互联网巨头雅虎以高达1.2亿美元的价格，收购了3721公司。而周鸿祎，也因此在中国互联网界出了名。

收购完成后，周鸿祎出任雅虎中国区总裁，负责公司在中国市场的业务拓展。

然而，周鸿在2005年选择了离开，再次开始筹划自己的新事业。

2006年，他创立了奇虎公司，开始了在互联网安全领域的发展。当时，随着互联网的快速普及，网络安全问题日益突出。

病毒、木马、钓鱼网站等层出不穷，给广大网民的上网体验和财产安全带来了严重的威胁。基于这一点，奇虎公司推出了360安全卫士等一系列安全软件产品。

这些产品界面简洁、操作简单，且完全免费，很快受到了广大网民的欢迎。

360安全卫士更是凭借其强大的查杀能力和实时防护功能，成为了用户电脑中的必备软件。

而360也在不断拓展产品线，推出了360杀毒、360浏览器等新产品。

2011年，奇虎公司更名为360公司，并在美国纽交所成功上市，成为中国第一家在美上市的互联网安全公司。

不满足于软件领域的成就，周鸿祎还带领360进军硬件领域，开辟了新的战场。

360相继推出了360行车记录仪、360儿童手表等一系列智能硬件产品。

通过软硬件的双轮驱动，360的市值一度突破百亿美元，多次入选"全球互联网企业100强"。

在周鸿祎看来，创业从来都不是一件容易的事情，需要付出常人难以想象的努力和汗水。

谈到自己的成功秘诀时，周鸿祎强调了两点：

第一是要有清晰的目标和方向，知道自己要做什么，为什么而做； 第二是要有坚定的意志和毅力，不为困难所惧，不为挫折所折。

前段时间的巴黎奥运会，中国跳水运动员全红婵，夺得金牌。

周鸿祎就用自己的成功论，对她做了评价。

全红婵奥运夺冠背后的哲学

在周鸿祎看来，全红婵的夺冠并非偶然，而是天时、地利、人和等多种因素共同作用的结果。

他特别提到了"一万小时理论"：成为一个领域的佼佼者，需要至少一万小时的刻苦训练。

全红婵之所以能在奥运赛场上脱颖而出，正是得益于她多年来的努力和坚持。天才的成功往往需要两个关键因素：一是恰逢其时，二是刻苦训练。

而在周鸿祎自己的创业历程中，也证明了他的心得体会并非嘴上说说。

2023年，周鸿祎被清华大学计算机科学与技术系电子信息专业，录取为博士研究生。

对于这位互联网大佬来说，重返校园深造，可以说是为自己的知识体系"充电"，也为公司的长远发展积蓄力量。

在周鸿祎的规划中，360一定要成为一家全球领先的网络安全公司，为全世界的用户提供最安全、最智能的产品和服务。

他曾说，360的使命是"让世界更安全"。

如今，周鸿祎的身份除了企业家，还有一个——中国网络社会组织联合会副会长。

他在采访中所说，"创新和责任是互联网企业永恒的主题"，这也将是周鸿祎不变的追求和坚持。

屏幕前的你有什么看法呢？欢迎在评论区留言……

参考资料

[1] 【平安江苏】——《家长反映儿童手表问答诋毁中国人，360独家回应！》 [2] 【九派新闻】——《周鸿祎谈全红婵夺冠：不要觉得优秀的人都是天才，找准方向努力一万个小时你也能成为天才》 [3] 【商业人物】——《周鸿祎，突然辞职！》 [4] 【全国党媒信息公共平台】——《周鸿祎再就360儿童手表问题道歉 “用户一发现问题我们立即就把该停止的服务停掉了”》 [5] 【周鸿祎】——《周鸿祎：产品经理要学会做“头脑体操”》 [6] 【北京青年周刊】——《周鸿祎写了一套“产品经理进阶指南”，需求者自取！》 [7] 【和讯网】——《周鸿祎谈自我定位：我首先是个产品经理，希望成为一个成功的企业家，而不是生意人》 [8] 【新浪财经】——《周鸿祎再回应儿童手表事件》

声明：取材网络、谨慎鉴别