关于技能
注意，这里提到的产品概念，指的是广义的产品，经过一定设计能够解决问题的事物，叫产品。一个平台，一件事，一个流程，一个团队，一个项目，都可能是一个产品。
而关于技能的描述，也并非一定针对单个人或者一个团队，一个人如果同时具备这些能力那是极好的，而在有相对明确的分工团队内，也不意味着只需要具备其中一项能力就行了，这些能力是相辅相成的。
一、需求分析
需求即解决问题的诉求，并且是在某种特定的场景下产生的诉求和欲望。需求是驱动所有产品/所有商业/所有公司发展的原动力。没有需求，产品就没有存在的意义。
幸运的是，人的欲求永无止境，我们总能找到“问题”，也正因此，无数的创业公司蓬勃发展，从人类生活的各个角度切入，想要通过解决问题，满足人的生理、安全、社交、尊重、自我实现的诉求（马斯洛需求层次）。
这是偏用户角度的分析，商业需求表面上看起来与这五个需求没有关系，但毕竟任何商业活动都是在与人打交道，最终都可以归结为这五点。但是为了方便理解和思考，对于商业需求，我们还是有必要从商业角度出发进行重新梳理。
稍微具象一些，我将商业需求定义为，对某一件事变得可行（available）、快速（efficient）、有效（effective），并以此创造价值获取收益的诉求。期望需要某件事从无到有，从慢到快，从有到优，则满足商业需求，即是通过一种解决方案（平台/服务/商业模式）让某件事变得可行、快速、有效，以创造价值并获得与价值对等的收益。
需要注意，这里对于C（偏用户）端和B（偏商业）需求的描述，并不是割裂的一分为二的描述，只是从不同的侧重点进行说明，以解释在洞察分析以及解决问题思路构建过程中的差异点。
两者不是对立关系，比如你做C端产品需要考虑用户体验问题，也要考虑中长期怎么变现的商业问题，而做商品产品一开始就会考虑变现问题同时会在需求满足的过程中与用户发生交互，也要从C端产品的角度出发考虑如何进行产品设计。这便是B端与C端产品经理工作的基础差别，它们需要满足的需求性质有所不同，在解决方案构建过程的思路和结果也会不同，核心目标也不同。
但并不是所有从无到有，从慢到快，从有到优的事情，都是值得做的事情，而不值得的原因有二，一是可能并没有这样的需求，二是投入产出比不高。前者需要鉴别需求，而后者需要决策要不要满足这个需求。
当确定需求应该被满足时，需要将用户/商业需求，转化为产品需求，即，需要构建何种产品能力和功能，需要做何种优化，来满足需求。将需求转化为产品需求，正是产品经验的价值体现。
二、方案验证
人无完人，事无完事，水平再高，也不太可能初始方案百分百正确，在完整版实施之前，小成本验证，是必要动作，也是非常关键的动作。
关于验证方法，《精益创业》一书中提到了MVP的概念，minimum viable product，指最小化可行性产品，将产品方案用最简洁的实现方式开发出来，暂时忽略掉高级复杂的功能特性，开发一个“简陋但必备功能”的产品，快速投放市场让目标用户上手使用，然后通过不断地听取反馈掌握有价值的信息，由此对产品原型迭代优化，尽快达到理想目标状态。
比如我要造一辆车，我的核心技术是独家的V8引擎，希望能够以80km/h的速度连续行驶500公里，这是核心目标。那我造这辆车，最重要的事情就是要满足速度和续航，这俩搞定了，其他都好说。
现在我又没那么多钱造一辆整车出来，那甚至可以只要引擎，轮子，方向盘，刹车，我就可以上路测试了，当然为了保证测试驾驶员的安全，可能还得加上相应的保险措施。但我完全没必要在验证速度的阶段，给车上安音响和空调，如果你觉得要把这些载重量算上，那多拉几桶水就得了。
你要是路子野一点，可能还有更野的方案：去汽车报废厂，找辆别人家的车，拆掉换上自己的引擎，直接变成老司机。 这是我想强调的一点，我认为MVP仍然不是最佳的验证思路。MVP中的product，我将它改为 plan。最小化可行的方案，并不一定是最小化可行的产品方案。这里的区别是，在验证的阶段，你甚至完全不需要开发产品出来。
这个点，我自己是有经历过的，很痛，所以也和大家强调，虽然我们的本职工作是做产品，但并不是在工作的任何阶段，都需要以“产品”的方式进行。尤其在这几年，互联网创新多为模式创新，产品反而是商业模式的承载体。
大学里鼓捣过一些小项目，有一个是，帮别人去校门口小店里买鸡排饭，赚一块钱跑腿费。简单预估了下每天的订单量，算了下觉得能赚，于是马上开始着手准备线上下单平台，并且也确实考虑了，哪些是核心功能，哪些可以后面再说。
在完全没有进行产品开发时，已经能够通过此方式，快速验证满足需求的方案是不是可行，并且还可以知晓关键数字。这样的验证方案，才是MVP，是最小可行方案，成本远低于进行产品开发。
你甚至还会进一步想，目前直接联系跑腿小哥就可以解决基本需求，那是不是还有必要进行产品化，以及产品化又该改善哪些点，解决基本需求之上的什么问题。
这便是在方案验证过程中，最需要注意的点，我们需要去花时间寻找最简单的验证方法。它可能是问一个用户，画一张图，人肉做一个实验，就能够解决的问题，千万不要因为产品的条件反射，忽略了验证方案的合理性，一步指向产品化，试错成本会高很多。合理设计验证方案，用最小的成本得到最可靠的结果，才是“精益”的方式做产品。
三、产品设计1. 定位和边界
产品设计的目标是解决特定的人群在特定的场景发生的特定的问题，看起来像一句废话，但也是平常很容易犯的错误。
在设计的过程中，可能会发现某个地方有缺陷，会导致用户C或者D无法使用，于是增加功能来解决此问题，但发现E和F又发现了问题，修修补补，最后产品越来越臃肿，而且四不像，可能都忘了，CDEF本来就不是产品的目标用户，但在假想使用场景时却不小心代入了。
这个点在商业/专业型产品上，会体现得更加明显，我也是吃过亏的。
举个简单的例子，Adobe的Photoshop，Premiere等产品，普通人可能会觉得这软件啥玩意儿真特么难用，根本看不懂，学习成本太高了。但其实人家本来面向的就是专业用户，而不是小白，从一开始，所有的功能都是针对专业用户而设计的，如果纠结这些功能描述太晦涩普通人看不懂，然后做了很多相关的改造，那有可能就变成美图秀秀了。
同样，如果美图秀秀非觉得目前这些功能太简单了，要加一堆更高级的图层啊，蒙板啊，路径啊之类的功能，用户可能会一脸懵B。毕竟美图秀秀就是简单拼个图加个字而已。
出现这样的问题，是因为刚开始没有搞清楚产品的目标用户和需要解决的问题，没有搞清楚产品的定位。而就算搞清楚了定位，在产品设计和开发的过程中碰到问题的时候，很可能因为“追求完美”的条件反射，习惯性地解决产品设计中的“bug”，打了很多补丁。
实际上，想一想初始规划的产品定位，这个问题并不在应该解决的范围之内，就像“不能使用蒙板来抠图”是一个做图的过程中可能会出现的问题，但不应该是美图秀秀这个傻瓜式拼图软件需要解决的问题，它已经在美图秀秀产品规定的边界之外了。
明确产品定位和边界，哪些问题应该是产品功能设计中需要考虑的，而其他是应该抛出来（不是不管，因为可能影响到产品正常使用）的问题。
在工作中，尽量不要做“大而全”的东西，而是尽量做到“小而美”，即专注于解决某种特定的问题，不追求一次解决所有问题，这样思路和工作内容都会更加聚焦，也能更快更好地迭代，因为知道路在哪。
大而全的东西有其存在必要性，因为一站式，全链条的服务，能带来连续完整的体验，前后配合度和效率也会更高，大而全的东西，建议从一开始小而美的点去突破，慢慢做起来，形成“一条龙”服务。
2. 标准化
对于产品的目标用户，不管是A还是B，产品的体验应该是近似的。同样的功能和交互，不同的用户在使用时，应该都能快速理解其使用方法，符合其基本认知结果，且操作结果也一致。这就要求我们在产品设计时，充分考虑“内”和“外”的标准和规范。
内是指同一产品内类似逻辑和功能操作的方式、反馈都应该是一致的。比如在一款射击游戏中，不管你捡到什么样的枪，肯定都是左键射击右键瞄准，R键换子弹。如果突然捡到一把枪，是Q键换子弹，那在紧张刺激的游玩过程中，很可能因为习惯性操作，被敌人干死。
在形成了标准化的认知之后，用户能够更容易理解功能使用方法，甚至不依赖任何的提示也能正确完成操作。
在具体产品设计中，类似的功能应该尽量使用同样的表达方式，比如不同地方的开关，应该保持同一种开关，不同地方的输入框，应该采用同一种设计，以便一眼看出这就是输入框。
规范一些的设计和开发，都会产出Kit（工具包），比如UI Kit，比如Development Kit，一方面通过工具包的方式，在有相关需求的地方可以直接调用，另一方面提前规范好的Kit也能够保证前后端在用户使用和反馈方面的标准和统一。
外是指如果已经有类似功能的产品，并且用户已经形成了一定的习惯，这时我们应当遵循行业惯例进行设计，而不应该强行创新，就像大部分的螺丝都是顺时针拧紧，逆时针拧松，修理工在碰到不同的电器需要修理时，也不需要阅读手册就知道该怎么拧螺丝。
有个记得比较深的例子，手机上的虚拟键盘，还有我们实体键盘，基本都是qwerty布局（当然也有其他奇葩的布局，这里不讨论），但有一次下载了一个手机银行app，设置密码的时候发现键盘顺序与日常使用的顺序完全不同，甚至还是动态的！还美名其曰安全键盘，我找一个字母找了半分钟，找下一个字母又找了半分钟，输入体验极其糟糕，话不多说立马卸载。就算是为了安全，也不应该在键盘布局上做文章，其造成的用户感知是极其混乱的。
我们经常吐槽，卧槽这什么反人类操作，本质上其实是设计的时候没有充分考虑人的基本认知和标准化认知，导致使用时不符合正常操作逻辑，导致了不适感。这点尤其在用户产品设计上，需要注意。
3. 明确的感知
确定的输入，应该有确定的结果，并且，操作结果应当以及时/明确/合理的方式被用户所感知。
比如汽车仪表盘为什么存在，是让驾驶者明确感知到当前速度，那可能会想到，为什么自行车不需要仪表盘？
汽车速度更快，高速运动时，人的视觉感知能力会下降，所以需要仪表盘来明确显示当前真实速度，而自行车速度更慢，通过肉眼观察也能差不多知道当前速度是快是慢。
汽车是踩油门加速，自行车全靠脚踏板，蹬腿就知道速度快慢了，所以对于自行车来说，脚蹬的速度便也是一种明确的感知，而汽车却不能通过油门来感知行驶速度。
仪表盘的另外一个作用是看油箱油量，快没油的时候还会报警，这也是及时明确的信息反馈。
对应到产品设计中，最简单的例子就是，按钮的状态。
一个简单的按钮，也会有多种不同的状态，比如不可用，可用，鼠标悬浮，按下，按下之后成功执行功能或者并未执行功能时相应的提示，等等，设计这么多状态的原因就是，不通过文字说明和直接指导，用户看到时便明白是什么意思，同时能够明确感知到，自己进行了相应的操作和操作的结果。对感知和反馈的合理设计，能够减少或者消除用户的疑惑，使用产品更具备安全感。
同样，对反馈的优化，也能提升用户体验，比如为什么程序员都喜欢用机械键盘，是因为机械键盘相比薄膜键盘，反馈感知更好，键程更长，在打代码时，手感更好，打字效率也更高，甚至还有人就喜欢机械键盘的声音呢。而机械键盘还有空间的问题，所以在不少笔记本上，人们又开始探索蝶式/X式键盘，期望在较低的键盘高度之下，也能有不错的打字体验。你看，这些种种尝试和创新，都是为了优化打字的感知和反馈。
4. 预设计
预设计是针对某种情况下的必然或者可能发生的操作做半自动的提前设计，其实是对已知信息的合理应用，通过用户的已知行为，能够推断其下一步行为，并设计相应的交互和功能，使得用户更快或者以自动的方式跳转到流程的下一步。
还是汽车仪表盘的例子，不知道大家有没有注意过一些汽车的仪表盘，为了夜间显示，会有背光，之前好奇仪表盘的背光是有单独开关开启的还是根据光线感应自动开启的。有次坐车问我爹，原来，当开启前照明大灯的时候，仪表盘就自动开启了。
当时突然觉得真是个精妙的设计，不需要单独的开关，仔细想想，开启大灯这个动作，已经给系统传达了一个有效的信息：开大灯照明了，自然光线已经不足以正常驾驶了，那肯定也看不见仪表盘了，所以开大灯的时候，仪表盘也应该开背光，很简单，也不用用户主动操作了。
还有一个典型的预设计是烧水壶的自动断电机制，通过这个例子想说明的是，预设计要参考正确的条件。
最原始的烧开水方式，那当然就是架个锅在火上烤，沸腾的时候拿起来，要不水就烧干了，后来我们就看到了，壶嘴上带个口哨的水壶，水沸腾之后就会叫，人听到后去关火就好了。
明火烧水还好，如果是电水壶，没有断电机制就很危险了。当然我们现在的电水壶都能自动断电，我看到时，首先想到的是，里面是不是有温控开关，检测温度到100度的时候就断电，后来查了才知道是蒸汽开关。检测到一定量蒸汽就会切掉开关。
选用蒸汽开关的最主要原因，并不是更安全和简单，我意识到我刚开始从温度控制的角度根本就不对。原因是，沸腾的定义本来就并不是温度达到临界值，而是水开始气化，我假想做这个预设计的时候，先决条件就是错的（小学就学过，不同气压下，沸点是不一样的，如果用100度来预设计，那就完蛋了）。因此，使用蒸汽开关，才能够真正根据水沸腾的状态来决定断电。
同样，我觉得，楼道里的声光控照明灯，也是一个错误的自动设计。它本来是方便人们在楼道里摸不到开关的情况下，自动亮起，但我每次到住所楼道的情况都是，正常步行至门口，然后没亮，开门，没亮，大力关门的时候，楼道里的灯才亮起，然而这时候我已经来到室内了，外面纯属浪费电。
提高声控开关的灵敏度可以一定程度上缓解问题，但本质的原因是，根据是否有声音这个信息，无法准确判断人是不是在楼道里，要开灯了。合理的方式是使用人体感应开关，记得之前学校里的楼道照明是使用的类似开关，但现在大多数见到的自动照明基本都是声光控开关，可能也是成本问题吧。
好的预设计，会让用户觉得，好像产品知道我接下来要做什么，不用我自己操作了。
5. 有情感的设计
在明确的认同感偏向的基础上，有情感的设计，是画龙点睛的工作。
我使用过的APP中，印象很深的两个比较讨巧的情感设计是B站和即刻。
如果同样的逻辑，放在一个很正经的政务APP上，就会显得mdzz。根本原因是B站本身确实有这样的认同感偏向，而后者没有，就会弄巧成拙。
还有很多APP里都会有一些小彩蛋，有没有这些东西，完全不会影响产品的功能，但如果这些情感交互用得恰到好处，会给产品增色不少，甚至用户会觉得，牛逼，有情怀，这个产品经理懂我。当然，关键就是巧妙，用得好是画龙点睛，用得不好就很尴尬了。
6. 文档撰写
很多初学的产品经理会觉得不会写PRD什么的，但我反而觉得写文档是产品经理工作中，最轻松的一个事情。不会写，其实是因为没有想清楚，而没有想清楚的时候，就翻翻上面的东西，想清楚再下笔。
产品经理工作中，最常写的几个材料是，MRD（商业需求文档）、PRD（产品需求文档）、产品图示。
MRD是用来说明该产品在市场上具备什么价值，模式如何，怎么转得通，PRD用来说明产品功能是什么，该如何实现，期望目标，产品图示以图形的方式说明产品功能、架构、界面。
最后一个我刚开始写的是原型图，后来改为了产品图示，是因为，很多产品都需要以图形的方式来表达，但使用图形表达的关键点会有不同。图形不一定指界面，也可能是结构，也可能是流程。
比如你要做的产品是一个推荐系统，这个系统压根就没有前端，没有界面，用户不需要直接看到它，那我们并不需要画原型图，应该画的反而可能是系统架构设计图和算法原理图。
如果做的产品是一个移动app，可能需要直接画出高保真原型图，因为用户体验很关键，而用户体验与前端交互表达密切相关，所以并不能无脑丢给UI/UE的同学去做。
你如果做的是一款拼装模型，在设计阶段，不仅要设计好外观，图示中更需要表达的是，玩具的组装过程。
不止是图示在不同类型的产品上会有不同关键内容的表达，文档也一样。
这里我们把这些材料（就姑且称为文档）也看作产品来进行分析。这些文档的用户可能是你的大佬，可能是开发和设计同学，解决的问题是向读者表达你对产品的设想，并期望以此为蓝图进行设计和实现。
场景可能是现场讲解和实现时参照。面对这些不同的场景和需要解决的问题，文档的写法当然不是一成不变的，要看读者是谁，想表达什么。
所以我才说，写文档其实是最轻松的事情，它不应该拘泥于严格的格式，只要能向读者清楚地表达想要表达的意思，它就是一个好文档。你看，做产品之后，会发现设计的美妙，想清楚读者和表义，然后来设计这个文档。
至于格式，不强求，但是如果说文档的结构、描述、版式也能同时做到较高的规范性，文档会更容易被不同的人阅读和理解（合适的格式，在阅读时结构更清晰），更容易在不同的时间阅读和理解（标准规范的描述减小因时间和记忆带来的理解误差），更少出现“只有你自己读得懂，别人都读不懂”和“过一段时间之后看不懂自己写的文档”的情况。
四、数据分析
通过对数据的分析，能够知道产品的“功能”和“性能”是否正常。功能是否正常指的是某个功能是否正常运行，性能指的是功能运行结果的质量是不是达标。
运用合理的数据指标可以衡量功能和性能，比如某个功能的使用频次可以反映用户对该功能的需求强烈程度，比如单位时间可提交表单的最大数量可以反应服务性能，用户使用该产品前后做某件事所用的时间变化可以反映产品的效率提升，用ABtest方式测试得到的结果可以反映产品的增量价值。
数据分析的核心其实是发现明显的差异性，理想和现实的指标差异，A和B的指标差异，有和无的指标差异，等等，建立数据指标并建立合适的数据指标预期，就可以更容易找到产品和规划的差距并着手改进。
为了监测产品的数据，做产品数据指标的分析，我们甚至会简单做一个产品，用来实时监控这些数据指标，通常我们把它叫作dashboard，仪表盘，呈现比较及时的产品关键指标数据。所以，做产品设计和开发，除了主线的产品核心功能，别忘了对产品的监测也是需要设计和开发的一部分。
很多公司都会有专门的BI部门，就是专门分析商业数据，同样在做商业产品的时候，也要具备BI的思维，甚至在一定状态下，需要开发BI相关的分析工具来更好地进行商业数据分析。
五、产品运营
产品运营的作用是链接用户和产品，使得用户的使用过程和产品给用户带来的收益形成正循环，让用户用得爽，让产品活得好更久，尽可能放大产品的覆盖面和生命周期。产品运营使得用户和产品发生关系并持续发生关系。前者的表现是用户越来越多，后者的表现是用户活跃度的保持和提升。
在toB类型的公司，商业产品的运营，不只是对用户使用负责，还可能需要对业务负责，即，期望通过用户正确的使用和正循环的过程，带来业务增长。业务增长的动因，可能是单纯的流量质和量增加，也可能是用户在使用产品的过程中，效率/质量更高而带来更高质量的产出。
而为了能够有效地链接产品和用户，产品运营工作之前，需要了解并对产品功能和用户需求非常熟悉，如此才能够知道，产品需要的用户长什么样子（明确用户画像），用户对产品的认知（确定产品的用户侧表达），才能做好对内推进产品迭代，对外推进拉新促活。
运营的英文是operation，操作，运作。在不同的产品，不同的产品阶段，都有可能有不同的工作，但核心都是，让产品能用起来。
运营是一个持续性的工作，如果一直重复，那就没啥意思了，无论是对于个人成长还是价值发挥，都没啥意思。有意思的是，要在运营过程中形成方法论，明确在什么情况下，如何合理地使用产品功能来达到最佳效果，沉淀方法论，才能在不同的产品，在产品的不同阶段，知道该使用什么样的方法，提升用户使用质和量，并加速产品迭代。
比如：
产品刚上线阶段，对于小白用户，最需要的是产品培训，可以通过手把手教学，视频指导等方式，让用户快速掌握使用方法并上手；
在后期如何通过运营活动提升用户活跃度，等等，如果能够形成体系化的方法，运营工作将会更加游刃有余。
另外，做运营工作，一定要直接接触用户，但同时不能把自己变成一个用户，产品运营应该是介于供求方之间的角色，在to B型的业务中，需要做好用户价值和商业价值的平衡，高用户价值就意味着更高的投入，而高商业价值又期望更少的投入，在保证不损害用户利益的情况下，做商业价值最大化。
运营方法方面，先前有提到漏斗模型和反漏斗模型，建议以这两种模型去看待运营工作，找到漏斗的关键节点，并施加以影响，对提升运营效率很有价值。
六、决策
决策是做选择，寻找一个想像中成功概率最高，后悔概率最低的可选方案。由于资源有限，我们经常会面临选择难题。
既然是做选择，那一定会有机会成本，一定会有代价，一定会有责任，同样应该有权力调动资源，也有权利享受决策成果。在决策者身上，责任/权力/利益应该是同时具备的。
很多事情，作为旁观者可能不解为什么做这种决定，但对于承担责任的决策者来说，他的选择是在考虑到多种结果的情况下做出的，思路与旁观者可能完全不同。
所以，日常不要做一个键盘侠，瞎喷别人的决策，当别人来寻求建议时，最好也不要直接帮别人做决定，而是帮对方列出可能的结果，提供更多的周边参考信息，引导担责者本人自己做出合理决策，反正一般别人来问我，期望我给些建议的时候，我都是这么做的。
要知道如何做决策，首先要明白决策是需要承担责任，对选择的结果负责，出了锅就是你来背。一个经验比较丰富的人，决策的失误可能会小一些，但作为新人，不应该由于惧怕承担责任而不去做决策。这是前提，即作为决策者需要明白权力/责任的统一性，做决策之后，损失需要承担，成果需要享有。
按照我们之前在思维部分讲过的，通过归纳演绎，推演出可能的结果，然后对结果进行量化衡量，以比较多种决策选择之间，哪个成功概率最高，损失最小。这里的核心是对可能结果的价值考察，要考虑短期价值和长期价值，要考虑模块本身的变化，也要考虑对系统其他模块的影响。
从决策实施过程来看，有一个比较直观的办法，可以用表格的方式，将这几种选择一一列出，然后再把对这几种决策的衡量维度和权重列出，形成一个选择x衡量维度的矩阵，对各项一一进行打分，最后便可直观看到哪个选择的分数更高。在衡量方法设计合理的前提下，这种方法直观有效，推荐使用。
之前我在换租的时候，看了不少，最后感觉有两个还不错，但这两个却纠结了很久，不知道该选哪个。后来决定，从地理位置、小区环境、房间面积、房间布局、房间装修、设施配置、价格等因素，对这两个选择进行打分，通过分数高低来判定该选哪个。
最后，我比较了这两个的分数，然后。。。并没有做出选择！因为打分之后又细想了下，那个房间的书桌打在了阳台上，还无法拆除，阳台是向南的，那我放在书桌上的东西都会接受阳光曝晒，要这书桌有何用，这书桌对我来说就是废品！于是，也不用看分数了，原则上我不能忍受这个废品设施的存在，所以可以直接pass了。
这里有一个值得注意的地方是，在决策的过程中，除了考虑对过程投入和结果价值的衡量，有一个大前提别忘了，即基本原则。基本原则是具有一票否决权性质的关键因素，在做选择之前，先理清楚，什么东西是不可忍受的，一定要杜绝的，只要一出现就一定不会考虑的。这些基本原则能够直接排除一大票不靠谱的可能性，也约束了决策过程。
七、项目管理
我老板有句话讲得好，要成事儿，你要学会做一个局。这个局里，有人，有事，有资源，有目标，有关系，有情绪。而这些东西，便是项目管理需要管理的东西，将这些东西之间的连线和顺序理清楚，项目运转便会更加顺畅，说是管理，用“协调”这个词更为准确，通过对不同因素之间进行协调，让项目走得更快。
协调人。人是项目中推进事情发展的因素。在项目中，需要保证所有参与人理解项目内容，参与人需要保证有足够的精力来完成分工指派的任务，保证有足够的能力完成符合质量要求的任务。如果有理解问题，需要进行沟通，如果有精力问题，需要协调精力，如果有能力问题，严重情况下还可能要考虑换人。
协调事。这个事，更多指的是问题。由于项目是多人参与，当出现问题时，难免出现分不清锅甚至是互相甩锅的情况。为了避免这种情况的发生，一开始就要明确责任，出现问题之后，也需要尽快确定谁背锅。而确定谁背锅，并不是为了指着他的鼻子骂他，而是为了立刻推进解决问题。
协调资源。项目所需要的资源，在一开始就明确好，需要哪块提供什么资源。在项目跟进过程中，如果出现资源缺失，需要及时补足。
协调目标。只有上下同欲，为了共同的项目目标工作，才能一起完成一件事，在项目启动之前，需要确定目标，找到和你志同道合的人来完成这件事，所有人都应该认同这个目标，这样不仅能够保证运转过程中大家的方向统一，也能在出现分歧时有目标准绳进行判断。
协调关系。关系最关键，系统思考中提到过，各模块之间的关系，比模块更加重要
。比如我把电脑的扬声器去掉，我仍然可以插一个耳机继续听，就算不听，我仍然能完成基本操作，但如果主板没有向外部输出声音的接口，或者说有耳机和音箱，但是不知道怎么和主机连接，那约等于没用。
再比如学校给你换个老师，你还能继续上课，但如果是学生来考核老师，那这学校估计要大乱。
这是与单纯做产品不同的点，在推进产品时，大家主要是承担正常的岗位职责，我负责设计，你负责开发，他负责测试，他负责运营，但在项目组中，其实是虚拟的岗位职责，通过目标并不是责任将大家进行聚合，出于个人意愿做事，难免会有情绪问题，因此在项目组中，人的情绪也是需要协调的，甚至应该定期通过沟通/TB等方式来加强积极情绪。
万不可理所当然地认为，所有人就都应该做这些事，不想做或者做不好，一定是人的问题。
以上，大家还会发现，项目启动，并不单只是一个状态，还是一个动作，项目启动意味着在目标、所需要的资源、需要做的事，需要参与的人、人员的分工、责任与权力方面，与所有人达成一致并且。而在项目过程中的协调和管理，则是通过持续跟进和迭代，解决这些问题，并朝着项目目标做事。 把这个局布好，项目就成功一半了。
八、关于业务
成熟业务的产品经理，做产品工作就好。创新业务的商业产品经理，是业务型的产品经理，是小CEO。
刚开公司一段时间，基本是在做内部系统和工具，虽然确实是商业性质的产品，但此阶段主要还是基本的根据用户需求设计相应功能解决问题，而到后来发现，之前做的一些工作，确实能够提升使用效率和效果，但没有办法说清楚，商业角度的价值在哪里，是不是能帮忙赚更多的钱？
到底什么是业务，业务是找到一种可落地的，能够持续赚钱的办法，并将其打造成为一种模式，甚至是一个完整的行业生态。而作为商业产品经理，期望这种模式是基于产品能力构建起来的，所以核心是，探索并形成具有高变现价值的产品能力。注意这是商业产品经理的“产品业务”，如果是其他不需要产品也能构建的业务，负责人可能是其他职能的同学更为合适。
另外，也不是意味着其他业务不需要产品，有了产品可能变得更好。比如房产中介业务，没有链家APP也能正常运转，但有了链家APP，效率更高，业务体量更大，（一直在说，业务运转，业务并不是一个状态，也不是一个结果，业务是动态的，有资源、人、事的流转才是业务，是一个持续的过程）。
那么，如何找到这样一种方法，里面几个关键词，可落地，持续，有钱赚。
可落地表示这个方法应该是符合公司大方向，并且还可能与其他业务有配合的方法，表示这个方法在现阶段公司状态下能够落地实施，且投入产出比预估为正。持续表示这个方法不是赚快钱，不是赚投机钱，不是一杆子买卖。如果让PM去炒股，那他也肯定在致力于寻找一种预测方法然后让自己不断地能赚到钱，而不是一夜暴富。
有钱赚的问题，是作为商业产品经理，在业务设计中需要考虑的关键问题，当你构建了一种业务模式，付钱的人是谁？付钱的人为什么买单？他为什么选择你而不选择竞品？该付多少钱？这些点，核心都围绕一个关键切入点：你期望构建的产品能力，期望形成的业务模式，解决了什么样的客户问题。这个问题，要么别人解决不了，要么别人解决得不好，要么别人卖得贵。
最不推荐的是最后一种，因为打价格战的最后结果只能是薄利多销，同类型产品都逐步趋近于合理市场定价，毫无利润可言。所以如果你在做市场调研的时候已经发现需求被满足，而且价格也合理，那就不建议继续做了，除非它对于全局还有别的战略意义。
比如国内的手机厂商，大部分都不具备什么核心能力，定价相对较低，一旦出现价格屠夫，行业一片哀嚎。甚至有人把小米比作是行业搅屎棍，小米要切入什么行业，那个行业的平均价格都会下降到快趋近于成本。
但对于小米自己来说，它可不是自己的搅屎棍，它就愿意把产品卖到接近成本价，但它还再卖，因为即使这部分赚不了什么钱，对于小米整个生态的布局也有关键性的作用，手机是超级入口，还是智能设备的中心，所以它还是要做。
第一种，别人解决不了的问题，但你能解决，也不太现实，凭什么别人一直解决不了，就你突然就解决了。
《我不是药神》中的格列宁的制药公司，是一个“别人搞不定但我能搞得定”的例子，所以它具有这个市场的定价权，如果完全按市场经济，想定多少就定多少。当然，为了解决这个问题，前期也投入了大量的研发成本，对于别的企业来说可能是天文数字，这便是代价。
这个时代，创业团队风起云涌，见缝插针，各行各业的各问题，有一些是限于基础科学和前沿技术瓶颈，非常难解决，剩下的基本都已经被解决或者在解决了。
我们所构建的业务模式，更多还是对现有解决方案的改良，通过一种成本更低的方式，做到了更好的效果，便有了相应的商业价值。
做改良，收益会更可控，风险更小一些。现在经常在洗脑广告里听到的“没有中间商赚差价”，它并没有完全改变某种交易方式，只是改良了信息传递过程，便能够立有一席之地，而且风生水起。探索业务模式，不妨从“对现有流程进行改良和加强，以形成一种新的更好的模式”的思路出发。
搞业务，一定不能封闭，商业是有来有往的，闷头搞一定是死路。业务本身，存在于生态里。就像自然界有生态系统，里面会有捕食关系，共生关系，寄生关系，这个生态系统才能形成循环，在一个业务模式里，有上下游（上游是供应方，下游是被服务方），有竞品，有友商，才能持续运转。
当然，竞品有可能不存在，供应方有可能是自己。上下游有依赖关系，竞品有竞争关系，友商有合作关系，找清楚自己在整个生态中的位置和角色，加强合作，稳定依赖，减小竞争，便可使业务更加润滑。本质上这就是用系统思维在进行分析，明确模块和关系，所以你看系统思考极其关键。
那么问题来了，在toB场景下，怎么搞定客户？
关键在于合作共赢。
与客户之间进行业务交易，并不是简单的我把包子卖给你，我失去了包子而得到钱，你失去了钱而获得饱腹感。这是因为toB场景下，客户本身也有自己的商业模式，对于客户和我们两方来看，并不是零和博弈，因为还有第三方实际承担成本（那就是我们这些屁民啦）。
所以，在这样的状态下，双方最理想的合作模式，是我赚钱，你因为用了我的产品也能赚更多钱。
相应地，在设计业务模式之前，需要搞清楚，你服务的客户，是怎么赚钱的，对方是什么样的业务模式。通过双方的合作，对方的业务能转得更顺更好，那这事儿就成了。
所以，搞定客户的核心，简单点说，就是要了解客户的痛点，而了解客户的痛点，就需要了解其业务运作模式，然后以双方业务都能转得通，整个生态能转得通为方向去做。
另外，再说一点。产品经理，即使是纯用户产品经理，不参与业务能力构建和相关跟进，也有必要了解和熟悉公司的各项业务，自己的需求挖掘和产品设计、运营等，都需要符合业务规划，才是满足公司要求的产品。
九、关于AI
这几年，人工智能很火。凡事只要和AI挂钩，就觉得突然变得很屌，甚至有时觉得AI可以解决现在解决不了的任何问题，还会有人觉得AI就是替代人的工作，AI如果能像人一样处理问题，就是牛逼的AI产品。
虽然说在某些需要拟人的场景下，越像人的AI越牛逼（比如陪聊机器人），但大部分情况下，AI像人没卵用，能以投入产出比较高的方式来解决问题才牛逼。核心还是看需求和解决问题。
人工智能是人工创造的智能，而不是类人智能。人工智能产生的原因是，人们希望通过机器的能力，增强人类改造世界时的边界和效率，本质上，人工智能也是人类的工具。与一把锤子，一辆汽车不同的是，人工智能这个工具在经过设计之后，能够自主感知，学习，输出，还可能变得越来越牛逼。
各种影视作品里描写的AI，比如《2001太空奥德赛》中因为不承认自己的计算错误不想被人发现错误而杀死人的HAL9000，比如钢铁侠里变成Ultron的Jarvis，以及《终结者》系列里的天网，都是人类创造出的AI，最终毁天灭地。甚至这几年，出现了很多警惕人工智能的言论，谈AI色变。
确实，电影也不是瞎拍的，如果人类太浪，让机器有了自我意识，并且在非意识层面（效率/能力）还强过人，确实有可能会打得人类生活不能自理。
但现阶段，远没到如此程度，AI只是在某些垂直领域，尤其是规则性比较强的领域，由于其结构化的计算性能强过人类，会在不断的学习后，超过人类。
比如之前的DeepMind，AlphaGo等等，也只能在棋类游戏，电子游戏等具有明确规则，且胜负相对容易衡量的竞技中，胜过人类。但在相对复杂一些的翻译，语音交互场景中，人工智能都经常会变成人工智障。
现在应该担心的，根本不是AI有一天会当家作主的问题（这个问题如果上升到哲学层面，是有研究价值的，比如AI是不是生物，人类是不是本来就是进化到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，嗯？）。
本节资料推荐：
书籍《精益创业》、《增长黑客》
书籍《商业模式新生代》，制作精美，图示明确，有方法有案例，就是没有电子版，然后实体书有点贵
各种互联网公司传记，可以看看腾讯的《腾讯传》和红衣教主的《颠覆者：周鸿祎自传》，重点看他们在关键问题上如何做选择的
