做产品经理,还是得多听老人言
刘飞 人人都是产品经理

知乎上有个问题是:『有哪些事情是你入行时不以为然甚至嗤之以鼻,入行后却整个颠覆了之前的认知并奉为至理的?』

我是这么回答的:

1.『产品经理不是经理。』

刚入行的时候觉得自己高高在上,或者至少觉得自己很有分量。相信大多数产品经理都这么感觉的。『我比程序员高贵。』『我是未来要成为 CEO 的男人/女人。』

实际上呢...

请自行百度『产品经理是条狗』。歌词很感人。

真把自己当成经理,工作上绝逼会步步维艰,什么都推动不了。

2. 『不管设计得再怎么样完美,需求总会改的。』

以前还特别奇怪,你设计产品的时候考虑周全点儿不就行了,干嘛非得改需求。但是经过了很多次惨痛的教训,终于发现,需求总是会改的。

改需求不代表产品经理不认真、太随意,也不是老板或者高层总喜欢拍脑门想点子,而是有很多现实原因。

可以列举一些:

市场情况变化。比如因为某些事件,用户的需求变动;或者竞争对手的动作,导致必须有应对措施。

运营策略变化。比如公司的运营手段不同了,导致产品上的支撑方法也要不同。

研发阶段暴露出了问题。比如有一些底层逻辑之前很难发现会出问题,但研发中暴露了,导致产品方案要改为更适配的。

时效性变化。比如由于开发周期过长,导致时效性下降,所以也没必要用原来的复杂方案。

临时需求插入。比如各种因素导致的,有更重要的需求紧急加入,这时必然要修整原来的方案或者延后开发。

虽然产品经理确实会在设计上出现纰漏,但更多情况下,产品经理只是背锅侠而已...这是我从事这个职业前没有意识到的。


3. 『用户很傻,而且会越来越傻。』

这里说的傻不是 low,也不是笨,而是用户不会愿意在使用产品的时候还思考。

我在入行前也觉得说用户傻的人才傻,现在是什么年代,大家的知识量、对新事物的接受程度都大不一样,什么不会用去网上搜一搜、跟朋友问一问不就好了?

几年前很出名的书《Don't Make Me Think》说的理念我就不太明白,想一想怎么了。

后来发现在设计的时候真的很蛋疼。

一些特别小的问题、在用户体验上一点极小的漏洞,都会产生巨大的灾难性的后果。真的除非把用户当成小白,不然设计出的产品总会被骂。

比如之前朋友做的产品的一个功能,是邀请有奖。用户 A 发二维码给用户 B,用户 B 扫码下载,注册成功再去输入邀请码,两边都有奖。就是中间有个环节,用户 B 扫码下载后,90% 都意识不到要去设置里输入邀请码。

虽然邀请机制在各种 APP 里都有我们认为大家都很熟悉了,虽然在用户 A 发给用户 B 的使用说明里都明确写好,但是用户就偏偏不去找,也不知道去找。

最后怎么办呢。把用户当成小白,设计中用户 B 扫码后先填自己的手机号,才能下载。这样记录下用户 B 的手机号,也就知道他是用户 A 邀请的了。后面就不需要用户 B 再输入邀请码了。

就是从产品设计上来说很小的改动,让这个功能的使用率上升了好几倍。

空白页的设计也是很好的防呆设计。比如相册、任务表等空白页里,可以提示用户点击什么/去哪里找到新建照片、新建任务的功能。是的,现在看起来都很傻,但真的很重要......估计众多产品同僚们有过血泪史。

像这个空白页,是分享过的内容,下面看起来像是废话:『你分享过的东西将会出现在这里。』不过没有的话,真的会有很多用户搞不明白。

再比如一个很经典的反面例子:

尼玛谁知道 USB Mass Storage Device 是啥啊。好,就算知道这个,『通用卷』又是什么鬼?

我百度过了,知道什么 Storage Device 和『通用卷』的意思了,那现在呢?我该干嘛啊?

国产的某应用的做法就形成了鲜明的对比。

防呆、把用户当成傻子,是产品设计的基本思路。并不是说用户真傻,而是他们越来越懒,并且希望找到最不需要动脑的产品。

