一名“佛系”产品经理的成长之路

从零开始学运营,10年经验运营总监亲授,2天线下集训+1年在线学习,做个有竞争力的运营人。了解详情

产品经理既要对产品负责,还要对用户负责,因此工作中会和各岗位沟通协调,相爱相杀。那么产品经理与各岗位之间的工作界限如何划分呢?

众所周知,互联网行业的产品经理每天需要与形形色色、不同岗位的人沟通,上至老板,下至测试、客服等。

产品经理的日常事务性工作有一大半都花在了与不同岗位的沟通协调上,自然在工作中也会和各岗位产生诸多交集。都说产品经理是CEO的学前班,所以就该你这么忙。

那么在团队协作中,产品经理与各岗位之间的工作界限是如何划分的?对于很多“佛系”的产品经理可就是个难题。

下面我们就来聊一聊“佛系”产品经理在日常工作中是怎样处理的。

一、与运营的爱恨交织

行业中,很多人都会认为运营与产品是不分家的:他们需要共同为产品的绩效考核指标负责,为用户体验负责,所以这两个岗位的工作界限真的是说不清,理还乱。

记得某一年的4月份,运营总监找到我,说老板需要一份关于产品的年度规划方案。对于这份方案,老板只有一个要求:希望今年的新增用户达到1000万,要求在一周内完成方案。

听完后,我的直觉是这应该是一份关于运营的年度规划,哪里是产品设计、产品研发的规划方案。我试图向他解释说明:这是一个运营工作中关于拉新的方案,不是产品的规划方案,也不应该由产品经理来编写这份方案。

唠叨了半天,我的解释说明是无效的,最终还是被运营总监怼回去了。他认为这个目标的完成,和产品设计、研发关系紧密,需要我们产品研发部先给出一份年度规划方案。然后还和我说了一堆产品经理也需要对考核指标负责,接着还向我说明了他的思考方向与思路。

就这样,一脸无奈的接了这么个重要任务。方案中,将1000万的目标拆解到每个月,从运营的手段,产品的改版、优化,营销策略等几个维度来规划具体工作。后来这位总监还找到我,帮忙完成了多个营销活动方案的策划,甚至活动效果的总结。

说实在的,也感谢他给我安排的这些任务,提升了自己的全局性思维,提升了自己看问题的高度与深度。

二、与设计师的千丝万缕

日常工作中,产品经理与UI设计师、视觉设计师之间的沟通合作也很频繁,大家都同属设计这一宽泛领域。只不过产品经理强调的是逻辑设计、结构设计,而他们更多关注的是视觉效果层面。

视觉设计师通常是在收到产品经理的原型设计后,才开始处理视觉显示的问题。很多视觉设计师都是直接按照原型的布局、结构、甚至颜色来设计界面,在他们看来只需要做好给页面配色,仅仅处理好这个层面的视觉显示问题就算完成了工作。

如果做完后,发现还需要调整按钮或文字的位置,修改字体的大小或字体,他们会认为这是产品经理的原型设计有误,没有明确表达出这一效果。在与这类设计师工作配合中,我们只能尽量严格要求自己,提高原型的保真度,按钮的位置、颜色、字体的选择、字体的大小,还有一些阴影、透明度效果尽量表现出来。

有一次在做高保时,需要从网上抠取一张图片,当时想找一位设计师帮忙,那位设计师貌似有些不耐烦的说道:抠图这么简单的事情都不会啊,哪个产品经理不会使用PS。

所以,只能自己琢磨如何抠图,当即从百度搜索了一些抠图的技巧,业余时间还将框选、套索、魔镜、钢笔等所有的抠图方法系统性的学习了一遍,从此抠图不求人。

三、与程序员的不打不相识

产品经理与程序员打交道的机会就更多了,他们之间的故事不胜枚举,在很多公司这两个岗位似乎总是对立的,产品经理与程序员的撕逼大战每天都有人在上演着。不是程序员在抱怨产品经理不懂技术、更改需求,就是产品经理在抱怨程序员的研发能力不足、拖延需求等。

对于很多没有技术背景的产品经理来说,在与程序员沟通的时候会显得格外困难。

当你在和他们描述业务需求的时,他们的评估反馈通常是这样的:这里需要一个什么样的接口来实现,这些内容存储在客户端本地会比接口调用效率更高;数据库应该怎么样设计,包含哪些表,表里包含哪些字段。

