learn-tech/专栏/技术领导力实战笔记/096阿禅:工程师转型产品经理可能踩到的坑.md
2024-10-16 06:37:41 +08:00

129 lines
10 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

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