技术转产品应该注意什么

[fe619742721]

6 年前端，现在有一个契机转 toB 产品岗位，对产品业务逻辑有自信，对产品工作方式和沟通交流的能力不是很确信。

目前考虑可能的几点挑战：
1. 角色的转变，要从之前研发的角度对需求进行批判，转变到从产品的角度从 0 开始构建需求
2. 工作方式的变化，重文档，重交流
3. 避免带入技术思维


希望各位不吝赐教。

[freeup]

楼主之前怼过产品么 对产品有意见么？ 换位思考下 就知道该注意什么了

[fe619742721]

@freeup 有过，我现在带一个小团队，需求评审的时候我是怼人主力军。。

[ddoyou]

现在带小团队，沟通能力问题应该不大，产品更多的是要：思考为客户解决需求的方式。
把解决方式搞明白后转发给开发团队

[fe619742721]

@ddoyou 感谢建议，现在就是对客户沟通这块有点儿虚，目前有几个大客户定制需求需要跟进

[LaGeNanRen]

建议就是：不要试图用技术能力解决业务问题、以及商务们酒桌上应该谈好的问题：）

[sutaking]

好的产品要能聚焦需求，把研发的力量投入到最有效的地方，一般的产品就是什么都要做，还自信于自己抠细节的能力

研发的角度

[frozenshadow]

技术转产品的好处是有需求的时候能想到大致的解决方案和 ROI ，但做产品之后要注意身份转换，不要被过去的经验束缚。ToB 的产品最大的难点在于理解用户背后真正的需求。还有就是要注意：ToB 生意里面，用户和客户不是同一个概念

[madlifer]

我是比较反对技术转产品的那部分人，我认为技术做的越久，思维越不容易打开，单纯做个合格的 PM 是问题不大的，但是思考方式的局限性可能会导致成长性不高，做不了开疆扩土的那种产品。

我相信你都 6 年经验了，换岗肯定有自己的考虑，多半是为成长性方面的考虑，比如带产品带好了，转成产品总监。所以我觉得还是得看你自己怎么想的，有没有抛弃“模式经验”的决定。

#5 说的挺好的，不要用技术能力解决业务问题。 很多开发喜欢钻牛角尖，定了个需求就死磕技术方案，但作为产品侧来说，只要版本目标能够达到，一些小细节都可以妥协。

这个说法也可以换一个描述 就是 一个需求问题， 技术上无法实现的，从产品上去规避，产品上无法规避的，从商务上进行妥协。交易无非就是利益交换而已，技术上做不到的，对于交易来说只是少了一张可以出的牌。

[fe619742721]

@madlifer 刚熟悉了两天，有一点感受到你说的 技术做的久，思维打不开的那种感觉了，现在在有意的提醒和克制自己的技术思维，不过说实话，这个磨合和转变过程很煎熬，我知道现在的状态有问题，我也知道问题的原因，但是只能靠自己摸索问题的答案

[madlifer]

@fe619742721 我建议可以去读一读产品的经典书，比如 产品方法论、 上瘾、启示录、用户体验要素、金字塔原理、学会提问，可能更多不是说你要学到什么，二是感受一下产品思维考虑的出发点是什么。其他都可以电子阅读，俞军的《产品方法论》可以买一本纸质书经常翻一下

[madlifer]

@fe619742721 自己摸索可能时间太长了，本身你转岗 boss 肯定对效果有要求，还是多看看书比较好一点。还有两本比如 人月神话、UML 之类的我估计你作为研发肯定看过，就不推荐了。

[0x0208v0]

楼主怎么样了，我也最近被技术思维困扰，怎么跳出技术思维看世界呢

[fe619742721]

@v2exblog 干的没什么动力了，想转回去。。

[laujon]

楼主现在怎么样了？还在做产品吗