这也是为什么 T2 发布会上老罗主打的远程协助功能引起大家共鸣。这个技术难吗?不难。这个功能之前没有吗?有啊。但是发布会里演示的效果就是操作简便,老人用起来不费力,这也是产品的竞争力。

说到用户越来越傻,其实大家都是有体会的。各种设计都在让大家少动脑、少动手,过去的电脑要经过专业培训才能用,现在的智能手机 3 岁小孩都可以快速上手。

4. 『要把用户体验做好,很不简单』

每次用什么产品,总觉得卧槽不就是几个按钮点来点去,几个页面切来切去吗?有什么难的。

用户体验的话,大家都差球不多,都没啥区别,比着搞一搞就行了。

后来才慢慢知道,原来看起来越简单、越自然的操作,就越需要更纠结、更慎重的考虑。

比如很多人用过聊天时会标注消息已被对方读到的功能后,就觉得自己想得比微信远了。大家都倾向于认为自己想到的别人没想到的,就是自己有理;而自己觉得应该没有,别人有了,也是自己有理。其实微信做这个是有自己的考虑的,他们的产品经理也不傻:

如果我们针对需求一个人去满足,你可能获取了这部分用户,但是得罪了另外一部分用户。有人就挺不喜欢把我的已读状态暴露给别人,你想这样的话,如果你的上级找你,你看了然后你又不回,就很麻烦。

我们要给人撒谎的机会,我们说人性是什么?给他撒谎的机会,说我没有看到。你看短信不太准确,我们经常会说,你那个短信丢了,我们没有看到。如果我们把人都像机器一样约束起来不一定是好事。

我们为什么不做已送达的状态?因为我们觉得未来的系统是绝对可靠的,我们有这个信心,肯定会送达,除非他关机了,我们不会再专门做一个是不是已送达,只有不自信的系统才会做这样一个状态。而且你每发一个消息还有个已送达或者发送中,那很丑陋的,多了一个东西在那里。所以这也是一种态度。对于这种用户要什么就给什么,其实这是考验产品经理水准的东西,因为我满足需求很容易,但是你怎么找到理由拒绝他,或者说找到什么方式实现它这个非常难。

也是从此之后,我对很多产品有了敬畏之心,不是想当然地跟大家扯皮:『这个 APP 做得好垃圾,你看这里XXX,你看那里XXX』。

真是做产品经理时间越久,就越发现自己的无知。比如很简单的可用性三个字,就有所谓的尼尔森十大原则:

一、状态可见原则

用户在网页上的任何操作,不论是单击、滚动还是按下键盘,页面应即时给出反馈。“即时”是指,页面响应时间小于用户能忍受的等待时间。

二、环境贴切原则

网页的一切表现和表述,应该尽可能贴近用户所在的环境(年龄、学历、文化、时代背景),而不要使用第二世界的语言。《iPhone人机交互指南》里提到的隐喻与拟物化是很好的实践。此外,还应该使用易懂和约定俗成的表达。

三、撤销重做原则

为了避免用户的误用和误击,网页应提供撤销和重做功能。

四、一致性原则

同一用语、功能、操作保持一致。

五、防错原则

通过网页的设计、重组或特别安排,防止用户出错。

六、易取原则

好记性不如烂笔头。尽可能减少用户回忆负担,把需要记忆的内容摆上台面。

七、灵活高效原则

中级用户的数量远高于初级和高级用户数。为大多数用户设计,不要低估,也不可轻视,保持灵活高效。

八、易扫原则

互联网用户浏览网页的动作不是读,不是看,而是扫。易扫,意味着突出重点,弱化和剔除无关信息。

九、容错原则

帮助用户从错误中恢复,将损失降到最低。如果无法自动挽回,则提供详尽的说明文字和指导方向,而非代码,比如404。

十、人性化帮助原则

帮助性提示最好的方式是:1、无需提示;2、一次性提示;3、常驻提示;4;帮助文档。
现在真的不敢随便说『用户体验不就是那么回事』这样的话了。

5. 『产品设计,尤其是交互和 UI,(大部分情况下)在一个产品中起到的作用只占 10%。』

这也是过去我嗤之以鼻的。牛逼的产品的交互和 UI,没有做得烂的,怎么可能起不到主要作用。