他们不停的向你反馈这些内容,以表示他们对业务需求的理解,希望得到你的确认。

相信很多产品经理,在听到程序员的这些话,是处于一脸茫然的状态。如果你不能明白他们这些话,随意进行确认,而事后等到测试阶段又发现了问题,这个时候在去找程序员去提BUG的时候,程序员通常会觉得这个产品经理不靠谱——又是在随意更改需求?同时也会引发很多争吵的声音。

既然程序员不能在沟通中转变他们的思维,那么身为产品经理怎么办?我们只能自己去学习了解接口能够实现的功能、了解接口规范、了解数据库设计的一些基础理论。懂得去分析:哪些功能或者内容需要依赖于接口的开发传递,哪些功能或者数据更适合客户端的本地开发,了解在前后端接口联调过程中有哪些注意事项。

记得曾经有一位技术总监要求我监控程序员的开发进度,他让我建立了这样一个表格,罗列出项目中包含的页面、每个页面包含的接口、接口的名称、接口的说明、接口的完成情况、接口开发的实际工作量。在技术评审会上,他们要求我一起参与确定关于接口的名称、定义、说明,确认数据库结构、数据表的字段设计。

起初,在制定、维护这样的项目进度监控表时,遇到了很多困难,心里也有过很多抱怨。因为按照这样的要求来监控项目进度,必然需要产品经理对开发常用的技术原理非常熟悉,这样的进度表似乎有点超出了产品经理的监控范畴。虽然对于这样的项目进度监控,还是头一次,完全从技术开发的角度来监控项目进度,但确实也让我学到了很多,对技术原理的认识更加深刻了。

四、与测试工程师的唇亡齿寒

大家都说产品经理需要对产品的结果负责,所以上线前的需求确认自然成为了产品经理的份内工作。在上线前,有些产品经理都会仔细确认产品的文案,确认产品的核心功能是否完善,操作流程是否顺畅,业务流程是否正确。很多时候,其实是产品经理和测试工程师一同对产品质量负责,甚至在上线后出现重大问题,产品经理可能是第一责任人。

我们团队的测试工程师都没有编写测试用例的习惯,他们总是说很忙,认为有了详细的需求用例,没有必要在编写测试用例文档。所以在阅读需求文档时,常常会要求我们将需求用例写的足够详细,包含哪些操作步骤,期望输出结果,限制条件等。

为了满足开发、测试他们的要求,希望从他们的思维角度能够准确理解业务需求,编写PRD时,再一次妥协了。在需求文档中,当你将需求用例描述的尽可能详细时,意味着你对用户操作流程的理解也会更加深刻,对很多细节的把控也会更加到位。

我们的测试工程师还有一个习惯:在测试过程中,如果遇到不清楚的需求或者不能推动开发解决BUG时,通常会在禅道系统中将问题提交给产品经理。

每次产品进行大版本的改动时,都能收到来自测试提交的几十个BUG。他们不愿意做推动问题解决的第一人,这个重担还是落在了我的身上。有时候一个BUG问题可能会牵涉到好几个开发之间的配合,所以我想这也是测试工程师将一些BUG指派给我的原因,麻烦事都落在我的身上。

但从另一个角度来说,我也感谢他们:正是因为这样的一些经历,使得我在开发项目中遇到问题时,能够较快的定位问题出在哪里,并给出一些建设性的解决方案,开发同学们也更愿意与我合作了,对我也多了一份信任。面对项目实施中遇到的问题,也能更从容应对。

五、最后的总结与期望

“佛系”产品经理的工作似乎没有边界,在沟通过程中不够强势,工作也比较辛苦,劳心劳力。身为一个产品新人,自己还不够强大时,很多“佛系”产品经理的一些习惯能够促使自己变得更加强大,能够获得快速提升自己综合能力的机会。

平时工作当中谦虚点、低调点、温柔点,从某种角度上来说,吃亏也是一种福分。“佛系”产品经理能够锻炼自己的意志,不断提升自己的综合实力,使得自己成为团队当中不可替代的一类人。

佛系产品经理是团队当中的多面手,哪里需要就去哪里,遇到问题不闪躲,快速解决问题,是团队当中的救火队长。“佛系”的做法,只是我们在职场当中打怪升级的一些方法,但并不等同于工作中没有立场,没有原则。

希望各位产品人,能够利用自己“佛性”的一面,提升自己的综合能力,在工作中,绽放你的光芒。

 

