十年产品老兵：互联网产品经理的本质是什么？

编者按：本文来自微信公众号“辉叔说产品”，作者：辉叔，36氪经授权发布。原标题《互联网产品经理的本质（一）》，本文为“互联网产品经理的本质”系列文章第一篇

前言：

2015年就形成了互联网产品设计方法论，因为工作与生活种种，我写了又停，虎头蛇尾了几次。今年借着疫情在家，结合之前给去哪儿，车来了，瑞幸等公司的培训，逐步体系化的写出来，分享给要求分享的同事与未曾谋面的朋友。

另外也希望大家能够不断督促和反馈，让我能不懈怠，不偷懒地将研究思考所得，够体系化的整理出来，继续不断地提升自己。

热烈欢迎关注和吐槽！！！

自互联网行业的产品经理概念产生到被广泛接受，对于这个职业的内涵和外延有着多样的理解与定义。这些定义基本上是围绕产品经理的职责或者是定义了职责的外延，比如需求获取，产品设计、资源协调等。而从产品经理工作的本质如何定义产品经理呢？

结合我十多年产品工作的思考与探究，我心里的产品经理概念的内涵是这样的：

产品经理是通过自身特有的世界观、价值观的个人视角，洞察和解构现实世界，并能基于解构出的规律与要素，重构概念与逻辑模型，通过协作推动系统实现的方式，反映、强化、再造现实世界活动的人。

这个概念中，反映出了产品经理的5个任务，即洞察、解构、重构、实现、再造，下面分别说明每一个任务的核心内容：

1 洞察

产品经理要创造出成功的产品，被用户广泛接受和使用，就需要对客观世界进行洞察。“洞察”需要不仅仅观察客观世界的表象，更重要的是理解表象后的规律和逻辑，即为什么会这样。而谈到理解，不可避免的具有很强的个人性，这也是为什么产品设计无法完全标准化，但也充满了创造可能性的原因。

正如《俞军产品方法论》中描述的，产品工作更接近社会科学（例如社会学、经济学、心理学等），依赖于大量的经验和数据，但是无法真正重复验证。经验本身就是特定时间和空间条件下的个人性体验，这决定了特定时刻的个人视角（个人认知）；同时这些要素本身和一个人的世界观与价值观乃至人生观互为影响。

可以说，作为产品的主导者，产品经理个人的世界观与价值观下的个人视角，实质上影响着产品工作的需求发掘，用户识别，目标设定，范围定义，功能实现，交付推广，商业模式设计乃至产品调性等方方面面。套用当前流行的概念，即个人的三观和视角决定了产品的底层代码。

需要注意的是，这里特别强调是“产品的主导者”，作为执行者的差异化观点能在我们外部产品中看到的可能性很小。个人化视角或者价值观与世界观的产品外化，比较多在一个独立产品的从0到1的初早期，或者个人产品中容易被看到（鉴于这个特点，以及当前大量的产品经理实际是刚开始的从事产品设计工作的毕业生，我更倾向于将这个定义定位于“产品构架师”这样的一个称谓层面）。

比如一个对与陌生人交流愿望并不强烈的人就不太可能做出陌陌这样的产品；Airbnb也必然是两个偶然体验到共享住宿好处的人做出的；一个刚毕业不久的价格敏感的，但是旅游兴趣广泛、年假概念强的年轻人，会比一个经验丰富收入不错的产品经理，更有可能做出一个基于价格预算，推荐多个合适目的地的国际机票产品；不喜欢二次元的人做出B站的可能性微乎其微。

但随着产品的发展和组织的扩张，产品的惯性与积累的数据，一定程度上弱化了个人性的展示。但是这实质上是组织环境，与产品数据反馈，反向影响了产品经理的判断，即个人性的特征在这种条件下一定程度上趋同化。但是当没有数据支撑条件下需要拍脑袋决策，或者对数据有不同理解的时候，产品经理之间的分歧和争吵又会立刻展现出不同的价值观与个人视角的差异。

