产品经理，一个不太懂技术，又不直接负责业务，手里还没什么实权的角色，偏偏从上到下都在跳跃，哪里都能看到他的身影，哪里都能有他参与。那么就产品经理如何去做到尊重这个岗位，又能优雅的管理好自己，我们来细致的聊一聊。
无意中看到一篇关于和产品经理做业务沟通的文章，趁着有空，好好的阅读了一下，发现对话的过程很有意思，也很值得思考。
有一个前公司关系还不错的同事跳槽到新公司了，正好在现在的公司附近，就约了一起出来坐坐。其实就是叙叙旧，相互聊聊天而已，但真实的情况是整个过程都在听他诉苦，在各种抱怨。
A告诉我，在入职前和入职后，面试官和公司之间发生了巨大的变化。
在面试时，说的工作内容和时间工作内容有很大的偏差，而且涉及到跨行业所以有很多条件是A完全没有接触过的，没有人对接，一上来就直接要负责填坑；不光要解决前任留下来的各种问题，还要解决销售对外吹破天然后拿回来的单子。
还有就是入职半年了，基本都是干杂活，都是些体力输出的事情。比如因系统故障导致200个单据无法同步，就需要A同学手动一个一个录单。
哪怕是这样他现在的上级对他也很不满意，觉得他在这边价值不大，做的事情也不重要，没事还要PUA他一下。
A同学现在压力很大，经常怀疑自己的能力；不得已只能持续加班，又被同事说内卷，然后在排斥他。
其实A同学本身还是很优秀的：重点本科毕业，之前又是在大厂做事，还是优秀员工，还有优秀项目奖章，在任何一家中小公司做个高管不成问题的。只不过被大厂毕业了而已，所以自己也降低了身份，到了一家中型互联网公司去任职，做了副总监，下面有几个新人，老人归总监管。
A同学说，他被PUA印象最深刻的一次是：那天中午，大家在一起开会，A同学正在教导新人产品逻辑定义的时候，被总监吼了一嗓子：A，你的原型为什么还没做出来……
话说A同学虽然不算行业里的大牛，但他的价值远远在画原型、写文档的工作范围之上。
A同学特别想不明白的是：为何这个公司要如何对待一个高能力的人，花大价钱招来一个好手，却给安排做一些常规的事情。
话说我在经历的众多公司了，多多少少都会遇到这个情况，就是公司招来一个大佬，但实际却没有可以发挥的地方。
另外可能外加一些其他的客观原因：办公室政治内斗、部门领导不希望下属太强等、团队里的人排挤等，很多的时候，并不是上级在施压，还有同事之间的相互关联。
其实，很多的时候，这就是互卷的原因——同样都是工作了10年的人，凭什么你从大厂跳槽来的，薪资就要高一倍，我跟着公司做了这么多年，还要受到空降兵的压迫？
有时候，可能是无心，但这也充分体现出一个人的教养问题，如何保持对他人的“尊重”：当我无意中说了一句话，当我无意中做了一件事情，就会刺伤到别人，而我却无感知。
产品经理这个行业，因为入岗快、基础低、要求不高，所以来了很多人，我们都知道“人人都是产品经理”，但好的产品经理却不多，这就导致很多人对产品经理这个岗位有歧义，认为做这块都是高岗高薪低水平的人。
通过几个案例，来沟通下如何去“尊重”一个产品经理，希望能够纠正一些错误的观念，也希望能改变一些产品经理的职业素养。
想要别人看得起，先得看得起自己，尊重是用能力来说话的。
所谓当局者迷旁观者清，当你沉醉在自己的世界中，你是无法站在客观的角度来评价这个事情的真实情况。
就拿实际的业务来说，使用Axure来画原型依然是很多产品经理的传统模式，他们更习惯在自己的环境中去做事，较少能够学习和利用新技术来提升自己。
这种情况在传统企业，在老一辈的产品经理经理中最为常见。
他们需要进行产品设计的时候，依然还是用线框画出来一个一个的方格，然后在里面做交互。
实际我们都知道，产品原型的表达方式有很多，而使用Axure如果还依然是在用单机版，那么团队协作、交互设计将会增加很多的额外的工作量。
视野开阔一点的产品经理都知道，现在的原型设计，并不只是简单的做出来一个线框图就可以了，也不是说你在原型上面加点文字描述丢给研发就能实现。
你要基于商业化的策略进行考虑，这个产品——要怎么样能赚到钱。只有考虑如何能够赚到钱，才能满足产品设计的最基础定义——解决温饱。
产品功能设计是最业务流程中最基础的概念，之所以很多人复杂是因为：没有很好的梳理出来对应的业务流程、节点、规则和处理条件。
好的产品设计是要保证业务流程简单，数据交互清晰，节点有对应的判断条件，并且可在一定的情况满足和包容特殊的分值情况。
如果你对产品设计上升到一定的高度，你就会发现：很多的时候需求其实“很简单”，特别是在信息化的时候，用户并不需要那么多高端的流程，他们要的很简单。
只不过这个“简单”在历史遗留的糟糕产品设计之上，就变得复杂起来的。
比如你要做一个一人申请多人报销的功能，初始的想法就是在申请单上添加一个关联人，报销的时候关联人去选这个申请单就可以了。
但实际在做的时候，你发现“申请单和报销单之前是定死了一对一的绑定关系”，然后你又发现“报销单的审批关系是完全匹配申请单，多人没办法用新的审批规则”，等等这些实际的历史问题，会困扰着每一个产品经理。
这也导致了很多人在新规划产品设计的时候，特别不习惯改旧流程，总是希望能够使用新的规则。
作为一个产品经理，吸收多元化的知识，这是一个基本的常态。
我们既要做到适应当前的环境和条件，先去解决问题，把当前的节点处理掉，然后在想办法来优化、完善、改变。要事有三条，解决为优先。
之前的系统条件是：先和各部门确认好，然后在约定的当天进行手动调整，同步其他各系统接收新组织架构做部门和人员同步。
这当中有一个很大的问题：既新组织架构生效后，旧组织架构中在走的审批流无法变更，要么催促尽快完成审批，要么管理员手动根据旧组织架构的审批条件，重新定义新组织架构的审批条件。
现在的系统新增了一个条件：允许存在新旧组织架构，既同时存在两套规则，在新组织架构生效后，新申请的申请都按照新组织架构的流程进行；原来旧组织架构的审批流还可以继续扭转，但会在审批流和给节点审批人做标注提醒，还可以做加签处理。这样就不会影响实际业务的正常运作。
社会在进步，人类也在进步，你的经验只是在过去的时间里产生的价值，也用在当前，但无法适应未来。
在任何的领域，底层逻辑是相对的固定，但在应用的前端一定是随着市场、时间、环境等客观原因在进行变化。
在多数的时候，经验很重要，当你有经验的时候意味着你可以快速下手，可以马上定位问题。
但由于很多表面的经验都是死的，大多数人缺乏的是一个熟能生巧的过程，也不懂得在常规的经验中体验出精髓，只会盲目埋头干，所以我们不应该因为自己知道很多的知识，就以为会比别人更强，以为自己高人一等。
在很多的时候，我们会发现一个事件：当系统发生了某件事故的时候，需要做大量的单据处理，量居多而且相对麻烦，那么一些人在没有排查清楚问题和定位好解决方案前，就先夜以继日的埋头苦干，加班加点的熬夜手动去操作。
然而，他们不知道的是，很多的时候只需要程序员写一个SQL就能解决：
sql=”select * from 数据表
where字段名=字段值 order by字段名[desc]”sql=”select * from 数据表 where字段名like ‘%字段值%’ order by 字段名 [desc]”
sql=”select top 10 * from 数据表 where字段名=字段值 order by 字段名 [desc]”
sql=”update 数据表 set字段名=字段值 where 条件表达式”
sql=”update 数据表 set 字段1=值1,字段2=值2 …… 字段n=值n where 条件表达式”
做产品，不是说有苦劳就好，还得看你的功劳才行，团队的概念就是集合大众之长，取之精华。
所以这里我们要不断的接收新型的事物，暂时抛弃自己已有的经验，去学习和获得更好的知识。
请教同事，没什么不好意思的，很多的时候我们只是不知道还有更好的方法而已，出现问题的时候，多一句话问问，或许就有一个新的解决方案。
在需求讨论会的时候，用正确的态度，诚恳的表达出自己希望能够希望大家的想法，来打破自己固有的思维，其实是一种很不错的提升方法。
如果能持续以这种方式和方法来保持自己的态度，同事相对也会很“高兴”的让你从他那里学到新的内容。
之前的系统条件是：先是正常审批，如果是超标要升1级；
额外条件1如果是申请人身兼多岗，以最低岗提交还要自动升级高岗匹配条件；
额外条件2在审批规则中如果遇到节点为空（没有部门负责人）时，需要往上升1级审批，最高到当前当前申请人的第三级领导；
额外条件3如果当前人员的上1级领导已是最高截至。
额外条件4如果是遇到指定审批人，要同时判断是否1人多岗，按照最高岗位来定审批规则。
每次遇到审批规则调整，都需要系统管理员，对着手工表格，一条一条核对，异常繁琐，且容易配错误。
之前一直不肯上新的业务，就是来回调整过基础，每次都出问题，还要系统管理员自己收拾烂摊子。
现在的系统新增了一个条件：复制模拟审批流，既可以从当前的审批规则中，复制出来一条线（含主线下的分支），做临时使用，可针对个人、部门、单据、时间做临时管控。
当你以专家的去指点别人的时候，虽然能够解决问题，但很多的人并不服你。而你在不小心说错话，或做错事的时候，就会被人落井下石——特别是当你在赶时间出货粗糙的时候，更会被别人指指点点。
在大多的时候，人们只能看到他希望看到的东西，凭什么他比我高一级，他连一点逻辑都做不好。
实际上一个小时的评审会，别人只有这一点出错了，而你却恰好看到了这一点，并放大到了这一个小时里。
很多的时候，我们会不由自主的把自己代入到其他的角色上，并幻想如果是我在这个职位上，我要怎么怎么做的更好，其实这种阿Q精神就是对自己能力的一种隐晦折射。
要考虑一点：大多数的人都会很在意别人说自己的不好，会忽略别人高于自己的地方，会下意识的提升自己顺便贬低别人。
其实在职场上，同事的面试该卖还是要卖一下，维护好同事之间的关系，有利于持续发展。其实在工作上每个人的精力都是有限的，特别是遇到跨系统对接、跨部门协调，稍微遇到一点扯皮的事情就要纠缠半天，本身是为了一个问题要协同解决，结果到了最后是赔笑了半天求人家解决这一个问题。
不同岗位上的人，就是对其他岗位上的补充，比如数据分析，你以为的数据分析就是得到结果，识别状态，做下标记，得出结论就可以。
实际数据分析岗要先拿到数据，然后去清洗数据，然后在对一些条件做客观的判断去做数据验证，最后是匹配规则，最后才能生成结果，最后进行验证。
对于自己不太清楚的岗位内容，不要随意的下结论去否定他人，更不要以自己以为的结论就去定义他人。
当然，有些确实是在磨洋工的，就一定要提出反驳意见。
之前的系统条件是：产品先自我评估，然后产品内部评估，然后在找业务评估，最后上会和研发团队一起评审。
当研发团队按照研发的角度来定义时，就会发现产品需求可能没那么重，或者该流程会增加额外的工作量。研发团队也会对产品需求进行评估，看工作量，看应用程度， 看结果转化。
这个时候就特别怕产品一直在磨人，研发受不了就会直接拍桌子。
现在的系统新增了一个条件：产品带着研发体验用户实际操作的过程，让一个特别熟悉系统的人去模拟不怎么用系统人的操作，这样研发才能切身的感受到对于需求优化带来的好处。
所谓的切换角色考虑，并不是说你直接把自己当做另外一个人，你还要把自己降低到当前环境的条件中，这样你才能真正的考虑到为什么做，要怎么做。
任何一个行业，任何一个岗位，都有很多的前辈遗留下来很多的资源，这些资源都可以很好的拿来利用。
一个真正有能力的人，是会借力打力，在遇到困难的时候能够第一时间找到能够解决的人，或能够给出解决方案的人，他们会尊重公司的“前辈”，学习他们特有的长处，并转为自己可在利用的能力，让自己在激烈的竞争中处于不败之地。
如果你一味的自我专研，很容易就陷到误区中，做出来的产品只会自嗨。
大多数的人都是平庸的人，他们无法思考跨越天空的难题，只能小步快跑，那这里就是看你是在别人已经铺好的路上面跑，还是选择一条充满着艰难险阻的道路。
已有的资源是在已有的环境中，通过验证后得出的结论，很多的时候都是经验堆积出来的，新人在刚接触的时候，确实会不知道里面的规则，那么友好的请教一些别人，就能够马上掌握里面的规则。
业务部门提报：有一个新业务诞生，需要新作一套业务流。通过沟通，发现该需求和公司很早之前一套废弃的流程有60%的内容是匹配的。那么在这里我们就可以复制这套业务流，然后在此基础上进行二次修改。
切记不要直接启用然后变更，废弃的内容，不用放着不要紧，一旦启用会出现很多意想不到的事故。
1、先定义好角色和层级。
2、在定义业务主线流程和各逆向分支节点。
3、定义各字段的设定条件。
4、做好节点跳转关系。
5、识别判断逆向条件的处理方案和扭转条件。
6、各终点结果呈现和对应结果通知。
7、数据大屏呈现。
这个是对应的业务条件，那么对应着这些业务条件去看公司当前有哪些已做好，可借用的内容，拿来去做二次转化。
这里要注意的是：你需要的是请教和沟通，而不是直接上来指导。
对话和指令是两种方式，不要以你当前的结论去定义别人的行为，良好的对话是两个人直接相互碰撞、融合，产生精华。
很多的时候，产品经理会被追问一个时间节点，比如组合商品销售，A商品40元，B商品30元，C商品33元，组合售价100元（含10元店铺红包），现在A商品仅退款，B商品既退货又退款，需要产品经理给个完整流程的方案和数学定义公式。
先不说数学公式怎么做到通用匹配，就说这个业务关系的正向流程和逆向流程要怎么判断就够产品经理好一阵思考了：这怎么直接给你一个时间节点的呢，我是说1个小时？还是1天？还是10天？
很多的领导不懂得思考的时间，不懂得如何估算大家的工作量，只会定义这个需求很简单，你去说下，明天上线；实际这里会有很多的问题，要经过思考，要梳理流程，才能确认各节点之间的关系和最终结果的定义，然后在进行开发、测试，最终上线运行。
思考是一种本质的定义，在通常的定义中，我们会下意识的形成肌肉记忆，既遇到问题自然的想到当前问题之前是怎么解决的，现在还沿用之前的方法一样就能够解决。
但，节点会变、场景会变、条件会变，那么一成不变的方法就不能解决大多数的场景。
产品经理这个时候就会考虑，如果我把条件扩大一些，把范围设计广泛一点，这样是不是就可以包容了更多的场景，就能达到一力降十会的条件了。
就比如手机号的限制，通常我们以大陆的手机号来做定义都是数字1开头、11位字符、纯数字这三个条件就能够基本满足了对吧？在此基础上，然后还可以在加上前面2位不可重复，在前端多增加一步判断，就可以让后台少一步识别。
用户不想要个锤子，用户想要的是照片能够在我看到的地方：用胶水贴上去。
电子屏、投影仪和锤子的区别是什么？是解决掉用户想要在我想要看到的地方有一个影像，那么基于这个场景条件，然后在看自己的产品能匹配上哪些。如果依然还是一个锤子的事情，我可以提供长钉、膨胀螺丝，还可以提供组合相框，或上门服务。
都说人人是产品经理，但很多人实际做不好产品，因为他们只会从自己的角度来理解问题，来解决需求，并不能系统化、大众化、合理化的定义需求。而是通过不断的迭代产品，不断的提升成本，不断的复杂流程来定制+针对来满足需求。
那么真实的理解一下当前的需求，多问两句，真实的用眼睛去看下，用脑子想一下，实际操作一下，你就会发现用户说的和想要的实际有较大的偏差。
一款好的产品，必须包括这三大要素：充分的动机、足够的执行能力，以及一个恰到好处的触发机制。
专栏作家
老虎~色，公众号：产品经理有话说，人人都是产品经理专栏作家。13年产品经理经历，拥有优秀的方案解决能力，擅长通过问题反推业务主导产品。
本文原创发布于人人都是产品经理。未经许可，禁止转载
题图来自Unsplash，基于CC0协议
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。