00.前言

理解车联网需要产品视角

近十年来，中国的汽车保有量增长迅速，无论是市场环境、技术环境还是政策环境，都不断在发生变化。巨大的不确定性总是带来巨大的机遇和风险，车联网产品随着各类不同背景的厂商进入，变得热闹非凡。良莠不齐的玩家，夹杂着炒作和欺骗的各类新概念，让公众对车联网的理解变得非常模糊，即使是擅长抽象和完善概念的产品经理人群，面对快速发展的车联网市场，也很难就“车联网产品”的内涵和外延达成一致。不过对一个新事物来说，对基本定义的明确过程，也是创新产生和发展的过程。

附图：百度指数中的需求图谱

研究方法

本文尝试用一个定性的分析框架，从产品视角来理解车联网产品，大致分成以下几步：

1、列举正在发生的可能影响车联网的事件
2、建立围绕“车”的基本模型，推导出“车联网产品”的场景
3、结合 1 和 2 的结论，得到“车联网产品”的基本架构
4、通过“车联网产品”的基本架构，分析BAT的实际产品布局
5、预测市场，给出一般性建议（可能滞后且无用）

01.推动变化的事件列举不完全

建立一个四象限图，横轴是对产品影响的不确定性，纵轴是影响的高低，将事件分类为“技术”、“市场”、“环境”、“渠道”、“产品”几类，并放置在象限图中。右上角“影响”高且“不确定性”高的事件，需要重点关注，产品创新通常来自这个区域的事件刺激。

附图：影响“车联网产品”的事件，受限于精力和能力，列举和分类都会有疏漏

附图：近10年来，中国私人汽车拥有量的变化，数据来自国家统计局

02.车联网产品的一般场景

在经济学家薛兆丰的眼中，“产权”是通过“使用权”、“收益权”和“转让权”三个权利来实现的，借用这个概念，我们可以将“车”这个产品的内在，分为两个部分：“工具属性”和“资产属性”。

从工具属性上看，“车”是“人/货”的搬运工

对于“人”而言，可以有两种角度来看待“车”，但本质上都是“出行场景”，遵守“连接/分发”的商业模型。“出行场景”中的车联网产品是市场热点，BAT等科技巨头的主力产品，也大都是这个领域的。

1、“车”是“人”的一类空间，是独立于“工作”、“生活”、“娱乐”之外的空间，随着汽车保有量上升，人群在这个空间上花费的时间同样在急速增加，会产生大量的消费机会。

2、“车”是空间与空间相联系的管道，出行增加了“空间”和“空间”之间的连接，使得人们可以进入更丰富的消费场景中。而且这种空间之间联系的增强并不是消费机会的线形增加，而是可能创造新的消费机会。

附图：“人”相关的车联网产品场景，图中的“产权”是指狭义的车辆登记产权

对于“货”而言，是“产业场景”，之所以不称为“运输场景”，是因为这类场景中，还有丰富的采集或分发行为。常见的产品应用领域有物流、仓储、农业、环卫、工程、矿业等方面，除物流和环卫领域外，其他应用领域还有一个显著特点，就是车通常在封闭空间中运动，人的活动很少，非常适宜 Level 4 的无人驾驶技术应用。

“产业场景”在互联网环境中被讨论较少，但市场规模总量巨大，车联网产品与面向个人消费者的产品形态差异明显。

从资产属性上看，“车”是实体资产和数据资产的总和

实体资产是指车这个实体的价值。无论是乘用车和商用车，在通常情况下，实体资产的价值都是一条不断下降的曲线，我们已经可以通过二手车交易的大数据，通过算法基本确定这条残值曲线（新能源车的残值曲线与汽油车有明显不同，受到电池残值的影响）。

数据资产是指车在各类场景中被“使用”，使车成为数据产生和处理的基本节点（一种边缘计算），这些数据的价值可以被挖掘（也可以在云端）出来，数据资产曲线与实体资产曲线相反，不断增值，还可以被物联网放大。

我们可以做这样一个论断：

车联网产品之战，胜负关键是争夺不断增值的数据资产

这场玩家众多的战役，有三个重要的子战场：

1、对实体（车/人）的争夺，数据入口
2、对数据传输和数据处理权的争夺，数据管道
3、对消费场景的争夺，数据应用

在数据入口战场里，关键策略是生产车辆，从源头控制。玩家有传统主机厂、互联网造车新势力、地产/能源/家电巨头（恒大、宝能、格力等）。

在数据管道战场里，关键策略是控制数据采集和处理。玩家有车联网云计算服务提供商、车载OS或车机设备提供商、电信运营商，如华为、BAT的车联网部门、部分创业团队。

在数据应用战场里，关键策略是控制消费场景的供给。玩家有滴滴、BAT的内容部门或O2O部门、部分创业团队。

03.车联网产品的基本架构

车联网产品的基础场景，决定了产品视角的车联网产品定义：车联网产品，提供有关“车”的数据产生、处理、传输、应用的解决方案。结合01.推动变化的事件中重要且不确定性高的各类事件，得到一个基本的架构。

