本文由作者 @SkySOON 授权发布

全文共 17348 字，阅读超过 30 分钟，建议收藏到“微信读书”阅读

题图来自 Unsplash ，基于 CC0 协议

———— / BEGIN / ————

一、前言

从毕业到现在，成为PM已有三年，在移动广告公司，作为商业产品经理，从最初的产品功能设计，到后来逐步负责一条产品线，具备了一定的业务能力。

这三年来的成长，极速且痛苦，不能说成功或者失败。

本来成功的经验也难以复制，而失败的经验值得思考；因此我会更多讲一些考虑事情的思路和失败的教训，至少能够在面对已知的情况时，知道哪些坑已经踩过了；面对未知的情况时，知道该怎么去思考，以什么样的思路想事情更合理，而不是实操。

近年来，互联网泡沫越吹越大，行业确实在欣欣向荣，但是随之而来的是：产品经理这个岗位，出现了扭曲和变异。

这样的变化本身并没有好坏，毕竟，企业都是根据发展需要进行不同角色定位。

只是，大多数人仍然在神化产品岗位时，像BAT这些大公司里的不少产品岗位，已经从产品核心Owner的位置，变成了像别的岗位一样，具备专业技能，跟着大部队干事儿就完了。

而创业类小公司的产品岗位，又对产品经理能力要求极为严格——招产品像是在招CEO。

这种尴尬的两极分化的局面，导致不少人不知该如何选择。

大公司有面子，但进去只能从一颗螺丝钉做起，纸面招聘要求还很高；小公司能学到更多东西但对能力要求高，说不定进去还得打杂，啥事儿都得管，风险还高。

我并不能帮你决定该选哪条路，但不管选哪条路，“想事情的方法”这件事都极为重要，尤其是在大公司内不太能获取的经验和能力成长。

我处在一个稳定业务面临挑战&期望探索形成新的业务/产品/商业模式的公司；虽然也才三年，不过，从60分做到80分，从0做到1，稳定业务产品，创新业务产品，都有负责过，一路摸爬滚打，自觉这些经验和方法沉淀还是可以看一看的。

另外，笔者从事的是商业产品经理，与用户产品经理在工作内容和能力要求上，都有不小的差异，本文更多也是从商业产品角度来讲。

其实毕业时还是期待做用户产品的，毕竟离用户很近，觉得通过自己的设计能够直接影响到用户会比较有成就感；后来也是阴差阳错从事商业产品经理，意外地发现，这条路距离诗和远方更近，而且也更有挑战更有趣。

至于商业产品经理和用户产品经理的详细区别，后续也会讲到。

如果你内心喜欢有挑战的事情，且有勇气不断突破自己的舒适区，还意淫自己以后成为CEO位置的人物，带领一帮人飞黄腾达，走上人生巅峰，相信从商业产品经理作为起步，是一个不错的选择，本文或许也能给到你一些帮助。

二、为什么选择做产品？

从岗位性质来说，我认为商业产品经理，或者说，像商业产品经理/具备商业产品经理思维的角色，是世界上最有趣最富有挑战的事情。

它的核心是：通过合理的设计（对人的设计、对事情的设计、对资源的设计、对工具的设计），基于一个目标，把一件高价值的事情做成，并且能够不断扩大其价值。

相比于Product Manager ，我更喜欢将这个岗位定位为Architect——建造师，缔造者。喜欢创造和探索，喜欢通过设计来解决问题，用老方法解决新问题或者用新方法解决老问题。

我相信：还是有不少人期望将自己的想法实现，而不是实现别人的想法，或者明明发现了一个需要马上解决的重要问题，而自己并非身在其中，只能在一旁干着急。

如果是这样，那产品经理这个岗位，是让你有机会“搞事情”，而且有机会和一帮人把事情搞大的最好选择。

之前曾经做过UI/UE类的工作，负责某个移动APP一小部分的界面设计，最痛苦的事情并不是改稿，而是自己在体验APP的过程中发现了不少与界面和交互设计无关的问题，想要搞事情，想要推进解决，但限于角色定位，也只能提提建议，而无法协调资源去解决，会觉得非常难受。

当然，这并不是说做好自己本职工作不多管闲事，就是有问题的，看个人性格和想法。角色分工本就是希望在本专业发挥最大价值，只是如果从性格上来说，就是喜欢“搞事情”、“捅娄子”、“专业杠精”，那还是做产品更痛快。

从能力成长来说，产品经理岗位本身的要求，能够锻炼和成长的能力方向，相对于其他岗位更为全面——设计/运营/项目管理/商务等能力基本都会在工作过程中得到成长。

在公司内，起步阶段其实就已经相当于是在进行小型的内部创业，因此在工作过程中会很快遇到产品、运营、项目管理、商务等各方面的问题和挑战，也能够在解决问题的过程中快速构建多栈能力。

