为什么需要PM这个职位？

在地里看到这个关于pm的职能的讨论的帖子 [产品经理PM是不是一份比程序员码农更好的工作?] 特别想分享一些自己在实际工作中的经历和感受。

背景：某大厂码农，厂内文化十分产品/数据导向，pm话语权大。入职该厂后从entry level混到senior，之前一直在to C 产品组

先说结论，就我呆过的几个组，和围观过的几个组，并不能直观感受到pm给eng的工作和项目带来直观的帮助。要说最大的帮助，可能是向上搞marketing，给pm链上的高level的人宣传项目etc。有的项目需要和marketing的人对接，但在lz参与的项目里这种情况不多。在具体落地过程中，反而带来无数的conflict和communication gap, 而且这些情况随着码农级别越高越明显。

在我司，产品组的高级别码农做的事情其实和pm有很大的overlap。eng自己就可以搞定跨组开会，数据分析，road mapping, 和designer沟通，项目进度跟进等等。产品组有很多eng在做这样的事，或者在往这个方向grow。而且eng有更大的优势是因为是干活的人，对系统的low hanging fruit和可能踩的坑更了解而提出更有价值的input。当你往这条路走的过程中，无可避免地要碰到pm这个微妙的角色。项目需要stakeholder，但这个人必须有pm的title吗？这种感觉就像，因为这个人挂着pm的title所以就统领项目，而不是因为这个人有能力，有context。

见过无数被pm搅和得鸡飞蛋打的项目，比如不顾实际情况定下不可能达到的goal，为了强推自己的想法而无视惨淡的实验数据，产品的tech debt规模达到需要重构的时候依然强推快速开发。见过最好的pm是没有存在感的pm，体验最差的pm是把自己当ceo把程序员当工具人的pm。另一方面，也有无数被强EM+强eng盘活的项目，摸鱼的pm跟着一起鸡犬升天。

然而既然pm这个角色不可避免地存在，每次只能绞尽脑汁在对抗中合作。我和我司一些高级别的ic和manager也聊过类似的话题，这种困扰不是我独有。以上仅针对to C的产品pm

从designer角度来答一下这个题，我在三个start up工作过，直接合作个十多个PM。
1. PM role 是不是必须的？不是，上面好多都说了如果Eng和design有足够的product的能力理论上是不需要pm的，很多公司早期都没有PM。我现在做的一个产品也是没有pm，全靠design和Eng一起讨论做什么feature，自己plan自己的活。话语权是真有了，但是实话确实也是真累。
2. 为什么公司需要招PM？有product sense的Eng和design毕竟是少数，创业初期可以找到这样的人，公司大了之后完全没法保证这个质量。另外对于公司来说，高度专业化的职位是对公司的利益肯定是最大的，把plan和沟通的工作交给PM，让画图的专心画图，写代码的专心写代码。
3. 为什么PM总把项目搅合的鸡飞蛋打？ 因为好的PM真的是太少了！这个行业入门面试基本全靠一张嘴（并不是说会吹就容易），但是能吹真的让人很难evluate其他的能力。 而且真的是不知道哪里来的这种有毒的说法“PM是一个项目的CEO” ，有这种mindset的pm真的能躲多远躲多远，有毒。
4. 每个公司也都见过好的PM，个人觉得PM最重要的一个素质就是orgaized，觉得对项目有正面影响的PM大多数都是非常organize，不管是doc，开会，planning都弄的调理清楚，需要做的decision，需要调节的dependency都一清二楚，项目推进就很快。
. From 1point 3acres bbs5. 能咋办呢？我在过的公司的design team的做法就一直要求designer去interview panel，虽然行业上来讲这个职位是不可避免的存在，但是还是要想把法不要把有毒的pm招进来和自己合作。

