AI产品经理转型指南：六大方向与能力模型
这两年，产品经理圈子里最让人焦虑的事情之一，大概就是要不要转型做AI产品经理。打开招聘软件，AI产品经理的岗位越来越多，月薪三四万的很常见，有些资深岗位甚至能开到七八万。再回头看看自己做了多年的传统产品，难免有点心动。但真要投简历，又发现事情没那么简单。有的岗位要求熟悉大模型训练和评测，有的要求懂Agent、RAG、MCP，还有的要求五年以上金融、制造或企业软件经验。同样叫AI产品经理，招聘要求却像是完全不同的职业。更让人郁闷的是，自己明明已经做了五年甚至十年产品经理，到了AI领域，难道还得从初级产品经理重新做起？这种焦虑并非空穴来风。脉脉高聘发布的2026年AI人才报告显示，今年1—7月，AI产品经理岗位量同比增长120.54%，在非技术岗位中扩招速度排名第一。岗位确实在增长，但机会并没有平均分配给每一个产品经理。原因很简单：如今的AI产品经理，早就分化成了好几种截然不同的职业方向。有人研究大模型的能力边界，有人天天研究用户留存，有人给企业搭Agent，还有人负责把AI真正部署到客户的业务系统里。这些人都叫AI产品经理，但日常工作、技术门槛、薪资以及未来的发展空间，差别相当大。对于想转型的产品经理来说，选错方向，有时比暂时不转型更麻烦。今天我们就来系统盘点一下：AI产品经理究竟有哪些类型？薪资差距为什么这么大？传统C端、B端产品经理又该怎么选？01AI产品经理，已经分成了六大阵营如果按照产品所处的技术层次、服务对象和工作内容划分，目前可以把AI产品经理大致分成六类。第一类：AI原生应用产品经理。这是很多人最向往的方向。豆包、元宝、Kimi、DeepSeek、千问，以及即梦、可灵等AI应用，背后都有对应的产品团队。这类产品的共同特点，是核心体验高度依赖大模型。如果拿掉AI能力，产品的主要价值也就不存在了。AI原生产品经理每天需要思考的问题非常多：用户为什么要用你的产品？为什么用完一次就走了？模型应该具备哪些能力？什么时候采用对话交互，什么时候需要按钮、画布或其他操作方式？还有一个非常现实的问题：Token是要花钱的。假设用户每天调用几十次模型，成本已经超过了会员收入，那么产品越受欢迎，公司可能亏得越多。做传统互联网产品，产品经理主要考虑流量、留存、转化、商业化。到了AI原生应用，这些问题一个都没少，还得研究模型能力和推理成本。更头疼的是，模型升级太快。辛辛苦苦设计出来的功能，可能下个月模型一次更新就能直接实现，之前的产品设计也得跟着调整。这类岗位的技术理解和创新要求普遍较高，尤其是头部通用AI助手。腾讯、阿里、字节、百度，以及Kimi、DeepSeek等公司，都在这个方向持续投入。中小企业想在通用助手赛道与这些公司竞争，难度可想而知。但垂直AI应用仍然有机会。例如AI教育、AI医疗、AI设计、AI陪伴、AI法律等领域，对特定用户和业务场景的理解同样重要。对于普通产品经理而言，进入垂直AI应用团队，通常比直接冲击头部通用助手团队更加现实。第二类：AI+产品经理。这一类可能是传统互联网产品经理最值得关注的方向。所谓AI+，就是让一个已经存在的产品具备AI能力。比如支付宝推出AI助手阿宝，微信正在测试原生AI助手小微，美团推出小美。这些产品原本就拥有大量用户、丰富的业务场景和成熟的服务体系。现在的问题是，如何让AI理解用户需求，再把原有功能调动起来。举个例子。以前用户想在微信里点外卖，需要找到相应的小程序，搜索商家，选择商品，确认订单。有了AI助手，用户可能只需要说一句：帮我点一份附近评分不错、30元以内的午餐。看起来简单的一句话，背后涉及意图理解、商家搜索、服务调用、用户确认、支付权限等一系列环节。还有更麻烦的事情。假如AI替用户订错了餐，或者把一笔消费账单算错了，责任该怎么划分？哪些操作可以让AI自动执行？哪些必须经过用户确认？做这类产品，熟悉模型当然重要，但多年积累的业务经验、用户习惯和风险意识，往往更重要。这也是为什么我认为，大部分传统C端产品经理，转型时应该优先关注AI+岗位。你的用户洞察、交互设计、增长经验和行业知识都能继续发挥作用。没有必要为了转型AI，把之前积累的经验全部推倒重来。第三类：企业级AI/Agent产品经理。这个方向没有通用AI助手那么热闹，但可能是大量B端产品经理最现实的转型机会。如今不少企业都在讨论建设自己的Agent。金融公司想用AI辅助核保、理赔，制造企业想用AI优化生产和供应链，零售企业想用AI提升客服、销售和运营效率。表面上看，这些需求似乎都能通过大模型解决。实际落地时，麻烦才刚刚开始。比如一家保险公司希望让AI自动处理部分理赔业务。你得先弄清楚理赔流程，知道哪些材料需要人工审核，哪些规则必须严格执行，哪些数据不能随便调用，还要考虑AI答错时如何处理。做完Demo，往往只是项目的第一步。接下来还有系统集成、权限管理、数据安全、员工培训、客户验收，以及最终的ROI评估。传统产品经理习惯讨论用户体验，企业级AI产品经理可能还得经常回答老板一句非常朴素的话：花了这么多钱上AI，到底帮公司省了多少钱？这里有一个值得关注的变化。过去，很多B端产品经理觉得自己做的东西不够性感。天天跟ERP、CRM、OA、审批流打交道，哪有做社交、内容、消费产品那么风光。到了Agent时代，情况发生了变化。企业最缺的，恰恰可能是那些真正理解业务流程、熟悉行业规则、知道系统怎么对接的人。比如做了八年供应链产品的经理，未必懂模型训练，但他知道采购、库存、物流、结算之间如何协同。让他负责供应链Agent，业务理解可能比一位刚学会搭Agent的新人深入得多。当然，懂业务也不能替代技术能力。你至少得知道Agent如何调用工具、如何检索企业知识、如何控制权限，以及如何评估实际效果。这里还要提一个正在快速增长的新岗位：FDE，前线部署工程师。根据脉脉的数据，2026年1—7月，FDE及现场部署工程师岗位量同比增长1522.73%。增幅确实惊人，不过也要考虑新兴岗位原有基数较小的问题。FDE通常需要进入客户现场，把AI能力接进真实业务系统，很多岗位还要求能够独立编写代码、完成工程部署。它与企业级Agent产品经理有明显交集，但并非同一个岗位。产品经理如果希望往FDE转型，必须认真补足工程实战能力。第四类：AI平台与开发者产品经理。如果说前三类主要面向终端用户和企业客户，那么这一类服务的用户，很多本身就是开发者。代表产品包括扣子、Dify、阿里百炼、火山方舟，以及TRAE、Qoder等AI开发工具。他们要解决的问题，是让别人更方便地开发AI应用。例如，一个企业想搭建自己的客服Agent，该如何导入知识库？怎么配置工作流？怎么接入外部工具？如果调用量突然暴涨，怎么保证稳定性和控制成本？对于AI编程工具，问题又会变成：怎么理解项目代码？如何修改多个文件？如何执行和验证任务？怎样减少开发者反复干预？这类岗位有一个特点：开发者不好糊弄。普通用户可能觉得功能能用就行，开发者会非常关注API设计、调用延迟、错误信息、兼容性、稳定性和成本。因此，平台产品经理的技术理解门槛相对较高。如果你过去做过低代码、数据中台、云服务、开发者工具、API平台等产品，转型会相对顺畅。如果完全没有技术背景，只是因为觉得AI平台工资高就去投简历，恐怕连面试中的技术问题都很难回答。第五类：大模型产品经理。这类产品经理离模型研发最近，也最容易让外行产生误解。很多人以为，大模型产品经理就是负责设计类似ChatGPT这样的产品。实际工作可能完全不同。比如负责某款大模型的产品经理，需要判断模型下一阶段重点提升什么能力。是编程能力、数学推理，还是工具调用？如何构建评测集？模型升级后，哪些场景变好了，哪些场景反而退步了？遇到模型胡说八道，产品经理还得跟算法和数据团队一起分析问题，判断应该优化提示词、工具链、训练数据还是模型本身。这里对技术理解、数据分析和模型评测能力的要求非常高。从薪资天花板来看，大模型相关资深岗位确实很有吸引。但对大部分传统产品经理来说，这也是转型门槛最高的方向之一。尤其是已经工作多年、没有算法或数据背景的人，未必值得为了一个高薪岗位，从头补起大量底层技术知识。反倒是做过模型评测、AI训练、数据产品的从业者，可能拥有更接近的能力基础。第六类：策略算法产品经理。很多人容易忽略这一类。事实上，在大模型出现之前，互联网行业里就有大量产品经理与AI算法打交道。例如抖音的推荐策略、搜索引擎的排序策略、广告投放算法等。他们本来就需要理解机器学习、数据指标、A/B实验和算法策略。到了大模型时代，这些岗位也在发生变化。AI搜索、生成式推荐、智能广告、模型驱动的用户运营，都可能成为新的业务方向。对于原本做推荐、搜索、增长策略的产品经理而言，转型AI相关岗位有一定优势。他们已经习惯用数据和实验来评价产品，也知道算法输出不可能每次都完全符合预期。不过，这类岗位依然强调扎实的数据分析、实验设计和业务策略能力。只会调用大模型API，并不足以胜任。02同样叫AI产品经理，为什么有人月薪两万，有人八万？讲完六类岗位，再来谈谈大家最关心的薪资。六类岗位速览：难度、席位、薪资先看几组数据。2026年1—7月，脉脉平台新发AI岗位量同比增长789.47%，但新发AI岗位平均月薪为63160元，同比只增长2.74%。注意，这里的63160元是新发AI岗位整体的平均值，涵盖技术等不同类别，不能直接当作AI产品经理的平均工资。另一份来自BOSS直聘的《2026人才趋势报告》显示，AI相关职位的薪资溢价，从2022年的3.3倍回落到了2025年的2.6倍。这两组数据放在一起，挺值得产品经理琢磨。2026市场信号：量在涨，价在分层AI相关岗位越来越多，但AI标签本身带来的薪资溢价，已经不像早期那么夸张。从原稿整理的猎聘公开JD样本来看，同样挂着AI产品经理头衔，一家零售企业的报价是16—24K，而某通用Agent数据产品经理岗位，报价则达到65—95K、15薪。差距非常明显。当然，这些只是不同企业、不同职级的公开报价样本，不能拿来当作六类岗位的平均薪资。为什么会有这么大的差距？我觉得至少有三个原因。首先，企业需要解决的问题不同。一个企业招聘产品经理，只需要把客服系统接上大模型；另一个企业招聘产品经理，要负责大型Agent平台的产品架构、评测体系和商业化。两者都叫AI产品经理，但工作复杂度和承担的责任明显不同。其次，AI行业的技术变化太快，真正有经验的人还不够多。传统互联网产品经理可能拥有十年工作经验，但真正做过大模型商业化、Agent规模化落地的人，未必有多少。最后，也是最容易被忽视的：薪资高的岗位，不代表适合转型。如果你已经是一位月薪三四万的资深B端产品经理，为了进入AI领域，跳到一家完全不熟悉的大模型团队，从初级岗位重新开始，最后未必能涨薪。更何况，招聘JD写着80K，也不代表所有候选人都能拿到80K。那可能是企业愿意为某位资深人才支付的价格。所以，看到高薪先别急着兴奋。真正值得研究的是，这家企业为什么愿意支付这个价格，而你过去的工作经验，有多少能帮它解决问题。03三、AI产品经理最需要补的，究竟是什么能力？能力模型：一栋三层楼现在很多人学习AI产品经理，上来就学Prompt、RAG、MCP、Skills、Agent。这些当然需要了解，但如果只会几个工具，就觉得自己已经完成转型，恐怕有点乐观。AI时代，产品经理的能力可以分成三个层次。第一层：传统产品能力。需求分析、用户洞察、业务理解、产品设计、数据分析、项目推进。这些能力依然重要。尤其是需求判断。很多老板看到Agent火了，就要求产品经理给自家的业务也做一个Agent。但如果原来的业务流程根本不复杂，用几条规则就能解决，为什么非要调用大模型？如果调用AI后，成本增加了，准确率还下降了，这个功能还有什么价值？能判断哪些需求值得做、哪些不值得做，依然是一位优秀产品经理的重要能力。第二层：AI专属能力。这部分才是传统产品经理需要重点补课的地方。首先是模型能力边界。你得知道模型擅长什么、不擅长什么，以及在什么情况下容易出错。不能用户提出任何需求，都指望模型一句话搞定。其次是Agent设计能力。需要理解RAG、工具调用、MCP、Skills等技术概念，知道如何让AI连接知识库、外部服务和业务系统。这里不要求每个产品经理都能独立开发复杂系统，但至少应该能够动手搭建简单Agent，并与工程师讨论实现方式。第三是评测能力。传统产品里，一个按钮点击后没有反应，可以明确判断为Bug。AI产品麻烦得多。例如一个智能客服，回答了100个问题，其中90个基本正确，5个不够准确，另外5个完全答错。这样的产品能上线吗？答案取决于具体业务。如果只是普通商品咨询，部分错误或许可以通过用户反馈和人工客服兜底；如果涉及资金转账、医疗建议或合同审批，哪怕少量严重错误，也可能无法接受。所以，AI产品经理必须学会设计评测集、分析badcase、制定不同风险等级下的验收标准。第四是成本意识。模型调用需要Token，复杂Agent可能执行多轮推理和工具调用，用户一句简单的需求，背后可能产生多次调用成本。产品经理如果只关注功能效果，不考虑成本、延迟和商业化，产品很容易陷入用户越多、亏损越大的尴尬。第三层：价值交付能力。这是我认为最值得产品经理长期投入的地方。做出一个AgentDemo，如今已经没那么难了。借助扣子、Dify或者AICoding工具，很多没有编程背景的人，也能搭出基础原型。问题在于，Demo能够运行，距离产品真正有价值还有很长一段距离。有多少用户愿意持续使用？准确率能否达到业务要求？有没有减少人工工作量？成本是否可控？企业愿不愿意付费？真正能把这些问题解决的产品经理，才更有机会拿到高薪。对于资深产品经理来说，企业最终购买的往往是你解决复杂问题、推动业务结果的能力。04C端产品经理怎么转？别急着去大模型公司C端产品经理转型路线如果你现在做的是社交、内容、电商、工具、社区、教育等C端产品，我建议优先考虑两个方向。第一个是AI+。比如你过去做电商产品，对商品搜索、用户决策、下单转化、售后流程都非常熟悉。那么转型做AI购物助手、智能导购、AI客服等产品，原有经验可以直接派上用场。如果你做的是社区、内容产品，也可以往AI内容生产、智能推荐、AI搜索等方向发展。尽量找与你原来的业务经验接近的岗位。如果所在公司正在推进AI项目，内部转岗通常也值得优先尝试。你已经熟悉公司的业务、数据和团队协作方式，转型成本会低不少。第二个是垂直AI原生应用。对于中小公司的C端产品经理来说，这个方向可能更现实。国内的通用AI助手市场已经聚集了大量头部企业，竞争非常激烈。但AI教育、AI陪伴、AI设计、行业工具等垂直方向，仍然存在不少探索空间。这些公司未必拥有最强的模型，却可能因为更了解某类用户，而做出有竞争力的产品。当然，也得提醒一句。不要以为换成AI产品经理，过去做C端产品的所有方法都可以直接照搬。传统产品经理往往习惯把用户路径设计得非常确定：用户点击什么按钮，系统就出现什么结果。AI产品具有更强的不确定性。你需要思考模型出错怎么办、用户如何纠正结果、什么操作需要二次确认，以及怎样避免用户产生过高预期。这是传统C端产品经理需要重点补上的一课。05B端产品经理，这轮AI机会值得认真看看B端产品经理转型路线相比C端，我反而觉得，很多B端产品经理没有必要那么焦虑。尤其是有金融、制造、零售、供应链、医疗、企业服务等行业经验的人。过去这些年，B端产品经理经常面临一个尴尬的问题：产品很复杂，业务很重要，但个人能力似乎不太容易被外界看见。很多人做了多年ERP、CRM、OA、数据中台、业务系统，想跳到一家互联网大厂做C端产品，未必容易。AI正在给这些经验提供新的用武之地。比如一家制造企业想建设生产管理Agent。模型公司可以提供大模型，技术团队可以完成代码开发。但谁来梳理采购、生产、库存、质检之间的流程？谁知道一条异常数据会影响哪些业务？谁能判断哪些流程允许AI执行，哪些必须人工审批？这些问题，恰恰需要熟悉业务的产品经理来解决。对于B端产品经理，我建议优先考虑企业级Agent、AISaaS、AI行业解决方案。如果过去做过低代码、数据中台、开发平台，也可以考虑AI平台产品经理。而那些具备编程能力、愿意深入客户现场的人，可以进一步关注FDE方向。不过，有一个坑要特别注意。别把传统B端系统里的“加一个AI按钮”，当作完成AI转型。不少企业的AI项目，容易停留在最简单的功能集成阶段：给OA加个AI问答、给CRM加个智能助手、给知识库加个聊天框。演示时看着挺先进，上线后却没多少人用。因为员工真正需要的，可能是AI帮他完成原本需要半小时的审批、查询或数据处理任务，而不只是多一个可以聊天的入口。产品经理需要重新梳理业务流程，决定AI在哪里参与、如何与人协作、怎样处理异常，以及最终如何衡量价值。这才是企业级Agent产品经理应该发挥作用的地方。当然，企业级AI项目也没有想象中轻松。客户需求复杂、项目周期长、定制化成本高，甚至需要频繁出差和现场交付。如果只是因为觉得B端AI岗位多，就盲目跳槽，同样可能踩坑。06给准备转型的产品经理，一份90天行动方案怎么选与90天转型计划说了这么多，真正要行动的时候，很多人还是会纠结：我现在应该从哪里开始？我的建议是，先别急着报班，也别急着辞职。给自己三个月，完成一次尽可能贴近真实工作的AI项目。第一个月：把AI工具真正用起来。不要停留在用豆包、元宝或ChatGPT写文档、做总结。试试用TRAE、Qoder或Cursor做一个可以运行的小工具，再用扣子、Dify等平台搭建一个Agent。把RAG、工具调用、MCP、Skills这些概念亲手跑几遍。对于没有编程背景的产品经理来说，AICoding尤其值得投入时间。以前做一个简单的产品原型，可能要找设计师、开发人员帮忙。现在不少想法已经可以自己先做出可运行的版本。能够快速验证想法，本身就会改变产品经理的工作方式。第二个月：解决一个真实问题。别再做那些网上一搜一大把的天气查询Agent、新闻总结Agent了。最好从自己工作中寻找问题。比如提高客服工单处理效率、自动整理业务报表、搭建企业知识问答系统，或者优化某个重复性的运营流程。项目不需要很大，但要有实际用户和真实需求。同时建立一套简单的评测集，记录模型回答出错的情况，测试准确性、成本和处理时间。如果连自己做的Agent究竟改善了什么都说不清，拿去面试也很难有说服力。第三个月：把项目变成转型作品集。整理项目背景、业务问题、产品方案、技术选型、评测方法和实际结果。如果确实提升了效率，就用数据说明。例如某个业务流程原本平均需要20分钟，经过测试和优化后，实际处理时间减少到了多少？其中人工审核的工作量是否下降？模型调用成本是多少？数据不一定非得多漂亮，关键是有真实依据。随后找3到5份自己感兴趣的AI产品经理JD，对照岗位要求，检查哪些能力已经具备，哪些仍需补足。面试的时候，与其反复强调自己很热爱AI，不如拿出一个自己真正做过的项目。很多时候，一个完整、真实的项目案例，比堆满简历的AI课程证书有用得多。07你真的需要转型吗？写到这里，我想谈一个可能不太讨喜的观点。这几年，产品经理圈子里经常出现一种焦虑：好像不赶紧转AI，过两年就找不到工作了。但AI产品经理这个头衔，未来可能也会逐渐失去今天的特殊性。就像十几年前，大家还会专门讨论移动互联网产品经理，今天已经很少有人这样区分了。AI能力越来越普及后，也会逐渐成为产品经理的基本要求。到时候，企业招聘一位电商产品经理、金融产品经理或者供应链产品经理，可能默认你就应该懂得使用AI。但这不代表过去的产品经验会失去价值。恰恰相反。如果一个人既懂业务，又懂AI，还能推动项目落地，那么相比只懂工具的新人，他可能具备更强的竞争力。我也不建议所有人都追着最高薪的AI岗位跑。一个已经做了八年金融产品的经理，去做金融Agent，可能很有竞争力；让他突然转去负责底层大模型评测，原本的很多积累却未必能用上。转型这件事，最忌讳的就是看别人赚钱，自己就急着换赛道。尤其是工作了五年、十年的资深产品经理，职业经验本来就是最宝贵的资产。AI发展得越快，越应该认真想想，自己究竟懂什么、擅长什么，有哪些别人短时间学不会的东西。技术可以重新学，工具可以慢慢练，但一个人花了十年才建立起来的行业认知和业务判断力，不应该轻易清零。AI产品经理值得转，但没必要每个人都从零开始。能把过去的积累带进AI时代，或许才是大多数产品经理更值得走的路。本文由作者@老曹，授权发布于平台，未经许可禁止转载。