从做事思路来说，作为商业产品经理，在结果导向之下，通过逻辑分析和推理，输出符合中长期目标并且现阶段投入产出比最高的方案，明确实现的路径、资源需求、阶段性关键目标、迭代优化方案，知道该在什么时候什么情况下找什么人解决什么问题，并作为先锋带领团队向长期目标突进——这整个过程，本来就是搞事情的最优思路，即便不做商业产品，也非常适用；甚至可以针对性简化后，适用于生活中各种事情的处理。

总之，产品牛逼，商业产品牛逼！我身为商业产品经理感到非常自豪！

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

本文内容实际上是在说方法论。

百科词条如是说：

方法论会对一系列具体的方法进行分析研究、系统总结并最终提出较为一般性的原则。

本文希望基于笔者的经验和工作过程中的思考总结，梳理“通过商业产品思维搞事情”的方法和技巧。

如果你是一个PM，那可听听同行的想法和思路，求同存异，取长补短，借此形成自己的方法论。

如果你不是一个PM，也可快速了解产品思维，并将其运用到广义的“产品”工作中，比如开一个店，比如做一个剁手的决定，比如出一个旅行规划。

把方法论应用在生活中，总感觉有点丧心病狂走火入魔，但合理（不是上纲上线的杠精）的运用，确实能够在某些情况下，做决定更高效，少了很多纠结，也能更快辨别做哪些事是有用的，而不是一段时间之后发现原来这事纯属浪费生命。

我一直觉得：产品经理应该积累能力，而不是积累经验，而经验的增长和能力的增长也并无关系。

一个做过很多产品，具备丰富产品经验的PM，可能也并不是一个好的PM，而在做事之前有完整的思考，知道该如何正确地做事，如何做正确的事，并且能将思考结果运用在做事上，做好一件事，做好一个产品，我觉得这是一个好的PM。

希望大家获取的，不是经验，而是思路。

我在文章中举的例子，也会有不少与互联网行业无关，一方面希望大家能在生活中代入这样的思考；另一方面也想证明，这套思路不只是在产品经理工作中适用，而是可以在生活中落地的。

四、关于思维

如果你面试过产品岗位，或者了解过产品岗位需求，或者已在产品部门工作，那你可能会发现：相比于其他专业性较强的职能部门，产品岗位的同学，可能来自各种各样奇怪的专业，并且很大程度上，目前的工作也和在学校所学的专业毫无关系。

你可能还会发现：

没错，至少我认为：产品经理最重要的，不是他目前具备的能力和已经获得的经验，而是他认识/解释/改变世界的方法和思路——因为这些思考方式能够折射出，这个人面临具体问题（所有问题，更多是用户/客户问题，而非专业和技能问题）时，会如何处理。

而产品经理最核心的工作即是：解决问题。

所以，具备产品思维，对于产品经理来说，是先于其他任何能力的。

这也是我想说的：灵性。

这个词听起来有点玄学，但确实是我想到用来描述产品经理思维特征的最合适的词汇了。

我将灵性解释为：

在面对需要解决的问题时，能从横向（多角度）纵向（多节点）系统化分析，并找到能够在现阶段条件下解决问题，且尽量符合中长期目标的最小可行方案。

思维方式概括并抽象为以下如下一些关键点，关键点我会举例说明。

1. 结果导向

结果导向，既然产品经理以解决问题为目标，那问题的本质是什么？什么情况就算问题解决了？问题解决到什么程度就够了？这些问题在思考如何解决问题前，就需要明白。

在学校里，如果你考试不理想或者参加比赛没获奖，老师以及你自我安慰时，总是会说：哎，结果不是最重要的，过程最重要，要看你过程中学到了什么。

对于个人来说，没毛病。但是，公司是百分百追逐利益的组织，并不是学校——我出钱你出力，很简单的交换。

因此，从学校跳到公司，首先需要明白的一点就是：结果至上，没结果就别瞎说，工作目标一定是为了达成一个确定的结果。

以前有个小同学刚来不久，有次我找Ta聊天，希望引导Ta思考并制定自己的工作愿景和职业规划，结果Ta说了句：我来这就是想找个厉害的大神带我学习。

我内心真是，一口老血。

这话要是让领导听到，岂不是当场暴走？

在结果导向思考的过程中，最简单的方式就是定KPI（Key Performance Indicator），通常通过数字的方式衡量一个工作结果，比如流水、利润、人效提升等等。

但KPI考核方法过于片面，尤其对于产品工作，并不是最合适的。

很多产品的结果表现，不能完全用KPI指标来概括，因此这里也重点讨论一下，产品工作如何更合适地进行结果评价。

合理的评价方式，建议首先做到定量和定性结合。

为什么需要这样的评价方式？是因为产品本身并不一定直接带来金钱收益，也不只是带来其他数字上的变化，还可能有“从无到有，从A到B”的变化，而这样的变化，也是期望达成的结果之一。

从商业产品经理的角度来说，需要构建产品能力，也需要有明确的业务收益。

前者指的是能做什么事，后者指的是做成什么事。