后来真的发现,如果功能不好用,再顺畅的交互、再华丽的 UI,都没意义。

比如聊微信,你发现数据丢了、记录没了,你是不会再用的;比如逛淘宝,你搞了半天都找不到想买的东西,你也不会再用。

再比如 12306,交互一塌糊涂(当然改版后略有好转),验证码烂到爆,更没什么视觉效果可言,但大家不得不用啊,因为能买票,买到票就行了。

还有像这个网站:

要是在意用户体验的同学,肯定已经要反胃了。但这可能是少有的广大男同胞都会使用的产品,因为只有这里能满足需求。

所以你看,12306 核心竞争力是垄断了票务,[敏感词]网站也是提供了其他地方没有的资源。交互和 UI 比起这些来微不足道。

这是一个方面,你会发现真的几乎没有人单纯为了交互和 UI 去使用什么产品。从另一方面说,互联网公司的成功之路上,产品设计相对于运营、推广、内容、资源,都是微不足道的。

你会因为滴滴打车那几个弹窗舒服、按钮合适就用吗?当然不是。用是因为补贴多,或者能打到车(有雄厚的推广资金和强大的线下运营团队)。

你会因为微信比别的社交 APP 简单、色调明朗就用吗?当然不是。用是因为大家都用啊,没得选(有海量的用户基础)。

你会因为支付宝的交互优秀、视觉突出就用吗?当然不是。用是因为安全啊,因为方便啊(有极佳的技术支撑和广泛的线下合作)。

有人会问,那为什么好产品的设计和交互都很不错呢?只是因为他们花得起钱雇高阶的设计师了而已...

6. 『产品经理要多看书、多学习。』

在入行前别人告诉我多看书多学习时,我不认可,我觉得产品经理应该多体验、多实践。

我当时想到证明我的论点的理由是:

互联网是千变万化的,产品经理又是很新的职业,过去的书和知识不能提供帮助。

产品经理需要的都是软实力,比如逻辑判断、沟通能力、审美和创新能。

产品经理并不需要太多技能和成体系的方法,尤其是工具、流程和制度,没有通用的。

只要够聪明,在摸爬滚打中同样能快速成长。

于是摸爬滚打一段时间后,再开始看书、虚心跟牛人学习,才意识到自己犯了很大的错误。

按刚才的顺序,倒着来说。

关于成长

够聪明的确能快速成长,但是产品经理的工作周期很长,也不像工程师或者设计师,做的成果很快就能得到检验。产品设计和项目跟进做得好不好,很有可能是要通过长达数月甚至半年的检验。

自己摸爬滚打的成本很高,还是建立在学习能力足够强的基础上。

而产品设计或者项目跟进的工作,可不像写代码一样,调试时就会报错,甚至还会告诉你怎么改。产品经理的工作你可能做了一年,成果有好有坏,但你很可能不能发现原因,也不知道好的怎么保持、不好的怎么改正。

所以明明通过别的途径能少走弯路,却偏偏要靠自己撞墙来学习,这是不合理的。

关于技能和方法

确实没有通用的技能、工具和制度,比如有的团队喜欢 Axure,有的就喜欢 Keynote。有的喜欢把文档按照交互逻辑整理,有的喜欢按照功能逻辑整理。大公司讲究格式和流程,小团队追求效率。

这只是说浅层次的,在深层次的概念和方法论,却不仅可以算是通用的,简直要说是必备的。

比如刚刚说的用户体验中可用性的原则,再比如用户体验的五大要素(层次分类方法不一样,但道理都相通)。还有大致有几种图片排列方式啊、有哪些注册登录方法啊......这些海量的知识,如果不去有针对性地学习,很可能需要自己折腾几个月搞明白一个地方的做法后,才发现在知乎上别人已经答过了,看一眼就全明白。

前人的经验在这个方面显得特别重要。

关于软实力

逻辑能力、沟通能力等等,都确实是产品经理要具备的。但这些能力反而更需要系统去学习。

从逻辑方面来说,有的是能应用于日常生活中的逻辑科普书籍,讲社交和沟通的更多。其他的能力比如管理能力、组织协调能力,也都是成熟的大企业已经总结过成熟的方法论的。

