产品观
2014-11-18
做产品就是发掘需求和解决需求的过程。对需求发掘的越准确，对需求解决的越有效，那么这个产品的价值就越大。
产品观
1、如何做产品
- 1）形成一套产品理念。这套理念所要传达的是在做产品时发掘需求和解决需求的过程中遵循的原则和思维方式。产品理念能够使产品的决策方向保持长期一致，提高决策效率。
- 2）基于产品理念去做产品。在这一套理念下去发掘需求和解决需求。
- 3）实战检验和完善理念。在涉及理念的细节上去做不同的设计并统计用户数据，把数据作为参考工具，不要盲从。在这个基础上追索产品决策失败或成功的真实原因，逆向思考并改进产品的理念。
2、为更好地发掘需求，做一个「懂人性」的产品人
- 懂人性，就意味着能够穿透功能列表去寻求其背后所代表的用户的「心理诉求」。
- 懂人性，就意味着能够去除杂音去倾听用户在「应用场景下的痛点」。
3、为更好地解决需求，做一个「懂技术」的产品人
- 懂技术，并不意味着比开发人员更能写代码，而是更明白一项技术能用来做什么。
- 懂技术，就意味着能更好地理解开发人员，懂得他们的难处和痛处，那么在工作中沟通起来就更顺畅。
- 懂技术，就意味着能在产品设计的阶段根据某些功能的可行性和实现成本来做到合理取舍。
4、看清趋势：一个有价值的产品越来越倾向于「技术和数据」的洪流与「人本精神」的双向对接，而不是前者向后者的单向倾泻。
- 随着技术的发展和数据的爆发，很多产品人思考的问题是如何把用技术和数据组建的服务
PUSH给用户，这种呈现的方式往往是一种自上而下的、无节制的、压迫式的倾泻。因为，我们在这里常常克制不住欲望，想要“给予”用户更多的数据、更全面的功能，去试图讨好所有人，却忘了从用户的感受出发去思考「给的数据是不是太多造成了噪音」、「给的功能是不是太多造成了迷茫」。 - 随着移动互联网不断地发展，用户的体验意识不断觉醒。所谓「人本精神」即更加重视个人的价值和尊严，更加重视用户对产品的体验和掌控。在产品中应该站在用户的角度去自下而上地思考，去和我们能够提供的技术和数据进行对接，从而提供有节制的、直击痛点的数据和功能。
产品设计
发掘需求
1、需求不是简单的功能列表，需求本质上是用户的心理诉求。
比如：漂流瓶是满足倾诉，好奇的心理诉求。这是一个心理驱动的范例。如果为做交友而做漂流瓶，就会把握不到本质。
2、站在用户的角度，用同理心去感受他们的需求。
站在用户的角度做产品就是要用同理心去理解对方，在此基础上去唤醒对方「内在的主动性」，这需要用自下而上的体会去抓住用户的痛点，进而制定方案，而不应该是自上而下的强压、强推。
3、需求只来自于你对用户的了解，不要从同类产品里找需求。
需求是满足人们的人性需要，所以要不断地探索和理解人性，从而理解用户。从别人的产品中，你只能看到功能，你无法深刻地理解需求。
4、大部分新功能是可以砍掉的。
要学会问用户最不希望要什么功能，而不是总是问用户最希望要什么功能。
5、时尚是驱动力。
人是跟风的，「因为别人都在用，所以我也要试试」。不要太工具化。从微博等其他媒体上体会用户潮流，了解用户的场景、感受。忽略评论家的意见。
6、满足自己的需求优于满足用户的需求。
你无法理解每个人，你无法满足海量个体的个性需求，所以从自身出发去捕捉大众需求，而人同此心。
7、从调研获得需求是骗人的。
从大量反馈看出需求是骗人的，从数据统计看出需求更是骗人的。用户反馈能帮助完善体验，但不会告诉你要做什么新东西。
不要去问用户你觉得我怎么做会比较好，因为他不知道，或者只是他以为他知道。比如很多用户使用任务管理软件时，主动设置很多任务，并且都加上了提醒，当用户主动加提醒时觉得自己想要被提醒，但当每天都被提醒 n 次时就开始烦了，关掉提醒甚至直接删除这个 App。
8、在产品中满足用户「掌控一切」的心理需要。
所谓掌控一切的心理需要就是用户在使用你的产品做一件事的时候：
- 1）不迷茫（比如：下一步的动作指向明确，用户的某一个操作所产生的结果与他的预想是一致的；比如：产品的功能分类和布局合理，符合认知逻辑。）
- 2）不害怕（比如：数据不会出人意料丢失、程序的使用逻辑不会有去无回或贸然进入意料之外的地方）
- 3）不被打扰（比如：我要做A事情，其间不会插入乱七八糟的1、2、3事情）。
做产品的时候是要把用户当成白痴（所以我们要把交互做的简洁、易于理解），但是要注意的是不要让你的产品显得用户很白痴（所以我们不能让交互产生模糊和歧义而诱使用户犯错或者让用户不明白到底发生着什么，不能因为我们的某些目的而去迫使用户去干什么）。
「简洁的功能分类和布局」 + 「线性的使用逻辑 」是很好的策略。 简洁的功能分类和布局，即将整个产品的所有功能归纳为尽可能少的几个类别，在这种简洁的分类下去布局功能的入口。 线性的使用逻辑，即从哪里来就回哪里去，而不是网状式任意跳来跳去的使用逻辑。有时为了快捷，可以在一条逻辑线上做一个返回的快捷跳跃，但是也需要慎重。 值得一提的是这种策略不仅便于用户理解，而且对开发人员来讲也是很友好的，由于逻辑简洁清晰，开发人员能更好地规划其实现方式。
比如：微信的朋友圈是一个很重要的内容入口，但是微信并没有因为它重要就把它放到了顶级（比如作为TabBar的某一项），而是从整个产品的全局来考虑，把它归入了「发现」这个类别。这样虽然增加了用户进入朋友圈的步骤，但是一切却是自然而然、合乎逻辑，这样就易于用户掌控。
9、「心理满足」的驱动力远胜于工具甚至省钱。
比如：如果把微信定义为省钱的短信替代工具是不会成功。微信不是QQ，微信不只是一个通信工具，微信是互联网蔓延到移动端后的一种生活方式，反映的是心理满足至上。
10、寻找产品的「群体效应」。
比如：附近的人不是为了陌生人交友，是为了好奇心。为了满足用户心中对「他们会发生什么？」的好奇。它是有群体效应的。每个人在观察别人，也在被观察。他们第一次在显示中大规模互相看到。
11、在强调金钱逻辑与分配规则的环境中，人们会更倾向于在与他人的竞争、制衡甚至相互打压中实现个人利益的最大化（个人利益不但包括钱，还包括老子一定要爽）；反之，一旦切换到一个没有金钱诉求及利益冲突的非盈利环境中，人会变得慷慨、开放、无私。在环境成员的相互影响与作用下，彼此的慷慨与无私还将进一步被激发。
12、不一定按数据说话，按用户需求和价值说话。
案例：小视频拍摄入口有两个：一个是微信页面下拉发小视频，另一个是朋友圈右上角加号发小视频，使用频率：朋友圈右上角加号占 95%，微信页面下拉只占了 5%。如果按数据说话应该干掉这个入口，那为什么没干掉？因为我们不是完全按数据说话的产品，更重视用户体验：主界面快捷方式对于要拍摄稍纵即逝的瞬间，需要最短路径马上拍摄，如果撤掉，当遇到非常好瞬间要拍摄的时候，拍摄路径太长会导致错过很多好的瞬间，并且这些稍纵即逝的瞬间的内容价值可能远高于慢慢从固定路径录制的内容价值。
13、价值信息最大化。
文字、图片、URL、视频哪个性价比最高，哪个信息量最大？URL 信息量最大，图片性价比最高，视频的信息量很大但性价比最低。
微信里体现价值信息最大化原则案例：
- 朋友圈点赞没有头像。
- 小视频自动播放。
- URL 的弱化。
- 文字太长时折叠。
- 单图vs多图：单图缩略图很大，最高效率，不用点开大图也可以看清楚，而多图的时候会变成小的缩略图，这时候接收方的诉求是要第一时间知道这九张图核心要说的信息是什么，点开大图再看具体内容。
14、不同很易，更好很难。
案例：新浪微博做的Watch 版 App 的功能是跑步记步功能，但微博属于信息类的，做个计步器和微博有啥关系，无法体现产品核心价值；所以最后还是选择把收发消息，看朋友圈，赞等基础核心功能发上去，做实用性的东西比做帅气不同的东西更有价值，不为创新而创新，不为不同而不同。
案例：为什么要做小视频？1.视频信息含量是最高的，是文字和图片无法比拟的；2.有些场景是很难用文字描述的，视频可以解决。做小视频而不是大视频是因为大视频信息量很大，收看时间长，信息价值不高，所以用 6 秒小视频来做到既有信息量，又保证信息价值。反例是 QQ 空间，空间一直有长视频，看到微信出了短视频，也把自己的长视频改成短视频，结果被用户投诉的要死，这就是产品经理没有想清楚自己的产品定位，一味模仿追随，空间最擅长的是沉淀，长视频是最好的沉淀形式之一，更别说空间还有 PC 阅读特性等差别。不同很易，更好很难。
15、真实的内容才有生命力，噱头往往是对信息的破坏。
案例：美拍等视频拍摄工具都有配音，加特效等功能，美化后让整个视频变的很好看，但微信不会做这些，因为美化后的视频，去掉了声音等，无法还原给朋友传递信息的真实现场。真实性还体现在微信的所有数据，各种对外的方式都秉持真实性。
16、不要从目标倒推方案。
比如我们要 50 万用户，那倒推要三件事分别引流 10 万、20 万、20 万，按此方式可能会达到 KPI 目标，但很可能会背离你设计这个产品的初衷，用手段而不是产品功能达到目标，这不是真的解决问题的方法。
案例：提升海外活跃度：发现当用户好友数超过 15 个时，活跃度会增加很多；所以当时的做法是引导加好友，然后又引导加陌生人，好友数还不够，就改版附近的人，这种就是按目标倒推数据方案的反例。
数据可以帮助你了解原因，但不会告诉你原因。一个不知道其原因的成功决策，比一个失败决策还危险。
17、AB test 可以用来对比效果，而不是选择方案。
AB test 用的越多，表明产品经理判断力越弱。使用 AB test 时要有很明确的选择，并且知道影响因素是不可控的。
解决需求
1、在起始时弱化自我定制的设计性的开发，优先功能场景性的开发。
能用标准方法／标准控件解决问题就不要用特殊处理。保持 UI 和设计贴近苹果是一个很好的策略。
什么是设计性开发？比如，在苹果提供的平均大小的TabBar的中间放一个凸起的圆形Tab来凸显这块的重要性；比如，把苹果标准的NavigationBar的做的更花哨等等。
为什么弱化自我定制的设计性开发？因为苹果的 UI 设计已经很优秀，保持与苹果一致的 UI 可以提供 iOS 平台一致性的体验，用户已经在这种一致性的体验中受到了足够的训练，所以他们会更快熟悉你的界面。此外，自我定制的设计是不稳定的，会因为自己不同时候的感受不同就发生变化，这点体现在设计工作上就是会不断产生修改UI设计的需求，这会给产品人员和开发人员带来很大的负担，并且这个负担的真实价值不明显。当弱化了设计性开发后，就能有更多的时间和精力进行功能场景性开发，从而提供更好用的、更优秀的功能，捕捉更有价值的应用场景。
当产品的功能性开发到达某一定程度时，可以迭代回来做更加细致的设计性开发，提升细节体验。比如：加载时的小动画；页面切换时精细合理的切换效果；按钮点击时的反馈效果等等。
2、只抓主场景，不做全功能。
做大而全很容易，做少却很难，因为什么都往大袋子里装很简单，但是甄别哪些是可以剔除不要的很难。如果没有化繁为简的能力，就克制自己做多的欲望，而做多通常源于不自信。
抓大场景，忽略小场景，非重要特性就放在设置里，而放在设置里不如不做。
比如：微信朋友圈只能发照片，发140字的难度远胜一张图片。
3、先做产品结构，再谈功能细节。
产品结构是骨骼，不可多变和复杂。创作从骨骼开始，而不是先造肌肉。
比如：微信的产品结构。
4、设计就是分类。
分类是人类大脑的识别模式，分类是化繁为简的方法之一。PM每天都应思考如何让事情更有条理。
比如：微信保证只有四个底部tab。
5、面向场景来做设计而非功能列表。
不堆砌功能。功能服务于场景和整体体验，没有孤立的功能。
6、避免战略行为替代真实需求。
- 避免“打通”。需要打通，说明不是需求。
- 避免“整合”。需要整合，说明都不行了。
- 避免“拉动”。需要拉动，说明是KPI了。
- 避免“导入”。需要导入，说明没生命力。
- 避免“多平台”。不为平台而平台。
- 避免“全面”。全面的东西是平庸的。
7、收缩一个页面的信息维度，保持简洁。不同维度的信息可以相互勾连住，但不要相互破坏。
比如：一个基于话题的社区，话题列表页面A->某话题下所有用户发表内容页面B。
在话题列表页面，主要内容是话题的属性，这是维度A的信息。那么点击一个话题，进入这个话题后，是用户在这个话题下发表的内容，这是维度B的信息。
页面A中，我们可以展示一部分维度B的信息，比如在某一个话题的TableViewCell的右边AccessoryView中显示该话题最近一条信息的icon；但是不能因为要展示更多的维度B中的信息而改变页面A某一个话题的页面布局以至于影响到其他条话题的展示。
例子：红点是一种最简单的一个维度到另一个维度信息的hook方式。
比如：微信的微信Tab对应的页面会用TableView显示一行行会话记录，比如你跟小明、小红、小刚的聊天都各自是一行，在这每一行的subtext里会显示最后一句聊天记录，这样不会破坏这个页面的布局，但是能让这个维度的信息和下一个维度的信息hook住。
比如：微信朋友圈的TableViewCell会在朋友圈有新消息的时候，在该Cell的AccessoryView中显示最新消息用户的icon。
8、世界在变化，世界是新的。
忘记过去的数据甚至经验，对当前和未来趋势的洞察才重要。
比如：PC上的入口在搜索框，手机上的入口在二维码 。
比如：小屏手机点按手势很好用，大屏手机滑动手势变得重要，因为点按不再那么便捷。
9、做人人都爱用的产品。
产品面前，人人平等。不要把产品做的低龄化（卡通、萌？）、女性化（粉色？）、男性化……
10、让功能存在于无形之中，出现在合适之时。
让新版看不出有变化，只有新手才迫不及待想要将所有新功能罗列在显眼的地方。
比如：微信餐饮商家插件不可见，扫描才有。
比如：翻译功能，只当选中某个单词时才出现。
11、极简方式能不被超越。
但是要记住：「简约不是少，而是没有多余；足够也不是多，而是刚好你在。」—高圆圆女神的结婚婚贴上如是说。
比如：微信摇一摇。
比如：iPhone的指纹解锁和指纹支付。
12、尊重用户。
保护用户隐私（通讯录上传要经过同意，LBS暴露位置要告知）。不诱导用户。在每个体验点上以用户为重。
比如：在所有的正文编辑处，加上crash后的内容保护。
比如：系统邮件，采用真实的产品经理签名，而非机器思维的“系统管理员”。
13、宁愿损失功能也不损失体验。
比如：不为了流量而到处加入口。
14、不过度设计。
做得越多可能错得越多。对主干精雕细琢，对枝叶不做深。
15、「隐私」重要性大于「便利」。
案例：微信登陆网页版或者换一台设备后的聊天记录都是从零开始。这是因为当别人登陆你的微信时，很可能就是通过网页版登陆或是在其他设备上登陆，这时隐私泄漏给你带来的风险比聊天记录清零带来的伤害大得多。
16、「接收方」体验的重要性高于「发送方」。
追求保护双方的感受，但是当有冲突时，优先保护接收方的感受。
案例：微信到现在也没做信息已读的功能。
案例：白底黑字比绿底黑字更清楚，所以微信用白底黑字展示给好友发来的信息，而自己发出的信息自己本来就清楚，所以用绿底黑字。
案例：为什么短视频不支持自拍功能？自拍需求大多是女生的需求，这让自拍的人挺爽，但试想一下当朋友圈被各种妹子的自拍占领，就一个头，还会动，对于接收方而言，其实看的没那么爽。
17、缺乏价值支撑的流量，事倍功半。
大多数产品的思路还是引流、拉下载、框用户。流量是 1000 万有 1% 的用户转化，就有 10万 真实用户，所以不断找流量，但实际上大部分流量都被浪费掉了。如果，我们将思路放在转化率的提升上，或许 100 万流量就能达到 10 万用户了。
18、对用户而言固定路径是最近路径。
案例：为什么不让最近发送的表情在最前的位置？原因是每次发表情都会改变表情顺序，每次打开表情顺序都被改动，反而会延长找到想要表情的时间，觉得表情不好用。最快的路径永远是固定的路径。
19、线性原则优于逻辑原则。
如果你有两个 tab 的话，就会有一个主 tab，按已有的数据显示 2 个 tab 会二八分配，80% 的流量在主 tab，只剩下 20% 的流量到第二个 tab。如果你已经能决定哪个 tab 是核心，那为什么还需要第二个 tab，如果你没办法决定哪个最重要，那分 tab 也没办法为你决定，还是会二八分流，专注主要功能，把所有流量聚焦在一个 tab，不作无谓分流。不用多 tab 展示，一个地方不要两个按钮。
在逻辑原理和线性原则相冲突的时候，优先线性原则。
案例：微信的搜索原本是放在顶上加号旁边放一个放大镜的 icon，但最后还是把搜索框直接加在聊天记录顶部的搜索框，而不是右上角放 “加号” 和 “搜索” 两个 icon。
产品管理
1、 尽早发布，Done is better than perfect。
早发布意味着你有更多的机会，而机会意味着一切。早发布才可能有一个足够好的时间窗口，更快的发现想法中错误的部分，摸清并梳理好用户真正的需求。有些时候产品经理甚至是整个团队其实是闭门造车，即使你收集到了足够多的用户数据，梳理之后觉得把握住了用户的痛点，但实际却往往是相反的，你所理解的痛点可能并不是用户真正的「痛点」，不过是隔靴搔痒罢了。
不需要等到产品完美再发布。完美的产品如果没人用，没资格称之为完美。
2、 如果没有自然增长就不必推广。
硬导入用户，只会给用户留下坏印象，以后再也不来了。KPI是好产品的副产品，不为KPI而改变产品。
3、 节奏最有力量。
团队最好能保持自己固定的工作节奏，不要搞疲劳战，不要搞无意义的消耗战。更不要看同业产品有什么功能就跟进去做什么功能，跟着别人亦步亦趋，自己节奏会先乱掉。
控制好节奏，意味着一个团队各个环节应该衔接好。产品做的不错，那么运营就必须要跟上，运营一旦能跟上，服务也要跟上…
4、 内容本身也是产品。
如果产品的功能做的不够好，那就不如把产品里的内容先做好，内容要比 App 更容易传播。内容本身就是产品，内容本身就是功能。
如果是起步中的团队，你大多数情况下不需要花很多精力去做网站，不需要去找外包做一个根本没几个人用的 App，写几篇好文章传播效应更广。微信微博就是很好的传播平台，你为什么不好好利用? 在任何一个地方能够取得优势的话，都可以提升你的产品覆盖能力，漏斗效应你总知道的吧?
5、 不要做体外循环式的运营。
有些团队看了各种病毒营销的案例，也去有样学样，比如拍个视频之类的，希望能通过 SNS 传播开来，基本上不会有多大作用。即使是大型互联网公司做这个也做不来，成功的案例非常少。
之所以说这些是「体外循环」，原因也简单，跟你的核心业务没什么关系。举个例子，桔子水晶酒店以前搞的那个「十二星座」微电影，就是典型的体外循环，对企业推广品牌的价值并没那么大。尽管他们不会承认。再比如，一些创业团队到处参加各种创业大赛，基本上也是在消耗自己有限的资源。如果你想曝光，只需要一两次就行了，热衷于参加这些活动，而且还需要公司资源去配合，对你的团队究竟有多大帮助 ?
6、 多思考，少开会。
如果你想少开会，那你就要平时多思考。不要停下对产品的思考，当你思考的足够多，你就能知道应该怎么做。
少开会不意味着少沟通，把你的想法记录下来，见缝插针的跟团队成员做异步的信息交流。这样应该够用了。
7、 任何产品都要能第一时间收集统计数据。
产品关键指标的统计，在产品开发过程中就应该埋好点，要求能够第一时间统计到。如果能够做到近乎实时统计，当然更好。
统计数据也是功能。给团队成员使用的功能。没有地图，军队怎么作战? 没有数据，多数时候没办法做有效的分析。没有数据，又怎么支撑你的结论?