没有定性只有定量，容易造成外强中干和形式主义。比如盲目追求销售额增长而忽略了客户关系维度，这个季度的KPI虽然确实完成了，奖金也拿到了，但客户再也不会被“骗”了，中长期完全不可持续发展。

没有定量只有定性，会导致收益不明确不可衡量甚至没有收益。比如老师和你说这学期只要把我布置的作业写完就行了，成绩多少分都无所谓，是不是有毒，除了一些修身养性的选修课，可能一般老师也没这个仙气。

百科对结果导向如此解释：

我表示不同意。

“往往，他们太注重结果了，而导致过程的错误，结果达不到。”这个缺点并不是由于结果导向造成的，而是在结果或者目标设定的过程中，定量和定性考核未结合或者设定错误造成的。

结果导向的思考，不仅是帮助在完成一件事情时用来进行质量评价，更重要的反而是通过合理的结果考核方式制定，约束实施过程，以保证推进方向和需要构建的能力，符合目标设定。

就像国家在追求GDP的同时，也会说要大力发展XX产业，重点扶持XX产业，也会强调可持续发展，也会说绿水青山就是金山银山之类的。

因此，在结果导向的过程中的方式，能够更合理地衡量和指导产品经理工作进程。

它保证了工作是需要达成一定的收益，同时也不至于太追求数字，保证通过某种特定的方式和路径来达成目标。而约束达成数字的方式，原因是，我们希望在过程中构建的方法/经验/工具等，能对后续长远发展起到作用，而不只是当前KPI。

关于如何制定目标，我们再举个例子：

你看，其实在上面的这个描述中，已经有了定量和定性的描述：定量是每天挣一两万，定性是包子质量好还能有口碑。

但是，往往我们在工作中制定目标时，就会变样：

极端点说，那负责卖包子的同学可能就会不断地在高价的边缘试探，也许确实找到了那个平衡点，顾客可接受这个价格且利润率最高。但这个时候，口碑的愿景其实就不太能达到了。

这种方式，不是可持续的；说不定明天有另一家包子店和你家包子一样好吃还便宜，那就要GG了。

同样如果你过于理想化，对你的员工说：

如果要稍微规范一些的描述，可以是：

• 目标：构建口味符合自家手艺标准的包子产品，并以包子为主售产品（数量占比80%以上）在保证合理利润率情况（10~20%）下实现规模化（日流水1w+）运作

• 关键动作1：在用料和制作方法上探索并明确符合自家标准的包子生产流程且成本符合（单个成本1块以内）

• 关键动作2：以传统口味为主要卖点进行营销，在包装/店内VI/对外宣传上均有体现，形成相应品牌认知

• 关键动作3：包子售卖业务常态化，日均流水1w+，独立顾客100+

上面的描述不一定符合实际，只是从考虑结果衡量的角度，更加全面和规范。

关于目标制定方面，已经有很多大佬和大佬公司总结了不错的方法和工具——SMART原则和OKR考核办法个人觉得比较好用。

套用SMART原则能帮助你制定合理的考核标准，而OKR能够帮助你明确为了达成目标，在不同的界面上需要实现什么样的关键结果。

这两个我就不具体展开讲了，大家自己搜索了解即可。

虽然思路和方法是无尽的，但现阶段的资源一定是有限的，在有限资源条件下做事，只能解决一个核心问题，所以结果导向时，需要保证目标聚焦，上面例子中，三个关键动作从不同维度表达了，为了卖出受欢迎的包子需要做哪些事情。

有个小习惯，每次做事之前用一句话来描述你期望达成的目标，如果无法一句话概括，那可能就不是很靠谱了，做着做着你会发现接下来不知道该往哪个方向了。

所以，结果导向有两个关键点：一是合理的衡量方式，二是聚焦在一件关键的事情上。

2. 逻辑思维

这可能是产品经理的特质中最典型的一个点了。总是被提到甚至被吐槽：你们PM就是，想个啥事儿都逻辑性特别强，非要分析原因，非要理个123出来。

逻辑一词，最初希腊语logos本意即是词语/言语，引申为思维/推理，可见逻辑其实就是关注思维规律和思维过程的学问。

逻辑是更清晰更高效地进行思考，不扯太多概念性的东西，就产品经理日常会用到的几个思考方法举例说明。

（1）抽象

通过抽象，抽离事物的特征、属性、关系，将个别的、非本质的内容剔除，概括本质特点和构成。

抽象对于简化和概括产品工作非常有帮助，只有通过抽象的方式来观察和分析产品，才能从最根本的层面发现和解决问题；同样因为抽象，也能够更快地发现问题，而不会停留于表层现象。

举个例子：

正常思路的话：可能你已经开始去网上搜索空气净化器的原理和构造，甚至设计图了。

现在，别急，试着先在脑子里过一遍——啥是空气净化器？空气净化器的本质是什么？

我会想：

自下而上后，你会发现，咦，那口罩是不是也是，新风系统是不是也是？

没错，是的。

抽象之后，你会发现：这些东西其实都差不多，只是表现形式不一样而已嘛~

