灵性产品/我的三年产品路

前排提醒: 一篇很长的文章，大概4.5万字，建议收藏阅读

前言

从毕业到现在，成为PM已有三年，在移动广告公司，作为商业产品经理，从最初的产品功能设计，到后来逐步负责一条产品线，具备了一定的业务能力，这三年来的成长，极速且痛苦，不能说成功或者失败，本来成功的经验也难以复制，而失败的经验值得思考，因此我会更多讲一些考虑事情的思路和失败的教训，至少能够在面对已知的情况时，知道哪些坑已经踩过了，面对未知的情况时，知道该怎么去思考，以什么样的思路想事情更合理，而不是实操。
近年来，互联网泡沫越吹越大，行业确实在欣欣向荣，但是随之而来的是，产品经理这个岗位，出现了扭曲和变异，这样的变化本身并没有好坏，毕竟，企业都是根据发展需要进行不同角色定位。只是，大多数人仍然在神化产品岗位时，像BAT这些大公司里的不少产品岗位，已经从产品核心owner的位置，变成了像别的岗位一样，具备专业技能，跟着大部队干事儿就完了，而创业类小公司的产品岗位，又对产品经理能力要求极为严格，招产品像是在招CEO。这种尴尬的两极分化的局面，导致不少人不知该如何选择，大公司有面子，但进去只能从一颗螺丝钉做起，纸面招聘要求还很高，小公司能学到更多东西但对能力要求高，说不定进去还得打杂，啥事儿都得管，风险还高。。。我并不能帮你决定该选哪条路，但不管选哪条路，“想事情的方法”这件事都极为重要，尤其是在大公司内不太能获取的经验和能力成长。我处在一个稳定业务面临挑战&期望探索形成新的业务/产品/商业模式的公司，虽然也才三年，不过，从60分做到80分，从0做到1，稳定业务产品，创新业务产品，都有负责过，一路摸爬滚打，自觉这些经验和方法沉淀还是可以看一看的。
另外，笔者从事的是商业产品经理，与用户产品经理在工作内容和能力要求上，都有不小的差异，本文更多也是从商业产品角度来讲。其实毕业时还是期待做用户产品的，毕竟离用户很近，觉得通过自己的设计能够直接影响到用户会比较有成就感，后来也是阴差阳错从事商业产品经理，意外地发现，这条路距离诗和远方更近，而且也更有挑战更有趣。至于商业产品经理和用户产品经理的详细区别，后续也会讲到。如果你内心喜欢有挑战的事情，且有勇气不断突破自己的舒适区，还意淫自己以后成为CEO位置的人物，带领一帮人飞黄腾达，走上人生巅峰，相信从商业产品经理作为起步，是一个不错的选择，本文或许也能给到你一些帮助。

为什么选择做产品？

从岗位性质来说，我认为商业产品经理，或者说，像商业产品经理/具备商业产品经理思维的角色，是世界上最有趣最富有挑战的事情。它的核心是，通过合理的设计（对人的设计、对事情的设计、对资源的设计、对工具的设计），基于一个目标，把一件高价值的事情做成，并且能够不断扩大其价值。相比于Product Manager ，我更喜欢将这个岗位定位为Architect，建造师，缔造者。喜欢创造和探索，喜欢通过设计来解决问题，用老方法解决新问题或者用新方法解决老问题。
我相信，还是有不少人期望将自己的想法实现，而不是实现别人的想法，或者明明发现了一个需要马上解决的重要问题，而自己并非身在其中，只能在一旁干着急。如果是这样，那产品经理这个岗位，是让你有机会“搞事情”，而且有机会和一帮人把事情搞大的最好选择。之前曾经做过UI/UE类的工作，负责某个移动APP一小部分的界面设计，最痛苦的事情并不是改稿，而是自己在体验APP的过程中发现了不少与界面和交互设计无关的问题，想要搞事情，想要推进解决，但限于角色定位，也只能提提建议，而无法协调资源去解决，会觉得非常难受。当然这并不是说做好自己本职工作不多管闲事，就是有问题的，看个人性格和想法，角色分工本就是希望在本专业发挥最大价值，只是如果从性格上来说，就是喜欢“搞事情”、“捅娄子”、“专业杠精”，那还是做产品更痛快。
从能力成长来说，产品经理岗位本身的要求，能够锻炼和成长的能力方向，相对于其他岗位更为全面，设计/运营/项目管理/商务等能力基本都会在工作过程中得到成长。在公司内，起步阶段其实就已经相当于是在进行小型的内部创业，因此在工作过程中会很快遇到产品、运营、项目管理、商务等各方面的问题和挑战，也能够在解决问题的过程中快速构建多栈能力。
从做事思路来说，作为商业产品经理，在结果导向之下，通过逻辑分析和推理，输出符合中长期目标并且现阶段投入产出比最高的方案，明确实现的路径、资源需求、阶段性关键目标、迭代优化方案，知道该在什么时候什么情况下找什么人解决什么问题，并作为先锋带领团队向长期目标突进，这整个过程，本来就是搞事情的最优思路，即便不做商业产品，也非常适用，甚至可以针对性简化后，适用于生活中各种事情的处理。
总之，产品牛逼，商业产品牛逼！我身为商业产品经理感到非常自豪！

本文内容对你有什么帮助？

本文内容实际上是在说方法论。
百科词条如是说，方法论，就是关于人们认识世界、改造世界的方法的理论。方法论是一种以解决问题为目标的理论体系或系统，通常涉及对问题阶段、任务、工具、方法技巧的论述。方法论会对一系列具体的方法进行分析研究、系统总结并最终提出较为一般性的原则。
本文希望基于笔者的经验和工作过程中的思考总结，梳理“通过商业产品思维搞事情”的方法和技巧。如果你是一个PM，那可听听同行的想法和思路，求同存异，取长补短，借此形成自己的方法论。如果你不是一个PM，也可快速了解产品思维，并将其运用到广义的“产品”工作中，比如开一个店，比如做一个剁手的决定，比如出一个旅行规划。把方法论应用在生活中，总感觉有点丧心病狂走火入魔，但合理（不是上纲上线的杠精）的运用，确实能够在某些情况下，做决定更高效，少了很多纠结，也能更快辨别做哪些事是有用的，而不是一段时间之后发现原来这事纯属浪费生命。
我一直觉得，产品经理应该积累能力，而不是积累经验，而经验的增长和能力的增长也并无关系。一个做过很多产品，具备丰富产品经验的PM，可能也并不是一个好的PM，而在做事之前有完整的思考，知道该如何正确地做事，如何做正确的事，并且能将思考结果运用在做事上，做好一件事，做好一个产品，我觉得这是一个好的PM。希望大家获取的，不是经验，而是思路。
我在文章中举的例子，也会有不少与互联网行业无关，一方面希望大家能在生活中代入这样的思考，另一方面也想证明，这套思路不只是在产品经理工作中适用，而是可以在生活中落地的。

关于本文的结构

哈，要上纲上线的话，这也算产品逻辑思维的体现了。在写这篇长文之前，把文章当作是一个产品，就像做一个产品设计一样，我首先用mindmap梳理了全文结构，明确了每个版块和要点划分。这样的好处就像这样，我在一开始能够用清晰的123点，向你简单快速地说明全文想要表达的核心思想和叙述结构。全文结构如下：

• 思维（产品思维是什么样的思维，产品经理该如何思考）
  • 结果导向
  • 逻辑思维
  • 数据驱动
  • 价值判断
  • 灵性
• 技能（产品需要具备的专业、管理、决策能力）
  • 需求分析
  • 方案验证
  • 产品设计
  • 数据分析
  • 产品运营
  • 决策
  • 项目管理
  • 关于业务
  • 关于AI
• 习惯（什么样的风格/习惯对产品经理工作是有益的）
  • 探索
  • 学习
  • 迭代
• 理念（比较务虚，原则/世界观性质的观点）
  • 思考优先
  • 学院派与野路子
  • 主动介入
  • 竭尽求援
  • 万物皆产品
  • 能力构建
  • 舒适区突破
  • 平等沟通
  • 正循环
  • 装逼

（注意，就算是第二部分偏专业技能方面的描述，也是在讲，该如何去思考这些事情，非实操）

一些建议和说明

• 建议不要将此文章内容照搬作为思考和工作准则
• 建议在观看文章内容同时配合做思维训练，如代入工作问题和想法上的疑惑等
• 建议对文章内容结合读者本人思考和经验进行改造升级，形成自己的方法论
• 由于个人岗位和行业局限，以及资历局限，文章观点可能在某些情况下并不适用，且后续可更新

关于思维

如果你面试过产品岗位，或者了解过产品岗位需求，或者已在产品部门工作，那你可能会发现，相比于其他专业性较强的职能部门，产品岗位的同学，可能来自各种各样奇怪的专业，并且很大程度上，目前的工作也和在学校所学的专业毫无关系。
你可能还会发现，面试的时候，面试官会问你，怎么看这件事，怎么去想这件事，你会怎么做，实际工作的时候，产品总是在写写画画，去梳理，去归纳，去分析，去总结，去推演，而不是去执行。
没错，至少我认为，产品经理最重要的，不是他目前具备的能力和已经获得的经验，而是他认识/解释/改变世界的方法和思路，因为这些思考方式能够折射出，这个人面临具体问题（所有问题，更多是用户/客户问题，而非专业和技能问题）时，会如何处理。而产品经理最核心的工作即是，解决问题。
所以，具备产品思维，对于产品经理来说，是先于其他任何能力的。这也是我想说的，灵性。这个词听起来有点玄学，但确实是我想到用来描述产品经理思维特征的最合适的词汇了。我将灵性解释为，在面对需要解决的问题时，能从横向（多角度）纵向（多节点）系统化分析，并找到能够在现阶段条件下解决问题，且尽量符合中长期目标的最小可行方案。
思维方式概括并抽象为以下如下一些关键点，关键点我会举例说明。

结果导向

结果导向，既然产品经理以解决问题为目标，那问题的本质是什么？什么情况就算问题解决了？问题解决到什么程度就够了？这些问题在思考如何解决问题前，就需要明白。
在学校里，如果你考试不理想或者参加比赛没获奖，老师以及你自我安慰时，总是会说，哎，结果不是最重要的，过程最重要，要看你过程中学到了什么。对于个人来说，没毛病。但是，公司是百分百追逐利益的组织，并不是学校，我出钱你出力，很简单的交换。因此，从学校跳到公司，首先需要明白的一点就是，结果至上，没结果就别瞎jb说，工作目标一定是为了达成一个确定的结果。以前有个小同学刚来不久，有次我找Ta聊天，希望引导Ta思考并制定自己的工作愿景和职业规划，结果Ta说了句：我来这就是想找个厉害的大神带我学习。我内心真是，一口老血。这话要是让领导听到，岂不是当场暴走。
在结果导向思考的过程中，最简单的方式就是定KPI（Key Performance Indicator），通常通过数字的方式衡量一个工作结果，比如流水，利润，人效提升等等。但KPI考核方法过于片面，尤其对于产品工作，并不是最合适的。很多产品的结果表现，不能完全用KPI指标来概括，因此这里也重点讨论一下，产品工作如何更合适地进行结果评价。
合理的评价方式，建议首先做到定量和定性结合。为什么需要这样的评价方式，是因为产品本身并不一定直接带来金钱收益，也不只是带来其他数字上的变化，还可能有“从无到有，从A到B”的变化，而这样的变化，也是期望达成的结果之一。 从商业产品经理的角度来说，需要构建产品能力，也需要有明确的业务收益。前者指的是能做什么事，后者指的是做成什么事。
没有定性只有定量，容易造成外强中干和形式主义。比如盲目追求销售额增长而忽略了客户关系维度，这个季度的KPI虽然确实完成了，奖金也拿到了，但客户再也不会被”骗“了，中长期完全不可持续发展。
而没有定量只有定性，会导致收益不明确不可衡量甚至没有收益。比如老师和你说这学期只要把我布置的作业写完就行了，成绩多少分都无所谓，是不是有毒，除了一些修身养性的选修课，可能一般老师也没这个仙气。
百科对结果导向如此解释： 结果导向的人就是重结果不重过程的人，他们做一件事在乎的是能得到什么结果，能有什么收益，对自己有什么好处。很多时候，他们只会做对自己有利可图的事，而不是有价值，有意义的事。他们为了达到自己的目的，为了自己的利益，有时候，会煞费苦心，绞尽脑汁的来想办法。他们不在乎过程是否完美，是否合理，是否合乎伦理，有时候甚至不在乎是否合法，只在乎他们梦想的那一个完美的结果。往往，他们太注重结果了，而导致过程的错误，结果达不到。他们的优点是目标明确，但往往他们的缺点是会被一些现象迷惑，而去追求不现实的目标，或是会有多个目标，惨死在追寻梦幻的路上。如果他们心思正，目标明确，能非常好的达成结果，实现价值。主要一点是心思要正，殊途同归，但要找那条正途，而非歪门邪道。
我表示不同意。 “往往，他们太注重结果了，而导致过程的错误，结果达不到。”这个缺点并不是由于结果导向造成的，而是在结果或者目标设定的过程中，定量和定性考核未结合或者设定错误造成的。 结果导向的思考，不仅是帮助在完成一件事情时用来进行质量评价，更重要的反而是通过合理的结果考核方式制定，约束实施过程，以保证推进方向和需要构建的能力，符合目标设定。 就像国家在追求GDP的同时，也会说要大力发展XX产业，重点扶持XX产业，也会强调可持续发展，也会说绿水青山就是金山银山之类的。
因此，在结果导向的过程中，直接效益+能力建设的方式，能够更合理地衡量和指导产品经理工作进程。它保证了工作是需要达成一定的收益，同时也不至于太追求数字，保证通过某种特定的方式和路径来达成目标。而约束达成数字的方式，原因是，我们希望在过程中构建的方法/经验/工具等，能对后续长远发展起到作用，而不只是当前KPI。
关于如何制定目标，我们再举个例子。
你有一个梦想，开一家包子店，希望把自家手艺发扬光大，每天挣它个一两万。也希望某天能看到门前排起了长队，店里顾客来来往往，吃你家的包子，嘴里说“真香”，还不忘发个票圈推荐给朋友。
你看，其实在上面的这个描述中，已经有了定量和定性的描述，定量是每天挣一两万，定性是包子质量好还能有口碑。但是，往往我们在工作中制定目标时，就会变样。比如你现在是包子店老板，有可能想愿景的时候是这么想的，但给员工定目标就可能会变成“日流水2万，利润5千”。极端点说，那负责卖包子的同学可能就会不断地在高价的边缘试探，也许确实找到了那个平衡点，顾客可接受这个价格且利润率最高。但这个时候，口碑的愿景其实就不太能达到了，这种方式，也不是可持续的，说不定明天有另一家包子店和你家包子一样好吃还便宜，那就要GG了。同样如果你过于理想化，对你的员工说，我希望，一年后，我们的包子能受到大家的欢迎，门口排起长长的队伍，脸上洋溢着幸福的笑容，那怕是这个理想只能停留在理想状态了。
如果要稍微规范一些的描述，可以是：

