6 个回答
研发与产品有相同的地方，都是要去思考一件事情的解决方案。
产品考虑的是业务的解决方案，研发考虑的是技术实现的解决方案。
两种方案中，都包含正确的流程、异常的处理，未来的扩展，历史的兼容。
思维模式相同，但是具体的环境不同。
我要这么说，你可能觉得那技术转产品其实挺简单的。
那我接下来要说的就是这其中的不同。
如果把解决问题当做一道数学题，技术研发所用的公式，其中的参数维度会简单的多，用研发的思维讲，就是输入的参数从数量上和维度上都很少。而产品不同，产品解题用的公式，输入的参数它的变化范围更大，维度更多。而且解决一个问题，需要用的函数也更多。
以上是用研发思维的总结。
咱在说产品的思维，做产品要考虑的不是解题的答案，而是这个答案对于全局的价值。
解决一个问题可以有多种解决方案，但是价值最合适的那个才是你最需要的。为什么我这里没有说价值最大的，还是因为全局二字，你为解决这一个问题，设计的方案，或许对当前这个方案来说是最优解，最完美的，但是对全局则不一定。
举例来说：当前我们为了配合一个营销活动，做相应的支持功能，但其实这个活动最终效果如何我们运营也好产品也罢，都拿不出有力的证据来证明，尚处于摸索阶段，那么你如果将方案出的特别完美，特别全面，也就意味着大量的资源投入。但是其实对于全局来说，这种验证性的需求，我们只要初期达到前端业务逻辑能够支撑的程度即可，待运营起来之后，再根据数据反馈决策是否继续完善。
多说一句，研发转产品，切记要避免一点，就是陷入以前做技术解决方案的细节中去，你可以慢慢学原型，慢慢学设计，但是一定要将思维转换过来，要本着解决根本而不是表象的宗旨去思考。
就说这么多吧，如有不足，请多指正。
https://coffee.pmcaff.com/article/G2Qd27WVkZ/coffee
关于技术转产品，是从执行落地how思维到根因探究why思维方式上的切换，其中最关键start with why 思维非常关键，附上个人原创的文章系统说明了这个这个思维，供参考。
当开发人员的时候，最多考虑的是如何实现一个纷繁复杂的功能吧？
如果转行做产品，把思路调整为自己（用户）会如何去用这个东西。拿最基础的登录注册来举例，如果你处在密码登录的状态下，已经输入手机号和密码，密码错误，此时你想用验证码登录，切换到验证码登录时，已经输入的手机号要不要保留呢？这个时候，保不保留，功能都已经完整，但是如果手机号能够带过来，对用户来说体验就会更好一点。
这只是用户体验的一个细节，产品更多的还会考虑在未来一定时间内需要完善的功能，有点像下象棋，将军之前的排兵布阵。而这将军之前的准备，在技术人员的眼前往往会变成产品经理SB，天天都在设计些什么玩意。（此话不绝对，只是表达个意思）
如果你想转换自己的思维，可以看看自己负责产品的历史迭代，回顾并揣摩每一个版本，每一次迭代的设计思路，在当时为何那样设计，有哪些地方做的很好，有哪些地方做的不合理，有哪些版本让用户量得到了飞跃，有哪些版本上线后卸载率大幅上升。这样重新用不同的眼光看看自己开发的产品，应该能够体味到作为设计者和实现者的思维差异。
然后也可以看看竞品的设计思路，尝试去了解用户画像，抽时间画画竞品的原型图，也看看产品相关的书，希望能帮助到你
- 先放下架子，俯下身来，听一听客户想干什么？别没说两句就说：这个行不通，那个不合理。产品就是基于客户需求构建合理性和可行性的
- 不要像个科学家一样，闷头格物致知，闭门造车，搞出来一堆飞机稿没办法落地，客户就在现场，放空心态，多沟通，多学习，多询问。张一次嘴比想一天还有用。
- 先把人理顺了，然后理流程，最后理功能。不要一上来钻到细节里面出不来，不叫停的话，选型都搞完了，最后拿着一堆自以为的文档当成成果。人能立得住，需求才立得住，然后才有后来，否则连后来都没有。
- 跟用户聊不要带一堆专业名词，什么spark，hive，hbase，客户听不懂，也不想听，他们只关心需要我干什么，花多少钱，能干成什么样，有什么风险，你怎么给我保证？
- 不要着急给解决办法，更不要着急出技术方案，也不用说我有100种方法能够实现你的需求，用户只需要一种最好的，越是着急的需求，越要缓慢的回答。
- 在其位谋其政，不要这么体谅你得研发兄弟们了。该逼一逼的时候是要逼一逼。
谢邀，我赞同却道天凉的观点：产品考虑的是业务的解决方案，开发考虑的是技术实现的解决方案。
不过既然来了，我还是留点观点哈，那就是先把自己问残了再说，哈哈哈
NO.1【职业发展定位】
为什么我要从技术转产品？什么是产品经理？
NO.2【同理心】、【结构化思考】、【会分析（竞品分析、案例分析等）】【会争资源、排优先级】。。。更多
A、用户是如何具体和你的产品发生关系的，一个什么样的人出于什么目的，在怎样的时机，场合做了什么，怎样用你的产品，最后得到了什么？
B、二八原则、以终为始、穷尽所有，互不交叠
C、如何通过分析使产品变得更好
D、dis一些反向需求
NO.3【面对用户的需求，得怎么落地，如何大胆猜想、小心求证】
或许得先明白4个知道
A、知道理论上的进展
B、知道实际上能达到的程度
C、知道最牛逼公司的工程架构
D、知道当下公司可以达到的程度
最后调研、分析、总结、文档、评审、开发、测试、上线、迭代
NO.4【作战地图】
MTP：
先角色化，因为不再是被动接受，而是主动去意淫、去分析、去规划对应的作战地图；比如制定目标（市场占有率、营收、技术）、策略？清楚商业模式、市场定位的变化和调整；
保持对外部战场环境的敏锐程度（竞争对手发生了哪些变化？未来的技术方向？政府的方向是什么？）
NO.5【KPI如何完成、产品如何迭代，得不间断的复盘】
抗KPI，一个人干？还是拓团队干？
NO6.【工具支撑】
离不开组织结构、后台工具平台、运营方法和策略、工作标准产生
NO.7【未来可期、如何发展】
你所在的团队，你觉得缺什么样的人才，你需要什么样的搭档，团队在那些方便存在人才风险，类似的人才是什么样的，将在团队中起什么样的作用？。。。。等
以上短时间梳理，或许会有不全，随时欢迎同伴补充；
供你参考。谢谢！
认识不同岗位的约束条件，以及该约束条件下实现目的的最优解。
研发是按时、高质量的完成任务，在此条件下，不得不去考虑实现难度，任务量的多少，不然做不完啊，不然就是给自己挖坑了，因此要和产品经理周旋，砍价。
产品是实现用户/商业价值的最大化，在此条件下，就要想用户到底想要什么，产品如何提供最好的解决方案满足需求，这是当前价值最大的事情么？因此要忽略技术细节、如何实现，思考如用户价值的最大收益。