从AI部门小书架上抄起来的书,刚好当时和大家在讨论产品相关的话题,带着一些问题看完了。

整体来说有点“平淡”,不是指作者不厉害,而是作为先行者,作者的产品理念在行业里已经是常识了,以至于看下来增量比较少。
如果有过产品经历,或带过产品团队,亦或经常参与到产品决策中,那这本书里的增量认知可能不多。

内容纲领

书的篇幅不长,整体分为四个章节。小节篇幅很短基本在平均2页左右,倒没有阅读压力但有些小节会有浅尝辄止的感觉。

前两个章节讲角色分工、流程与工作界面,集中介绍产品SOP(当然,也有作者的自己的理解)。 第一章节是介绍产品经理的角色定位,包括去比较项目经理、主程、销售经理在做产品里的优势与劣势,产品经理怎么周围角色协同,甚至如何招聘这些课题,如果已经在运转一个产品部门了或已经有相关思考了,这个章节的信息比较枯燥且平淡,可以跳过。

第二章节聚焦在介绍产品流程、每个流程环节的工作界面、如何与不同职能部分协同工作。比如去介绍了如何探索论证一个产品的空间,采用什么样的产品迭代方式最好,如何做原型测试等。这块整体也比较平淡或者偏常识(同上,可能是因为作者作为先行者,所定下的很多经验已经成为行业常识造成的“平常”),但开始有一定可参考的方法以及有特色的观点出来。整体阅读价值还是偏低。

第三章节是本书的核心,开始介绍作者的产品理念,介绍了如何去收集定真实需求、以及作者的一些产品理念(体验与需求可用性与美感等),如果想快速获得作者关于产品内生的一些思考,看这个章节就可以了。

第四章节只有2小节,介绍产品经理在工作过程中的一些反思清单,工具性强一些。

有一些枯燥,尤其是前两章介绍产品工作SOP时,偏常识。


增量观点

看完已经有一周了,在没有刻意整理的情况下,脑子里还有的一些留存观点在。

1. 不写一行不知道用途的代码

这个是作者序言中的一个观点,“不写一行不知道用途的代码”是转换为口语化表达的。这个观点是让我有共鸣的。
作者介绍自己在HP时,因为缺乏客户调研,开发了一个最终没有“价值”产品的经历,感叹到如果没弄清产品能帮到哪些客户、提供了什么价值,不盲目投入任何精力(这倒是和雷军讲自己97年那次产品失利的感悟很像)

我同时有二三线公司和一线大厂的经历,比较差别的话,其中一条便是小厂因为资源有限,对于任何一个产品决策都会反复的确认其商业价值、用户价值。即使是中后台的产品也如此。

大厂因为暴满的研发能力与研发资源,会习惯性的忽略产品的客户与价值这些基本的因素,在很难听到炮火声的中后台部门,如果没有趋势判断,非常容易陷入拿着方案找问题。这种预设立场的方案往往是不需要的,也造成了大量中台产品存活周期非常短,甚至从没对业务或管理产生任何增益。

现在的部门也有这样的迹象,这并不是同学们“个人特质”有问题,还是因为在资源满足甚至溢出的情况下,环境会潜移默化的引导了风向变化。甚至在这种环境中,追问产品价值的同学显得更为异类一些。这点上也一直在影响我老板的一些思维,去探寻产品的价值,否则写的任何一句代码都是多余的。

这里需要补充的是,不是说所有的产品都能成功,有些就是风险型探索性的项目,但这时仍然是需要去定义,需要探索的是什么,需要论证的是什么。而不是陷入“因为我能做所以我要做”,或“因为这个有挑战所以我要做”的陷阱中。

2. 情绪化用户是最佳的需求挖掘对象

作者将客户分为情绪化用户、理性用户、无主见跟随用户,并将情绪化的用户列为最价值的需求采集对像,原因挺有意思。

客户“需求”,可以理解为是对当下现况的不满。比如打车软件,解决的就是原有客户对传统交通的灵活性的不满;导航软件,解决的就是原先大家对纸质地图的不满。

产品经理的工作就是去捕获这些不满,尤其是商业型产品经理。对这些“不满”捕获的越准确,产品定义自然会更准确。
情绪化用户对于不满的表达,往往是最显性和激烈的,自然也是更好捕捉的。
而对于理性用户来而,遇到一些“不满”往往会有一些忍耐空间,导致产品的需求在早期在他们身上传达的不强,更为隐性。

要么找到一个观察场景,让客户的不满情况得到释放;或者直接到一个群苛刻不容易满足的客户,从他们身上去捕获更强的需求信号。

关于需求挖掘,还有个观点值得一说:提防技术爱好者与特殊需求用户。

技术爱好者对于产品的点评讨论会是更热烈的,声量更响的,但有可能是脱离实际的,因为他们用某种产品,很可能是因为产品内在更新了某些新技术,即便这些技术并没有带来新的体验提升与应用场景拓展,他们仍然非常热衷,因技术层面的满足感,反而会忽略对产品能力的问题。

而特殊需求用户,能提出的异类小众需求,有时可能是超前的引导,因为他们先行于市场。而更多时候可能将产品引向错误的方向。本质上是考验对产品定位是否清晰、产品方向是否有定力。当然,如果定位上就是定制软件,那这点上顾虑会少一些,定制软件是交付导向,以交付驱动。