• 目标：构建口味符合自家手艺标准的包子产品，并以包子为主售产品（数量占比80%以上）在保证合理利润率情况（10~20%）下实现规模化（日流水1w+）运作
• 关键动作1：在用料和制作方法上探索并明确符合自家标准的包子生产流程且成本符合（单个成本1块以内）
• 关键动作2：以传统口味为主要卖点进行营销，在包装/店内VI/对外宣传上均有体现，形成相应品牌认知
• 关键动作3：包子售卖业务常态化，日均流水1w+，独立顾客100+

上面的描述不一定符合实际哈，只是从考虑结果衡量的角度，更加全面和规范。
关于目标制定方面，已经有很多大佬和大佬公司总结了不错的方法和工具。SMART原则和OKR考核办法个人觉得比较好用。套用SMART原则能帮助你制定合理的考核标准，而OKR能够帮助你明确为了达成目标，在不同的界面上需要实现什么样的关键结果。这两个我就不具体展开讲了，大家自己搜索了解即可。
虽然思路和方法是无尽的，但现阶段的资源一定是有限的，在有限资源条件下做事，只能解决一个核心问题，所以结果导向时，需要保证目标聚焦，上面例子中，三个关键动作从不同维度表达了，为了卖出受欢迎的包子需要做哪些事情。有个小习惯，每次做事之前用一句话来描述你期望达成的目标，如果无法一句话概括，那可能就不是很靠谱了，做着做着你会发现接下来不知道该往哪个方向了。
所以，结果导向有两个关键点，一是合理的衡量方式，二是聚焦在一件关键的事情上。

逻辑思维

这可能是产品经理的特质中最典型的一个点了。总是被提到甚至被吐槽：你们PM就是，想个啥事儿都逻辑性特别强，非要分析原因，非要理个123出来。
逻辑一词，最初希腊语logos本意即是词语/言语，引申为思维/推理。可见逻辑其实就是关注思维规律和思维过程的学问，逻辑是更清晰更高效地进行思考。不扯太多概念性的东西，就产品经理日常会用到的几个思考方法举例说明。

抽象

通过抽象，抽离事物的特征、属性、关系，将个别的、非本质的内容剔除，概括本质特点和构成。抽象对于简化和概括产品工作非常有帮助，只有通过抽象的方式来观察和分析产品，才能从最根本的层面发现和解决问题，同样因为抽象，也能够更快地发现问题，而不会停留于表层现象。
举个例子（码字时瞄到旁边的空气净化器，那就拿空气净化器来举例吧），你之前从来没有研究过空气净化器的结构，现在你需要设计一款空气净化器，该怎么设计？正常思路的话，可能你已经开始去网上搜索空气净化器的原理和构造，甚至设计图了。现在，别急，试着先在脑子里过一遍，蛤，啥是空气净化器，空气净化器的本质是什么？
我会想，空气净化器的用途是净化空气，那它的输入是污浊的空气，输出是干净的符合人体健康标准的空气，而处理模块的作用即是去除空气中的有害物质。进而，可以将它抽象为，一种以污浊空气为输入健康空气为输出的有害物质过滤装置。自下而上后，你会发现，咦，那口罩是不是也是，新风系统是不是也是？没错，是的。抽象之后，你会发现，这些东西其实都差不多，只是表现形式不一样而已嘛。你甚至还会发现，既然是空气过滤装置，那么考察它们的关键指标是什么，是能过滤什么东西和过滤的效果好不好，进而抽象出，空气过滤装置（甚至还可以进一步抽象为一个筛选器）的关键性能指标是过滤物类型和过滤效能（筛选内容和筛选效率）。
你看，在什么都还没有做之前，通过自下而上的抽象，你就已经知道了这么多事情，知道了空气净化器的构成是什么，核心是什么，关键指标是什么，还知道了同类型的产品有什么，而如何设计，原理是什么，反而是后面才需要关心的事情了，对产品经理来说，前面这些事情是非常重要的。是不是很有趣很鸡智的做法。（我保证在写文章时没有搜索空气净化器的相关资料，就是这样推理出来的）
程序员面向对象编程，其实也是一种抽象的思路。比如开发一个权限管理模块，用于管理所有登录用户可操作的功能，比如管理员A可以看所有人的信息，而普通人B只能看自己的信息。在进行功能开发时，不应该直接对账户A和B进行权限指定，而应该是将其抽象得到角色这一结构，定义管理员角色和普通用户角色这两个对象，给对象赋予不同的权限，然后为A和B这两个具体的用户分别分配管理员和普通用户的角色。这样一来，不仅能够方便查询到，用户A和B分别是什么属性的用户，后面来了A2，A3，B2，B3，也不需要重新写代码，只要为其赋予相应的角色即可。面向对象的好处就在于此。同样，像一些大平台的语言，都会预先提供一些Development Kit，也是面向对象，通过工具包的方式，每次去new就好了。

切分与解构

将一件事物用可枚举的，互相独立的点来进行结构化的描述。比如选购手机，你自然地会想到，多少钱，配置怎么样，好看不好看，耐摔不耐摔，本质上是对手机这个商品在不同维度进行切分和解构，来更好地判断是不是满足你的购买要求，这些解构的维度分别是价格/外观/配置/工艺。如果你观察得仔细，也许会发现一些电商网站的比较功能其实就是这么做的，你可以把纠结不定的产品放在一块，它会帮你把同维度的参数列表呈现出来，帮助你快速比较和做选择。
比如之前举到的包子店的例子也一样，关键动作之间相互独立，是对目标在不同维度的切分和解构，这么梳理甚至能帮助你发现之前思考中遗漏的部分，比如很容易忽略的包子制作方法标准化这个关键点。
这个思考方式的好处显而易见，条理清晰，解构为独立的不同因素之后，你能够更快做判断和分析，而不是各种因素混在一起，剪不断理还乱。它还能让你考虑的点更加全面，因为思考并列举不同的维度/方向/特征，难度远小于毫无目的事无巨细地一一列举。就像画马时，画两颗蛋和4条线很容易，而直接从头开始画工笔画就难得多了。
那么问题来了，马的细节总得画，怎么办，包子还得做，怎么办。很简单，重复切分和解构的过程，对每一个维度再进行这个过程，直至最细粒度，比如代表马头的那个蛋，可以再画一个小蛋表示眼睛，一个小蛋表示鼻孔，比如手机配置可以再细分到屏幕分辨率，处理器型号，电池容量等等。细分过程中，一开始不要求必须正确，而要求尽可能枚举所有能想到的信息，不放过任何一个细节，后续逐步进行归纳和分类。这个过程用树状结构的脑图进行梳理最方便，相应的工具也有很多，在线的百度脑图，zhimap，本地客户端比如mindmanager等等都很方便，我个人非常享受这个过程，可以将一个事物解构到独立的最细粒度，然后一一观察哪里要做什么事情。

系统思考

系统化也会需要解构，将系统切分解构为负责不同职能的模块/结构，分别具有不同的行为，但系统思考更注重关联/组织/部分与整体。校友钱学森同学对系统作如此定义：系统是由相互作用相互依赖的若干组成部分结合而成的，具有特定功能的有机整体，而且这个有机整体又是它从属的更大系统的组成部分。
缺乏系统思考，容易出现的现象是，只见树木不见森林，头痛医头脚痛医脚。工作中，你经常会发现，解决一个问题，刚开始觉得很容易，但后来发现花的时间越来越多，为了解决这个问题，需要先解决其他问题，然后不断地，打了很多补丁。本质的原因并不是没有弄清楚这个问题，而是没有从系统的角度去思考它所处的位置/模块，没有考虑它与其他模块的交互/联系/依赖。其中关键是意识到要解决的问题处于一个错综复杂环环相扣的系统中。
系统中两个关键点，一个是要素，一个是要素之间的内在关联关系，后者比前者更为重要，对系统起决定性作用。比如手表缺了秒针那至少还能看时分，但如果每+1s，分针退一格，那就没法看了。
在解决问题的过程中，需要花更多精力理清楚要素之间的关联关系，输入输出是什么，谁对谁有影响，谁对谁有依赖，这是“成大事”的关键，否则就会手忙脚乱。工作中碰到的系统，其实很多，不只是你要开发的XX平台，XX管理系统，才是系统，一个团队，一个工作流，一个小功能小交互，都是系统。在做事之前搞清楚，哪块工作会需要哪个人做哪个事，谁的小失误可能会影响全局推进，等等，才能成事。在构建与人相关的系统时所做的事，我赞同我老板的描述：”你要做一个局“。
我们总是强调做事要有先有后，种瓜得瓜，种豆得豆，但在系统思维中，如果片面地使用线性方式进行思考，就会出现问题，比如种一颗瓜子可能得到一颗瓜，但种1w颗瓜子，有可能土壤养分已经无法维持正常生长，导致颗粒无收。导致这样的原因是，土壤本身这个参数应该被考虑到植物生长的系统中，并且与瓜子之间有一些相互影响。非线性不如线性容易解释，但也让自然千变万化，系统思考时要注意很多现象都是非线性的。
另外，系统本身作为一个模块去考虑它的输入输出时，会有一个奇妙的机制：反馈。反馈调节在系统控制中的作用很有意思，是调节系统平衡或者持续增益的关键因素，我们后面会讲到。

归纳演绎和推理

归纳与演绎是两个过程，归纳从特殊到一般，演绎从一般到特殊。 归纳和演绎都有两个关键要素，前提和结论。
归纳并不能得到百分百肯定的结论，因为它的前提并不是“真理”，而是“现象”。比如，我刚上班一周，发现每天下班八点走总是会堵车，第二周每天九点回的，发现不堵车，于是我决定晚一个小时回去，因为我觉得九点应该不会堵车。
归纳法以整体中的一部分作为抽样对象进行研究，以此来代表整体，样本范围选择决定其代表性。如果要证明归纳得出的结论是正确的，那除非检查整体中的每一个样本，那是不可能的。比如你想证明九点永远不堵车，不仅要检查过去每天九点都比八点顺，还要检查未来的样本。
而演绎得出的结论是特殊的，确定的，而其推导前提是确定的。比如，手机是能打电话的移动电子设备，iPhone是手机，所以iPhone能打电话。而如果前提本身有问题，则演绎法不work，比如所有的天鹅都是白的，我明天要去动物园看天鹅，它一定是白的。这个前提本身是错误的（但在发现第一只黑天鹅之前，人们真的以为这是真理呢），所以最后得出的结论也不可参考（黑天鹅事件在经济学中，常用来形容非常难以预测，且不寻常的事件，通常会引起市场连锁负面反应甚至颠覆）。
归纳和演绎并不能准确地告诉我们下一步一定该怎么走，但通过基于一定假设条件的思考，能够帮助我们规避风险，针对可能情况做出相应的设计，以便在遇到问题时快速响应。
基于归纳和演绎方法，通过论证展现做模拟和推理，看起来是纸上谈兵，但纸上谈兵并不是无用的，它的意义是从一个观点出发，得到另一个让人接受的观点，能在我们做出任何实际投入之前，就能根据不同的假设条件模拟推演出对应的结果知道在什么情况下会出现什么坑，帮助我们节省大量的实际成本投入，提前预知并避免风险。
狼人杀里的推理最多了，对吧。想想你在一场狼人杀里面是怎么思考的。如果他是预言家，那么他在XX时候就该跳出来了，所以他不可能是预言家；我是好人，如果他也是好人，在这个时间点上，不可能踩我，如果是狼人，这个时间再不杀人就晚了，嗯，大概率他应该是个好人。你看，你通过假设，推测当假设条件成立时，对方应该有什么样的表现，当这些表现真实发生时，你就能通过排除或者概率排序得到最优解，来获得游戏的胜利。
战场打仗也需要沙盘模拟，在沙子做成的立体地图上，插上小旗子，放上小人儿和模型，用不同的颜色来表示敌方和我方，推动小坦克模拟敌方进攻路线，然后思考：如果敌方从这个方向切入，我方应该如何应对才能破局？
上面两个例子，其实是用最简单的方式，在假定条件下，模拟甚至穷举事件真实发生时最可能的形态，进而推演出相应的结果表现和应对方式，而虽然假设条件还未发生，应对方式却是真实得到的收获。
程序中的if else 其实是通过条件判断语句来消除一部分未知事件造成的风险，这本身也是一个假设推演的过程，如果用户输入正确，那就登录成功，如果输入错误，需要重新输入，如果输出超过5次，就锁定不让输入。如果不进行这样的if else设计，那可能你的系统要GG。
其实，换位思考也是在做推理，我准备和某人说一件事情，如果我是Ta，听到这件事会怎么想，会怎么做。啊，我感觉如果我这么说，Ta可能会想马上打死我，不行，得换种说法。你看，通过假设，避免了被打的风险（大雾）。
在假设推演的过程中，你可能会发现，唉，这个以前好像发生过，类比一下，我似乎知道我该怎么做了。比如在沙盘模拟过程中突然发现，咦，好像某次历史上的战役也是类似的情况，我们看看他们当时怎么发起进攻的，有什么损失是可以避免的，哎就很棒是不是。
所以，假设也不是一味的空中楼阁，如果在假设的过程中运用类比，在历史数据库中寻找相似的案例，并对比当前情况与历史案例的相同点和不同点，那这些经验能够极大地帮助你减少推演过程中无法确定的因素，约束假设推演的过程，避免最后发现，需要做的假设越来越多，而并不能得到有效的结论。
另外，需要注意，世界的复杂性可能让推理变得难以进行，在推理的过程中，需要适当地简化和舍弃一部分与主线无关联或者影响可以忽略的要素，以进行简单推理。

数据驱动

产品经理用数据说话，商业产品经理更然。数据不等于数字，数据是可置信的信息。
大学主修电子信息工程，关于信息，男神香农（信息理论的奠基人）有一句经典的概括，信息量代表了不确定性。他创造性地用信息熵（entropy）概念来衡量信息量的大小，即为随机不定性程度的减少。这就表明了他对信息的理解：信息是用来减少随机不定性的东西。比如，我抛了一枚硬币，并清楚地知道它是正是反，则这个结论已知，完全确定，则这个信息的熵值对我来说其实是0。而如果我在抛这枚硬币之前，有人能告诉我一条硬币结果是正是反的信息，因为它是有概率存在的，按香农的公式计算出来，信息熵值为1（以bit为单位，而后的byte、KB等概念都是从此演化而来），它代表了一个最简单的陈述：是/否代表了数据的最小单位。
扯这个概念，一方面是怀念一下香农大神，另一方面也是表达，数据，或者说信息，在我们做决策时的关键作用，是抵消不确定性。可用的（即准确的）数据量越多，做决策时的风险就越小，所以，做决策需要数据驱动。
数据驱动的核心是，在收集到有效数据的前提下，运用合理的方法对数据进行处理和分析，从而输出对决策有帮助的结果和结论，从而指导实际的产品设计和内容选择。
这里直接以一个很多人都听过甚至做过的产品，且是一个相对复杂的例子，DMP（Data Management Platform）数据管理平台（DMP在广告/搜索/电商/内容推荐等领域发挥非常关键的作用）来讲解运用数据做决策的过程，同时也带大家了解，如果在系统层面需要搭建数据驱动决策的能力，需要怎么思考。
以电商商品推荐为例，我们一般将DMP能力分解为以下几个关键模块：

