—— BEGIN ——

产品经理被喷通常来自两个方面：第一来自企业外部，也就是用户；第二来自企业内部，你的小伙伴。

用户喷你是因为产品的用户体验太垃圾；小伙伴喷你是因为你不是一个合格的产品经理。

所以问题来了：

用户体验真的不重要？

这貌似是一个老生常谈的话题，但还是要谈。

经常浏览产品相关话题的同学可能会看到过这样的对话：

可以看出：相对于用户体验，他们更看重盈利模式（商业模式）。

对于这样的人，我通常只能送他几个英文字母：WQNMLGB。

盈利是我们应该考虑的，但是在考虑盈利之前，要先考虑产品能给用户带来多大价值。

在给用户创造价值之前，我们首先要考虑的，应该是产品的用户体验。

没人相信垃圾的用户体验可以带来稳定的用户，没有用户的商业模式就是空中楼阁。

我们分别从软件体验、硬件体验两个维度来分别讨论用户体验的重要性。

一、软件用户体验

微信、网易云音乐、滴滴

京东、网易严选、简书

以上几个APP是在我手机里躺着的时间比较长的几个APP，它们有一个相似之处：穿上的衣服再没换过。

（注：此处只谈论用户体验，运营的相关问题不在此讨论）。

恰恰相反，与上述产品形成鲜明对比的，是那些频繁给产品换衣服的。

而发生了这种行为的，通常都是——产品经理有病。

病在哪里？说好听点是迷茫，不好听就是无知。

他们通常又通常喜欢给自己找一些借口和理由。比如：移动互联网时代，就是要快，小步快跑，试错迭代，大佬的话，总没错吧？

大公司可以试，没家底的小公司多试几次就试没了。

他们可能会觉得人家做的好看所以我也要试试，人家能做我也可以做；人家做出来了那我就照搬过来，不顾是否符合自己产品的使用场景和业务逻辑；总之，抄人家的总没错。

所以，我要频繁的给产品换衣服，反正我觉得好看、实用，用户肯定也会觉得好看、实用，我是在帮助用户。

这些就是90%的互联网产品现状。

而最最要命的，是你在频繁的版本迭代中，频繁的给产品换衣服——先是衣服的颜色换来换去，接着是样式，然后拉锁换成了扣子，索性不要扣子，改成套头的，接下来把外面的口袋放到了内里，顺便又给口袋加了扣子。

用户更新完后就气的骂娘了：我本来拉锁用的舒舒服服的，你偏偏给我换成了系扣的；我双手习惯插在上衣外口袋里，你偏偏给我弄没了，我手往哪放？

好不容易培养起来的用户习惯让你生生的给掰折了，而你还在沾沾自喜。

只能恭喜你，你又成功的祸害了一款产品。

所以对于用户来说，一个功能的所在位置无论在哪，只要它对用户来说是重要的，有价值的，用户都可以找到它，你所做的就是不断优化它，而不是给它不断的挪位置、变样子。

别做功能产品经理，多去研究竞品，研究你的用户，研究人。

二、硬件用户体验

每个人都有自己喜爱的硬件产品，今天我来说一个最不起眼的——插排。

我们分别对比3种插排，看这些插排有哪些异同。

1. 第1种插排

这种插排没有开关，插排通电后即可使用，简单易用。

但没有开关意味着什么？就是说如果你是一个有安全意识的人，为了消除安全隐患，在你出门之前，你就要把家里所有插排断电(冰箱等除外,不要在意这些细节)，出门回来再把所有插排通电。

你每天都要将插头拔下来然后再插回去，时间久了你自己都烦。

2. 第2种插排

开关有了。至少对于我来说，上述（1）中声明的问题在这里得到了解决，我不需要每天来回插拔插头，只需要按一下开关，省力省事，在一定程度上替我解决了安全隐患。

它仅仅比第1种插排多了一个开关按钮。

3. 第3种插排

（2）的优点它也有。但它在常规的二孔、三孔插口之外，又为我提供了USB插口，方便我用数据线为手机充电。

这样，即使手机充电线的插头丢了也不影响我充电，或者，我可以把充电线的插头一直插在床头的插座上。

这种插排设计的好处是：

1. 近几年手机在生活中扮演的角色越来越重要，几乎成为了身体的一部分，甚至超过了电脑和电视，在插排上提供USB插孔，符合趋势。而且，你还可以畅想一下，手机的无线充电离我们的生活越来越近，未来各厂商协定好通用的无线充电协议或者突破无线充电的技术屏障之后，插排也可以提供无线充电功能。毕竟，插排本来就承担了电力输送的任务。那共享充电宝还有意义吗？

2. 不管是有意还是无意，它都满足了我诸多种生活场景。

3种插排比较完毕，至少在我看来，从比较的次序上来看，插排的用户体验越来越好；意料之外，情理之中的设计初步显现。

随着电子产品的日益更新，插排或许会突破传统，承载更多的用电需求。

我会选择用户体验更好的那个插排。而这个插排仅仅是多了一种插孔和一个按钮。

所以，用户体验很重要。

如何达到良好的用户体验？

• 从空间上为用户提供达到目标的最优路径。

• 从时间上为用户尽快解决问题。

