序言

为什么叫《见山》#

我刚入行的时候，对产品经理这份工作的理解很直接：用户有需求，业务有目标，老板有方向，产品经理把这些东西听明白、想清楚、写成方案、推动上线。那时候的成就感也很具体，一个页面上线了，一个流程跑通了，一个功能从需求池里划掉了，好像就意味着问题被解决了一次。

那个阶段没有什么不好。一个产品经理如果没有经历过相信功能、相信流程、相信执行的阶段，很容易把产品做成一堆漂亮但落不了地的判断。很多基本功都是在那段时间里长出来的：怎么把混乱的想法拆成页面，怎么把模糊的目标写进需求文档，怎么和设计、研发、运营一起把事情推到线上。那时候的山，就是眼前这座山。需求就是需求，功能就是功能，交付就是交付。

但做得久了以后，事情会慢慢变得不一样。你会发现，用户说出口的需求，未必是他真正需要的东西；数据发生异常的位置，未必就是问题产生的位置；一个过去帮你打过胜仗的方法，换了场景以后可能变成负担；一个看起来很完整的系统，未必真的让业务变好；一个所有人都觉得“应该做”的方向，也可能只是组织焦虑找到了一种功能形态。更尴尬的是，产品经理越资深，越容易被自己的专业能力困住。你会画更完整的方案，会写更有说服力的文档，会用数据讲出更顺的故事，也会在评审会上更快给出答案。但很多错误，恰恰不是因为能力不够，而是因为太快进入了自己擅长的那套动作。你以为自己在解决问题，其实只是把一个还没定义清楚的问题，做成了一个看起来很专业的功能。

这时候，山开始不像山了。你开始怀疑需求，怀疑数据，怀疑方法论，也怀疑自己过去那些成功经验。你不再那么容易被“竞品都做了”说服，也不再轻易相信“用户呼声很高”就等于“产品应该做”。你会在排期前多问一句：这件事到底值不值得做？你会在方案会上多问一句：我们是不是已经默认了一个答案？你也会在复盘时多问一句：这个功能上线以后，到底改变了什么？这不是变得消极，而是产品经理真正开始长出判断的阶段。只是这个阶段并不好过。组织通常更容易看见产出，而不是判断。上线一个功能，周报里很容易写；砍掉一个不该做的方向，却很难被当成成绩。你花两周时间把一个需求挡在版本外，可能没有人觉得你做了什么；你花两个月把它做上线，哪怕结果一般，至少看起来像是完成了一件事。

所以产品经理越往后走，越会遇到一个很现实的问题：你明明比过去更懂产品了，却反而更难用“做了什么”证明自己的价值。 因为真正重要的工作，很多时候发生在功能被写进 PRD 之前，发生在会议里那句“先别急”之后，发生在你把一个看似合理的需求重新翻译成问题的那一刻。 我写这本书，就是想把这些不太容易被看见的判断现场写下来。

这本书写给谁#

这本书不是写给刚入行的产品新人看的。我不会系统讲怎么画原型、怎么写 PRD、怎么做用户画像、怎么搭需求池。这些东西重要，但不是这本书要解决的问题。读到这里的人，大概率已经会做这些事，甚至做得不错。我更想写给那些已经做过几年产品、开始有点不安的人。

你可能已经能独立负责一个模块，也可能已经带过团队；你知道怎么推进项目，知道怎么和研发、设计、运营、业务沟通，也知道增长、转化、留存、复购这些词在不同会议里意味着什么。但你可能也正在发现，过去让你显得专业的能力，正在把你带进某种惯性里：越会做功能，越容易用功能回应一切；越熟悉方法论，越容易用方法论替代现场判断；越有经验，越容易把过去的答案套到今天的问题上；越承担团队责任，越难说出那句“这件事现在不值得做”。

这本书想讨论的，不是产品经理如何变得更忙、更全能、更会交付，而是当你已经具备基本执行能力之后，如何建立一套更稳定的判断方式。这个判断方式不是让你永远正确，也不是让你站在会议室里显得比别人更清醒。它只是在真实工作里帮你多问几层：这个需求是谁的？它解决的到底是什么问题？用户现在付出的代价是什么？数据能证明什么，又不能证明什么？技术承诺背后藏着什么成本？组织如果选择这条路，需要停掉什么、投入什么、承担什么？ 很多时候，产品经理真正的价值不是给出一个更漂亮的答案，而是让团队别太早相信第一个答案。

这本书会怎么展开#

我不想把《见山》写成一本产品经理知识大全。产品这件事当然有很多能力维度：需求、用户、体验、数据、技术、架构、增长、商业、AI、项目、团队、职业发展……如果只是把这些词逐个讲一遍，很容易写成一本厚厚的工具书，看起来完整，读完却不知道下一次评审会该多问哪一句。 我更在意的是，这些能力在真实判断里如何发生。

