caoz谈能力成长 - 取舍之道

俞军老师说过特经典的一句话，优秀的产品经理，要学会做减法。

我们设计产品的时候，创业者，说真的，点子都很多，把设计，计划书拿出来一看，我产品这样这样，然后这样这样，以后还可以拓展为这样这样，聊天的时候突然灵光一现，对啊，我还可以把这个加上去。等等等等。

那，下面是个对比范例

用户真的需要这么多么？

很多时候，我们被自己创造的各种伪需求所麻醉，大家谈东西的时候往往流于自己的才能展示而忽略了事务的本质，比如说，公众号起名这个事情，很多人都有各种奇思妙想而忘记了最基本的诉求，容易识别和容易传播，所以很多特别有想法的名字其实识别度非常低，特别是一些认为用了谐音很有才华的那种名字，最不容易被人传播，因为大部分用户基于第一感都会输入错误。 这就是创业者以及很多工作者最容易犯的错误，想太多，而忽视了最基本的东西。

那么，做产品设计的时候，我们要不断问自己一些问题。

用户的核心诉求是什么，这个功能点设计是否满足用户的核心诉求？

如果没有这个功能会怎样，用户还会不会使用这个产品？

想明白这俩问题，可能80%的功能都是没必要的，当然你说锦上添花好不好，请别一上来就搞，时间成本是最大的成本，相信我，很多你以为精妙的设计可能毫无意义。

谈完产品谈用户

前几天说了，你做一个新项目，一个创业公司，你要知道一点，不可能讨好所有用户，苹果公司够大吧，人家都压根没打算讨好所有人，对不起，我就不出998人民币的特价款，买不起的选安卓去吧。 所以，即便有些需求是用户定义的，有些痛点是用户提出的，你也要甄别一下，这是不是你核心目标用户的需求，这是不是你核心目标用户的痛点。 有时候，你甚至要为了让某些用户更满意，而伤害另一批用户，这个决定你敢不敢做！有没有价值！

我的观点是，如果为了发展更多的用户而伤害核心用户，是得不偿失的，很多公司犯过这样的错误；而为了核心用户去伤害一些其他用户，很多时候是正确的，你不能指望面面俱到，让每个人都满意。

举个例子，有人跟我说要做高端社交平台，想法是通过一些社交平台让普通人也能参加高端社交场合，这需求听上去很不错啊，普通人也想去高端场所，参与高端活动啊，找一些资源以廉价的方式提供给普通人的一些参与方案。但我一听就玩意就不行，啥叫高端社交，你搞这个你认识门卫保安或者举办方，你几个人私下靠关系凑进去了也就算了，你想规模化商业化，你开毛玩笑，这玩意一旦规模起来高端社交肯定变味，高端用户一定会极大反感，最后一定是高端用户见你就躲，高端活动唯恐跟你发生关系，你剩下一批普通用户自娱自乐么？你以为取悦了更多人，高端社交强调的是什么，私密性！准入门槛！

理解核心用户的诉求，理解核心产品诉求，再来理解项目管理。

说个小公司，项目快启动的一种思考方式。

我跟员工说，能不能启动个啥项目，员工说，这个，需要做什么什么，什么什么，什么什么，工作量蛮大的，算算大概6个月吧。我说3个月我要它上线，别跟我说工作量多大，按照3个月上线给我做排期，也不难为你，你说的那些，不一定都要做，你自己研究一下，非核心的都扔后面去，做到哪些最基本的就能上线了。然后我们拉出来测试调整。后来员工一直给不出3个月的排期，好吧，我自己也有些无能，这个项目就不了了之了。但我说句心里话，要是搁十年前，这事我一个人，最多两个月就上线了。（2005年，cnzz第一个版本的所有核心代码，其实就我一个人写了两周你们信不信。当然，那啥，写的时候有一些早期积累。不过所谓的早期积累也是不到一个月的工作量。当然，那时候的版本和现在相比，其实功能挺单薄的。）

什么思路呢，就是你先排工期，基于工期去优化产品设计，决定取舍，不追求说第一个版本的完美度，但是追求效率，并且保证核心功能在第一个版本都能充分体现，线上再根据反馈快速迭代。 大部分公司的研发都是先定需求后定工期，如果你先定工期后定需求，你会发现，其实很多东西并不是非做不可的。

