这是《微信背后的产品观》读书笔记第四篇。前面三篇是张小龙对用户、需求、设计的理解，这里回看：
1）关于用户，张小龙说了这11个核心观点
2）收藏：关于需求，张小龙的16个核心观点 (附PDF下载)
3）关于产品设计，张小龙有话说，字字珠玑（上）
《微信背后的产品观》书中内容，源于张小龙内部8小时的演讲，在这次演讲中，他把自己15年来关于产品的所有经验和心得一次性全部公开。
本书内容共分为5部分，分别是用户篇、需求篇、设计篇、气质篇、UI篇。
「设计篇」内容很多，这里分为上、中、下三部分整理。
如果你也想看180余页的《微信背后的产品观》PPT。关注我👇👇👇，回复「产品观」获取。
对于一个产品，我们更应该偏向产品本身还是运营？这没有绝对的衡量标准，这要看各家的特长和偏好了。而且对于不同类型的产品，也会有不同的侧重点。
很多开发的同事都知道，我们要做“类型”还是做一个一个“实例”？如果我们不是把各种订阅内容抽象为一个订阅平台的话，可能就会做了很多很多的“实例”出来，产品变得非常复杂。邮箱漂流瓶和微信漂流瓶有什么区别？邮箱里的漂流瓶有不同类型，有同城瓶、交友瓶，是一个个“实例”，偏运营多一些。微信漂流瓶只有一种。可以想象，邮箱漂流瓶因为用户需求类型增加就增加“实例”，这样做下来，会把大家累死。所以我倾向直接做到最本质的东西，至于他能满足用户什么需求，那是用户自己的行为。我们做一个“类型”，用户自己产生“实例”就可以了。也就是做高度抽象，而不是具体化。我们常常认为，发现用户的行为不太好，可以通过系统努力去“教育”或者“引导”用户，让用户符合我们的期望。但这不是好的办法。比如如何让微信新用户设置头像？可以注册时必须上传头像，比如当做任务奖励。但我们这样做。没有头像的用户，发送给好友的消息，是没有头像的。当用户发现自己没有头像时，很快就去设置了。这比引导用户去设置头像自然得多，这是用户自发的，不是被系统引导的。“摇一摇”是非常好的一种体验过程，这个体验过程包括了肢体动作、来福枪的声音、动画以及操作的结果，非常连贯。我们把这个功能已经做到了极简化，这种极简化的体验是很难被超越的。如果有一个东西已经做得非常非常少了，要更少是很困难的。当时支持的一个重要的理由是：我们将来的服务器会很稳定，网络状态也会越来越好，消息是必然会送达的。虽然说现在（指2011年）的网络状况不是很好，也会出现丢消息的情况，但是我们首先要考虑的是未来的情况，要根据未来的场景来设计。我们在做邮箱时思考，对于一个产品来说什么是好的体验？可能需要满足几个要求。比如“切入要准”、“功能设计得要好”。但是我们把速度单独列出来，“速度一定要快”，这个速度是指系统响应的速度。回顾邮箱能做起来，有两点是最重要的。第一是简单，第二是速度快。微信4.0的时候，点击进入一个会话群的响应速度是挺慢的，我们做了很多改进来保证进入速度得到提高。在微信的朋友圈里，我们的开发做了很多次重构，才保证了时间线的流畅体验，保证我们速度能超越所有有时间线的产品。虽然为了提升这里的速度，开发的代价很大，但是这样的代价是值得的。对于产品经理来说，这个特性本身不足够令人兴奋，让人产生热情的话，可能做了也做不好，也没办法理解这个特性还可以有哪些亮点或者别的什么更好的想法。好奇心是产品经理的驱动力，你不可能真正理解自己不感兴趣的需求。保留变化是围棋里的一句话，这在产品里面也是挺重要的。
在产品里面我们常常会把后面版本该做的事情放到前面去了，这会导致我们把1.0版本规划得非常完美，把2.0的东西给做了。比如web微信上线的时候，很多同事提意见说功能不全，为什么做了这么简单的功能就发布了？我们没办法一下子就做一个功能全面的东西出来，如果我们在做一个版本就做全面功能的话，一定是错误的。因为我们不可能一开始就想得那么细，只能一边做，一边看发布后用户有什么反馈，根据反馈再决定2.0应该做什么。也有用户提到，觉得微信的朋友圈很粗糙，连评论和回复都没有就发布了。当时并不是没有想到，只是觉得这些东西是可以放到以后再做的。不管是做邮箱还是做微信，我们都追求用户的“自然增长”。
微信在2011年5月才开始在邮箱里做推广在此之前，微信没有打任何广告，因为我们还没有看到自然增长的曲线，或者说增长得很慢，没有一个爆发点。当一个产品还没有到爆发点的时候去推广做广告，他的投入和收益是不太成比例的。好的产品应该是自然增长的，而不应该为KPI而改变产品。KPI这是一个好产品的副产品，好的产品自然会产生好的增长曲线。做产品可以保持一些粗放的状态。如果还没有好的解决方案，一定不要先去做。
因为我们的需求非常多，当没有想好方案或者没有想到方案会带来副作用，硬要去解决的话，可能会得不偿失，产生的副作用可能会远远大于正面作用。举一个案例，发错群消息。这个问题还挺普遍的，也挺难解决的。我们以前尝试过一个版本，把群聊的气泡变成蓝色（其他的是绿色），希望用户可以通过气泡的颜色来辨别群聊。但发现这种方案很难接受，用户接受了绿色气泡，就不是很能接受蓝色气泡。我们也不能在用户输入的时候提升用户：你正在群聊中，发消息请小心。所以我们先把问题放着了，放到后面想明白了，再去解决。有一次，一个能力很全面很厉害的开发同事在朋友圈抱怨：觉得微信的代码越来越复杂了，开始搞不定了。
我在后面给他写了一句评论：如果一个问题的解决方案太复杂，一定是问题本身错了，事实上就是这样的。比如为了解决视频通话里面多种状态切换的问题，里面的状态有点太多了。这时我们跳出技术方案反推回来，会发现可能我们的需求一开始就定义的不对。我们会发现有些应用很奇怪，在细节上出现一些难以理解的东西。比如微博的博文后面，会出现“来自iPhone客户端”、“来自iPad客户端”...之类的。这里我们一直没有想清楚，为什么“来自iPhone客户端”是值得显示的信息。虽然前面提到过要满足用户的“贪嗔痴”，这也是“贪嗔痴”的一部分。但是这些信息是没有含义的。所以我们不会搞一个“微信iPhone在线”这样的东西。
《微信背后的产品观》中「产品设计篇」篇幅很长，「设计篇」下的产品笔记，也将在今日发布，欢迎关注。
这里有一个180余页的《微信背后的产品观》PPT原始资料。