附图：侧重C端车联网的基本架构表述

数据在车联网产品架构里的流动

1、数据采集，实际上就是数据源，数据产生在很多位置

车内：主要是车机，通过车内的各种感应器和前装记录设备，记录车的使用数据
车外：通过外设，如无人机、空气净化器、行车记录仪等，记录车的环境数据
车与车：通过云端或者车车通信，记录车的使用数据和环境数据
车与人：通过人机互动，或者是手机等移动设备与车机互联，记录人与车互动关系
车与云：记录车与环境互动关系，包括与城市、路网、产业场地的互动

2、数据处理，可以在车/手机/云多端处理

从外部政策环境看，二手车出海和鼓励电动车消费，都会带来车辆更新，更多感应器和处理器会被安装到新车上，促进了车作为终端的数据产生和计算能力，这是硬件层面的提升。在软件层面，新车都安装了智能的操作系统，利用硬件的能力大大提升。软件方面的成型产品非常多，如阿里的斑马智行、百度的小度车载OS、腾讯的车联网生态解决方案等，后面会更详细给出架构图。

附图：华为公有云车联网解决方案

数量巨大的存量乘用车和商用车市场，也可以通过后装一些设备来升级数据采集和处理的能力。常见的车载一体机方案，需要对车做小量改装，产品质量良莠不齐，市场表现一般。近几年兴起的智能后视镜和智能行车记录仪，车主可自助安装，功能强大且价格低，市场表现良好，甚至还有智能车载支架这样的几十块钱的产品出现，极有可能为数据采集和处理提供新的机会。

3、场景识别，数据处理的目的是为了识别场景，在具体的场景中让车做出对应的“动作”

C端方向上，腾讯的车联网场景定义如下，

出行场景：通勤、出游、拥堵、……
娱乐场景：听歌、小说、游戏、……
车生活场景：停车、加油、违章、……
社交场景：车载微信服务、约会接人、……

B端方向上，物流、仓储、农业、环卫、工程、矿业等场景都可细分出来不同的应用场景

4、消费，场景识别是数据应用，消费则是数据变现

C端方向上，腾讯的车联网场景定义对应着两类消费，一类是内容消费（关键是内容生态），一类是实体消费（关键是消费场景丰富性）。这两类消费的核心控制点，都是支付能力及整合人车数据的超级ID。

B端方向上，消费是指结合产业特点，提高产能/运力的能力，对商用车市场研究很少，不展开。

04.BAT的车联网产品架构

超级ID取胜的腾讯

虽然腾讯车联网在媒体采访中，不强调微信作为超级ID存在的强势地位，可能为了避免主机厂的反感。但实际上，车载微信可以安装在任何以安卓为原型的车机设备上，利用腾讯本身已经有的内容生态（阅文集团、QQ音乐、腾讯视频等）、线下服务生态（美团和京东等），支付能力，覆盖掉主机厂的前装优势，成为车联网的入口。同时，微信作为一个ID，可以将用车人的数据，无缝迁移到任意安装有车载微信的车辆上，这个优势在未来车辆使用权越来越重要，产权越来越不重要的趋势中会被放大。

附图：腾讯生态车联网解决方案

无人驾驶技术领先的百度

百度的车联网产品布局也非常完整，以Apollo开放平台为核心的自动驾驶解决方案切入，更容易与主机厂达成合作。弱点是内容生态、线下消费生态、支付能力都较腾讯和阿里单薄。优势是在产业车联网这个方向上，比腾讯和阿里走得更远，产业方向对内容、线下消费和支付能力要求较低，对自动驾驶、路径规划、产业能力整合上要求较高，百度已经有一些实现。
附图：百度车联网平台和生态

平衡的阿里

阿里入局很早，与上汽合作的斑马智联进入市场好几年。在超级ID方面，有淘宝支撑；在内容生态上，有优酷土豆、虾米、大麦等；在线下消费能力上，有口碑和飞猪；在支付能力上，更是有强势的支付宝。产品架构上，与腾讯的布局基本一致。

05.需要回答的问题及可能无用的市场建议

地理空间的大小，影响消费形态

汽车市场下沉，广大三四线城市和农村地区，单次出行时间较大城市短，环境熟悉，一般不需要导航，也不需要长时间在“车”空间里的内容消费，线下娱乐消费场景不依赖线上流量。在这样的场景中，在供给侧的内容形态和线下消费生态，都需要哪些变化？

长时间的出行场景也有不同

路线固定的通勤和路线不固定的出游，都是时间较长的出行，潜在的是打发时间和节省时间的不同需求，可能产生需求的“人”都不同，是重视“驾车人”还是重视“乘车人”？

增量市场和存量市场

增量市场受到经济大环境的影响，商用车联网和存量车辆改造，可能是数据富矿。

车联网+区块链+金融，也可能是组合式的好应用。

躲不开的“手机也可以”

手机作为最流行的智能终端，性能强，更新快，如何跟车机形成合力？是否会出现车机只是屏幕和传感器，手机才是数据关键节点的形态？

信息量极少的洞察