• 数据的收集（采集需要的各节点数据，比如浏览/收藏/购买/分享）
• 数据的处理（对数据进行清洗/整理，过滤无效数据，分类有效数据）
• 数据的分析（基于一定的分析方法对数据进行分析和计算以输出结论，比如根据购买频次统计分析生活状态和购物喜好）
• 数据的使用（运用数据分析结果指导策略制定，比如根据购物偏好结论为该用户推荐同类更多商品）

数据收集

在第一个步骤中，我们可以运用多种方式收集用户数据，比如做用户调研，比如收集商品购买订单等等，但在大数据时代，我们聊点高级的，即埋点（我这里说的埋点是概念上的埋点哈，并不是埋点这种技术）。埋点是说，在对商品推荐有价值的行为节点，建立数据的采集和记录机制，在相应的行为发生时进行事件汇报和记录，这样可以记录每一个有价值的行为，完全不需要做什么抽样调查。在这里，我们把用户与购物相关的有价值动作用一个对象”行为“记录下来，每一条行为记录当中，都包含有用户id，行为发生时间，行为类型，前向或者后向节点，行为具体内容等，具体可以这样设计：

• 唯一记录id
• 用户（名称/id等）
• 发生时间
• 行为类型（比如点击/加购物车/收藏/购买/分享等）
• 事件内容（比如手机-小米-小米Mix尊享版）
• 前向节点（比如分享页/活动页）

这里复习一下，其实在设计用户数据结构时，用了面向对象的设计方法，并不是记录每次用户的下单过程，而是将用户的每个关键动作都抽象为”行为“这一相对普适的结构，这样不仅具备良好的结构性能，在后续数据分析时也会有更高的自由度和规范性。
由于有了更加高性能和更加稳定的动作采集、汇报、记录机制和技术，以及高性能的规模化数据存储结构，使得像上述对数据的实时规模化记录成为可能。也正是有这些技术，推动了大数据的落地。所谓大数据，并不是指数据多，而是指数据全，我们不在像以前那样，做数据抽样调查，纠结于抽样方法和样本数量，因为我们现在获取的是全部所有数据，基于全量做研究，得出的结论将更为可靠，且节省了抽样成本，这才是大数据的关键。
既然提到这个关键，多说两点。
第一是注意幸存者偏差，在数据收集机制的设计时，要考虑收集数据的片面性对结果的影响。这里比较典型的例子就是今年的高考题之一的，关于统计战斗机弹孔位置来决定如何做改良的例子。专家的错误在于，他即使查看了所有幸存飞行员所驾驶飞机的数据，得出的结论也是基于成功飞回来的样本，而忽略了那些在战场已经坠毁的战斗机数据。这些数据反而才是最关键的，回来的战斗机，虽然机身那些位置有弹孔，但反而他们回来了，正说明这些位置中弹不会导致致命。
二是注意收集正确的数据，举个例子，你期望每天早上，在合适的时间，通过你的app给用户推荐一条早安帖，你机智地想到，周末用户可能会起得晚一些，我周末应该晚点再推消息，避免打扰到用户。你用算法构建了合理推送时间与周内/周末的关系，并依此完成推送时间决策。在周一到周五，8点推，周六和周日，10点推。但有一次，劳动节放假了，那天是周一，你8点推送了一条消息，把用户吵醒了。熟睡中被手机APP推送消息吵醒，想想这是多么恐怖的一件事情，用户一怒之下，卸载了你的APP，血崩。你看，用户起床时间的真正影响因素是节假日而非周一到周日。以人类的聪明才智，这个点很容易想到，但一是体现在产品设计中并不容易（我印象中IOS的闹钟都只能设置为周一到周五生效或者周末生效，用小米手机发现MIUI有优化，可以自动联网同步工作日和节假日数据，从而设置仅工作日/仅节假日闹钟，这也是被MIUI圈粉的一个小细节），二是我们今天聊的是DMP，在算法模型做处理时，如果你在前端并没有设计要收集节假日和工作日数据，而只收集了星期数据，那机器再怎么学习，算法再怎么优化，也无法得出效的结论。这里的本质错误是没有搞清楚真正影响因素。
当然我们本来就是做数据研究，可能在一开始就是不明白，用户起床时间到底与什么因素有关，为了尽量在后续能够做全面有效的分析，在不了解的情况下，数据采集应该尽量做到维度的全面覆盖。这时又会有另一个问题，现在还没发达到我们可以记录用户的每个行为的程度，就算有，在数据处理和分析阶段也会需要无限的计算资源才能够满足需求，怎么搞？
合理的解法是，在做系统设计之前，基于历史经验和人工模拟的实验，来进行影响因素的排除过滤和筛选，比如，我们大概率判断，国内用户的起床时间和当天国外的天气没关系，反而可能和今天堵不堵车有关系，如果不知道，也可以简单设计实验来做基本验证。基于这些经验和预实验，能够极度简化模型参数，既不浪费系统性能，同时也保证了起始数据收集维度的正确性。
所以你看，我们该相信经验，还是数据？我说我们该相信数据，但经验和数据不矛盾，相反，经验给大数据/人工智能提供了一条快速收敛的捷径，这些宝贵的经验让模型在一开始能有更好的初始学习条件。
所以你再看，产品经理的价值体现在哪里？更多情况下，可能并不是参与DMP系统技术架构的设计，那些交给技术同学就可以了，产品经理在这里做了什么事，他基于经验和前期的模拟实验，更好地设计了DMP系统输入，指导了在数据收集阶段该收集哪些数据，这个价值远大于做具体系统架构设计，这才是真正的”设计性“体现，这才是真正的architect！

数据处理

我们收集到的数据并不一定都是可用的，对于电商来说，有可能有刷量数据，比如在店铺刚上线前期为了冲销量有很多假订单，甚至还会有竞争对手攻击而制造的假数据，还可能有由于设备不稳定性而造成的抖动等，这些数据都是不可用的脏数据，一般都有比较明显的数据集中特征或者错误，运用这些特征，建立处理规则，即可清洗掉脏数据，避免对正常数据分析造成干扰。
清洗完成后并不能马上用于数据分析，这是因为有些数据比较原始，仍然处于”机器不可读“的状态，也不利于人工分析。比如你采集到了用户在你的优惠活动H5页面的点击位置，想研究H5的UI设计与点击位置的关系。那需要在数据整理阶段，将原始数据中的点击坐标数据做加工，根据规则，比如根据坐标范围划分为边缘/中心/上下左右等分块区域，对数据进行重新标记，这样你在分析时就可以直接看区块维度数据了。同样，比如你想分析购买商品价位分布，那就需要提前进行划分，比如1-10，10-50，50-100，100-1000，1000+等等，否则原始数据里，每0.1元阶梯上都有商品分布，最后根本无法收敛出结论。这个过程，我称之为对数据进行结构化处理的过程。
数据处理的核心是基于一定的规则，对数据进行过滤和结构化处理，以使数据达到”可分析“的状态。

数据分析

对数据基于一些统计或者计算方法进行分析。在分析之前，需要制定合理的分析方法和分析指标。
分析方法多种多样，分类，聚类，维度交叉，漏斗分析，运用先前讲过的归纳演绎的方法，能够得出结论，在这里不进行展开，说下在营销领域常用的漏斗分析。漏斗分析之所以叫漏斗，是因为从上往下，越来越小，每个过程都有折损。大多数情况下，营销过程都是多节点的，不是一步完成的，每一步都会有流失，比如广告展现了，不一定所有人都点击，有人点击了，又不一定会购买，漏斗分析通过将整个链路打通，对每个节点之间的转化情况做分析，以便定位最终效果差的原因并作出优化。另外多说一句，基于这几年比较火的增长黑客理论，又建立了反漏斗模型，在用户增长的结构中，每一步通过传播带来的增长越来越多，这种分析和漏斗又是相反的，也很有趣。至于其他基于机器学习的分析方法，这里更不展开了，大家自己了解即可。
分析指标非常重要，合理的分析指标能够直观衡量事物和现象的质量和程度。比如互联网公司经常会使用到的，增长率，活跃率，点击率，等等。举一个指标设计不合理的例子。假设你现在研究某款产品的购买用户在性别上的分布，以决定对不同性别的推荐机制。你最后发现男女比例8:2，于是你得出了这款产品的购买者多为男性的结论。但你却忽视了，全国人口比例就是8:2，这个性别分布太正常了，就是平均情况。合理的指标设计，可以引入目标人群指数（TGI for Target Group Index）来衡量人群偏好。该指数的计算方式是目标占比/大盘占比，大于1代理正偏好，小于1代表负偏好。引入TGI后，你发现，男性和女性的TGI均为1，与大盘情况相同，没有特征偏好。而如果男女比例是9:1，那你会发现男性是正偏好，女性是负偏好，数值越大代表偏向越强。这便是分析指标对分析结果带来的影响。

数据运用

数据最多的应用是帮助决策。上面已经举了很多例子，运用数据分析的结果，可以用于推广决策，内容推荐，流程优化等等。这里提一个比较有趣的，数据驱动产品迭代。
说来也确实是产品的”灵性“了。我刚来时，主要负责广告投放系统，对广告系统的常见统计指标和优化方法有比较深刻的了解。有次公司举办Hackathon（黑客马拉松，几个人组队，按比赛主题在较短时间内做一个产品prototype出来），主题是boost，加速。在想我们要做什么，想boost什么的时候，我联想到，我们天天看点击率激活率优化广告，为什么不能用来优化产品？我们的线上平台，也有很多入口，有很多工具，有很多按钮，也会有点击率，那这些节点的数据，岂不是会对分析产品问题和功能优化有非常大的帮助？于是，我们想了个办法，通过嵌入js，扫描全部控件事件的方式，实现了线上产品所有控件的全监控，把每个用户行为和前后节点都进行了记录，并允许在前端将任何两个有关系页面的数据链接起来做指标计算。这个产品后来也确实获得了大佬的认可。
这里有两个关键点，一是将数据驱动的理念用于产品优化，甚至在部分情况下能够做到自动优化。现在一部分安卓手机能够根据用户对不同app的打开频次和时间进行记录，并预测app使用习惯，推断你可能在什么时间点将要打开什么app，从而提前在后台准备好相应的程序，达到提升响应速度的效果，这便是一个数据用于产品优化的很好的例子。二是在我设计的产品中，并没有太面向过程地考虑，如何进行处理数据，而是将数据条目本身作为对象进行存储和管理，这是系统的核心。而在前端，不同需求的用户，可以将数据通过不同的组合方式、交叉维度、统计指标进行分析，具备极高的自由度，而它的前提便是我将每个条目作为可以搭出不同模型的最小块积木。以数据而不是计算为核心，数据与分析进行分离，有需求者可以按自己需要的方式进行取用，是现在做数据类产品的一个不错的理念。
也没看过什么太多相关的书籍，我的方法也是在实践中逐步总结出来的。翻过一本《数据驱动/从方法到实践》，初学者可以看看，浅显易懂，笔者花了总共不到一天的时间看完，觉得和我自己实践得出的结论还挺一致的。数据驱动这事，更多还是靠实践，多进行收集/处理/分析/使用数据的实践，便能更快建立自己的分析方法和体系。

价值判断

在公司里，作为产品经理，尤其是商业产品经理，想搞钱，就必须搞清楚短长期投入产出比。理想情况下，想要的当然是一分耕耘，十分收获，但一来这个并不是那么容易的，二来是未来不可知，已经产生的投入，在什么时候产生价值，产生多大的价值，都是值得讨论的问题。公司角度会考虑，管理者会考虑，作为商业产品经理也一定要考虑，普通工作也最好考虑，因为这样才是对自己负责，让工作价值和效果最大化，说不定还能涨点儿工资就美滋滋了。
在价值判断上，偏用户的产品经理和偏商业的产品经理需要考虑的维度也有所不同。对于偏用户侧的PM来说，产品的价值是被人使用并且不断被人使用，是用户量、活跃用户量、功能使用率、使用时长、增长率等等，而对于偏商业的PM，更多考虑的是其变现价值，是否能够形成一种可长期持续赚钱的模式，是不是能形成一门生意。比如微信，toC角度考虑，关注产品功能和用户体验，toB角度考虑，关注朋友圈广告曝光量有多少，互动率如何，流量变现价值有多少，适合什么类型的客户投放。比如生产一部手机，toC角度考虑，关注外形设计，关注配置，关注ROM体验，toB角度考虑，唉你说这个手机就是一个超级入口，这价值可大了，能不能搞点事情，比如预装APP啥的（一众安卓手机厂商：你说谁呢？？？），比如以手机为中心搞个生态（乐视：蛤？），比如弹个系统级的广告（小米：喵喵喵？）等等。说的极端了，商业产品经理没这么欠抽的。
toB的产品经理，考虑的更多是，如何通过产品能力的构建/升级，并且聚拢各方的资源和事，让一种“你好我好他也好”的模式能够持续转起来，能够持续赚到小钱钱。而这，也是业务思维，是成为CEO走向人生巅峰必须要想清楚的事情。
在结果导向的部分内容中，提到过，数字价值和能力价值，这里再强调一下，产品的价值，一定不只是会体现在数字上，如果那样，直接搞销售得了，不需要产品。效益增长，问题解决，本身就是有一部分价值无法用直接的数字衡量的，而这部分的价值，在不同的产品阶段，甚至远大于在数字指标上的提升。在进行价值衡量时，一定不要忽略掉这部分的价值。

灵性

很玄学了，但灵性确实对产品经理非常重要。能把上面这些思考能力运用自如，并且很有悟性，很聪慧，我觉得是有灵性。它很难解释，但如果说，一个有灵性的人，会有什么样的表现和做事方法，我觉得是，能举一反三，能以一叶而知秋，能一眼看清楚事物的本质，能把自己获得的经验/能力/方法/工具，快速变换为解决问题所需要的形态，等等，我认为这是有灵性。
自己是个菜逼Dota2玩家，但偶尔也会看比赛录像，弹幕经常会夸某个选手某个操作“很灵性” 。有个很简单但也很灵性的操作，在Dota2里有个道具是一根树枝，买了这根树枝放在身上，你的属性会得到小幅提升，总之就是变得更厉害一点。除了被动地让你提升一些属性值，你也可以主动使用它，点击地面一个位置，使用树枝，可以种下一棵快乐的小树苗。而Dota2里的另一个机制是，有视野限制，地图各种地方，长了非常多的树，你躲在里面，别人就看不到你了，你就可以搞偷袭或者逃生。于是，当你走在马路上，敌人在追着你打时，你可以当场种下一棵小树苗，种在你和敌人中间，这样他就突然看不到你了，你就可以逃走了。然后，Dota2里还有另外一个道具，叫吃树，吃一棵树可以加血。于是，当你发现你血不够的时候，你还可以在种下小树之后把它吃掉来回血。同样，作为你的敌人，为了找到你，不让小树苗挡住他的视线，他即使满血，也可以把这棵树吃掉。是不是很神奇！这两个道具是Dota2里最基本的道具之一，但玩家们都能有这样的骚操作，在不同的情境之下，用这两个道具来达到追捕/逃生/回血等不同的目的，我认为这就是灵性，能够将已具备的能力/思维/知识，快速转变为解决问题需要的形态。
灵性与一个人本身天然的思维模式和应激模式有很大的关系，我只能说，如果有灵性，那一定非常适合做产品经理，如果没有的话，具备上述的思考能力，也能让你在产品工作中游刃有余。
May the force be with you.