从共情到决断：女性产品经理真正的进阶之路
女性产品经理的共情力是优势，但过度体谅各方立场容易让产品沦为妥协的产物。本文通过真实案例拆解，如何从理解困难转向坚持目标，完成从共情到决断的认知升级，并给出四个可训练的进阶方法，帮助产品经理在协作中守住核心价值。刚转做产品经理时，我总认为站在用户角度的共情力对产品经理有着非一般的意义，也是我作为女性的天然优势——擅长换位思考。但后来我发现，自己对“换位思考”的理解过于宽泛：除了理解用户的真实需求、还会同时体察销售的业务压力、研发的技术难点，不断消化各个部门间的立场差异，最终导致我的项目沦为了“妥协”的产物。在跨部门协作中，我也习惯站在对方的角度思考问题，考虑每个人的感受，尽可能找到一个大家都能接受的解决方案。但随着工作的深入，我发现：在产品开发过程中，过度体谅他人的难处很容易陷入一个误区——顾及了所有人的立场与压力，却忘了坚持产品本该实现的核心目标。真正促使我开始反思的，是老板的一次工作方式：它不仅彻底改变了我之前的做法，也让我彻底明白，为什么很多时候我会离产品目标越来越远。面对产品目标与技术实现之间的冲突，他不会因为研发遇到困难，就轻易放弃原本希望实现的产品体验。相反，他会不断追问：问题究竟在哪里？有没有其他方案？技术边界在哪里？如果当前路径走不通，还有没有新的可能？这种对目标的坚持，让我重新思考产品经理的价值。我们究竟应该做一个善于理解所有人的老好人，还是一个能够识别关键问题、做出判断，并带领团队找到解决方案的人？共情，作为女性的天然优势，能让我们更贴近、更理解用户；但这种能力也会迁移到与同事、老板和跨部门伙伴的相处中，使我们在协作里显得温和周全，却也容易在冲突面前将“共情”异化为“妥协”。核心观点：女性产品职场，从共情走向决断，并非要我们变得强势，而是要完成一次岗位认知的升级。一、当共情变成妥协，产品经理就容易失去判断产品经理的工作，本身就是在不同诉求之间寻找平衡。用户希望体验更好，销售希望功能更丰富，研发关注实现难度与系统稳定，老板关注市场机会和商业回报。这些诉求都有合理之处，却未必能够同时满足。假设我们在开发一款产品的时候，用户希望增加一项功能，销售认为它有助于提升竞争力。但研发评估后发现，这项功能会增加成本、延长开发周期，还可能带来可靠性风险。这个时候，产品经理应该怎么办？是坚持原有的体验目标，继续寻找技术方案？是缩减功能范围，确保产品按时上市？还是重新评估投入产出，调整产品定义？这时，理解各方只是起点，真正困难的是做出取舍。现实中，和我一样共情力比较强的女性产品经理，往往会不自觉地采取比较温和的做法，选择阻力最小的路径：体谅研发的难处，主动降低要求；又担心销售不满意，于是额外增加功能；希望团队保持和谐，就处处回避冲突。结果却是，各方的意见都被照顾到了，唯独产品的核心目标越来越模糊，需求转化越来越不精准。我们忙着协调各方，却忘了初心：这些努力，究竟是在帮助产品实现目标，还是在减少团队之间的冲突？共情让我们理解不同角色为什么这样想，但作为产品经理，我们必须进一步判断：哪些诉求值得满足，哪些问题必须优先解决，哪些方案需要调整。二、理解困难，不等于接受困难过去，当需求与研发实现发生冲突时，我会考虑研发的工作压力，也会思考是不是应该适当调整要求。但在之后的工作过程中，我观察到老板处理问题的方式职中坚持一条：面对技术障碍，他不会简单地把“实现困难”当成最终结论，而是继续追问解决路径，推动团队探索更多可能。让我受到触动的，不是他比别人权利更大，而是他始终把注意力放在目标上。为什么有时候，我们在理解问题之后，第一反应是调整目标？为什么我们会把某个方案难以实现，等同于用户需求不值得实现？为什么我们花了大量时间协调各方，却没有进一步推动团队寻找新的解决路径？我开始逐渐意识到，自己需要改变的不是理解他人的能力，而是面对问题时的思考顺序。过去，我可能会先问：“研发不好实现，我们是不是应该降低一些要求？”而现在，我会先问：“我们想解决什么问题？这个目标为什么重要？当前方案为什么走不通？有没有其他路径可以实现目标？”两种思考方式，看似只是提问顺序不同，背后却是不同的工作逻辑。前者从现有困难出发，容易逐步降低目标来适应现实；后者先明确目标，再分析约束、寻找方案。与此同时，坚持目标不意味着不计代价地推进。当用户需求缺乏证据、商业价值不足，或者技术风险和成本超出合理范围时，调整目标同样是专业判断。关键在于：我们应该基于价值和证据调整目标，而不是仅仅因为遇到困难，就过早放弃对产品体验的追求。理解研发，也不能以降低用户期待为代价，而是与研发一起寻找实现用户价值的路径。产品经理不仅要提出需求，更要判断需求是否值得实现；不仅要协调资源，更要推动团队在约束中寻找最优解；不仅要关注产品能否上市，更要关注它是否真正创造了价值。三、女性产品经理的进阶，关键在四个转变从共情走向决断，职场女性产品经理不是放弃温和、变得强势，而是在保留理解力和协作能力的基础上，建立更清晰的判断标准和目标意识。给你一些在我工作过程中的进阶转变，主要体现在以下四点：1.从听见需求，到识别真需求起初，刚转行产品，我们很容易把需求管理理解为收集、整理和排期。而进阶的产品经理则会继续追问：这个需求是真的吗？重要吗？值得投入吗？例如，销售反馈很多用户希望增加一个功能。这个时候，产品经理并非应该立即排期。还需要进一步确认：这些反馈来自多少真实用户？是否集中于同一类人群和场景？它解决的是核心痛点，还是锦上添花？是否存在成本更低、效果更好的替代方案？判断需求合理性，至少关注三个维度：真实性：用户是否真的遇到这个问题？重要性：问题的频率和影响程度有多大？价值性：解决问题能否带来明确的用户价值和商业回报？需求数量不等于需求价值，声音大小也不等于优先级。产品经理的核心能力，不是收集了多少需求，而是能够从大量需求中识别出最值得解决的问题。2.从理解问题，到定义问题理解问题，是知道发生了什么；定义问题，是明确究竟要解决什么，以及什么才算成功。假设用户反映某款设备操作不方便。这时如果直接提出“优化操作体验”，设计和研发很快就会进入方案讨论。但更进一步的产品经理，会继续明确：问题发生在哪个场景？用户在哪一步受到阻碍？最需要改善的参数是什么？是减少操作步骤、缩短任务完成时间，还是降低误操作率？问题定义越清晰，团队的努力就越容易形成合力。否则，设计师追求界面简洁，研发追求实现稳定，销售追求卖点突出，大家都很努力，却未必在解决同一个问题。产品经理不仅要说清楚做什么，更要说清楚为什么做、做到什么程度，以及如何证明它有效。3.从理解各方，到做出取舍这是从优秀协作者走向产品负责人的关键一步。产品开发从来不是一道所有条件都满足的理想题。资源有限、时间有限、技术有边界，产品经理必须抛开个人情感，在这些约束中做出选择。当用户体验与成本发生冲突时，需要判断这项体验提升是否影响购买决策、目标用户是否愿意为此付费、成本增加多少，以及有没有替代方案。当上市时间与功能完整度发生冲突时，则需要区分哪些功能决定核心价值，哪些可以延后，哪些质量风险绝不能接受。真正的决断力，不是坚持自己的意见，而是基于事实和目标，明确优先级、解释取舍依据，并承担相应责任。面对分歧，我们可以尊重研发的专业判断，同时要求进一步论证替代方案；可以理解销售的业务压力，同时拒绝缺乏价值依据的功能叠加。成熟的产品经理，不是没有分歧，而是能够让分歧围绕事实、目标和价值展开，最终形成清晰的决策。4.从推动交付，到承担结果很多产品经理把项目按时上市视为工作的终点，但上市只是开始。产品是否真正解决了用户问题？用户是否愿意使用？体验改善是否带来了转化、留存或复购？投入是否获得了预期回报？这些问题才决定产品工作的实际价值。如果一项产品按计划上市，却几乎没有用户使用，产品经理就不能只用“项目已经完成”来证明工作成果，而应该继续复盘需求判断、目标用户、解决方案和验证过程。当然，产品成败受到市场、渠道、定价、组织资源等多种因素影响。承担结果，不意味着产品经理对所有因素负单方面责任，而是主动识别自己能够影响的环节，推动问题解决，并持续验证产品价值。从“我完成了任务”，走向“我帮助产品创造了什么价值”，是产品经理职业成熟的重要标志。四、决断力不是性格，而是一套可以训练的方法有人性格直接，却不一定判断准确；有人性格温和，同样可以做出清晰而坚定的决策。对于女性而言，决断力不是天生的强势，而是建立在目标、证据和取舍之上的专业能力。在日常工作中，从我的个人经验总结，可以通过五个问题训练自己的决策能力。第一，我们究竟要解决什么问题？先明确用户、场景和痛点，不要因为有人提出功能，就直接进入实现讨论。第二，我们凭什么认为这个问题值得解决？区分真实数据、用户反馈、业务判断和未经验证的假设，避免把个别意见当成普遍需求。第三，这次决策要实现什么目标？是提升体验、增加转化、还是降低成本？目标不同，判断标准也不同。第四，为了实现目标，我们愿意做出什么取舍？明确开发周期、资源、成本和风险，判断哪些代价值得承担，哪些边界不能突破。第五，我们如何验证决策是否有效？通过原型测试、技术验证、MVP、小范围试点或上线数据，尽可能降低不确定性。这五个问题，构成了一套简单的决策逻辑：明确问题→验证价值→设定目标→权衡取舍→验证结果。更重要的是，要定期复盘自己的决策。当一个判断出现偏差时，不急着为自己辩解，而是回看当时掌握了什么信息、忽略了什么风险、依据是否充分，以及下一次应该如何改进。每一次有意识的复盘，都是在把工作经验转化为专业能力。五、真正的成长，不是从温和走向强势写到这里，我想再强调下产品职场女性产品经理如何蜕变。我们没有必要因为自己先发优势，就把共情视为需要克服的弱点。共情能够帮助我们洞察用户、识别需求、理解团队，也能够让跨部门协作更加顺畅。真正需要警惕的，是当我们过于关注别人是否满意时，逐渐忽略了自己作为产品经理的专业责任。我们可以温和，但不含糊；可以理解别人，但不轻易放弃判断；可以接受不同意见，但不因为压力就随意改变方向。这才是更成熟的职业状态。我们真正需要建立的，是一种内在的确定性：清楚产品的目标是什么，明白什么对用户和业务才是真正重要的，也知道面对复杂问题时，该依据什么做出判断。核心观点：共情，是理解世界的能力；决断，是改变现状的能力。当我们能将二者结合起来，既看得见人的需求，也守得住产品的目标；既理解现实的约束，也愿意带领团队寻找解决方案，我们就不再只是善于协调的那个老好人，而是能够创造价值、推动改变的决策者。女性产品人职场真正的进阶，不是从温和走向强势，而是从理解走向判断，从协调走向决策，从完成任务走向创造价值。最后，祝每一位在产品职场打拼的女性产品经理，都能坚定地走在自己选择的道路上，既不辜负与生俱来的共情与细腻，也不放弃内心的判断与坚持，成长为团队中优秀的领导者！本文由@万物复苏原创发布于人人都是产品经理。未经作者许可，禁止转载题图来自Unsplash，基于CC0协议该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务

FDE在硅谷是香饽饽，在国内可能是个坑？
混AI圈，很难躲开FDE这三个字母。ForwardDeployedEngineer，前沿部署工程师。数据确实唬人。领英今年初的报告说，这个岗位从2023到2025年涨了42倍，同期AI工程师只涨了13倍；Indeed的口径是一年翻了七倍多。OpenAI和Anthropic前阵子几乎同时成立企业服务公司，OpenAI一出手就收购了一家英国AI咨询公司，把上百名资深FDE直接收编。国内也跟上了，腾讯在深圳挂出40到70K、15薪的FDE岗，上海ZF还专门办了FDE人才培训班。于是”转FDE，年薪百万”的帖子满天飞。我想泼盆冷水。在美国，FDE是香饽饽；在中国，它很可能是一个换了新名字的老坑。这篇文章不再科普FDE是什么，我想站在一个做了很多年产品、自己也要招人的老板角度，聊两件更扎心的事：国内的FDE凭什么大概率被做成”高级外包”；以及产品经理、研发、项目经理、运营、售前这五类人，转FDE分别会卡在哪。01同一个名字，两种活法FDE这套打法，是Palantir当年为了伺候涉密ZF客户逼出来的。它有一个灵魂假设：工程师嵌进客户团队，帮客户把能力建起来，项目结束后客户能自己跑。Palantir卖的是”能力转移”。国内甲方要的是什么？是交付物。付钱，给我系统，验收，结项，出了问题再来找你。这背后是一整套组织逻辑。海外的FDE通常是被业务一把手亲自拉进项目的，坐在会议桌中间，和客户一起定义问题，考核看业务指标变没变，钱按成果算，越做合同越大。国内的FDE往往是IT部门或采购按合同招进来的，坐在会议室角落等需求，考核看有没有按期结项，钱按人天算。你把右边这一串特征连起来读一遍：按人天收费、按需求实现、按期验收。这不就是外包吗？只不过外包出去的，是一个更贵、更懂大模型的人。所以我的第一个判断是：FDE在国内会不会沦为外包，不取决于你技术多强，取决于你被放进了一个什么样的权力结构。进了一家真想做AI转型、愿意给你话语权的公司，你是特种兵；进了一家只想”买个AI系统交差”的甲方，你就是个高级实施。02先把尺子立起来：FDE的六块拼图要对比岗位，先得有把尺子。我把FDE的能力拆成六块。动手编码，原型自己写，而且要写到能上生产，不是做个demo拍拍屁股走人。方案架构，客户的数据、老系统、权限体系，你得真能接起来。业务翻译，客户嘴里说”我想用AI提升效率”，你得把它翻译成一个能做、能验证的具体问题。推动协调，在别人的组织里把事推下去，你没有任何行政权力。客户沟通，坐得住会议桌，扛得住业务老大的质疑。结果闭环，对系统上线后真有人用负责，再把现场踩的坑反哺回产品。有个说法是FDE的时间大约四成写代码、六成面向客户。这个比例本身就说明问题：决定成败的，是后面那六成。六块里，我认为最难补、也最值钱的是两块：业务翻译和结果闭环。前者靠对行业的理解，后者靠心态和担当，这两样都没有速成班。03五个岗位，一个一个拆拿着这把尺子量下去，我发现一个规律：真正决定你能不能转过去的，往往不是你缺哪块能力，而是你原来岗位养出来的那个惯性。能力缺口可以补，惯性不改，补了也白补。售前和解决方案：离得最近，但最大的坑恰好在终点线上。售前的底子在五类人里最接近FDE。面客是满分，天天在客户现场；方案架构很强，知道怎么把产品塞进客户的IT环境；编码中等，大多能自己搭个POC。但售前有一块几乎是空的：结果闭环。售前的KPI是签单，POC做漂亮了、合同签了，就交给实施团队，人转身去追下一个商机。FDE恰恰相反，签单只是开始，你要对上线三个月后有没有人用负责。所以售前的惯性是”签完单就撤”。还有一个更隐蔽的毛病：为了成交，售前习惯过度承诺。到了FDE的位置，你承诺的每一句话都得自己兑现，这时候就知道当初画的饼有多烫手了。想转，最好的练法是主动跟一个项目，从POC一路跟到上线后三个月，亲眼看看自己的方案在真实业务里是怎么”坏掉”的。站在老板角度，售前转FDE是最快的，但前提是考核得改，你还按签单额给他算钱，他就永远是个售前。产品经理：底子第一梯队，但要戒掉”等排期”的瘾。B端产品经理最值钱的就是业务翻译，这正好是FDE六块拼图里最难补的那块。懂流程、懂权限、懂客户组织里谁说了算，这些都是PM天天在干的事。缺口也很明确：动手编码。但说句实在话，这块缺口在今天比任何时候都好补。TRAE、Qoder、Cursor、ClaudeCode这些AI编程工具，已经能让一个不怎么写代码的产品经理把原型做到能跑。问题在于从”能跑”到”能上生产”，中间隔着数据权限、异常处理、日志、回滚这些工程素养，这不是工具能直接给你的，得靠在真实项目里一次次被现实教育。产品经理真正要戒的，是两个惯性。一个是”写完PRD等排期”。FDE身后没有研发团队给你排期，你想清楚了就得自己动手。另一个更隐蔽：PM习惯做通用产品，一上来就想抽象、想复用、想平台化。FDE的顺序正好反过来，先为一个客户把事做成，再从里面抽象。顺序一反，就会变成在客户现场画平台大饼，客户最烦这个。站在老板角度，我对产品经理转FDE是最看好的。原因很简单：FDE的终极价值是把现场经验反哺产品，而产品经理天然就握着这条通道。Palantir那套Ontology本体模型，最早就是从现场项目里提炼出来的。一个能写代码的产品经理去做FDE，三年后回来做产品负责人，那是降维打击。运营：最被低估的一类人，但硬技能补课最多。很多人第一反应是运营跟FDE不沾边，我不这么看。运营有一块能力是其他岗位都不如的：结果闭环。运营天生对数字负责，知道”系统上线”和”有人在用”之间隔着多远。推动协调也强，在业务一线把一个动作推下去，是运营的看家本领。业务理解同样不差。问题出在硬技能上。方案架构和编码，是运营离FDE最远的两块。运营的惯性是”只盯数据不碰系统”，习惯在既有系统上做运营动作，从来不去碰数据从哪来、接口怎么调、权限怎么配。我的建议是别想着一步变成全栈工程师，可以先从扣子、Dify这类智能体编排平台切进去，把一个真实的业务流程用Agent搭起来跑通，再慢慢往代码和系统集成里扎。老板这边也要看清楚：一个懂业务、肯补技术的运营，往往比一个只会写代码、不会跟人说话的工程师，更接近”能交付结果”的FDE。研发工程师：代码最硬，却可能离得最远。这个结论可能会让不少工程师不服气。研发的编码是满分，架构也强，这两块是FDE的地基。但研发最缺的，恰好是最难补的那两块：客户沟通和业务翻译。研发的惯性是”关上门才写得出代码”。需求不清楚？那你先写清楚再来找我。可FDE的工作，就是在需求不清楚的地方干活。客户自己也说不清要什么，你得陪他一起把问题找出来。再加上很多工程师有技术洁癖，看到客户十几年前的老系统、堆在Excel里的业务数据，第一反应是崩溃，第二反应是”推倒重来”，而客户最不可能接受的就是推倒重来。能转好的研发，是那种喜欢看到自己代码被真人用起来的人，比起技术优雅，更享受”这东西真解决了问题”的成就感。站在老板角度，这类人最稀缺，因为愿意走出去的研发本来就少。找到一个，就是宝。项目经理：推动力满分，但也是最危险的转型路径。项目经理的推动协调是满分，客户沟通也强，天天在甲方和乙方之间周旋。缺口是编码和方案架构，硬技能几乎要从零开始。但这不是我把项目经理放在最后的主要原因。真正的原因是：国内很多公司招的所谓”FDE”，本质上就是驻场项目经理。这恰恰是FDE沦为外包的那条路。项目经理的惯性是”按计划交付，不问结果”。甘特图是安全感，范围变更要走流程，按期验收就是胜利。可FDE经常要做的，恰恰是推翻原计划，因为你在现场发现客户最初提的需求根本不是真问题。项目经理想转，第一件事是戒掉”范围变更就走流程”的本能，学会对业务结果而不是对计划负责。老板这边有个很好用的自检：如果你招FDE，最后面进来的人全是项目经理画像，那说明你心里要的其实是交付，不是FDE。04一个反直觉的排序五类人摆在一起，我的排序是：售前和产品经理在第一梯队，运营和研发在第二梯队，项目经理在第三梯队。最反直觉的是研发。代码写得最好的人，反而没进第一梯队。原因就在AI本身。AI编程工具正在以肉眼可见的速度，把”写代码”这块缺口变便宜。一个产品经理今天借助TRAE或Qoder能做出来的东西，三年前得配一个小研发团队。但面客的本事、对结果负责的担当，没有任何工具能替你补，只能靠你自己一次次下场练出来。所以我的结论是一句话：缺口好补，惯性难改。05站在老板这边，说几句不好听的先对想转FDE的人说。别被百万年薪晃了眼。那是美国顶级选手、在尊重工程师的土壤里拿到的数字。在国内，你第一要问的不是”我能力够不够”，而是”这个平台给不给FDE真正的话语权”。面试的时候留个心眼：面你的是业务负责人，还是IT部门？考核是按人天，还是按业务结果？进项目之后，你能不能见到客户真正拍板的那个人？这几个问题的答案，比JD上写的薪资更能决定你三年后是什么样子。能力可以补，但一个把你当高级外包用的坑，你再强也跳不出来。再对想招FDE的老板说，也包括我自己。想清楚你要的是FDE，还是一个便宜点的乙方。如果你心里其实是”我出需求、你来实现、出事你背”，那你要的是实施工程师，别用FDE的名头和薪资去招，招来了也留不住。真正的FDE需要三样东西：定义问题的空间，按结果而不是按人天的考核，以及他从现场带回来的反馈能真正进入你的产品路线图。还有一笔账得算明白：国内客户的付费习惯是按人天。如果你不敢跟客户谈按结果收费，FDE模式在财务上就成立不了，算到最后它就是一门毛利很薄的人力外包生意。FDE的问题，归根结底不是招人的问题，是商业模式的问题。FDE这阵风会越刮越大。但风口上，有人飞起来，有人只是被吹得团团转。区别从来不在风，在你站的地方。本文由作者@老曹，授权发布于平台，未经许可禁止转载。

功能是答案，问题是题目：AI 时代，产品经理唯一稀缺的产出
一份需求文档喂给AI，四十分钟，一个带权限的审批模块跑通了，放在两年前这是两个后端加一个前端两周的活。文章由此提出：当生成一个功能的速度趋近于零，功能的稀缺性就塌了，功能是答案，问题是题目，被重新定价的正是定义问题的能力。AI时代的功能生产过剩，正在重新定价产品经理。上周有朋友给我看了个东西。他们把一份需求文档喂给AI，四十分钟，一个带权限的审批模块跑通了，前后端都能点。放在两年前，这是两个后端加一个前端两周的活。那一刻我冒出来的判断有点冷：答案正在免费。当生成一个功能的速度趋近于零，功能的稀缺性就塌了。功能是答案，问题是题目。答案越便宜，题目越贵。AI正在重新定价产品经理，定的就是你定义问题的能力。01功能的黄昏功能过剩不算新话题，新的是它的性质变了。过去功能堆砌，代价是低效。团队忙、研发贵，进度一拖再拖，但方向大体没错，堆出来的东西总有人用。现在代价变成致命。生产成本塌了之后，你手工堆三个月，别人AI堆三天，堆功能从战术问题变成了生存问题，而且这个差距追不上。Intercom的联合创始人DesTraynor有句话说得狠：多数团队把交付当成功，把学习当浪费。翻译一下，上线即终点。上线之后用户为什么不用、在哪一步断掉，没人管。国内SaaS这两年把这个现象演得很足。为了拿下标杆客户，一家公司能给采购流程加七八种定制审批。为了对齐友商，首页能塞进十几个入口。功能清单越拉越长，NPS一路往下走。销售签单靠“我们功能比他家多三条”撑场面，交付之后这三条从来没人打开。我管这个过程叫功能的过度繁殖。生物学上它意味着什么，数量增速永远快于资源增速，环境一变，批量出清。AI就是那个环境变量。它把“做出来”的成本压到极低，也把“为什么做”的价格抬得很高。一个只擅长做功能的PM，正在失去定价权。答案不值钱了，你还在按答案的规格要求自己。02功能思维是怎么长出来的功能思维是环境一步步训练出来的结果。拆开看，有四个机制。第一个机制最日常，叫需求直译。客户在会上说，能不能加个导出按钮。PM点头，记下，回到工位把“导出按钮”四个字原样填进需求文档，补上交互和字段细节，标P0。一场会开完，从耳朵到文档，全程零加工。客户说出来的永远是他想象的解决方案，PM只做誊写的话，AI比你誊得快一万倍。第二个机制是竞品绑架。竞品上了新功能，焦虑立刻传到老板那里。老板问的是“我们什么时候有”。为什么做，从头到尾没人问。于是路线图的排列逻辑，从什么最重要，悄悄变成别人有什么。第三个机制藏在考核表里。季度OKR写的是完成了多少需求、上线了几个功能。交付可量化，周报里写出来漂亮，庆功的时候也理直气壮。至于上线之后有没有人用，那是下个季度的模糊地带。人以交付计，行为自然向交付对齐。第四个最难承认，存在感焦虑。B端公司里PM的日常存在感靠什么撑？写文档，画原型，剩下的时间追排期。这些动作看得见，摸得着，周报里列得出来。坐在客户旁边看他们用一下午系统，或者花三天想清楚一个问题，在很多人眼里等于没干活。产出焦虑逼着PM制造看得见的产出，哪怕产出只是一个又一个功能。四个机制叠在一起，功能思维就成了顺理成章的反应。环境奖励交付，惩罚思考，换谁都练得出来。03翻译，PM最值钱的动作拿一个最常见的功能解剖一下。客户要导出按钮。往下挖一层，为什么要导出？他说每月要给领导交一份经营月报。再往下，月报里的数字从哪来？从系统各个模块里翻，翻一个小时，凑齐了填进Excel。到这里，真问题浮出来了：他要的是月报生成这个动作本身。导出只是他能想到的路径。功能方案到这里才真正展开。可以是导出，可以是每周自动推送一封月报邮件，甚至可以让系统直接把月报生成好。照着原始需求做导出按钮，客户拿到的还是那一小时的手工活，只是换了个地方复制粘贴。需求是外语，问题是母语。客户用功能说话，用户递过来的从来都是答案的碎片，问题藏在碎片后面。PM的手艺，是翻译。说一个我们正在做的项目，制造业企业的宿舍管理系统，替换一套用了多年的Excel。前期访谈了一批宿管阿姨和后勤主管，需求清单拉出来很长，报修要拍照上传，晚归要打卡，连访客登记都排上了号。每条都具体，每条都像刚需。调研往深走，我们在调研里看到的真问题是另一回事。宿管阿姨每天最重的负担，是晚上十一点后挨个楼层点名，手工抄，抄完录系统，两层楼要一个钟头。她们要的是一个人在不在的确认机制。项目还在建设中，最后能交出什么，现在下不了结论。但团队已经确认了一点价值：调研阶段就把点名这件事翻译了出来，后面的功能取舍第一次有了标准，哪些需求服务确认机制，哪些只是噪音，开会不再靠嗓门大。怎么练翻译？三个动作。追问链。失败的画面你一定见过：客户提需求，PM打开文档边听边记，记完确认字段，散会。全程礼貌，全程无效。动作很简单，对每个需求连问三层为什么。要导出，为什么。做月报，为什么偏偏是月报。这份月报谁看，看完他要干什么。问到第三层，话题往往已经换了内容。场景还原。会议室里想象用户，和蹲在用户旁边看，是两回事。Instagram的前身叫Burbn，一个功能繁多的签到应用。创始人发现用户反复只做一件事，传照片加滤镜，于是砍掉其余一切，才有了后来的Instagram。场景里看三天，胜过会议室里猜三个月。B端同理，你不在宿舍楼里蹲一个晚上，想不到点名是核心场景。问题重述确认。翻译最容易断在最后一步，PM心里懂了，文档里写的还是原始需求。动作是当着客户的面复述问题：你真正头疼的，是每晚点名占掉一个钟头，对吗。对方点头或摇头，都比你在文档里猜要值钱。点头，方向锁死。摇头，他往往会顺嘴说出更接近真相的版本。04检验你的问题定义问题定义也有质检标准，三个要素：谁，在什么场景，被什么卡住。缺一个，问题就是虚的。对照着看两条需求。第一条，优化报表导出体验。第二条，连锁品牌的区域经理每周一早上要给总部交经营周报，系统数据分属五个模块，他每周五下午花两个小时手动拼一张表。第一条写的是功能，第二条写的是问题。评审会上哪条能吵出结论，一目了然。汽车行业有个现成的样本。五菱做宏光MINIEV之前，去三四线城市看人们怎么出行，看到的场景具体到不能再具体：接送孩子，买菜，一趟三五公里，停车比开车还难。定价和尺寸直接来自这些问题，两三万，四个座，塞进巷子不难。如果当初问的是怎么造一辆便宜又体面的燃油车，答案再标准也到不了这里。问题定义对了，答案可以粗糙，有迭代空间。问题定义错了，答案越精致越浪费。AI在这件事上是个双向放大器。放大器只认输入。问题定义清楚，AI替你解题，一天迭代十个方案。问题定义是糊的，AI放大的是糊，十个平庸方案一天之内全部到齐，你连错在哪都来不及想。工具越强，用工具的人判断力越值钱。05PM的新坐标回到开头的画面。四十分钟跑通一个审批模块，那一刻真正要紧的事只有一件：提问的资格还攥不攥在你手里。功能是答案，问题是题目。AI把答案的供给拉到无限，题目的稀缺就成了唯一值钱的东西。前面聊过AI把执行成本压到极低，这次想说的是后半句：成本归零之后，剩下的东西才叫能力。AI淘汰的产品经理只有一种：拿到答案就开工的那种。如果你只想带走一个动作，试试这个。下一个需求评审之前，把需求用三个要素重写一遍：谁，在什么场景，被什么卡住。写不出来就先别排期，先去问，先去看。这不丢人。恰恰相反，这是眼下最值钱的半小时。功能会被生成，问题不会被生成。题目永远在等人出。本文由人人都是产品经理作者【简单有道】，微信公众号：【简单有道】，原创/授权发布于人人都是产品经理，未经许可，禁止转载。题图来自Unsplash，基于CC0协议。

