【2023】拜个早年,产品经理要不要懂技术

这是一个古老的问题,但确实一直有人问。

 

答案很简单,产品经理是个综合的岗位,所以,不能仅仅看是否懂技术,就判断“能不能做”,但,懂技术肯定是个优势,只要不滥用的话。

产品经理要不要懂技术
产品经理要不要懂技术

 

具体点说:

 

不要求你会Coding,但至少可以和技术人员无障碍对话。

最好的情形,是技术可以直接用平时和同伴说话的方式和你交流,而不用刻意翻译,当然,和越强的技术配合,你就会越轻松,他们也会为你考虑,尽量用通用一点的语言。

或者,你的沟通能力、理解能力特别强,也可以弥补一点Gap。

如果,对话过程中,你经常听不懂,技术解释了互相还是不明白……那是很伤的,失去了信任,基本就要没法做朋友了。

 

举几个实例:

至少知道iOS的开发分客户端、服务端吧,一个改动,可以判断出是哪边的事情,不要找错人。

能想得到一些静态文案,做成配置文件,可以方便的改,这种需求,对于技术一窍不通的人可能会想不到,之后就会不断抱怨为啥改一句话也那么麻烦。

比较好的,有时候逻辑讲不清楚,可以直接看关键代码,各种语言的语法其实都类似,稍微写过某种,基本看得懂。

比较简单的XML文件要会改吧,比如帮助页面,把文案给技术,技术再改,太麻烦了。

能给出建议某些东西可能经常要改动,所以最好放在服务端,某些功能最好做成H5页面。很多业务需求和技术方案会互相影响的。

……

就算你看不懂上面我在说什么,也不用担心,确实见过很多文科出身的人,被熏陶几个月以后,也上手了,但这几个月,自己和整个团队确实都比较痛苦,有不少效率损耗。所以,在应聘时候的劣势……得有更多的加分项来填补。

 

当然,这也和产品形态有关,比如做Baidu搜索核心的产品经理,估计非特定方向的技术出身,是很难补上来了,又如你要做一个导购类的App,貌似就容易些(有误伤不要打我)。所以,你要补哪方面的“技术常识”,最好能先明确将来你要做什么产品,可能碰到哪些。

 

最后加一句,如果很懂,请勿滥用。

一是对自己,应该把更多的时间精力用在思考产品层面的事情;二是对技术,不应该剥夺大家的“责任感”与“参与感”。

 

快过年了,估计下次正儿八经的文章要年后了,提前给大家拜个早年啦~~~

iamsujie的公众号二维码
iamsujie的公众号二维码

【2021】技术人员的Secret Toolbox

之前我们谈到过能让产品经理在技术人员,包括工程师/设计师眼中迅速变Low的事情,其中有一点是“逼着技术团队承诺”,有同学不理解,问:

 

技术负责人对开发时间进行评估,并且给出排期承诺,是必须的吧?

答:我更倾向于认为承诺是传统瀑布模型下的模式,开发明确的任务、技术也成熟,可以提前计算好,但互联网的敏捷模式下,很多时候会做着做着发现坑、做着做着需求有不得已的变化,所以应该技术和产品一起做【预测】,心里想着目标,一起面对变化。最核心的区别,承诺是技术对产品的责任,预测是两边一起承担责任。

 

当然,这里面有个前提,就是技术同学要很靠谱。

 

而更可怕的一点,还没说,那就是容易逼出一系列可怕的大招——

技术人员的Secret Toolbox

技术人员的Secret Toolbox
技术人员的Secret Toolbox

Copy&Paste,不假思索的“复用”,满足当前需求就好,不考虑逻辑的可扩展,比如A和B现在1对1,不考虑将来有可能1对N,即使是业务上已经做出提示的时候;

Hardcode,写死代码,不用配置文件、变量,当你发现某个参数不妥,想要多改几次试试的时候,发现工作量超乎想象,而且怎么都改不干净;

Less Testing,听来一个很搞笑的故事,某位技术同学写完代码做单元测试,第一次没过,百思不得其解,于是再跑一次看看,结果过了,再跑,又过了,于是,就认为第一次是幻觉;

Skip Error Handling,不考虑异常情况,假设用户都是正常使用(当然,在某些情况下,业务方认可的时候确实可以这样做),举个最简单的例子,输入框没有做安全上限的长度控制,用户可以直接把程序搞挂;

