为什么说完美主义的产品理念背后有个天坑？

                                                完美主义，这是初级产品经理，特别是有追求的初级产品经理必走的弯路，而且这条弯路背后还潜藏着硕大的一个天坑！

那些年我走过的弯路之——完美主义
完美主义，这是初级产品经理，特别是有追求的初级产品经理必走的弯路，而且这条弯路背后还潜藏着硕大的一个天坑！火山刚开始做产品的时候就走过不少这样的弯路，也顺道挖了好多坑，今天来跟大家分享一个我之前做过的真实的产品案例。
火山所在的公司是一家专门为票务代理人提供自动化业务系统的创业公司，打造的是一款基于SaaS的toB类产品。差不多3年前，也就是在我刚开始做产品的时候，我接到了这样一个需求：
需求名称：订单拦截
需求来源：上海xx客票代理服务公司
提出人：我公司x销售同事
需求描述：
虽然我们系统可以实现没有人工干预的自动出票（票源来自我们系统自动推荐的供应商），但是利润空间有限，而我们的客户大多本身有自己稳定的出票渠道，而且他们某些产品利润空间比我们提供的更大，为保证利润最大化，在用户前台下单后，系统需要将订单进行拦截（即不走自动出票的流程），经线下与固有渠道比对好利润之后，人工确定是否通过我们系统出我们推荐的供应商的票。
这就是大致的需求背景，看到这里，请各位看官先别着急往下看，设想一下假设你是接收到这个需求的产品经理，你将会如何设计产品以实现这个用户需求？
思考一分钟，计时开始……

犹记得当时我刚做产品不到1年的时间，为了提升自己在产品方面的专业素养，我看了很多书有关产品的书籍，对产品的用户体验无比在意，有着强烈的完美主义倾向，做任何的产品功能，功能体验都会抠得很细，提高用户体验是我做产品的无上法则，什么边边角角都尽可能地考虑周全，这个项目自然也不例外。
闲话休烦，我们言归正传，回来继续说这个项目。接到这个需求之后，我首先做的事情就是穷尽我有限的脑洞，对需求可能的用户场景进行了无限详尽的分析，除了最基本也是最重要的下单流程相关变更之外，在订单拦截设置上，我设想还存在以下几种用户场景：
场景1：首先，订单拦截需要可控，客户可以决定是否要做拦截，因此，需要一个订单拦截的开关，可以打开和关闭订单拦截功能；

场景2：订单拦截开启时，需要考虑一天之中的时间，客户白天有人守着的时候，订单拦截开启，下了班，或者中午吃饭的时候，没有客服在电脑跟前时，有可能会忘记关闭订单拦截，这个时候订单拦截需要自动关闭，走自动出票的流程；

场景3：不同的客户上下班时间不一样，因此，需要支持不同的客户按照不同的时间来设定拦截；场景4： 周一~周五上下班时间固定，周末值班，时间可能会跟平时不一样，因此，需要支持按照工作日和周末拦截时段的区别设置；

场景5：如果遇到平日是法定节假日，客服的上下班时间可能会不一样，因此需要支持按照个性化的时间段进行订单拦截；

场景6：有些热门机票库存有时候会非常紧张，订单拦截之后由于有时间延迟，最后想再去从我们平台自动出票的时候，可能票已经没有了，因此为了优先保证出票，需要设定一个阈值，当余票数量低于5张时，订单拦截不生效；

场景7：不同的客户对这个阈值可能会有不同的设定，不一定每家都设定5张，因此需要支持不同的公司设定不同的阈值；

场景8：订单拦截后，如果超过半个小时订单没有做任何处理，有可能是客服来不及处理或者没有注意到，为保证客户出行，如果检测到超过半小时没有出票时，系统需要触发自动出票流程；

场景9：不同的客户可能对自动处理的时间会有不同的要求，因此需要支持时间上的自定义；

场景10：春节等个别特殊时段，没有客服值班，所有的订单需要走自动出票流程，订单拦截不生效；

基于以上这些应用场景，关于订单拦截设置模块的功能，经过差不多1个多星期的产品设计调整和反复优化，（请忽略新手的效率问题）我做出了一个产品Demo，效果如下图所示：

