产品经理求生指南

文章插图
去年12月份，在疫情弥漫的悲观情绪里，和前同事进行了一次关于产品经理面临失业的讨论之后，我写了一篇文章《会是谁最后干掉了产品经理？》，文章很直白的表达了“我需要努力找到一个产品经理不被替代的理由。”一晃又过去了半年，我或许找个了一个产品经理“苟活”的更好的理由，并且我不希望这是唯一的一个。
一、“天问”困境产品经理的“天问”困境，我是谁，我在哪里，我是做什么的？让我重新再想起这个问题是我在搭地铁的时候，又看到熟悉的、印在T恤上如程序员slogan一样的句子：Talking is cheap，show me the Code 。这句话来自Linux 的创始人 Linus Torvalds，他在 2000年8月25 给linux-kernel 邮件列表的一封邮件提到了一句话，后来不知道怎么就变成了和“hello world”一般的存在。
而我，一直觉得这句话是程序员小哥说给产品经理听的。于是，我就很自然的想起当初转做产品经理工作后，有相当长的一段时间，我都一直没有一个很好的答案来回答家人和朋友关于“产品经理到底是干什么的“这个问题。那个时候它还算是个新生，最起码算是小众事物（相对的），特别是在互联网（包括软件）行业（区别是消费品行业）。哪怕到现在，虽然都知道产品经理是个什么工种，日常做些什么，但或许依然并没有一个很明确的概念，可以很条理、舒服的讲给别人听。
一个可能很关键的原因是：我们的企业、行业对于产品经理的定位本身就不是很清晰。这一点大家去招聘网站上看看各家企业在招聘产品经理岗位的工作内容和能力描述上都能够窥得一二（当然，我不保证这些JD不是互相抄来的），大体总结起来就是，既懂又懂，既会也会。具体来说就是要求产品经理在能力和经验上，同时兼具程序员、视觉设计师（UI）、交互设计师（UE），但又无需向他们那么专注和专精。
诚然，产品经理在实际工作中，与程序员、视觉设计师（UI）、交互设计师（UE）的工作都有交叉（或者说是深度的交叉），乃至和运营经理的工作也有交叉，但这种定位的模糊，很自然地使得产品经理与其他工作相比而言缺乏独立性和完整性（如果在每一交叉项里太深入了，又偏离了产品经理本身的定位）：

与程序员相比不会代码，不会编程；
与视觉设计师（UI）相比，对于界面规范、设计原理和软件的使用又没有那么专业；
与交互设计师（UE）相比，对于人机交互、界面交互规则、发展变化趋势的了解也没那么深入；

所以，鉴于企业对于产品经理的定位与要求，产品经理无疑需要去了解和学习这些可能与自身“独立性“不太相干的内容。再扩大一些，至少按照目前行业的惯例，作为产品owner的产品经理，同时也是产品实现过程的组织者、协调者和推动者，这一职能本身严格意义上来说，是项目经理的工作，产品经理无疑在这里又产生了一次交叉。于是，在这一个又一个的交叉里，产品经理到底是做什么的，愈发模糊，无所不做却定位尴尬。
二、不知山中“不知庐山真面目，只缘身在此山中“ 。原谅我根据古诗词生造了一个成语。不知道是谁开的解读先例，这句诗绝大多数时候都被当作哲学的思辨来使用。生活的经验也告诉我们，对于事物的了解可能正需要超脱一些，跳出来，再看回去，方有可能发现问题的核心。
【产品经理求生指南】跳出产品经理的日常的工作之后，我尝试做了如下的推论：
问：所有的代码编写、UI和UE设计，它们的目的是为了什么？
是为了产品，为了产品（功能、交互等）的实现。
问：那么，产品实现是为了什么？
是为了用户，服务用户的使用。
问：那么，服务用户是为了什么？
是为了公司赚钱，商业利益的达成。
Bingo！如果这个“倒推”成立的话，或者说可以按照这种方式来穿透产品实现过程的话，产品经理最根本的职能，应该是为实现一个产品的商业利益服务，在此过程中的每一个工作点都应该是围绕这个目的而进行的，也应该是以此作为出发点和最终落脚点的。但是，作为“埋身”的具体日常工作，往往都是为了追求效率和质量的精细分工，是为了目的快速高效达成而进行的分包和拆解，这个“潜藏”的核心点在实际工作的过程中让产品经理很难去关注到。更为严重的是，就像抄袭JD一样，这个目的被慢慢地有意无意地被漠视了、忽视了。
三、回归如果产品经理的定位应该在商业利益达成的逻辑成立的话，那么产品经理的视野、时间和精力就都应该在向商业利益和商业利益的实现来倾斜。而商业利益的实现和商业目的的达成，第一步应该是商业模式的构建，或者说是对已有商业模式的理解。所以，当然不是写代码、不是UI，也不是UE，商业模式的构建和理解才是产品经理最核心也是最基本的职能和职业技能。
1. 那么，商业模式是什么？按照MBA智库对于商业模式的定义：