2 解构

如何体现我们洞察的结果？现代科学的基本方法就是要素分解和结构化，我们也使用这样的方法，即“解构”方法来帮我们完成“洞察”的落地。

解构就是将洞察到现象背后的本质，进行要素和逻辑与规律的分解：

要素的涵义显而易见，即客观事物的组成部分；

逻辑描述的是要素之间的关系；

规律是一类特殊的逻辑关系，反映要素变化产生的相互影响与结果（可能的概率），即要素间的动态关系。 

以一个房子为例，我们可以看到两个不同的个人视角，就会有不同的洞察和解构方式。从一般人的个人视角看，可以分解为：

• 要素：地，墙，房顶，门，窗户。

• 逻辑：墙需要垂直立在地上；房顶垂直立在墙上（暂只考虑与地面平行的情况）；门与窗都开在墙上。

• 规律：如果没有地面，就没有墙；如果少于2面墙，房顶就无法盖上（或者墙上沿长度小于房顶外延50%的情况，房顶就会掉下来）。

从力学工程师的角度，很可能就会被结构为（举例，具体分解未必贴切）：

• 要素：承重（柱或墙），房顶，分割墙，地面，孔洞

• 逻辑：承重（柱或墙）支撑房顶，承重（柱或墙）垂直地面，孔洞都分布于分割墙上。

• 规律：承重能力低于房顶重量，就会垮塌；地面能够有效承载所有承重，房顶，分割墙重量总和的150%。

在业务不断发展过程中，随着问题域的变更以及认知的提升，对事物的洞察和解构也是不断演进的，例如在国际机票在线销售（和一般的电商类似），洞察的范围主要是售前，关键要素就是品类（具象就是充分多航空公司、航线，航班）、价格（具象为舱位——行业上用来作为价格的容器）、库存（具象为该舱位的剩余座位数）；而随着用户出行的增多，对服务质量的要求提升，关键要素又增加了售后交付（具象为出票时间，出票合规性），所以产品工作中，又必须将这一新增要素和一同出现的新逻辑要纳入需求分析、产品设计的范围，从而引发产品的下一步迭代。京东自建物流的突进，实质上也是类似过程，将新的要素纳入问题域，产生了新的业务机会与产品形态。

3 重组

洞察与解构是对客观世界的认知过程。因为个人视角的存在，认知的要素与规律有所差异。同样由于个人视角，业务环境与目标，资源限制等原因，需要对解构的要素、逻辑与规律，进行筛选、组合、抽象升级最终选择成为构建产品最重要的基石，并进行概念模型的设计，形成产品的主骨架；并在此基础上实现逻辑模型，为系统实现奠定基础

A.筛选：

现实世界运行涉及到的元素众多，洞察与解构获得的是符合个人视角的重要元素，即要素。但是互联网产品是为了实现特定目的系统化成果。受环境影响和资源约束等，筛选出适合的关键要素，快速、高效地构建可运行产品，实现当前目标。

例如，用户坐飞机出行，买机票这一件事情，涉及的因素众多：

• 出发：出发地，出发机场，出发日期

• 到达：到达地，到达机场，到达日期

• 乘机人：人数，儿童和成人，特殊身份如海员，老年人

• 路线：直飞，中转，经停

• 航班：起飞时间，到达时间，飞行时间；航空公司，机型，机龄;舱位等级,舱位；座位数，座位分布

• 价格：价格，适用条件

• 库存：剩余座位数

• 政策：退票，改签，no show

• 服务：是否有免费托运行李，手提行李，餐食，餐食种类，餐食费用

• 会员：等级，权益，积分

即使这样罗列，我们实际上依然忽略了很多现实中的元素。

虽然出行过程中这些都会涉及到，但解构后，诸如乘机人特殊身份，机龄这些都并不成为要素，所以我们可以剩下：

• 出发：出发地，出发机场，出发日期

• 到达：到达地，到达机场，到达日期