这个产品设计几乎“完美”地解决了上述所有的应用场景需求，也成功亮瞎了销售同事的钛合金g眼。而后，提交开发时，开发小伙伴却颇有微词，表示这里面的逻辑太多，实现起来难度比较大，但在我耐心的解释和坚持之下，最终还是顺利地推进了开发。现在回想起来，我依稀记得当时我被自己缜密的思维，周全地考虑感动得不行不行的样子。
终于，经过开发小伙伴差不多一个多月的开发，产品基本成型，在内部测试的阶段，客户来我们公司拜访，我就得意洋洋地给客户做了详细的产品展示和培训。一番讲解之后，客户似乎并不买账，同时还提出了不少疑问：
[ol]

需要拦截的指定时段与周期a\b同时勾选时可能存在时间上的重叠，重叠之后以哪个为准；

拦截时段与不拦截时段如果出现重叠，是拦还是不拦？

既然本身就有拦截开关，那为何在拦截设置里面又要设置例外条件？订单拦截开启时，又遇到了不做拦截订单，到底是拦还是不拦？
[/ol]
我花了10几分钟的时间，给客户解答这个订单拦截的逻辑，最后发现不仅没帮客户把问题解释清楚，反而连自己都被绕进去了。在这个时候，我已经意识到：无论我最后能否帮客户培训清楚这个功能，这都已经注定将是一个失败的产品设计，而最直接的表现就是——学习成本太高，没有几个用户有那么好的耐性愿意花那么长时间去研究你的功能怎么使用的。如果进一步上升到理论高度来说，就是我的产品设计已经违背了“Don’t make me think”的产品设计黄金法则。
之后，经过与客户的深入交流，了解到客户其实只是需要一个简单的订单拦截功能，需要拦截的时候手动打开，不需要拦截的时候就手动关闭就可以了。换句话说，我费劲心思所做的那些产品设计在真正的用户手里已经被判了死刑！
自己所作出的投入虽然白费，虽然没有得到用户的认可，但毕竟是自己掰石头砸了自己的脚，终究是谁也怨不了；可是对于本身前期就颇有微词，而现在又不得不毁掉自己亲手码出来的开发GG那边……你能想象我当时心里的忐忑吗？
正所谓“自己挖的坑，含着泪也得填完”。为了降低开发GG的不满，我 生生“编造”了好一通凿凿之辞：由于这个功能现阶段还不稳定，加之用户需要时间适应，因此，这个项目中的所有设置里面的相关功能均作为高级设置，在后期迭代的版本中根据用户的需求我们再逐步放开……费了九牛二虎之力，好说歹说，开发GG终于答应了把分时段、分周期、特殊情况不拦截等等功能逻辑先全部注释掉。最终，我们交付了如下一个订单拦截的功能：

实际的应用场景就是，用户需要拦截的时候打开，不需要的订单拦截就时候关闭可以了。真正完美地解决了用户的实际需求，也不需要用户去思考。
后来，两年多的时间过去了，随着时间的推移，我们的客户增长了10几倍，订单业务量上涨了几十倍。所有新老客户都一直用着两年前我所设计的订单拦截功能打理着他们的实际业务，而当初我所设想的哪些用户场景几乎从来就没有客户再提起过，而我“天才般”设计的那些所谓 “完美”的高级功能沉睡在开发GG的代码行里，从来也没有再醒来过……
做一个项目，我不仅把自己给坑了，成功地坑了开发，坑了测试，进而也坑了公司（资源浪费）。所以，现在你明白为什么我说完美主义对于产品经理而言是一条弯路了吧。
如今三年过去了，重新审视三年前自己做过的这个项目，感触良多，今天我想尝试对这个项目做一次复盘，反思一下自己当年都犯了哪些错误。看到这里，想必各位看官对这个案例也会有自己的一些看法。我们不妨再暂停一下，思考一下发生在火山身上的这个案例是否有带给你某些启发？
思考一分钟，计时开始……