由于更换车机系统的难度和成本高，造车可以锁定系统，所以BAT们纷纷投资造车新势力，也纷纷与传统主机厂合作。5G带来的很可能是车机系统切换的成本大大降低，也提升了造车者们的话语权，优先需要确定的，是数据的产权。

06.End

如果对目前的车机系统感兴趣，可以参考易车有一个《车载互联系统专项评测》系列。

起因：

在某一个周末，跟在凡影的工作的前同事小航聊天，说到电影咨询的一些市场基本情况。有一个重要业务是通过问卷调查，研究即将发行的电影，是否受欢迎；也提到现在的剧作者，越来越重视消费者喜欢看什么，IP创作从极个人化的方式向市场导向转变。我结合之前做音乐个性化推荐的经验，提出了一个通过分析剧本的文本，在拍摄之前就大致预测受欢迎程度的思路。

北京凡影科技有限公司（凡影Fanink），电影行业专业的调研公司，很多电影都是他们的客户，比如《流浪地球》

思路：

基本思路是这样，通过分析影史 top1000 的电影剧本得出受欢迎剧本的基本特征，结合对大众对故事性的一般理解和时下风尚，就可以预测新剧本是否欢迎，同理还可以用作网络小说的预测。

什么是好剧本？

一个好剧本，应当是剧作者具备相当的文字功力，会讲故事，台词废话少，能用合理的篇幅表达人物和冲突，总结起来应该具备下面几点：

人物突出

• 每个场景中出场的人物数量合理
• 台词集中在主要人物身上
• 台词符合人物设定

节奏合理

• 场景数量合适
• 台词密度合适
• 冲突段落位置合适

情感传达到位

• 台词符合剧本基调
• 人物情感饱满

怎么从剧本文本中判断？

从好剧本的要素来看，需要通过剧本文本判断出很多内容：

• 人物数量
• 人物之间的互动频次
• 场景数量
• 场景台词密度
• 场景情感倾向

通过获得大量的剧本文本，通过机器学习的技术，剧本本身的一些规范以及开源的各种NLP库支持，应该是可以识别出来的，我找到了小伙伴振民和晓峰，说起这个基本思路，他们觉得可以业余时间试试看。

阻碍：

现实还是骨感的，我们都不是这个行业里的人，资源和思路上都有局限性。

1、一个电影或者电视剧的流行，剧本很重要，但也只是其中一部分，还要考虑导演、演员、宣发等各要素。
2、优秀的剧作者不需要这种机器分析。
3、最关键的，我们拿不到大量的剧本素材，机器学习无从谈起。

思路转变：

既然剧本拿不到，就只能找一个替代品，我想到的是字幕。字幕文件里有对话文本和对话发生的时间，更接近电影播放时给观众的感受。如果将视频的整个时长当作一条时间线，可以这么看：

1、对话发生的时间区间，将对话发生密集的位置，当作视频核心场景。
2、在核心场景中，计算台词的密度。
3、分析人物数量是比较困难的，准确的需要通过剧本或者分析视频获得。
4、对话中包含大量“你”、“我”、“我们”等代词，可以用来分析对话。

代价也是有的：

1、字幕不包括人物名称，需要单独分析，有相当难度。
2、大量影片的出彩之处是演员的肢体语言和表情，没有台词，也就没有字幕可以分析。
3、场景切换也需要通过其他方式来识别，除非排除“场景”这个要素对剧本质量预测的影响。

实际上，如果有弹幕数据支持，这个分析会更好做，那是B站的活。

工作：

主要的工作都是用振民同学完成的，我们指定了目标网站，购买了服务器，他写了爬虫，去获得字幕和电影评分等数据。其中的过程略去不表，倒是有几个发现：

1、字幕大佬射手网停了，原有的电影和电视剧字幕，也被用作深度学习的训练材料，不过是翻译方向的。
2、并非只有我们想到了分析剧本这个方向，优酷认知实验室有一个叫做鱼脑团队也在做。

不太好的结果：

还是因为我们并没有这方面的经验，彼此的时间也都不可控，断断续续进行了一段时间，进展不理想，距离分析预测剧本还差很远。这不是一个文本相似度的简单计算，而是剧本内容的高度抽象，不花时间思考和实验，不会有好结果。

意外插曲：

中间还发生了一个意外，非常有趣。有一天意外（我确实忘记是从哪里）得到了一个几千部电影字幕的压缩包网盘地址，于是兴致勃勃在服务器上下载回来，结果发现是岛国特产电影的字幕，字幕文件名就是车牌号，本着“下都下好了”的精神，我们决定聚类一下看看会出现什么情况，振民同学在排除掉高频无意义的词之后，得到了28个分组的结果，当然分组内容很有意思，也大都是不可描述的词语。

再次转变的思路：

剧本和电影字幕太复杂了，我们决定从我最熟悉的歌曲角度入手重新设计，歌曲的歌词字数少，对歌曲受欢迎程度的影响更大，且LRC格式的歌词，同样有时间标记。我们干了下面几件事情：

