产品管理工作的本质是在为产品用户体验“立法” ——聊产品文档对用户体验管理的重要性

分享

汽车产品经理几乎是一个不可能由单一个体担任的角色——“工业之王”绝非浪得虚名,其复杂度也无须赘言。

所以产品管理工作的内容是什么?

在短短7、8年的汽车产品工作经验中,我所接触的不同团队在这一工作中重点各有不同:有的侧重于对用户和需求趋势的了解和传达、有的侧重于对竞争策略即产品定位的讨论和锚定、有的侧重于对产品价值、价格和利润的平衡和优化、还有的更偏向实现层面:通过对设计、硬件和参数的深入理解不断提升产品力。

以上工作无不涉及多种学科专业,对能力经验要求如此多元和深刻,每个汽车子系统的专业英文缩写就要记上百项,更不要提用户研究这种虚无缥缈又深入本质的工作了。

不过,貌似产品经理这一角色就像互联网产品经理一样总给人留下一种“人人都能做”的印象。而反之的事实,是优秀的产品经理凤毛麟角,少之又少,汽车行业也一样。

著名的互联网产品学习网站的名字说明了这一工作的门槛……

优秀产品经理的缺失也直接导致优秀的产品同样的凤毛麟角、少之又少。

确实,技术问题、实现问题有工程研发团队,市场销售环节也有专门的销售部门和团队,造型有能说会画的设计师……产品经理好像存在感一般,大多是文档的撰写者、汇报者,或领导想法的贯彻者(也就是领导更像单一的产品经理角色),其中后者已经是行业内结果最出彩的工作形式了。

这篇文章无意对什么是“好产品经理”进行讨论。之前阅读“辉哥奇谭”公众号,有一篇《好的产品经理极度稀缺》已经很好的分析了这一问题,我也翻来覆去的阅读过。辉哥列出了六条好产品经理须具备的条件,分析得醍醐灌顶,这里做引用:

一、  好产品经理必须具备足够的生活阅历

二、  好产品经理必须洞察人性

三、  好产品经理必须克制

四、  好产品经理必须懂生意

五、  好产品经理必须是管理专家

六、  好产品经理必须有决策权,但决策权是自己打出来的

从去年阅读过这六条后,一直印在心里作为行为准则。前五条是可以习得的或锻炼的,最令我印象深刻、甚至击中内心的是最后一条:决策权。

之前看过的一副Stakeholders Salience(利益相关方的显著性)图,很好的描述了项目过程中“谁说了算”的问题

说跑偏了,这里回到这篇文章的命题:产品人到底是干什么的?

工程眼里产品是“代表用户发需求的”、设计眼里也许是和工程对战的“队友”、销售眼里是“乱加价”的……

而由“决策权”三个字,联系到自己日常工作中的思考,我得出了关于产品管理工作的真正价值:为产品“立法”。

每个品牌其实都有一部或成文或隐形的产品“法典”——可以比作“宪法”,即原则与价值观。其旗下的每个产品则分别在这部“法典”上做延展,类似于“修正案”。

一部成功的产品“法典”必然不是一蹴而就的,就像法律本身一样,跟随现实发展的步伐持续成长、修正,在打磨过程中不断至臻完善——其结果必然也必须是至臻完善的产品。

产品的“法”,说穿是用户体验的“法”,致臻完善的产品带来的是极致的用户体验。

所以为产品用户体验“立法”,没有决策权怎么行。

但立法又绝不只是有决策权就可以的,收集多元的信息、制定合理的规则、形成有效的决策,无一不是工作量极大但绝对造福众生/众产品的工作。

我把产品“立法”工作分为以下3个内容,按顺序分别是:

1. 案例收集和取证——侦探工作,必须要有足够的产品和用户信息作为基础,这些信息应该是围绕产品用户体验的不同分支之延展

2. 文档管理和记录——文案工作,必须要有可生长、有逻辑的结构体系,让上述产品信息和用户体验记录的积累实现量变到质变,才能保证产品落地执行过程中时刻保持“有法可依”

3. 应用评价和决策——法官工作,基于信息和结构体系,对产品开发过程进行不间断的跟踪并“依法”评价产品状态,在需要选择时“依法”且合情理的做出有利于用户体验的判断

这三层工作内容,大部分我接触过的团队从第一层,直接跳到了第三层。当然,天赋异禀和决策权的“好产品经理”完成这种跳级总是美仑美奂令人羡艳。

作为在学习中成长的产品经理,第二层,文档管理和记录,是被广泛忽略的。

原因很简单:一是功在当代,利在千秋,不能立竿见影获得回报与奖赏;二是案牍劳形、绞尽脑汁,生活工作已经精疲力竭,怎能再做这受累不讨好之事呢?

而学习,无非是书先读厚再读薄的过程,没有这一层积累,很难有妙手偶得的临幸。

当然这些工作总是有善良、勤勉之人在做,譬如现在OEM中常用的一些文件:产品特征目录、配置表、VTS、BOM清单……这些动辄几千行的文档,无一不是由前仆后继的专业汽车人无数次迭代而成,而多少新品牌、新人,靠着这些宝贵文档开始了他们的工作。

