“在这加一个按钮，跳转一下就可以了”，“加个配置功能吧，扩展性好一点，业务后续可以自行维护”，“这回需求不能变了”，“把文档补一下，这块的具体逻辑写清楚点，还有具体的接口描述”
每天我都会听到类似的对话，有时候我在想，这些对话背后到底隐含着什么问题，通过一个个文档串联出来的产品或者系统到底会变成什么样子，作为产品经理到底应该把需求描述到什么程度才算可以，这个表面看是一个流程标准范畴的问题，实际影响着整个产品线的整体发展。产品经理和技术的沟通方式到底应该是什么样子的，产品经理是否要懂技术。到底产品和研发两个角色的价值体现在哪里，很多团队对两个角色的绩效考核标准是工作量，能力考核标准又是通过晋升述职时的短暂整理表述体现。到底我们应该从这些问题中怎么突围。接下来我谈谈我的感受。
我想用两个词来尝试分析上面提到的问题，“视角”、“影响”，
我是从研发转型到产品的，还记得当时身边的研发兄弟们开玩笑说“技术实力不行了，转产品动动嘴挺好的”，转到产品组后我的新产品兄弟又对我说“总算有懂技术的了，给我们好好补补，到时候好跟研发PK”，我想了好久到底我对自己之前的研发技能要怎么利用，转换角色后我又要取舍什么。经过这几年的一个整理沉淀，我现在的想法是，之前的技术能力只能用于我对问题的理解，而开展工作过程中我要做的是转换视角，用产品经理的视角思考问题，有时候你可以尝试在解决一个问题的时候，刻意的去避免讨论技术实现方案作为你的产品设计方案。比如，“在数据库里冗余一个字段，这个报表就能实现”，“在代码里加一个枚举，区分以来两个业务来源”，“我找一个接口，你调用判断一下是否，然后分别走不同的逻辑”。其实你可以看到这里面很多场景都是从你的口中脱口而出，或者经过你的大脑思考，想尽办法去说服研发帮你实现这个效果。整个过程中，产品的作用到底在哪里，产品开发上线的整个生命周期中，你的工作与研发架构师的工作区别在哪里，或者换个角度来说，有产品经理这个角色开始，那一定是有一些别的工种不会做需要你来完成的任务，那这部分任务到底是什么，是不是需要你来做，缺失了会有什么问题。
我们用到的第一个词就是视角，做产品时，需求的分析挖掘工作，是产品经理的本职工作，做到完整性、不失真、体现出优先级几方面的内容是产品经理的职责所在，拿出一部分精力去理解客户说的需求背后的真正意图，在以后的产品结构的基础上，朝着团队产品规划的方向进行设计和描述是产品经理应该有的一个视角。如何把用户需求、业务运营、商业计划几个角度的信息与设计方案、技术语言连接起来，中间那部分就是产品经理应该做的。你需要有一些方法和技巧能够让用户尽可能多的表达他的问题，尽可能的掌握现在的产品或系统现状。然后用产品的语言把问题和产品方案描述清晰，在产品的角度技术架构是细节，在技术架构的角度逻辑代码是细节。不要拿别人的思维方式干自己的活
刚才描述的整个过程中，其实是有一个传递的过程的，但这个过程我更喜欢把他叫做影响，如果你想要实现一个你认为的产品功能，与其跟技术人员聊具体的实现方案，不如聊这个功能为什么要有，如果有应该是什么样子的，如果是另外一个样子会有什么问题。一点一滴的通过每一次接触来表达你对产品设计的思路，在落地过程中去解决不同工种工作过程中的问题，逐渐你会在你所接触的周围产生一个影响，这个影响将不是一个按钮的摆放，不是一个数据字段的有无，而是你对用户需求的理解，你对问题描述的准确度以及在这个工作开展过程中你的作用与价值。
如果这条路可行，那么研发会在自己的环节专心做自己的事，而你就专心用产品的视角解读真实需求并做好传递工作，最后你的产品设计就会影响到技术架构。
写于二零一七年十月十九日