这本书前面会先处理一个底层问题：产品经理为什么会被“做功能”困住。很多人以为资深之后自然会更清醒，但我的经验恰好相反，越资深，错误往往越贵，也越隐蔽。经验、数据、方法论、组织评价体系，都会在某些时刻变成判断的滤镜。只有先承认这一点，后面谈产品观、需求观、用户观和认知融合，才不是在讲概念，而是在校准我们看问题的方式。

当认知问题说清楚之后，书会进入更具体的工作现场。一个产品经理不能只停在“我知道要判断”，他还要知道怎么判断：怎么在方案已经很顺的时候暂停下来重新定义问题，怎么判断一个设计是不是真的降低了用户任务成本，怎么让数据成为证据而不是装饰，怎么听懂技术同学说“这个很重”背后的真实代价，怎么把自己的判断整理成组织能选择的材料，又怎么让一次选择进入路线图、优先级和持续资源配置。

再往后，问题会变得更复杂。产品进入复杂系统之后，很多代价不再出现在前台页面上，而是藏在架构、权限、库存、履约、风控、对账和组织协同里。增长也不会只是热闹的数据，商业也不是产品做完之后再想的变现方式。一个增长活动能不能算得过账，一个市场机会到底属不属于你，一个产品上线之后有没有真正完成价值交付，这些问题都要求产品经理把视角从功能往外拉开。AI 也是一样，它会让很多执行动作变便宜，但不会替我们承担判断。越是工具强大，越要问清楚：我们到底在用它解决什么问题，错了以后谁负责。

最后，书会回到团队和人。因为产品判断从来不只是个人能力。你自己想清楚，不等于团队能想清楚；你能做判断，不等于组织愿意为这个判断付代价。产品负责人真正重要的产出，不只是自己做出几个正确决策，而是让团队慢慢形成共同的判断语言。到了职业后半场，产品经理也迟早要面对这个问题：当体力、执行、熟练度不再是最稀缺的东西，你到底靠什么继续创造价值？

这些内容看起来很大，但我不想把它们写虚。每一章我都会尽量回到真实项目里：当时发生了什么，我为什么那样判断，哪里想错了，代价是什么，后来又怎么修正。有些案例跑出了结果，有些案例只是让我意识到自己原来想得太简单。它们不一定都漂亮，但 我相信，产品经理真正能沉淀下来的，不是被包装得很完整的成功故事，而是那些可以被复盘、被提炼、被团队复用的判断现场。

我不会假装自己总是对的#

写这本书之前，我也犹豫过。因为一旦你开始写方法论，就很容易把自己写成一个事后永远清醒的人，好像每一次都提前看到了问题，每一次都做出了正确选择。真实情况当然不是这样。我做错过很多判断。也做过一些当时看起来很专业、后来证明价值不大的功能；推进过一些过于完整、但没有真正打中问题的方案；也在组织压力下妥协过，在数据好看的时候自我说服过，在经验顺手的时候忽略过新场景的不一样。很多东西不是一开始就想明白的，是在项目失败、功能被下掉、团队复盘、用户不买账之后，才慢慢被迫想明白。

所以这本书不会把判断力写成一种神奇能力。判断力不是保证你永远正确，而是让你更早发现自己可能错了；不是让你在会议室里压过别人，而是让你把事实、代价、选择和验证摆到桌面上；不是让你永远说“不”，而是让你知道什么时候应该停，什么时候应该做小一点，什么时候必须承担一个不舒服但更诚实的选择。

我越来越觉得，产品经理真正难的地方，不是会不会做，而是能不能在所有人都准备开工的时候，忍住多问几句。 这个动作会让会议慢一点，让排期复杂一点，也可能让一些人短暂不舒服。更麻烦的是，你问完以后也不一定对。但产品经理这份工作的重量，恰恰就在这里： 我们不是站在真理那边的人，我们只是在有限信息里，尽量让团队少一点自我欺骗，少一点无效投入，少一点把局部正确当成整体正确。

从这里开始#

如果你现在仍然相信，只要把需求做得更多、更快、更完整，产品就一定会变好，那这本书可能会让你有点不舒服。因为它会不断追问：这个需求为什么存在？这个功能解决了谁的什么问题？这组数据到底证明了什么？这个方案把代价转移给了谁？这个方向如果错了，能不能体面退回来？

但如果你已经开始隐约感觉到，产品经理不能只靠交付证明自己；如果你已经在某些项目里意识到，真正重要的问题常常发生在开工之前；如果你已经开始带团队，发现“让大家做得更快”不如“让大家先判断得更准”重要，那么这本书就是写给你的。

我不敢说这里有答案。更准确地说，这里有一些我走过的路、犯过的错、后来想明白的事，以及到今天也还没有完全想明白、但值得继续追问的问题。接下来，我们仍然要面对需求、功能、数据、增长、技术、系统、商业、AI、团队和职业这些具体的山。只是我希望，读完这本书之后，你看它们的方式会有一点变化： 你知道山不只是山，也知道山终究还是山。产品经理最终要负责的，不是把世界解释得更复杂，而是在复杂之后，仍然能回到那个最朴素的问题：

这件事，值不值得做？