1、因为过去长期在数字音乐领域，很容易就得到了大量的歌词文件。
2、爬了某音乐网站引以为荣的歌曲评论文本。

总的来说，基本假设是歌词的质量和情感倾向，是影响歌曲流行程度的重要因素。歌曲评论的情感倾向，与歌词的情感倾向一致性比较强，也就是说歌词写得好，共鸣更多，更易流行起来。少数收到特定事件和文化背景因素影响的歌曲，歌词与评论的情感倾向可能不一致。

结局：

从希望得到一个剧本预测引擎的初始目的出发，一波三折，最后意外得到了一个歌词流行度预测引擎，考虑到歌手、唱片公司、曲风等要素后，最终得到的预测结果，看起来还是比较合理的。

后记：

这是从文本角度分析的思路，如果讲音乐分拆出来旋律、歌词情感和文化倾向、配器等要素，应该会得到更好的预测分析结果。

本文不包括基本职业素养，如学习能力、激情、敬业、沟通等。一家之言，仅供参考。

需求发现和分析能力

场景不停变化发展，用户需求是动态的，要求产品认知不断迭代，该能力的核心是识别定义需求场景和判断需求满足情况。通常通过用户调研报告、需求分析文档、需求评审文档、项目总结及述职等方式体现出来。

能力同时体现在数量和质量上：

1、数量是指用户需求被发现分析的个数。应考虑到产品不同的发展阶段，成熟产品相对初创产品，需求发现的难度要高，在数量的要求上也不同。

2、质量是指用户需求定义的准确性，包括考察人群覆盖比例，场景和需求的频次，满足程度，简言之是需求的性价比，而不只是需求发现的难度。

人群覆盖比率高，场景频次高，满足程度较大不足才应被纳入能力考察范围。极限情况下需求，用于考察思考完整性和深度，避免需求上的过早过度发现导致产品过早过度设计，造成资源和时间上的巨大浪费。

高质量的需求发现和分析，应符合以下三个要求：

1、直击本质

本质是指事物区别于其他事物，本身所固有的根本的属性。需求的本质指向某个普适性的心智模型，使得用户行为在具体的场景下可以被解释和预测，需求分析是理性科学的，可以被证伪的。避免用“用户偏好不同”来解释“用户行为不同”，“偏好”是个性的，分散的。任何偏离本质，流于表面的分析，都可以在“偏好”的指导下找到自己的解释力，这种万能说法伤害了需求满足的判断标准，使产品失去迭代进化的能力。

2、分析严谨

分析严谨的要求实际上包括了三段：

2.1、分析素材基于事实。分析素材的采集，要求准确（精确且完整，以可以支持分析为限，过于追求精确和完整将失去性价比）和客观（不参杂个人价值判断），是事实而非观点；

2.2、分析过程反映因果关系。需要强调的是相关性与因果性的差异，我们说统计上的正相关性，是指 A 与 B 同时增加或减少的情况，如泳裤与西瓜的销量同时上升，是相关性，而不是因果性。夏季来临，温度上升，人们消暑降温的需求增加，带来了销量增加，才是因果性。

2.3、分析结果可被重复校验。由于现实情况的复杂性，我们很难在每一个需求发现和分析中，都严格追求完美的因果关系，大部分时候，这种分析都是指用户在 A 的场景下，大概率会发生 B，重复多次，重复多人，都不改变这种概率或概率分布。

3、结论合理

应该意识到，结论是有前提条件的，结论指导的产品设计或商业实施，也应该是有可操作性的。假设一个三段论分析：稀有金属很值钱，月球上有很多稀有金属，所以去月球开采稀有金属能很赚钱。这个分析不严谨，结论也不合理，忽略了商业成本和现有技术条件。

从需求发现的深度上，可以层次分为：

1、发现现有产品对现有需求满足不足的地方，包括不限于文案、交互、功能缺失、策略疏漏、分支情况考虑不足等。

2、发现新的需求场景，通过延伸现有策略、功能、产品，可以满足此需求。1和2是基于现状的一种改良。

3、发现新的需求场景，通过新的策略、功能、产品来满足此需求。这是一种创新，容易产生新的业务增长机会，是需求发现和分析能力的最好体现。

从判断需求是否被满足的角度，可以层次分为：

1、不具备量化能力，依赖访谈和个人印象。

2、具备量化能力，量化方法有特殊性，仅用于严格同类型需求的判断。

3、量化方法具备可复制性，可用于指导同类型需求是否被满足的判断。

市场及竞品分析能力

市场与竞品分析能力的核心，是数据采集和结构化能力。通常通过商业分析报告、行业发展调研、竞品分析报告等方式呈现。

分析工具使用

包括不限于波士顿矩阵、波特五力模型、SWOT，使用成熟工具是为了清晰说明问题，依赖工具的分析，只注重了分析过程的逻辑性，而忽视了分析本身的目的是为了指导行动。分析报告是以观点为核心，而不是以使用工具的过程为核心。包含分析工具的报告，可以是这样一个结构：

分析目的 -> 观点 -> 证明观点的逻辑 -> 分析工具/模型对逻辑过程的支持 -> 实施代入分析工具 -> 结论 -> 结论的局限性 -> 校验结论的方法

