我的“草根”产品之路
转型之缘
2016年，因为孩子开始读书了，我选择在集团内从杭州湾研究院调到杭州总部一个新业务事业部，接触的业务从传统的整车开发变成了共享汽车，岗位也从整车研发项目管理变成了共享汽车项目经理，这是调过来时沟通好的。
但2016年后半年，国家正在加强对新能源汽车的监控，并即将于2017年1月1日开始实施《GB/T 32960 电动汽车远程服务与管理系统技术规范》。整车能否按照国标的要求完成平台符合性和车辆符合性认证，关乎到整车是否能够进行公告认证及销售。集团层面希望监控平台能掌握在自己手中，事业部领导希望能够将新能源汽车监控平台作为公司的拓展业务。因为需要频繁与研究院电子电器团队沟通，作为事业部里唯一有整车研发系统项目经验的人，我被安排协助同事负责这个项目。结果干了不到一个月后，这个项目彻底给了我。没想到当时的一个帮忙，竟然改变了我的职业方向。
转型之路
从2008年毕业到2016年，我干的一直是传统行业的项目，从汽车车零部件的结构设计到整车研发项目管理，做的产品都属于“看得见摸得着”的类型，接触的产品开发流程也是三维建模、模具开发、注塑冲压与组装，这些与我的材料专业也算是对口。突然做一个“看不见”的监控平台，并且与我的专业知识也没有关联性，一时间有种无从下手的感觉。
但任务来了，只能想办法往下做。以我在整车方面的知识作为基础，以逻辑思维为支撑，拿出国标规范仔细解读。先把国标要求的主流程逻辑理顺，其中的具体技术实现细节与开发同事反复讨论、沟通，大概梳理出项目任务。这个过程中，也得到了整车侧同事提供的原监控平台的一些信息，这个对我帮助很大，可以让我知道主流程是否完整。事后回想起来，我在这个过程中更多是一个项目经理的角色，工作的重点在于业务上的梳理，并完成从国家监控平台到整车研发、生产基地、商务中心、售后服务的整个业务链的对接，而真正的监控平台产品设计部分，是架构师帮我完成了。
缺的功课总要补上的。当时的国标对监控平台没有强制性要求做后台portal，所以当监控平台与国家平台联调通过，车辆也能接入到平台，并实现数据转发到国家平台，我以为这个项目就算完成了，还为此开心了几天。后来等到上海地标认证，才发现还缺少一个必要的portal进行后台管理。但国标和上海地标对portal没有像《GB/T 32960 电动汽车远程服务与管理系统技术规范》一样有明确的要求，只有一些笼统的要求。我再一次傻眼。
于是回到对标思维，了解研究院原来监控平台供应商是怎么做的。当我拿到了他们的平台使用手册，仔细阅读后，以为找到了救命稻草，立马就组织开发同学开会，告诉他们就按这个做就行了。结果当然是被开发同学一顿怼：PRD没有，原型也没有，怎么做？我心里嘀咕，我做硬件就是这样啊，拿来一个样品，自己测测尺寸，就可以三维建模了，然后出图纸、开模具就行了。现在“样品”都有了，为什么不行呢？尽管被怼得委屈，但毕竟是跨行，还是抱着万事虚心的态度，第一次不成功的产品会后还是认真找前端经理了解了互联网产品的开发流程和产品经理需要提供的文档。经过痛苦的思维转变及向同事请教，我完成了自己真正意义上的第一稿产品文档及原型设计。如果说新能源监控平台项目里我是项目经理，从这个portal开始我才算是真正转变到产品经理。
渐入佳境
接下来的几个月里，我沉醉在优化PRD和原型设计里，并且从中获取了突破自我的巨大乐趣，甚至一度考虑去读个交互设计的研究生。此后的2年里，我带着小团队一直在迭代新能源监控平台，业务侧不仅接入了更多车型，也整合原来的监控平台，帮集团拿到了补贴，优化了售后换件流程；功能侧也进行优化和增加，也打通内部很多系统，甚至还通过监控平台收集到的数据分析出底盘系统的bug，那时我一度觉得自己彻底完成了从传统项目到互联网产品的转型。
2019年开始，因为业务的调整，我开始参与TSP（telematics service platform）的产品工作。在我做新能源监控平台的过程中，公司经过组织架构调整，我们小团队归属到了云平台部门，新部门的核心业务是TSP平台。此时刚好是TSP平台因为业务发展需要进行重构，简单是说是按照新的规划，重新开发一个TSP，并把原来的业务及数据迁移过来。其中我负责的部分是新平台的管理后台。
原以为借着做新能源监控时的经验，我可以很容易完成新平台的后台设计，等到动手才知道，新能源监控平台相对TSP来说只能算是一个小的业务模块，一下面对一个包含众多业务的大平台的后台，要考虑的问题太多。就以简单的账号管理和权限管理为例，首先需要把业务的细节梳理清楚，然后再考虑用户体验，最后再把一个个功能原型设计出来，并且经历与开发一轮又一轮的沟通和评审，最终确定功能。小到每一个button的显示逻辑、文案，都需要反复斟酌。
产品打磨
在这过程中，我查了很多资料，也看了很多书，有交互设计的，也有产品思维，还有一些基础的技术知识，真正意义上进行产品基本功的打磨。虽然过程很琐碎，但不断收获的感觉很好，也让我与开发沟通起来更加有信心。再次面对开发的挑战，我能够把自己的设计意图有理有据地进行解释，不但高效完成了沟通，也促进了与开发的友谊，赢得了开发的尊重。
这之后，我又开始逐渐接触TSP的核心模块，比如远程控制功能、预约充电功能，逐渐把书上看到的在工作中运用，实现理论与实践的结合。
感受与建议
回首这几年的跨行之旅，对于想做产品的同学，有一些建议：
首先需要对产品有个整体概念，对产品方向、业务领域和用户类型进行全貌的了解，从中找出自己喜欢和合适的产品方向、业务领域，确定今后打算做哪类用户类型的产品。简单地说，就是有一个“我在哪儿，我要到哪儿去”的概念。
其次是练好产品的基本功，不管是刚毕业还是要转行，这一点都很重要。基本功包括产品常用的工具使用、需求分析、用户调研、竞品分析、方法论等，这些在很多产品的书和垂直论坛以及公众号上都可以看到。拥有了这些基本功，能够提高自己把思路转变成方案的时间，也能够进行规范的输出。不但提高工作效率，也提升个人品牌形象。
要确定好自己要坚持的行业，对于做B端产品的同学，这个尤其重要。因为B端产品对行业知识的积累要求更高，只有产品的基本功，还不足以支撑完成一个好的产品设计。只有了解业务细节、流程，才能设计出合适的功能。持续在一个行业的深耕，不但能让行业知识得到继承，也能掌握行业的发展动态，在产品设计上给出更合理的解决方案。同时在一个行业的深入，也能够在接触行业里的其他业务模块时触类旁通，快速上手。比如我现在负责MNO业务，这块以前完全没有接触过，但通过与运营商的几次沟通，加上对整个车联网业务的了解，能够很快形成MNO业务的概貌。每一个产品人，不但要具备USB人才的基础素质，更要让自己具有T型人才的可能，让自己快速熟悉新的业务模块，完成当前模块与其他业务之间联系的理解，缩短适应时间。
多与人交流，与各种学习方法相比，与人交流是最快的一种。我在转型过程中就吃了这个亏，与人沟通交流还是不够，当然这跟性格有关。有的人就是喜欢通过看书学习，有人就是喜欢多问多聊来学习，我过去就属于前者。在回头总结时发现，如果我一开始就多聊，哪怕不懂，厚着脸皮多问，我可能能够更早完成产品基本功的打磨，这个转型之路可以缩短至少2年。更早知道我该知道什么，我还不知道什么，我可以通过哪里去知道这些，而不是一开始我根本不知道自己不知道什么，也不知道去哪里获取自己想要的东西。这个过程中如果遇上愿意指导或给出建议的老师，一定要好好珍惜。
建立生活中的产品sense，因为做了产品，我会在生活中多关注其他产品，比如支付宝里的地铁出行，从一开始简单的二维码扫描，到后来的地铁路线查询、下车提醒设置、附近地铁站点查询，再到后来的乘车记录、出行优惠、场所码扫描，这些都是地铁出行场景里常用的功能。再比如支付宝的场所码扫描，刚上线时看不出是否扫描场所码，我还在想这里有个漏洞，然后没过几天，场所码扫描后就出现了“已扫描”的水印，产品逻辑闭环了，安检人员也一目了然。还是一个支付宝的案例，购买西湖益联保时，添加参保人员的页面，对于父母就没有增删功能，只有选择；对于配偶，就有增删功能。这个就很好覆盖了用户需求，功能不多也不少，没有因偷懒而冗余，刚刚好。再举一个例子，快递超市取快递，有时多个快递，并且还不是同一天到的，取件码的短信中间也被插入了其他短信，可能记不清有几个快递了，事儿不大，但也挺困扰的。升级后，每次扫码出库时，屏幕上会弹窗提醒你是否还有几个快递未取。虽然功能不大，但很好解决了用户的需求，我觉得都是好的产品，因为充分研究了用户需求。因为对产品的喜欢，我甚至在体检、购物支付、医院就诊，都会多看一眼他们的系统，看看他们的一个button怎么布局，他们的一个信息怎么显示。这些积累的素材，帮助了自己思考，也许哪天还能够助一臂之力。
逻辑思维，这个是产品经理的灵魂，我当时之所以有勇气接下新能源监控平台的项目，除了公司的安排，也是因为对自己逻辑思维的一点自信，认为自己能够实现这个突破。如果产品经理自己的逻辑都不清晰，小到产品评审时被开发挑战无法顺利完成评审，大到产品上线后用户体验差。
继续前行
2021年，我离开了这个给我机会完成转型的公司，来到凯捷。现在负责大众一个车联网平台的产品设计，这里吸引我的是完全从零开始搭建一个车联网平台，有机会把之前已经做的再优化，想做而没做的进行实践。
人生其实挺有趣的，大学时计算机课上觉得编程很难，我还默默地想，以后不要使用电脑，谁知到后来处理一个实验数据都要用电脑，到工作后更不必说，当然使用和编程是两回事。刚毕业那会儿，因为做汽车零部件的项目要去了解汽车各个系统，遇到不理解时在想以后我要避开汽车。结果到现在，我居然做了汽车＋互联网的工作，并且还很喜欢！
所有的经验和建议都有深深的个人烙印，我说的这些也一样。所以不要过度迷信，适合自己的才是最好的。