一年前说 PM 会被淘汰，现在 Anthropic 说：人人都得学会当 PM
在一场现场对话里，Anthropic的AmiVora把产品定义成连接人们的问题与可用技术的桥：人的一侧变得慢，技术的一侧却从五年一变变成两个月一变。她的同事MikeKrieger转做一线贡献者后，被提醒项目需要一个PM。一年前，有人说AI可能让PM（productmanager，产品经理）变得多余。现在，气氛变成了人人都要学会当PM。这是主持人DanShipper在开场时的原话，台下笑了，但他问的是一个真问题：做东西越来越容易，为什么反而更需要有人去决定做什么、对结果负责？这是9月10日LennyandFriendsSummit在旧金山的一场现场对话，Lenny’sPodcast在9月29日发布了视频。嘉宾是Anthropic的AmiVora和MikeKrieger，两人都在做产品，Mike今年年初转做IC（individualcontributor，一线贡献者），现在主要自己动手做东西。他们要回答的是：当技术每隔两个月就变一次，PM这个角色还剩什么，又有哪些东西该扔掉？我看完的判断是，PM的工作没有消失，只是最贵的部分换了位置。技术两个月变一次，人的问题没有变Ami对PM的定义很简单：产品是连接现实中人们的问题和可用技术的一座桥。这一点一直没变，变的是节奏。过去技术可能五年、十年才变一次，现在感觉是两个月一次。她说，作为一个人，要适应这种速度真的很难。所以她的办法是把两边拆开看。人的一侧变得慢，大家遇到的还是那些问题，那就一直盯着人的问题不放。技术的一侧则要保持新鲜的眼光：把自己知道的“过去这个问题怎么解决”大部分扔掉，带着对问题的理解重新试一遍。她还说，现在有点像把时钟拨了回去。她刚入行的时候，这份工作没有清晰的定义，PM就是一个通用的问题解决者，到处走，撞到墙了就去问人或者想办法。现在角色的边界又在变模糊，只不过这一次，撞墙之后手边有各种各样的脚手架可以用。我觉得这段话把“变”和“不变”拆得很清楚。很多关于PM会不会消失的争论，其实是把两件事混在了一起：做事的方法在飞快过期，做事的理由却没有。理由没变，就意味着这个角色不会凭空消失，但做法要随时准备重来。Mike以为Claude能顶替PM，被提醒后改了口Mike讲了一个最近的经历，几乎就是对开场问题的回答。他转做IC以后，手上有个项目快要上线，一位和Ami合作的PMlead把他拉到一边，说这个项目需要一个PM。他的第一反应是：真的需要吗？Claude不是已经能搞定了吗，我们手上事情还很多。对方坚持说需要。等她加入之后，他才看到所有那些如果自己不管就会掉在地上的胶水和连接工作。一周后他回头给她发消息说，你是对的。他列了一串这个角色在做的事。Anthropic的客户从个人专业用户到大型企业都有，各种情况有没有考虑到？客户成功团队要在问题实时冒出来时给出解释，有没有人想过？安全防护有没有拉进来？大家是不是都在正轨上？哪怕有AI帮忙，也没有人有无限的精力。需要有人确保一切接得上，始终惦记着最终用户，这样埋头做事的人才能一直埋头，不用时不时抬起头去做另一种完全不同的活。Dan追问得很直接：为什么不干脆让Fable来做？Mike的回答是，他们内部确实在用Claude做很多连接工作，它能提醒你，组织里另一个角落正在发生和你有关的事。但他认为，Claude目前还不是一个convenor（召集人）：总得有人把Claude们和人聚到一起，让事情落地。他开玩笑说，等哪天Claude自己给他排了一个会，他会问是谁约的，然后发现是Claude觉得他们两个该聊聊。这件事还没发生，“但不是因为做不到，大概只是我们还没打开那个设置”。我的想法是，这一段值得小心读。Mike自己都说了，“还不是召集人”不等于“做不到”，所以拿它当PM的护身符是靠不住的，它有保质期。更稳的理解是，这类工作的难点在于需要有人对“整体有没有接上”负责。速度变快以后，漏掉的东西更容易悄悄溜走，Mike也说，这个角色现在要做得比以前更精细。如果你在组建团队，这顶帽子只会越来越重要。过去引以为傲的手艺，有一部分已经过期Ami讲了一件让她不太舒服的事。她花了很长时间训练自己站到用户的角度，想象一个功能怎么放进别人的生活。因为过去做出来、上线一个东西太贵，所以评审会上要反复讨论按钮放哪里，手指在手机上怎么移动，用户是在什么情境下把手机从口袋里掏出来的。她说，现在大概没有人会再问她这类问题了，更快的办法是直接做三个版本试一试。她觉得最难的是身份。大家都知道创新者的窘境，说的是一家公司太擅长某件事，就一直做下去，哪怕应该试试别的。她说个人也一样：你知道自己擅长什么，就想继续做下去，哪怕新的方法在未来更重要。她也没有在模型公司工作过的背景，所以每过几个月，就得对自己说：好，那就试试这个，看能不能弄明白。那什么能力是现在更需要的？她列了三个：适应力，也就是把自己对变化的容忍上限抬高；判断力；还有一股不屈不挠的劲。后两个其实来自同一个变化：工具越好，能做的东西越多，岔路就越多。你得在信息有限的情况下判断要做什么，然后比过去更执着地让它真的发生。她也谈到怎么带团队。不确定的时候，人会忍不住想把一切规划清楚，包括要做哪些产品、职业会怎么走，这是一种拿回控制感的办法，但会把你锁在新东西之外。她的做法是framethechaos（给混乱搭一个框架），让大家觉得参与进来是安全的，也承认这里面有情绪，不轻松。Mike补了一句，混乱之外需要清晰的DRI（directlyresponsibleindividual，直接责任人）。实验室里把一个个尝试叫做bet，每个bet都有一个lead，由他来说该不该加码、该不该收掉、团队要加人还是减人。用他的话说，大家一起在黑暗里摸索，但总得有人握着笔。我觉得这里有个容易被忽略的细节：被淘汰的不是某个岗位，而是岗位里一些很具体的手艺。按钮该放哪里这种判断，过去是稀缺能力，现在被“做三个版本试一试”取代了。真正难的不是学新东西，而是承认自己最拿手的那一块已经不值钱了。软件要让agent也能用，先把基础零件做对话题转到产品本身，Dan问Mike，当软件的使用者从只有人，变成人和AIagent一起用，应该怎么设计。Mike给了一条时间线。最早是把AI放在一个侧边栏或者小窗口里，和产品其余部分是断开的。后来有一些功能本身由AI驱动。再往后是agent-native（原生为agent设计）：人能做的事，agent也应该都能做。他说很少有产品真的做到了这一点，包括他们自己的产品。可一旦做到，就会冒出一些新的行为，比如agent能把以前没连起来的东西拼到一起，或者主动提出别的做法。他认为下一步是界面本身也能被agent改写，也就是malleablesoftware（可塑软件）。这个概念谈了很多年，他觉得现在真的在变成现实。他举了一个内部的例子：他们正在做一个比较复杂的项目，至少有四条独立的工作线。团队让Claude一边盯着进展，一边生成界面，先给TPM（technicalprogrammanager，技术项目经理），再给整个团队看项目现状。你不喜欢这个界面，就不必接受别人决定好的样子，可以和Claude一起改。他说，过去一年Anthropic里最大的变化之一，就是大量日常用的软件由Claude构建、维护和迭代，随时都在变。这也带来新问题，比如谁可以更新数据，是人点击，还是Claude在后台改，数据的来源该怎么追溯。如果你是一家已经有成熟SaaS产品的公司，该怎么选？Mike的建议是，核心是在产品里建好primitives（基础组件），像一层基础设施。他自己每次用新产品，都会让它做一件人能做、但需要想一想的事，看操作是否都走同一套底层通道，让agent和RESTAPI（常规的程序接口）能共用。想得周全的产品，用起来能感觉出来。他也承认，一个做了20年的应用要后补这一层很难。好处是一旦做对，就可以一步步演进：先保留侧边栏，再试一个更可塑的个人首页，用的是同一套底层，不必重新发明基础设施。感觉“贴上去”的产品，就是没有这一层。我觉得Mike的这个检验法比很多方法论都实在。判断一个产品是不是agent-native，不看它宣传里有没有AI，而看它里面一件稍微复杂的事，是不是走同一条底层。如果每个入口各走各的，那agent永远只是后加的访客。多押几注，再收拢成一个产品Anthropic要同时服务很大一段范围的用户：想往前冲的人，只想聊天的人，有大企业合同、不能一天之内换掉界面的客户。Dan问，这怎么平衡？Ami说得很坦率：这是个很难的问题，他们的做法是尽量在每个人所在的位置上接住他们。现在要弄清楚什么有效还太早，产品不是稳定的，不是找到正确答案做出来就行，是大家一起探索。所以她鼓励团队多试，哪怕几个东西有点重叠、有点重复，等弄清楚、找到PMF（product-marketfit，产品和市场匹配）之后，再回过头把它们整合成一个对所有人都说得通的东西。她把最坏的结果说得很具体：一开始就根据一套理论认定“应该这样”，把产品限制得死死的，一个连接市场的机会都没给。她宁愿要五个互相重叠、各有做法的产品，也不要一个被过度约束的。Mike补充了一个关键条件：这些方向要有真正兴奋的团队。他说，让一个对方向不感兴趣的团队去做一个“B队”的产品，从来没成功过，结果一定很糟。并行实验要能做起来，靠的是底层。Mike说，几个月前，chat和Cowork的记忆系统、MCP（ModelContextProtocol，让AI调用外部工具的协议）和文件存储方式都不一样，在上面做新实验会很吃亏：做出来第三个东西，和另外两个都不共享记忆，一开始就像是被孤立了。所以他们有个foundations团队专门解决，让你不管在哪个产品里，都能带着自己的记忆。他强调，这类事要交给不同于创新团队的人去做，实验才会彼此互补，哪怕有重叠。Ami则强调，要把话说出来：三个方向并行，有时会让人沮丧，觉得自己是不是被放弃了。这没关系，这是我们所处的世界，没有人知道答案，我们都在同一个团队里。怎么知道一个东西开始有效了？Ami说，大部分还是普通的PMF信号：人们用不用，喜不喜欢，会不会回来，会不会和别人聊，有没有得到价值。产品的目标没变，还是解决问题。Mike还讲了一个很有意思的做法：把项目“停放”。他们2024年在Anthropic内部做出了第一个computeruse产品，当时模型还不够强，用起来很糟。起初他们想，也许它不适合做自动化，但适合做教学，比如问怎么在Photoshop里做一件复杂的事。结果它能做到，但是用的是早期agent那种方式：试一下，不行，关掉再来，二十分钟后终于做成了，你什么也没学到。自动化和教学两头都不行。于是他们把它停放了，之后每出一个新模型，就放进evalharness（评测框架）里跑一遍。有一次换了新模型，他们突然发现它成功的次数多过失败，翻看记录，意识到这是真正的变化。他们在实验室里把这也算作一次胜利：就算项目只证明了模型还没准备好，只要沉淀成eval，或者和研究团队建立了连接，几个月后就可以重新来过。他的看法是，要早点做，才会有这种直觉。Dan接着说，这有点像一种capabilityblind（能力盲区）：试过一次，没成，就再也不试，也不做评测，结果三个月后新模型出来，在他们想不到的地方变好了。他说自己常遇到别人说“它做不到这个”，一问，用的还是旧模型。最后一个难题，是并行实验里有一个跑通了，要怎么放回产品。加一个tab，tab越来越多，各自的用法不同，看着很难看。做成独立的app，又永远不合并。Ami半开玩笑说“我不知道你在说什么”，然后承认没有完全想清楚。她的方向是回到primitives，让产品用起来是该有的样子，别把认知负担一股脑转给用户，说“这里有一堆工具，你自己选吧”。Mike从Instagram的经验补了一个现实判断：使用高度集中在主feed，大概占80%，把explore做好，也许只是从10%到15%。所以永远要问，主tab是什么，怎么把这个体验做好，再让它成为通向其他体验的入口。他说，PM一半的工作，是对侧边栏里多一个东西、多一个tab说不，同时又判断它能不能在验证后被合并进来，而不是太早杀掉。做东西变便宜之后，值钱的是判断和收拢回到Dan的问题，我对这场对话的理解是：AI没有取消PM的工作，是换掉了这份工作里最贵的部分。以前贵在做之前想清楚，因为做错的代价高，所以才会为按钮放在哪里反复开会。现在做错便宜了，贵的是三件事：信息不足时决定做什么；在越来越多的岔路里持续推进；把并行出来的东西接起来、收拢成一个产品。Mike讲的接缝工作、Ami讲的判断和执着、两人都讲的主tab和primitives，其实说的是同一件事。不过要读出这场对话的边界。这是模型公司的内部视角。Anthropic有foundations团队专门去统一记忆这类底层，有实验室可以把项目停放起来等新模型，这样的余量大多数公司没有。视频里也没有给出任何数据，说明并行押多个方向的成本有多大。而且“PM”在这里更像是一顶帽子：Mike自己是IC，也需要有人替他戴上。他说Claude还不是召集人，却没有说它做不到，所以这个结论会过期。如果要把这场对话变成具体的行动，我会留两个检验。一个是Mike的：让自己的产品做一件人能做、但要动点脑筋的事，看它是不是和agent走同一条路。另一个是Ami的：列出自己最引以为傲的几项手艺，问问哪一项现在用“做三个版本试一试”就能替代。技术每过几个月就换一次，该扔掉的是做法，留下来的，应该是“这个人到底遇到了什么问题”。本文由人人都是产品经理作者【深思圈】，微信公众号：【深思圈】，原创/授权发布于人人都是产品经理，未经许可，禁止转载题图来自Unsplash，基于CC0协议

产品开发中，产品经理为什么特别重要？
会员续费入口优化，看似简单的功能需求，实则暗藏业务判断的深水区。本文以一款付费模板工具为例，拆解如何从“没续费”的表象中定位真实卡点，通过冻结名单、明确观察窗口与主指标，构建可检验的续费过程。运营提出一个需求：把会员续费入口做得明显一点，快到期时再提醒一次。这件事很容易被拆成几项开发任务：增加按钮、配置提醒、接入支付、延长会员有效期。但这些功能都能正常运行以后，还会剩下一个问题：原来没有续费的人，会因此愿意续费吗？产品经理的作用，往往就在这个问题里。团队需要有人判断，眼前的功能究竟在解决哪种业务问题，以及怎样知道它解决了问题。下面用一款提供付费模板导出的工具作业务示例。为便于讨论，设定会员每期有效30天、由用户手动续费，不涉及自动扣款。情境和规则用于说明方法，不对应真实项目，也没有预设的转化结果。一、先分清没续费的人，究竟卡在哪里会员没有续费，原因可能很不一样。有人用过模板，也准备继续用，只是没有注意到到期时间；有人主动找过续费入口，却没找到；有人已经下单，但支付没有完成；还有人这个月根本没用过付费权益，觉得不值得再买。只看“续费人数不够”，这些人都会落在同一组里。但一个到期提醒，显然解决不了全部问题。所以，在确定按钮放在哪里之前，要先把会员的使用记录、续费路径和用户反馈对起来。谁用过核心权益？谁进入过会员页？支付失败集中在哪个环节？用户不愿续费，是暂时没有任务，还是没有获得预期价值？数据可以帮助定位行为，具体原因还需要结合用户反馈。没有点击续费入口，不能直接推断为“不知道入口在哪里”。为了继续这个示例，假设本次核对已能复现两个问题：到期信息不够醒目，会员页的续费入口不容易找到；现有支付通道则可以使用。团队据此选择一个明确目标：帮助本周期已经使用过模板、仍待续费的临期会员，看清有效期和权益，并顺利完成手动续费。这次先改善到期信息、权益说明和续费入口，不同时增加折扣、改会员价格或引入自动扣款。否则多项改动混在一起，后面很难判断究竟是哪一项起了作用。用过模板，也不等于一定愿意续费。它只是本次选择人群的依据。没有使用过权益的会员，应另查激活和产品价值问题；不能把这部分人从报表里去掉，就宣布整个会员业务变好了。目标定到这一步，团队才知道哪些功能值得进入本期，哪些问题暂时没有被解决。这个判断会同时改变设计、研发、运营和数据的工作。二、同一批会员，究竟怎样算续费了目标明确了，指标也要在开发前说清楚。如果只记录新按钮的点击率，很容易得到一份好看的报告，却回答不了业务问题：原来从会员中心续费的人，可能只是改从新按钮进来了，总续费人数并没有变化。先把观察对象固定下来。本例约定，在每位会员原定到期日前7天，记录其原始到期日，筛出本周期已经完成过付费模板导出、尚未提前续费的人，形成待观察名单。之后即使他续费、退款，或者没有再打开产品，也不把他从这份名单里移走。这里用的是冻结名单之前发生的使用行为，不能等改版上线后，再挑出使用最积极的一批人计算结果。续费改变的是会员的新有效期，原始观察日期也不能跟着重算。接着观察原定到期日前7天至后7天。这是本例约定的窗口，不是通用行业标准。主指标看这份名单中，有多少人在窗口内完成了支付，并且新一期权益确实生效；同一会员只计一次，从任何正常续费入口完成都要算。因此，这个指标只表示“目标临期会员的续费完成率”，不能代表所有会员。它也不等于净收入或长期留存，后续退款和再次使用还需要继续观察。新入口的曝光、点击、下单和支付，则用于解释主指标为什么发生变化。曝光后少有人点击，可以进一步看表达和使用场景；点击后大量中断，需要检查购买信息和操作过程；支付成功却没有取得权益，则是履约问题。这些信号帮助排查，却不能替用户表态。按钮点击只说明一次行为，不能直接证明他理解了价值。到这里，产品经理需要和数据、研发一起确认事件及状态来源。等功能上线后才想起补埋点，往往已经无法还原改动之前的情况。三、一个续费入口，背后有两套状态接下来才进入具体设计。会员页需要让用户看清当前到期时间、这次购买的权益、价格，以及续费后的新有效期。到期提醒应把人带到正确的续费位置，已经完成续费的人也不应继续收到针对旧到期日的催续信息。真正容易出错的，常常是这些页面背后的规则。首先，会员有效期与续费订单是两套状态。一个仍然有效的会员，可以有一笔支付失败的续费订单。不能因为这笔新订单失败，就把他原本仍有效的权益收掉。其次，支付完成和权益生效之间还有一步。如果钱已经付了，会员时间却没有延长，系统需要能够识别和跟进这个断点。页面不能只显示一句“支付成功”就让用户自己等，也不能引导他反复付款。本例进一步约定：未到期时续费，新一期从原到期时间顺延；已经到期后续费，新一期从本次订单约定的支付成功时间起算。因为每期固定30天，购买页应明确展示计算后的新有效期，避免提前续费反而损失剩余时长。这些属于业务规则，需要产品、业务与相关团队确认。研发负责选择可靠的实现方式：同一订单的支付通知到达多次，不能多发几期权益；用户反复点击，也不能在不知情的情况下生成重复购买。测试则需要准备对应的验证场景。退款同样要与具体订单及其权益关联。退掉一笔续费订单，不等于可以直接删除用户全部会员权益。应按已确认的退款及权益规则处理，并让客服能查到订单和有效期变化的原因。这些问题很难由任何一个岗位独自回答。设计需要知道该展示什么，研发需要知道哪些变化被允许，测试需要知道怎样才算正确，运营和客服需要知道如何触达用户、如何解释异常。产品经理要做的是把这些判断放进同一份方案：未确定的规则由谁确认，哪些结论会影响其他团队，改了以后需要同步到哪里。把信息在群里转发一遍，还不算完成这件事。这也是产品经理在开发中的重要作用：他要持续检查，各团队正在实现的局部功能，能否接成同一条完整的用户路径。四、验收通过以后，再看业务问题有没有改善上线前，先按确认过的目标和规则检查功能。一个仍有效的会员提前续费，剩余时长要被保留；一个已经到期的会员完成购买，新一期权益要按约定生效；一次支付失败，不能破坏原有权益；重复通知、支付后发权延迟、退款处理，都要有明确结果和处理责任。提醒是否仍按旧到期日发送，客服是否能定位相关订单，埋点是否覆盖了约定的观察人群，也属于上线准备。产品验收关注业务规则和路径，测试提供质量验证，研发与运维确认发布、监测和回退条件。功能能够可靠运行以后，再看原先固定的那批会员。有人看到了提醒但仍未续费，可能要继续核对权益价值和使用需求；有人发起支付却没有完成，先排查支付过程；有人完成续费却迟迟没有再次使用，则需要观察购买后的体验。不同问题对应不同动作，不能看到一个总转化率就统一加大推送。退款、投诉和再次使用，也要给每位续费用户同样长度的后续观察时间。窗口最后一天才购买的人，不能因为还没有来得及使用，就被计成“续费后不活跃”；观察尚未结束的记录应标为待观察。续费完成率上升，如果同时伴随更多退款或问题反馈，也不能直接下结论说改版成功。历史记录可以提供参照，但相同口径下看到变化，仍不足以证明是新入口造成的。季节、流量来源和权益内容都可能影响结果。如果条件允许，可以在名单冻结时安排同期对照，并按原来的分组统计；不能事后只挑看到提醒、点过按钮的人比较。没有这些条件，就如实记录观察到的变化，结合行为和反馈继续排查。产品经理的判断也包括知道哪些结论现在还下不了。回看最初的需求，如果团队只收到“加按钮、发提醒”，完全可能交付一套能运行的功能。而把用户问题、目标人群、有效期规则、支付发权和结果判断补齐后，团队交付的才是一段能够被检验的续费过程。这些工作可以由具备相应能力的其他角色分担，但必须有人持续负责把它们接起来。产品经理之所以重要，就在于这份连续的责任：让每一项开发工作有明确的业务依据，也让上线后的结果能够反过来检验最初的判断。本文由@AI产品经理老猫原创发布于人人都是产品经理。未经作者许可，禁止转载题图来自Unsplash，基于CC0协议