你甚至还会发现，既然是空气过滤装置，那么考察它们的关键指标是什么？是能过滤什么东西和过滤的效果好不好，进而抽象出，空气过滤装置（甚至还可以进一步抽象为一个筛选器）的关键性能指标是过滤物类型和过滤效能（筛选内容和筛选效率）。

你看，在什么都还没有做之前，通过自下而上的抽象，你就已经知道了这么多事情：知道了空气净化器的构成是什么，核心是什么，关键指标是什么，还知道了同类型的产品有什么。而如何设计，原理是什么，反而是后面才需要关心的事情了。

对产品经理来说，前面这些事情是非常重要的——是不是很有趣很鸡智的做法？

PS：我保证在写文章时没有搜索空气净化器的相关资料，就是这样推理出来的。

程序员面向对象编程，其实也是一种抽象的思路。

比如开发一个权限管理模块，用于管理所有登录用户可操作的功能，比如管理员A可以看所有人的信息，而普通人B只能看自己的信息。

在进行功能开发时，不应该直接对账户A和B进行权限指定，而应该是将其抽象得到角色这一结构，定义管理员角色和普通用户角色这两个对象，给对象赋予不同的权限，然后为A和B这两个具体的用户分别分配管理员和普通用户的角色。

这样一来，不仅能够方便查询到，用户A和B分别是什么属性的用户，后面来了A2，A3，B2，B3，也不需要重新写代码，只要为其赋予相应的角色即可。面向对象的好处就在于此。

同样，像一些大平台的语言，都会预先提供一些Development Kit，也是面向对象，通过工具包的方式，每次去new就好了。

（2）切分与解构

将一件事物用可枚举的，互相独立的点来进行结构化的描述。

比如选购手机，你自然地会想到：多少钱，配置怎么样，好看不好看，耐摔不耐摔——本质上是对手机这个商品在不同维度进行切分和解构，来更好地判断是不是满足你的购买要求；这些解构的维度分别是：价格/外观/配置/工艺。

如果你观察得仔细，也许会发现一些电商网站的比较功能其实就是这么做的——你可以把纠结不定的产品放在一块，它会帮你把同维度的参数列表呈现出来，帮助你快速比较和做选择。

比如之前举到的包子店的例子也一样：关键动作之间相互独立，是对目标在不同维度的切分和解构，这么梳理甚至能帮助你发现之前思考中遗漏的部分，比如很容易忽略的包子制作方法标准化这个关键点。

这个思考方式的好处显而易见：条理清晰，解构为独立的不同因素之后，你能够更快做判断和分析；而不是各种因素混在一起，剪不断理还乱。

它还能让你考虑的点更加全面，因为思考并列举不同的维度/方向/特征，难度远小于毫无目的事无巨细地一一列举。

那么问题来了：马的细节总得画，怎么办？包子还得做，怎么办？

很简单，重复切分和解构的过程，对每一个维度再进行这个过程，直至最细粒度。

比如代表马头的那个蛋，可以再画一个小蛋表示眼睛，一个小蛋表示鼻孔；比如手机配置可以再细分到屏幕分辨率，处理器型号，电池容量等等。

细分过程中，一开始不要求必须正确，而要求尽可能枚举所有能想到的信息，不放过任何一个细节，后续逐步进行归纳和分类。

这个过程用树状结构的脑图进行梳理最方便，相应的工具也有很多，在线的百度脑图，ZhiMap，本地客户端比如mind manager等等都很方便。

我个人非常享受这个过程，可以将一个事物解构到独立的最细粒度，然后一一观察哪里要做什么事情。

（3）系统思考

系统化也会需要解构，将系统切分解构为负责不同职能的模块/结构，分别具有不同的行为，但系统思考更注重关联/组织/部分与整体。

校友钱学森同学对系统作如此定义：

缺乏系统思考，容易出现的现象是：只见树木不见森林，头痛医头脚痛医脚。

工作中，你经常会发现：解决一个问题，刚开始觉得很容易；但后来发现花的时间越来越多，为了解决这个问题，需要先解决其他问题，然后不断地，打了很多补丁。

本质的原因并不是没有弄清楚这个问题，而是没有从系统的角度去思考它所处的位置/模块，没有考虑它与其他模块的交互/联系/依赖。

其中关键是：意识到要解决的问题处于一个错综复杂环环相扣的系统中。

系统中两个关键点，一个是要素，一个是要素之间的内在关联关系；后者比前者更为重要，对系统起决定性作用。

在解决问题的过程中，需要花更多精力理清楚要素之间的关联关系，输入输出是什么，谁对谁有影响，谁对谁有依赖，这是“成大事”的关键，否则就会手忙脚乱。

工作中碰到的系统，其实很多，不只是你要开发的XX平台，XX管理系统，才是系统，一个团队，一个工作流，一个小功能小交互，都是系统。

在做事之前搞清楚，哪块工作会需要哪个人做哪个事，谁的小失误可能会影响全局推进，等等，才能成事。