我觉得默认pm做所有决定领导sde本来就是错的，很多project是pod lead制，可以是高级别engineer/em去做可以是pm去做也可以是mkt/strategy head之类的，pm去organize的事情可以是辅助engineer去安排会议排spring催data拿approval解决engineer觉得麻烦的事情，也可以是兼职pod lead带领project的road map. 如果一个engineer lead一个项目没有pm帮忙，那只能默认这个engineer把pm不那么fancy的那些杂货都得自己扛，理论上不会有太多时间关注技术，代码和细节了，保证开会从早开到晚天天ppt，连搞个data sharing approval都得找他填form开会之类的浪费时间。如果是team里的engineer情商不高/英语不好/沟通不行，那也只能是pm来当pod lead了，如果engineer自己也乐意兼顾pm的工作，也是可以招一个pm到自己pod里分担project management的一些杂活自己lead 最重要的strategical items，这样的情况对engineer来说是最理想的，否则会比较容易stuck在一堆meeting里没时间发挥自己最大的优势，那显然易见不管是谁lead project pm role还是很有必要的。

PM还是有其必要的把，只能说好的靠谱的PM凤毛麟角。PM对于一个团队的帮助是从customer的角度来审视产品做的逻辑。如果这个PM做过engineer那可能他提的feature就会是非常有用的。工程师自己plan最大的问题就是over engineering（工程师天天修bug，优化系统升职快还是干大feature，设计新系统升职快），明明不需要搞得那么复杂的东西，做工程的人就会跟你说要设置一大堆参数，考虑这个Corner case，有时候短期内撑死了就几百几千个人用，非要设计成几百万用的，结果就是产品做出来非常复杂难用，且不稳定。遇到太多senior engineer就特别愿意对着一个Corner case然后去设计一个复杂的UI去解决他。

面向用户的内容还是需要 PM 的，虽然有很多 eng 的产品嗅觉也还不错，但是有的产品上，开发者自己跟目标用户差异巨大，就比较难通过直觉真正理解用户痛点。
而且 Eng 毕竟不是100%的时间都花费在理解用户，理解product market fit 和 协调不同功能的人上面，也很少有 eng 愿意花大量时间搞这些。与其用写代码和设计时间去做协调，很多 eng 还是更偏好做自己喜好的事情。

至于 PM 做计划，如果只需要计划 eng team的roadmap 那的确没啥必要。但是如果有需要跟数据组，marketing, sales, PMM, ops， finance 等协作的情况，那就有value add，这种情况下认为是产品的 mini CEO也非常合理。毕竟产品成败也不完全由代码的能做什么和可靠性来决定的。尤其在早期，product market fit 是一件需要有人一直专心去考虑的事情。

Eng 自身的优势和局限都是非常看重技术，如果不去刻意留意，则很容易出现over engineer的情况，像楼上说的，明明只需要几百几千，却非要设计一个支持千万上亿的分布式系统；明明内部 dash 偶尔才有人看看，但是非要坚持几个 9；明明修修补补还可以再用三年，却非要用最新出来的blingbling的技术；总体别留坑是好事，但是让产品中留多少tech debt，也要看产品发展来决定，越接近 MVP 的东西越乱，throw away的东西越多，太过坚持代码质量，对推动产品也未必有帮助。

沟通效率：eng 对eng 沟通效率还是不错的，但是eng对其他function和executive的沟通经常显得特别细枝末节，抓不住重点。当然很多人很注重这一点，也可以做到communicate at the right abstraction level，但是毕竟大部分时间花费在解决问题上面，只有投入更多精力去刻意思考才能抽身出来，所以 EM/PM有时候也起到一个沟通interface的作用。

带宽问题：就算eng 觉得 PM 做的事情自己也都能做，但是有没有时间精力和兴趣去做，也要考虑。会做的事情未必都要亲力亲为，如果手头有回报更大的事情，那delegate相对回报更小的事情给别人，也是增加自己impact and scope的必经之路。比如 manage up，比如深挖技术，学点新东西，甚至逃避烦人的会议等，是对很多 eng 都有value add的活动。

但是 backend infra 之类与其说要 PM 还不如要 TPM，最好是做过 eng的 TPM（不是指拿了 degree 就直接做pm/tpm的人，是指真的亲自做过eng的人）。遇到不懂技术的 PM 完完全全是浪费生命，只能增加负价值。这个方向有vision的 EM/TL 加 TPM 组合，技术眼界 + 高质量设计 + 快速执行 就很无敌，顶多需要designer给设计少量界面。PM 如果要添加价值，可能就在宣传上。尤其是有朝一日从公司独立出去做 2B 产品的时候，有人能做marketing + PR 还是必不可少的。