本节资料推荐

• 美剧《硅谷/Silicon Valley》，HBO的这部喜剧对于互联网创业团队遇到的问题刻画非常精细，你可能会觉得片中几个主要角色在做决策时非常智障，但那也是作为影视作品为了喜剧效果用的表现手法，实际工作和思考中，你真的可能会遇到这样的问题
• 书籍《系统之美-决策者的系统思考》，书中以大量生活中的现象为例作引导，探讨并尝试解释系统的复杂性，同时给出对系统进行改造和提升的方法，好书
• 书籍《简单的逻辑学》，真的很简单，但也很好玩，看完可以成为一名优秀的杠精，和别人撕逼时一定不会输，手握逻辑武器，理直气也壮

关于技能

注意，这里提到的产品概念，指的是广义的产品，经过一定设计能够解决问题的事物，叫产品。一个平台，一件事，一个流程，一个团队，一个项目，都可能是一个产品。而关于技能的描述，也并非一定针对单个人或者一个团队，一个人如果同时具备这些能力那是极好的，而在有相对明确的分工团队内，也不意味着只需要具备其中一项能力就行了，这些能力是相辅相成的。

需求分析

需求即解决问题的诉求，并且是在某种特定的场景下产生的诉求和欲望。需求是驱动所有产品/所有商业/所有公司发展的原动力。没有需求，产品就没有存在的意义。
幸运的是，人的欲求永无止境，我们总能找到“问题”，也正因此，无数的创业公司蓬勃发展，从人类生活的各个角度切入，想要通过解决问题，满足人的生理、安全、社交、尊重、自我实现的诉求（马斯洛需求层次）。这是偏用户角度的分析，商业需求表面上看起来与这五个需求没有关系，但毕竟任何商业活动都是在与人打交道，最终都可以归结为这五点。但是为了方便理解和思考，对于商业需求，我们还是有必要从商业角度出发进行重新梳理。稍微具象一些，我将商业需求定义为，对某一件事变得可行（available）、快速（efficient）、有效（effective），并以此创造价值获取收益的诉求。期望需要某件事从无到有，从慢到快，从有到优，则满足商业需求，即是通过一种解决方案（平台/服务/商业模式）让某件事变得可行、快速、有效，以创造价值并获得与价值对等的收益。
需要注意，这里对于C（偏用户）端和B（偏商业）需求的描述，并不是割裂的一分为二的描述，只是从不同的侧重点进行说明，以解释在洞察分析以及解决问题思路构建过程中的差异点。两者不是对立关系，比如你做C端产品需要考虑用户体验问题，也要考虑中长期怎么变现的商业问题，而做商品产品一开始就会考虑变现问题同时会在需求满足的过程中与用户发生交互，也要从C端产品的角度出发考虑如何进行产品设计。这便是B端与C端产品经理工作的基础差别，它们需要满足的需求性质有所不同，在解决方案构建过程的思路和结果也会不同，核心目标也不同。
但并不是所有从无到有，从慢到快，从有到优的事情，都是值得做的事情，而不值得的原因有二，一是可能并没有这样的需求，二是投入产出比不高。前者需要鉴别需求，而后者需要决策要不要满足这个需求。
当确定需求应该被满足时，需要将用户/商业需求，转化为产品需求，即，需要构建何种产品能力和功能，需要做何种优化，来满足需求。将需求转化为产品需求，正是产品经验的价值体现。

方案验证

当明确需求应该被满足，并且已经有想法，这个产品该怎么做时，别急着马上就开搞。因为再牛逼的产品经理也无法保证，这个产品方案一定是没问题的，产品做出来之后就一定能完美地满足用户需求，微信1.0版本的store评论还一堆差评呢。所以，按初始想法大刀阔斧地开搞，是非常危险的，往往最后做出来一个看似超级牛逼的产品，但用户就是不买账，就很监介。人无完人，事无完事，水平再高，也不太可能初始方案百分百正确，在完整版实施之前，小成本验证，是必要动作，也是非常关键的动作。
关于验证方法，《精益创业》一书中提到了MVP的概念，minimum viable product，指最小化可行性产品，将产品方案用最简洁的实现方式开发出来，暂时忽略掉高级复杂的功能特性，开发一个“简陋但必备功能”的产品，快速投放市场让目标用户上手使用，然后通过不断地听取反馈掌握有价值的信息，由此对产品原型迭代优化，尽快达到理想目标状态。比如我要造一辆车，我的核心技术是独家的V8引擎，希望能够以80km/h的速度连续行驶500公里，这是核心目标。那我造这辆车，最重要的事情就是要满足速度和续航，这俩搞定了，其他都好说。现在我又没那么多钱造一辆整车出来，那甚至可以只要引擎，轮子，方向盘，刹车，我就可以上路测试了，当然为了保证测试驾驶员的安全，可能还得加上相应的保险措施。但我完全没必要在验证速度的阶段，给车上安音响和空调，如果你觉得要把这些载重量算上，那多拉几桶水就得了。
你要是路子野一点，可能还有更野的方案：去汽车报废厂，找辆别人家的车，拆掉换上自己的引擎，直接变成老司机。 这是我想强调的一点，我认为MVP仍然不是最佳的验证思路。MVP中的product，我将它改为 plan。最小化可行的方案，并不一定是最小化可行的产品方案。这里的区别是，在验证的阶段，你甚至完全不需要开发产品出来。
这个点，我自己是有经历过的，很痛，所以也和大家强调，虽然我们的本职工作是做产品，但并不是在工作的任何阶段，都需要以“产品”的方式进行。尤其在这几年，互联网创新多为模式创新，产品反而是商业模式的承载体。大学里鼓捣过一些小项目，有一个是，帮别人去校门口小店里买鸡排饭，赚一块钱跑腿费。简单预估了下每天的订单量，算了下觉得能赚，于是马上开始着手准备线上下单平台，并且也确实考虑了，哪些是核心功能，哪些可以后面再说。搞了几周，搞完了，大张旗鼓地在学校里刷海报，然后看有没人下单。刚开始还有几单，后来发现下单的同学，需求还在，但是不从平台下单了，而是直接给我发短信或者打电话 = = | ，我也是日了狗了，这平台白搭了，相比于打电话，并没有带来什么更好的体验。但现在想想，如果当时不犯蠢，不着急马上做平台，而是先在BBS里发一条消息，说要买饭可以加我微信。然后就坐等订单就行了。这样，不用坐实际的开发，你就能知道，每天的订单量会有多少，订单的时间分布是什么样的，每个用户的需求是高频低频，大家关注的是时效性还是价格还是什么。在完全没有进行产品开发时，已经能够通过此方式，快速验证满足需求的方案是不是可行，并且还可以知晓关键数字。这样的验证方案，才是MVP，是最小可行方案，成本远低于进行产品开发。你甚至还会进一步想，目前直接联系跑腿小哥就可以解决基本需求，那是不是还有必要进行产品化，以及产品化又该改善哪些点，解决基本需求之上的什么问题。
这便是在方案验证过程中，最需要注意的点，我们需要去花时间寻找最简单的验证方法。它可能是问一个用户，画一张图，人肉做一个实验，就能够解决的问题，千万不要因为产品的条件反射，忽略了验证方案的合理性，一步指向产品化，试错成本会高很多。合理设计验证方案，用最小的成本得到最可靠的结果，才是“精益”的方式做产品。

产品设计

定位和边界

产品设计的目标是解决特定的人群在特定的场景发生的特定的问题，看起来像一句废话，但也是平常很容易犯的错误，在设计的过程中，可能会发现某个地方有缺陷，会导致用户C或者D无法使用，于是增加功能来解决此问题，但发现E和F又发现了问题，修修补补，最后产品越来越臃肿，而且四不像，可能都忘了，CDEF本来就不是产品的目标用户，但在假想使用场景时却不小心代入了。这个点在商业/专业型产品上，会体现得更加明显，我也是吃过亏的。举个简单的例子，Adobe的Photoshop，Premiere等产品，普通人可能会觉得这软件啥玩意儿真特么难用，根本看不懂，学习成本太高了。但其实人家本来面向的就是专业用户，而不是小白，从一开始，所有的功能都是针对专业用户而设计的，如果纠结这些功能描述太晦涩普通人看不懂，然后做了很多相关的改造，那有可能就变成美图秀秀了。同样，如果美图秀秀非觉得目前这些功能太简单了，要加一堆更高级的图层啊，蒙板啊，路径啊之类的功能，用户可能会一脸懵B。毕竟美图秀秀就是简单拼个图加个字而已。
出现这样的问题，是因为刚开始没有搞清楚产品的目标用户和需要解决的问题，没有搞清楚产品的定位。而就算搞清楚了定位，在产品设计和开发的过程中碰到问题的时候，很可能因为“追求完美”的条件反射，习惯性地解决产品设计中的“bug”，打了很多补丁。而实际上，想一想初始规划的产品定位，这个问题并不在应该解决的范围之内，就像“不能使用蒙板来抠图”是一个做图的过程中可能会出现的问题，但不应该是美图秀秀这个傻瓜式拼图软件需要解决的问题，它已经在美图秀秀产品规定的边界之外了。
明确产品定位和边界，哪些问题应该是产品功能设计中需要考虑的，而其他是应该抛出来（不是不管，因为可能影响到产品正常使用）的问题。在工作中，尽量不要做“大而全”的东西，而是尽量做到“小而美”，即专注于解决某种特定的问题，不追求一次解决所有问题，这样思路和工作内容都会更加聚焦，也能更快更好地迭代，因为知道路在哪。大而全的东西有其存在必要性，因为一站式，全链条的服务，能带来连续完整的体验，前后配合度和效率也会更高，大而全的东西，建议从一开始小而美的点去突破，慢慢做起来，形成“一条龙”服务。

标准化

对于产品的目标用户，不管是A还是B，产品的体验应该是近似的。同样的功能和交互，不同的用户在使用时，应该都能快速理解其使用方法，符合其基本认知结果，且操作结果也一致。这就要求我们在产品设计时，充分考虑“内”和“外”的标准和规范。
内是指同一产品内类似逻辑和功能操作的方式、反馈都应该是一致的。比如在一款射击游戏中，不管你捡到什么样的枪，肯定都是左键射击右键瞄准，R键换子弹。如果突然捡到一把枪，是Q键换子弹，那在紧张刺激的游玩过程中，很可能因为习惯性操作，被敌人干死。在形成了标准化的认知之后，用户能够更容易理解功能使用方法，甚至不依赖任何的提示也能正确完成操作。在具体产品设计中，类似的功能应该尽量使用同样的表达方式，比如不同地方的开关，应该保持同一种开关，不同地方的输入框，应该采用同一种设计，以便一眼看出这就是输入框。规范一些的设计和开发，都会产出Kit（工具包），比如UI Kit，比如Development Kit，一方面通过工具包的方式，在有相关需求的地方可以直接调用，另一方面提前规范好的Kit也能够保证前后端在用户使用和反馈方面的标准和统一。
外是指如果已经有类似功能的产品，并且用户已经形成了一定的习惯，这时我们应当遵循行业惯例进行设计，而不应该强行创新，就像大部分的螺丝都是顺时针拧紧，逆时针拧松，修理工在碰到不同的电器需要修理时，也不需要阅读手册就知道该怎么拧螺丝。有个记得比较深的例子，手机上的虚拟键盘，还有我们实体键盘，基本都是qwerty布局（当然也有其他奇葩的布局，这里不讨论），但有一次下载了一个手机银行app，设置密码的时候发现键盘顺序与日常使用的顺序完全不同，甚至还是动态的！还美名其曰安全键盘，我找一个字母找了半分钟，找下一个字母又找了半分钟，输入体验极其糟糕，话不多说立马卸载。就算是为了安全，也不应该在键盘布局上做文章，其造成的用户感知是极其混乱的。
我们经常吐槽，卧槽这什么反人类操作，本质上其实是设计的时候没有充分考虑人的基本认知和标准化认知，导致使用时不符合正常操作逻辑，导致了不适感。这点尤其在用户产品设计上，需要注意。

明确的感知

确定的输入，应该有确定的结果，并且，操作结果应当以及时/明确/合理的方式被用户所感知。
比如汽车仪表盘为什么存在，是让驾驶者明确感知到当前速度，那可能会想到，为什么自行车不需要仪表盘。一方面，汽车速度更快，高速运动时，人的视觉感知能力会下降，所以需要仪表盘来明确显示当前真实速度，而自行车速度更慢，通过肉眼观察也能差不多知道当前速度是快是慢；另一方面，汽车是踩油门加速，自行车全靠脚踏板，蹬腿就知道速度快慢了，所以对于自行车来说，脚蹬的速度便也是一种明确的感知，而汽车却不能通过油门来感知行驶速度。仪表盘的另外一个作用是看油箱油量，快没油的时候还会报警，这也是及时明确的信息反馈。
对应到产品设计中，最简单的例子就是，按钮的状态。一个简单的按钮，也会有多种不同的状态，比如不可用，可用，鼠标悬浮，按下，按下之后成功执行功能或者并未执行功能时相应的提示，等等，设计这么多状态的原因就是，不通过文字说明和直接指导，用户看到时便明白是什么意思，同时能够明确感知到，自己进行了相应的操作和操作的结果。对感知和反馈的合理设计，能够减少或者消除用户的疑惑，使用产品更具备安全感。同样，对反馈的优化，也能提升用户体验，比如为什么程序员都喜欢用机械键盘，是因为机械键盘相比薄膜键盘，反馈感知更好，键程更长，在打代码时，手感更好，打字效率也更高，甚至还有人就喜欢机械键盘的声音呢。而机械键盘还有空间的问题，所以在不少笔记本上，人们又开始探索蝶式/X式键盘，期望在较低的键盘高度之下，也能有不错的打字体验。你看，这些种种尝试和创新，都是为了优化打字的感知和反馈。

预设计