本文由 @kevin 原创发布于人人都是产品经理。未经许可,禁止转载

题图来自 unsplash,基于 CC0 协议

赞赏是对原创者的最大认可
6人打赏
评论
欢迎留言交流
  1. 产品经理不需要懂技术

    回复
  2. 大哥的pm心路好坎坷

    回复
  3. “感谢他给我安排的这些任务,提升了自己的全局性思维,提升了自己看问题的高度与深度”
    “业余时间……从此抠图不求人”
    “也感谢他们:正是因为这样的一些经历,使得我在开发项目中遇到问题时,能够较快的定位问题出在哪里,并给出一些建设性的解决方案……”

    不管是否合理,都能看作一次任务/挑战,并且从中得有收获,而且还能怀有一颗感恩之心。 :oops: 佩服,学习

    回复
  4. 我觉得文中运营总监说的没错吧,本来这事双方都有责任

    回复
    1. 但是不应该甩手直接扔给产品吧,以运营为主,产品辅助配合。

      回复
  5. 所有岗位都是权责分明,就剩产品岗位,模糊不清,在很多公司说白了就是个背锅侠

    回复
  6. 感觉这样的产品好累啊。怎么把所有的活都拦的差不多了。特别设计的。抠图那时产品的事。要他设计干吗。还有阴影和透明度。要他设计干吗。我觉得佛系有点累

    回复
  7. 佛系少女。冯提莫

    回复
  8. 很佛系,厉害了,我就脾气不好,直接开怼,一直想改来着~

    回复
  9. 本人比较赞成在理解产品经理职能的基础上去做些个人能力提升的工作。比如对于技术理论知识的了解、相关输出内容质量及个人全局性思维的提升,这些本就是一个产品人进阶途中必须要做的。对于那些无理由或伪理由而增加的工作内容,个人认为不应妥协,这无疑是告诉他人自己的专业能力的不足……

    回复
  10. 对全文感同身受,但是只同意最后一句话“佛系产品经理。。。哪里需要就去哪里…不等同于工作中没有立场,没有原则。”
    完善自己是必要的,但是逆来顺受的结果就是把自己累死还不讨好~比如本文就没有提到主人公是否有被认可

    回复
    1. 经常努力很多,而且费力不讨好

      回复
  11. 这是一篇好的个人总结,但是凡事都是蜻蜓点了下水,只是在描述一件事情,还只是表象。。

    回复
  12. 道系 请多多指教

    回复
    1. 多交流,共同进步

      回复
  13. 这得是把运营,开发,测试的工资都挣了才能这么干呢吧,自己分内的工作还有时间做吗?

    回复
    1. 更多的是游走于各岗位的沟通吧,总有些人不愿意主动沟通,都把沟通的工作推给产品,都需要产品帮他们牵头联系,然后就陷进去了。

      回复
    2. 我觉得我也很佛系,这样就会导致,这人不明确…你有没有遇到过相关问题?应该怎么处理呢?感觉自己老是背一些莫名其妙的锅…

      回复
    3. 佛系并不等于没有自己的主见和立场哦,有些时候自己可以帮别人多担当一点,但要对方领情,认识到这点。不同公司对产品经理的定位也会不一样,有些公司不光是产品规划设计,还要更多很多项目管理类的工作。管理类的工作承担过头了,容易得罪同事,自己也感觉很累。

      回复
    4. 🤒Tmd管他领不领情😟顺产品者生逆者拖出去重打50大板🙁

      回复
    5. 哈哈,不能这么偏激啊,产品经理对人员是没有实际管理权利的,这样做工作更难开展。

      回复
    6. 可以牵头联系,不要把活儿都揽到自己这,项目分工不明确进度能把控好吗?让他们对你产生依赖性,你这卡住了所有人都在等你,其实好多工作明明不是产品负责的到最后项目延期,产品就是第一责任人。这样会恶性循环下去吧。

      回复
  14. 去他妈的佛系,给老板讲清楚工作职责,大不了谁也不做,拜拜了

    回复
  15. 我也属于“佛系”PM,但是这样的工作真心太累,往往忙于各个部门的沟通,而真正疏忽了产品的本身

    回复
    1. 白天的时间几乎忙于开会与沟通协调,要下班了才能有时间设计产品

      回复
    2. 对于下班准时回家的我,从“佛系”慢慢转变成“魔系”了

      回复
    3. 哈哈

      回复
    4. 真是这样

      回复
  16. nice

    回复