AI 时代产品经理的竞争力迭代：从方法论执行到经营判断力升维
AI已能自动完成PRD撰写、竞品分析等基础工作，产品经理的执行瓶颈被打破，判断力成为新的核心短板。本文从瓶颈理论、半人马模型与Cynefin框架出发，结合实战经验，探讨产品经理如何从执行者升级为经营者，构建AI时代的高阶判断力。笔者此前在文章《方法论被自动化之后：产品经理真正的壁垒是隐性知识》中提出过一个观点：产品工作的标准化方法论属于显性知识，可被编码、复刻，大概率会被AI逐步自动化；而判断力属于隐性知识，难以标准化、无法完整编码，是AI难以习得的核心能力。结合笔者自身多年产品岗位的成长经历来看，时至2026年，这一判断的前半部分已基本落地。Productboard2025年的行业调研数据显示，产品经理借助AI工具，单任务平均可以节省4小时工作时间。当前AI已覆盖产品工作多项核心场景，能够独立完成PRD撰写、用户故事拆解、竞品分析、用户反馈聚类、测试用例生成、产品路线图更新等常规工作。同时，产品助手、原型生成、需求管理、可视化协作、数据分析、交付跟踪等工具，已经形成相对完善的AI产品工具生态。从笔者的实战工作体验来看，如今的产品工作效率已经实现大幅革新：输入基础需求描述，三十秒就能生成一份结构完整的PRD初稿；导入用户访谈记录，五分钟就能完成需求聚类与优先级初步建议；批量上传竞品资料，就可以自动输出竞品对比矩阵。三年前需要半天至两天完成的基础性工作，如今已压缩至分钟级。产品标准化方法论的自动化已然成为常态，但笔者觉得，行业发展并未走向“产品经理被替代”的单一结局，反而推动产品岗位的价值逻辑迎来全新迭代。基于从执行效率不足到判断力缺失这一趋势，笔者将在本文中深入探讨产品经理的能力升维路径：仅停留在项目执行层面的判断，可能已经没办法适配行业发展，结合笔者的项目实战感悟认为，产品经理需要逐步建立经营视角，以经营者思维完成产品决策与价值取舍，实现判断力的高阶升级。一、工作瓶颈转移：从执行效率不足到判断力缺失笔者认为，借助经济学瓶颈理论，可以把AI对产品工作的核心影响清晰地拆解出来：一条工作流水线的整体产能，由效率最低的核心工序决定，优化非瓶颈工序无法有效提升整体产出，只有打通核心瓶颈，才能实现效率升级。产品经理的工作链路可以简化为：需求理解、方案设计、文档撰写、评审对齐、验收交付。在AI工具普及前，产品工作的核心瓶颈集中在执行层。PRD撰写、竞品梳理、需求拆解、流程图绘制等工作重复性高、耗时久，从笔者过往的实战经历中能够看到，产品经理的大部分精力都耗费在“将思维逻辑转化为标准化文档”的落地过程中。彼时，标准化方法论是产品经理的核心竞争力，能够快速将判断落地为文档、推进项目落地的从业者，就能形成岗位优势。AI的普及打破了这一执行瓶颈。文档撰写、竞品分析、流程梳理等基础工作效率大幅提升，原本制约工作推进的执行效率问题基本得到解决，不再是产品工作的核心短板。随着执行瓶颈的消解，判断力不足成为产品工作新的核心瓶颈。AI可以高效完成标准化执行工作，却没办法完成核心决策判断：AI能够快速生成PRD初稿，却不能判断内容的合理性、适配性与落地价值；AI能聚类整理用户反馈，不过，不能区分有效需求与无效噪音；AI能输出多套产品方案，然而，不能结合企业资源、组织约束、战略方向筛选最优方案。在AI普及前，执行工作占据产品经理80%以上的工作时长，判断力的价值被大量重复性工作掩盖，即便判断能力突出，最终产出也会受限于执行效率。笔者从自身成长经历中得出，普通从业者依靠标准化方法论就能够完成基础工作，判断力出众只是锦上添花。在AI接管大部分执行工作后，执行耗时被压缩至整体工作的20%，判断力的权重被大幅放大。产品经理的核心价值不再是“落地执行”，而是“精准判断”。能否做出高质量的需求取舍、方向决策、方案筛选，直接决定工作产出的价值。此时，判断力不再是加分项，而是产品经理立足的核心基础。缺乏判断力的从业者，无法甄别AI输出内容的优劣，工作价值会持续被压缩；具备优质判断力的从业者，能够借助AI放大工作成果，实现价值倍增。二、人机协同半人马模型：胜负核心在于协作质量2005年，国际象棋世界冠军加里・卡斯帕罗夫发起国际象棋自由式锦标赛，赛事允许任意参赛组合，包括纯人类、纯机器、人机协作。赛事初期，多数人认为“顶级棋手+高端超级计算机”的组合会包揽冠军，最终夺冠的却是两名业余棋手搭配三台普通商用电脑的组合。卡斯帕罗夫的发现卡斯帕罗夫后续在《哈佛商业评论》的复盘研究中提出：能力较弱的人类与普通机器，搭配高效的人机协作流程，能够战胜能力更强的人类与高端机器的低效组合。人机协同的核心竞争力，不在于人或机器的单一绝对能力，而在于二者的协同适配质量。这一结论，便是经典的“半人马模型”。将该模型落地到产品岗位，结合笔者的实战观察可以看到，从业者的能力层级可以清晰地划分为：仅具备判断力但不擅长运用AI的产品经理，竞争力弱于判断力普通、但熟练驾驭AI的从业者；而兼具优质判断力与高效AI协作能力的“半人马型”产品经理，才能形成核心竞争优势。笔者觉得，半人马模型的核心不是简单使用AI工具，而是精准把控人机分工的边界。业余棋手夺冠的关键，并非设备或个人棋力占优，而是清晰掌握机器的能力边界：明确哪些场景可以依托机器决策，哪些场景需要人工干预修正，熟知机器的优势与系统性短板。笔者认为，适配产品岗位的人机协同能力，主要包含三层核心内容，且三层能力均依托产品经理的隐性判断能力：第一，精准放权，明确AI可以决策地场景。对于结构化、模式化、纯数据驱动的常规工作，可以交由AI处理，充分发挥其高效执行的优势；第二，及时干预，overrideAI的局限性输出。涉及组织协作、隐性业务背景、价值取舍、利益平衡的复杂场景，AI输出存在天然短板，需要人工主导修正决策；第三，精准提问，提升AI输出质量。依托自身对业务问题的深度理解，将模糊的业务需求，转化为AI可识别、可落地的指令，从源头保障输出有效性。从笔者自身成长经历中得出，从业经验丰富的产品经理，积累了大量项目经验与隐性业务认知，能够更精准地判断AI的能力边界、识别输出漏洞，这是新手难以快速复刻的核心优势。在此基础上，笔者认为，高阶产品能力的核心差距，体现在格局与视角的差异：普通从业者以执行者视角判断任务落地可行性，而笔者认为，优质从业者会以经营者视角，判断工作的实际价值、收益与代价，让产品判断从项目执行层面，升级到经营决策层面。三、Cynefin决策框架：找准AI与人工判断的能力边界DaveSnowden提出的Cynefin框架，构建了一套完整的感知、应对问题的决策体系，将所有工作场景划分为清晰域、繁杂域、复杂域、混乱域四类，不同场景对应不同的因果逻辑与应对策略。笔者在多个业务项目中尝试将该框架适配产品工作场景，可清晰区分AI的有效应用范围与人工判断的核心价值场景。从整体适配效果来看，AI在清晰域场景中基本可以实现全覆盖，在繁杂域中能够提供高效辅助，在复杂域中仅能发挥有限作用，在混乱域中则基本无法适配。同时，AI的能力边界始终在持续扩张。往年需要人工逐条梳理、分析的繁杂工作，如今已逐步转化为标准化清晰任务。例如竞品分析工作，已从人工逐条比对迭代为AI自动生成对比矩阵。这意味着，AI可替代的标准化工作持续增多，而仅靠人工可完成的工作，逐步收缩至复杂域与混乱域，笔者认为，这两类场景也是产品判断力、隐性知识高度集中的核心领域。从对过往踩过的项目坑中复盘，笔者认为，产品经理的核心竞争力，不在于熟练掌握标准化方法论（已被AI普及覆盖），而在于长期深耕复杂、混乱的业务场景，积累的隐性模式识别能力。经历过大量跨部门协作、项目危机、方向抉择的从业者，能够精准预判协作风险、把控混乱场景的处理节奏、识别隐性业务隐患。这类嵌入实践经验的认知，难以编码复刻，也是AI难以快速习得的核心能力。然而，值得关注的是，复杂域与混乱域的判断工作，早已超出单纯的项目管理范畴，更贴近企业经营决策：产品方向选择决定企业资源投放，跨部门博弈本质是组织利益分配，混乱场景下的决策直接影响业务与组织发展走向，这些都是企业经营者的核心工作范畴。四、三层判断核心结构：AI时代产品经理的基础能力体系AI接管大部分执行工作后，产品经理的判断工作并未消失，而是完成了体系化重构，形成执行判断、协同判断、元判断三层能力结构，各层级的判断对象、依据与核心价值各有侧重。笔者结合实战复盘认为，这套三层判断结构，是当下外包项目中的产品经理，要吃透的基础能力体系。1、执行判断：AI主导，人工校验该层级以AI输出为核心，产品经理主要承担审批、校验、修正的角色。AI可批量输出多版PRD草稿、用户流程方案、测试用例等标准化成果，产品经理负责快速甄别内容可用性，筛选合理的方案、修正漏洞问题。执行判断的标准相对清晰，主要考量内容结构完整性、逻辑自洽性、格式规范性、场景覆盖度。AI在该层级优势显著，能够高效完成标准化输出，人工判断频次高、单次判断密度较低。典型应用场景：借助AI生成PRD初稿后，产品经理校验功能描述是否完整、异常分支是否覆盖、数据流来源是否清晰、审批流转场景是否闭环等细节问题。2、协同判断：人机共判，人工主导决策该层级是人机协同的核心场景，AI提供数据支撑与方案参考，产品经理结合隐性业务背景完成最终决策。AI依托海量历史数据与标准化模式，可完成需求优先级排序、项目风险评估、多方案对比等基础工作；产品经理则结合AI无法识别的组织关系、资源约束、战略目标、业务干系人诉求，对AI结论进行优化调整。该层级融合了AI的广度数据优势与产品经理的深度业务认知，判断质量直接决定项目推进效果与业务落地价值，判断密度与核心价值均处于中等偏上水平。典型应用场景：AI基于用户提及频率，将某功能需求列为最高优先级，然而，产品经理结合业务实际，发现另一项低提及率需求关联核心客户续约，具备更高商业价值，因此调整需求优先级。AI的数据分析结论具备合理性，而产品经理的调整，是基于数据之外的商业关系与业务价值做出的高阶判断。从笔者自身的实战经历中，就多次遇到过这类数据结论和真实商业价值相悖的情况。3、元判断：人工主导，校验AI决策元判断是AI时代衍生的全新产品能力，核心是判断AI输出结论的合理性与有效性。笔者觉得这一点很容易被从业者忽视：AI输出的内容往往结构完整、逻辑通顺，但可能存在隐性漏洞：遗漏未公开的业务信息、依托过时行业模式、忽略特殊业务约束，且AI无法自主识别自身的认知盲区。这就需要产品经理依托行业经验与业务积累，校验、修正甚至否决AI的输出成果。该层级高度依赖从业者的长期行业沉淀，是隐性知识的核心体现，判断密度高、对业务风险把控至关重要。典型应用场景：AI生成竞品分析报告，仅覆盖有公开资料的竞品，遗漏了部分无公开文档、但具备核心竞争力的行业玩家。资深产品经理凭借行业积累，能够快速发现漏洞，补齐分析盲区，规避决策偏差。上述三层判断体系，构成了AI时代产品经理的基础核心能力：执行判断规避AI标准化输出的细节漏洞，保障工作落地质量；协同判断融合人机优势，优化项目决策合理性；元判断守住业务底线，规避AI认知盲区带来的决策风险。在此基础上，产品能力还可进一步升维至经营判断。笔者认为，前三类判断均围绕项目交付展开，核心是解决“如何落地”的问题；而经营判断围绕商业价值展开，聚焦“是否值得落地”，综合考量方案投入产出比、战略契合度、组织长期价值，是更贴合企业核心需求的高阶能力，也是AI无法覆盖的核心领域。五、竞争力护城河形变：从宽度优势到深度、高度优势行业共识的“判断力是产品经理的护城河”，在AI时代有了全新的内涵，护城河的形态已经发生本质形变。结合笔者多年的行业观察与自身成长经历来看，这种变化感受尤为真切。AI普及之前，产品经理的核心竞争力是“宽度优势”，依托全面的标准化方法论构建壁垒：熟练撰写PRD、绘制原型、完成数据分析、统筹项目流程，标准化技能越全面、执行效率越高，岗位竞争力越强。AI普及之后，所有标准化、可编码、可复刻的宽度能力都被逐步填平，行业竞争不再比拼基础执行能力。笔者觉得，产品经理的竞争力护城河从“宽”变“深”，剩余的核心优势，全部集中在难以编码、AI难以习得的隐性知识与高阶判断力领域。从业者多年积累的场景模式识别能力、风险预判经验、用户与市场人性洞察、混乱场景的秩序构建直觉，在AI时代彻底摆脱了重复性执行工作的掩盖，成为核心差异化竞争力。这不是行业危机，而是产品岗位价值重估的重要契机。护城河的深度，来源于长期积累的隐性知识；而护城河的高度，取决于产品经理的格局与经营者思维，笔者认为，这正是拉开高阶产品人差距的核心关键。经营者思维不局限于岗位身份，核心是视角升级。普通产品从业者以执行者视角思考“如何把事做好”，聚焦项目交付落地；具备老板思维的产品从业者，以经营视角思考“这件事该不该做、落地价值是什么、风险与代价由谁承担”，聚焦业务商业成败与长期发展。两种视角，决定了完全不同的决策高度与岗位价值。从笔者自身的实战经历中得出，经营者思维主要体现在三个维度：第一，价值维度。判断需求落地价值，不局限于用户诉求与技术可行性，核心考量是否能创造真实商业价值，包括增收、降本、构建差异化竞争壁垒等核心目标。AI可校验需求的功能完整性，但是，没办法判断需求的商业价值，这类决策需要依托市场洞察、人性认知与行业竞争判断。第二，资源维度。资源分配不被动响应各方诉求，不依据诉求紧急程度排序，而是以投入产出比、长期价值为核心，将有限资源倾斜到高价值、高成长性的业务方向，主动构建企业长期业务能力，这也是企业经营者的核心工作。第三，风险维度。风险判断不局限于合规、延期等基础问题，更聚焦企业长期利益与品牌声誉。部分需求虽然可以落地、短期有收益，不过，会损害用户信任、透支品牌、破坏行业生态，这类短期有利、长期有害的工作，需要主动规避。这种取舍能力，依托的是商业认知与行业格局。以上三类判断，无法通过单纯的数据推演、逻辑分析得出，本质是价值取舍、人性洞察与经营决策，是AI难以触及的核心领域。能够持续输出这类高质量判断的产品从业者，早已超越传统项目执行者的定位，成为以产品为核心载体的业务经营者。六、经营者格局的养成路径笔者认为，经营者思维与行业格局并非天生具备，也不依托岗位职级赋予，而是长期刻意练习、持续沉淀的结果。从笔者自身成长经历中得出，核心修炼路径包含三方面：第一，升级视角，以经营者思维复盘日常工作。跳出产品岗位的固有视角，日常工作中主动换位思考，以企业老板、业务负责人的视角审视每一项需求、每一次决策，长期坚持就能够逐步完成思维升级，摆脱执行者的思维局限。第二，拓宽认知，积累跨领域知识体系。格局的核心是视野，视野依托多元信息支撑。仅掌握产品专业知识，决策只会局限于产品落地层面；兼顾商业、组织管理、用户人性、行业生态等多领域认知，才能让产品决策贴合经营本质，实现价值升维。第三，扎根实战，在博弈与抉择中锤炼能力。格局无法通过理论学习形成，只能在真实业务场景中打磨。笔者觉得，日常工作中的资源争夺、利益权衡、风险抉择、需求取舍，都是修炼经营思维的核心场景。每一次决策选择，都是格局与判断力的积累过程。七、总结AI时代，产品经理的岗位价值正在经历三轮清晰跃迁：从依托方法论落地的“执行者”，升级为依托专业认知的“判断者”；再进阶为高效协同AI的“半人马合作者”；最终成长为立足业务本质的“经营者”。每一次跃迁，本质都是判断力的持续升维，从基础的执行判断、协同判断、元判断，升级为高阶的经营判断。结合笔者的实战感悟，产品经理的核心竞争力护城河，维护方式已然改变。AI可以替代绝大多数标准化方法论的落地工作，所以，笔者认为，不需要再花大精力去堆砌基础执行能力，核心重心应转向隐性知识的积累、复杂场景判断的练习、跨领域认知的沉淀。其中，经营者思维与行业格局的修炼，是构建长期、差异化、难以被替代竞争力的核心关键。笔者认为，AI没有弱化产品经理的岗位价值，反而提高了岗位能力门槛。新时代的产品从业者，不仅需要甄别、优化AI的输出成果，做好业务落地判断，更需要以经营者格局把控产品方向、权衡业务价值、规避长期风险，以产品能力承载业务的长期发展。本文由@Roxana原创发布于人人都是产品经理。未经作者许可，禁止转载题图来自Unsplash，基于CC0协议

产品经理是做什么的？详解产品经理的5个主要职责
房产经纪人提出“给公共房源加标记”，产品经理却最终做成了小程序消息提醒。从“加标记”到“发提醒”，中间藏着产品经理的核心判断链路：理解问题、分析需求、推进方案、参与验收、复盘迭代。本文通过真实案例，拆解产品经理的五项职责如何环环相扣，帮你建立从问题到结果的完整工作框架。“在电脑端房源列表上，给公共房源加一个醒目的标记。”房产经纪人提出这样一条需求，听起来很简单：调整样式，补一个标签，交给开发实现。但接到需求的产品经理发现，系统明明已经有一个专门查看公共房源的页面。用户为什么还要在另一个列表里找它们？这个问题追下去，最后做出来的功能变了：团队在小程序里增加了房源转为公共房源的消息提醒。这是一个很典型的产品现场。从“加标记”到“发提醒”，中间那段看不见的判断，恰恰是理解产品经理工作的起点。做了多年产品后，我把这份工作看成一条连续的链路：弄清用户的问题，分析需求并取舍，形成方案并推进协作，参与验收上线，再根据结果决定下一步。不同团队会有不同分工，但每一项都需要留下可供下一步使用的结论。一、先弄清问题，再决定做什么第一项职责，是理解用户及其所处的业务。在这个房产系统里，房源可以按归属分为私有和公共，也可以按是否能够交易来分类。经纪人平时查找可交易的房源，因此默认列表中同时显示私有和公共房源；如果只想找公共房源，也可以切换到专门的页面。按这个逻辑，“把公共房源标得更醒目”似乎没有解决一个新的查找问题。关键线索藏在房源归属的变化里。原来，系统有一条规则：经纪人超过规定时间没有跟进，私有房源就会转为公共房源，俗称“跳公盘”。系统已有消息通知，但经纪人经常外出带客户看房，很少留意电脑端的系统消息。等到发现时，自己的房源可能已经转公了。所以，用户真正担心的是：自己的房源发生了归属变化，却没有及时获知。醒目的标签是他能想到的解决办法。这时再比较方案，差别就清楚了。列表加标记，需要经纪人先回到电脑前、打开列表、认出房源；消息提醒则可以通过日常使用的手机告知他变化。这个案例最后把方案落到了小程序的微信消息推送上。产品经理在这一环节要留下的，至少包括使用者、业务规则、问题发生的场景，以及已有办法为什么没有奏效。缺少这些信息，团队只能围绕一个标签的颜色和大小讨论，很难判断这件事是否值得做。第二项职责，是分析需求，确定目标和范围。理解了问题，也不意味着用户提出的每个相关功能都要进入本期版本。还要确定：这次准备改善哪件事，方案覆盖哪些情况，要付出什么实现成本。用户影响、业务价值与开发投入，都应进入取舍依据。沿着房源案例往下看，“让经纪人及时获知归属变化”和“让公共房源更容易被找到”，就是两个不同目标。前者要检查通知是否触达了相应的人；后者要检查查找过程是否顺畅。两种功能可能都有用，却不能用同一套理由证明它们必须同时做。如果本期要解决的是消息遗漏，讨论就应围绕提醒发生的时机、接收对象和相关使用场景展开。至于列表是否需要整体改版，需要另有证据支持，不能顺手扩大范围。这里是在说明如何判断取舍，原案例并未披露团队的完整排期和资源评估。需求分析的交付物因此不能只有一个功能名称。它还要让团队知道：本期解决什么问题，为什么采用这个方向，以及哪些事情暂时不在范围内。二、把判断变成团队能实现的方案第三项职责，是把方案讲清楚，并和团队一起推进实现。另一个需求来自财务人员，来自财务人员：希望电脑端的报销单据详情能够全屏显示。原来的单据在小窗口中打开，窗口可以最大化，底部有打印和取消按钮。追问之后才发现，财务人员遇到的困难有两个：报销审批节点很多，横向排列后，小窗口装不下，需要拖动横向滚动条才能看完整。看完以后，财务还要把单据打印出来归档。团队随后调整了审批节点的展示方式。例如，原先分散排列的部门审批、店长审批，可以按所属的门店层级组织显示，使审批关系更容易辨认。打印流程也增加了预览：先看预览，再确认打印。这个案例的价值，在于方案已经落到了具体操作中：哪部分内容难读，怎样组织显示，打印前多了哪一步。只有“优化体验”四个字，设计和开发无法据此判断该改什么。继续把这类方案交给团队实现，还会出现更细的问题。将节点合并展示，是否仍能看见每个节点的审批状态？展示层级变化，会不会让人误以为审批步骤也被删掉了？预览中的内容与实际打印内容如何对应？这些是沿方案需要进一步确认的规则，不能靠各个岗位自行猜测。产品经理要根据问题选择表达方式：操作顺序可以用流程图说明，页面布局用原型表达，权限、状态和异常处理则写进规则。文档写得多并不自动代表方案清楚；同一个问题在原型、需求文档和会议结论里说法不同，反而容易造成返工。协作也从这里开始。业务方确认方案有没有遗漏工作要求，设计师判断信息怎样呈现，研发评估实现条件，测试检查规则是否足够明确。讨论改变了方案，就需要把结论同步到相关材料；仍未解决的问题，也要明确由谁补充、何时给出判断。具体开几次会、怎样安排评审，要根据团队节奏调整，但“结论有人确认、变化有人同步”这件事不能省。这一项职责最终要交付的，是团队可以据此开展工作的方案，以及实施过程中持续有效的产品判断。三、上线前，把业务路径走完整第四项职责，是参与验收和上线准备，检查实现是否满足约定。上述房产案例记录了问题和处理方案，并未公开完整的验收、上线效果数据。沿着这两个方案，可以进一步看清产品验收应该检查什么。对于房源转公提醒，验证到“系统发出了一条消息”就结束，仍然不够。需要核对消息是否对应那条发生变化的房源、是否发给应当知晓的人，以及接收者能否从内容中理解发生了什么。触发时机和使用条件，要以团队确认的业务规则为准。对于报销单，页面变得紧凑，也只是其中一项变化。还应按财务人员的工作顺序，查看审批关系、辨认节点状态、进入打印预览、确认打印内容。某个按钮能够点击，不等于这条工作路径已经成立。这些检查需要产品、业务和测试共同参与。产品经理负责澄清业务预期、判断实现是否偏离方案；测试对质量进行专业验证；技术发布条件则需要研发、运维等相应负责人判断。发现问题以后，产品经理还要说明它影响哪些用户、是否阻断关键操作，供团队决定修复、延后还是调整上线范围。上线准备中还容易漏掉两件事：使用者是否知道流程变了，产品团队是否有办法看到上线后的表现。例如，打印流程增加预览步骤，使用说明和相关业务沟通就需要与之对应。如果上线后准备检查提醒的使用情况，所需的数据记录也要在开发时考虑，不能等到复盘才发现没有记录。验收、运营沟通、数据记录和反馈渠道，应该在上线前就逐项确认。需求沟通时就想清楚怎样检查效果，后面才不会只剩下“功能已经做完”这一条结论。这也解释了为什么五项职责是一条相连的工作链：上线后要回答的问题，往往需要在需求阶段就留下条件。四、回到最初的问题，判断下一步第五项职责，是观察使用结果、复盘问题，并形成下一轮决定。继续用房源提醒说明：提醒发送成功，只能证明发送环节完成；是否帮助经纪人及时获知归属变化，还需要结合触达、使用和用户反馈来判断。不能直接把发送量当作需求已经解决的证据。报销单也是如此。打印预览的使用次数，能说明有人进入这个环节，却不足以单独证明财务工作更顺畅。还需要回看最初的困难：审批信息是否更容易读懂，打印内容是否符合归档需要，是否出现了新的操作障碍。这些都是应当验证的问题，并非原案例已经公布的改善结果。若要进一步判断“节省了多少时间”，还需要上线前后的可比记录，说明观察对象和任务条件；没有数据，就不能把功能完成写成效率提升。复盘也要分清两条线。一条看交付过程：评审遗漏了什么，需求为何变更，信息有没有同步，哪些依赖影响了上线。另一条看产品结果：实际使用与原先预期有什么差异，用户的问题有没有得到缓解。过程顺利而结果不好，可能需要重新检查问题判断或方案；使用效果有改善，但团队反复返工，则需要修正协作与交付方式。两种情况不能用一份“项目已完成”的记录一笔带过。回到开头，经纪人要一个醒目的标记，产品经理需要先理解他为什么提出这件事。做出提醒以后，还要继续检查提醒是否在他的工作场景里起作用。职责从一个具体问题开始，也应当在这个问题的实际变化中接受检验。本文由@Lucas原创发布于人人都是产品经理。未经作者许可，禁止转载题图来自Unsplash，基于CC0协议

