7.4发了一篇技术如何转产品的文章:【周复盘】技术如何转产品01——1+1>2?
所谓知行合一,这边真的就去做了一些产品相关工作,4个多月下来小有心得,这里分享出来大家聊聊。
问题一:什么是技术产品
首先回答第一个问题应该是,什么样的技术适合转产品?
1)做技术已经达到了自己天花板,并且感觉自己很难再进一步,努力做技术ROI很低的同学;
这是我本来有一个领域(Scope)的事情做的很好,但是这个领域我已经很难再进步了,于是我发展了一个跟这个领域很相关的另一个领域,于是我就变成了所谓的两栖人才。
2)做技术中途转技术管理后,发现技术领域已经达到了天花板,想更多的了解业务,做更多创作性的工作,于是从技术总监转成了产品;
3)发现自己技术做不下去,又不想离开互联网行业,于是...
总而言之,就是技术这条路大概是走不下去了,所以就转产品了......
问题二:技术转产品有什么难点
1)对这个世界的认知太少;
做技术比较好的同学,往往有一些蜜汁自信,因为他有将想法变成现实的能力,会认为这是一种稀缺能力(现在逐渐变多),差的只是一个想法:)
PS:他们不知道的是这个想法其实更稀缺
但真的做技术比较好的同学,在技术上(特别是代码)会花费大量的时间,什么设计模式、操作系统、数据结构、前端框架,随便一个玩意,跳进去2年就没了,你出来的时候的感觉基本就跟跟什么都没学似的,有人问你什么是设计模式,你大概率依旧回答不了......
因为个人的精力是有限的,你投入了技术,那么你对业务、对产品、对销售、对人际关系等等会不太懂,甚至会认为跟人打交道是个很麻烦的事情,不然写代码来的简单,技术做产品的第一个问题是对真实世界了解太少,并且认为真实世界是傻逼:
所以,技术想要做好的产品,首先要打破认知壁障,这里要做的第一件事就是承认自己不行!
最近产品负责人让我去面试产品专家的时候,我第一句话就是:我的产品专业度不行,单就产品我未必能问出太多的东西,可能会更着重做事一块......
初期,诚实的面对自己,说自己不行,没什么丢脸的,但一年后还是不行的话,那可能就是真不行,不太适合做产品了。
2)产品需要深转
产品工作有一点跟技术类似:产品需要深转,真实的进入每一个难题,不断的自我质疑,然后再找到解法,这里是我们公司的对产品的定义:
产品是通过不断的输入,找到不同的排列组合,产生对用户更有效、更高效、更可及的解法。
所以产品的本质是解决生活中的问题,这个跟我们解决技术上的问题是一样的,简单的BUG是一种解法,复杂的问题需要框架,所以复杂的产品问题是需要对应的产品框架来解决的。
可以类比你思考一个框架难点时候的的辗转反侧,也可以类比你解决了一个性能瓶颈的欣喜若狂,产品设计是需要耗费巨大心力的,这里面是很多很多的策略,很多很多的匹配策略落地的策略。
一个产品点子,可能需要一百个策略来推动,不可谓不难!
如果认为产品比技术简单而想要转产品的同学,我觉得可以慎重,这条路不简单,有时候甚至更难......
3)产品更需要交流
产品是一个对协调能力要求较高的工种,上要串联运营,下要单挑开发,前要PUA老板,后要跪舔设计。
如果本身“木讷”的程序员要做以上工作,会被伤害自尊心的,这个心理防线首先自己就要拉低,这个时候很多技术会认为还是写代码轻松......
进入真实世界后,你会发现,当初自己认为多么了不起的技术大神,也只是在技术领域罢了,其他领域依旧有大神,没有优劣之分,技术不比其他工种更优越,要把这句话记住,虽然我依旧认为程序员是最伟大的......
问题三:技术转产品为什么会那么恶心?
最后一个问题扣一下主题,尺有所短寸有所长,技术产品也会有很多天然的优势,但这些优势对技术来说,可能比产品本身更恶心人......
这里不说原因,直接上几个Case。
1)我觉得该这么实现
一天项目组两个前端吵得面红耳赤,我听了下大概内容,无非是A同学想用这个框架,B同学想用那个组件,一个事情争完以后,又为其中一个技术细节实现拉扯了快一小时了。
考虑到项目进度,我直接嚎了一嗓子:你们这种技术之争,不要在这扯犊子,我觉得可以用A同学那个方式去实现,原因是1、2、3,其实B同学的方案也不会有太大问题,最终都能实现我要的功能,只不过你们在这样争论下去会影响我项目进度,所以我建议......
2)我想重构系统
一天,后端主程跑过来给我说,之前下面同学实现不够优雅,我想重构一下系统......
我的回答就很简单了,重构个锤子,滚!!!
3)你怎么不画原型图
第一次做我项目的同学都会发出一个疑问,你怎么不提供原型图?
这里真实的答案是,我不会画那玩意,并且我不想去学......
图片型文档,我最多提供一个PPT,如果是这样,技术看来,这个产品真尼玛是low到爆了,但是:我把数据表设计出来了......
然后把我认为该提供的文案尽量提供齐全,由于职业习惯,每个策略甚至伪代码都会在大脑里面跑一圈,数据流也不会出问题,于是在项目后期,就会出现另一个场景:
我:这个系统现在的数据结构,跟我最初的设计差距大不;
后端主程:差距不是很大......
4)什么时候能实现
在项目过程中,我说个最多、最讨人厌的一句话就是:
这个应该很简单吧,什么时候能实现......
技术同学多次据理力争,最终却无功而返,但是这样有个非常重要的点要注意:
现在写代码的毕竟不是你,技术同学要怎么做实现,他说的deadline只要跟你冲突不大,不要斤斤计较,请不要斤斤计较,随它去吧。
综上,技术转产品后,正常情况下可以与程序员完美沟通,效率奇高,做产品设计时会更考虑版本迭代,甚至可以达到,1.0、2.0、3.0三个版本毫无关系,最终迭代却有完美一体,无论对迭代还是维护,都有莫大的好处。
5)你不要扯犊子了
有时候跟一个产品同学聊天,确实相持不下的时候,最后会忍不住冒出一句,你不要扯犊子了,你这个根本不能实现,并且成本极高,你考虑清楚再说好不,下面技术同学会怎么骂你......
产品:那个,我......
正所谓,你跟我说产品我跟你说实现,你跟我说实现,我跟你说体验,你跟我说体验,我跟你说收入,恶心人莫过于此吧?
结语
以上是我做产品时候一些小小的心得,希望对各位有用。