分析质量

从分析内容完整性要求，应该包括分析目的、市场/竞品情况、对产品的影响广度及深度、应对方案、方案评估方法等。符合内容完整性要求的报告，可作为考察市场及竞品分析能力的重点，也可以针对不同类型的分析报告，设定不同的内容完整性要求。

从分析类型完整性要求，可以包括市场趋势、政策与法规影响、上下游产业链、外部渠道分析、主要竞争对手的规模变化与动作、主要竞品的特点与流程、潜在替代品分析等。产品经理可输出的符合内容完整性要求报告类型越多，越能体现相关能力。

从分析的深度上，可以层次分为：

1、描述型报告，描述市场上正在发生的事实，以及竞品的状态变化，缺少分析框架，主要考察数据收集能力。

2、评估型报告，除覆盖描述型报告的要求外，增加分析框架，可针对少数关键流程/产品特性/市场要素，准确评估外界市场环境和竞品变化对产品的影响。

3、对比型行业报告，除覆盖评估型报告的要求外，设计有针对性的数据采集清洗方法，构建分析工具和方法，相对准确做出中长期市场态势预测，对产品中长期规划提出合理化建议。

从数据有效性的角度，可以考察以下：

1、采集数据的来源和方法。数据来源的丰富性和数据准确性，直接影响到分析的质量，产品经理应掌握各类数据的来源，同时对数据来源的擅长领域、准确性、更新频次、覆盖范围等特点有清醒的认识。来源包括不限于数据分析工具、有关部门权威发布信息、研究机构行业报告、可信个人数据源。

2、清洗数据的能力。主要指从原始数据中分离对市场及竞品分析有用的数据的能力，熟练使用数据分析工具尤佳，包括不限于Excel、SQL、R语言。清洗思路通用性的价值优先于工具技能。

3、数据的呈现能力。数据除及时有效外，还应便于理解，市场及竞品分析中的数据可视化呈现及对分析结论的支持力度，也体现出产品经理理解和表达的能力，属非必要能力。

方案设计能力

业务的复杂性要求产品方案具备多样性，方案设计能力的核心，是抽象业务，并通过功能或流程满足的能力。通常在不同类型的PRD、分享、分析报告中体现。

从方案的类型区分，各种方案的难易度与业务场景有关：

1、靠近直接用户的交互功能设计

交互的操作步骤/操作时间，量化用户体验的方法可以通过搜索得到很多，不赘述；
功能对需求的满足程度，通过NPS考察，关键依然是需求的定义而不是功能点；

2、侧重业务流的操作流程设计方案

正向流程，节点明确，分支流程覆盖全面，使用业务流的各方角色任务划分清晰；
逆向流程，可从任意节点回退流程；
流程相对标准化，新增业务支持改动小；
作业模块简单可微服务化，针对同一要素的操作保持在同一作业模块中处理；

3、提高效率的策略/算法/模型设计方案

策略/算法/模型迭代产生的关键指标增长，在相似增长的情况下，简洁优于复杂；
可解释性高，可向非产品开发角色输出简化包装后的描述，方便理解；
从需求到策略/算法/模型的思考过程清晰，可输出到同类业务；

4、面向营销增长的运营方案设计方案

增长的结果，体现结果导向；
增长的性价比，体现经营思维；
运营方案的可重复性，体现抽象能力；
运营方案的特殊性，包含时机、目标人群、运营动作等，特殊性体现了产品经理对业务特殊性的理解；

5、涉及财务税务法务的支持方案设计方案

容易忽视的方向，通用性强，技术要求高，在考察时需要更多考虑协作方的NPS；
财税法相关的方案，考察数字准确性，对合规要求的支持程度和响应速度；
财务相关工作，存在相当多的可自动化的重复劳动，财务人力投入的减少，也可以作为考察指标之一；

对高阶的产品经理而言，除在方案设计上具备基本的能力外，还应当具备系统化视角，增加产品管理制度、产品架构设计、产品团队结构设计、商业创新设计等。

1、产品管理制度设计方案

包括产品方案设计的基本流程，文档模板，质量检验方法、评审规则等，这些制度设计风方案应当是被实施并取得相应效果的；
制度设计的实施需要得到开发等相关部门的支持，在考察中可以征求相关协作部门的意见；

2、产品架构设计方案

产品线之间的协同设计，考察产品线之间的交互模式；
产品矩阵之间的协同模式设计，考察产品是否形成逻辑自洽，市场反馈良好的网状结构，形成合力推动业务发展；

3、产品团队结构设计方案

产品团队的结构，需要覆盖产品架构设计，通过业务划分和梯队建设设计，在产品人力的投入上保证业务正常，同时需要考虑业务突然增长和人员意外流程产生的风险；
产品团队成长路径设计，在至少未来 6 个月的业务增长假设下，从招聘和成长两个维度建设团队。外部招聘时，可以通过对标内容明星项目和团队，考察高阶产品经理的团队建设方案能力

4、商业创新设计方案