产品经理转型FDE指南
过去一年，”FDE”（ForwardDeployedEngineer，前沿部署工程师）从一个Palantir内部的岗位名称，变成了AI行业最热的招聘关键词之一。OpenAI、Anthropic等大模型公司在招，国内做Agent、做行业大模型的公司也在招。与此同时，大量产品经理开始认真思考一个问题：我是不是该转FDE？这篇文章想先泼一盆冷水，再给一条路。冷水是：FDE不是”会写代码的产品经理”，也不是产品经理的”升级版”，很多PM对这个岗位的想象是错的。路是：如果你真的适合，PM确实是转FDE最有潜力的人群之一，但前提是你愿意放下一些PM最引以为傲的东西。01先搞清楚：FDE到底是干什么的FDE的本质可以用一句话概括：带着公司的产品和技术，扎进客户现场，把客户的业务问题真正解决掉，并把现场的认知带回来改造产品。这里有三个关键词。第一是”扎进现场”，FDE不是远程支持，而是嵌入客户的业务流程，和客户的一线员工坐在一起。第二是”真正解决掉”，FDE的考核不是交付了多少功能，而是客户的业务指标有没有变化，比如客服成本降了多少、审单效率提升了多少。第三是”带回来”，好的FDE是产品团队伸向市场最远的触角，现场发现的共性问题要沉淀回平台。为什么AI时代FDE突然重要了？因为大模型的能力和企业的实际价值之间，隔着一条很宽的沟：企业的数据是脏的，流程是隐性的，知识在老员工脑子里，评判”好不好”的标准没人写下来过。模型再强，没人把它”接”进业务里，就只是一个聊天框。FDE就是填这条沟的人。把FDE和几个容易混淆的角色放在一起看，差别会更清楚：角色核心产出对什么负责是否自己动手构建产品经理需求定义、产品决策、PRD产品在市场上的成功通常不售前/解决方案架构师方案、POC演示签单做演示级别实施/交付顾问按合同完成部署配置按期验收做配置，少量开发FDE在客户环境里跑起来的系统+业务结果客户的业务指标是，且是生产级看完这张表，你会发现FDE最像的其实是”一个人的创业团队”：自己发现问题、自己定义方案、自己写代码、自己对结果负责。02.PM转FDE：优势是真的，错觉也是真的02.PM转FDE：优势是真的，错觉也是真的先说优势。PM转FDE，有三块能力是别的背景很难速成的。一是问题定义能力，客户说”我要一个智能客服”，PM天然会追问”你真正想降低的是什么”；二是业务抽象能力，能从一个客户的具体诉求里看出哪些是个性、哪些是共性；三是跨角色沟通能力，能同时和客户老板、一线员工、自家研发说上话。这三块恰恰是很多纯工程背景FDE的短板。但更值得警惕的是几个错觉。错觉一：我懂业务，技术可以慢慢补。在FDE这个岗位上，技术不是加分项，是入场券。你在客户现场，客户的数据接口报错、召回效果不好、Agent在某个分支上反复出错，没人会等你回总部找研发排期。AIcoding工具确实大幅降低了写代码的门槛，但它能帮你做出demo，很难帮你独立扛住一个生产环境。错觉二：FDE是更高级的PM。恰恰相反，从某种意义上说，FDE是在做”更低层”的事。PM的核心价值之一是”判断该做什么，然后交给别人做”；而FDE的工作方式是”判断该做什么，然后自己做完”。很多PM过去几年最擅长的，是在文档、评审、对齐中推进事情，而这套能力在客户现场的权重会明显下降。错觉三：做FDE是在追风口。如果你转FDE的动机主要是”这个岗位火”，那大概率会很痛苦。FDE的日常是大量不体面的工作：清洗数据、和客户IT扯权限、在凌晨排查一个莫名其妙的线上问题。风口带来的是岗位数量，不会让工作本身变得更轻松。03真正的挑战在哪里1.技术能力的硬门槛一个合格的AI方向FDE，至少需要能独立完成这些事：用Python写业务逻辑和数据处理脚本，用SQL取数和分析，调用和集成各类API，搭建RAG和Agent工作流，设计评估体系（eval）来量化效果，以及把东西部署到客户能用的环境里。其中最容易被PM忽视的是评估。在AI项目里，”做出来”不难，”证明它好、知道它哪里不好、持续让它变好”才难。而评估能力恰恰是PM有机会建立优势的地方，因为它本质上是把业务标准翻译成可测量的指标。2.从”规模化思维”到”做不能规模化的事”PM的职业训练是规模化：一个需求要服务尽可能多的用户，一个功能要尽可能通用。FDE的起点正好相反，它要求你先为一个客户做到极致，哪怕方法看起来很”土”、很定制。这会带来一种持续的心理拉扯：你会本能地觉得”这样做不优雅、不可复用”。但FDE的逻辑是，先在一个客户那里把价值跑通，再从三五个客户的实践里提炼出可复用的部分。跳过第一步直接追求第二步，是PM出身的FDE最常见的失败模式。3.中国B端市场的特殊难度在国内做FDE，还要面对一些海外文章里很少讨论的问题。定制化泥潭是第一个：甲方很容易把FDE当成免费的外包开发，需求无限膨胀，最后项目变成一个不赚钱也沉淀不下任何东西的交付黑洞。数据和合规是第二个：私有化部署、内网环境、数据不出域，很多在公有云上几小时能搞定的事，在客户现场要耗上几周。组织政治是第三个：AI项目往往触动既有岗位和流程，推动它的业务负责人和可能被影响的一线员工，对你的态度完全不同。4.和总部产品团队的张力FDE站在客户现场，产品团队站在平台视角，两边天然会有冲突。你会觉得产品团队不懂一线，产品团队会觉得你总在提定制需求。如果公司没有清晰的”现场需求回流机制”，FDE很容易被边缘化，变成一个高级实施人员。这一点在选择公司时尤其要看清楚。5.岗位概念的鱼龙混杂FDE这个词在国内还很新，很多公司只是把原来的实施、交付、售前岗位换了个名字。如果你满怀期待转过去，发现日常是写标书、做配置、跑验收，那落差会很大。04一个不太讨喜的判断：不是所有PM都该转说得直接一点，以下几类PM转FDE的成功率会更高：对技术有真实的好奇心，业余时间愿意自己折腾代码；有B端、行业或数据产品背景，理解企业流程和数据；享受解决具体问题的成就感，而不是只享受”定义方向”的成就感；能接受高强度出差和驻场，能接受在不确定中工作。而如果你最擅长、最喜欢的是用户洞察、体验设计、增长策略，对写代码有明显的抗拒，那转FDE很可能是用自己的短板去和别人的长板竞争。这时候更好的选择也许是往AI产品经理的方向深挖，而不是硬转。FDE不是PM唯一的出路。真正的危机不在于你是不是FDE，而在于你是否停留在”只会写文档、只会传话”的中间层，这一层在AI时代会被快速压缩。05如果决定要转，应该怎么做第一步：诚实地诊断差距拿一个你熟悉的真实业务场景，给自己两周时间，尝试独立做出一个能被真实用户使用的AI应用原型，从数据准备到上线，不依赖研发同事。做完之后，你会非常清楚自己卡在哪里。这比看十篇”FDE能力模型”的文章都有用。第二步：有针对性地补技术，以”能交付”为标准不需要成为算法专家，但要达到”能独立交付”的水平。建议的学习顺序是：先Python和SQL打基础，再学API调用和数据处理，然后深入RAG、Agent编排和评估体系，最后补齐基本的部署和运维常识。全程充分利用AIcoding工具，但要求自己理解生成的每一段代码，因为在客户现场出问题时，AI未必能替你兜底。第三步：在现有岗位上”预演”FDE最好的转型路径往往不是裸辞重来，而是在现岗位上主动靠近FDE的工作方式。主动申请去客户现场，跟着交付团队跑一个项目，自己负责一个POC，把”需求调研”变成”和客户一起把问题解决掉”。这些经历既能验证你是否真的喜欢这种工作，也会成为你转型时最有说服力的履历。第四步：用作品而不是简历说话准备两到三个端到端的案例，每个案例讲清楚四件事：客户的真实问题是什么，你做了什么判断和取舍，你亲手构建了什么，最终业务指标变化了多少。FDE的面试官最想看到的，是你”把一件模糊的事做成”的完整证据链。第五步：选对公司，识别真假FDE面试时可以重点问几个问题：FDE的考核指标是什么，是按项目验收还是按客户业务结果？现场发现的共性需求，有没有机制回流到产品？FDE团队和产品、研发团队是什么关系？公司的商业模式是否支持FDE做深，还是逼着FDE做快？这几个问题的答案，基本能帮你分辨出这是一个真正的FDE岗位，还是换了名字的实施岗。第六步：调整心态，从”对的方案”转向”跑起来的方案”这是最难也最重要的一步。PM习惯追求逻辑完备、方案优雅，而FDE的世界里，一个在客户那里真实跑起来、带来20%效率提升的粗糙系统，远比一份完美但没落地的方案有价值。学会接受不完美，学会先交付再迭代，是PM转FDE真正的”成人礼”。06叨叨几句FDE的兴起，某种程度上是对产品经理这个职业的一次价值重估。当写代码的成本不断下降，”知道该做什么”和”让它真正在客户那里跑起来”这两种能力的价值会越来越高，而夹在中间、只负责传递信息的角色会越来越尴尬。所以，PM转FDE这件事，真正要回答的问题不是”这个岗位有没有前途”，而是”我愿不愿意从一个定义问题的人，变成一个解决问题的人”。想清楚这一点，路径反而是清楚的。本文由作者@人人都是产品经理，授权发布于平台，未经许可禁止转载。

从入门到精通，一篇文章带你入门产品经理！（2026 年最新版）
很多人学产品从Axure、Figma开始，工具越学越多，面对真问题时却越学越迷茫。因为产品经理的核心不是"画原型"，而是完成一次"从问题发现到结果验证"的闭环：判断哪个问题值得解决、哪种方案更适合当前资源、哪些需求应该延期。2026年的产品经理，从"做功能"转向"对结果负责"，从"追热点"转向"理解真实场景"。很多人第一次了解产品经理，是从“画原型、写PRD、做需求分析”开始的。于是，学习路线通常变成：先学Axure，再学Figma，然后背几套方法论，最后找几道面试题练习，以为这样就可以了。这种方式看起来很努力，却经常让人越学越迷茫。工具学了不少，文章看了很多，真正面对一个问题时，还是不知道该从哪里开始。我做产品这些年，越来越确定一件事：入门不是把工具学会，而是完成一次“从问题发现到结果验证”的产品闭环。你要知道自己在解决什么问题，为什么值得解决，准备如何解决，以及如何判断方案有没有用。工具、文档和方法论，都是为了让这件事更顺利。一、产品经理到底在做什么？产品经理不是“提需求的人”很多新人对产品经理的理解，是业务提出需求，产品经理把需求写成文档，再交给设计和研发。这只是工作中的一小部分，而且往往不是最难的部分。真正的产品工作，通常从一句模糊的话开始：“我们是不是可以加一个AI功能？”这时，产品经理不能马上打开原型工具，而要先问：谁需要这个功能？他在什么场景下遇到了问题？现在是怎么解决的？现有方式的成本是多少？这个问题足够重要吗？新的方案真的比原来的方案更好吗？经过这些判断，模糊的想法才可能变成一个值得投入的产品问题。产品经理真正负责的，是一条完整链路：发现问题→判断价值→设计方案→推动落地→验证结果→继续取舍其中最重要的工作不是画页面，而是做判断。你要判断哪个问题值得解决，哪种方案更适合当前资源，哪些需求应该延期，哪些功能虽然用户喜欢但暂时没有业务价值。不是“怎么做”，而是“做不做”“先做什么”“做到什么程度”。产品经理每天都在平衡几种价值一个产品方案通常同时面对四类约束。第一是用户价值。用户是否真的遇到了问题，产品是否能让任务更容易完成。第二是业务价值。产品能否带来收入、留存、效率提升，或者帮助公司建立新的竞争优势。第三是技术可行性。研发成本、系统限制、数据质量和上线周期是否允许这个方案落地。第四是长期风险。隐私、合规、滥用、错误结果和后续维护成本，都可能决定一个功能能不能真正上线。好的产品经理不是只站在用户一边，也不是只听业务安排，而是在几种价值之间做出清楚的取舍。不同类型的产品经理，工作重点并不一样C端产品经理面对的是大量个人用户，通常关注用户体验、使用频率、转化和留存。B端产品经理面对的是企业客户和内部业务流程，更关心角色权限、流程效率、组织协作和商业回报。数据产品经理需要理解指标体系、数据链路和分析工具，帮助业务获得更可靠的信息。AI产品经理则要额外面对模型能力、数据质量、输出稳定性、使用成本和人工兜底等问题。所以，AI产品经理不是“会使用几个工具的产品经理”。一个聊天窗口不等于AI产品。真正的AI产品通常包含输入、上下文准备、模型调用、结果处理、用户确认和反馈修正等多个环节。这份工作适不适合你？在开始学习之前，可以先问自己三个问题。1）你是否愿意长期处理没有标准答案的问题？产品工作很少有一开始就清晰的任务。你可能只有一封用户投诉、一组模糊数据，或者一句业务方的想法，需要自己把问题拆开。2）你是否能够接受方案被推翻？产品经理提出的方案，可能被用户否定，也可能被研发指出成本过高，还可能因为业务方向变化而被暂停。一个成熟的产品经理不会把方案被修改理解成对个人能力的否定。3）你是否愿意为结果负责，而不只是为文档负责？写完PRD不代表工作结束。功能上线后，用户有没有使用，问题有没有改善，指标有没有变化，这些才是产品工作的最终反馈。如果不是，请关闭本页。如果是，请继续。二、2026年，产品经理的能力模型发生了什么变化？从“做功能”转向“对结果负责”过去，产品经理常常用这些黑话来标榜自己已经入门：竞品分析、需求管理、高保真原型。但这种“工具型产品经理”，早已经被淘汰。现在的产品经理更需要关心的是：你解决了什么问题？为什么选择？具体改变了什么？结果如何验证？如果重新做一次，你会放弃什么？“负责用户调研和原型设计”是一句过程描述。“访谈8名学生后，发现真正的障碍不是信息不足，而是信息无法比较，因此重构了筛选和排序流程，并通过两轮测试验证用户完成任务的时间明显下降”，才更接近产品经理的工作表达。从“会用工具”转向“会与技术协作”AI让很多产品工作变快了：原型可以快速生成，文档可以自动整理，用户反馈可以批量归纳，数据也能得到初步分析。所以，如果是做AI产品经理，至少需要理解这些基本问题（你可以试试看）：大模型适合处理什么类型的任务为什么模型会产生幻觉RAG解决的是什么问题Agent和普通问答有什么差别多模态能力可以改变哪些交互方式如何评估模型输出的质量为什么一次调用会涉及成本、延迟和权限问题不是说产品经理要亲自训练模型，但要求产品能够和研发讨论边界。当研发说“技术上可以做”时，你还需要继续追问：准确率大概如何？失败时怎么办？需要多少数据？响应时间是否可以接受？用户是否能发现错误？上线后如何监控？从“用户体验”转向“用户、技术和商业的连接”过去很多产品体验停留在表面上：页面是否清晰，操作是否顺畅，功能是否方便。今天，这种表面功夫已经不够了。可能因为调用成本过高而无法规模化；可能因为使用频率太低而无法形成商业价值；可能因为反馈时间太长而没人愿意使用。产品经理需要同时看三件事：用户是否愿意使用，技术是否能够稳定实现，业务是否能够持续承担。从“设计答案”转向“设计验证方式”以前做产品方案，往往先讨论页面和功能。真正核心的问题是：我们准备如何知道这个方案是否有效？你设计了一个AI求职助手，不能只展示它生成的结果，还要观察：用户是否更快完成简历修改？是否更容易发现自己的经历短板？是否愿意继续使用？他们是否需要大量手动纠正？模型犯错时，用户能否及时发现？不需要一开始就拥有完美指标，但必须有验证意识。一个小规模、可解释的测试，通常比一份看起来完整但没有用户参与的方案更有价值。从“追热点”转向“理解真实场景”现在的大环境变化很快，几乎每天都有新模型、新工具和新概念，但产品经理不能只追着热点学习。真正值得关注的核心是：新能力能不能解决真实问题，能不能嵌入用户已经存在的工作流程，能不能降低用户的成本？很多Demo看起来很惊艳，用过一次之后却没有继续使用——不是功能没满足用户需求，而是没有进入真实场景。产品经理要做的，不是把所有新能力都塞进产品；而是找到一个具体任务，我们的解决方案是否真的能让任务变得更快、更准，或者更容易完成。三、零基础学习路线——不要按课程顺序学，要按产品闭环学第一阶段：先学会观察问题零基础学习最容易走偏的地方，是一开始就寻找“产品创意”——这是路走歪了。先训练自己观察真实问题。你可以这样记录：有人在求职时需要反复整理岗位信息；有人在课程结束后找不到自己的笔记；小商家每天重复回答相同的问题；团队成员经常因为信息分散而重复沟通。不要急着写解决方案，先把问题说清楚：谁遇到了问题？问题发生在什么场景？用户现在如何解决？现有方式有什么成本？这个问题发生得频繁吗？用户是否愿意为更好的解决方式付出时间或金钱？“我想做一个AI学习助手”还不是产品问题。“准备考试的大学生需要从大量课程资料中找到可复习的重点，但目前只能手动翻找，整理一次需要很长时间”才是更接近产品工作的描述。第二阶段：学会基本的产品表达产品经理需要把模糊的问题表达清楚，让设计、研发、业务和测试能够按照同一个理解工作。入门阶段不需要同时学习十几种工具，先了解一些常用的技术名词、沟通黑话，掌握几种基本表达方式就够了。用户流程图，用来说明用户如何完成任务。信息架构，用来说明内容和功能如何组织。低保真原型，用来说明页面、操作和交互关系。需求文档，用来说明为什么做、做什么、做到什么程度。验收标准，用来说明什么情况下可以认为功能完成。工具学起来很快，真正重要的是能力、沟通和协作。第三阶段：通过拆解产品建立产品思维可以从边界更清晰的产品开始：小程序、小工具之类，学习反复拆解自己正在使用的产品。不建议一开始就分析微信、抖音这类复杂产品。它们的用户、业务和系统都太庞大，新人很容易把文章写成对功能的罗列。拆解时，不要只问“这个页面为什么这样设计”，而要追问：产品服务谁？用户在什么场景下使用？用户原本有什么困难？产品帮助用户完成的核心任务是什么？哪一步最容易中断？产品如何获得收入或持续运营？如果只能改一个地方，应该改什么？拆解的目的，是训练自己同时看到用户、场景、业务和方案。第四阶段：做一个小而完整的个人项目当你完成几次问题观察和产品拆解后，可以开始做自己的项目了。选择一个你能够找到真实用户的问题，例如：帮学生整理求职信息帮学习者处理课程笔记帮小商家回答高频咨询帮团队完成资料整理帮用户把零散信息变成下一步行动项目的重点不是功能多，而是能否完成一次闭环：提出假设→设计最小方案→找真实用户试用→记录反馈→修改方案这一阶段，什么才算真正入门？完成以下几项成果，你就已经走过了产品经理入门最关键的一段：一份问题观察记录，一次产品拆解，一份简化PRD，一套低保真原型，以及一次真实用户测试和迭代记录。这些成果是给你自己看的证据：你是否真的理解了用户问题，是否做过产品判断，是否能够根据反馈修改方案。产品经理的学习没有一个“全部学完”的时刻。真正的入门，是你开始对一个真实问题负责，并且愿意根据结果修改自己的判断。本文由@Yiyan原创发布于人人都是产品经理。未经作者许可，禁止转载题图来自Unsplash，基于CC0协议