在构建与人相关的系统时所做的事，我赞同我老板的描述：“你要做一个局”。

我们总是强调做事要有先有后，种瓜得瓜，种豆得豆，但在系统思维中，如果片面地使用线性方式进行思考，就会出现问题。

导致这样的原因是：土壤本身这个参数应该被考虑到植物生长的系统中，并且与瓜子之间有一些相互影响。

非线性不如线性容易解释，但也让自然千变万化，系统思考时要注意很多现象都是非线性的。

另外，系统本身作为一个模块去考虑它的输入输出时，会有一个奇妙的机制：反馈。

反馈调节在系统控制中的作用很有意思，是调节系统平衡或者持续增益的关键因素，我们后面会讲到。

（4）归纳演绎和推理

归纳与演绎是两个过程，归纳从特殊到一般，演绎从一般到特殊。 

归纳和演绎都有两个关键要素，前提和结论。

归纳并不能得到百分百肯定的结论，因为它的前提并不是“真理”，而是“现象”。

归纳法以整体中的一部分作为抽样对象进行研究，以此来代表整体，样本范围选择决定其代表性。

如果要证明归纳得出的结论是正确的，那除非检查整体中的每一个样本，那是不可能的。

而演绎得出的结论是特殊的，确定的，而其推导前提是确定的。

而如果前提本身有问题，则演绎法不work。

这个前提本身是错误的（但在发现第一只黑天鹅之前，人们真的以为这是真理呢），所以最后得出的结论也不可参考（黑天鹅事件在经济学中，常用来形容非常难以预测，且不寻常的事件，通常会引起市场连锁负面反应甚至颠覆）。

归纳和演绎并不能准确地告诉我们下一步一定该怎么走，但通过基于一定假设条件的思考，能够帮助我们规避风险，针对可能情况做出相应的设计，以便在遇到问题时快速响应。

基于归纳和演绎方法，通过论证展现做模拟和推理——看起来是纸上谈兵，但纸上谈兵并不是无用的，它的意义是从一个观点出发，得到另一个让人接受的观点，能在我们做出任何实际投入之前，就能根据不同的假设条件模拟推演出对应的结果知道在什么情况下会出现什么坑，帮助我们节省大量的实际成本投入，提前预知并避免风险。

狼人杀里的推理最多了，对吧？

想想你在一场狼人杀里面是怎么思考的：

你看，你通过假设，推测当假设条件成立时，对方应该有什么样的表现；当这些表现真实发生时，你就能通过排除或者概率排序得到最优解，来获得游戏的胜利。

战场打仗也需要沙盘模拟：在沙子做成的立体地图上，插上小旗子，放上小人儿和模型，用不同的颜色来表示敌方和我方，推动小坦克模拟敌方进攻路线，然后思考：如果敌方从这个方向切入，我方应该如何应对才能破局？

上面两个例子，其实是用最简单的方式，在假定条件下，模拟甚至穷举事件真实发生时最可能的形态，进而推演出相应的结果表现和应对方式；而虽然假设条件还未发生，应对方式却是真实得到的收获。

程序中的if else 其实是通过条件判断语句来消除一部分未知事件造成的风险——这本身也是一个假设推演的过程：如果用户输入正确，那就登录成功；如果输入错误，需要重新输入；如果输出超过5次，就锁定不让输入。

如果不进行这样的if else设计，那可能你的系统要GG。

其实，换位思考也是在做推理：

在假设推演的过程中，你可能会发现：唉，这个以前好像发生过，类比一下，我似乎知道我该怎么做了。

所以，假设也不是一味的空中楼阁，如果在假设的过程中运用类比，在历史数据库中寻找相似的案例，并对比当前情况与历史案例的相同点和不同点，那这些经验能够极大地帮助你减少推演过程中无法确定的因素，约束假设推演的过程；避免最后发现，需要做的假设越来越多，而并不能得到有效的结论。

另外，需要注意：世界的复杂性可能让推理变得难以进行，在推理的过程中，需要适当地简化和舍弃一部分与主线无关联或者影响可以忽略的要素，以进行简单推理。

3. 数据驱动

产品经理用数据说话，商业产品经理更然。

数据不等于数字，数据是可置信的信息。

大学主修电子信息工程，关于信息，男神香农（信息理论的奠基人）有一句经典的概括：信息量代表了不确定性。

他创造性地用信息熵（entropy）概念来衡量信息量的大小，即为随机不定性程度的减少。这就表明了他对信息的理解：信息是用来减少随机不定性的东西。

比如，我抛了一枚硬币，并清楚地知道它是正是反；则这个结论已知，完全确定，则这个信息的熵值对我来说其实是0。

如果我在抛这枚硬币之前，有人能告诉我一条硬币结果是正是反的信息，因为它是有概率存在的，按香农的公式计算出来，信息熵值为1（以bit为单位，而后的byte、KB等概念都是从此演化而来），它代表了一个最简单的陈述：是/否代表了数据的最小单位。