这些仅靠个人领悟,不知道多久才能悟到书里能达到的水平。

关于变化

我在读很多书时看到例子觉得老,就有点嫌弃了。估计大家都有这种感受。书的出版周期很长,所以时效性难免差一些,不过主要是指例子。

在读了很多关于互联网、创业和产品的书之后,我深刻感觉到,除了例子很老,绝大多数的方法论、道理和逻辑,都是不会过时的。

这简直打开了新世界的大门。我翻了很多出版三五年,甚至七八年的书,发现现在遇到的问题居然都能得到解答。Web 时代的很多分析,用在移动互联网只是在实现层面有差别,在底层逻辑上完全一致。这也是为什么《用户体验要素》是差不多上个世纪的作品,过了 15 年仍然是产品经理们的必读书籍。

就拿《启示录》举例子吧。这是 2008 年的一本书,但关于产品设计的内容,到 8 年后的现在都是适用的。

比如很多朋友会问我的问题:『外包团队靠谱吗?有什么问题?』

书里提到(作者把外包成为定制):

长久以来,开发定制软件困难重重......虽然需求存在,但客户通常不知道自己想要什么......等到交付软件时,客户往往发现到手的软件和想象中的相差十万八千里,于是又要求开发人员修改,如此恶性循环,客户屡屡失望而归。

定制软件的客户认为自己了解自己的需求,所以不需要什么产品经理,他们也不需要用户体验设计师......客户不理解什么是用户体验,以及对成本过于敏感(让开发人员设计产品可以节约成本)。

是不是特别眼熟?

换句话说,这就是现在到处问『开发个 APP 到底多少钱呀?』『我让外包做的产品怎么不满意呢?』的土老板们遇到的问题。

他们既不理解为什么需要产品经理和设计师(不就是放几个按钮、画几个图标吗?),也不理解为什么外包团队总是做不满意(告诉他们大概的样子,实现不就行了吗?)。

我见过的所有的,真的是所有的,外包团队的作品,都会遇到这样的问题。

我再摘录几段话,看看是不是感觉特别有道理、特别眼熟。是的,这些在我之前的答案中都出现过。

许多产品团队没有意识到,或者很晚才意识到要转变工作重心。更糟糕的是,产品经理还时不时冒出新点子;公司高管认为产品文档还可以继续修改,导致开发要求大幅变更,严重影响开发团队工作。结果不是发布日期一推再推,就是某些功能被迫取消,或者产品质量下滑。

这段话说的就是我提过的『产品经理不仅要想点子,还要保证产品的实现』。

在我看来,每当团队内出现严重的意见分歧时,并非是大家对事实的认定有争议,而是对目标和目标的优先级有不同的理解。

这是我提过的『有争执时讲道理都可以解决问题,除非大家价值判断不同』。

我无法想象不深入理解用户需求,特别是在禁止与用户面对面交流的情况下,产品经理怎样打造出让用户满意的产品。

这是我提过的『任何事情都看用户的需求,做判断,而不是主观上做太多自以为是的设计』。

目前流行的研发模式通常是这样的:创业者想到一个好点子,得到启动资金后,马上招聘程序员开发产品。由于创始人最清楚要做什么,因此,他通常会扮演产品经理和产品设计师的角色。开发团队则按照他的想法实现产品。这些创业公司一般在『秘密状态』下运行,很少与用户互动。另外,由于产品需求和创意往往边做边变化,开发进度相对较慢。

这里面同时提到了创业中『创始人会兼任产品经理』、『创业过程中太过频繁改动需求』和『创业者过于关注自己的点子的保密性』的问题。难以想象,08 年美国就流行的事情,在如今的中关村和望京 SOHO 重新上演。

我看书的时候边看边拍大腿,一是因为说的太有道理了跟我想的一样一样的,二是妈蛋为什么没有早多些读书。

7. 『程序员总是会讨厌产品经理。』

不管怎么讨好程序员,他们总会讨厌你的,不用太担心是不是自己做得太差。协作中尽量公正就好啦。

具体原因?还用说吗。参见第一条。

希望能帮到你。


CIO之家 www.ciozj.com 公众号:imciow
关联的文档
也许您喜欢