这个思路历史上是来自日本的精益生产，在80年代的时候，made in japan以廉价质优产品快速打入北美，攻陷欧美市场，那时候日本厂家如何思考的呢，北美和欧洲都是我琢磨一个产品要做什么，然后计算成本，然后按照利润率，计算售价，然后标价出去卖。日本人把这个颠覆掉了，我要打败你，我先计算这个东西我准备卖多少钱，然后计算利润率，回推成本，然后我设计这个产品，我基于这个成本去做，没用的我砍掉，能裁剪的都裁剪，但保留强大的核心功能不能比你差，然后做出来产品，比对手便宜30%-50%，一下子把美国厂商打蒙了。这是成本反推的设计思路，在互联网时代，时间成本是最大的成本，所以，我们要以工期来反推设计，裁剪需求。

下面说技术的取舍之道

因为我做过统计，对这个比较熟，有个朋友当时要做个统计系统，他们员工做了几个月还没搞定，我就过去瞅瞅，一瞅就发现问题了，啥问题呢？为了根本不存在的需求较劲呢。

我们在做技术的时候，有时候产品给出的需求，只是一个使用说明，对于一些边界条件并不明确，而边界条件这玩意，对技术设计的复杂度和开发难度影响极大，极大，极大，极大。

实际上，技术人员应该明白应用场景的边界在哪里，有针对性的取舍，这样技术方案就可以变得简单，研发成本就会极大降低。

案例说话

无论是百度，谷歌，还是阿里，你去搜索的时候，你都不可能靠翻页遍历所有结果，翻到一定页数，就不给翻了，这就是边界条件。如果程序员非要较劲给出所有搜索结果的查询和排序，这就要命了，谷歌都做不到。　而潜台词是，其实真正的用户并不关心也不太会翻到七八十页去找结果。除非搜索结果很少才需要遍历，搜索结果很多的情况下给出权值最高的top列表即可，至于所有满足搜索条件的数字，其实只是一个系统估算值，根本没有去遍历搜索。

再拿统计说事，比如你是一个网站的站长，你要看网站的来源

如果这个来源是你特定的广告载体，你可以标注出来单独统计。

如果不是，你会去关心超过top 200的来源么？真的不会，站长只会关注最前面带给自己流量的网站和网页，不会关心一些奇怪的只有一两个点击的那些奇怪的来源，所以，站长不关心的数据，系统需要保存么？

理解这个思路，很多开发就简单了，至少你技术有限的情况下可以把很多看上去很复杂的项目搞定了。

允许不完美，允许设置一些边界条件，一定范围内降低准确度，存储量，来减少复杂度，这样开发效率就会极大提升，开发成本就会极大下降。

这个现象有多普遍呢？根据我的观察，开发人员做无用功，为不存在的需求而打拼的非常非常普遍，而这可能是很多公司老板，主管都不清楚的隐形成本。

再说典型场景，比如一些排名服务，你排第二，第三，第五，当然名次都很重要，但是你排50251,50252,50255,　这个具体数字对你重要么？告诉你排在50000-51000之间是不是就可以了？　很多技术设计如果稍微变通一下，复杂度就会极大降低。

2004年做一统，2005年做cnzz，我的开发时间都特别短，当然产品问题也不少，但没阻碍它们先后成为中国互联网统计平台的no.1。这事我做过总结，那时候我的技术水平实在不咋样，当然现在也没好太多，能做的快，而且在当时市场上表现力还不错，并不是因为我技术有多好，而是因为懂得取舍。这一点是很多大公司的程序员的盲区，所以他们用了几十倍甚至上百倍的代价，做同样的东西。

简单总结

１，从产品层面，对需求做裁剪，好的产品经理要会做减法，点子多，但落实起来，要围绕核心，初期不要过于复杂，有需要可以上线后根据用户反馈迭代。

２, 从用户层面，不要试图讨好所有人，要明确核心用户群体的诉求，有所取舍，让一部分人惊喜，另一部分人离开，比平庸四处讨巧的产品可能更好。很多优秀的互联网产品，都很固执和执拗，他们潜台词就是，不喜欢我的用户，我其实也不打算服务你们。

3，从技术层面，要理解需求，基于需求和研发的的难点设计边界条件，将需求简化，在满足用户核心诉求的前提下允许一定程度的不完美，允许一定程度的不精确。这样对研发效率的提升和运维成本的下降是惊人的。

一个不懂得取舍的系统，往往里面90％的数据和信息是在需求层面毫无意义的，有机会我会找一些案例出来，这样的真的见过很多。