可惜上述列出的文档暂无一可以承担产品“法典”之职责,那产品“法典“到底应该是一份什么样的文档呢?

先说结论:产品“法典“之根本是一份完整描述整车所有用户可感知功能的Function List。

为什么这样说?简单比对一下上述其他文档可一窥究竟。

先说在大部分企业已经由产品部门管理的内容。

产品特征目录:用于记录产品目标和达成情况,即开发目标。优秀的特征目录可以从战略到细节描述产品的各个方面,还可以纳入用户语言与产品特征的衔接。但实际落地过程中,制定开发目标时主观评价占到工作的大多数,我接触过无数团队还在给产品的各个特征做1~10分的主观评分——座椅臀部横向支撑:A车7分、B车5分、C车8分——在纠结和不同个体的主观分歧中耗费掉精力不算,对产品的实际结果管理作用微乎其微,最后权当作一份检查结果记录了。

每家都不同但都一样尴尬的产品特征目录(个人整理,部分示例)

配置表:可以说是万恶之源了,粗暴的把用户需求简化成配置的文档,既不能描述整车用户价值,又给执行和落地团队过度发挥留下了空间。同时,每个品牌每个车型的差异在配置表上也仅能通过“有无”、“多少”来体现,最大化的削弱了汽车主机厂存在的核心价值——集成。更不要说由之而衍生的PVA计算和销售话术了。

再说产品部门之外的。

VTS:这是真正落地的文件,细致入微。我有幸参阅过三四家主机厂的VTS部分内容,完整的VTS表单能让研发工程师们的工作有据可依,算是最接近“法典”的东西了。问题出现在,VTS每个内容的目标参数设定是来自于产品特征目录开发目标和配置表的,然后在VTS中把定性的、主观的和配置性的语言转化为参数,转化过程往往一头雾水或依靠对标简单的推导出结果,在对于关键用户体验点的支持上非常薄弱——因为这些体验它们往往不是参数化的,但也绝非主观化的。

BOM:赚钱之本,从产品本身的角度描述产品。BOM的重要性不言而喻,管理BOM的每一个作者都是汽车产品的精通者,他们通晓细节与成本,对供应链、细分行业现状了如指掌。BOM的变化牵动着项目经济性和企业利益。但从用户体验角度,BOM无法完成从产品价值到产品价格的桥接,只能支持配置增减对产品利润影响的观察。尤其在“硬件不够软件来凑“的未来,用户体验和BOM的关系好像渐行渐远。但BOM是必须的,只不过没有嵌入用户体验的整体逻辑中。

Function List:放在最后说,因为结论已经先说了Function List是未来“法典“之根基,是”宪法“一样的存在。Function List现在可能由不同的部门管理,或者不同专业都管理各自专门的Function List,实际上它可以描述汽车产品的范围远超于配置表,都是用户能用得到的产品实际功能。

为什么说Function List是根基?我总结了四点:

一是通过它几乎可以完整的描述整车产品,比如有趣的例子是“四个轮子加两排沙发”,用Function List的语言来描述就是“能动+能盛人”,当然这种简化确实是“战略上藐视”的时代产物;

二是在软件定义硬件的大变化背景下,硬件和配置已经不能再有效的描述汽车产品了,复杂度更高了。用我们SoCar唯一撰稿人也是CEO的晓亮总举的例子来说,从硬件和配置表上根本看不出一台Tesla和一台奔驰之间的区别!

三是用户体验角度,用户能体验到的大部分产品内容是以Function的形式存在的!相对于VTS和BOM中只有极少数可以被用户体验和感知到的内容,Function List几乎都被用户直接接触、直接体验;

四是,想想就知道,Function List可以作为上述所有表单、文档的中枢——每个Function都必须要由硬件、参数、设计组合支撑特定的产品特征和用户体验。

结论重现:产品“法典“之根本是一份完整描述整车所有用户可感知功能的Function List。

现在,不谦虚地说,还没有看到一份相对完整、工整的Function List(可能会有上千项,我在梳理中),也没有看到任何以Function List为中轴连结产品特征目录、VTS、BOM的用户体验管理体系。

也就是说,产品“立法”工作最艰苦最繁复的部分还是个空缺。没有一个坚实的第二层,产品“立法”工作可能是浮在表面的样子工作……文档工作对于产品用户体验的重要性在上面分析了这么多,下面就是要去做了。

后面的文章中将继续记录自己在整理Function List时关于内容和用户体验的一些阶段性的思考成果。也会分享一些“案牍劳形”后的产出……

关注So.Car官方公众号

掌握So.Car最新观点动向

胡嘉禾
胡嘉禾SoCar 联合创始人

7年汽车产品战略咨询经验。2014年参与So.Car的组建工作,负责自然语言处理底层算法在汽车行业应用的开发。So.Car Data & Consulting 平台基础数据架构的设计者

最新报告更多