在设计产品时，人们每天都要应对各种各样、层出不穷的需求，有些来自外部用户的反馈，有些来自内部精英团队的想法，这些都是产品和新功能的bug.

好像所有的需求都维持住了，产品就会越来越强，然后吸引大量的用户，然后赚大钱，然后招大量的人，然后产生大量的需求…

问题是，需求是会不断进来的，人不可能完全消灭所有的需求，996也做不完，一辈子都不可能。

人能做的就是继续对需求进行排序，保留优先级最高的需求。问题是，人们应该如何对需求进行排序？

面向用户，明确优先级

是张小龙。教人做产品的人没有一亿。因此，人们应该更多地与用户沟通，优先考虑用户的需求：

当用户给出反馈或者嘲讽的时候，要小心，要更深层次的交谈，并做好记录修复bug，改进或者增加角色，积极联系非常感兴趣的用户，他们会让你给出大量反馈按时做用户调查，用心倾听沉默的大多数对用户指出的需求说了什么，按照反馈用户数量，危害类别，难度系数等级排序。

你做产品的时候，你创造出来的冲动是非常震撼的。会有一些新的想法。我们在一起很开心，希望明天就能放了他们。但人要克服自己的创造欲，重视用户的建议。人家的产品是给客户的，不是给自己的。

在总流量收入已经很稀缺的时期，获得一个新用户比吸引一个老用户要难得多，所以提高用户粘性显得非常重要。关注每一个用户的反馈，发现bug立即修复，优先维护用户意愿，才是最合理的提高用户粘性的方法，没有一个是这样的。

BUG优先于新角色。

墨菲定律是这样的：

任何会出错的事情。

程应该都知道如何编写没有bug的代码。那时候只有人没有发现，或者知道但没有马上修复。

众所周知，现在的产品的bug通常是非常容易被忽略的。会不会是BUG隐藏的太深，人和用户都没有发现；用户会发现BUG，但是没有反馈；也会是人的选择性失明，问题不大。

其实用户对产品质量的规定是非常严格的，哪怕是最小的问题也会发现并嘲讽。人们仍然可以了解用户的反馈，否则如果没有网络监控，人们会发现BUG为时已晚。

还有一种相互的情况。当用户反馈看似不太可能的bug时，人们会本能地觉得产品应该没有问题，问题应该是用户的电脑浏览器或者互联网，或者某种奇怪的原因造成的。其实只是大家在逃避问题。编码的操作方法很清晰，没有什么不能表达的。如果出了问题，多半是bug。以下是人们的亲身经历：

据一位用户反馈，他在邀请团队成员加入时，发现有时邀请不成功。

人们查过网络监控的统计数据，发现曾经有过一些不成功的案例，受害的不仅仅是一个用户，而是极少数。

随后，人们检查了前后左右两端代码，发现没有问题。