扯这个概念，一方面是怀念一下香农大神，另一方面也是表达：数据，或者说信息，在我们做决策时的关键作用，是抵消不确定性。

可用的（即准确的）数据量越多，做决策时的风险就越小，所以，做决策需要数据驱动。

数据驱动的核心是：在收集到有效数据的前提下，运用合理的方法对数据进行处理和分析，从而输出对决策有帮助的结果和结论，从而指导实际的产品设计和内容选择。

这里直接以一个很多人都听过甚至做过的产品，且是一个相对复杂的例子，DMP（Data Management Platform）数据管理平台（DMP在广告/搜索/电商/内容推荐等领域发挥非常关键的作用）来讲解运用数据做决策的过程，同时也带大家了解，如果在系统层面需要搭建数据驱动决策的能力，需要怎么思考。

以电商商品推荐为例，我们一般将DMP能力分解为以下几个关键模块：

• 数据的收集：采集需要的各节点数据，比如浏览/收藏/购买/分享。

• 数据的处理：对数据进行清洗/整理，过滤无效数据，分类有效数据。

• 数据的分析：基于一定的分析方法对数据进行分析和计算以输出结论，比如根据购买频次统计分析生活状态和购物喜好。

• 数据的使用：运用数据分析结果指导策略制定，比如根据购物偏好结论为该用户推荐同类更多商品。

（1）数据收集

在第一个步骤中，我们可以运用多种方式收集用户数据，比如做用户调研，比如收集商品购买订单等等，但在大数据时代，我们聊点高级的，即埋点（我这里说的埋点是概念上的埋点哈，并不是埋点这种技术）。

埋点是说：在对商品推荐有价值的行为节点，建立数据的采集和记录机制，在相应的行为发生时进行事件汇报和记录，这样可以记录每一个有价值的行为，完全不需要做什么抽样调查。

在这里，我们把用户与购物相关的有价值动作用一个对象“行为”记录下来，每一条行为记录当中，都包含有用户ID，行为发生时间，行为类型，前向或者后向节点，行为具体内容等，具体可以这样设计：

• 唯一记录id

• 用户（名称/id等）

• 发生时间

• 行为类型：比如点击/加购物车/收藏/购买/分享等。

• 事件内容：比如手机-小米-小米Mix尊享版。

• 前向节点：比如分享页/活动页。

这里复习一下：

其实在设计用户数据结构时，用了面向对象的设计方法，并不是记录每次用户的下单过程，而是将用户的每个关键动作都抽象为“行为”这一相对普适的结构，这样不仅具备良好的结构性能，在后续数据分析时也会有更高的自由度和规范性。

由于有了更加高性能和更加稳定的动作采集、汇报、记录机制和技术，以及高性能的规模化数据存储结构，使得像上述对数据的实时规模化记录成为可能。

也正是有这些技术，推动了大数据的落地。

所谓大数据，并不是指数据多，而是指数据全，我们不再像以前那样，做数据抽样调查，纠结于抽样方法和样本数量，因为我们现在获取的是所有数据，基于全量做研究，得出的结论将更为可靠，且节省了抽样成本，这才是大数据的关键。

既然提到这个关键，多说两点：

第一是注意幸存者偏差，在数据收集机制的设计时，要考虑收集数据的片面性对结果的影响。

这里比较典型的例子就是今年的高考题之一的，关于统计战斗机弹孔位置来决定如何做改良的例子。

专家的错误在于，他即使查看了所有幸存飞行员所驾驶飞机的数据，得出的结论也是基于成功飞回来的样本，而忽略了那些在战场已经坠毁的战斗机数据。

这些数据反而才是最关键的——回来的战斗机，虽然机身那些位置有弹孔，但反而他们回来了，正说明这些位置中弹不会导致致命。

第二是注意收集正确的数据。

举个例子：

你看，用户起床时间的真正影响因素是节假日而非周一到周日。

以人类的聪明才智，这个点很容易想到，但是：

① 体现在产品设计中并不容易。我印象中IOS的闹钟都只能设置为周一到周五生效或者周末生效，用小米手机发现MIUI有优化，可以自动联网同步工作日和节假日数据，从而设置仅工作日/仅节假日闹钟，这也是被MIUI圈粉的一个小细节。

② 我们今天聊的是DMP，在算法模型做处理时，如果你在前端并没有设计要收集节假日和工作日数据，而只收集了星期数据，那机器再怎么学习，算法再怎么优化，也无法得出效的结论。这里的本质错误是没有搞清楚真正影响因素。

当然我们本来就是做数据研究，可能在一开始就是不明白，用户起床时间到底与什么因素有关。为了尽量在后续能够做全面有效的分析，在不了解的情况下，数据采集应该尽量做到维度的全面覆盖。

这时又会有另一个问题：现在还没发达到我们可以记录用户的每个行为的程度；就算有，在数据处理和分析阶段也会需要无限的计算资源才能够满足需求，怎么搞？