为实现客户价值最大化，把能使企业运行的内外各要素整合起来，形成一个完整的高效率的具有独特核心竞争力的运行系统，并通过最优实现形式满足客户需求、实现客户价值，同时使系统达成持续赢利目标的整体解决方案

说的简单一点，商业模式是解释和说明一家企业、公司，或者一个组织如何利用发现的市场机会，通过一定的组织方式，创造价值并变现的一个方法。用更直白的话来说，商业模式就是说明通过什么途径或方式来赚钱。
2. 商业模式的构成商业模式这个东西是随着商业存在而一直存在的，简单来说，我们”种菜卖菜，卖菜买菜种再种菜卖菜“就是一个很清晰的商业模式。但就一种模式而言，略有些简单了，所以”古早“时代也并没有人提出商业模式或者类似的东西。
直到近代，随着商业和竞争的发展、以及更精细的分工，商业模式的概念才逐渐出现和明确。商业模式的差异决定了不同的市场或者经济的参与者采用不同的方式、通过不同的产出、在不同的“节点”参与社会、经济分工和竞争。在这个过程中，有几个环节或者说要素构成了一个商业模式的核心，或者说，这几个要素的差异构成了商业模式之间的差异。这几个要素分别是：目标客户、价值主张、核心能力、合作依赖、盈利模式。这几个要素以某种类似“线性”的方式粗略的串联起一个商业模式的构成。
如果对于商业画布有过了解或者研究的同学，肯定对于上面的几个要素感觉到很熟悉，实际上商业画布就是用来描述和呈现一个项目的商业模式的，所以，商业模式分解开来就是根据这些核心要素来解释，这个商业项目是什么、通过什么方式在运作、通过哪些条件来支撑、如何达成收益等等。