深度：产品经理要守住产品边界！为什么会这么难？
钉钉AI项目ONE从300万日活到边缘化，一场典型的边界失守案例。本文深度剖析其兴衰轨迹，揭示产品崩塌并非偶然，而是人性弱点、组织压力、商业焦虑等多重因素叠加的必然结果，为产品经理敲响警钟。钉钉的AI项目《ONE项目》的完整兴衰轨迹，成为互联网行业比较经典的产品边界失守的案例。这归功于钉钉员工的爆料。这就不得不让我们思考，守住产品边界为啥这么难？作为钉钉创始人回归后主推的顶级AI战略项目，ONE立项之初定位极度清晰、克制且精准：打造AI工作信息流，通过智能聚合、优先级筛选，把杂乱的办公消息、待办事项自动梳理，实现从人找事，到事找人的核心体验，核心价值是解决用户信息过载、工作杂乱、效率低下的痛点，单纯聚焦员工减负、办公提效这一单一核心场景。项目初期数据极其亮眼，上线即突破300万日活，用户对智能梳理工作、自动汇总待办的轻量化体验高度认可。但短短数月，这款被寄予钉钉AI转型厚望的标杆产品，快速走向失焦、变形、边缘化，最终从首页核心入口降级为负一屏次要功能，彻底淡出用户视野，后续被全新项目替代，草草落幕。ONE项目的崩盘，并非技术缺陷、竞品冲击或用户需求失效，而是一场典型的渐进式边界彻底失守。为贴合公司AI战略叙事、满足管理层的全场景预期、承接各业务线的堆叠需求，ONE一步步突破初始定位边界：从单一的工作信息智能梳理工具，强行扩容为全域办公Agent中台。团队不断堆叠功能，陆续接入审批、会议、文档、绩效、考勤、工作监控等全链路模块，原本精简的AI卡片推送，从初期日均10-20条精准信息，暴涨为海量全维度动态推送。最致命的是，产品底层立场彻底偏移：原本服务员工减负的工具，逐渐演变为服务管理者监控员工的AI监工系统。它不仅梳理员工工作待办，更自动汇总员工工作漏洞、未完成任务、在线时长、操作轨迹，让员工工作状态彻底透明裸奔。最终出现全员抵触、中层忌惮、用户留存断崖式下跌的局面，完美印证了边界失守的致命危害。ONE项目的陨落，给所有产品经理敲响警钟：产品崩塌从来不是突如其来的重大失误，而是边界一点点松动、定位一步步偏移、价值一层层稀释的必然结果。做产品最容易走的弯路，从来不是不会做功能，而是什么都想做、什么需求都接、什么热点都追。几乎所有做崩的产品、做烂的项目、做疲惫的产品团队，根源高度统一：产品边界彻底失守。赛道越做越泛、功能越堆越满、场景越扩越杂、用户越做越乱。原本聚焦清晰的核心产品，慢慢变成大而全、杂而不精的四不像；原本轻量化的高效迭代，逐渐陷入无休止的需求叠加和资源内耗。机会所有产品经理都知道产品要守边界、做聚焦，但几乎所有人都守不住边界。为什么？表层原因是不会拒绝、不懂取舍；而底层真相，是人性弱点、组织压力、商业焦虑、能力缺陷、行业环境五大维度的系统性合力，不断推着产品突破边界、偏离定位。一、到底什么是产品边界？很多产品经理对边界的理解极其肤浅，单纯认为边界就是“功能做不做”的简单选择题，甚至将边界视为束缚产品创新的枷锁。真正完整的产品边界，可以理解为他是产品定位的衍生概念，是产品顶层定位的落地围栏、是产品价值的护城河、是所有迭代决策的唯一标尺。当我们确定了产品的定位，必然产生一个五行的边界。1、用户边界：明确产品核心服务人群、次要服务人群，清晰划定不服务、不讨好、不妥协的非目标用户。拒绝为小众个性化需求，牺牲大众核心用户体验，杜绝用户圈层泛化、定位模糊。比如钉钉ONE初始核心用户是全体职场员工，核心诉求是减负提效，后期强行适配管理监控需求，突破用户边界，彻底背离核心用户价值。2、场景边界：明确产品深耕的高频、刚需、核心业务场景，主动放弃低频、边缘、伪需求场景。杜绝为了补齐所谓“产品闭环”，盲目拓展无关场景，导致产品精力分散、核心场景深耕不足。ONE项目最初只聚焦工作信息梳理、待办智能汇总单一场景，后期无边界拓展至人员监控、绩效复盘、行为追溯等场景，彻底脱离核心赛道。3、能力边界：清晰界定产品的核心壁垒能力、基础配套能力和绝对不触碰的能力范畴。核心能力持续深耕打磨，配套能力轻量化支撑，跨界能力坚决不碰，拒绝无意义的功能堆砌、热点跟风、技术叠加。ONE原本核心能力是AI信息聚合与优先级筛选，后期强行叠加全域数据统计、行为监控、智能考核等能力，核心能力被彻底稀释。4、商业边界：明确产品的核心商业模式、变现路径、价值主张，不盲目跟风跨界商业化、不透支用户体验换取短期收益、不脱离产品核心价值做变现。稳定的商业边界，是产品长期健康发展的基础。所谓守边界，不是偷懒不做事、保守不创新，而是主动取舍、精准聚焦，把有限的研发、运营、市场资源，100%集中在核心价值上，打造不可替代的产品壁垒。而守住边界之所以难，是因为每一次坚守，都需要对抗人性本能、组织压力、商业焦虑与行业内卷，是典型的逆势而为。二、人性层面：产品经理自身的底层弱点，是边界失守的根源所有外部压力，最终都会通过人性弱点击穿产品边界。绝大多数边界崩盘，始于产品经理自身的认知偏差与心态短板，这是最隐蔽、最核心、最容易被忽视的内因，也是无数项目重蹈ONE覆辙的根源。1、全能错觉：误以为功能越多，产品越强将产品功能数量等同于产品竞争力，功能越多、场景越全、覆盖越广，产品壁垒越高、用户体验越好，这绝对是产品设计最大的误区。在这种思维驱动下，会主动承接各类边缘需求、跟风各类热点功能、补齐各类所谓短板，陷入无边界迭代陷阱。但真实的产品逻辑恰恰相反，产品的壁垒从来不是做得多，而是做得深、做得准。互联网产品的核心竞争力，是单点极致的价值输出，而非面面俱到的功能堆砌。过多的边缘功能，会直接稀释产品核心价值、分散有限的研发资源、提升用户认知与使用成本、放大系统架构复杂度。钉钉ONE项目的迭代全程印证了这一点：团队陷入全能幻觉，试图让一款AI梳理工具，同时兼顾信息汇总、效率提效、人员监控、绩效辅助、行为追溯等多重功能，追求全场景AI办公闭环。最终看似功能无比完善，实则每一个功能都不极致，核心的减负体验彻底消失，冗余功能带来的负面体验无限放大。很多产品做到后期臃肿不堪、体验割裂、BUG频发、维护成本暴增，都是全能幻觉的必然代价。2、讨好型心态：不敢拒绝任何人的需求，害怕冲突与否定产品经理是典型的跨部门枢纽岗位，日常对接老板、业务、运营、市场、用户、客户等多方角色，每天接收海量、杂乱、立场各异的需求。很多产品经理长期陷入讨好型工作模式，核心心态是规避矛盾、追求好评、隐藏自身决策压力。早期初入职场的我就有这样的心态，怕拒绝老板，被定义为执行力差、格局不足、不懂战略；怕拒绝业务，被吐槽不配合业务、不懂落地、阻碍业绩增长；怕拒绝用户，被质疑不重视体验、脱离用户、不懂产品；怕拒绝客户，被诟病不市场化、流失商业机会。最后产品崩了，直接责任人还是我。这种“怕”的心态，导致的结果是无论需求是否贴合产品定位、是否属于产品边界、是否具备投入产出比、是否会破坏核心体验，一律先承接、先落地、先迭代。不敢拒绝的本质，是用产品的长期价值、核心壁垒、用户口碑，换取当下的人际安稳、短期好评与工作省心。短期看，这类产品经理配合度高、落地量大、产出亮眼；但长期看，产品边界全无、定位持续偏移、核心价值被稀释，所有杂乱需求层层堆积，最终彻底拖垮产品竞争力，ONE项目的逐步变形，正是一次次无底线承接需求的结果。3、焦虑型迭代：害怕落后内卷，被迫盲目跟风扩张互联网行业永远处于高速迭代、持续内卷、热点频出的状态，产品经理极易陷入深度迭代焦虑：竞品出新功能就恐慌落后、行业出新热点就急于跟风、同行拓展新场景就焦虑错失机会。这种恐慌心态，会彻底打破产品的克制定力，倒逼边界持续松动。很多产品的边界突破，并非基于用户痛点、产品定位、商业逻辑的理性决策，而是焦虑驱动的被动跟风。为了看起来有创新、有迭代、有战略，为了跟上公司AI、数字化、全场景的战略节奏，不断突破原有边界，盲目叠加热点功能、跨界场景、衍生能力。ONE项目的迭代后期，团队正是陷入了战略焦虑：为了贴合全域AIAgent的行业热点、匹配公司AI转型的宏大叙事，不甘于只做简单的工作梳理工具，强行拓宽产品边界，最终彻底脱离初心。焦虑驱动的迭代，本质是无效迭代；恐慌催生的边界拓展，最终都会变成产品无法甩掉的沉重负担。三、组织层面：公司与团队的压力，倒逼边界持续松动如果说人性弱点是边界失守的内在根源，那组织压力就是击穿边界的最大外部推力。很多成熟的产品经理，明明清晰知道产品边界、明确判断需求不合理、清楚迭代会导致失焦，却不得不妥协让步。核心原因就是，个人产品定力，根本抵不住公司层级的系统性压力。钉钉ONE项目的变形，就是组织倒逼边界失守的典型案例。1、老板的增长执念与战略拔高：无限拓宽产品边界绝大多数企业管理者的底层思维，是增长无上限、业务无边界、机会不能丢。在这种战略视角下，产品聚焦等于格局局限，克制迭代等于保守落后，坚守边界等于错失行业机遇。老板永远希望产品能承载更大的战略价值、覆盖更多场景、服务更多用户、创造更多增量。老板最常下达的指令、提出的需求就是：顺带完善一下、补齐这块短板。在管理者视角，这只是小的功能增补、战略升级；但在产品落地视角，每一次顺带完善，都是一次核心边界的突破，都需要搭建全新的逻辑体系、交互流程、数据模型与维护机制。ONE项目的崩盘，顶层战略拔高是核心诱因：原本轻量化的工具产品，被强行拔高为钉钉AI转型的核心载体、全域办公中台。为了匹配宏大战略，产品不得不无限拓宽边界，从单点工具迭代为复杂系统，最终彻底失控。长期在这种指挥逻辑下，任何产品的边界都会被一点点蚕食，从精准聚焦慢慢变成全面铺摊、杂乱无章。2、业务部门的痛点转嫁：把所有业务问题全部甩给产品业务、运营、市场团队的核心考核KPI是落地短期业绩、解决当下业务难题、完成阶段指标，不会为产品的长期定位、边界稳定、核心价值负责。他们的工作逻辑极度直白：只要我有痛点、业务有卡点、指标有缺口，产品就必须帮我解决。现实工作中，80%的业务临时需求、个性化需求、紧急迭代需求，本质并非产品能力缺失，而是业务流程不规范、运营策略不合理、人员执行能力不足、业务规划不完善导致的人为问题。但业务团队会习惯性规避自身问题，将所有卡点统一包装为产品需求，倒逼产品迭代承接。产品经理如果坚守边界、理性拒绝，就会被业务团队投诉不支持业务落地、不懂业务、缺乏协作精神，成为业务推进的阻碍；只有持续让步、无差别承接非边界需求，才能维持跨部门协作顺畅。这就导致产品边界，长期沦为业务低效运营、流程混乱的兜底工具，持续被动松动。ONE项目后期大量无关功能的堆叠，大多来自各业务线的痛点转嫁需求。3、团队考核的短期产出导向：制度奖励扩张，惩罚克制绝大多数互联网公司对产品经理、产品团队的考核体系，都是极致的短期产出导向。考核核心指标永远是：迭代功能数量、上线模块数量、需求落地率、业务支撑率、项目完成速度。没有任何一家公司会正向考核产品经理：拒绝了多少无效需求、砍掉了多少冗余功能、守住了多少产品边界、精简了多少复杂逻辑、规避了多少迭代风险。考核机制直接决定团队行为：既然多做多加分、少做少得分、不做不得分，扩张迭代有业绩、有产出、有亮点，坚守边界、取舍克制只会无产出、无亮点、甚至被质疑不作为，所有产品团队都会本能选择承接需求、拓宽边界、堆叠功能。制度从根源上奖励扩张、惩罚克制，产品边界失守就成了必然结果。四、商业层面：市场与增长的矛盾，让边界难以坚守产品的终极目标是商业变现与持续增长，而商业增长的天然逻辑，就是突破现有边界、挖掘全新增量、拓展业务版图。这与产品守边界、做聚焦、重克制的底层逻辑天然对立，形成结构性无解矛盾，也是中大型产品边界持续失守的核心商业诱因。1、存量竞争下的增量焦虑，倒逼产品跨界破界国内互联网行业早已彻底进入存量竞争时代，单一赛道、单一场景、单一用户群体的增长天花板极低。当产品核心场景增长见顶、核心用户渗透饱和、核心营收趋于稳定，企业的增长焦虑会瞬间拉满，必然要求产品跳出原有边界，寻找全新增量空间。而企业最愿意选择、成本最低、落地最快的增量方式，就是拓宽产品边界、跨界叠加功能、覆盖新用户、拓展新场景，不愿深耕存量、打磨体验、优化效率，只想快速找新增、做数据、讲故事。这就形成了产品经理最难的两难处境：坚守边界、聚焦深耕等于短期增长停滞、无法交付商业指标；突破边界、盲目扩张等于产品失焦、价值稀释、长期崩盘。2、B端产品的客户定制绑架，摧毁通用产品边界B端、企业级、SaaS产品的边界失守，是行业普遍通病，核心元凶就是大客户定制需求绑架产品通用边界，钉钉全系产品都深陷这一困境。头部付费客户、战略大客户、标杆企业，总会提出大量个性化、非通用、非核心场景、小众行业的定制需求。对于企业而言，大客户意味着高额营收、标杆案例、行业背书，为了留住客户、保住业绩、抢占市场，公司会无条件要求产品团队妥协落地所有定制需求。每一次个性化定制，都是对通用产品边界的一次精准破坏。无数次定制需求层层叠加后，原本标准化、轻量化、逻辑清晰的通用产品，会变成千人千面的拼凑产物，核心逻辑混乱、功能臃肿冗余、系统维护成本暴涨、通用竞争力彻底丢失。钉钉整体的功能臃肿、ONE项目的定位撕裂，都是长期迁就大客户定制、失守通用产品边界的必然结果。3、商业化变现的路径依赖，透支长期产品价值当产品核心商业模式的变现效率放缓、存量变现见顶，团队极易陷入商业化焦虑，进而产生严重的路径依赖：不愿打磨原有商业模式、不愿优化存量变现效率，而是直接放弃边界坚守，盲目叠加各类短期变现功能。原本聚焦用户体验、核心效率、工具价值的产品，被迫叠加广告推送、会员付费、增值服务、跨界营销、数据付费等各类商业化模块，导致产品定位混乱、用户体验断崖下滑、核心价值被彻底弱化。为了短期变现突破边界，最终透支产品长期生命力与用户口碑。五、能力层面：多数产品经理，缺乏守边界的核心能力抛开人性、组织、商业的所有外部因素，很多产品经理守不住边界，本质是核心能力不匹配岗位要求：只会被动承接需求、落地迭代、输出方案，不会主动做价值判断、顶层取舍、干系人博弈、需求论证，没有守住边界的硬实力与软实力。1、没有坚定的顶层定位标尺，边界判断全凭感觉很多产品经理的产品边界是模糊的、弹性的、凭经验的，没有清晰固化的产品定位文档、没有明确的需求取舍标准、没有统一的价值判断体系、没有固化的核心价值边界。面对繁杂需求、多方施压、热点诱惑时，没有客观的判断依据，只能凭主观经验、人情关系、职场压力做决策。没有坚定的定位标尺，就没有坚守边界的底气，别人稍加施压就让步、别人稍加提议就承接，边界自然一退再退、持续崩塌。2、只会承接需求，不会拆解、说服、替代需求初级产品经理的核心短板高度统一：不会拒绝，且不会优雅拒绝。面对不合理、超边界、伪需求，只有两种极端选择：要么生硬硬刚，引发跨部门矛盾、得罪领导与业务；要么全盘承接，彻底失守产品边界。而成熟的边界取舍能力，从来不是简单说“不”，而是一套完整的闭环能力：拆解需求真伪、挖掘需求底层痛点、区分通用与小众场景、测算投入产出比、评估边界影响、提供替代落地方案、理性说服干系人放弃无效诉求。多数产品经理缺乏这套论证与博弈能力，只能被动妥协。3、算不清资源成本与机会成本多做一个功能、多接一个需求，其实是有成本的。研发开发成本、测试校验成本、服务器运维成本、系统架构负担、用户认知成本、体验割裂成本。更核心的是机会成本：团队的人力、时间、资源永远是绝对稀缺的。你投入资源落地一个无关边界的冗余需求，就必然牺牲核心场景的优化、核心BUG的修复、核心体验的升级、核心壁垒的打磨。看不懂机会成本，就永远学不会克制，永远守不住产品边界。六、边界的失守，是温水煮青蛙的过程很多生活中被骗的人，骗子一般不会一上来就放大招，这样你一定会发现不对劲。一般、骗子是先让你付出很小的代价，然后一步一步的获取你的信任，直到不能自拔。同理，绝大多数产品的产品失焦、边界崩塌、定位变形，一般不是某次重大决策失误、某次大规模改版、某次战略跑偏的突发结果。真实的行业真相是：几乎所有边界失守，都是典型的温水煮青蛙，没有剧烈崩塌，只有渐进变形。产品边界的溃败，从来不是一次重大错误导致的断崖式崩盘，而是由无数次微小的妥协、微小的让步、微小的破例、微小的叠加，日积月累形成的不可逆变形。每一次让步都看似无伤大雅，每一次破例都只是“仅此一次”，每一次叠加都只是小功能增补，但长期累积，会彻底颠覆产品原本的定位与价值。回看钉钉ONE项目的完整生命周期，全程没有一次颠覆性错误，却一步步走向消亡：第一次让步：为贴合战略，新增少量AI场景拓展，小幅拓宽能力边界，看似丰富产品能力；第二次让步：为满足业务需求，新增审批、会议卡片推送，场景边界小幅泛化，轻微偏离核心减负场景；第三次让步：为适配管理端诉求，新增工作轨迹汇总、未完成事项统计，用户立场开始偏移；第四次让步：为追赶AI热点，全面升级为Agent中台，彻底放弃轻量化工具定位，产品彻底失焦变形。整个过程没有剧烈冲突、没有重大失误、没有颠覆性改版，只是一次次无伤大雅的破例妥协。但正是这种渐进式的松动，让原本清晰、克制、精准的产品边界，慢慢被蚕食、扭曲、解构、重构，最终从员工减负工具彻底变成组织监控工具，完成致命蜕变。这就是边界失守最可怕的地方：它具备极强的隐蔽性、累积性、不可逆性。单次破例的成本极低，低到产品经理可以轻松说服自己无所谓、不影响；但无数次破例叠加后，产品的底层逻辑、核心价值、用户立场、定位边界会彻底变形，且后期无法修复、无法回退。等到团队发现产品彻底失焦、用户彻底抵触、数据彻底崩盘时，早已积重难返，只能降级、关停、迭代新项目。更值得警惕的是，温水煮青蛙式的边界失守，会形成极强的团队惯性：一旦破例一次，后续的边界约束就会持续失效，需求承接会越来越随意，迭代取舍会越来越宽松，产品会越来越臃肿，最终彻底失去聚焦能力与核心壁垒。产品的衰亡，从来不是猝s，而是慢慢癌变。七、所以，守边界是反人性、反组织、反商业的顶级能力看完以上六层逻辑，我们就能彻底明白：为什么所有人都懂守边界、做聚焦的道理，但极少有人能真正守住产品边界。因为守住产品边界，本质是三重艰难对抗：对抗自己的贪心、焦虑、讨好型人性；对抗公司的增长压力、短期考核、业务倒逼；对抗市场的内卷竞争、增量焦虑、商业化诉求。扩张是顺势而为，克制是逆流而上。做加法、堆功能、扩边界、接需求，是顺势、舒服、无压力、有产出的工作；做减法、砍功能、拒需求、守边界，是逆势、痛苦、抗压、无显性产出的修行。这也是产品能力层级的核心分水岭：初级产品拼迭代速度，中级产品拼方案能力，高级产品拼边界取舍。能守住边界的产品经理，拥有的不是懒惰和保守，而是顶级的战略定力、商业判断力、组织博弈力与产品底层底气，是真正懂产品、懂商业、懂组织的成熟从业者。最后想说，无数产品的兴衰证明真正的产品壁垒，从来不是无限扩张的功能边界，而是长期稳定的价值边界。什么都想做、什么都承接的产品，最终只会平庸内耗、逐步消亡；敢于取舍、懂得克制、坚守边界的产品，终将深耕出专属壁垒、脱颖而出。对于产品经理而言，守住边界、敢于克制、精准取舍、长期坚守，才是贯穿职业生涯的修行。学会拒绝无效需求、砍掉冗余功能、放弃伪增量、坚守核心价值、抵制渐进式边界侵蚀，做到这些，你才是真真的产品掌舵人。本文由@老赵的产品论原创发布于人人都是产品经理。未经作者许可，禁止转载题图来自作者提供