产品反哺商业的方案设计，产品架构是否能容纳商业尝试的不确定性；
是否有产品机制保障商业创新；

方案难易程度的判断点：

1、涉及业务角色数量，难度与数量正相关。

2、涉及功能模块或系统数量，实质上就是方案适用场景的多少，难度与数量正相关。

3、涉及不可控要素数量，且方案可以限制不可控要素对完成度的影响。

4、方案的抽象性，可复制到其他业务场景的可能性越高，难度越大。

以上难易度的考察，受限于具体业务场景，难易考察创新型方案，可以通过建立“明星”方案作为参照物，得到方案的相对难度，逐步建立难易度量化能力。

方案执行能力

方案是否有效，说到底还是要通过实践来检验，执行是设计+实践+迭代的整体过程，执行能力的核心是资源利用和项目管理，项目管理类的资料和书籍非常多，简要说明。通常体现在项目结果中。

1、产品设计方案分拆，边界清晰，执行计划目标明确，milestone设计合理，执行过程可以被持续监督，不断反馈。

2、执行判断力，判断是否执行，判断执行优先级，取舍有方。对高阶产品经理，此项能力的要求更高，同时还需具备向上管理预期，平行协调沟通的能力。

3、产品设计方案资源估算准确，资源包括涉及角色、投入人力、时间等，无需求变更等特殊情况，误差应在10%以内。

4、产品设计方案对合作方的影响及协同方案设计实施能力，要求产品经理除自身负责的模块或产品线外，理解协作模块或产品线的运作方式，在方案设计及执行时，能大致评估出会影响到多少外部模块和产品线，并协调资源处理。

5、进度跟踪，迭代交付能力，重要的是不断反馈和调整，拿到结果。

以上几种能力的考察，主要是通过日常项目进度和结果，协作团队的评价进行。

对高阶产品经理，需要增加设计保证执行的工具，建立保障机制的能力。要求任何一个产品经理都克服一切困难，尤其是克服部门墙和职级差异造成的困难，是不现实的。在多人团队的协作中，除依赖个人执行能力之外，还需要设计和推动标准化流程和协作机制的建立，包括奖惩、指导、总结等环节，减少执行中的不确定性和不必要损耗。这种能力会降低对产品经理个人能力的要求，有利于产品团队产出质量。

商业能力

无论是 toB 还是 toC 的产品，最后都需要商业变现，或者是成为商业生态中的一环，支持商业变现。商业能力的核心是经营思维，通常体现在PRD和项目总结里的成本测算、收益评估等环节，日常工作中反映出来的财务思维也是重要考察项。

1、谈判能力。内部，通过目标协调一致；外部，通过共赢协调一致。谈判的结果，首先是达成合作，然后才是一城一地的得失计算。

2、财务思维。基本读懂财报，知晓复式记账法，了解现金流对公司经营的重要性，理解所有的资金都是有使用成本的，算大账超过算小账。

对高阶产品经理，理解组织的商业模式和收入模式非常重要。商业模式是我们为最终客户提供了什么价值，客户为什么商品付钱；收入模式是谁付钱给我们，让我们提供商品。商品与产品是不同的，整个商业组织的交付物，是交付给客户的商品，而产品经理所做的，是通过“产品”生产“商品”，因此，让“产品”容纳“商品”创新尤为可贵。

指导能力

考察指导能力，是指通过结果考察指导的广度和深度，能力核心是抽象总结和沟通。

指导的广度是指：

1、受指导的直接人数应超过管理的人数，即是指导范围超出管理范围。

2、能力建设和方法总结得当，具备普适性，可影响大部分产品经理，可以通过考察指导人方法论产出、专业领域的专利或业界口碑进行。

指导的深度需要从指导力度和质量来看。指导力度越大，耗时越多，与直接指导人数成反比；指导质量从被指导人的能力进步来判断，通常看被指导人承担项目的难易度增加和晋级情况。

指导力度可分级为：

1、动作指导。指导做什么事务，什么步骤，每一步的做法，指导者监控过程和结果。

2、战术指导。指导做什么事务，分解执行由被指导者完成，指导者评审方案和监控结果。

3、战略指导。指导做什么方向，战略节点、事务分拆都被指导者完成，指导者只监控结果。

4、目标共同体。具备战略建议和决策能力，自下而上提供战术战略，形成目标共同体，不再区分指导者与被指导者，而是合伙人角色。

执行层面的产品经理，应该具备动作指导下一级产品经理的能力，并接受上一级产品经理的战术指导。
有管理职能的产品经理，应该具备战术指导下一级产品经理的能力，并接受上一级产品经理的战略指导。
极少数的资深产品架构师，应该具备指导和培养产品管理者的能力，成为组织的目标共同体。

什么时候需要产品职级

能力的层级任何时候都需要，帮助我们定位自己；职位的层级可能带来高昂的管理成本，在产品团队规模较少，低于100人时，不要启动明确的职级划分。

