这是一个创建于 975 天前的主题，其中的信息可能已经有所发展或是发生改变。
6 年前端，现在有一个契机转 toB 产品岗位，对产品业务逻辑有自信，对产品工作方式和沟通交流的能力不是很确信。
目前考虑可能的几点挑战：
1. 角色的转变，要从之前研发的角度对需求进行批判，转变到从产品的角度从 0 开始构建需求
2. 工作方式的变化，重文档，重交流
3. 避免带入技术思维
希望各位不吝赐教。
目前考虑可能的几点挑战：
1. 角色的转变，要从之前研发的角度对需求进行批判，转变到从产品的角度从 0 开始构建需求
2. 工作方式的变化，重文档，重交流
3. 避免带入技术思维
希望各位不吝赐教。
 |
1
freeup 2022-04-18 14:33:10 +08:00
楼主之前怼过产品么 对产品有意见么？ 换位思考下 就知道该注意什么了
|
 |
2
fe619742721 OP @freeup 有过，我现在带一个小团队，需求评审的时候我是怼人主力军。。
|
 |
3
ddoyou 2022-04-18 16:12:44 +08:00
现在带小团队，沟通能力问题应该不大，产品更多的是要：思考为客户解决需求的方式。
把解决方式搞明白后转发给开发团队 |
|
4
fe619742721 OP @ddoyou 感谢建议，现在就是对客户沟通这块有点儿虚，目前有几个大客户定制需求需要跟进
|
 |
5
LaGeNanRen 2022-04-19 09:08:27 +08:00
建议就是：不要试图用技术能力解决业务问题、以及商务们酒桌上应该谈好的问题：）
|
 |
6
sutaking 2022-04-19 13:52:57 +08:00
好的产品要能聚焦需求，把研发的力量投入到最有效的地方，一般的产品就是什么都要做，还自信于自己抠细节的能力
研发的角度 |
 |
7
frozenshadow 2022-04-20 14:00:39 +08:00 via Android
技术转产品的好处是有需求的时候能想到大致的解决方案和 ROI ，但做产品之后要注意身份转换，不要被过去的经验束缚。ToB 的产品最大的难点在于理解用户背后真正的需求。还有就是要注意：ToB 生意里面，用户和客户不是同一个概念
|
 |
8
madlifer 2022-04-20 14:27:06 +08:00
我是比较反对技术转产品的那部分人，我认为技术做的越久，思维越不容易打开，单纯做个合格的 PM 是问题不大的，但是思考方式的局限性可能会导致成长性不高，做不了开疆扩土的那种产品。
我相信你都 6 年经验了，换岗肯定有自己的考虑，多半是为成长性方面的考虑，比如带产品带好了，转成产品总监。所以我觉得还是得看你自己怎么想的，有没有抛弃“模式经验”的决定。 #5 说的挺好的，不要用技术能力解决业务问题。 很多开发喜欢钻牛角尖，定了个需求就死磕技术方案，但作为产品侧来说，只要版本目标能够达到，一些小细节都可以妥协。 这个说法也可以换一个描述 就是 一个需求问题， 技术上无法实现的，从产品上去规避，产品上无法规避的，从商务上进行妥协。交易无非就是利益交换而已，技术上做不到的，对于交易来说只是少了一张可以出的牌。 |
|
9
fe619742721 OP @madlifer 刚熟悉了两天，有一点感受到你说的 技术做的久，思维打不开的那种感觉了，现在在有意的提醒和克制自己的技术思维，不过说实话，这个磨合和转变过程很煎熬，我知道现在的状态有问题，我也知道问题的原因，但是只能靠自己摸索问题的答案
|
|
10
madlifer 2022-04-21 09:38:13 +08:00
@fe619742721 我建议可以去读一读产品的经典书，比如 产品方法论、 上瘾、启示录、用户体验要素、金字塔原理、学会提问，可能更多不是说你要学到什么，二是感受一下产品思维考虑的出发点是什么。其他都可以电子阅读，俞军的《产品方法论》可以买一本纸质书经常翻一下
|
|
11
madlifer 2022-04-21 09:39:28 +08:00
@fe619742721 自己摸索可能时间太长了，本身你转岗 boss 肯定对效果有要求，还是多看看书比较好一点。还有两本比如 人月神话、UML 之类的我估计你作为研发肯定看过，就不推荐了。
|
 |
12
joApioVVx4M4X6Rf 2022-12-11 09:47:40 +08:00
楼主怎么样了，我也最近被技术思维困扰，怎么跳出技术思维看世界呢
|
|
13
fe619742721 OP @v2exblog 干的没什么动力了，想转回去。。
|
 |
14
laujon 2023-08-07 16:06:44 +08:00
楼主现在怎么样了？还在做产品吗
|
Select Language