预设计是针对某种情况下的必然或者可能发生的操作做半自动的提前设计，其实是对已知信息的合理应用，通过用户的已知行为，能够推断其下一步行为，并设计相应的交互和功能，使得用户更快或者以自动的方式跳转到流程的下一步。
还是汽车仪表盘的例子，不知道大家有没有注意过一些汽车的仪表盘，为了夜间显示，会有背光，之前好奇仪表盘的背光是有单独开关开启的还是根据光线感应自动开启的。有次坐车问我爹，原来，当开启前照明大灯的时候，仪表盘就自动开启了。当时突然觉得真是个精妙的设计，不需要单独的开关，仔细想想，开启大灯这个动作，已经给系统传达了一个有效的信息：开大灯照明了，自然光线已经不足以正常驾驶了，那肯定也看不见仪表盘了，所以开大灯的时候，仪表盘也应该开背光，很简单，也不用用户主动操作了。
还有一个典型的预设计是烧水壶的自动断电机制，通过这个例子想说明的是，预设计要参考正确的条件。最原始的烧开水方式，那当然就是架个锅在火上烤，沸腾的时候拿起来，要不水就烧干了，后来我们就看到了，壶嘴上带个口哨的水壶，水沸腾之后就会叫，人听到后去关火就好了。明火烧水还好，如果是电水壶，没有断电机制就很危险了。当然我们现在的电水壶都能自动断电，我看到时，首先想到的是，里面是不是有温控开关，检测温度到100度的时候就断电，后来查了才知道是蒸汽开关。检测到一定量蒸汽就会切掉开关。选用蒸汽开关的最主要原因，并不是更安全和简单，我意识到我刚开始从温度控制的角度根本就不对。原因是，沸腾的定义本来就并不是温度达到临界值，而是水开始气化，我假想做这个预设计的时候，先决条件就是错的（小学就学过，不同气压下，沸点是不一样的，如果用100度来预设计，那就完蛋了）。因此，使用蒸汽开关，才能够真正根据水沸腾的状态来决定断电。
同样，我觉得，楼道里的声光控照明灯，也是一个错误的自动设计。它本来是方便人们在楼道里摸不到开关的情况下，自动亮起，但我每次到住所楼道的情况都是，正常步行至门口，然后没亮，开门，没亮，大力关门的时候，楼道里的灯才亮起，然而这时候我已经来到室内了，外面纯属浪费电 = = 。提高声控开关的灵敏度可以一定程度上缓解问题，但本质的原因是，根据是否有声音这个信息，无法准确判断人是不是在楼道里，要开灯了。合理的方式是使用人体感应开关，记得之前学校里的楼道照明是使用的类似开关，但现在大多数见到的自动照明基本都是声光控开关，可能也是成本问题吧。
好的预设计，会让用户觉得，好像产品知道我接下来要做什么，不用我自己操作了。手机APP上的预设计就很多了，比如短信应用，检测到是验证码类短信，会在文本卡片下方给出复制按钮。复制的文本，在下次调起输入法的时候，输入法会气泡提示刚刚复制的文字，点击即可快速输入到文本框内。再比如刚刚拍了一张照片，进入微信后，点击加号的时候，会自动弹出刚刚拍的照片，问你是不是要发送这张照片。这些都是通过已知信息去做预设计的不错案例。

有情感的设计

在明确的认同感偏向的基础上，有情感的设计，是画龙点睛的工作。同样是手提包，可以看到男款和女款会有很大差异，而这种差异是有必要的，也是巧妙的，因为在包的认同感上，不同性别确实有明显偏好，比如男性更关注“酷”、“机能”、“庄重”，而女性可能更关注“漂亮”、“典雅”、“轻便”，所以同样是小型随身物件的收纳容器，功能上并没有区别，男款和女款包的差异会很大。
我使用过的APP中，印象很深的两个比较讨巧的情感设计是B站和即刻。B站是ACG社区，用户基本都是二刺螈，B站的虚拟形象是22和33，两个二次元萌妹子。在B站APP登录界面，放置着22和33，萌萌地看着你，有意思的是，当你点击密码输入框的时候，22和33会用双手捂住眼睛，好像他们知道你在输密码，所以主动不看。简单的一个“机关”，就很有趣味。而如果同样的逻辑，放在一个很正经的政务APP上，就会显得mdzz。根本原因是B站本身确实有这样的认同感偏向，而后者没有，就会弄巧成拙。
即刻APP，它的slogan是“看点好玩的”，用户都比较有趣（傻逼网友笑死我了），它的点赞功能有一个有趣的反馈。如果你发布了一条状态，然后给自己点赞，或者点赞后取消给自己的点赞时，APP都会通过Toast提示机制，弹一个非常贱的嘲讽的表情给你。对于这个APP的用户，大家会觉得有意思，但如果是别的类似的APP，可能有的用户就会不知所云甚至觉得非常奇怪。
还有很多APP里都会有一些小彩蛋，有没有这些东西，完全不会影响产品的功能，但如果这些情感交互用得恰到好处，会给产品增色不少，甚至用户会觉得，牛逼，有情怀，这个产品经理懂我。当然，关键就是巧妙，用得好是画龙点睛，用得不好就很尴尬了。

文档撰写

很多初学的产品经理会觉得不会写PRD什么的，但我反而觉得写文档是产品经理工作中，最轻松的一个事情。不会写，其实是因为没有想清楚，而没有想清楚的时候，就翻翻上面的东西，想清楚再下笔。
产品经理工作中，最常写的几个材料是，MRD（商业需求文档）、PRD（产品需求文档）、产品图示。MRD是用来说明该产品在市场上具备什么价值，模式如何，怎么转得通，PRD用来说明产品功能是什么，该如何实现，期望目标，产品图示以图形的方式说明产品功能、架构、界面。最后一个我刚开始写的是原型图，后来改为了产品图示，是因为，很多产品都需要以图形的方式来表达，但使用图形表达的关键点会有不同。图形不一定指界面，也可能是结构，也可能是流程。比如你要做的产品是一个推荐系统，这个系统压根就没有前端，没有界面，用户不需要直接看到它，那我们并不需要画原型图，应该画的反而可能是系统架构设计图和算法原理图。而如果做的产品是一个移动app，可能需要直接画出高保真原型图，因为用户体验很关键，而用户体验与前端交互表达密切相关，所以并不能无脑丢给UI/UE的同学去做。而你如果做的是一款拼装模型，在设计阶段，不仅要设计好外观，图示中更需要表达的是，玩具的组装过程。
不止是图示在不同类型的产品上会有不同关键内容的表达，文档也一样。
这里我们把这些材料（就姑且称为文档）也看作产品来进行分析。这些文档的用户可能是你的大佬，可能是开发和设计同学，解决的问题是向读者表达你对产品的设想，并期望以此为蓝图进行设计和实现。场景可能是现场讲解和实现时参照。面对这些不同的场景和需要解决的问题，文档的写法当然不是一成不变的，要看读者是谁，想表达什么。
所以我才说，写文档其实是最轻松的事情，它不应该拘泥于严格的格式，只要能向读者清楚地表达想要表达的意思，它就是一个好文档。你看，做产品之后，会发现设计的美妙，想清楚读者和表义，然后来设计这个文档。
至于格式，不强求，但是如果说文档的结构、描述、版式也能同时做到较高的规范性，文档会更容易被不同的人阅读和理解（合适的格式，在阅读时结构更清晰），更容易在不同的时间阅读和理解（标准规范的描述减小因时间和记忆带来的理解误差），更少出现“只有你自己读得懂，别人都读不懂”和“过一段时间之后看不懂自己写的文档”的情况。

数据分析

前面讲过数据驱动的思维，基本上涵盖了对数据运用的完整方法，这里不再多讲，重点关注产品设计和迭代过程中的数据分析。
通过对数据的分析，能够知道产品的“功能”和“性能”是否正常。功能是否正常指的是某个功能是否正常运行，性能指的是功能运行结果的质量是不是达标。运用合理的数据指标可以衡量功能和性能，比如某个功能的使用频次可以反映用户对该功能的需求强烈程度，比如单位时间可提交表单的最大数量可以反应服务性能，用户使用该产品前后做某件事所用的时间变化可以反映产品的效率提升，用ABtest方式测试得到的结果可以反映产品的增量价值。
数据分析的核心其实是发现明显的差异性，理想和现实的指标差异，A和B的指标差异，有和无的指标差异，等等，建立数据指标并建立合适的数据指标预期，就可以更容易找到产品和规划的差距并着手改进。
为了监测产品的数据，做产品数据指标的分析，我们甚至会简单做一个产品，用来实时监控这些数据指标，通常我们把它叫作dashboard，仪表盘，呈现比较及时的产品关键指标数据。所以，做产品设计和开发，除了主线的产品核心功能，别忘了对产品的监测也是需要设计和开发的一部分。在商业产品的相关工作中，更是有BI（Business Intelligence，商业智能）的概念，商业智能提供使企业迅速分析数据的方法和工具，以体现并实现商业价值。比如超市会关注每天分小时的人流数据和销售数据，关注成交量，成交额等等。很多公司都会有专门的BI部门，就是专门分析商业数据，同样在做商业产品的时候，也要具备BI的思维，甚至在一定状态下，需要开发BI相关的分析工具来更好地进行商业数据分析。

产品运营

产品运营的作用是链接用户和产品，使得用户的使用过程和产品给用户带来的收益形成正循环，让用户用得爽，让产品活得好更久，尽可能放大产品的覆盖面和生命周期。产品运营使得用户和产品发生关系并持续发生关系（???）。前者的表现是用户越来越多，后者的表现是用户活跃度的保持和提升。在toB类型的公司，商业产品的运营，不只是对用户使用负责，还可能需要对业务负责，即，期望通过用户正确的使用和正循环的过程，带来业务增长。业务增长的动因，可能是单纯的流量质和量增加，也可能是用户在使用产品的过程中，效率/质量更高而带来更高质量的产出。
而为了能够有效地链接产品和用户，产品运营工作之前，需要了解并对产品功能和用户需求非常熟悉，如此才能够知道，产品需要的用户长什么样子（明确用户画像），用户对产品的认知（确定产品的用户侧表达），才能做好对内推进产品迭代，对外推进拉新促活。
运营的英文是operation，操作，运作。在不同的产品，不同的产品阶段，都有可能有不同的工作，但核心都是，让产品能用起来。运营是一个持续性的工作，如果一直重复，那就没啥意思了，无论是对于个人成长还是价值发挥，都没啥意思。有意思的是，要在运营过程中形成方法论，明确在什么情况下，如何合理地使用产品功能来达到最佳效果，沉淀方法论，才能在不同的产品，在产品的不同阶段，知道该使用什么样的方法，提升用户使用质和量，并加速产品迭代。比如，产品刚上线阶段，对于小白用户，最需要的是产品培训，可以通过手把手教学，视频指导等方式，让用户快速掌握使用方法并上手；而在中期大量扩张阶段，通过各种优惠活动拉取更多新用户，是最重要的事情，面对何种用户，该用什么样的方式吸引他使用，如何进行营销表达，吸引潜在用户主动关注和获取产品；在后期如何通过运营活动提升用户活跃度，等等，如果能够形成体系化的方法，运营工作将会更加游刃有余。
同样，在进行运营活动时，也需要进行数据分析，构建运营指标体系，用来衡量用户数量、质量、来源和去向、各环节转化率、甚至细节的用户画像等等，通过这些指标来衡量运营质量，并及时发现和解决运营问题。
另外，做运营工作，一定要直接接触用户，但同时不能把自己变成一个用户，产品运营应该是介于供求方之间的角色，在toB型的业务中，需要做好用户价值和商业价值的平衡，高用户价值就意味着更高的投入，而高商业价值又期望更少的投入，在保证不损害用户利益的情况下，做商业价值最大化。
运营方法方面，先前有提到漏斗模型和反漏斗模型，建议以这两种模型去看待运营工作，找到漏斗的关键节点，并施加以影响，对提升运营效率很有价值。

决策

决策是做选择，寻找一个想像中成功概率最高，后悔概率最低的可选方案。由于资源有限，我们经常会面临选择难题。
既然是做选择，那一定会有机会成本，一定会有代价，一定会有责任，同样应该有权力调动资源，也有权利享受决策成果。在决策者身上，责任/权力/利益应该是同时具备的。
很多事情，作为旁观者可能觉得卧槽为什么做这种决定，但对于承担责任的决策者来说，他的选择是在考虑到多种结果的情况下做出的，思路与旁观者可能完全不同。所以，日常不要做一个键盘侠，瞎jb喷别人的决策，当别人来寻求建议时，最好也不要直接帮别人做决定，而是帮对方列出可能的结果，提供更多的周边参考信息，引导担责者本人自己做出合理决策，反正一般别人来问我，期望我给些建议的时候，我都是这么做的。
要知道如何做决策，首先要明白决策是需要承担责任，对选择的结果负责，出了锅就是你来背。一个经验比较丰富的人，决策的失误可能会小一些，但作为新人，不应该由于惧怕承担责任而不去做决策。这是前提，即作为决策者需要明白权力/责任的统一性，做决策之后，损失需要承担，成果需要享有。
按照我们之前在思维部分讲过的，通过归纳演绎，推演出可能的结果，然后对结果进行量化衡量，以比较多种决策选择之间，哪个成功概率最高，损失最小。这里的核心是对可能结果的价值考察，要考虑短期价值和长期价值，要考虑模块本身的变化，也要考虑对系统其他模块的影响。
从决策实施过程来看，有一个比较直观的办法，可以用表格的方式，将这几种选择一一列出，然后再把对这几种决策的衡量维度和权重列出，形成一个选择x衡量维度的矩阵，对各项一一进行打分，最后便可直观看到哪个选择的分数更高。在衡量方法设计合理的前提下，这种方法直观有效，推荐使用。之前我在换租的时候，看了不少，最后感觉有两个还不错，但这两个却纠结了很久，不知道该选哪个。后来决定，从地理位置、小区环境、房间面积、房间布局、房间装修、设施配置、价格等因素，对这两个选择进行打分，通过分数高低来判定该选哪个。最后，我比较了这两个的分数，然后。。。并没有做出选择！因为打分之后又细想了下，那个房间的书桌打在了阳台上，还无法拆除，阳台是向南的，那我放在书桌上的东西都会接受阳光曝晒，要这书桌有何用，这书桌对我来说就是废品！于是，也不用看分数了，原则上我不能忍受这个废品设施的存在，所以可以直接pass了。
这里有一个值得注意的地方是，在决策的过程中，除了考虑对过程投入和结果价值的衡量，有一个大前提别忘了，即基本原则。基本原则是具有一票否决权性质的关键因素，在做选择之前，先理清楚，什么东西是不可忍受的，一定要杜绝的，只要一出现就一定不会考虑的。这些基本原则能够直接排除一大票不靠谱的可能性，也约束了决策过程。

项目管理