火山复盘：
在这个项目中，火山至少犯了两个严重的错误：脱离用户、完美主义。前者是产品经理圈子里常见的一种错误，而这种错误对于产品经理而言往往又是非常严重乃至于是致命的，但由于与本文的主题不相匹配，因此在本文中我就不再展开分析，我会在后期专门撰文分析，今天我着重分析一下后者，即——完美主义。
完美主义最大的表现就是抓小丢大，死抠细节，不放过任何一个应（bian）用（bian）场（jiao）景（jiao）。我在这个项目中就是这样一种表现，总希望自己做出来的产品可以适应各种各样的场景，满足用户方方面面的需求。其实这样做产品很累，而且效率也会很低，但即便如此，依然总有无数的产品经理在这条道路上前赴后继……
我不由得想到了一句歌词：是我想得太多，犹如飞蛾扑火那么冲动……
产品经理追求完美本无可厚非，而且我们周围用过的很多神一样存在的产品，例如微信、苹果等等背后都有这么一个理念，也正因为他们追求完美的理念，才让我们得以用到那么棒的产品。但凡事过犹不及，把握好度很重要，如果在资源并不充足的情况下，就过份主张完美主义的产品理念，做任何的项目都那么在意这些边边角角的细节的话，这将非常影响产品的节奏。如果一个产品团队都是秉持着这样一种理念，它对于唯快不破的互联网公司，特别是资源本就非常匮乏的创业公司来说负面影响是非常非常大的，不信，我们来算一笔账就很清楚了。
在这个项目中，我作为产品经理，为了实现这个客户需求，花了3周左右的做需求，其中1个多星期就是在做上述的那些边边角角的需求，开发GG花了5周左右的时间开发，测试花了2周左右的时间测试，也就是说这个项目总共花费工时：
产品+开发+测试=3+5+2=10周≈2.3月
这其中还没有计算需求评审占据的业务、开发和测试的时间，测试研读PRD，写测试用例的时间以及最终产品跟踪、业务内部培训、外部解答的时间。最终，实践证明我所有那些追求完美的设想在很长一段时间内都是多余的，也就是说所有基于案例中所提到的应用场景做出的设计和开发都是不必要的，至少在很长一段时间内是不必要的，而如果去除这部分需求，粗略估计整个项目的工期可以缩短一个月，即节约1人月的工时。如果一个公司有10个人的产品团队，每人每月做1个这样的项目，那么1年下来浪费的人力是多少呢？
1人x1个项目x1个月浪费工时x10人x12个月=120人月
按照人均人力成本12k计算，全年共浪费人力成本：
120×12000=144万/年
换句话说，1年下来，一个10人左右的完美主义产品团队无形之中就给一个公司造成了144万的成本浪费。是不是有一种不算不知道，一算吓一跳的感觉？
而完美主义带来的负面影响远不止这种资金成本上的损失，因为这些是可估量得出的；这背后更大更恶劣的影响还在于时间上的损耗，因为120人月（10人年）的另外一种含义是，一年下来团队里面少了10个人的产出，而这个数字还是建立在10个人的基数上测算的，假设你公司的产品团队有30人，50人乃至于更多，可以想象一下，在这个天下武功唯快不破的年代，少了30、50个人的团队对一家互联网公司的影响会有多大，完美主义的产品理念背后潜藏着多大的一个天坑……
回到开头的话题，为什么说完美主义是初级产品经理必走的弯路？选择做产品经理的人大多都是比较有想法的，都希望自己生的“孩子”长得更好看一点，技能更多一点。而刚开始做产品的时候，但凡有追求的产品经理，肯定各种产品经理相关的书籍资料恶补，而在产品经理所能涉猎到的诸如张小龙、马化腾、周鸿祎、雷布斯等产品大咖总结的产品方法论当中，用户体验是相对而言最容意感知得到也最好被理解的，因此，无数初级产品经理就将打造完美用户体验作为了产品道路上的一个信条也就不奇怪了。所以，现在你知道为什么我说有追求的产品经理最容易走上完美主义这条弯路了吧？
那么，有没有办法可以控制或者避免自己的完美主义倾向呢？答案是：有！那就是——抓大放小，基于主应用场景设计产品。
后记：不久前，我作为初创团队的一员，怀着感伤离开了待了3年的创业公司。要问我在一家创业公司做三年产品经理有多少收获，我只能说实在太多太多，这些收获不仅仅局限于技术流的产品硬技能强化，如流程图、原型图、PRD等，更多的是对于意识流的产品软技能提升，这其中就包含了沟通协调、产品规划、产品方法论等等。而无论硬技能还是软技能，最深刻的感悟永远都是从自己挖过的坑或者走过的弯路中收获的。我将会在接下来的一段时间里，我会由浅入深地把我的这些收获和感悟进行总结并与大家进行分享，希望可以给在产品经理道路上打拼的同仁们一点点启发。