randytaninpty 发表于 2021-6-9 04:06
显然是啊。。。你以为老板们傻嘛。花那么麽多钱弄个副作用的人，多雇一个sde不好吗。咱们都是搞it的。说白 ...

实际上公司就是存在着大量冗余，挂着同样title的人在不同org不同文化里扮演的角色也不一样，一个team再厉害从几个人scale到几十个人的过程里会面临很多优化operation的挑战，取决于你看问题的角度是为结果找理由，还是how we can do better

我觉得问题不在于PM不应该存在，而是大部分PM自己也没有product sense，就光靠刷存在感和抢credit。
为啥这些PM还存在？一堆念MBA的自己立个壁垒保护自己利益呗。。

个人体会，作为一个SWE，又做plan又做coding是很花时间精力的。要么wlb很差，要么高级别更侧重于plan，要么低级别更侧重于coding。PM需要帮助中低级别的SWE节省plan上的时间精力。

其实不需要，只要码农project sense足够好就完全不用，而且会让效率提高很多。可是这种码农有点贵，很多公司舍不得，只能分开招懂coding和懂project 进度控制还有些基本的business sense的人。效果当然差于一个人啥都懂，因为会有很多沟通成本，但是价格也便宜很多

“见过最好的pm是没有存在感的pm，体验最差的pm是把自己当ceo把程序员当工具人的pm。另一方面，也有无数被强EM+强eng盘活的项目，摸鱼的pm跟着一起鸡犬升天。”

总结的太好了... 真的非常看组..... 还有大老板 和 SDM 是不是知道  SDE 的苦处。还有，我觉得最大的问题是 PM 的KPI 跟 SDE 不一样，那么 tech debt 和 build feature meet growth number 有冲突的时候，是真正给 SDE 们去 fix tech debt的时间， 然后 clean and simplify 一些 process , 还是让 SDE 做完一个 feature 后，气也不给喘，直接做下一个 feature， 直到年底假期快到了，本来大家应该歇会儿划水的时候，这下好了，让大家来做 tech debt 和 operational excellence 的东西.... (这个其实也是 SDM 不作为的锅，对同级唯唯诺诺，对手下重拳出击)
当然，这里其实还有一个可以脱离被 PM 指手画脚的方法，就是去一个偏 backend infra service 组，这样不是直接 To C， 就会好很多。

(亲身经历，说多了都是泪，求米求米)

robincan 发表于 2021-6-8 12:31
我觉得问题不在于PM不应该存在，而是大部分PM自己也没有product sense，就光靠刷存在感和抢credit。
为啥 ...

感觉是这样的，很多真的是没有 product sense， 而是 business school 的pull information 那一套非常 managerial 的沟通技巧，各种 open ending question 问一遍， 然后 meetings after meetings with customer teams. 然后整理好笔记了，又跟 Engineer meeting after meeting 来 brainstorm.... 我也不知道 brainstorm 是为了做个样子让 SDE 有参与感还是咋样，product idea 要跟 SDE 开会来想，那还要 PM 干啥.... (好的 PM 应该是整理好信息之后，提出自己的 product idea 的，然后跟 SDE 和 SDM 一起决定 prioritization 而不是在那边pull 啊 pull 的)

不能赞同更多，我也是一直不明白PM存在的价值。我们组做to B的，我和楼主有同样的疑惑。领导一个项目的进度方向，不应该是交给最懂技术的人来做吗？PM怎么能正确的估算出多少时间到哪里？

路过看看看看看看

匿名者 发表于 2021-6-8 12:20
个人体会，作为一个SWE，又做plan又做coding是很花时间精力的。要么wlb很差，要么高级别更侧重于plan，要么 ...

这个我不太认同，做planing其实是机会，增加visibility和锻炼综合能力，包括向upper management 做presentation。入门码农plan小feature 多做execution, 经验多的码农plan大feature多mentor junior，不明白为什么要横插一个叫pm的角色抢credit。这本来就应该是swe的工作内容之一，现在因为多了个叫pm的role所以被硬生生拆开，再加上刻板印象搞的码农就没有product sense只会埋头写码似的，被pm当coding monkey使唤