怎样做好产品经理，至少不被喷？

产品经理们往往只注重提升自己的硬实力，却容易忽视提升软技能。

经理们不止要和开发撕，还要和设计撕，和运营撕，见谁撕谁，于是就有了矛盾。

矛盾产生原因1：需求自我矛盾

我们可以看到产品经理在版本1.0中提出一个A需求，在版本2.0中就会对A需求推翻重做或做出比较重大的更改。

当程序员问他为什么要改时，回答往往是当时考虑的不够充分；现在考虑充分了，你改吧，下个版本不改了。

果不其然，下个版本又改了。

其实他一直都没有考虑充分，因为没有数据做支持，他自己也弄不清用户的行为习惯；需求的产生一切靠臆想，不断对过去的自己进行自我否定同时也会让团队的伙伴对你的能力产生怀疑。

所以，与其投入不少时间和资源浪费在那些鸡肋功能上，不如将这些资源投入到一些有意义的事情上。

比如开发一套数据采集和埋点系统，不用一步到位，也可以逐步升级这套系统，这是很有必要的，采集用户行为记录进而辅助产品决策，是做新功能还是优化老功能，做到有的放矢。

这样，在你下次提出产品需求，只要有数据做支撑，有理有据，团队的成员都会给予理解和支持。

矛盾产生原因2：工作流程未形成真正的闭环

其中，产品最主要撕逼的对象是开发，而开发不止要和产品撕，还要和设计撕。

为什么？

肯定是产品和设计给开发挖坑了。

开发的工作容易量化，开发阶段收尾提测后，通过每个开发的bug数量就能量化这个开发的产出。

而在很多企业，产品设计部门的产出都体现在KPI上，比如新版本投放后带来多少流量，提高多少购买转化率，唯独没有量化团队内部协作产出。

所以造成的一种结果就是：

（1）设计部门出的设计稿，看起来没问题但实际有问题。比如没充分考虑到机型适配问题，导致的结果是开发在开发阶段需要和你调试这些问题，耽误若干个小时，进而延误其他功能模块的开发进度。

再比如在需求评审阶段没和开发没沟通好UE问题，导致在开发阶段或提测阶段插入一些额外的UE需求，导致项目交付延期。

（2）产品部门出的PRD，看起来没问题实际上也有问题。这个问题就多了，最多的应该是功能使用场景考虑的不够全面，以及新旧版本的功能兼容性问题。

举个二者兼有的例子：

一个电商项目，前期是销售自营商品，为了丰富商品品类，在后期接入了第三方电商平台的商品（比如京东、严选等）；由此造成的问题是：旧有的收货地址和第三方电商平台的收货地址形成冲突。这种冲突体现的使用场景还不少，比如填写订单页、填写收货地址页等等。

如果上述这些问题不能在需求评审阶段找出来进而带到开发中，造成的后果就是在开发阶段撕逼，并且造成项目的延期交付、上线。

因为产品设计部门在工作中造成的疏忽，最终都转换到了开发部门的头上，由开发部门去消化，最重要的是产品设计部门还意识不到这样的问题，一而再再而三的继续疏忽，开发部门自然不能容忍。

所以，怎么解决？

设计部门内部形成设计规范文档，产品部门内部形成产品规范文档。

规范文档形成的初期阶段（不完善阶段），在需求评审会议上，由开发按照业务流程和产品、设计挨个页面挨个过，每个细节都要过——虽然这样的会议可能会消耗很长的时间，但当规范文档成熟起来后，会议时间就会缩短，好处是提前扫清开发障碍，将问题解决在摇篮中。

并且，产品也可以将一个大版本的功能拆分成几个小版本，小步快跑，不断迭代。

当开发、产品、设计部门都同意规范内容后，就严格按照规范来执行，除非是重大问题（P2及以上）或紧急需求可以在开发阶段/提测阶段插入进来，其余都可以挪到下一个版本中进行迭代。

如果你觉得什么功能都重要，那其实什么功能都不重要。

在这个过程中，规范的其实是产品、设计者的协作规范。

矛盾产生原因3：团队内部缺少沟通

我们经常看到的是产品会将一个功能改来改去，开发不厌其烦。

其实开发烦的不是改来改去，而是看不到改来改去的目的在哪，像个无头苍蝇撞来撞去。

所以开发提出新需求时，最好注明提出这个新需求的来源是哪里，目的是什么，追求什么样的结果，新需求开发完投入到市场后，根据采集到的数据来决定下一步的措施。

小到一个需求，大到一个版本迭代，团队内部（产品、运营、开发、设计）都应该明确刚才的3点：

1. 需求来源

2. 目的

3. 结果

不要认为开发只是一群码代码的、远离需求就不进行沟通，缺少沟通就会产生缝隙，小问题最终会酝酿成大问题，制造团队矛盾。

还是那句话，只要结果是积极正向的，团队成员无论多累就会觉得值得。

总结

产品经理是一个需要用心去做的职业，我们不但要拥有绝对的硬实力，从时间和空间上的不断优化为用户提供一个实用的产品。

更要推进团队协作效率，协作效率的提升可以让产品经理的工作事半功倍，也可以让产品实现快速迭代。

—— END ——