一、交互转产品的心得
1. 优势
我认为交互设计师转型产品经理存在一定的优势，比如思维逻辑性比较强，注重用户场景分析，可以将用户体验的理念贯穿在方案设计中。不过产品经理负责的内容更广泛，需要与开发技术打交道。如果缺少技术知识，需求评审时会遇到各种问题。我就多次被开发人员 diss，不过也不必过于纠结和压力过大，抱着学习和讨论的心态不断进步，经常性的总结自己的得失，总会积累起足够的经验。
2. 对技术能力的要求
我始终认为有专攻，产品经理主要工作在需求层面，吃透业务，做好需求分析和功能设计最为重要。技术实现层面则主要依靠开发人员，产品经理只要参与沟通和协调就可以了。
作为产品负责人，产品经理的压力会更大，在一些问题上要学会自我和解。比如技术能力，无论你如何学习，也无法与专业的技术人员相比。很多时候功能的落地实现必须由开发工程师参与其中，他们不能只做编码工作，只有大家共同协作才能更好的完成工作，必要的争论甚至争吵是不可避免的。
二、快速适应产品经理工作的方法
我负责的是数据治理、数据开发领域的产品，业务中包含了不少技术侧的知识，比如 API、数据归集、清洗处理等。对于“零”技术基础的我，每一个需求都需要花费不少精力去学习、分析，既要深入地理解业务，还要快速完成产品功能设计，所以必须要找到一套适合自己的方法。
1. 向内挖掘
①产品文档与系统走查
入职新公司时，公司同事一般会提供一堆的产品文档，帮助我们快速了解产品。不过文档材料可能会存在各种问题。质量参差不齐，有的缺少各种必要信息，大量的文档阅读体验并不友好，效率并不高。有的文档更新不及时，跟实际的系统开发功能不匹配。
我个人认为除了阅读产品文档，还需要体验走查产品系统，帮助我们更好地理解系统逻辑和业务功能。在体验产品系统时，作为系统新用户也更容易发现产品问题，可以纳入后续产品迭代的需求池。
②他人的经验
应届生入职时，公司通常给新人足够的时间和机会成长，安排专门的带教人传授各种经验。社招员工不会有这样的待遇，不会有人给你做产品知识培训，只能依靠自己野蛮生长，需要自己主动向其他同事学习。不过每个人都很忙，请教他人时也需要一定的技巧。
首先我们需要对产品有了基本了解之后，带着问题去跟同事沟通，甚至带着简单的方案去与同事讨论。这样沟通的效率会更高，也更容易激发出对方的沟通欲望，有助于我们收获更多的产品信息。这对后期的产品设计工作非常重要，因为我们过往的经验很可能与现在的产品并不相符。
比如一款数据归集系统可以包含很多功能，比如结构化数据、非结构化数据同步、甚至整库的迁移同步，此外还有各种 ETL 工具等等，满足各种场景的需求。但是如果公司并不想投入太多精力，对产品定位只是归集数据的展示和管理，其他的功能依靠第三方工具实现。产品经理的设计规划就只能基于这样的定位展开，否则只是一厢情愿。
另外与同事的沟通时，我们还可以了解产品的研发背景，一些产品问题的历史根源，甚至可能会挖出公司隐秘的权力斗争和团队矛盾，避免在今后的工作中踩坑。
③需求沟通
产品经理接收到的大部分需求只是“一句话”，比如优化 XX 流程，提升 XX 能力。实际上这些信息都有特定的故事背景，只是在需求传递的时候被精简掉了，所以当我们接到需求时，首先要了解需求的背景、目标等。
遇到这种情况，我会进行一定的分析和思考，总结出产品中存在的问题，以及初步的解决方案，然后与 leader 讨论，确定自己的理解是否正确，并为为自己的一些疑问点寻求答案，这样基本上可以明晰需求中的主要设计方向。
另外前期的思考可以让自己做好充足的准备，当 leader 的想法与自己不一致的时候也可以充分表达自己的观点。
④梳理流程图
之前做 C 端产品时业务比较简单，对流程图并没有足够的重视。进入到 B 端产品领域，愈发感受到流程图的重要性。
在需求分析阶段，流程图简明扼要地展示了业务顺序和逻辑关系，可以为后续的需求设计做好规划和指引，避免场景的遗漏。
当涉及到跨系统、跨角色的需求时，我们很容易将关注点停留在自己产品这一侧，导致跨系统衔接点功能缺失。需要借助泳道图从更加宏观和全局的视角，审视业务流程和用户场景，找到产品的问题点。
在设计评审阶段，流程图可以辅助你清晰地表达需求内容，让参会人员更容易理解需求流程和业务逻辑并达成了一致，这样后续的原型评审才有意义，也更容易水到渠成。
2. 向外学习
①竞品文档
之前做交互设计的时候，觉得 B 端的竞品分析比较难做。因为 B 端系统主要是面向企业客户，很多产品采用私有化部署方式，不对外提供试用服务，产品白皮书也无法轻易获得，只能通过官网了解一些粗浅的信息。
有了 SaaS 模式之后，产品开始提供试用服务，但是需要提供企业信息，然后有专门客服跟进沟通后才会提供账号密码，并且这些试用账号还会限制有效期。不过即使登录了系统，有些业务流程也无法完全走通，比如审批流程。或者因为缺少必要信息无法完整体验产品功能。
不过一些大厂的产品体系比较完备，例如云厂商既可以注册账户，也可以查阅产品文档。大厂的文档材料非常的详细，包含了产品界面、业务规则、功能介绍等信息。只要耐着性子学习，可以学习到很多产品知识。
② 学会抄作业
产品的很多需求在竞品中都能找到相似的功能，可以给产品经理的设计工作带来很大的帮助。但是这并不是要无脑抄作业、完全照搬。可以向竞品学习一些底层的业务逻辑，至于实现方式和做到什么程度，还是要基于自己产品的客户场景、产品定位决定。
比如之前我曾经收到过 API 流控的需求，市面上有很多这样的产品。有些通过插件的方式实现，有的功能强大，除了 API 流控，还有针对 IP 和应用的流量控制。经过分析这些功能与我们的产品并不完全匹配，我们只是参考了竞品的底层控制逻辑，实现形式做了简化。
如果功能只是全盘照搬，自己有没有想清楚业务逻辑和用户场景，在需求评审的时候就很可能会翻车。
