共计 3377 个字符,预计需要花费 9 分钟才能阅读完成。
分享前,我先自我介绍一下,我从事 Java 开发的全栈工程师 5 年,也是一名连续创业者,之前做过科技媒体、做过智能音箱,做过很多事,踩过许多坑。今天想跟你分享的话题是“工程师转型产品经理可能会遇到的几个坑”。
之所以称之为“坑”,而不是“问题”,是因为我自己并没有真正做过工程师,而是接触过很多工程师,也有很多工程师转型产品经理的朋友,我将所有的问题与经验总结起来,并分享给你,希望对你有用。
工程思维与产品思维
首先以手机摄像头为例,来说说工程思维与产品思维的差异。假设我们要做一款手机摄像头,从工程思维的角度,我们可能会考虑,如何提高摄像头的分辨率;如何提高弱光下的快门速度;如何进行 ISO 调整;如何优化人像识别功能;如何使闪光灯更智能等等。
从产品思维的角度,我们可能会更多的考虑拍照场景、美颜效果,比如如何拍出来就显五官立体、肤色嫩白;如何做到自动美颜并可以立即分享朋友圈;如何从众多照片中自动选取最美的一张等等。
我与很多工程师朋友的理解是:工程思维更关注效率和如何实现,也就是“How”;而产品思维更关注“场景”以及用户的内心需求,也就是“Why”。
在具体的产品开发中,产品思维和工程思维都很重要,需要将两者结合起来,产品思维需要工程的配合与支撑,将“场景”落实到产品开发。比如,产品经理想做一款夜间拍摄效果更好的手机摄像头,那么就要做到既保证人像清晰,又保证背景明亮,这时就需要工程师们在技术上做相应的提升和优化,比如前景快门锁定、快门拉长等。
工程师转型产品经理可能遇到哪些坑?
在这次分享前,我跟几位从工程师转型做产品经理的朋友聊了聊,从中摘取了四条较为典型的吐槽。
视角变了,原先追求完美和逻辑性,现在是怎么快速实现目标怎么来;
很多时候,用户视角的简单性与工程思维的完美性有冲突;
转型这一年,踩过的坑无数,包括产品战略层面、沟通层面、团队管理层面、执行层面;
以前不用做这些,现在要做很多公司内部的东西,比如对上沟通,然而老板永远不懂我;对下沟通,光打鸡血远远不够;还有跟兄弟团队和部门之间因为资源不足产生的博弈等。
对此,我稍稍总结了一下,总结出了工程师转型产品经理时,可能会踩进去的 7 个坑。
除了这些,针对当前互联网公司的技术需求以及结合主流技术,我自己整理了一套系统的架构技术体系,当你技术过硬的时候,能够解决技术问题才会服众。不少公司都很重视高并发高可用的技术,特别是一线互联网公司,分布式、JVM、spring 源码分析、微服务等知识点已是面试的必考题,这些东西可能你们平时在工作中接触过,但是缺少的全面系统的学习,加入后端开发群:943918498,或是关注微信公众号:Java 资讯库,回复“架构”,免费领取架构资料。
1、认为用户傻
“我明明设计了一个很聪明的按钮,用户就是不用, 非要用那个复杂的方法来使用我的产品。”
举个例子,假设产品经理设计了一个开关,用户只需向上一推就可以把灯打开,比原来向下按的方式更省时省力,结果发现用户并不买账。可能 99% 的用户还是用向下按的方式去开灯,尽管这样会稍微费力一点,但用户已经习惯了这样的行为方式。
对于这类情况,很多产品经理容易陷入一个误区:既然有更加方便的产品使用方式,用户就该放弃原有的方式,去使用新方式。但是,他们忽略了用户习惯较难改变的事实。
2、觉得同事傻
“那帮运营和市场老给我提不靠谱的需求, 一点都不懂技术和产品,瞎指挥。”
这是我曾经陷入的误区之一,以前我在一家公司做客户端,很多时候,市场和销售的人在与客户聊天之后,就会找我提需求,比如在某个位置加个广告位。在当时的我看来,这完全是他们在瞎指挥。
后来,我反思当时的做法,认为应该从两方面思考这件事。第一个方面,当同事提需求时,这个需求可能已经变质,不再是客户的原始需求了。作为产品经理,应该去了解客户最原始的需求。
第二个方面,应该考虑同事提出这个需求想达成的目的,比如他的目的可能并不是为了加一个广告位,而是为了借此达成盈利目标,那我们其实可以通过其他方式帮助他实现目标。
因此,当同事提需求时,我们应该把他和普通用户放在同一层面,尽管提的是一些所谓的“傻”需求,我们也要花费时间与精力去认真分析这些“傻”需求背后的动因,以及如何才能帮助他们解决问题、实现需求。
3、觉得同事还是傻
“明明那么简单的道理和逻辑, 这帮同事怎么就不理解呢?”
这个问题其实出在沟通层面,然而,产品经理很重要的职责是沟通, 很多时候, 沟通是做成一件事的关键。
之前有个产品经理跟我分享,他做工程师时不擅长沟通,也不想沟通。在他看来,这些事情都很简单,为什么还要花时间给别人解释,这是他后来转型做产品经理时很难跨过的一道鸿沟。
在公司中,不同职位与不同资历的人,彼此的认知都不同,而作为产品经理,需要团结团队里的每一个人,让大家朝着同一个目标努力。那么,你就必须跟所有人解释,某件事的重要性,某个功能为什么存在,某件事为什么要那么做等等。而且,因为认知的差别,你与每个人的沟通方式也要有差别,找到合适的沟通方式才能获得对方支持。
可以说,提升沟通能力是工程师转型产品经理的必经之路。
4、容易在前端呈现过多技术
“我给用户做了一个特别炫酷的功能, 用户可以自定义各种参数,但似乎他们并不怎么用。”
其实,许多做产品的书籍、课程都会写到,不给用户选择,反而是最好的选择。举个例子,前段时间小程序黑咔相机特别火,日活量最高时可达千万。它的功能特别简单,就是给照片中天空提供各种动态效果,比如用户选择梵高星空,它就能将图片中的天空变幻为动态的梵高星空效果,然后一键保存、分享,操作非常简单,过程中没有任何需要技术的地方存在。
这个产品的用户平均年龄大概 50 岁,最早在某个摄影群中爆发,由于操作简单,效果有趣,迅速被群成员分享,一天时间内由日活 30 多万,迅速上涨至几百万,第二天再增长至一千万,是一个特别经典的例子。
5、过于追求完美,害怕返工
“用这个方法来实现产品方案太笨了,对服务器的开销太大,我们应该重写代码,用另一种方案。为了应对未来可能存在的需求改动,我要把能在后端定制的功能都写了 API,并且把功能拆成各种层级。”
许多创业公司在开发产品前会将计划思考周到,以防未来可能出现的需求改动,比如将各种 API 补全、把框架都搭好等等。但在实际开发过程中,我们还需考虑阶段性问题,如产品当前处在什么阶段,是否应该在当前寻求最完美的实现方案;如果处在 MVP 阶段,是否应该允许回炉重做等等。
我们应该允许一些不影响主功能的 Bug 存在,先让功能运行,再补全不完美的地方。有许多工程师害怕返工,觉得按照产品经理的需求去做时,会不断出现新的需求,就需要不断地返工进行完善。然而对产品经理来讲,他需要根据每个阶段的数据变动,去观察市场反馈,从而迅速做出调整。所以,我们应该放下害怕返工的心态,接受随时推翻重做的可能性。
6、认为功能大于场景
“我们有 A 功能、有 B 功能、有 C 功能……我们有非常多的功能,都是我们自己的技术实现的。”
产品经理经常犯一个错,就是总觉得应该再多开发一些功能给用户使用,让他们的体验更丰富。然而,我研究了许多小程序的方法论,发现小程序之所以火爆,除了自身裂变属性较强外,非常重要的一点是,它只满足用户一个功能的需求。你可以看到,很多拥有多合一功能的小程序,很难火起来,因为功能增多之后,会模糊用户对这个小程序的认知。
7、忽视运营
“酒香不怕巷子深, 好的产品, 用户自然回来, 首先要做好的是产品, 运营和营销并不重要。”
其实不然,产品与运营始终不可分割,产品经理一定要与运营人员密切沟通,甚至做到产品经理即运营本身。
最近几年,很多成功的产品,其成功的原因中运营占得比重甚至大过了产品本身。以小程序为例,很多小程序的功能比较容易实现,技术门槛并不高,别人也可以快速复制,关键点反而在于如何做用户增长。
对此,我们的做法是采用 AB 测试,反复测试,总结结果,在这个过程中,产品经理需要跟运营不断沟通,共同摸索出最优结果。
并且很多时候,产品经理还需要身兼多重角色,我有一位朋友是做电商产品经理,他每天除了做 AB 测试,测试各种按纽,优化各种流程之外,还会涉及对文案细节的改动,某次他改动了一句广告语,结果下单率提高了 9%。
可以看出,产品经理做测试、运营、文案等细节工作,看似与技术没有太大关系,却是产品获得成功必不可少的一部分。