文章插图
3. 产品经理与商业模式产品经理日常的工作并不与商业模式相关？这或许是个问题。翻看我们每天的日报、周报和月报，以及可能占用了我们绝大部分工作时间的各种会议，就会发现产品经理绝大部分的工作内容、工作目标都是具体项目的实现的管理，包括时间上的、效果上的，具体小到一个按钮位置，大到一个APP的上线发布。
日常的具体工作在时间上和效果上的要求，在某种程度上限制了产品经理对于其他问题的观察和投入，换句话说，正是限制了对于”产生这些具体工作的原因“的关注。估计有同学觉得我说的不对，因为我们对于产品、功能的优化都是有着清晰的路径和依据的，这个路径和依据最基本的就是每个产品的版本规划和需求池管理，以及我们在功能和产品发布前所设定好的相关预期数据指标，比如下载率/量，留存率/量，转化率/量等等。但是这些作为直观的、可量化的KPI指标的满足只是我们日常工作的直接原因，而既定商业模式需要的满足才是根本的原因。也就是说，我们的目光盯在KPI指标的时候，更多是在完成一个定量的”实验“，而不是一个理论的实践。
产品经理一起吹牛逼的时候会提到一个形而上的词 “产品sense”，目前这个词似乎还没有一个很严格的定义。狭义来说，可以理解为在缺乏竞品参照或数据支持的情况下，对产品功能、操作流程及用户体验的主观预判，因此也大致可以归类到我们说的“实现”的层面。与之相对的，我认为还可以有另外一个词，姑且先叫做“商业sense”，它主要用来定义对于商业机会的发现，并能够将其具象化到目标客户、价值主张、核心能力、合作依赖、盈利模式的确定上。当然如果我们把产品的概念放大，我认为广义的“产品sense”应该是包含“商业sense”这部分内容的。所以，这也就是产品经理对于本职的”商业模式“的理解和把握的题中之义。
要提升“商业sense”，一方面是需要在日常的产品工作中，适当的分配或者额外增加时间对企业所在的行业的了解，基本上包括自己产品在同业竞品中的位置、同业产品之间的差异、造成这些差异的可能原因（是在目标客户的细分上有差异，还是核心能力上的绝对差异，或者说是由于核心能力不足，对于合作依赖的需要）。
除此之外，对于行业所在产业的上下游也同样需要适当的了解，因为在当前社会分工精细化，专业化的原则下，每个行业都是整个产业链上的一个节点，既接收上游行业的产出物作为“生产原料”，又向下游行业提供自己的产出物。因此，对上游行业的了解对于自己稳定获得所需的”生产原料“至关重要，上游行业的变化很可能意味着自己的商业模式需要进行对应的调整；而下游行业（终端用户/消费者）的需要，决定了所提供的产品和服务的被接受程度和价值定位，也直接关系着商业模式的成功。
由此做适当的推导，直接上游行业也必然会受到上游的上游产业的影响，而下游产业也必然会根据其下游（直至终端用户）的需求变动而调整，也就意味着，作为产品经理需要对于整个产业的商业模式、整个产业的发展变化、整个产业的发展态势等有一定的认知和了解。
要提升“商业sense”的另外一个方面，是对于自身产品和自身能力的理解和定位。具体到商业模式的要素，对应的关键因素大致是核心资源，即满足产业上下游需要且区别于同产业节点上的其他竞争对手的独占能力，更直白一点说是在能力上的竞争优势；当然更广义的来说，重要伙伴（合作依赖）应该也可以包括在内。其他的核心要素，都在不同的维度，描述了产品自身在商业语境下意义。在了解行业、产业的前提和基础上，对于自身能力的理解，能够有效地“锚定”自身在行业、产业中的位置，帮助产品经理进行产品决策和规划、执行产品实现路径时进行有效判断，进而对于选择进入、退出、加码或者放缓在行业或者产业节点、阶段的选择上提供不同于数据指标意义上的决策辅助。
当然，产品经理并不是要脱离日常的工作来考虑商业模式的问题，相反是更需要基于功能实现或者产品实现的工作内容去考虑这些问题。这些问题的考量，可以更好地帮助产品经理去理解当前的工作为什么要做，除了了解达成产品的“战术指标”之外，它的“战略”目标是什么，知其然且知其所以然。
另外，在考虑这些问题的时候，通过对更深层原因的了解，理解，更大的意义还在于有机会获得更好的问题解决的方法、更佳的业务实现的路径。因为往往我们会发现，比较两个同样可以有效解决问题的方案的好与坏，判断的关键往往并不在这个方案本身上，而是制定这两个方案的时候参考的信息的多少，信息维度的多寡，解决方案所面向的“用户”的多样性和覆盖能力。
也就是说，在日常的以“实现”为目的的产品经理的工作内容中，对于行业、产业的商业模式的理解是有益于更好的完成工作的。当然，对于商业模式的了解和理解，并不一定是要求产品经理去制定新的商业模式，产品经理首先是商业模式的实际的构建者，当然不排除是未来商业模式的变革者和创新者。
四、寄语，包括给自己的产品经理去关注商业模式，似乎恰好“印证”了产品经理的上限是CEO的说法，但我个人觉得其实并不完全是，并不是所有的产品经理会把自己未来的目标定位在CEO 。我感觉，说产品经理是产品的主人翁还是更妥帖，不管是服务于一个功能，一个产品，还是一个商业模式，都是owner的角色，通过实际的工作，先把这个行业，产业或者说赛道想清楚，表述清楚，再通过产品、服务去做清楚。CEO说破天就是个岗位，并不是个职能。