关于情感与需求,我认为是作者在本书中唯一有深入表达的部分,中间有一段访谈实录,值得一看。

3. 硬件为软件服务,软件为体验服务,体验为情感服务;产品为需求服务;

这个标题很泛化,书上的例子也只浅浅的夸了一下苹果产品设计,本想直接跳过的。但联想到一个反例,让我对这段话的共鸣更深刻了一些

产品为真实需求服务,这点是容易共识的。但如何挖掘价值需求定义产品,不仅需要方法论,不是客户口头说什么既什么,更需要创意与情感,尤其是对C的产品。

而“硬件为软件服务,软件为体验服务,体验为情感服务”这点上,脑子里首先跳出来的产品反例既是小米11 Utrla。
作为阐述了一个观点,用自己的话说,既是所有硬件、软件、体验的提升,都是需要有服务目标的:我们为什么加这个副屏,这个副屏服务了什么,解决了什么需求。
没有服务目标的堆叠(不限于硬件范畴了)是技术性的自嗨。

小米11 Ultra的副屏,现在社区讨论中多偏负面,也是犯了这个错。11Ultra的Case可能还会再复杂一点,当推出副屏时,圈子对副屏未来的作用和场景还是有一些期待的,包括我也主观上认为副屏能带来一些体验提升和应用场景,但小米并没有继续在软件层面开发利用好这块副屏,使之成为摆设。
这便是硬件与软件了割裂,不管是硬件太超前还是软件太缓慢,结果上就是断层和割裂了,硬件与软件的脱节导致没有联合起来形成场景应用和体验提升。站在今天来反问,这块副屏到底是硬件部门自己加的,还是软件部门有体验提升想法,向硬件部门提出的? 如果是后者,软件部门是没有执行原定想法的吗?从这个视角,一个拉横的产品经理很关键。

4. 大众产品、企业产品、平台产品

作者对大众产品、企业产品的定义,是指分别以服务大众与企业为某个场景目标的产品(如打车、如自动化营销),作者分别例举了10条个人经验,总体来说不算新颖,不再复述了。

因为当下部门正在做一个拉通多个职能部门的平台类产品,所以对平台产品这块有一些共鸣。
平台产品的第一个挑战是服务的目标角色变多了,不仅要定义清楚对每个角色的服务目标,还需要定义不同角色的权力/责任/利益,其复杂度从设计一个效率/体验工具,变成了设计一个虚拟组织。
组织工作流程可以类比为工厂里的流水线,假设生产一个产品需要三条流水线协作,每个流水线有十个环节,那么第一条水线的第一个工人,对第三条流水线的最后一个工人的工序和目的,肯定是不了解的。 这带来了第一个挑战,需求收集变得困难

如果说以服务个体或者企业为主的产品,产品经理可以将自己代入到客户视角,去实操感觉去提炼需求,那当服务一个组织时,“组织”这个实体是具备多面性的,像一个多面体,只从一个角色去描述它都是不准确的。这个多面体的每个面,可能还是局部冲突需要博弈和规则裁决的,有一个场景可以示例一下这种冲突:如果大公司里没有内控或者PI部门来制定审批流的,那个每个部门对于审批流的设置和理解可能是完全不同的,权力大、工作少、风险责任低是所有部门对审批流的最大诉求,但全局来看这明显不可能的。

我在内部开玩笑,做平台产品在收集需求,就好比要调查案件需要采访10个人收集线索,这10个人立既不同甚至有些微冲突,同时还不一定说真话(“不说真话”是指这个过程中某个参与角色因为对全局缺乏了解,他讲述的理解不一定是正确的,而不是指对抗性的说假话)

所以当设计一个平台产品时,需求定义需要基于全局的理解,对目标概念约定会有更多的讨论;“权责利”成了最大的设计要素;产品思维之上还需要叠加架构思维,这也是平台产品往往需要很强大的业务架构师甚至全局架构师介入。

作者在书中例举的是windows这样的平台产品,这中间的角色包括应用开发者、内核开发者、终端用户、供应商等,角色性质上和上面举例差异比较大,但平品设计本质上,还是需要围绕参与者之间的核心诉求以及“权责利”设计。

继续扩展话题,我认为平台产品可以分化提炼出生态产品,这个方向上比较推崇微信,微信就像一个上帝视角的规则制定者,规定公众号、服务号、小程序、广告商、用户、ISV之间的交互关系与约束,甚至连"一个公众号在不同情况下,分别可以主动向客户发几条什么样的消息"这样的细则都有约束。完成这些生态规则制定后,这些角色之前围绕各自的需求与利益的,便自行运转起来了。

能证明这些规则指导下的生态是否足够好,我认为可以从这个生态的规模、效率以及洁净程度来衡量,前两者很好理解,最后一条看的是这个生态的自洁性,背后对应的是生态的质量及寿命,一个无法自我净化的生态系统是会很快毁灭的。 一个自洁性好的生态,往往在花费少量的治理(运营)成本,便可对生态的运转质量及寿命进行保证,而这也是业内对微信产品力认可的重要原因。微信在业内得到认可不是因为软件聊天体验好,相反,在对比skype,tg,discord,微信的聊天体验真的算差的。但这并不掩盖微信生态的强大。


转载请注明出处:读书笔记:启示录-打造用户喜爱的产品 - Toast.pub

本文采用「CC BY-NC-ND 4.0」进行许可