Descope,偷摸减需求,不举例了,真的会有,验收的时候产品经理负责,发现了还好,但有时候只验收主要场景是发现不了的;

Less Review,减少设计评审、代码Review等,我们认为强技术可以少评审,但会动用secret toolbox的同学往往并不是很厉害的人物;

No Autotest,无测试自动化,工欲善其事必先利其器,磨刀不误砍柴工,一直不磨刀,整体效率就一直上不去;

……

还有啥招,技术同学不妨自爆……

 

这样做,本次交付的时候,会看着很美,需求都满足了,这时候产品经理还会暗爽——就是要逼吧,你看,逼一逼都做出来了,下次继续……

但往后,做着做着,你会发现整个技术团队越来越不愿意承诺了,承诺的越来越难达到了,经常延期?效率好像越来越低?出活越来越少?那就是因为填坑的时间占比越来越大了。

 

最终有一天,技术Leader面露难色的找到你,说:

“兄弟,业务发展太快了,技术架构跟不上,要重构了”

“啊,要多久”

“两个月,一半的兄弟都要参与”

“不可能,因为……”

“必须重构了,不然说不准什么时候就挂了”

……

熟悉吧,over。

iamsujie 微信公众号二维码
iamsujie 微信公众号二维码

【2020】产品经理对技术做这些,就完蛋了

今天说些能让产品经理在技术人员,包括工程师/设计师眼中迅速变Low的事情:

 

开始实施之前

【说不清需求价值】,技术问“为什么要做”的时候,支支吾吾,或者说“老板要的、运营要的”,成为了传话筒,是最Low的,相反,能有理有据的顶老板的产品经理,通常会在大家的眼中逼格满满;

【没想到功能细节】,表现为技术问细节(当然,是涉及业务的细节,不是技术实现细节)的时候,自己还没想过,现场想,被发现了,或者因为是接二手需求,并不知道、也没有去追溯这个需求的初衷;

【帮技术评估工作量】,特别是技术出身的产品经理容易犯这个错,潜台词就是“希望加活”,我评估过了,这些都能做掉的,不要给我偷懒;

【逼着技术团队承诺】,产品经理想的是,如果技术承诺了,但却做不到,这样自己就没责任了,但很多事情,在开始的时候是谁也不知道的,应该大家在一条船上同舟共济,这就是“接力跑”和“踢足球”在交棒/传球之后的区别;

面壁思过吧
面壁思过吧

实施过程中

【做了一半改需求】,scrum里的表现就是sprint内的非受迫需求变更,大家很难忍受的是产品经理自己没想清楚,而导致的劳动浪费,俗话说“没有变更就没有伤害”,碰到性子烈的就直接要干架了,当然,如果是外部市场变了,大家都可以理解;

【开发过程中消失】,你可以出差、可以开会,但是要能及时响应技术的问题,要不然,为了进度大家照着自己的想法做下去,验收的时候产品经理跑出来说“这不是我要的”,可不要怪没人理你;

【过度关注实现细节】,帮技术决定技术方案,也是技术出身的产品经理容易犯的错,越俎代庖了,会降低技术同学的积极性,渐渐的就完全打工心态了;

 

产品发布之后

【发布后没有反馈】,技术人员也需要从市场、用户那里获得反馈,从而知道自己做的事情产生了价值,提升成就感,做完发布,石沉大海,大家是不可能有owner感的;

【无节奏感】,让技术人员忙一阵闲一阵,发布之后再忙着研究接下来做什么,让技术人员在干死干活的高强度之后突然不知道做什么,几天后又开始要赶进度;

 

全过程都有

【优柔寡断无决断】,是产品经理最要不得的品质,就是在已经讨论完毕后,大家都等着你拍板的时候“你说吧,往哪儿走我们就跟着办”,这时候你说“啊,那个,各种方案各有利弊啊,我也不知道怎么办啊,你们有什么好想法……”,你就完蛋了;

【报喜不报忧】,产品经理总想藏着掖着一些信息,比如“老板在考虑干掉这个项目”这类信息,出发点可能是好的,但,当大家通过其他途径知道了以后,互信就完全打破了,大家会觉得“你还是把我们当资源”;

 

还有啥,欢迎补充。

PS:12月6日周六,杭州的公益公开课报名已经结束,不能到现场的太多,所以会录视频,不过现场网络还没铺好没法直播,能解决这个问题的朋友可以联系我的公众号,谢谢。

iamsujie 微信公众号二维码
iamsujie 微信公众号二维码