合理的解法是：在做系统设计之前，基于历史经验和人工模拟的实验，来进行影响因素的排除过滤和筛选。比如，我们大概率判断，国内用户的起床时间和当天国外的天气没关系，反而可能和今天堵不堵车有关系，如果不知道，也可以简单设计实验来做基本验证。

基于这些经验和预实验，能够极度简化模型参数，既不浪费系统性能，同时也保证了起始数据收集维度的正确性。

所以你看：我们该相信经验，还是数据？

我说我们该相信数据，但经验和数据不矛盾，相反，经验给大数据/人工智能提供了一条快速收敛的捷径，这些宝贵的经验让模型在一开始能有更好的初始学习条件。

所以你再看：产品经理的价值体现在哪里？

更多情况下，可能并不是参与DMP系统技术架构的设计，那些交给技术同学就可以了，产品经理在这里做了什么事，他基于经验和前期的模拟实验，更好地设计了DMP系统输入，指导了在数据收集阶段该收集哪些数据，这个价值远大于做具体系统架构设计，这才是真正的“设计性”体现，这才是真正的architect！

（2）数据处理

我们收集到的数据并不一定都是可用的。

对于电商来说，有可能有刷量数据（比如在店铺刚上线前期为了冲销量有很多假订单，甚至还会有竞争对手攻击而制造的假数据，还可能有由于设备不稳定性而造成的抖动等）；这些数据都是不可用的脏数据，一般都有比较明显的数据集中特征或者错误，运用这些特征，建立处理规则，即可清洗掉脏数据，避免对正常数据分析造成干扰。

清洗完成后并不能马上用于数据分析，这是因为有些数据比较原始，仍然处于“机器不可读”的状态，也不利于人工分析。

比如你采集到了用户在你的优惠活动H5页面的点击位置，想研究H5的UI设计与点击位置的关系。

那需要在数据整理阶段，将原始数据中的点击坐标数据做加工，根据规则，比如根据坐标范围划分为边缘/中心/上下左右等分块区域，对数据进行重新标记，这样你在分析时就可以直接看区块维度数据了。

同样，比如你想分析购买商品价位分布，那就需要提前进行划分，比如1-10，10-50，50-100，100-1000，1000+等等；

否则原始数据里，每0.1元阶梯上都有商品分布，最后根本无法收敛出结论。

这个过程，我称之为对数据进行结构化处理的过程。

数据处理的核心是基于一定的规则，对数据进行过滤和结构化处理，以使数据达到“可分析”的状态。

（3）数据分析

对数据基于一些统计或者计算方法进行分析。

在分析之前，需要制定合理的分析方法和分析指标。

分析方法多种多样，分类，聚类，维度交叉，漏斗分析，运用先前讲过的归纳演绎的方法，能够得出结论，在这里不进行展开，说下在营销领域常用的漏斗分析。

漏斗分析之所以叫漏斗，是因为从上往下，越来越小，每个过程都有折损。

大多数情况下，营销过程都是多节点的，不是一步完成的，每一步都会有流失。

比如广告展现了，不一定所有人都点击；有人点击了，又不一定会购买。

漏斗分析通过将整个链路打通，对每个节点之间的转化情况做分析，以便定位最终效果差的原因并作出优化。

另外多说一句：基于这几年比较火的增长黑客理论，又建立了反漏斗模型，在用户增长的结构中，每一步通过传播带来的增长越来越多，这种分析和漏斗又是相反的，也很有趣。

至于其他基于机器学习的分析方法，这里更不展开了，大家自己了解即可。

分析指标非常重要，合理的分析指标能够直观衡量事物和现象的质量和程度。比如互联网公司经常会使用到的增长率、活跃率、点击率等等。

举一个指标设计不合理的例子：

合理的指标设计，可以引入目标人群指数（TGI for Target Group Index）来衡量人群偏好。该指数的计算方式是目标占比/大盘占比，大于1代表正偏好，小于1代表负偏好。

引入TGI后，你发现，男性和女性的TGI均为1，与大盘情况相同，没有特征偏好。

而如果男女比例是9:1，那你会发现男性是正偏好，女性是负偏好，数值越大代表偏向越强。

这便是分析指标对分析结果带来的影响。

（4）数据运用

数据最多的应用是帮助决策。

上面已经举了很多例子，运用数据分析的结果，可以用于推广决策，内容推荐，流程优化等等。这里提一个比较有趣的，数据驱动产品迭代。

说来也确实是产品的“灵性”了。

我刚来时，主要负责广告投放系统，对广告系统的常见统计指标和优化方法有比较深刻的了解。

有次公司举办Hackathon（黑客马拉松，几个人组队，按比赛主题在较短时间内做一个产品prototype出来），主题是boost，加速。

在想我们要做什么，想boost什么的时候，我联想到：我们天天看点击率激活率优化广告，为什么不能用来优化产品？我们的线上平台，也有很多入口，有很多工具，有很多按钮，也会有点击率，那这些节点的数据，岂不是会对分析产品问题和功能优化有非常大的帮助？