在国内互联网公司的产品经理成长路径中，通常在对标阿里P7这个级别上，会出现一次P序列和M序列的分叉，一部分人走上了管理（M）之路，更多人走上了专业（P）之路。P序列的高级别，被称为"产品专家"，或者是"产品架构师"。相对于能力更通用化，发展更成熟的研发线系统架构师，产品架构师的定位比较模糊，至少在实践中，工作内容与系统架构师有诸多重合之处。梳理产品架构师的内涵及外延，是一件有趣的事情，下面的内容都是我个人的理解，欢迎批判和探讨。

一、产品架构的一些问题

1、产品架构是什么

广义上，产品架构是业务结构的镜像，描述的是从实际业务中抽象出来的需求（子需求），和需求在如何通过在系统之中（子系统之间）进行交互，最终被满足的过程。

狭义上，产品架构是指需求和交付物之间的关系。

用下面一个表格来说明：

在实现层面，系统架构应该包括数据、业务/商务、运营、营销等整体业务流。

2、产品架构对组织架构的影响

组织架构变革在新零售话题中常常被提到很重要的位置，系统中台化趋势要求组织结构液态化，以响应商业环境和业务形态的快速转变；在产品架构话题中，组织架构和产品经理个人的成长却常常被忽视。

直接影响产品技术研发类组织架构，产品架构最后的交付物是系统架构，会切分好各子系统（子模块）之间的内容，PM和RD的工作内容和协作关系也随之确定。

间接影响整个业务流各参与角色的职责内容和协作关系，随着业务变化和系统改进，参与角色的工作内容甚至是角色本身，都可能改变或取消。

完成业务结构、产品/系统架构、个人成长三合一，是衡量产品架构是否优秀的一个重要视角。

3、产品架构的评判点

好的产品架构，应该是容器，提供空间（性能冗余/数据监控分析/损失管理等能力），容纳业务的不确定性（创新），是一种系统机制。

评判点也用一个表格来说明：

4、谁来评判产品架构

由于产品架构是需求间的关系和需求实现的过程，参与产品架构评估的角色，应包括具备业务抽象能力的业务方、产品、研发，以业务场景为基本维度。

5、产品架构设计实施的一般方法

产品架构与技术上的架构设计实施过程有一致性：

乐高一般的开放系统架构应包括三个基本要素：

• 组件/构件

  • 可复用的模块，尽量排除个性化的业务流程逻辑，排除过程。即是，内部信息流程不依赖外部模块处理，高内聚
  • 关注组件的输入输出，组件之间的信息流及媒介

• 模式

  • 支持业务全流程的系统闭环的一组知识体系
  • 商业需求/客户需求被满足的生产交付过程

• 规划

  • 对业务长期支持，设计未来整套行动方案

6、产品架构视角下的系统化创新

在业务发展的早期阶段，产品设计开发工作经常落后于业务创新，主要工作内容是响应和配合业务需求，产品经理及工程师，常常有疲于奔命的失控感，但这是一个基础设施建设的必要阶段。随着对业务理解加深及产品系统架构的完善，产品领先业务，进入系统化创新的阶段就会到来。

系统化创新常常以这样一种方式进行：

业务流程被抽象成为颗粒度非常细小的节点，通过四个方法（方法来自《简约至上：交互式设计四策略》）变成全新形态出现

• 删除（自动化或智能化）非必要节点
• 重组（有时是替换）为新模块
• 隐藏支线节点
• 转移节点到其他产品

二、产品架构师的一些问题

1、产品架构师是什么

产品架构师是产品团队内部的专业咨询顾问角色，深度参与到产品设计实施的全环节

• 架构设计

  • 从业务诉求（商业诉求）中抽象需求，以结构合理的系统完成满足需求之交付物的生产，并使生产持续

• 团队建设

  • 成为P序列产品成长的坐标和参考，为PM的专业序列制定能力模型阶梯及成长路径，提供产品专业相关的指导
  • 识别并培养具备产品架构师潜力的产品经理
  • 建立并维护适合架构师成长的规则及团队环境

• 项目实施

  • 在实施层面的协调工作更多，平衡不同项目在方案上的投入产出
  • 分拆架构目标，落地到具体的项目实施中，确保架构目标/进度符合团队整体目标/进度

2、产品架构师职位要求

• 对业务的理解

  • 理解业务全流程各环节，参与角色及其作业操作（包括管理）
  • 理解公司商业模式，所在业务线的商业模式及定位
  • 理解基础的技术实现
  • 行业趋势、产品方案趋势、竞争对手产品研究能力，关键是完成产品评价标准
  • plus-具备基本的财务/税务/法务知识

• 对产品工作的理解

  • 具备探索并成功实施（规划/设计/运营/增长）创新方向的产品能力
  • 具备规划和部署产品矩阵，实现组织目标的能力

• 对职级的要求

  • 应具备高级经理及以上的产品职级和能力，从内部培养效果更佳

3、产品架构师的工作方式

• 产品架构师与产品执行负责人的协作

  • 架构师跨产品模块参与评审，为系统间交互提供符合架构设计的建议，尤其是在中台化项目中，重视流程；产品执行负责人确定具体设计及实施方案，重视细节；
  • 架构师对项目/系统目标负共同责任，以协商为基本前提，保留在对架构设计的最终决定权，同时承担最终责任；
  • 设置产品架构委员会，规避重大项目架构设计风险；