我老板有句话讲得好，要成事儿，你要学会做一个局。这个局里，有人，有事，有资源，有目标，有关系，有情绪。而这些东西，便是项目管理需要管理的东西，将这些东西之间的连线和顺序理清楚，项目运转便会更加顺畅，说是管理，用“协调”这个词更为准确，通过对不同因素之间进行协调，让项目走得更快。
协调人。人是项目中推进事情发展的因素。在项目中，需要保证所有参与人理解项目内容，参与人需要保证有足够的精力来完成分工指派的任务，保证有足够的能力完成符合质量要求的任务。如果有理解问题，需要进行沟通，如果有精力问题，需要协调精力，如果有能力问题，严重情况下还可能要考虑换人。
协调事。这个事，更多指的是问题。由于项目是多人参与，当出现问题时，难免出现分不清锅甚至是互相甩锅的情况。为了避免这种情况的发生，一开始就要明确责任，出现问题之后，也需要尽快确定谁背锅。而确定谁背锅，并不是为了指着他的鼻子骂他，而是为了立刻推进解决问题。
协调资源。项目所需要的资源，在一开始就明确好，需要哪块提供什么资源。在项目跟进过程中，如果出现资源缺失，需要及时补足。
协调目标。只有上下同欲，为了共同的项目目标工作，才能一起完成一件事，在项目启动之前，需要确定目标，找到和你志同道合的人来完成这件事，所有人都应该认同这个目标，这样不仅能够保证运转过程中大家的方向统一，也能在出现分歧时有目标准绳进行判断。
协调关系。关系最关键，系统思考中提到过，各模块之间的关系，比模块更加重要。比如我把电脑的扬声器去掉，我仍然可以插一个耳机继续听，就算不听，我仍然能完成基本操作，但如果主板没有向外部输出声音的接口，或者说有耳机和音箱，但是不知道怎么和主机连接，那约等于没用。再比如学校给你换个老师，你还能继续上课，但如果是学生来考核老师，那这学校估计要大乱。所以在系统中，在项目中，关系是最核心的存在。互相之间的输入输出和影响方式，上游是什么下游是什么，需要时刻关注，关系顺畅，项目才能正常运转。当解决关系问题时，也要注意其连带影响，避免对其依赖的模块造成负面影响。
协调情绪。人不是冷冰冰的机器，情绪的存在会造成输出结果不稳定，从而影响项目正常运转。所以，作为项目管理人，对成员情绪的关注和管理，不可或缺。这是与单纯做产品不同的点，在推进产品时，大家主要是承担正常的岗位职责，我负责设计，你负责开发，他负责测试，他负责运营，但在项目组中，其实是虚拟的岗位职责，通过目标并不是责任将大家进行聚合，出于个人意愿做事，难免会有情绪问题，因此在项目组中，人的情绪也是需要协调的，甚至应该定期通过沟通/TB等方式来加强积极情绪。万不可理所当然地认为，所有人就都应该做这些事，不想做或者做不好，一定是人的问题。
以上，大家还会发现，项目启动，并不单只是一个状态，还是一个动作，项目启动意味着在目标、所需要的资源、需要做的事，需要参与的人、人员的分工、责任与权力方面，与所有人达成一致并且。而在项目过程中的协调和管理，则是通过持续跟进和迭代，解决这些问题，并朝着项目目标做事。 把这个局布好，项目就成功一半了。

关于业务

成熟业务的产品经理，做产品工作就好。创新业务的商业产品经理，是业务型的产品经理，是小CEO。
刚开公司一段时间，基本是在做内部系统和工具，虽然确实是商业性质的产品，但此阶段主要还是基本的根据用户需求设计相应功能解决问题，而到后来发现，之前做的一些工作，确实能够提升使用效率和效果，但没有办法说清楚，商业角度的价值在哪里，是不是能帮忙赚更多的钱？无论是出于公司的状态和要求，还是个人能力和眼界的变化，都会提出这样的问题，商业产品的本质是什么，商业产品经理最该做的事情又是什么。带着这样的疑问，开始关注“业务”。
到底什么是业务，业务是找到一种可落地的，能够持续赚钱的办法，并将其打造成为一种模式，甚至是一个完整的行业生态。而作为商业产品经理，期望这种模式是基于产品能力构建起来的，所以核心是，探索并形成具有高变现价值的产品能力。注意这是商业产品经理的“产品业务”，如果是其他不需要产品也能构建的业务，负责人可能是其他职能的同学更为合适。另外，也不是意味着其他业务不需要产品，有了产品可能变得更好。比如房产中介业务，没有链家APP也能正常运转，但有了链家APP，效率更高，业务体量更大，（一直在说，业务运转，业务并不是一个状态，也不是一个结果，业务是动态的，有资源、人、事的流转才是业务，是一个持续的过程）。
那么，如何找到这样一种方法，里面几个关键词，可落地，持续，有钱赚。可落地表示这个方法应该是符合公司大方向，并且还可能与其他业务有配合的方法，表示这个方法在现阶段公司状态下能够落地实施，且投入产出比预估为正。持续表示这个方法不是赚快钱，不是赚投机钱，不是一杆子买卖。如果让PM去炒股，那他也肯定在致力于寻找一种预测方法然后让自己不断地能赚到钱，而不是一夜暴富。
有钱赚的问题，是作为商业产品经理，在业务设计中需要考虑的关键问题，当你构建了一种业务模式，付钱的人是谁？付钱的人为什么买单？他为什么选择你而不选择竞品？该付多少钱？这些点，核心都围绕一个关键切入点：你期望构建的产品能力，期望形成的业务模式，解决了什么样的客户问题。这个问题，要么别人解决不了，要么别人解决得不好，要么别人卖得贵。
最不推荐的是最后一种，因为打价格战的最后结果只能是薄利多销，同类型产品都逐步趋近于合理市场定价，毫无利润可言。所以如果你在做市场调研的时候已经发现需求被满足，而且价格也合理，那就不建议继续做了，除非它对于全局还有别的战略意义。比如国内的手机厂商，大部分都不具备什么核心能力，定价相对较低，一旦出现价格屠夫，行业一片哀嚎。甚至有人把小米比作是行业搅屎棍，小米要切入什么行业，那个行业的平均价格都会下降到快趋近于成本。但对于小米自己来说，它可不是自己的搅屎棍，它就愿意把产品卖到接近成本价，但它还再卖，因为即使这部分赚不了什么钱，对于小米整个生态的布局也有关键性的作用，手机是超级入口，还是智能设备的中心，所以它还是要做。
第一种，别人解决不了的问题，但你能解决，也不太现实，凭什么别人一直解决不了，就你突然就解决了。《我不是药神》中的格列宁的制药公司，是一个“别人搞不定但我能搞得定”的例子，所以它具有这个市场的定价权，如果完全按市场经济，想定多少就定多少。当然，为了解决这个问题，前期也投入了大量的研发成本，对于别的企业来说可能是天文数字，这便是代价。
这个时代，创业团队风起云涌，见缝插针，各行各业的各问题，有一些是限于基础科学和前沿技术瓶颈，非常难解决，剩下的基本都已经被解决或者在解决了。我们所构建的业务模式，更多还是对现有解决方案的改良，通过一种成本更低的方式，做到了更好的效果，便有了相应的商业价值。做改良，收益会更可控，风险更小一些。现在经常在洗脑广告里听到的“没有中间商赚差价”，它并没有完全改变某种交易方式，只是改良了信息传递过程，便能够立有一席之地，而且风生水起。探索业务模式，不妨从“对现有流程进行改良和加强，以形成一种新的更好的模式”的思路出发。
搞业务，一定不能封闭，商业是有来有往的，闷头搞一定是死路。业务本身，存在于生态里。就像自然界有生态系统，里面会有捕食关系，共生关系，寄生关系，这个生态系统才能形成循环，在一个业务模式里，有上下游（上游是供应方，下游是被服务方），有竞品，有友商，才能持续运转。当然，竞品有可能不存在，供应方有可能是自己。上下游有依赖关系，竞品有竞争关系，友商有合作关系，找清楚自己在整个生态中的位置和角色，加强合作，稳定依赖，减小竞争，便可使业务更加润滑。（本质上这就是用系统思维在进行分析，明确模块和关系，所以你看系统思考极其关键）
那么问题来了，在toB场景下，怎么搞定客户？关键在于合作共赢。与客户之间进行业务交易，并不是简单的我把包子卖给你，我失去了包子而得到钱，你失去了钱而获得饱腹感。这是因为toB场景下，客户本身也有自己的商业模式，对于客户和我们两方来看，并不是零和博弈，因为还有第三方实际承担成本（那就是我们这些屁民啦）。所以，在这样的状态下，双方最理想的合作模式，是我赚钱，你因为用了我的产品也能赚更多钱。相应地，在设计业务模式之前，需要搞清楚，你服务的客户，是怎么赚钱的，对方是什么样的业务模式。通过双方的合作，对方的业务能转得更顺更好，那这事儿就成了。所以，搞定客户的核心，简单点说，就是要了解客户的痛点，而了解客户的痛点，就需要了解其业务运作模式，然后以双方业务都能转得通，整个生态能转得通为方向去做。
另外，再说一点。产品经理，即使是纯用户产品经理，不参与业务能力构建和相关跟进，也有必要了解和熟悉公司的各项业务，自己的需求挖掘和产品设计、运营等，都需要符合业务规划，才是满足公司要求的产品。

关于AI

这几年，人工智能很火。凡事只要和AI挂钩，就觉得突然变得很屌，甚至有时觉得AI可以解决现在解决不了的任何问题，还会有人觉得AI就是替代人的工作，AI如果能像人一样处理问题，就是牛逼的AI产品。虽然说在某些需要拟人的场景下，越像人的AI越牛逼（比如陪聊机器人），但大部分情况下，AI像人没卵用，能以投入产出比较高的方式来解决问题才牛逼。核心还是看需求和解决问题。
人工智能是人工创造的智能，而不是类人智能。人工智能产生的原因是，人们希望通过机器的能力，增强人类改造世界时的边界和效率，本质上，人工智能也是人类的工具。与一把锤子，一辆汽车不同的是，人工智能这个工具在经过设计之后，能够自主感知，学习，输出，还可能变得越来越牛逼。
各种影视作品里描写的AI，比如《2001太空奥德赛》中因为不承认自己的计算错误不想被人发现错误而杀死人的HAL9000，比如钢铁侠里变成Ultron的Jarvis，以及《终结者》系列里的天网，都是人类创造出的AI，最终毁天灭地。甚至这几年，出现了很多警惕人工智能的言论，谈AI色变。确实，电影也不是瞎jb拍的，如果人类太浪，让机器有了自我意识，并且在非意识层面（效率/能力）还强过人，确实有可能会打得人类生活不能自理。但现阶段，远没到如此程度，AI只是在某些垂直领域，尤其是规则性比较强的领域，由于其结构化的计算性能强过人类，会在不断的学习后，超过人类。比如之前的DeepMind，AlphaGo等等，也只能在棋类游戏，电子游戏等具有明确规则，且胜负相对容易衡量的竞技中，胜过人类。但在相对复杂一些的翻译，语音交互场景中，人工智能都经常会变成人工智障。
现在应该担心的，根本不是AI有一天会当家作主的问题（这个问题如果上升到哲学层面，是有研究价值的，比如AI是不是生物，人类是不是本来就是进化到AI中间的一个阶梯，意识是什么，机器会不会有意识之类的，也是很有趣的话题，但不在本文讨论范围内啦），目前来看，AI话题里，应该关注的问题，反而应该是两个：一是互联网内All in AI 、AI first的怪风气；二是探索AI的实用场景并真正发挥其价值。
第一个问题，All in AI的，一看就知道是百度。百度All in AI 是否正确，我一个小屁员工就不评论了，但现在确实业内，尤其是创业圈子里，就像之前某一阵子O2O特别火一样，这一两年，啥事儿都想扯个AI，感觉拉上人工智能这个助攻，就能马上骗到投资。甚至有不少人，把人工智能理解为自动化，用机器代替人的工作，媒体也大肆报道什么自动写新闻的机器人，其实很不负责，会引导普通读者以为牛逼的AI就是像人一样，完成人类在做的工作，还担心会不会抢人类的饭碗啥的。这种风险是存在的，但被过度解读了。AI仍然是人类的工具，人创造AI，本质是希望基于大数据和对大数据的处理能力，通过高于人脑的计算力，用更短的时间，更科学的方法，来得出人工判断极难或者根本无法处理的问题，甚至输出更多“灵感”，而不是要替代人，即使有替代人的例子，那也是解决部分人工低效的问题。
人们和媒体担心的，抢人类饭碗的问题，更多是因为一些工作，重复劳动就能带来成就感和相应的报酬，而机器以更高效的方式完成这些工作，导致他们丧失了简单方式赚钱的机会，让他们被迫跳出舒适区（关于舒适区）。我不是隔岸观火，虽然暂时看来产品经理是AI的设计者，还不太可能被AI替代，但说不定就有一天真的出现了一个AIPM，抢我的饭碗。我也会有这样的担心，但不应该因为这样的担心而反对AI，而应该想，在AI时代，我们又该做什么价值更高的事情？
就像是马车时代，车夫活得美滋滋，突然有一天汽车出现了，人们发现汽车更快更舒适，一大批马车车夫都会失业。作为一个车夫，他肯定会抵触汽车，让他丢了工作，汽车是可怕的，应该禁止汽车销售，要不我就要失业了，而且你看，汽车你一踩油门就会跑，肯定很不安全，把你带沟里去，太可怕了太可怕了。但纵观历史全局看，你肯定明显会觉得，汽车的出现极大地方便了人们的出行。而且，作为旁观者，你可能还会劝车夫，既然有了汽车，何不顺势而为，放弃马车车夫工作，转职成为一名老司机？对吧，AI时代的道理也是一样的，唯一的区别是，需要抱有对AI产生自我意识的思考，然后各回各家各找各妈就可以了。 　　
总之，别太浮躁，AI不可怕，AI很厉害，但AI也不是万金油，安心做产品就好。
第二个问题，如何让AI真正发挥其价值。我们在之前已经说到了，AI本质是基于大数据和对大数据的处理能力，通过高于人脑的计算力，用更短的时间和更科学的方法来解决人工效率低或者根本无法解决的问题。那对于其高价值应用场景，就要考虑，哪些问题现在人工解决费时费力，或者根本无从下手的。最容易想到的就是智能的推荐系统，AI去猜你喜欢什么，然后给你推荐相应的内容。像头条的资讯推荐，网易云的私人FM什么的，（先不考虑现在的推荐机制确实有可能会造成风格越来越窄的缺陷）就是不错的应用。再比如翻译，最近几家公司都推出了境外旅行用的即时翻译机，通过AI加持，而不是简单的映射，能够让翻译结果更加符合场景表达，更顺畅和易懂。之前吹上天的阿里鲁班，自动设计广告的AI，其实也是解决，在商品和用户购买需求越来越丰富、细化、个性化的趋势下，如何“对每一个人做设计，做出更吸引用户的广告banner”，并且据我了解到，在机器完成设计之前，图层啊，布局啊什么的，关于设计理念和方法层面的信息，还是需要人工输入的。所以你看，它并没有完全替代人，它只是替代人完成了“根据每个人的喜好，给他做他可能会喜欢的广告”的过程，而相应的，人反而有更多的精力去做更上层更有价值的事情，比如研究设计方法。
这也是在AI解决问题过程中需要注意的点，第一是AI结合人的经验能够更快地完成能力构建，第二是AI与人应是配合关系而不是替代或者对立关系，第三是本质上AI解决计算能力问题。在三个基本原则基础上，发挥PM的核心价值，去判断什么是需求，什么又是AI产品需求，要用AI来解决什么问题，用AI来解决问题，是不是投入产出比是高的，这才是正经的做AI的路（做AI，嗯？）。

