从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，微信的聊天体验真的算差的。但这并不掩盖微信生态的强大。