产品经理的三思之道：思危、思退、思变
产品经理的成长，不止于向前冲，更在于深谙进退之道。本文借《大明王朝1566》中吕芳的六字真言，拆解思危、思退、思变如何映射产品工作，从预判风险到取舍迭代，再到破局革新，为产品人提供一套穿越周期的思维框架。最近二刷《大明王朝1566》，名场面之一莫过于吕芳教导冯保的六字真言：思危、思退、思变。这其实也是最通透的职场智慧，剧中的台词，已经说出了精髓：我再教你两句话，你记住！一句是文官们说的‘做官要三思’，什么叫三思？三思就是思危、思退、思变。知道了危险就能躲开危险，这就叫思危；躲到人家都不再注意你的地方，这就叫思退；退了下来就有机会，再慢慢看、慢慢想，自己以前哪儿错了，往后该怎么做，这就叫思变。这看似是古人G场的生存法则，实则是适配所有职场人的顶级成事逻辑，尤其契合产品经理的核心工作。产品经理是产品的第一责任人，手握需求、掌控节奏、决定走向，全程游走在用户需求、商业目标、技术瓶颈、市场竞争的博弈之中。很多产品人越做越疲惫、越做越迷茫，不是能力不足，而是思维偏执：只懂往前冲、求迭代、追热点，不懂预判风险、适时沉淀、灵活革新。真正成熟的产品思维，从来不是一味激进推进，而是深谙三思之道：思危以立身，思退以蓄力，思变以破局。一、思危预判风险，是产品的底层底气何为思危？剧中给出最直白的解读：看清当下的处境，预判潜藏的隐患，在风险爆发前主动规避。很多初级产品经理拿到需求就落地，跟风功能就迭代，只盯着数据增长、功能堆砌、进度交付，却从不审视背后的隐患，这也是很多产品高开低走、半路夭折的核心原因。产品的“危”，从来都不是突发的崩盘，而是日积月累的漏洞。从需求端看，盲目承接业务伪需求，不做用户调研、场景验证，看似快速推进，实则会造出无人使用的冗余功能，增加用户操作成本与团队维护成本；从体验端看，一味追求功能花哨，忽视兼容性、流畅度、隐私安全，微小的体验漏洞，终将积累成用户流失的导火索；从商业端看，只顾短期流量爆发，透支用户信任、破坏商业化平衡，看似数据亮眼，实则透支了产品的长期生命力。产品人的思危思维，本质是底线思维与预判能力。做需求评审时，不只思考“能不能做”，更要追问“该不该做、有什么隐患”；做版本迭代时，不只追求“新增什么功能”，更要预判“上线后会出现什么问题、如何兜底”；做战略规划时，不只紧盯“当下的增长”，更要警惕“市场变化、竞品冲击、政策风险”。思危不是畏手畏脚、消极保守，而是敬畏产品、敬畏市场。懂得居安思危，才能让每一次迭代都稳扎稳打，让产品在复杂的市场环境中，守住基本盘、站稳脚跟。二、思退适时蛰伏，是迭代的高级智慧如果说思危是看清风险的眼力，那思退就是取舍有度的定力。剧中冯保年少张扬、急于出头，险些卷入CH堂纷争万劫不复，正是吕芳让他主动退让、蛰伏沉淀，远离Power漩涡，才得以保全自身、静待转机。这份以退为进的智慧，放在产品工作中，尤为珍贵。产品行业最不缺的是激进的推动者，最缺的是懂暂停、懂取舍的决策者。很多产品陷入恶性循环：功能越做越多、链路越做越复杂、团队越做越疲惫，但用户体验和核心数据毫无提升。根源就在于不懂“思退”。不敢砍掉冗余需求，不愿停下无效迭代，不肯放弃过时策略，一味盲目向前，最终让产品臃肿笨重、失去核心竞争力。产品经理的思退，从来不是躺平摆烂、停滞不前，而是战略性收缩、针对性沉淀。当一个功能上线后数据持续低迷、用户反馈极差，不必执着于优化修补，果断下线、及时止损，是思退；当多条业务线并行、精力分散，无法深耕核心场景，主动收缩边缘业务、聚焦核心用户与核心价值，是思退；当行业风口泛滥、全员跟风追热点，不盲目入局，坚守产品初心、打磨基础体验，是思退。迭代的本质，从来不是持续新增，而是不断取舍。向前推进是能力，适时后退是格局。懂得思退，才能跳出忙碌的执行陷阱，从繁杂的需求中抽离，看清产品的核心问题，卸下无效负重，把精力集中在能创造核心价值的事情上，为后续突破蓄力。三、思变破局革新，是产品的长期生命力思危立身，思退蓄力，最终的落脚点，是思变。剧中的三思逻辑层层递进：看清危险得以避险，主动退让得以蛰伏，而蛰伏沉淀的最终目的，是反思过错、革新自我、等待新机。没有思变，思危只是怯懦，思退只是躺平，唯有三者一起，才能实现破局重生。产品行业唯一不变的，就是永远在变（这句话在任何行业都适用）。市场格局、用户需求、技术能力、行业政策，无时无刻不在迭代更新。很多曾经的爆款产品、标杆功能，之所以快速陨落，不是败给了对手，而是败给了一成不变的固化思维。固守过往的成功经验、依赖陈旧的产品逻辑，终将被市场淘汰。产品经理的思变，是复盘后的革新，是沉淀后的突破。日常工作中，思变是拒绝经验主义。不把过往的成功案例套用到所有新项目，针对不同的用户群体、市场环境，定制适配的产品策略；是跳出固有链路，敢于重构不合理的产品流程，简化冗余操作，打破“习惯式设计”的桎梏；是拥抱新趋势，在AI赋能、场景创新、轻量化体验的行业趋势中，主动探索新的产品形态、新的商业化路径。更重要的是，思变是自我革新。每一次版本迭代后，不只看数据结果，更要复盘问题：哪些决策失误、哪些需求冗余、哪些预判不足。在复盘沉淀中修正思维、优化方法，让自己和产品同步成长。思变不是盲目跟风、随意改动，而是在看清风险、沉淀蓄力之后，精准发力、精准破局。这是产品穿越周期、持续增长的核心密码。写在最后《大明王朝1566》的三思之道，放在产品职场，便是一套完整的成长与产品方法论：思危，是敬畏之心，让产品不翻车、及时察觉产品缺陷和风险；思退，是取舍之智，让产品不臃肿、方自己不内耗；思变，是革新之力，抓住时机、把握新机会。所以，产品经理不要急于求成、不要盲目激进。既能抬头预判风险，也能低头沉淀取舍，更能顺势革新破局。我把我看完这段剧的感悟给我的身边人讲，结果说我看剧就看剧，三句话离不开老本行，居然也能联想到怎么做产品经理。我觉得，这正是《大明王朝1566》的神奇之处，他明明再讲古代宫廷的事情，但是却让你自然而然的联想到职场。如果说这段内容你觉得没什么。那么，到了“改稻为桑”的剧情，你就会发现它其实就是讲的职场。如果把“改稻为桑”看成产品经理负责的一个项目，这种“做不好、但是又推不了，还随时爆雷”的感觉，只有经历过的人会明白。我觉得，这也是产品经理这个岗位的神奇之处，如果你是程序员、是UI设计师、或者是一个机械设计师、一个工厂工人。你的工作就是实现任务或落地需求。你不会觉得在你的工作中需要思危、思退、思变。但是产品经理不一样，我一直认为：产品经理是和生活高度重合、高度互通的一个岗位，做产品感觉不仅是做工作、也是在过生活。也就是说产品经理的思维或者方法论，放到生活中也是适用的，而生活中的一些感悟和一些做事的方式方法，也可以应用到产品经理的工作中。这里我并不是说产品经理的工作和生活不分，我们讨论的是更加抽象层面的东西。本文由@老赵的产品论原创发布于人人都是产品经理。未经作者许可，禁止转载题图来自作者提供

产品的“死生之地”：产品经理做产品定位
钉钉的困境，是产品定位错位的典型案例。本文从刷屏长文《置身钉内》切入，深度剖析产品定位的五大核心内核与落地维度，揭示定位如何决定产品口碑、商业化与长期生命力，为产品经理提供可复用的定位方法论。所有资深产品经理都有一个共识：产品定位是一款互联网产品的地基，更是产品全生命周期所有决策的唯一判断标尺。一款产品最终能走多远、口碑好不好、能不能实现商业闭环、用户是否愿意留存，从来不取决于功能堆得多满。真正决定产品稳不稳的，是从0到1那一刻锚定的产品定位。定位清晰，后续的需求取舍、功能设计、用户运营、商业化变现都会有据可依；定位模糊或错位，所有努力都是无效做功，甚至会南辕北辙，越迭代越偏离用户、越运营越消耗口碑。今年夏天刷屏全网的离职长文《置身钉内》，就用钉钉这款国民级产品的困境，给所有产品人上了最深刻的一堂定位课。一、从《置身钉内》说起今年夏天，一篇7.5万字的《置身钉内》刷屏互联网圈，从产品行业火到全网职场圈。我们跳出大厂加班、职场内卷、团队内耗的表层吐槽，撕开钉钉多年来争议缠身、口碑两极分化的核心根源。现在，热度褪去，但是留下的产品思考依旧值得所有产品经理反复复盘。作为深耕行业多年的产品人，我最有感触的不是大厂的管理乱象，也不是职场人的生存困境，而是文章揭露的致命定位误区：钉钉从诞生之初，就陷入了核心立场的错位，这也是它功能越来越全、市场占有率越来越高，却始终无法赢得用户认可的根本原因。钉钉的表层定位一直无比清晰：中小企业智能办公协作工具，主打高效办公、团队协同、企业管理。凭借免费策略、全场景功能覆盖，它快速垄断国内中小微企业办公市场，成为几乎人人必备的工具软件。但它的深层定位彻底失衡。B端产品天然存在“决策付费用户”和“终端使用用户”的割裂，钉钉在长期迭代中，彻底倾斜于企业老板、管理者的管控需求，把监督、考勤、数据监控、效率压榨作为产品核心价值，完全忽视了基层员工这一高频核心用户的体验与诉求。已读回执、全程在线监控、工作边界无限延伸、绩效数据全景追踪……所有产品设计、算法优先级、功能迭代，都在为管理者服务，让工具成为赛博监工。但是又宣传自己是让员工高效办公的工具。最终形成了极其畸形的产品生态：企业不得不用来提效管理，员工不得不被动忍受，产品有市场、有营收、有体量，却没有口碑、没有用户粘性、没有品牌温度。这就是典型的定位问题。它完美印证了一个真理：产品所有的体验问题、口碑问题、增长瓶颈，归根结底都是定位问题。定位一旦跑偏或者模糊，所有精细化运营、功能迭代、场景优化，都无法挽救产品的底层缺陷。二、什么是互联网产品定位？产品定位不是简单等同于对外宣传的slogan、赛道标签、用户人群划分。从《置身钉内》的复盘案例和行业实战来看，真正的产品定位，是一款产品的顶层战略定义，是明确“为谁、解决什么核心问题、提供什么差异化价值、放弃什么需求、坚守什么立场”的完整体系，是贯穿产品从诞生到迭代的底层纲领。完整的互联网产品定位，至少包含五大核心内核：用户定位：明确核心服务对象。精准区分核心用户、次要用户、边缘用户，确定产品资源的倾斜方向。不追求服务所有人，只聚焦精准目标群体，这是定位的前提。钉钉的误区就是错把付费决策者当核心用户，倒置了高频使用者的优先级。场景定位：锁定核心使用场景。明确产品在什么时间、什么场景、解决用户哪类具体问题，剔除低频、非刚需、与产品核心价值无关的场景，避免功能臃肿、赛道泛化。价值定位：提炼差异化核心价值。回答用户“为什么要用你，不用竞品”的核心问题，找到竞品的短板、自身的优势、用户的核心痛点，打造不可替代的产品价值。竞争定位：确立市场心智坐标。明确自己在行业赛道中的位置，是差异化错位竞争、还是同质化优势竞争，避免盲目跟风，在用户心智中占据专属认知。立场定位：坚守产品底层逻辑。这是定位的灵魂，决定产品是服务用户、赋能用户，还是约束用户、管控用户，所有功能设计、规则制定、算法逻辑都围绕立场统一落地。边界约束：这是最容易被忽视的一条。定位同时要告诉你“不做什么”。美团在早期定位为“本地生活服务电商”，所以坚决不碰实物电商，哪怕流量再大也不碰。这就是边界的力量。简单来说：slogan是定位的结果，而完整的战略取舍，才是定位的本质。定位不是写给外人看的宣传文案，是产品团队内部的行动准则。三、产品定位为什么如此重要？产品定位之所以被称为产品经理的核心必修课，是因为它决定了产品的生存根基、资源效率、发展上限，所有成熟产品的成功、大部分产品的消亡，都能从定位上找到根源。具体可以分为五大核心价值：定位是所有产品决策的核心标尺。产品迭代的核心是取舍，而取舍的唯一标准就是产品定位。面对海量需求、繁杂场景、多样用户，定位清晰的产品，能快速判断“该做什么、不该做什么、优先做什么”。反之，定位模糊就会陷入需求堆砌、盲目迭代、功能臃肿的陷阱，就像钉钉不断叠加全场景管理功能，最终丢失核心协同价值。定位决定产品的用户心智与口碑。互联网赛道同质化严重，用户的选择成本极低。清晰的定位能让用户一秒记住产品的核心价值，形成专属心智认知。微信定位“轻量化人性化社交”、飞书定位“高效团队协同”、企业微信定位“公私域客户运营”，精准的心智占位，是产品长期留存的核心。而定位错位的产品，只会让用户产生抵触心理，丧失情感认同。定位极大提升团队资源利用效率。任何公司的研发、运营、市场资源都是有限的。定位清晰，团队就能集中所有资源深耕核心场景、核心用户、核心价值，精准发力、单点突破；定位模糊，团队会分散精力、遍地开花，看似忙碌高效，实则没有任何核心成果，最终陷入“样样都做、样样不精”的困境。数据显示，定位清晰的产品，营销与研发资源效率可提升25%-40%。定位决定产品的商业化模式。所有可持续的商业化，都建立在精准的定位之上。定位明确，才能精准匹配用户付费意愿、搭建合理的变现体系、避开恶性价格竞争，甚至获得15%-30%的定价溢价能力。钉钉的商业化困境就在于，管控式的定位让用户极度抵触，即便功能齐全，也难以实现高质量的付费转化和用户忠诚。定位决定产品的长期生命力。短期产品靠功能，中期产品靠运营，长期产品靠定位。市场热点、用户需求、行业趋势都会不断变化，但产品的核心定位与底层立场可以长期稳定。无数昙花一现的爆款产品，都是跟风热点、定位摇摆，最终被市场淘汰；而长青产品，无一不是长期坚守清晰定位，持续深耕核心价值。统计显示，定位模糊的新产品失败率高达80%。总体来说，产品定位在产品的很多重大决策中，拥有一票否决权。四、产品定位的落地维度产品经理懂定位的理论，却不会落地，那么定位只停留在文档里，无法落地到产品迭代中。结合实战经验与钉钉的案例，产品定位的落地可拆解为四个可直接复用的核心维度，形成完整闭环：用户维度：精准取舍，锚定核心人群。落地第一步不是找需求，而是做减法。明确核心刚需用户、次要付费用户、边缘非目标用户，坚定向核心用户倾斜资源。B端产品尤其要平衡付费决策方与终端使用方，不能单方面讨好管理者、牺牲使用者体验，避免钉钉式的用户对立困境。场景维度：聚焦核心，砍掉无效场景。梳理用户全流程使用场景，筛选出高频、刚需、高价值的核心场景，作为产品的主攻方向；对于低频、伪刚需、偏离核心价值的场景，坚决放弃。杜绝“大而全”的产品思维，坚持“小而精”的聚焦逻辑，守住产品能力边界。价值维度：差异化落地，构建核心壁垒。对标竞品，梳理自身差异化优势，把核心价值落地到具体功能、体验、服务中。别人做全场景管控，你就深耕高效协同；别人做通用社交，你就聚焦私密轻量化沟通。让差异化价值看得见、摸得着，真正解决用户痛点，形成产品核心壁垒。执行维度：全链路统一，贯穿迭代始终。定位不是静态文档，是动态执行准则。产品的功能设计、交互体验、算法逻辑、规则体系、运营策略、商业化设计，必须全部贴合定位，做到全链路统一。杜绝“宣传一套、落地一套”的割裂情况，让定位渗透产品的每一个细节。五、产品定位思维不止于互联网产品产品经理岗位最核心的价值，从来不是会画原型、会写需求文档、会跟进迭代，而是拥有一套可泛化的顶层思维。产品定位思维，不仅适用于互联网产品打造，更是一套通用的人生与职场底层逻辑，可以复用在所有赛道、所有场景。做运营需要定位。账号定位清晰，才能精准吸引目标粉丝、输出垂直内容、实现高效变现；定位模糊、内容杂乱，最终只会粉丝零散、变现困难。做自媒体需要定位。明确自己的赛道、受众、核心价值，是干货输出、情绪价值、还是经验分享，专一深耕才能建立个人IP，形成差异化竞争力。求职简历需要定位。个人定位清晰，明确自己的核心优势、适配岗位、核心能力，才能精准匹配岗位需求，让面试官快速记住你，从众多求职者中脱颖而出。个人成长更需要定位。明确自己的职业赛道、核心优势、发展方向，懂得取舍无效努力、聚焦核心提升，才能避免内耗，实现长期成长。本质上来说，定位的核心逻辑永远不变：明确自我价值、找准目标受众、建立差异化优势、懂得取舍聚焦。掌握了产品定位思维，就掌握了万物归一的底层成事逻辑。写在最后重读《置身钉内》，我们读懂的不仅是一款产品的好坏，更是所有产品人必须坚守的底层准则：产品的所有问题，几乎都始于定位，终于定位。产品经理沉迷于细节、功能优化、运营技巧，却忽略了顶层定位的重要性。细节只能优化体验，定位才能决定成败。清晰的产品定位，是产品对抗市场内卷、规避同质化竞争、实现长期发展的唯一底气。对于产品人而言，定位不是一句空洞的口号，是一次次需求的取舍、一次次迭代的坚守、一次次价值的沉淀。做好产品，先定好定位；无论是做产品，还是做自己，精准定位、懂得取舍、坚守价值，都是终身受益的底层能力。本文由@老赵的产品论原创发布于人人都是产品经理。未经作者许可，禁止转载题图来自Unsplash，基于CC0协议