本节资料推荐

• 书籍《精益创业》、《增长黑客》
• 书籍《商业模式新生代》，制作精美，图示明确，有方法有案例，就是没有电子版，然后实体书有点贵
• 各种互联网公司传记，可以看看腾讯的《腾讯传》和红衣教主的《颠覆者：周鸿祎自传》，重点看他们在关键问题上如何做选择的

关于习惯

这些习惯看起来和产品能力没什么关系，不太会影响做事，但会影响成长速度。今时不同往日，尤其是在互联网行业，不是不进则退，而是不进则死。虽然我也才毕业三年，但看着那些刚毕业来实习的小屁孩（好吧我也算个小屁孩），能力和经历比当时的我都要强很多。互联网是年轻人的天下，趋势不可避免，每个人的成长都如此之外，说不定某天就被新人超越了。虽然这几年也在积累经验，但是这些经验不足以在能力沉淀上，有同样的增速。所以，有良好的习惯，不断迭代自己的方法和能力，才能保持进步。

探索

产品经理应该对事物有强烈的好奇心和探索欲。写的时候随手搜了下探索欲这个词，发现结果满是亲子相关的内容，有点迷啊，难道说，探索欲已经成了小屁孩的专属了吗！
探索欲和好奇心是学习的前提，学习是发现未知的东西并将它变为已知，如果希望自己更快地成长，需要具备提问的意识。
有次，去咖啡厅买奶茶，买完付款后，服务员小姐姐说加公众号盖章3次可以换一个满减优惠券。那我就很好奇，为什么要加公众号盖章啊，啥意思啊，没见过啊。然后就见小姐姐从小纸盒里拿出一个印章，我加了公众号之后，她在手机屏幕上用印章盖了一下，卧槽？真的有反应，真的盖了一个章，网页里显示了相应的图案，这怎么做到的，为什么我用手指随便戳就不会盖章呢？我第一作为工科生，第二作为营销行业的商业产品经理，我这就不能忍了，我一定要弄清楚，这玩意儿是咋玩的。
我首先想到的是，现在智能手机本来就是多点触控，那个印章上肯定有什么特殊的纹理和图案，按到手机上时，就像人用好几根手指同时触摸，这个唯一图案能够被识别为印章图案，然后就印上了。回到电脑前，马上搜了下相关的技术，发现原理确实如此，有个公司专门做这个，还将它做成了实体的手游道具，买了之后印一下，就可以在游戏中获得相应的虚拟道具。卧槽真会玩，真是基于移动设备做互动营销的一个有趣的玩法，想想应该也算一种AR（增强现实）了吧，以后说不定写什么PPT的时候就可以拿出来吹牛逼了。
在探索的过程中，可以在内心提三个问题，这是什么，这是用来做什么的，为什么它是这个样子。第一个问题是定义，第二个问题是场景，第三个问题是设计。相信几乎所有人坐飞机都会有疑问，为什么飞机需要窗户，为什么窗户是圆的。我们用前面三个问题来套一下，第一个问题就很简单了，第二个问题，万里高空，又不能开窗户，要窗户干啥？虽然不能开窗户，但有窗户可以欣赏外面的风景，而且可以缓解幽闭空间的不适感。第三个问题，为什么窗户都是圆的？上网搜索一下之后发现，原来，很久之前其实窗户是有方形的，但出了几次事故，因为边角受力不均匀而导致窗户开裂，后来就设计为圆形以分散受力，增强结构稳定性。你看，每个细节，其实都有设计理念在里面，通过增加窗户来缓解心理压力，通过对窗户的形状设计来增加稳定性，获得安全保障。
前文中提过，我不建议积累经验，而建议积累能力。而这就是积累能力的第一小步，去主动探索和思考，不用做什么实际工作，就好奇一下别人为什么要以那样的方式去设计一个东西，然后尝试自己想一想，再去找到正确答案想一想，这一个过程下来，收获已然远大于工作经验。
像一个小屁孩一样，充满好奇地去鼓捣乱七八糟吧！

学习

快速将发现的别人具备的优势或者更上层的思考转化为自己的能力和思维方式。 学习不是接受，学习是认同并理解。
我认为，学习是一种能力，也就是说，不是所有人都会学习。学习的能力并不是掌握具体的知识和技能，而是具备去掌握知识和技能的动机、思路、方法。耶鲁大学的前校长理查德.莱文曾经说过一句话：如果一个学生从耶鲁大学毕业之后居然掌握了某种很专业的知识和技能，那是耶鲁教育的失败。这位校长非常明白，通过大学获得的，应该是探索的勇气和学习的能力。
高中的时候，讲道理，我应该算是个学神，就是那种，平时不怎么认真学习，班里最调皮捣蛋的同学，要不就是上课偷偷看MP4，要不就是一放假立马带同学冲去网吧，考试还能提前交卷，分数出来后还基本是全校前五的那种。我不要脸地自吹一波，我认为，在那个时候，我比其他人做的好的，看的清的一点是，先学会如何去学习。当别人都已经开始撸起袖子刷题，记笔记，整理错题本，每天早起背单词的时候，我还在发呆。
我发呆的时候在想，怎么样我就能理解这些知识，怎么样我就能知道其中的原理，知道它的运作方式，因为只要了解了本质和原理，不管这个题怎么变，怎么出，用正确的思考方式，肯定能解出来。可能有想了好几天，才想清楚这个问题。为了保证我在看书做题思考的时候，能真的理解其中的原理（比如数学里为什么要用这样的证明方式，比如物理里为什么质能方程是这样的，比如化学里为什么这两种物质的反应是以这种方式进行，等等）我给自己列了几个点：

• 解题之前，解完题之后，都要想一遍，这种解法的思路是什么样的，为什么要用这种方式去想问题，要自己推演一遍
• 做错的题，去看正确答案和自己的思路差异在哪里，不行啊好丢人，居然没解出来，这正确答案的解题方法太low了，就算我第一次没答对，那我也要再想一种更牛逼的解题思路，面子不能丢
• 课本上的定理，公式，我要像老师给同学们讲题一样，自己写板书，模拟讲课，自己推导一遍，这样即使考试时忘了公式，也能自己推导出来，真牛逼
• 不局限于课本，如果原理搞不太懂的地方，要和老师撕逼，要不就看看别的相关书籍，做到研读而不是记忆

我还真就这么做了。别人的错题集累了好几本，试卷刷了一套又一套，但是我桌子上最多的东西，是草稿纸，还有一摞《Newton科学世界》杂志和一本《时间简史》。草稿上都是各种证明，各种箭头，各种随意写的字，记录了思考的过程。而这两本课外书籍，本来就爱看，其中很多内容已经转化为了自己的知识。我特别喜欢《科学世界》这本杂志，当时一本12块，真jb贵，但还是每期必买，全彩印刷，用非常明确而且特别好懂的大图解释一些科学原理。
以至于后来忍不了了，觉得课本里讲的太无聊了，想装逼，于是借着杂志里的内容，主动和老师说想用自己的理解给大家讲一遍。正好某些原理确实也晦涩难懂，老师觉得换种思路让大家理解下也好，在同学和老师的注视之下，在黑板上自己写写画画，给大家讲了一遍，完成了推导。
这些过程，让我对考察的知识点有非常深入的理解，甚至自己变成了老师，变成了课本编写人（其实这里也可以发现，我做的是产品的事，Architect的事，主动创造的事，而不是一个纯user的事，不是被动接受的事）。而其他人，更多做的事情，是努力去接受，努力去消化，努力去记忆，我觉得这并不是学习，是在做存储。在这种情况下，除非存储性能极强，比如一些学霸，人家就是能记住，考试就是会，那没办法。但在其他情况下，我都觉得，只有先学会了学习课本知识和答题的方法，然后再学习课本知识和答卷子，是一个更优的方法，而且，获得的知识和技能的体量，远大于被动接受。
我想，现实生活中，应该有很多人，并不会意识到，学习是需要方法的，当相应的目标被制定，或者任务被下达之后，直接反应马上是，我要尽快了解并接受并获取这些知识和技能，而不是我要想一下以什么样的方法，才能够更合理更正确地接受这些知识和技能。古话说得好，工欲善其事，必先利其器。器即工具的意思，但不应该将工具狭义地理解为方便我做事的某个实体，一把锤子，一个好用的电脑，而是，能够辅助我，让我做事做得更好更快的任何东西。在这里，事即学习，而器即是学习的方法。
在学习的过程中，还有一点值得注意，学习需要保持独立思考的能力，它并不是复制，而且将别人的观点进行分析之后，能够形成适合自己的观点。

迭代

迭代是重复反馈过程的活动，其目的通常是为了逼近所需目标或结果。每一次对过程的重复称为一次“迭代”，而每一次迭代得到的结果会作为下一次迭代的初始值。与迭代相对应的是直接/一步到位，能力构建本来就是一个不断上升的过程，不可能一步到位，所以，通过自身review和不断迭代来进行能力提升，在时间和经验积累之下就显得尤为重要。
在前面系统思考部分的内容中有提到过，反馈是系统中一个非常奇妙的机制，反馈可以调节系统输入，导致输出产生变化。反馈和迭代是个人能力成长的必备也是根本机制。
大学里学过《自动控制原理》的同学可能还记得，在系统末尾输出端，将信息返回到输入端，并改变输入，以影响系统功能的结构。合理的负反馈能够保证系统动态平衡（比如生态系统平衡），而一定的正反馈能够起到与输入同向的相似作用，使得系统偏差不断增大，进而在结果上起到放大作用。我们期望的就是，用合理的负反馈接到输入端，让输出更加稳定，少踩些坑，用合理的正反馈接到输入端，让输出具有放大作用。
能够收集到反馈并进行迭代非常重要。就像产品会有alpha，beta，正式版，2.0，3.0等等，在不断测试验证，收集反馈和升级的过程中，产品会变得越来越好用和强大。正如产品会做用户调研，个人能力成长也需要类似的迭代过程。你可以对你自己这个“产品”进行用户调研，比如问问周边同事/上级/下级对你的看法如何，别人眼中你的优缺点等等，还可以日常整理自己在思考和工作中的神级操作和智障操作。从人和事的角度收集正反馈和负反馈，并以这些反馈作为自身迭代的输入，将优点放大，将缺点抵消以便前进过程中更加稳定，让神操作越来越多，智障操作越来越少。在此过程中，不宜过于放大负反馈，比如过于重视别人的负面评价和之前自己工作中的失误，认为自己一无是处，那就翻车了。同样，正反馈过大也会导致另一个方向上的翻车。
迭代一定要有反馈输入，否则会像闭关锁国一样，你能说那个时期国内没有进步么，也并不是。但那都是瞎jb迭代，已经与世界脱轨，当外部事物突然涌进来时，原先那套早就不适用，观念和生活方式都会受到极大冲击，所以也不太建议以某一本书，某一个看过的发展路线作为参考标准去封闭地 进步和成长，没有外界的真实输入，后果是可怕的。（什么我大清已经亡了？？？）
实际工作中，建议形成对自身能力/优缺点/工作失误和成就的记录，比如写在笔记本上，或者画在脑图中，定期review这些关键点，作为反馈，调节接下来新的工作的方法和思路，不断重复这个过程，然后就可以成为一个大佬。
嗯，其实简单点说，反省可以进步。

关于理念

就像开头提到的，这部分会比较玄学，更加脱离实际工作中的技能和方法，是偏观念和原则方面的解释，虽然比较虚，但层面也更高，如果能够在思考过程中代入，可运用的场景也会更多。

思考优先

行动之前先思考。思考的内容是，行动的目标，行动的关键点，行动需要解决的问题，行动的路径和方法。做什么事，什么时候做，也是基于价值判断，所以经常会强调重要性和优先级。如果自己无法判断，则需要引入其他人做评审，即思考过程不一定是独立的个人的，可以是多人的合作的。
思考优先，从另一个点来说，留出review思考的时间。可能每天工作都很忙，但每天工作不能满，在时间安排上留出思考时间，至少10%，用于回顾工作/思考未知和已知问题/思考现象和结论。直观上看来，我花10%的时间做点实事，总是比花10%的时间坐在座位上干瞪眼发呆更有用，但其实思考的投入产出比更高，不应本末倒置。建议各位在做每天的工作和时间规划时，从意识上，将思考问题的时间作为一项专门的活动列在规划中，并且时刻关注思考的产出质量。

学院派与野路子

接上一个话题。之前讲了很多理论的东西，来说明在思考阶段，以何种方式进行思考是更优的，但我们常常陷于一些矛盾当中，有些事情可能需要很长时间才能想清楚，但想清楚的时候已经错过了最佳时机，甚至有些事情，马上就要去做，但还没有想清楚。这些冲突，以我的个人经历，通常出现在新机会出现的时候。可能你看到了一个市场的新机会，一个趋势，一个可能让猪飞起来的风口，想看看有什么切入点。但毕竟资源/能力/精力有限，对投入产出的衡量，以及对新事物探索的谨慎，会按正常套路调研需求，调研市场，但极有可能，等你想明白的时候，风口已经过去了，或者别人已经率先飞起来，占领了市场。
的确，产品经理不是一个投机者，我们强调判断，我们讲究逻辑，在做事上，这是非常好的习惯。但现实的问题是，机会稍纵即逝，如果等想清楚的时候再进行介入，黄花菜都凉了。在这种状态下，应该从产品经理的工作方式中跳出来去思考，选择“野路子”而不是“学院派”做法，先切入，甚至开始构建基本能力，然后再考虑迭代。但这并不意味着是先做事，后思考。在准备切入时，并不违背产品思考的基本逻辑，仍然要进行完整的判断，判断这个机会与工作主线是不是相关，判断它将来可能生长能力，判断是否有可能形成正循环，然后快速切入，过程中再不断迭代。
另外还有一个取巧的做法，就是如果很确定这个方向值得搞，这个新机会一定要切，那初始可以着手构建分化性（自己下的定义，就像干细胞在生长之后分化为不同类型的身体机能细胞一样）比较弱的底层基本能力风险低，在中后期，市场环境摸得比较清楚的时候，前期构建的底层能力可以通过迭代快速分化，并适配前端需求。
关于学院派和野路子的争论，在老板和下属，在产品思路和销售思路的职能上，总是会出现很多类似的争论，虽然是争论，但并不是冲突。我在工作中也遇到过不少相关的问题，也曾经纠结过。其实所有的纠结，都是因为还没有想的很透彻。但有些事，永远无法想得很透彻，而且有些事，不允许我们想清楚之后再做决策，我认为，只要保证大方向没问题，且能够与团队其他成员在项目规划上形成一致，便可以开始，剩下的“纠错”工作，放在迭代过程中进行，而正因为需要后续迭代，所以初始落地的产品建设，就要做成“可迭代”的。保持产品思考，在保证方向正确和认同的前提下，做可迭代的切入，这便是我在遇到“学院派”和“野路子”争论时，做选择的思路。