• 乘机人：人数，儿童和成人

• 路线：直飞，中转，经停

• 航班：起飞时间，到达时间；航空公司；舱位等级,舱位；

• 价格：（舱位）价格，适用条件

• 库存：剩余座位数

• 政策：退票，改签，no show

• 服务：是否有免费托运行李，手提行李，餐食，餐食种类，餐食费用

如果我们是一个刚刚开始提供机票在线预定产品，目标是让用户买到最便宜的机票，那么实际上产品中所必要的概念就大幅度减少，诸如舱位等级，舱位这种多级别价格、服务与政策可能就会被忽略或者简化，从而得到了这样一个系统概念模型中最重要的概念：

• 品类

• 出发：出发地与日期

• 到达：到达地与日期

• 乘机人：数量

• 路线：直飞，中转（经停）

• 航班：起飞时间，到达时间；航空公司；

• 价格：（最低舱位）价格

• 库存：剩余座位数

• 约束说明：政策与服务

从现实生活中的元素可能由于筛选掉，造成了一些用户诉求的无法满足，但这些诉求往往是比例很低，且对主要目标没有什么影响的。对这些的忽略，虽然给个别用户觉得不便，但是却能够帮助我们更快速、更低成本实现满足用户需求的、甚至是架构精简的产品。

筛选也不一定是减少，也可能是侧重，比如电商重要的要素，品类，价格，库存，交付。侧重品类弱化库存和交付，“逛”的业务形态可能是最佳匹配；侧重价格，比价或者尾货可能就是一种选择；侧重库存，拍卖是一种可选形态；侧重交付，物流或者保险就尤为重要。

B.组合：

现实世界的人行为千差万别，如果我们通过解构出的要素（维度），进行组合，往往能发现很多我们之前没有意识到的用户、市场和需求，并构建出新的产品概念模型。

还是以购买国际机票为例，我们从另外一个角度解构的要素如下：

• 地点

• 出发

• 到达

• 时间

• 预定时间

• 出发日期

• 到达日期（暂定被动结果）

• 乘机人

• 9人以下（一般零售）

• 价格

我们通过筛选的方法，将现实中用户对起飞时间和航空公司的偏好忽略，产品目标是帮用户找到满足条件的最低价机票，这里我们选择用函数来表示这个系统的概念模型：Min P（最低价格）=f（出发地，到达地，预定日期，出发日期，乘机人数）。

一般我们认为一次机票购买行为上述对应的要素都是确定的，比如：4月29日购买6月1日3张北京到巴黎的机票。函数表示是：min P=f（北京，巴黎，4月29日，6月1日，3人）.

当我们突破要素（即函数参数）通常的取值域限制，例如将巴黎替换为欧洲，函数变为min P=f（北京，欧洲，4月29日，6月1日，3人）；需求变成了4月29日预定从北京到欧洲任意城市3个人的最低价机票。这种实质上满足了愿意去特定区域任意城市的用户的最低价机票需求。

如果将出发日从一个单一日期变为一个月，则函数min P=f（北京，巴黎，4月29日，6月，3人）描述的是希望6月北京去巴黎的最低价需求。这个市场是时间弹性足够宽裕，目的地明确的低价用户市场。

一个问题，如果将预定时间变为4月29日到5月15日这个时间段，那么原函数描述的需求是一个什么样的需求呢？

上面可见，同样的因果关系，重新组织要素的取值域或者粒度，就会描述出新的需求与市场（不考虑市场规模和可实现性）。而再进一步我们可以将因果关系重组，函数变为 D（到达地）=f（出发地，预定日期，出发日期，乘机人数，价格限制），同样的要素，不同的因果关系，描述了有限预算条件下的弹性目的地诉求。

组合可以将解构的要素与逻辑通过新的组织模式，模拟并解释现实世界中各种不同的市场、需求和现象，从而能够帮我们发现被忽视的机会，或者带来新的机遇。

C.抽象升级：