从城乡规划到 AI 产品经理：我重新理解了“规划”这件事
从城乡规划到AI产品经理，看似跨界，实则底层思维相通。本文作者以亲身经历，剖析规划师与产品经理在问题诊断、多目标决策和不确定性应对上的共通之处，并探讨AI时代产品设计从功能到智能系统的转变，为转型者提供独特视角。当我真正开始学习AI产品之后，我才发现，自己并没有离开规划，只是换了一个需要被规划的对象。几年前，如果有人告诉我，一个学习城乡规划的人，毕业之后会把职业方向转向AI产品经理，我大概会觉得这是一条很奇怪的路径。在传统认知里，城乡规划和人工智能似乎属于两个完全不同的世界。一个研究城市、土地、人口、产业、交通、公共服务和空间关系；一个研究模型、数据、算法、产品、交互和智能体。一个面对的是规划图、规划文本和城市发展方案，另一个面对的是Prompt、Agent、模型能力、工作流和产品指标。但真正开始从规划转向AI产品之后，我反而越来越觉得，这并不是一次彻底的跨界，而是一次“规划对象发生变化”之后的能力迁移。过去，我规划的是城市；现在，我开始规划的是产品、用户、流程和人与AI的协作关系。过去，我需要回答一个城市未来应该建设成什么样；现在，我需要回答一个AI产品应该解决什么问题、为谁解决、如何解决，以及怎样让它真正进入业务和真实世界。表面上看，这是两个完全不同的职业；但拆解到底层逻辑，它们其实都在做同一件事情：在复杂、不确定、资源有限的条件下，通过系统分析理解问题，定义目标，组织资源，设计解决方案，并让一个更好的系统逐渐形成。这也是我从城乡规划走向AI产品之后，最大的一个认知变化。一、我为什么从城乡规划转向AI产品经理？作为一个城乡规划专业的学生，我最初学习的是“空间”。城市总体规划、详细规划、城市设计、乡村规划、城市更新、交通规划、公共服务设施布局……这些知识共同构成了我最初对于“规划”的理解。规划真正有意思的地方，并不是画出一张漂亮的图，而是面对一个复杂系统，判断它现在的问题是什么，以及未来应该往哪里走。比如研究一个城市，我们不能只问“这里缺什么”，还要研究人口结构、产业结构、交通网络、公共服务、土地利用、财政条件以及未来的发展动力。老城区为什么衰退？居民为什么不愿意回来？产业为什么没有形成集聚？一个公共空间为什么建出来却没有人使用？这些问题表面上彼此独立，实际上往往存在复杂的因果关系。因此，规划真正训练我的，并不是某一种软件，也不只是某一种图纸表达能力，而是一种系统性解决问题的能力。而当我开始学习AI产品时，我逐渐发现，产品经理面对的其实也是一个复杂系统。用户希望解决什么问题？为什么会产生这个问题？现有方案为什么不好？AI为什么适合介入？技术能不能实现？成本能不能接受？不同用户之间是否存在冲突？产品未来应该往哪里走？这些问题听起来很像互联网产品，但如果把它们和规划放在一起比较，我发现它们拥有非常相似的问题意识。所以后来我开始重新理解自己的职业转型：我并不是从“规划”跳到了“产品”，而是从空间系统的规划，转向了数字系统和智能系统的规划。二、规划师和产品经理，最相似的其实不是方法，而是思维方式很多人认为规划师转产品最大的优势是“会做PPT、会画图、会写方案”。我以前也有过类似的误解。但真正工作和学习之后，我认为规划专业能够迁移到产品领域的核心能力，其实不是软件和表现，而是下面三种底层思维。1.从问题出发，而不是从方案出发这是规划训练对我影响最大的一件事情。一个优秀的规划师，不会拿到项目以后马上开始画图。首先需要做的是调查、诊断和判断：这个地方真正的问题是什么？居民的需求是什么？现状为什么会变成这样？哪些问题是根本问题，哪些只是表象？这个逻辑放到AI产品里同样成立。很多初学者接触AI后，很容易直接进入“解决方案思维”：我要做一个AI助手、我要做一个Agent、我要接一个大模型、我要做一个AI工作流。但这些都是技术或产品方案，并不是需求本身。真正应该问的是：谁遇到了什么问题？这个问题为什么值得解决？现有方法为什么不够好？AI为什么适合解决？如果不用AI，原来的方法是什么？AI到底创造了什么新增价值？这其实就是非常典型的规划逻辑：先诊断，再规划。从这个角度看，城市体检和AI产品诊断也存在明显的相似性。住房和城乡建设领域近年来不断强调通过城市体检识别群众反映强烈的难点、堵点、痛点，再将体检结果用于城市更新，形成“发现问题—解决问题—巩固提升”的工作机制。如果把这个思路迁移到AI产品上，它同样可以形成一套完整流程：产品体检→问题诊断→AI介入→产品迭代→持续评估。所以我后来越来越觉得，产品经理本质上并不是“做功能的人”，而是发现问题并设计系统解决问题的人。2.多目标决策城乡规划还有一个很有意思的地方，就是它几乎从来没有所谓的“标准答案”。政府希望提高治理效率，居民希望生活品质提升，企业希望降低成本，开发主体希望项目能够盈利，生态部门希望保护环境，不同目标天然存在冲突。规划师真正做的事情，是在多个目标之间不断权衡，在现实约束中寻找一个相对合理的解。产品经理其实也一样。用户希望功能越来越多，研发希望需求越来越少，老板希望项目尽快上线，设计师希望体验更加完善，算法团队希望得到更多数据，安全团队又希望把风险控制在更低水平。最终产品经理面对的也不是一个绝对正确的答案，而是一个优先级问题：什么现在做，什么以后做，什么不应该做。规划中有“刚性管控”和“弹性引导”，产品中也有核心能力和探索能力；规划中有近期目标和远期目标，产品中也有Roadmap；规划中有总体规划、专项规划和详细规划，产品同样存在战略层、产品层、功能层和执行层。所以从这个角度看，我越来越愿意把产品经理理解成一种新的“系统规划师”。只不过过去规划师配置的是土地、空间、人口和公共资源，而产品经理更多配置的是用户需求、数据、技术、流程和组织资源。3.都是在不确定性中做决策这一点也是我进入AI之后才真正意识到的。传统城乡规划的变化速度虽然也在加快，但它通常存在相对稳定的空间、制度和建设周期。城市的发展往往按年甚至十年来衡量。AI完全不同。模型能力几个月就可能发生巨大变化；今天需要自己设计的复杂工作流，明天可能已经成为模型原生能力；今天一个产品的核心能力，几个月以后可能就被更强大的模型直接替代。这意味着，传统规划中的长期确定性，在AI产品中必须被重新理解。AI产品经理不仅是在规划产品本身，还需要规划产品面对技术变化时的适应能力。这也是我从规划转AI后最大的思维变化之一。三、真正进入AI时代以后，我发现“产品”本身正在发生变化我刚开始学习AI的时候，也曾经把AI理解成一种工具。Excel是工具，CAD是工具，PS是工具，AI也只是另一种工具。但现在再看，我越来越觉得这种理解已经不够了。AI正在从“功能”逐渐变成“参与者”。尤其是Agent出现以后，这种变化非常明显。OpenAI近年的相关研究把Agent描述为能够围绕目标进行多步骤任务执行、调用工具并持续完成工作的智能系统，并已经展示了这种工作方式从编程领域向法律、招聘等知识工作扩展的趋势。Anthropic同样认为Agent正在从简单问答逐步走向跨工具、多步骤、长流程任务执行。这意味着产品经理过去设计的可能是：页面→功能→流程。但未来越来越可能是：目标→Agent→工具→数据→权限→执行→反馈→评估。产品经理面对的对象开始变化了。过去我们设计的是“用户怎么使用产品”，未来越来越多时候，我们需要设计的是**“AI怎么完成任务，以及AI与用户怎么共同完成任务”**。这也是为什么我认为，AI产品经理和传统产品经理最大的区别，不是多学几个AI工具，而是产品的基本设计单位发生了变化。四、从“做产品”到“设计智能系统”传统互联网产品的确定性比较强。用户点击按钮，系统执行规则；输入数据，程序返回结果；一个页面对应一组确定的功能。而AI产品具有明显的概率性。同一个问题，不同时间得到的答案可能不完全相同；同一个Agent在不同上下文中也可能采取不同的行动；模型的能力边界、上下文长度、工具调用和外部环境都会影响最终结果。所以AI产品经理不能只关注“功能有没有”，而要开始关注另外一件事情：这个智能系统的成功率到底是多少？比如，一个AI招聘助手如果能够生成一份漂亮的职位描述，并不代表它是一个好产品。真正需要关注的是，它能不能准确理解招聘需求？能不能完成筛选？错误率是多少？什么情况下应该交给人判断？出现异常时能不能被及时发现？Anthropic最近对Agent评估的讨论也特别强调了这一点：Agent不是简单的单轮问答，它涉及检索、工具调用、多步骤任务等复杂过程，因此评价方式也需要从单轮输出质量转向更加完整的端到端任务评估。这意味着，AI产品经理需要逐渐学会一种新的产品语言：任务成功率、置信度、失败类型、人工介入率、工具调用成功率、成本、延迟，以及最终业务结果。这其实让我再次想到了规划。规划方案从来不是“画出来就结束”，而需要通过实施、监测和评估不断调整。AI产品也是一样。模型输出是方案，Evaluation是规划评估；Agent执行是规划实施；用户反馈则是城市体检式的持续反馈。这两套逻辑，其实比我最初想象的更加接近。五、如果把AI放回城市，规划又会发生什么变化？这是我从城乡规划专业转向AI产品之后，最感兴趣的问题。过去，我们谈智慧城市，更多讨论的是数字化。传感器、摄像头、城市数据平台、数字孪生、城市管理系统……这些技术把现实城市转化成数据，把数据汇聚到平台，再通过可视化帮助管理者理解城市。但AI进一步进入之后，城市可能开始发生另外一种变化：从“数字化城市”走向“智能化城市”。过去的逻辑大致是：现实世界→数据→平台未来越来越可能变成：现实世界→数据→模型→智能判断→行动→反馈→再学习这意味着城市系统不再只是被记录、被分析，而开始具备一定程度的理解、预测和行动能力。例如过去发现一个社区存在停车难问题，规划团队可能需要进行交通调查、停车调查、居民访谈，再通过分析形成方案。未来的城市AI系统可能持续分析人口、车辆、道路拥堵、停车需求、商业活动、公共交通和居民反馈，再识别潜在问题，生成不同解决方案，并对方案进行模拟比较，最后由人类决策者进行判断。这个变化真正重要的地方在于：规划师的工作会从“生产方案”逐渐转向“定义问题、建立规则、设计评价体系和做出价值判断”。而这其实越来越接近AI产品经理。六、为什么我特别看好AI×城市更新？在我看来，城市更新可能是AI与城乡规划结合得最自然的场景之一。因为城市更新本身就是一个数据密集、利益关系复杂、问题高度异质化的系统工程。一个老旧社区背后可能同时存在居民诉求、产权关系、基础设施、交通组织、公共空间、商业活力、历史保护、财政能力和土地价值等多重变量。过去，规划团队需要投入大量人力进行资料收集、现状调查、政策整理、居民意见归纳和方案比选。未来，AI很有可能首先进入这些环节。它可以帮助规划团队快速整理大量政策文件、历史规划和项目资料，也可以对居民诉求进行分类，对空间数据进行初步分析，对不同更新方案进行指标比选。当数字孪生、空间数据和生成式AI进一步结合之后，它甚至可能参与到方案模拟与辅助决策。这并不意味着“AI替代规划师”。恰恰相反。AI越能够完成信息整理和方案生成，规划师越需要把精力放在公共利益、价值判断、空间关系、社会协调和最终决策上。所以我现在越来越认为：AI真正改变的不是规划师要不要存在，而是规划师把时间花在什么地方。过去大量时间用于“理解信息”，未来可能有更多时间用于“判断信息”。过去大量时间用于“生成方案”，未来可能有更多时间用于“选择方案”。这其实是一种职业价值的上移。七、数字乡村可能也是AI下一阶段的重要场景如果说城市更新是AI与复杂城市系统的结合，那么数字乡村可能是AI降低专业能力门槛的一个重要场景。过去讲数字乡村，更多强调网络基础设施、智慧农业、电商、数字治理和公共服务等内容。近年来相关政策也持续强调数字技术与乡村产业、治理、公共服务以及城乡融合的结合。但AI进一步进入之后，我觉得一个非常值得关注的变化是：AI可能开始把过去昂贵而稀缺的专业能力，逐渐变成普通人可以获得的能力。比如，一个小型乡村未必有专门的品牌策划团队，但可以使用AI辅助农产品品牌设计；未必有成熟的文旅运营团队，可以用AI分析游客画像和设计旅游线路；未必有专业招商团队，也可以借助AI完成产业研究、项目包装和招商材料准备。这其实是一种很重要的变化。过去的数字化主要解决“连接问题”，而AI开始进一步解决“能力问题”。它不仅让乡村接入数字世界，还可能把部分专业能力下沉到乡村。从这个角度看，AI并不只是生产工具，也有可能逐渐成为一种新的公共服务能力。八、所以，规划专业转AI产品，究竟应该学什么？这是我在转型过程中反复思考的问题。刚开始学AI时，我也很容易陷入“工具焦虑”：今天学习Prompt，明天研究Agent，后天换一个模型，再去体验一个新的AI产品。问题在于，工具永远学不完。真正能够长期沉淀的，是自己的能力结构。现在回头看，我认为规划专业的人转向AI产品，至少需要补齐五个层次的能力。首先是AI基础认知。需要理解大语言模型、Embedding、RAG、Agent、多模态、Context、ToolCalling、Memory、Evaluation等基本概念。不是为了成为算法工程师，而是为了知道模型能够做什么、不能做什么，以及什么情况下应该采用什么方案。第二是产品基本功。包括需求分析、用户研究、产品设计、信息架构、流程设计、原型、PRD、指标体系以及项目协作。这部分传统产品经理的方法依然有效，AI并没有让产品基本功失效。第三是AI原生产品能力。这是传统产品经理与AI产品经理真正拉开差距的地方。你需要理解Prompt、RAG、AgentWorkflow、ToolCalling、Memory、Evaluation、Human-in-the-loop、权限、安全以及成本控制。最重要的是知道，AI产品为什么能够工作，以及为什么有时会失控。第四是领域能力。这一层恰恰可能是规划专业人的优势所在。AI人才很多，但真正理解城市更新的人不一定多；规划师很多，但真正能够把城市更新问题转化为AI产品的人同样少。未来真正有价值的竞争力，很可能来自二者的交叉。最后是系统设计能力。未来的AI产品不会只是一个聊天框，而可能是由用户、Agent、模型、工具、数据、知识库、权限、工作流和业务系统共同构成的复杂系统。从这个角度看，规划专业训练出来的系统思维，反而可能成为AI产品经理的重要基础。九、我现在越来越觉得，规划师真正需要改变的不是专业，而是时间尺度传统城乡规划最典型的思维是目标导向和长期建设。五年做什么，十年做什么，空间怎么布局，人口如何变化，设施配置多少，土地如何利用。这种思维在稳定环境中非常重要。但AI时代最大的特点之一，是变化速度正在显著提高。因此，我认为AI时代的规划不能只强调“长期目标”，还应该更加重视“动态调整”。换句话说，我们不仅需要回答“未来十年应该建设什么”，还需要回答：如果未来发生变化，我们有没有能力及时调整？这其实也是Agent很有意思的地方。Agent并不是一开始就知道全部答案，而是会根据目标不断观察、判断、行动、获取反馈，再重新规划。从这个角度看，未来的规划可能逐渐从一次性规划走向动态规划。我们不只是预测未来，更重要的是建立一个能够持续感知未来变化并不断修正自己的系统。这可能是AI对传统规划思维最大的启发之一。十、我重新理解了“规划”这两个字过去我认为，规划就是规划空间。后来我觉得，规划应该是规划资源。再后来，我认为规划真正规划的是系统。而进入AI时代以后，我开始意识到：规划可能还需要进一步走向“规划智能”。城市未来不只是物理空间，它还是数据空间、数字空间、服务系统和智能决策系统。当AI真正深入城市以后，我们甚至需要开始讨论：一个城市应该把多少决策交给AI？什么事情必须由人决定？AI应该拥有多大的权限？AI的决策如何被监督？数据如何被治理？智能资源如何公平地服务不同地区、不同人群？这些其实都是“规划问题”，只不过规划对象已经从传统的土地和空间，扩展到了数据、算法、Agent与智能系统。国务院2025年发布的“人工智能+”行动提出推动人工智能与经济社会各领域深度融合，并提出到2027年人工智能与重点领域广泛深度融合、智能终端和智能体应用普及率超过70%，到2030年超过90%的目标。这意味着，AI已经不只是科技行业内部的问题。它正在成为经济、城市、产业、教育、医疗、治理以及公共服务共同面对的问题。而一旦AI开始进入这些复杂系统，“谁来规划AI怎么进入系统”，就会成为一个越来越重要的问题。十一、所以现在回头看，我并没有离开城乡规划这是我最近对自己职业转型最大的一个重新认识。我曾经觉得，转向AI产品意味着我要把过去的专业知识放下，重新开始。现在我反而越来越觉得，这可能是一个错误的理解。我过去研究人口，现在研究用户；过去研究产业，现在研究业务场景；过去研究公共设施，现在研究AI服务能力；过去做规划目标，现在做产品目标；过去做近期和远期建设安排，现在做产品Roadmap；过去考虑规划实施，现在考虑产品落地。以前我画的是城市道路和空间结构，现在我设计的是用户流程和智能工作流。于是我突然发现：我其实一直都在做规划，只是规划对象发生了变化。从空间规划走向系统规划，再从系统规划走向智能系统规划，这可能正是我这次职业转型真正的意义。十二、最后，我对“AI时代规划”的一个判断我越来越认为，人工智能真正改变的，不只是某一个行业，而是人类组织工作的方式。过去，一个复杂任务往往意味着需要一个团队，由不同专业的人共同完成。未来，一个人可能调度多个Agent去完成其中大量的信息搜集、数据分析、内容生成、软件操作和流程执行。过去，一个规划团队可能需要大量时间进行资料整理、现状分析和方案生成；未来，其中越来越多环节都可能由AI协助完成。但这并不意味着人的价值会越来越低。恰恰相反，当执行成本不断降低以后，真正稀缺的东西可能会变成：方向、判断、价值、责任和审美。AI可以生成十个规划方案，但谁决定什么是好方案？AI可以分析一百万条居民意见，但谁来判断什么才是公共利益？AI可以模拟不同的城市更新策略，但谁承担最终决策责任？AI可以自主完成一个复杂任务，但谁决定它应该被允许做什么？这些问题可能才是AI时代真正值得关注的问题。所以，从城乡规划转向AI产品经理，对我来说最终并不是从“规划”走向“不规划”。而是让我重新理解：规划的终点从来不是一张图、一份方案，也不是一个功能。规划真正解决的问题，是面对一个复杂系统和一个充满不确定性的未来，我们想让它变成什么样，以及应该怎样让它逐渐变成那个样子。过去，这个系统叫城市。后来，它叫产品。而未来，它可能叫：“人+AI+城市”。也许有一天，我们真正需要讨论的已经不再只是“城市应该如何规划”，而是：当AI开始参与城市运行之后，我们应该如何规划人与AI共同生活、共同工作、共同创造的世界？对于一个从城乡规划专业出发、又走向AI产品的人来说，这可能就是我现在最想寻找的答案。因为到了AI时代，我越来越相信：未来最有价值的规划，不只是规划空间，更是规划智能；不只是规划城市，更是规划人与智能系统共同构成的未来。本文由@木林森f原创发布于人人都是产品经理。未经作者许可，禁止转载题图来自Unsplash，基于CC0协议

产品经理要学会“见人下菜碟”
产品经理常陷入“尊重所有用户”的误区，却忽略了资源有限下的取舍。真正的成熟，是学会按业务逻辑而非人情厚薄，对用户进行权重分层。本文深入B端与C端场景，剖析决策权、付费权等关键维度，教你如何在冲突中做出明智判断，避免沦为工具人。“见人下菜碟”这句话，平时语境好像是个贬义词。因为一般情况下它表达的意思都是：看人下菜、逢高踩低、谁有权谁就多照顾一点，谁没分量谁就敷衍一点。带着很强的道德瑕疵，听起来就不是什么好话。但是！恕我直言，在产品语境里，你就是得学会某种意义上的“见人下菜碟”。当然，我说的不是职场厚黑学，不是曲意逢迎，也不是谁官大就听谁的。而是你要非常清楚地知道，面对不同角色，不能用同一套标准理解需求，不能用同一种力度分配资源，更不能拿“我们尊重每个用户的声音”这种正确废话，来掩盖自己不会做判断。产品经理最容易沦为工具人，不是不会画原型，而是不再追问真实需求。而真实需求，很多时候不是“谁说了什么”，而是“谁的诉求会真正影响业务成败”。一、先把这句话从道德语境里拽出来很多产品团队最喜欢说的一句话是，“所有用户都很重要”。这句话不能说错，但如果你真按字面执行，项目大概率会做废。因为产品工作从来不是在真空里做公平题，而是在有限资源里做取舍题。你只有这么多人、这么点预算、这么点工时、甚至还要被卡排期。研发不可能无限加人，测试不可能无限扩容，老板的耐心和客户的窗口期也都有限。你每多做一个需求，背后都是别的需求被延后、别的风险被放大、别的机会被放弃。所以产品经理真正面对的问题，从来不是“要不要一视同仁”，而是：当不同用户的诉求冲突时，你到底先满足谁。这时候再说“大家都很重要”，就像别人问你想吃什么的时候你说“我都行”。听起来没错，但对做决定没有任何帮助。假装一视同仁，往往不是尊重用户，而是不敢负责。因为一旦你承认用户有权重差异，你就必须进一步回答几个很难的问题：谁是关键角色？谁掌握决策权？谁影响付费和续费？谁决定项目能不能真正落地？谁如果不满意，会直接卡住主流程？这才是产品经理该做的判断。不是按人情厚薄分高低，而是按业务逻辑分轻重。二、产品经理真正要分的，不是人情，而是用户权重很多人一听“分层”，就下意识把它理解成对人区别对待。也没毛病，但不是那种意义上的“区别对待”。不是“这个人我喜不喜欢”“这个人好不好说话”“这个人是不是领导嫡系”，而是这个角色在业务流程里到底处于什么位置。我通常会把用户权重大致看成几类因素的交叉：决策权：谁能拍板付费权：谁决定买不买、续不续业务价值：谁直接影响核心指标场景关键度：谁卡着主流程落地影响：谁决定系统最终能不能被用起来这几个维度，不一定每次都整齐划一。现实世界也不是MECE切完就彻底干净了。有的人既是决策者，也是使用者；有的人不付费，却掌握推广权限；有的人平时没什么存在感，但一旦反对，项目就推不动。所以产品经理真正需要的，不是套模板式的“用户分层入门”，而是建立一种权重意识。你要能把会议上那句很常见的话再深入一层拆开：“用户都这么说。”问题是，哪个用户？是拍板方、付费方、使用方，还是被流程波及的人？很多评审会之所以越开越乱，就是因为大家把不同层级的声音混成了一个“用户共识”，然后再拿这个共识来压方案。表面上是在听用户的，实际上已经被偷换概念了。这也是为什么我一直对“尊重每个声音就等于懂用户”这类话保持警惕。尊重可以是态度，但判断必须是能力。三、B端产品里，角色冲突才是常态这个问题在B端系统里尤其明显。因为B端从来不是只有一个“用户”。同一个系统里，至少会同时站着几拨人，而且他们的诉求天然就不一样。领导层关心什么？关心汇报效果、风险可控、对上能交代、对外有展示面。很多时候，他未必天天用系统，但他会在关键节点看报表、看数据、看项目是否可控。他要的是“我能看见、能管理、能拿去汇报”。业务主管关心什么？关心流程能不能推进、团队效率有没有提升、问题能不能尽快闭环。他站在中间，一头要接领导目标，一头要接一线执行。他要的是“别给我制造新的管理成本”。一线执行者关心什么？说白了，就是少填字段、少报错、少返工、别来回切页面、别今天这么填明天又改规则。对他们来说，系统不是战略工具，而是日常劳动现场。直白点说，少干活，多摸鱼。这三类人，都是用户。但他们不可能天然一致。领导可能希望字段更全、流程更严、痕迹更完整，因为这样方便管理和汇报；一线却只会觉得录入成本越来越高。业务主管可能希望系统强约束，减少团队跑偏；执行者却会觉得灵活性被锁死，出了特殊情况反而更难处理。你如果不分层，就会陷入一种很典型的假勤奋：收集了很多反馈，开了很多会，也记了很多问题，最后做的全是边边角角的小优化，真正影响上线成败的主流程问题反而没解决。这不是因为你不努力，而是因为你没有先判断谁的诉求更靠近业务主航道。所以我比较推荐大家用用户故事地图。用户故事地图这个方法，本质上就在提醒一件事：先看用户完成核心任务的主路径，再看每一步里谁的痛点最关键、哪个环节最不能掉链子。不是所有痛点都要同时解决，而是先保住主流程。B端产品尤其如此。不是“大家都不满意”最可怕。最可怕的是，拍板的人觉得没法汇报，主管觉得推不动，一线觉得更麻烦，最后系统挂在那儿，谁都不愿意真用。四、真正难的，不是知道要分层，而是在冲突里做取舍说到这里，很多人都会点头：明白了，要做用户分层。但真正难的地方，其实从这一步才开始。难的不是知道要分层，而是当冲突真的摆在你面前时，你敢不敢承认：有些需求明知不普适，也必须插队。这是很多产品经理最别扭、也最不愿意公开承认的现实。比如老板临时转来一个重点客户需求。团队一看就知道，这个需求不够通用，甚至会让系统变复杂；研发会吐槽，测试会皱眉，产品自己也明白它不是标准化最优解。但它还是得优先做。为什么？因为对方握着签约、续费、标杆示范，甚至组织背书价值，不夸张地说，团队的业绩都在他手上。你可以不喜欢这个现实，但你不能假装它不存在。这时候如果还有人坚持说“所有需求来源都该按同样标准评估”，那只能说，你还没认清职场。产品不是考试题，产品是资源配置。资源配置就意味着，你要把有限产能投到影响更大的地方。这个“更大”，可能是更大规模的主流用户，也可能是更关键的一笔合同，更可能是决定项目能否顺利推进的那个组织节点。这当然有代价。一旦你为了重点客户插队，团队就会承受棘轮效应带来的后续压力：客户会形成预期，销售会觉得“以后也可以这样争取”，内部排期纪律被打松一次，下一次就更难守住。所以问题不在于“要不要插队”，而在于你能不能说清楚：这次为什么值得插队它换来的业务收益是什么对通用能力建设造成了什么损耗这是不是一次性策略，还是会沉淀成产品能力后续如何控制扩散真正成熟的产品经理，不是从不妥协的人，而是每一次妥协都知道自己在换取什么。五、C端也一样：重度发声用户，不等于主流用户很多人以为，只有B端才需要这种权重判断。其实C端也一样。只是B端的角色差异摆在台面上，C端的误判更隐蔽。最典型的，就是把重度发声用户当成主流用户。社区里最活跃的人、评论区最能写的人、私信最密集的人、愿意参加访谈的人，确实更容易被团队看见。你和他们聊久了，会产生一种错觉：他们代表了用户。但很多时候，他们代表的只是“高参与度用户”，不是“高占比用户”，更不是“高价值主流用户”。这两者差别非常大。重度用户往往诉求更深、更细、更专业，也更容易提出一连串延展需求。你如果只围着他们转，产品很容易越做越重、越做越复杂，看起来功能越来越完整，结果整体留存和转化并没有明显改善。因为大多数人根本没走到那一步。他们真正卡住的，可能是注册第一步、首单转化、关键路径的信任建立，或者某个最基础的使用门槛。你却在给少数深度用户做高级玩法。这就是典型的“谁声音大听谁”。听起来像用户导向，本质上是样本偏差。研究出身的人对这个会更敏感一点。因为你一旦做过访谈、抽样、归类，就会知道：可见，不等于重要；能说，不等于代表。产品团队如果没有这个意识，就会把“用户反馈很多”误当成“需求优先级很高”。这两件事，不是一回事。六、分层之后，产品经理回应不同角色，不是态度不同，而是动作不同说到底，用户分层也不是川剧变脸，而是为了让你的动作更准确。不是对领导更热情、对一线更敷衍；不是对大客户秒回、对普通用户已读不回。那就真成了厚黑学。真正该不同的，是你的工作动作。对决策者，你要给的是结论、风险、取舍和汇报口径。他们不需要听你把每个细节从头讲完，他们需要的是金字塔原理式的信息：先说结论，这件事值不值得做；再说依据，影响什么目标；最后说风险，代价和边界在哪里。你如果给领导塞一堆一线碎反馈，看起来很充分，实际上是在增加沟通噪音，领导直接打断，重点反而容易被忽略。对业务主管，你要给的是方案、节奏和协同路径。因为他们最关心的是：这件事怎么推进、要谁配合、什么时候上线、上线后团队要怎么改动作。他们需要的是可执行性，不是概念正确。对一线执行者，你要给的是可用性、学习成本和异常处理。别动不动就教育用户“这是为了规范流程”。你得知道，一线不是不懂管理价值，而是他们先承受了最直接的使用成本。字段为什么非填不可？报错能不能说人话？异常场景有没有退路？如果这些问题你不解决，再高明的设计理念都落不了地。对重点客户，你要给的是预期管理和边界确认。能做什么，什么时候做，哪些是特例，哪些不会进入标准版本，都要讲清楚。否则今天插一次队，明天就会有人默认这个口子一直开着。很多团队最后不是被需求压垮的，而是被自己没说清的边界压垮的。对普通用户或低权重需求，也不是简单拒绝。而是放回统一的判断框架里：业务价值多大，影响范围多广，成本多高，和当前阶段目标是否一致。排后需要说明原因，不能做就明确关闭，能观察就进入待验证池。差异化回应，核心不是“见人说人话，见鬼说鬼话”，而是“按角色给动作”。这才是专业。七、产品经理最怕的，不是得罪人，而是不会取舍很多产品经理之所以累，不是事情真的多到做不完，而是心里始终想维持一种虚假的公平。谁的需求都想接，哪方都不想得罪，任何人的话都想表示理解。最后的结果往往是，自己成了所有矛盾的缓冲层，项目却没有抓住重点。靠谱的人之所以总被消耗，不是因为他们做得不够好，而是因为他们不懂得拒绝。但在产品工作里，拒绝本身没有问题。拒绝得没有依据，才是问题。你可以优先处理领导关心的报表，因为它影响项目能否继续拿到支持；你也可以优先处理一线主流程里的高频卡点，因为它影响系统是否真的被用起来；你还可以让重点客户需求插队，因为它关乎签约和续费。前提是，这些优先级都能被解释。能被业务价值解释，能被组织目标解释，能被用户影响解释，也能被落地成本解释。一旦解释不清，就不是用户分层，而是拍脑袋。一旦只剩“谁级别高听谁的”，那也不是产品判断，而是办公室政治。“见人下菜碟”这句话，在产品工作里真正该学的，从来不是圆滑。而是清醒。清醒地知道，用户不是一个抽象整体，而是一组位置不同、权重不同、目标不同，甚至彼此冲突的角色。清醒地知道，所谓用户导向，不是谁声音大听谁，也不是所有需求都一股脑地接。而是你要判断：谁影响业务成败，谁决定系统能不能被买、被推、被用、被留。产品经理的成熟，很多时候就体现在这里。不是你听了多少声音。而是你终于知道，哪些声音必须先听，哪些声音要继续验证，哪些声音可以暂时放下。说到底，真正负责的产品经理，从来不是对所有人都一样。而是对结果负责。作者：简谙公众号：简谙本文由@简谙原创发布于人人都是产品经理。未经作者许可，禁止转载题图来自Unsplash，基于CC0协议