训练产品思维
Haijun - 2014/11/11
就像每个人对「互联网思维」都有不一样的理解，「产品思维」作为抽象的存在，自然也没有一个标准的定义。不过这个词被提及的多了，说明不同公司对做产品的章法重视程度在加强。
我理解的「产品思维」，约等同于一些人所说的「产品感觉」，是作为产品经理在分析生活、工作中的问题时，都能够同时从设计者的初衷、不同人群在不同场景下的体验两个角度去想问题。
有效的修炼方式，是设身处地将某一行业的所有产品研究透彻，从纵深的流程、到横向的对比，整个过程辅以辩证的逻辑推演、品味判断，得到一个综合的结果。
跟实际做产品一样，「产品思维」的养成过程需要长期刻意的训练积累，很难「速成」。它一般是从产品分析和分解着手，难点有二：一是做到真正的「设身处地」，让自己进入「傻瓜模式」去理解设计者的意图，知其精华和糟粕所在；二是从熟悉的产品开始，逐个分析，形成自己的思考框架和套路。前者更考验一个产品经理的全面能力。
绝大部分人都是从自己日常使用的产品着手。但「新人」应尽量避免一上来就分析微信、QQ、淘宝、微博等「世界级产品」，这些产品已经成功，要去分析它们所满足的多样用户需求和价值，需要观察者站到更高，难度大了则易一叶障目，最后流于表面，只是产生了一些 Comments 而不能形成 Insights。选择一些规模中等，在某个行业做到有口皆碑的产品会更好，比如下厨房、豆瓣的一部分产品、美柚、Instagram、same、Path 等好多好多可以选的。
选好标的后，通过产品价值及人群的分解、信息架构、使用流程、产品核心机制（杠杆）等方面去想。我是做社区的，就以我比较熟悉的「豆瓣小组」产品为例，来展开一下。
– 基础产品形态：BBS 集群。BBS 的优劣势有哪些？
– 话题内容来源：UGC
– 小组来源：用户自行创建
– 小组管理：众包给组长和管理员。他们的动力是什么？
– 单个小组的粒度：由于完全用户自行创建，优劣势是什么？
– 小组生命周期：如何解决组长放手不管的情况？
– 内部竞争：同一主题的多个小组之间如何竞争？
– 产品价值：BBS 提供的产品价值非常多样的，拆解来看，每个产品价值背后都有无数的小组，如：结交朋友、寻求同好、排解寂寞、表达观点(论坛)、展现自我寻求认同、社团、俱乐部、答疑解惑、媒体、标签符号、树洞、发现未知的世界…
– 不同产品价值对应的小组，其人群规模和频次有何差异？
– 为了支撑这些价值，平台提供了哪些对应的「功能」设计？
– 小组内排序方式：沿用 BBS 的机制
– 内容分发与传播：小组首页Feed、豆瓣广播、书影音关联、浏览发现、外部SNS分享等，哪一个是产品最核心？
– 内容贡献者：动力是什么？在不同小组里，他们分别是一群什么样的人？
– 内容消费者：消费内容的场景，及价值是什么？
– 种子用户：早期用户如何来的？
– 人群过滤：如何有效地让正确的人去正确的小组？
– 生态系统：豆瓣小组是如何防止整体衰落的？如何维系用户的生命周期？（月度覆盖独立用户超过8000万）
– 品牌：人们是如何对豆瓣系产品形成「小清新」「文艺」等印象的？有哪些重要的影响因素？对于新用户如何使用产品又有什么影响？
– 移动化：小组的移动化做得如何，其策略是什么？
– 机会：小组在移动上有哪些新的机会？
– 横向对比：豆瓣小组与百度贴吧、单个BBS最核心的三个差异点是什么？
理解了什么问题才是影响产品的杠杆，才知道 UI 上是不是够「漂亮」有多大的问题。
一部分答案在持续使用中会得到，另一些答案可能在社会心理学的书本之中。能发现有些问题豆瓣解决的也不好，这是分析竞品最重要的价值之一。同样是社区，如果要分析另外一个产品，问题列表也会有一些差异。因此最佳的契机是研究者本来就是一个热爱泡社区、在社区中能收获快乐的产品经理。
随着对一个产品的深入使用，框架就会饱满起来，加上持续的跟踪观察（我觉得需要至少三年），量变会催生质变。而在 2014 年这样的时间点上，同一类产品在将来和过去的变化差异，就需要同时有所关注。比如社区，从 PC 时代到移动时代，场景和体验发生了巨大变化，而产品形态未必，能看到不少移动社区还是在沿用 BBS 这个最古老的形态。
既然是说一种思维，看起来也就务虚多一些。务实一点来说，「产品思维」是思考和观察层面的事情，一定程度上能为下层具体的产品设计、产品运营提供 Insights 和判断支持，它在不同类型产品中所能起到的作用也不一样。
有的放矢抠细节
Haijun - 2014/06/10
前同事设计师 Sophie 在 blog 上问「抠不影响成败的细节有必要吗」，事隔 7 日，从 Reeder 过去评论了几句。
实际上，在绝大多数情况下，这位工程师说得对，对成果毫无影响。在多数产品难以「创新」的情况下，很多互联网产品的「设计」整体作用都是被高估的。
但就像 Sophie 所说，这在以前合作过的工程师里却是少见的，前端工程师甚至会跟设计师一起抠细节。我猜测她说的是豆瓣。这是公司产品文化的具体体现，非常难得，对于设计师来说亦是运气。
在现在的公司里，产品和设计师（这两个职位二合一）被强调要尽可能去做 impact 足够大的事情，不纠缠细节。但几个月下来，总有一些细节问题不忍直视。这对于老板是处女座，注重产品设计的公司，是无法容忍的事情。于是每半年抽出一周时间，主题就是「查漏补缺」，公司上下所有人一起挑产品细节问题。一个字的文案、一个象素的对齐、一点点的色差，都可以被揪出来，集结成册，并尽量控制在一个工程师 0.5-1 天能解决的范围，鼓励数量越多越好。称之为 Polish Week。
Polish Week 最早来自于 Asana 在 2012 年的一篇 blog。
When we work on a mission and product as ambitious as Asana, it’s important to spend most of our energy on bold changes. However, we recognize that the finer details of a product are what bring delight to our users, so we built in time this episode to spend a week doing only product polish.
利用整周时间，工程师都用来 Polish。公司会将工程师分组，解决问题最多并通过 QA 验收的小组，会得到一些实物奖品。最近一次的奖品是一台 Segway，这两天总发现办公室总有人踩着这台家伙到处窜。
红绿灯的流量优化
Haijun - 2014/06/08
发现很多时候的路面拥堵，直接原因是车道和红绿灯设计的不合理。
比如之前在酒仙桥上班的时候，下班晚高峰从酒仙桥上机场高速，那是一个「丫」字形路口，首先需要左转。交管部门显然预知到了从南向西北方向的车流量巨大，所以设计了三条左转道。相比于巨大的车流，左转红绿灯的时间却很短，导致每次都要等上很多个红绿灯交替，才能过去。
另一个例子是在中关村东路与知春路的交叉口，自北向南，一共四条车道，两道左转，一道直行，一道直行加右转。在几乎 100% 的情况下，左转道都没有什么车，而右边两个道则排起了长队，加上最右道共用，使得右转也需等待。
交管部门在城市里安装了数以万计的摄像头，而实际却很难为这样的效率优化服务，根本原因是数据采集和处理能力有限。如果按照互联网的思考方式，运营部门针对第一种情况应该根据车流量调整左转绿灯的时长，使得「丫」字路口的整体流量趋于平衡；针对第二种情况调整车道配置，只需保留一个左转道，即可缓解排队及右转问题。
换个思路，从大众消费品的角度，汽车联网，上述问题或许是个应用场景。