目录
万物互联、源网荷储、可持续发展等等概念吸引笔者硕士毕业后便投身新能源+物联网赛道，成为一名ToB AIOT产品经理，在设备故障诊断领域体验了一把从“与数据斗”到“与人斗”的小闭环。踩过坑，也有幸趟出过几条路。
在即将离开之际，经前辈提醒故将这三年的成长路径做个总结，恰好切换视角梳理思路本身就是一件有趣的事，分享对于分享者本身更具价值，所以便写下此文。
整个回顾总结篇将首先介绍产品概况帮助读者代入和理解，从个人能力和产品认知两方面总结经验，最后反思总结改进点。本文聚焦产品技能树开枝散叶，如果读者对新能源赛道感兴趣，笔者后续可考虑开专题文章探讨。
1. 产品简述
请你想象一个场景：此时你是一个工厂厂长，厂里有不少价格昂贵的设备，负责精密器件的生产与加工。
你一定会非常关注这些设备的状态：
1. 当前运行的状态是否良好（因为工作状态不佳会影响产品质量）
2.设备是否有局部磨损、需要加油等异常。（因为小问题不及时处理会导致大的故障风险）
当你管理的设备足够多/分布足够广的时候，你一定希望有一个系统能在线监视这些设备的运行状态，并在它们需要维检时立刻提醒你。
这是传统工业里典型的故障诊断场景，现在请你将机械加工设备类比为新能源设备，虽然检修成本更高、数据接入和分析难度更大，体制内组织结构更复杂，但核心需求并没有太大区别。
要满足这些需求，需要解决的核心问题包括但不限于：
- 数据从哪里来？如何获取？——e.g. 物联网技术；相比深挖单一数据类型，主动拓展更多数据类型可以在同类竞争中获取更多优势，是自己投入成本还是外购取决于产品心智（产出比大概率是算的过来的，但产品本身的立足点不能丢）
- 故障案例从哪里来？——e.g. 关联历史工单和故障数据，发现负样本；与公司内部其他团队、客户、供应商建立共创关系可让案例数量迅速增长
- 分析结果如何呈现？——e.g. 离线报告/在线推送；数字化建设领域往往有“演示场景”，不要轻视这个场景，对于你的客户来说可能比一个100%准确的算法模块更重要
- 如何持续获取反馈？——e.g. 离线追踪/在线闭环；更多是产品自身策略/模型迭代需求，但要巧妙转化成客户需求才能推进，客户不会做对他来说没有价值的事
以上列举了我们在做一款新能源领域的故障诊断产品时遇到过的一些问题和解决思路，而“新能源”三个字更多影响的是客户群体组织结构复杂性：这个赛道的客户几乎都是大中型国企，他们更在意组织效率的提升（但不会主动求变），对响应积极性要求高，针对需求和问题大概率不会主动推动与发声，但某个团体一旦发出负面声音造成的影响短期内很难消弭——所以没有服务/运营/配套的纯SaaS模式很难在国企活下去（甚至没有活一段时间的机会）。
新能源和传统工业最大的区别在政策导向、在执行政策的人，物联技术只是解决问题的方案——不要脑补美化任何赛道，重点关注自身成长。
2. 个人能力
ToB产品经理在职场中有三棵技能树：领域知识，产品技能、职场技能。网上随处可以搜到的老生常谈在此就不赘述了，主要还是记录几点重要心得。
2.1 领域知识的快速积累
ToB相对ToC更复杂和具有挑战的是领域知识，所以成形的ToB业务一般有COE（领域专家）、Solution（解决方案）、Delivery（交付）等团队围绕业务核心为客户提供端到端的服务。
快速熟悉业务环节是理解业务中各角色痛点、痒点的基础，否则很难和客户共情，也很难与客户建立信任。
如何快速积累领域知识？以下是几条经验：
1. 用2周时间快速浏览网络知识，输出行业现状与挑战、竞品分析、公司基本情况等成果
2. 入职后用1周时间获取并学习产品材料，迭代丰富1中对行业和公司的认知，了解使用公司产品的用户角色，输出问题清单并请教乐于分享的同事
3. 开始做一些小需求！在需求评审和迭代过程中不断加深对业务的理解
4. 不要脱离客户，找机会深度体验一周以上用户的工作，找到真实的痛点
5. 不要脱离市场，收藏分享行业资讯的网站，紧跟时事
2.2 迭代产品技能：做好“中间件”，提高对接效率
笔者入职以来，即使从产品策划晋升为高级产品策划，工作重点基本没有脱离识别客户需求、给开发提需求、跟进项目交付并解决问题这几个方面。
2.2.1 对客户： 识别“关键人”，满足小团体的需求
经过PMF阶段，产品一般已经论证清楚客户公司的需求，也能创造足够客户价值。但经过PMF的产品往往也会陷入一个盲区，认为给客户公司创造价值等同于给客户公司创造价值，但往往在推动客户成功的环节会陷入停滞。
实际上，识别客户小团体的需求也是tob产品经理判断需求优先级的重要影响因素。说的更直白点，客户使用你的产品后，不会把自己干掉，而是能够体现个人价值从而达成KPI；另外还有例子是，客户不在意软件本身带来的价值增值，更重视花钱后能不能发表论文、申请科研成果等。一些“学院派”的PM会对这种打法不屑一顾，但实际上这些都是帮助客户成功的一部分。
不仅销售需要识别关键人物，让客户有效使用产品是帮助客户成功的前提（而不只是领导参观的时候打开演示）。客户关键人的识别其实很困难，我们也遇到过对接几年的角色实际上没有决策权（虽然我们花了很多时间服务他），可以尝试通过销售/客户内部OA系统/网络了解真实的关键人物，提高产品使用效果的迭代效率。
2.2.2 对研发：收敛控制欲，关注价值和实现成本
产品主要和架构师对接需求（直接和开发单线对接会有很多坑，吃力不讨好），需要做的事情是给出需求优先级、详细描述需求和把控最终结果（交付时间点、需求实现效果）。
评审实现方案不是给出实现方案（当然产品需要掌握一定技术水平，可以不会写代码，但要有底气去质疑方案low）。笔者认识有强烈控制欲的PM，干涉技术的实现路线，不仅让开发颇有微词、自己也疲惫不堪。“高关注（结果），低干涉（过程）”能让PM更聚焦需求和投入产出的评估，成长会快。
另外，他山之石可以攻玉，产品要时刻关注市场上的新技术，判断是否能低成本地解决当前紧急重要的问题。
2.2.3 对项目：降低依赖的前提是产品足够标准化
产品经常质疑项目：难道只会拉会？自己没有解决问题的能力吗？什么都要产品上那项目的工资请分我一份。
项目也经常质疑产品：文档这里差一点那里差一块，整个实施方案耗时耗力还容易出错，项目天天在现场出问题就被骂的压力产品能理解吗？
项目人员的能力没法控制，PM要划清项目和研发的边界，需要首先从产品侧发力让整个产品交付过程标准化、轻量化。如果下次面对项目的问题，在质疑项目能力之前先问问自己：必要的文档都给到项目了吗？文档里所有内容都清晰可理解吗？产品功能实施方案是最优不可简化的吗？做到开箱可用了吗？（这里的坑也不少，以后可以详细谈谈）
2.3 职场技能：重要但最容易被忽视
进入职场初期，我最大的疑惑是“怎么只有我加班？”“怎么只有我生气？”，慢慢掌握一些职场技能后发现做事效率更高了、内外的团队关系也更紧密。下面分享几点重要的心得：
1. 吵架是必须面对的，但不是必须的。学会避免“上头”，在争论发生时冷静识别争论双方利益对立面，以满足客户需求为导向，找出双方都可以接受的方案（一般）。
2. 当开发说“做不了”时，你可以和他沟通是觉得需求不合理还是实现方案有难度，前者不必谈（前提是你的需求已经经过评审），后者你可以拉一个能力更强的技术来评估所谓的实现难度。
3. 不要让事情留在自己身上/团队里，不要因为你的效率高就越俎代庖，你并不具备另一个岗位能掌握的能力与视野，高效合作很重要。
4. 向上管理：常见的学生思维会被动等待任务分派和被认可，不擅于甚至羞于主动提需求。主动是职场快乐工作的秘诀，想要有更挑战性的工作？觉得目前工作开展有难度？找你的boss喝杯奶茶好好聊聊吧！
3. 小结
本篇主要回顾了上一段工作中个人能力发展方面的心得，下一篇我会继续分享产品认知方面的感受与体会，将围绕为什么选择SaaS，市场为什么选择我们，AI是不是万能的解药等问题展开阐述个人想法。
2万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
