记一件有意义的事（1）

大约一个月之前，我和另外四个小伙伴在学校外面租了一个民居，开启了一段新的旅程，用时髦的话说“创业”。五个人当中，主要由我来负责产品相关的决策，其他四个小伙伴负责代码、设计相关的事务。

这一个月下来，最大的感受是，做一个需要推给公众的“产品”的感觉，和原来在学校里头做“产品”的感觉有很大的不同。我们只做了一个非常小的事情（先容我保密吧^_），但却有很多状况和之前预想的并不一样。为了履行之前的小小承诺，今天聊两个最近印象比较深刻的事情。

0

之前在学校里头做产品，很多时候目的性并不强。好奇、兴趣、锻炼自己的能力、甚至无聊，都可能是开一个新坑的原因。所以，实际上，很多时候思考的东西并不多。

但是离开学校去完成一件名叫“创业”的事情，使人在心态上有了许多不同。因为有了更大的责任和自我期望，你会花比以往多得多的时间去考虑现在正在做的这件事情。一般认为，有更多时间对某一件事进行思考，会有带来更多地好处——无论从深度、广度、角度。

然而，其实也未必。现在回过头来看，这种由于心态的转变带来的“思考”是一把并不有情的双刃剑，如果掌握不好，就会了结了自己。举两个例子，说明一下遇到的一些状况。

1

例子一：一个工具类产品的产品经理发现APP的活跃度并不高（本身属于高频次需求，不应该那么低），通过一系列的思考，发现如果集成一个社区功能会有效提高活跃度，并且一些第三方的数据也印证了这一点。于是将这个Feature尽快加入了开发列表。请问这样做有什么问题？

这位产品经理并没有理解，用户数和活跃度是支撑社群的关键。如果在自身的核心功能还没有完善的时候，加上社群相关的Feature，并不是一个理性的决定。如果用户发现你给的和自己想象的并不一样，那么下次你用力去推进这件事情的结果很可能是招至更多的反感。

无论怎么看，他都会认为自己做了一件正确的事情。唯一的错误就是，时机不当。产品根本就还没有到这个阶段。所以说，“产品是有生命的”其实是一件非常深刻的话。

但是，即便你掌握了很多方法，很有可能你还是不能够很好地做出选择。

为什么？回到例子一，再想一想，增加社区功能会有效提高活跃度对于产品经理的诱惑到底有多大？还会去考虑这种增长是短期的还是长期的吗？作为一个现实中的产品经理，你可能被上司的KPI压着走，也可能向我一样，在某一个创业团队中位于关键位置，在这样的情境下，还能够做出正确的决定吗？

很多时候，因为利益的存在，可能会乱了自己的阵脚，忽略产品生命阶段做决策。这也解释了为什么拥有那么多优秀产品经理的大公司也会做出那么多奇葩的产品来了吧。当然，因为利益而忽略产品阶段的错误都算小的了……

所以这是我需要提醒自己的第一件事情，不要操之过急。更加不要因为利益操之过急。据说腾讯内部有一个说法是“基于需求做产品，而不是基于战略做产品”，真是无比赞同了。

2

例子二：作为一个满脑子都在思考怎么让自己的产品变得更好的人，常常会冒出一些奇怪的想法，仿佛每一个都能够给产品带来新的增长点。这些功能往往并不重，觉得加上去也没啥大关系。于是迫不及待地找到开发团队满心换新地说，我们立马加上这个功能吧！

请问这有什么问题？

如果稍有常识，就知道这么做不是什么科学的做法。因为几乎一定会带来这些问题：

1）开发压力变大，周期边长
2）开发团队的吐槽
3）其他人会对决策是否足够经过思考表示质疑
4）后面遇到更好的idea没法插入（因为时间总归是有限的）

上面这些问题可能是别人评价一个产品经理是“傻逼”的最直接原因了。原以为犯这样的错误的年纪已经一去不复返了，但是因为那些奇怪的责任感，或者说不适应，好像最近这些问题有点抬头。但是面对每天冒出来的那么多的小想法，总不能丢着不管吧？在一番摸索之后，终于找到了有效的管理它们的小方法了。

请容我先卖个关子，暂且不表。

我们先来说另外一件事。作为一个Web2.0遗老、用RSS大概都有七年的人来说，必然逃脱不了的一件事就是信息过载。不管我怎么控制订阅源的质量，阅读器总会喊出一个让我觉得hold不住的数字。

我原来也对此束手无策，直到养成了一个习惯：每天打开阅读器，对每一个标题进行一次阅读，如果标题中有足够的信息量或者其他什么打动我的东西的话，我就会将他们在新标签打开。然后继续阅读订阅器中的标题列表，如此重复，直到把未读杀到零为止，然后，再去看继续去仔细看之前打开来的那些页面。

可能，你还并不能察觉到这比平时那样一篇篇地看有什么实质性的好处。但是实际上是有的，而理解这一点的关键就在于“阅读一篇文章”和“选择是否阅读一篇文章”实际上是两种不一样的思考方式。前者是要求理解和吸收，需要的是不被任何其他事情干扰的“流体验”，而后者的目的是评估和决策。两种思考方式交替使用会使得阅读时候需要的“流体验”遭到破坏，而同时，专注选择的时候也可以更加有效和准确，更能够选择出那些最应该被读的东西。

看到这里可能明白了，我们应该如何面对那些灵光一闪的“好想法”呢？和读阅读器中的内容类似，我现在的习惯是，每次都记下来（是的，我非常珍视他们），然后每周将他们重新评估一次，之后再挑选其中最重要的给开发。这样的好处是：

1）并不会错过什么好想法
2）统一评估是时候，更容易看出哪些想法是最好的，将精力投入在这些最重要的店上面。
3）保证了开发团队的“流体验”，不会被突然的需求打断。

改进有效！

在《思考，快与慢》这本书中提出来两个专门的词汇来描述这两种不同的思维方式：“窄框架”和“宽框架”。所谓“窄框架”就是遇到一个东西做一次决策，“宽框架”是把所有的东西都摆在一起集中起来选择。作者告诉我们，使用宽框架在很多时候是比窄框架更加理性的做法，我们应当掌握这种思维模式。BTW，这是一本不错的书，可以找来读一读。

所以，还是先按捺住自己内心汹涌的洪流吧——也许后面有更大的……