于是，我们想了个办法，通过嵌入JS，扫描全部控件事件的方式，实现了线上产品所有控件的全监控，把每个用户行为和前后节点都进行了记录，并允许在前端将任何两个有关系页面的数据链接起来做指标计算。

这个产品后来也确实获得了大佬的认可。

这里有两个关键点：一是将数据驱动的理念用于产品优化，甚至在部分情况下能够做到自动优化。

现在一部分安卓手机能够根据用户对不同APP的打开频次和时间进行记录，并预测APP使用习惯，推断你可能在什么时间点将要打开什么APP，从而提前在后台准备好相应的程序，达到提升响应速度的效果，这便是一个数据用于产品优化的很好的例子。

二是在我设计的产品中，并没有太面向过程地考虑，如何进行处理数据，而是将数据条目本身作为对象进行存储和管理，这是系统的核心。

而在前端，不同需求的用户，可以将数据通过不同的组合方式、交叉维度、统计指标进行分析，具备极高的自由度，而它的前提便是我将每个条目作为可以搭出不同模型的最小块积木。

以数据而不是计算为核心，数据与分析进行分离，有需求者可以按自己需要的方式进行取用，是现在做数据类产品的一个不错的理念。

也没看过什么太多相关的书籍，我的方法也是在实践中逐步总结出来的。

翻过一本《数据驱动/从方法到实践》，初学者可以看看，浅显易懂，笔者花了总共不到一天的时间看完，觉得和我自己实践得出的结论还挺一致的。

数据驱动这事，更多还是靠实践，多进行收集/处理/分析/使用数据的实践，便能更快建立自己的分析方法和体系。

4. 价值判断

在公司里，作为产品经理，尤其是商业产品经理，想搞钱，就必须搞清楚短长期投入产出比。

理想情况下，想要的当然是一分耕耘，十分收获；但一来这个并不是那么容易的，二来是未来不可知，已经产生的投入，在什么时候产生价值，产生多大的价值，都是值得讨论的问题。

公司角度会考虑，管理者会考虑，作为商业产品经理也一定要考虑，普通工作也最好考虑——因为这样才是对自己负责，让工作价值和效果最大化，说不定还能涨点儿工资就美滋滋了。

在价值判断上，偏用户的产品经理和偏商业的产品经理需要考虑的维度也有所不同。

对于偏用户侧的PM来说，产品的价值是被人使用并且不断被人使用，是用户量、活跃用户量、功能使用率、使用时长、增长率等等，而对于偏商业的PM，更多考虑的是其变现价值，是否能够形成一种可长期持续赚钱的模式，是不是能形成一门生意。

说的极端了，商业产品经理没这么欠抽的。

to B的产品经理，考虑的更多是：如何通过产品能力的构建/升级，并且聚拢各方的资源和事，让一种“你好我好他也好”的模式能够持续转起来，能够持续赚到小钱钱——而这，也是业务思维，是成为CEO走向人生巅峰必须要想清楚的事情。

在结果导向的部分内容中，提到过数字价值和能力价值，这里再强调一下：产品的价值，一定不只是会体现在数字上，如果那样，直接搞销售得了，不需要产品。

效益增长，问题解决，本身就是有一部分价值无法用直接的数字衡量的，而这部分的价值，在不同的产品阶段，甚至远大于在数字指标上的提升。在进行价值衡量时，一定不要忽略掉这部分的价值。

5. 灵性

很玄学了，但灵性确实对产品经理非常重要。

能把上面这些思考能力运用自如，并且很有悟性，很聪慧，我觉得是有灵性。

它很难解释，但如果说，一个有灵性的人，会有什么样的表现和做事方法，我觉得是：能举一反三，能以一叶而知秋，能一眼看清楚事物的本质，能把自己获得的经验/能力/方法/工具，快速变换为解决问题所需要的形态，等等，我认为这是有灵性。

自己是个菜逼Dota2玩家，但偶尔也会看比赛录像，弹幕经常会夸某个选手某个操作“很灵性”：

是不是很神奇！

这两个道具是Dota2里最基本的道具之一，但玩家们都能有这样的骚操作：在不同的情境之下，用这两个道具来达到追捕/逃生/回血等不同的目的，我认为这就是灵性，能够将已具备的能力/思维/知识，快速转变为解决问题需要的形态。

灵性与一个人本身天然的思维模式和应激模式有很大的关系。

我只能说：如果有灵性，那一定非常适合做产品经理；如果没有的话，具备上述的思考能力，也能让你在产品工作中游刃有余。

———— / END / ————

———— / 推荐阅读 / ————

>> 你和高级产品经理之间，差的不只是经验

>> 在高级产品经理眼里，产品架构是怎样的？

>> 高阶产品经理做需求，和你做的差异在哪里？

>> 在高级产品经理眼中，好的项目管理流程是怎样的

>> 高阶产品经理都是怎么分析问题的，从一个叫车软件说起...

知识零散？经验不足？野蛮生长？

BAT产品大咖手把手带你

实战演练体验产品从0到1全过程！

点击“阅读原文”，了解更多信息