主动介入

产品经理是事儿逼，是杠精，是六道杠大队长。PM通过产品满足需求，本质上是解决问题，哪里有问题，就应该有PM存在，所以，一个事儿逼产品经理，是一个尽责的产品经理，这些事，比如流程改良，比如产品bug，比如表达优化，比如格式，等等。作为商业产品经理更是如此，杠点可能就是商机，即客户愿意为之买单的东西。在与客户/用户沟通中，有的时候，他们直接表达的目标并不是最重要的，反而需要重点关注，在实现目标的过程中，碰到了什么样的麻烦，anyone, anywhere, anytime, 主动介入并解决问题都有可能导致效益提升，从而产生价值。而这些点，可能正是决定，客户会选择你，而不是其他的竞品公司，客户会选择为这个掏钱，而不是其他。于是，在主动介入并发现有高价值的需要解决的问题之后，逐步构建低成本高质量解决该问题的能力，便可形成一种业务模式。

竭尽求援

产品经理不可能一个人完成。正如上面所说，产品经理是事儿逼。在推进项目的过程中，当遇到不应该由产品经理解决的事情的时候（注意是不应该，而不是不能，产品经理可能具备全栈能力，但并不代表产品经理应该做这些事，在一个高效能的项目组内，应该是高度分工协同的，所以不是产品能做就要做，产品经理应该找到适合的人或者机制，通过最好的方式来解决问题，而不是所有事情都亲力亲为），要明确是不是项目组内其他人或者事的问题，自己是否能推动解决。如果自己无法推动，作为一名合格的杠精，一定要找领导、找同事，杠一杠。寻找一切能够帮助解决问题的合理方式，运用一切可以用到的外部援助，解决项目问题。
其实我认为这才是狼性的体现，并不是一个人单打独斗，竭尽个人全力，而是在碰到自己无法或者不适合解决的问题时，能够合理利用身边一切有助于达成目标的资源和能力，并有勇气和技巧，运用这些外部的资源和能力来完成一件事，这才是狼性。

万物皆产品

把世界上一切需要与人交互的经过设计的物件，都看作产品，一辆山地车是一个产品，一部电影是一个产品，一碗面是一个产品。产品可以用它具备的属性/功能/构成/输入输出等基本点概括，并且是经过设计的，具备某种功能，用来满足特定的需要，解决特定的问题。
在日常生活中，PM不该停留在user的层面，可以尝试从user和creator两个角色的角度来对产品进行分析。从user使用者的角度，关注该产品是不是好用，是不是能解决问题，从creator的角度分析该产品为了解决问题做了什么样的设计，通过什么原理达成了目标，将生活中的物件视为产品，去研究其设计思路，能够帮助成长。

舒适区突破

这个点，在自我进步过程中，是极为关键的一点，我甚至认为，如果一个人不具备突破舒适区的能力和勇气，那他永远不能获得成功。
讲突破舒适区的事情之前，我想先扯一扯进化论。我特别喜欢进化论的观点，我觉得达尔文简直就是个天才。进化论中有两个关键点，一是基因变异，二是自然选择。
基因变异能够让生物产生新的特征和能力，而变异的方向其实是随机的，发散的，在主观观点看来可能是有益的或者有害的。于是我们会发现，新生生物会发生与其父母辈不同的，千奇百怪的新构造。
这些构造是否对生物有益？变异体A和B，哪个是朝着更优的方向进化？其实不需要任何人来思考这些问题，生物的最本质目标是在环境中生活下去，那自然环境本身，便是生物的负反馈。自然环境不断变化，让变异体A和B可能变得更加难以或者容易在当前环境中生活，于是，在变化的过程中，有些变异体活了下来，有些变异体则死掉了。于是，随机产生的变异经过了自然选择，完成了“优选”。
以种群为单位，在这个过程中，不需要任何主观力量控制，许多个个体发生了变异，并最后生存或者毁灭，自然而然地，就形成了进化，从整体的角度看，无数个这样的变异和选择，得到了一个最优解。表面上的现象就是，生物越来越适应这个环境，完成了进化，产生了适应环境的身体构造。
我们在工作中总是很容易陷进或者说沉迷于目前工作所带来的满足感和成就感，长期处于这样的激励之下，会形成舒适区，认为这样没毛病，没问题，很合理，很愉悦。就像原始人那样，在他们的思维概念中，变异的那些人，就是怪物。我们惧怕改变，因为改变是有风险的，所以宁愿呆在舒适区，永远无法产生“变异”，永远无法“进化”。学生时代，很多人习惯做笔记，不懂的或者错题都要记下来，但却很少去真正理解，期末时满满一本整齐的笔记，上面密密麻麻的标注。因为要记笔记，每天都很忙很累，看起来很刻苦，学到很晚，自己觉得很充实，但最后并不能考得好。我认为这种人本质上是是懒得做更多思考的事情，沉溺于简单摘抄和记录带来的满足感，并且假装这样能学到东西，假装笔记记得越多，成绩就会越来越好，呆在刻苦学习的舒适区内不想出去。
在工作和生活中，很多人都能够意识到，不应该天天打游戏天天看小说天天刷抖音浪费时间（适当地打游戏看小说刷抖音完全没毛病，别喷我），但可能不一定会意识到，某些你已经非常熟练，形成固定规则，重复性的工作，简单输入有简单成就感的工作，其实才是最可怕的。它的问题难以察觉，并且做这些事情还有一些激励反馈，你不会觉得它会像打游戏那样属于低价值低收益的事情，久而久之慢慢习惯于这样简单的付出和收获循环，忘了进步，忘了要走了舒适区。
知乎里曾经看到过的另一个提问，人是怎么废掉的，在此引用其中一个高赞答主（曾加）的回答，看到时觉得简直是振聋发聩：
1、沉溺于轻易获得高成就感（可能是虚拟的）的事情，比如游戏，种马小说，赌博吸毒等
2、只接收低密度信息源，比如不太需要动脑的短视频，娱乐八卦，不愿意接受需要思考，转化，才能吸收的课程，知识等，难以进步
3、习惯用错位成就感来麻痹自己，比如用自己的长处与别人短处比较，从而获得“自己比别人强”的错觉
4、过度依赖既有可行路径，在工作中形成一件事的标准流程之后再也没有想过如何改进，一味机械执行还认为自己很充实，看上去每天都很忙，但实际上没什么进步
5、封闭了强化学习的通道，只愿意执行最简单的第一步，但不能巩固，只看不写，只学不练，就以为自己很有收获。
我们总是因为某些事情麻烦/需要学习和适应/有风险/不确定性，而惧怕改变，永远不去触碰那些觉得可能让自己刺痛的东西，导致一直在做以前做过的事情，沉浸在已经获得过多次但越来越没有意义的基础重复的成就感之中，变成了一只小白兔。而要摆脱小白兔状态，想想自己想要达到的状态，看看同阶段别人在做什么，并主动甚至强迫自己走出舒适区，试探之前没有做过的事情，你会发现比之前有趣一万倍的事情。
著名小说家倪匡曾经说过，人类之所以进步的主要原因是，下一代不听上一代的话。这句话也是非常简单明了地说明了，百分百听妈妈的话，呆在舒适区里，并不是最好的选择，不被打屁股，就很难进步。这句话下面，有人在评论区说，次要原因是，下一代听上一代的话，也没毛病，只有基于前人的经验，在走出舒适区之后，仍然能够记得，之前哪些坑踩过，然后高兴地去踩下一个未知的坑，才能更快进步。
回顾我在第三部分中提到的几个关键的习惯，发现/学习/迭代，配合上面的5条尖锐的描述，食用更佳。

平等沟通

为什么要上升到理念的层次，因为沟通是产品经理工作的基础。产品经理的思维是相对超前的宏观的全面的逻辑的，但因为工作模式的不同，其他岗位的人往往并不能很快理解产品经理思路表达。同时，产品经理因为工作性质的原因，沟通对象很少是产品，反而更多是非产品岗位的同学。于是，在沟通过程中，由于双方理解力和思考方式的不同，总是会不在一个频道上，如此的沟通是不平等的，不可能也不应该要求其他人像产品一样思考（当然如果这整篇都看完并且理解，可能也能像PM一样思考啦）。
而要做到平等沟通，首先要从产品经理的思路中退出来，站在对方的立场，从对方的利益考量和日常工作模式出发，进行沟通。否则，这次谈话，你可能觉得思路非常清晰，自我感觉良好，该讲的都讲了，但可能对方是一脸懵B，然后被迫与你沟通完了。于是，你在不平等状态下获得的信息，也不具有参考性了。
关键，站在对方立场这个事儿，并不是那么容易做到的，如果并不能理解对方的利益出发点和工作模式，那建议放开了聊，就日常互相扯皮先扯个十来分钟，再进入正题。而扯皮的过程中，也有一些小技巧可以用，也是我从培训中学来的，是个不错的方法。就是在前期扯皮的过程中，不代入任何我方观点和思考，像一个观测者一样，只观察，提一些不带有任何观点的问题，引导对方进行表达。
提什么样的问题，就很关键了，也很简单：

• 你希望达成什么事情
• 你要做哪些事情
• 现在遇到了什么问题，打算怎么解决

在扯皮的过程中，不提出任何建议和意见，就反复地，由粗到细地，问这些问题，一边思考，一边专心做一个聆听者。这样，扯完皮之后，你就大概明白，对方的目标和动作，同时心里也有了想法，沟通什么问题，该怎么解决，接下来双方的沟通会顺利很多，解决方案也水到渠成。

正循环

这个词在先前已经多次提到，这里再重点说明一下。在有些情况下，需求方和供给方并没有严格的先后关系，并不是供给方做好了，需求方自然就来了，也不是坐等需求方的需求变化，来改进供给方。实际工作中，我们也经常遇到这样的矛盾，最典型的矛盾就是用户和产品的关系。作为PM，我们总是会想，我要有更多客户/用户，这样我才知道产品该朝什么方向去做迭代优化，也会想，我的产品只有优化好了，才能有更多的客户/用户。是先有用户，还是先有产品，很多时候，都会有这样的纠结。我是照着产品找用户，还是照着用户找产品。
面对这样的纠结，第一点首先要明确，不是先有用户，也不是先有产品，而是先有需求。不管是先找用户，还是先落地产品，围绕的点都是要解决一个问题，这个问题应该是存在的。第二点是，不要抗拒这种“没有先后顺序”的现象，按产品思维可能总是会希望明确，用户和产品，哪个先哪个后，哪个是条件哪个是结果，但确实有些情况下，系统中的两个因素并没有先后关系，而是互为输入输出，互相影响，互相依赖，就是需要两头兼顾。
意识到这两个问题之后，需要从系统的角度，思考输入输出和反馈机制，在A和B构成的回路中，A或者B的哪些因素会影响到另一方增益/稳定/衰减。回路的问题是单因素衰退可能造成全局的影响，但优点也在于单因素增益能够通过循环不断放大。
人吃饱了才能卖力地种地，从而收获更多的粮食。而只有充足的粮食保证人能吃饱，才有足够的力气种地。不要妄想着不让人吃饱，还希望能种出符合目标要求的粮食来。要么晓之以情动之以理，画大饼先让人卖力干活，要么先借钱买一堆好吃的来，先让人吃饱，然后卖力地干活。往往我们会选择前一种方式，我们总是要马儿跑，又要马儿不吃草，前期一分钱都不想投入，还想着美滋滋的事情，但从系统的角度来看，在这种状态下，对后者进行调整，才是能让系统朝增益的方向发展，并形成正向循环的最好方式。
牛逼的产品，最后一定形成了正循环，比如淘宝，卖家越多，商品越丰富，买家也越多，买家越多，市场需求也会扩大，想赚一笔的卖家也会越多。这也是现在为什么一堆人都想搞平台的原因，平台的本质是链接需求方和供给方，做好运营，一旦形成正循环，供需之间会形成自动迭代，并因马太效应越来越强，这个市场会慢慢被“培养起来”。
牛逼的产品经理，应该懂得在设计尤其是业务设计阶段，发现或者设计一个能够形成正循环的系统，并将正循环的目标和思路体现在具体的功能设计和运营活动中，在迭代过程中关注正循环是否在正常迭代，某个环节是不是有问题。同时，尽量让正循环系统中的节点越少越好，链路越短越好，输入输出和反馈机制越简单越好。循环回路越复杂，投入就越多，需要关注的点也越多，可能会出问题的点也越多，风险越高。即使要在回路里面加入新的节点，也尽量保证是最有利于促进正循环的节点。

装逼

我觉得，装逼是一个人进步的最大动力。当你有了装逼的欲望，但是又怕装逼之后被别人取笑或者戳穿，唯一的办法只能是，踏踏实实地获取相应的技能并有大家认可的成果，像坂本一样凭实力装逼。我写这篇长文，本质上是希望对自己的能力和思维做一个比较系统的整理，查漏补缺，同时也分享给读者，希望引起一些思考。但反而，在朋友圈分享，大肆炫耀，让别人看到我认真写完了一篇5万字的长文，发出卧槽牛逼的赞叹，这种装逼成功的感觉，才是让我能坚持下去的关键动力。我希望装这个逼，认真地装个逼，装逼成功的自豪感，是对我码字的最大激励。
那么，对于你来说，值得让你认真装逼的那个事情，是什么？装逼成功之后，什么事情，谁的认可，会让你觉得很愉悦？找到这个事情，找到那个最让你有成就感的事情，然后为了能成功装逼开始行动，开始具备实力。毕竟，装了逼就跑，最刺激了对吧。

本节资料推荐

• 书籍《创新者的窘境》
• 书籍《黑天鹅》
• 动漫《在下坂本有何贵干》（好吧这条是闹着玩的）

后记

写这篇文章，不仅是向各位读者分享本人在产品工作中的一些思考，对自己而言，也是对工作经历和思考的一个全面的梳理和总结。我很庆幸能坚持下来，对于这篇文章来说，我想，我也是它的Architect了。希望这篇文章能给你带来一些思考，帮助你解决工作和生活中的一些困惑和问题，甚至可能会突然有灵光一闪，想到什么骚操作。如果你有时间和精力，也可以像这样，自己写一篇文章，整理能力，整理思路。
对于我来说，产品性质的工作确实是极富挑战同时又充满无限乐趣的事情，日常大部分时间都会在认真工作，但也会时常甚至是定期，变成一个孩子，把所有的工作中的生活中的产品，都变成玩具，像是在墙上贴满飞船和动漫电影海报的房间里，就这样坐在地上，随意摆弄着这些玩具。我希望自己永远保持玩乐的心态和探索欲，保持产品的灵性，保持一个建造师的角色，保持对世界进行探索和解释的过程，并基于自己的理解重塑自己的世界，甚至对除我自己之外的其他人有一些正向的影响。
这些内容也是基于个人经历和思考，难免有些点会比较局限，希望对各位有一些正向的影响，不同意见欢迎讨论沟通。
一起继续努力，成为有灵性的PM，共勉。

（转载请私信联系作者）