HiSEN

如何做一个让人讨厌的产品经理 - 《人人都是产品经理 2.0》读后感

零、背景

本文灵感来自《人人都是产品经理 2.0》
位置:7.4.2 如何做一个让 Ta 们讨厌的人

作为一个研发,工作过程中如果能及时发现如下场景,
及时给对方负反馈,否则受伤的是整个团队。
看了这本书之后,感觉对产品有新的认知,
知道他们在做什么,怎么做,后续可以更好的与他们沟通。
而且里面的内容对于研发来讲也是适用的。

一、开始实施之前

1.1 不说清需求价值

技术问”为什么要做”时:
1、时支支吾吾
2、这是老板(XXX)要的,假装自己是个传话筒
3、我接的是二手需求,什么都不知道
随说:其实正确的做法是追溯这个需求的初衷,有利于评估 ROI (投入产出比),以及排优先级,以及增进对业务的理解。

1.2 不去想细节功能

技术问细节(业务细节,非技术细节)时:
1、装作自己完全没有想过
2、那就这样做
3、肯能那样做也可以
4、要不你来定吧
随说:这些表现其实都是不负责的!没有明确的需要,后期容易扯皮,也可能做出来的东西有问题。

1.3 帮技术评估工作量

1、这不是很简单嘛,就改个 XXX,几行代码就搞定
2、这些我都评估过了,都能做
3、不要偷懒,不要忽悠我,我抖动
随说:评估真是个高难度的活,往往只见树木不见森林

1.4 逼着技术团队承诺

1、任何时候只知道公事公办,技术承诺了却做不到,自己就没有责任了。
随说:互联网企业更多的只是一个”预测”,而非”承诺”,因为变化太快,承诺是技术对产品的责任,而预测是产研一起担责。

二、实施过程中

2.1 做了一半改需求

1、经常在某个迭代周期内做”非受迫的需求变更”,这招杀伤力很大,技术同学一般受不了。
随说:非受迫,意味着是产品没有想清楚,然后导致研发无谓劳动。万万不可取。

2.2 开发过程中消失

1、可以想各种办法隔绝与研发的联系。
随说:一般都需要多次沟通,反复确认细节。

2.3 过度关注细节

1、帮技术确定各种技术方案,这个应该这样实现…
随说:这种一般少见,研发转岗产品的多一些

三、产品发布之后

3.1 没有发布后的反馈

1、发布之后,犹如石沉大海,不告诉大家任何结果,甚至庆功宴都不叫 Ta 们,紧接着继续安排他们干活。
随说:技术人员也需要从市场、用户那里获得反馈,从而对自己做的事情产生价值感和成就感。

3.2 任务无节奏感

1、让研发一阵忙一阵闲,发布之后再开始研究接下来做什么。
2、一会儿让研发有着天天通宵的高强度,给 deadline,下死命令,做完之后不知道做什么。
随说:保持合理的安排,让研发有个合理的预期比较好。而不是等你们上了大学就自由了这种…

四、全程适用

4.1 优柔挂断

1、你定吧,你说往哪儿走我们照办
2、啊…那个…方案各有利弊,我也不知道怎么办,你们有什么好想法
随说:自己左手和右手互搏,思考清楚之后给大家一个明确的结果。

4.2 报喜不报忧

1、藏着噎着一些坏消息,eg:老板正考虑干掉这个项目等,大家只能通过小道消息得知
随说:这样很破坏信任感

4.3 不把 Ta 们当人看

1、只关注结果,不关注人的成长,永远把合作伙伴当”资源”
随说:结果导向没有问题,但是没有成长,留不住人。