• 产品架构师与技术负责人的协作

  • 产品架构师角色重需求抽象和场景定义；技术负责人重实现；

• 产品架构师工作成果的评估

  • 落地项目的绩效
  • 产品、研发、业务团队的认同度调查
  • OKR及360度环评

4、产品构架师对PRD/MRD的影响

由于产品架构师重视中长期架构的规划实施，所以需要在PRD/MRD中强制增加以下内容

• 数据流及模块I/O
• 对不能严格控制的外部系统的依赖及交互，即是架构风险控制的内容
• 系统目标的完成评估方法，重结果
• 数据分析导向的监控和分析方法，重过程

5、产品架构师的晋级之路

下面的级别是从实施、变现、平台战略角度来说明，未必符合所有公司对架构师的晋级定位

在细分领域上，如电商、社交、工具、金融、人工智能等，都对产品架构师有非常高的专业要求，可以分别制定评分表来确定不同级别架构师的实际要求。

6、产品架构师的工作难点

• 作为非管理角色，如何获知/参与业务目标规划
• 作为规划型角色，如何平衡架构设计的长期收益与KPI的短期收益
• 作为重咨询角色，如何平衡架构设计师与产品线负责人之间的产品方案及优先级冲突

三、市场中对产品架构师的描述

通过查看一些招聘网站，选择了两个case，来看看不同公司对产品架构师的不同描述，说明产品架构师这个角色，并没有整齐划一的刻板定义，对有志于在产品P序列向上发展的产品经理们，在自己特定的业务和组织场景中，都可以形成有特色的产品架构师成长路径。

百度中台产品架构师

职位说明:

- 负责百度知道内容tag模型和用户画像建设，支持多端产品的推荐工作

- 负责百度知道内容及用户反作弊工作，及内容审核工作

- 负责百度知道整体数据平台建设

- 负责百度知道相关的中台业务工作

任职要求：

- 5年以上产品经验，有搜索、推荐、内容等平台型用户产品经验优先

- 逻辑分析能力强，计算机、数据分析等理工科相关专业优先考虑

- 工作积极主动，抗压能力强，快速学习，踏实认真，有责任，具有优秀的理解、沟通与协调能力

京东金融解决方案产品架构师

职位说明：

- 从事部门创新产品的产品管理和产品经理团队管理；

- 负责核心产品的产品创新、设计、规划和运营；

- 组织内部、外部资源完成产品开发和推广；

- 指导产品经理团队完善产品分析和设计；

- 对内外宣传产品特性和价值；

- 培养产品团队成员能力；

- 横向沟通项目相关的产品、售前以及商务部门。

任职要求：

- 本科及以上学历，计算机或相关专业；

- 5年以上to B的计算机服务类产品运营经验，有互联网、金融等行业经验优先；

- 具有产品设计、组织研发和运营的能力；

- 良好的沟通能力，具有对外客户产品售前支持能力；

- 具有团队管理和提升的能力；

- 具有创新精神和创新意愿者优先。

四、结语

如果觉得我写得还有一点道理，欢迎留言沟通或邮件沟通sluke[at]qq.com，说不定有机会在互联网产品工作上合作，一起成为更好的产品经理。

业务符合需求，组织适应业务，系统镜像业务

从用标签区分客户到用户微粒数据镜像客户，需求越来越细节和个性化，要求组织、系统、产品都要相应变革

PM的工作有新目标：

1. 信达雅翻译业务，用系统镜像业务
2. 用成本低的系统试验变化，反哺业务创新和组织变革

系统分层，强化中台，业务也是一个操作系统

Google 的实验性操作系统 Fuchsia OS，设计了一个四层结构，可以用来帮助理解业务系统的前中后台划分。

中台，是通过信息流、资金流、物流来反映商业全生命周期的枢纽

强化中台，可以理解成强化对业务变化的反应能力，要求组织柔性化液态化，系统功能粒度更小，应用方案更丰富（类似应用市场中的 APP 更多）

中台系统PM重点关注：

1. 客户最后获得的交付物是商品+服务，是一个漫长过程，结束不在商品交割的一刹那
2. 中台有所有数据的最终版本，需要保持一致和完整

变化发生在用户第一线，就像是果实和种子

一线的业务细节变化良莠不齐，中后台的感知经常滞后，中台化在加强感知能力，面对不同的业务驱动模式，PM的定位也有不同

资源驱动阶段：面向新兴市场，向外求增量
管理驱动阶段：面向饱和市场，向内求优势
创新驱动阶段：创造新物种

做系统的股东

组织里的各种角色都在为业务服务，接近客户的还有销售和运营，接近系统的还有研发，PM是组织里的中台。

销售、运营、研发的工作相对于PM，容易评估，他们是系统的债主，先拿走确定收益率的回报。PM是系统的股东，拿走剩余的收益，要求PM的主人翁意识要强于其他角色，因为有潜在的超高回报收益。