技术转产品需要怎么去转换自己的思维模式呢?

开发和产品一般会从不同的维度去思考问题,如果一个开发人员转产品岗,需要怎么去转换自己的思维模式呢?
阅读全文
请先 登录 后评论
  • 0 关注
  • 0 收藏 67 浏览
  • 略问用户 提出于 2020-10-22 17:37:52

6 个回答

xxxxxa

研发与产品有相同的地方,都是要去思考一件事情的解决方案。

产品考虑的是业务的解决方案,研发考虑的是技术实现的解决方案。

两种方案中,都包含正确的流程、异常的处理,未来的扩展,历史的兼容。

思维模式相同,但是具体的环境不同。

我要这么说,你可能觉得那技术转产品其实挺简单的。

那我接下来要说的就是这其中的不同。

如果把解决问题当做一道数学题,技术研发所用的公式,其中的参数维度会简单的多,用研发的思维讲,就是输入的参数从数量上和维度上都很少。而产品不同,产品解题用的公式,输入的参数它的变化范围更大,维度更多。而且解决一个问题,需要用的函数也更多。

以上是用研发思维的总结。

咱在说产品的思维,做产品要考虑的不是解题的答案,而是这个答案对于全局的价值。

解决一个问题可以有多种解决方案,但是价值最合适的那个才是你最需要的。为什么我这里没有说价值最大的,还是因为全局二字,你为解决这一个问题,设计的方案,或许对当前这个方案来说是最优解,最完美的,但是对全局则不一定。

举例来说:当前我们为了配合一个营销活动,做相应的支持功能,但其实这个活动最终效果如何我们运营也好产品也罢,都拿不出有力的证据来证明,尚处于摸索阶段,那么你如果将方案出的特别完美,特别全面,也就意味着大量的资源投入。但是其实对于全局来说,这种验证性的需求,我们只要初期达到前端业务逻辑能够支撑的程度即可,待运营起来之后,再根据数据反馈决策是否继续完善。

多说一句,研发转产品,切记要避免一点,就是陷入以前做技术解决方案的细节中去,你可以慢慢学原型,慢慢学设计,但是一定要将思维转换过来,要本着解决根本而不是表象的宗旨去思考。

就说这么多吧,如有不足,请多指正。

请先 登录 后评论
xxxxxa

https://coffee.pmcaff.com/article/G2Qd27WVkZ/coffee

关于技术转产品,是从执行落地how思维到根因探究why思维方式上的切换,其中最关键start with  why 思维非常关键,附上个人原创的文章系统说明了这个这个思维,供参考。

请先 登录 后评论
xxxxxa

当开发人员的时候,最多考虑的是如何实现一个纷繁复杂的功能吧?

如果转行做产品,把思路调整为自己(用户)会如何去用这个东西。拿最基础的登录注册来举例,如果你处在密码登录的状态下,已经输入手机号和密码,密码错误,此时你想用验证码登录,切换到验证码登录时,已经输入的手机号要不要保留呢?这个时候,保不保留,功能都已经完整,但是如果手机号能够带过来,对用户来说体验就会更好一点。

这只是用户体验的一个细节,产品更多的还会考虑在未来一定时间内需要完善的功能,有点像下象棋,将军之前的排兵布阵。而这将军之前的准备,在技术人员的眼前往往会变成产品经理SB,天天都在设计些什么玩意。(此话不绝对,只是表达个意思)

如果你想转换自己的思维,可以看看自己负责产品的历史迭代,回顾并揣摩每一个版本,每一次迭代的设计思路,在当时为何那样设计,有哪些地方做的很好,有哪些地方做的不合理,有哪些版本让用户量得到了飞跃,有哪些版本上线后卸载率大幅上升。这样重新用不同的眼光看看自己开发的产品,应该能够体味到作为设计者和实现者的思维差异。

然后也可以看看竞品的设计思路,尝试去了解用户画像,抽时间画画竞品的原型图,也看看产品相关的书,希望能帮助到你

请先 登录 后评论
xxxxxa
  • 先放下架子,俯下身来,听一听客户想干什么?别没说两句就说:这个行不通,那个不合理。产品就是基于客户需求构建合理性和可行性的
  • 不要像个科学家一样,闷头格物致知,闭门造车,搞出来一堆飞机稿没办法落地,客户就在现场,放空心态,多沟通,多学习,多询问。张一次嘴比想一天还有用。
  • 先把人理顺了,然后理流程,最后理功能。不要一上来钻到细节里面出不来,不叫停的话,选型都搞完了,最后拿着一堆自以为的文档当成成果。人能立得住,需求才立得住,然后才有后来,否则连后来都没有。
  • 跟用户聊不要带一堆专业名词,什么spark,hive,hbase,客户听不懂,也不想听,他们只关心需要我干什么,花多少钱,能干成什么样,有什么风险,你怎么给我保证?
  • 不要着急给解决办法,更不要着急出技术方案,也不用说我有100种方法能够实现你的需求,用户只需要一种最好的,越是着急的需求,越要缓慢的回答。
  • 在其位谋其政,不要这么体谅你得研发兄弟们了。该逼一逼的时候是要逼一逼。
请先 登录 后评论
xxxxxa

谢邀,我赞同却道天凉的观点:产品考虑的是业务的解决方案,开发考虑的是技术实现的解决方案。

不过既然来了,我还是留点观点哈,那就是先把自己问残了再说,哈哈哈

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【未来可期、如何发展】

你所在的团队,你觉得缺什么样的人才,你需要什么样的搭档,团队在那些方便存在人才风险,类似的人才是什么样的,将在团队中起什么样的作用?。。。。等


以上短时间梳理,或许会有不全,随时欢迎同伴补充;

供你参考。谢谢!

请先 登录 后评论
xxxxxa

认识不同岗位的约束条件,以及该约束条件下实现目的的最优解。

研发是按时、高质量的完成任务,在此条件下,不得不去考虑实现难度,任务量的多少,不然做不完啊,不然就是给自己挖坑了,因此要和产品经理周旋,砍价。

产品是实现用户/商业价值的最大化,在此条件下,就要想用户到底想要什么,产品如何提供最好的解决方案满足需求,这是当前价值最大的事情么?因此要忽略技术细节、如何实现,思考如用户价值的最大收益。

请先 登录 后评论