时间: 2021-07-30 11:22:39 人气: 17 评论: 0
身为产品经理，你是不是觉得自己做了很多事却不被认可？勤勤恳恳上班害怕以后**失业？本文作者以自己的工作经验，对这个问题展开了思考，希望对你有帮助。
从开始做产品起，我们努力学习需求分析、产品设计和项目管理等各项工作硬技能，同时我们还不断恶补自己，提高自己的逻辑思维能力、同理心和沟通表达等多项软技能。却很少有人告诉我们职场中除了工作要求的硬技能提升，除了个人能力软实力增长，还有人际关系的经营的十分重要。
换句话说，你的人际关系也是你的工作能力。
我曾经特别天真，觉得领导就是我的救星，遇到难题时直接抛出问题，希望他们可以给到我答案；我曾经特别高看自己，觉得产品有权利决定需求做与不做，全凭自己主观判断业务方提过来的诉求；我曾经还特别清高，对那些阿谀奉承、刻意拉拢关系的人表示不屑，心里吐槽不如多去干点工作更为实际。
秉承这着这样的心思，那段时间我在工作中也困难重重，经历着磨人的煎熬。明明努力工作却得不到领导认可；团队内项目推进困难，没开发资源导致项目延期看上去不可抗力因素这样的原因，也得不到业务方的认可。
我一直信奉的一句话，如果你在这条路上越走越难，只能说明这条路本身就走错了。
现在回想起来，心里只装每天要完成的具体事项list，忽略对周围环境和人际关系的感知，抓不住主要矛盾是我感觉极差的一项关键因子。不管是面对领导还是业务方，需要的都是解决核心矛盾和主要问题的人，职场不承认苦劳。
产品的本质，是整合企业资源，为业务提供舞台，并让用户爽到。企业以产品为媒介，与用户进行价值交换，达成创造商业价值盈利的目的。产品在日常工作中**接触很多人，领导、运营、客服、财务、开发和测试等。
现在重新审视，我分成了三大角色：领导、业务方和产研团队，三类角色分别对应着各自的目标和侧重点，产品，是这三大角色之间的连接器。
在过去，我觉得领导是管我的。在他面前，我**觉得自己职级低，小心翼翼等着他分配任务，按照指令一项一项去完成。更**不自觉紧张，不自信，他说的每句话全**接受，从不质疑。
现在知道了原来领导是我的资源。我站在自己的岗位位置上，思考和规划负责业务线的目标和计划，向领导提出解决方案，阐述清楚所做每项事情的目的和价值，找领导拿资源来实现。
无论是跨部门受限于组织架构沟通困难的问题，还是没有开发资源无法按照预期时间项目上线的问题，只要领导认可了你做事情的价值，他都可以帮你搞定。
企业中的上下级关系是一种很微妙的关系。你既不能完全把自己当做一个下属，所有的事情都靠领导想，做一个没有思想只**按照指令做事的机器，在心中把他高高挂起。也不能越权表现，对领导毫无顾忌，过度表现自己。
思来想去，我觉得正确的姿态应是成为领导的合作伙伴，心里尊重他并帮助想他思考漏的或者没到位的点。和领导之间多沟通、多互动，站在领导的位置去思考问题，领导为什么这么想？他要我关注这个指标的目的是什么？这个指标是不是很紧急？等等。
主动帮助领导思考问题，提出合理的解决方案，减轻领导压力的同时让领导感觉到你对他权威的认可，让自己的工作变得轻松，也让领导感觉舒畅。
向上管理好领导的期望值是日常工作的第一个重点，说的庸俗一点的词儿叫“面向领导编程”，你所做的每件事领导应该认可。
我在产品实习阶段，我的产品经理经常挂在嘴上说业务部门，业务方，那时候我非常困惑，明明就是运营啊，为何称作业务，心想运营只是不同于产品的一个同级别的岗位名称而已。后来才知道什么是业务，什么是业务方。
在提业务之前，需要先理解企业的组织架构，理解一个企业经营运转过程之中，不同的部门存在的目的和它本身的价值是什么。
一个很经典的组织架构图，任何公司，小到几十人的公司，大到几千人、上万人的集团企业，大的组织架构层面上都**包含：市场销售部、客服服务、人力行政、财务和产品研发团队。
企业**研发自己的产品，纯互联网公司研发软件产品，制造类公司研发实物，不管哪种类型，都需要对外销售，销售就涉及到生意，也即Bussiness，包含着市场、销售、运营等岗位，商品售卖出去后就**有客户服务部门处理售后部门。
在组织架构中，类似财务、法务、税务和人力这些部门，常常被归类为职能部门，主要目的是保证企业的行政运转；而市场销售部、采购部等部门，需要围绕核心业务开展工作，直接承担企业经营的业务目标，比如今年要挣多少钱，被称为业务部门。
产品研发和财务等部门一样，承担着职能部门的角色，为业务部门提供功能赋能，产品搭台，运营唱戏，共同实现我们的业务目标。
理解这层概念之后，再看业务提供来的功能和需求，你可以往上游深挖，当前他提的解决方案是否可以真的解决他的痛点，为了减轻他们的销售KPI压力，是否还有更好的方法来替代，我们怎么样制定长远的项目计划来实现我们的KPI目标，而不再是停留在零散的功能层面。
目前的问题是业务目标不明确的问题，还是组织架构没有人处理的问题，还是业务流程混乱的问题，最后才提到IT系统支持的高效问题。
总之，和业务方对接的过程中，时时要思考的是他们背后的压力来源是什么，当前他提出的解决方案或者你正在做的事情是否可以解决他们的业务痛点。
和业务方对齐目标，控制好业务方需求节奏和需求合理性，是日常工作的第二个重点，所以职场中第二人际关系是和业务部门的关系。
在上述内容中也讲到，产研团队在组织架构中，扮演的角色是为业务需求提供功能支持，是赋能部门。赋能部门的核心是保证项目交付时给到业务方的功能准确、时间无误和质量稳定。
如果说公司是老板的公司，公司内分工明确，齐心协力是老板要关心的事，公司层面**提使命、愿景和价值观，定好战略和人心归一。
那么产研团队整体对外要交付的项目范围、时间和质量保障则和产品的工作息息相关，产研团队内同样需要使命、愿景和价值观，让团队内每个成员知道自己对团队的贡献以及整个团队层面对公司的贡献和即将达到哪去。
产品经理之于产研团队，需要用影响力保持着团队的节奏感，带着开发测试给老板的公司打天下。
首先制定好的项目计划和价值输出需要获得团队内每个项目组成员的认可，让他们觉得所做的每件事都价值重大，充满激情，打满鸡血。其次，在每个项目正式开发过程中，不要胡乱插入临时需求打乱开发测试已有的节奏。最后，不断的滚动同步接下来开发迭代将要做的事，让大家觉得“未来可期”。
通常地向开发测试需求评审，做功能做项目每个产品都**做到，但是不断的向团队内灌输大家共同打造的产品愿景、目标和计划等，却是很多人忽略的。于开发测试而言，懂业务和看中项目价值远远比单纯只做功能和项目价值意义大的多。
其实我在工作中也发现，产品思维和开发思维的差异，产品**更乐于拥抱变化，更能接纳不确定的东西；可是开发更喜欢的是确定的东西，小到需求文档里一个文案，一个跳转链接，大到接下来一个月，半年我们明确要做什么都是希望明明白白给到的，一切不确定的东西到了开发那边他们**觉得心里没底。
我自己觉得这可能是工作内容属性不同导致的，产品面向的用户和市场本身就多变，而开发面对的系统和代码要求是高准确性，不能出半分纰漏。
带领好整个团队以小组的形式向业务方、向领导输出高质量的项目价值是日常工作的第三个重点。
企业虽然依照流程制度运作，但是不要忘记：制定和执行规则的，仍然是感性的人，产品经理常常把洞察用户，研究用户心理挂在嘴上，却容易忽略每天与我们打交道最大的是我们周边各种角色的同事。
企业中的每种角色都有自己的关注重点。当你发现你推动一件事情困难或者某个人对你不认可，可能要想想他背后真正的痛点是什么？当业务每天催促你把一个功能上线，你是否关注到他背后真正的压力是什么？
除了认真做事，职场中合作伙伴背后的真正意愿和想法更重要，这样可以保证你在做正确的事，把你从只有苦劳没有功劳的困局中拉出。
疫情那段期间，有人调侃老板只需要开发和运营即可，企业没有产品也能运转下去。
短期看仅仅针对具体的项目运转可能可以，但是从长远看，这并不是一个健康可持续的状态。毕竟产品的工作重点是对商业模式的探索和产品盈利模式的思考，对企业而言最大的价值是发现市场获利机**，不是每天在办公室里做做功能，跟跟项目。
产品由人加工，有用户，且可以被交易的商品或服务。因此，产品要经过“需求”、“生产”和“销售”三个环节。
产品经理要对产品的市场结果负责，需要对这三个环节分别进行关注，并“协调”公司不同分工下的不同职能，让大家共同完成目标。你说产品经理**失业，不存在的！
花开不败，微信公众号：涵小仙女，人人都是产品经理专栏作家。文艺女青年一枚，白天工作，晚上码字，爱美、爱跑步、爱旅行，愿我手写我心，余生不将就。
本文原创发布于人人都是产品经理。未经许可，禁止转载
题图来自 Unsplash，基于 CC0 协议