我在本科学习计算机时，对面向对象编程课本中记忆最深刻的一句话是：抽象，是人类认识世界的最主要的方法。

百度百科对抽象的定义：抽象是指从具体事物抽出、概括出它们共同的方面、本质属性与关系等，而将个别的、非本质的方面、属性与关系舍弃的思维过程。

解构本身就是一种抽象，重组过程本身在构建具有共性的模型，更是一种抽象：筛选与组合也是对解构出的要素的简化或逻辑泛化，是对客观世界的进一步抽象。而抽象升级，是更高级别的抽象，提出更高级别的共性，对个人能力的要求更高，同时也会帮助产品经理更深入理解业务的本质，让产品具有更强的韧性与弹性、更强的前瞻性，让系统具有更强的扩展性与稳定性。

以交易流程概念模型为例，我们最常见的流程是：

A 用户下单->用户支付->合同成立

但是在短租业务刚开始的时候，最普遍的交易主流程是：

B 用户下单->商家确认（或拒绝）->用户支付->合同成立

后其发展出了新的流程，包括现在很多酒店预定平台上依然存在这个流程

C 用户下单->用户支付->商家确认（或拒绝）->合同成立

三种不同的业务环境出现了3种交易流程：

• 在商品库存信息高度可靠、价格不易变的环境下，A的流程是最有效的流程，减少人工干预环节，所用时间最短。

• 像短租业务（初期）的情况，系统中房间库存数量少，且与其他实际上是共享，经常出现数据失实（脏数据）；或者价格波动很快，则最稳妥的流程是B，用户支付之前需要商家确认下单的信息（库存与价格）有效性之后，用户再去支付，成功率更高，虽然缓慢，但是用户体验更好。

• C介于B和A之间，即库存与价格数据准确率有一定提升，因为数据过期造成的用户拒绝的损失小于用户一次完成下单与支付的2个动作带来的收益，则C是B的提升版本。所以这种交易流程现在常见于数据共享的酒店业务。

可以看到B->C->A是一个逐步升级的过程，而恰恰也是业务不断演进，系统率提升的带来的产品与系统的进化。但是如果每次业务升级带来的系统进化，会带来大量的升级成本。如果能站在更高的抽象层面上，提供一个更具有通用性的要素与逻辑视角，那么系统就会具有更高的适应性和稳定性。

D 用户下单->商家确认1（或拒绝）->用户支付->商家确认2（或拒绝）->合同成立，这样一个通用性流程就是这样一个抽象升级的模型。只是在具体业务场景下，商家确认1或者商家确认2是否是自动确认的差异，只需要通过系统简单的参数控制即可。

从更本质上的认识上看，为了避免因“用户看到信息，用户下单，用户支付”之间的时间差形成的过期信息造成错误交易，商家确认行为才不得已出现在交易流程中。从这个角度抽象，D其实就是最直接的抽象流程，具体哪里需要商家确认的动作，只是根据具体的业务环境、数据变化程度，做的选择，所以ABC只是D的特例。

现实中D流程本身实质上也是被应用的，比如机票由于全球销售都共享库存与价格，所以变化极快（很接近中国春运的火车票），只是已有的平台对于商家确认1和2都使用了特定条件下的自动化拒绝，加快预定流程防止数据变化进一步恶化结果。

而这也是用户为什么在机票预定领域经常会遇到搜索到的价格，甚至下了单的机票，下一步就失败的原因。因为用户认知上应该和A流程一致，但模型上本质的不同引发的超出预期反馈，往往会造成用户的误解（当年应对的许多投诉与媒体抨击都是源于此）。

作者简介

辉叔

一个互联网从业10余年的老产品，曾经从0到1打造了小猪短租（产品联合创始人）；也作为去哪儿国际机票总经理负责完整业务与团队。希望通过公众号，将个人的产品观点、方法与经验，以及学习到的真知灼见与高级智慧分享、并帮助到每一个关注的朋友。