Delta值 (δ) ，指当标的资产价格发生变动时，期权价格的变化， 期权价格标的资产价格δ=Δ期权价格/Δ标的资产价格=∂f/∂S ，本质就是期权价格对标的资产价格的一阶偏导。（数学上的解释）
Delta值 (δ) ，指一个期权或期权的组合对标的资产价格变动的敏感性， 期权价格标的资产价格δ=Δ期权价格/Δ标的资产价格=∂f/∂S ，表明了一份期权空头的Delta和 Δ 份标的资产的Delta相互抵消，形成风险中性组合（也是Delta中性）。（金融学上的解释）
期权可以分为实值期权、虚值期权和平价期权，那么其和期权到期期限的关系可以表示
如上图是欧式看涨期权的情况，以到期日为例，由于合约到期，期权没有时间价值，对于实值期权中标的资产价格上升1元，所有的上升幅度都会体现在期权之中，所以Delta为1；对于虚值期权中标的资产价格无论上涨多少都无法增加期权的价值，所以Delta为0；平价期权则处于两者之间。看跌期权则相反。
1、关于模型
同一家管理人，其策略体系如果覆盖了指数增强、全市场选股、市场中性、灵活对冲、股票多空等，那么在选股端的模型是相同的，不存在不同策略使用不同模型。
在相同的策略框架下，做一些局部的调整就能构建出上述不同的策略。
核心模型是选股，传统的方法是对模型输入因子，输出股票组合；另一种端到端（神经网络）模型，输入的是数据，输出股票组合。
无论是哪种方式，具体的输出首先是一张打分表，将全市场的股票按照分数由高到低排列。
如果策略是指数增强，接下去就要按照对标的基准指数在行业和Barra风格上进行约束。
什么叫做约束？也就是将模型输出的组合，按照基准指数做调整，将每一个细项（风格、行业）的偏离（超过或者低于基准指数中的权重）控制在某个限度之内。
这个限度如何衡量？使用标准差SD，单项偏低超过0.5个SD之内的，叫做约束严格（最后的总偏离是单项偏离的加权平均）。控制在0.5~1个SD之间的也算是正常。如果在某一项，或者某几项的偏离很大，我胡乱举个例子在小市值上直接偏离100个SD，这就叫做暴露（小市值上）。
简单记忆：指数增强 = 量化选股 + 风格&行业约束
如果不想做约束可不可以？
可以。这样就完全按照模型选出来的股票去买。这个策略就叫做全市场选股。因为不对任何基准指数所包含的行业和风格进行约束，又叫做空气指增（对着空气约束 = 不约束）。
空气指增 = 量化选股 + 0约束
如果考虑到指数下跌，想要把beta下行的风险对冲掉。
这时可以选择两种方式：
第一种，通过做空股指期货（IF、IC、IM），这就是市场中性。
市场中性 = 量化选股 + 风格&行业约束 + 空股指期货，即指增附加一个股指期货的多头端。
在股指期货的选择和权重上还需要跟指增所对应的基准指数风格对应，但都会留出一部分风格上的暴露。
第二种，通过融券做空个股，这就是最近比较火的股票多空。
股票多空 = 量化选股 + 融券做空
这里是不需要去对照任何一个基准指数的风格的，而是需要根据空头端去匹配多头端。
2、为什么根据空头匹配多头？
目前看下来市场上主流的几家管理人的多空策略都是由空头端匹配多头端。
为什么？
因为空头融券是有稀缺性的，稀缺意味着在可得性上存在不确定性。
比如模型这批输出的排名几只AI票排在后列，但是对不起，融不到这几只个券，只能给你一些汽车的空头券。这时候你只能去调整多头端的建仓来匹配可得的空头券。
多头端一般不会出现买不到的情况。所以，从操作层面大部分是先确定空头端，然后根据空头来构建多头。
3、关于融券
融券分为场内和场外。
场内是主要方式，但限制比较多。
随借随还是一种业务话术，比如你借7天，可能才用了3天就要决定是否要续借。再比如卖出只能挂卖二，不能市价做空（卖一），这样就可能错过一些盘中的机会。
实际操作中这样的细节问题还有很多，这不是券商之间的优劣，而是场内融券机制如此。可以理解成现在没有高速公路，只有临时的水泥路。
场外券起步比场内晚，目前整个量比较小，但相比场内操作上更加灵活。
约券的顺序：融券T > 股票多空 > 实时券池
多空策略要看下单是T+1，还是盘中下单？前者先约券，后者使用的是实时券池。
实时券池x = X券商总券池 – 融券T约券总量 – 多空策略约券总量 – 其他空头约券总量
4、场内融券限制后的变化
新规前100%做多空策略，新规主要对场内融券规则做了限制。
如果管理人的策略是只做场内多空，那就大致就阉割为：
60%多空（场内）+40%的中性。
如果使用场外融券，可以增加一些券源，也就是空头机会，策略结构变为：
70~75%多空+25~30%的中性。
结果就是收益降低，多空策略收益>中性策略的收益。回撤是否降低，我没法确定，因为我见过中性策略回撤七八个点甚至超过10个点的，所以无法断言说中性策略的回撤就一定比多空小。
5、收益、风险来源
多空策略的收益就是来源于选股alpha，一揽子个股因强弱不同的差异加总。其次，为了实现这个alpha需要有充足券源的保证，这是执行部分。
因此多空策略既考验量化管理人的alpha能力，也考验期资源和商务能力，以及运营水平。
收益来源对应的便是风险来源，主要有：
第一，alpha端的回撤。
比如输出的打分表出现了错误，做多的强势股在实际行情中走弱，做空的弱势股在实际行情中走强，这时候就会出现回撤，而这个风险归因于alpha端的风险，属于策略层面。
第二，券源层面的风险。
券的可得性风险，直接影响该策略是否能够跑起来。
常用的指标是匹配度和到券率。匹配度是根据模型输出的空头券与合作券商能够提供给这家管理人的券源的占比，如果这个数字很低，意味着该券商的券源无法满足其策略要求。到券率是实际操作时你能够拿到的券，有时候在业务开始前你拿到的excel清单中会有许多券，而实际操作时你真正能够得到券会有差异，这当中存在一些风险。
比如模型输出要500个空头券，X券商说我只有50只券可以给你。你想50只比没有好吧，于是就做了50只空头，并对此匹配50只多头。但对不起，这50只空头券当中有30只是庄股，人家用call建的多头。你的空头端就会崩掉（不停被拉涨停~），这件事情在早年发生过。
另一个风险是召回（Recall），简单说就是你的空头端没了，这样多头就裸露了出来。有些召回是T+1日，有些是实时召回，全部是操作上的细节，这里就不展开了。
召回比例比较低的时候，双方只要及时沟通影响是不大的。比较麻烦的是突然之间出现一个很大比例的召回，这时候就是考验管理人商务和应急的能力了。
由于空头券源差异，导致多头端也不一样，整个多空持仓组合有差异。这就意味着，同一个管理人在不同券商做场内融券多空的业绩在局部时间点上会不一样。
此外，如果同一个券商，同一个多空策略不同多空产品的净值出现差异，那就要去了解是否在下单环节出现了优先顺序？
6、股票多空策略的业务模式
场内融券，一支基金产品只能开一个两融账户。
因此，大部分多空管理人会选择在主流的券源机构开设一只旗舰产品。
考虑到场内的融券效率比较低，包括券源可能比较有限，这时候就需要做一个选择：是否通过开设场外融券来补充券源？
场外融券是通过SAC进行的，一支基金产品可以签多个SAC，即可以接入多家场外券源。
实操中要注意的事项是资金分配划账，多头端和空头端是一起走，不可以在A券商建多头，在B券商场外融券做空。只能在A券商的做一部分多头+场内融券空，在B券商做一部分多头+场外融券空。这时候就涉及到放多少资金到B券商账户上的问题，这又是操作层面的细节了。
另外，选择使用场外券有一个弊端：
大部分券商的合规对场外融券产品有所排斥，这就意味着如果你做的是场外场内融券多空，该券商的自营、资管就无法下投，也没办法上代销。
如今有些管理人的多空策略上了某些券商的代销，基本上是只做场内融券多空。
当然，如果资金来源不依赖券商机构和代销，那么就可以忽略这一点了。
7、境内多空管理人的分类
融券分场内、场外；交易频段分低频和高频。
比如场内低频融券多空，场内场外高频融券多空。
大家可以通过这些分类，把策略看得细一些。
8、境外融券多空
国内量化私募在境外做融券多空的数量比较少，原因还是卡在券源上。
这个时间壁垒大致是3年，假设你找到了正确的方式，找到了正确的人，商务能力可以，大约3年把策略搞成熟。
9、真多空、假多空
可以预见接下来这个策略会被许多家管理人去尝试，甚至“抄袭”。毕竟什么热大家就追什么是咱们财富行业的一个特点。
但是多空这个策略，除了在多头和空头两端市值对齐（相等），还要尽可能将多空两头在风格、行业上的暴露给控制住。
假多空通常指粗放地在做多做空金额上对齐，其他都不对齐。比如今年上半年小市值跑得好，500指数比较弱一些。那么就多头端买一揽子小市值甚至微盘股，空头端做空一堆500成分股和大票。
这个做法在上周五就会出事，因为500成分股表现远远好于微盘股、上证50，于是形成多空双杀，回撤就会很厉害，甚至超过指数增强。
所以大家不要因为策略有稀缺性就盲目追逐，最好先了解下对方是怎么做的比较好。
10、多空策略面向哪些资金？
自有资金，直投资金比较多，代销端的钱比较少。
目前财富端零星出现了多空策略的代销，这块趋势后续还需要观察。
学习目标
本章任务
2.1 通过用户反馈解决问题
2.1.1 通过用户反馈关注什么？
自身产品的问题
竞品的问题
可能的机会点
2.1.2 通过哪些渠道来收集用户的反馈？
2.1.3 用户反馈不同渠道的处理策略
AppAnnie、应用雷达、ASO114、CQASO等
2.2 如何处理不同渠道的反馈
2.2.1 应用商店评论与用户反馈
监控应用商店监控什么？
低分差评：重点看1~3分
有效评价：重点看实际描述的评价
异常行为：比如水军刷榜、恶意评价
竞品变化：监控竞争对手的应用变化
2.2.2 微博贴吧与用户反馈
主流平台：微博、贴吧、知乎、雪球
依据产品类型的不同选择不同的用户群所在平台
工具：关键字+收藏夹、微博企业版、百度、Google等
2.2.3 通过用户咨询、投诉发现问题
内容来源：客服后台、录音、意见建议、用户反馈、邮件等
2.2.4 通过用户点评发现问题
差评：为什么差评？原因、现象是什么？
描述：重点看有实际描述的评论
异常行为：比如是否有刷好评的行为？有没恶意评价行为
2.3 思维导图法整理需求
2.3.1 产品设计的核心三要素
当需求分析遇上思维导图
用户 场景 需求
2.3.2 思维导图的思考方式
2.3.2.1 第一步：潜在用户有哪些
谁会对优惠码感兴趣？
思维导图，列出所有感兴趣的人
不用思考行不行，把能想到的穷举
2.3.2.2 第二步：列出用户发生（感兴趣）的场景
针对每一类用户“分别”往下分解
把“什么情况”描述清楚，最好简单描述一个故事
2.3.2.3 第三步：不同的用户分别碰到什么问题
2.3.2.4 第四步：现在的解决方案是什么
2.4 用户-场景-问题-现有解决方案
2.4.1 关于【用户-场景-问题-现有解决方案】四要素的意义
「用户-场景-问题-现有解决方案」这四要素，其实是一个比较友好的沟通和表达工具。
1、它能够快速的将你和其它在来自不同行业，有着不同表达习惯，目前正处在不同语境下的同学，快速拉入到同一个语境里。
2、它能帮你拆分清楚，用户遇到的真正的问题是啥，是在哪种场景下遇到的，以及遇到后目前的现有的解决方案是啥。
拿三节课内部，班班和技术同学报bug这件事举例：
有些同学在报bug时，是这样描述他们遇到的问题的：
“遇到问题：作业提交后系统不点亮”
如果你这样和刚来公司，正在专心写代码的研发新同学报bug，他应该会一脸懵逼
啥叫不点亮，不点亮有啥问题？正常情况应该是咋样的，这个同学是在哪遇到的这个问题？你到底在说什么？
但如果，你用「用户-场景-问题-现有解决方案」的方法进行问题描述的话，研发同学就一下子有画面感了，也知道你具体在问什么了。
“遇到问题：小三三同学认真做产品P1第2周作业的时候，提交完作业发现截图中左侧红框的小标记没有被点亮，正常情况应该是被点亮以表示鼓励的，但是他一直提交一直不亮一直提交一直不亮，对于学习的积极性造成了严重打击。小三三同学目前很崩溃，决定进行不写作业了。希望研发爸爸们帮忙看一下“
这样的描述过后，研发同学就会在帮你解决问题时，就会很清晰了。
2.4.2 关于用户
用户是一个群体中抽象出共同特征的集合，如：一线城市白领、大学老师、18岁的少女。他们在特定场景中，可能普遍遇到相同的问题、产生相似的需求。
在需求分析中，用户是分析的源头所在，我们需要理解产品的目标用户具体是谁，才可以更好的提出产品上的方案设计。
不过，用户分类也更多是依靠常识，或者自己在该行业持续的经验积累。所以目前在P1的课程作业中，暂时不要求大家掌握用户分类这件事。咱们能大体的概括用户是谁就足够了～
这里也介绍下常见的一些基础用户分类方法：用户分类有很多可以参考的维度，可以按照基础属性，比如年龄、性别、教育程度来进行分类；可以按照产品使用习惯，比如新老用户，付费/未付费用户进行分类；还可以从消费能力、兴趣爱好、社交关系等角度来分类用户。如果产品本身存在多种特定的用户角色（比如电商平台就有商家、消费者、平台运营方等至少三类角色），也可以考虑把这些不同的角色作为用户分类的依据之一。
尽管用户分类的维度五花八门，我们还是可以回归到用户分类的目的——是为了更有代表性的列举出场景和问题，以便于接下来进行需求优先级排序与产品的解决方案的思考——这也是用户分类的核心依据。
2.4.3 关于场景
场景：用户要使用一个互联网产品都有着其所附属的外在环境（比如时间空间）与内在心理状态（比如各种情绪），这些因素共同构成了产品的典型场景。
对于一个产品经理，「场景」是要经常挂在嘴边的词语。对任何产品的分析、用户问题的描述，都要是在一定场景下进行的。脱离场景的产品设计很可能没有办法解决真实场景下的用户问题。
我们一起来看看场景的例子：
场景的例子：
很多时候，场景和问题容易混淆，我们接下来也看看问题与场景的区别是什么。
2.4.4 关于问题
问题是用户在特定场景下完成某个任务过程中出现的，有些人也直接将问题理解为用户需求或痛点。
「问题」的例子（句子中加粗的部分）：
尽管以上的场景和问题拆得还不够细，但可以看出分析问题时，必须依托于场景。场景要能触发人的反应，才会产生需求/痛点。
2.4.5 关于现有解决方案
这个概念很明确，就是他们面对问题做出了什么回应，不过需要注意的是，这个是用户现在这个时候所选择的解决方案，而并非未来产品可能提供的解决方案。此外，不知所措、无动于衷也是一种解决方案~
根据用户的现有解决方案，可以对比市场中是否已经有产品提供更优的解决方案了；若没有，对自己的产品来讲，很可能是个不错的机会。
2.4.6 与【用户-场景-需求】的联系
在没有相应产品功能的情况下，用户现有的解决方案可能并没有真正帮助用户解决问题，所以需要通过产品设计提供一个比用户现有解决方案更好的解决方案，来真正解决用户的问题。所谓产品满足了用户需求、产品解决了用户痛点，本质就是产品为用户提供了一个适当的解决方案。
当我们在以「用户-场景-问题-现有解决方案」的思考方式来分析需求时，目的是为了思考用户存在的问题有哪些没有得到解决，哪些问题的重要性更高，从而可以进一步思考目前的产品设计是否存在要解决的问题，以及未来如何通过产品设计提供更好的解决方案，帮助解决用户现存的问题；
而当我们用产品设计三要素「用户-场景-需求」来分析产品时，出发点是分析产品目前的功能/解决方案是如何解决用户之前发生的问题的。
比如：
“小明在电商公司里担任产品助理，最近618，公司里的业务同学常常加班。但是他们公司又在郊区，上下班非常不方便。每当小明深夜加班到2点的时候，打开滴滴出行，想打快车回家时，就总是打不到“ 像这样的描述方式，就是 用户场景问题现有解决方案的运用~
而”小明同学最近常常在公司加班，备战公司618大促。每到深夜2点下班的时候就打不到车回家。这个时候小明同事给他推荐了嘀嗒出行这款产品，说用这个app在深夜打出租车的时候特别方便快捷。“
“嘀嗒出行满足了小明在深夜2点加班后，想打车回家的需求”这句话的描述，就是 用户场景需求的描述运用~
这两个描述方式，本质上表达的都是用户需求
不过，用户场景问题现有解决方案这种描述，可以更好帮助我们去思考清楚，当前产品还存在哪些问题，产品有没有办法提供给用户更好的解决方案。
而用户场景需求的描述，更多是用于分析产品目前的功能/解决方案是如何解决用户之前发生的问题的。
2.5 需求的优先级排序
四个维度
2.5.1 四象限看用户量与发生频率
某垂直电商平台
2.5.2 开发难度与见效快慢
2.5.3 产品价值
2.5.4 你对目标群体的熟悉程度
2.5.5 总结你的结论
用户：这个功能，第一批核心用户是谁？
场景：这个用户在什么场景下会使用？
问题：解决了这个用户最大的痛点是什么？
对比：和用户现在的解决方案相比，体验/效率提升有多大？
在不同的业务场景下，应该如何决定优先采用哪种排序维度呢？
需求的优先级并不存在标准答案，这里的四个维度是帮助你思考的框架。在不同的业务和产品中，优先级要考虑的因素可能差距也是巨大的。比如，对于银行系统的小伙伴来说，哪怕是一个影响面很小的安全漏洞，可能都必须要以第一优先级来响应。因此，结合自己产品的情况来组合成不同的排序四象限，是你在工作中可以思考的问题。
并且，这几个排序维度也是可以叠加使用的，比如先用用户量和发生频率筛选出第一象限，再用开发难度和见效快慢进一步缩小范围。
如何定义需求的优先级也是挺能看出产品经理的能力水平的，在上一节已经详细阐述了评估哪些需求该做，哪些需求不该做，对于已经决定要做的需求，这样的需求数量很多，是现在做，还是以后做，不可能在同一时间内全部研发完毕，总得有先有后，优先级高的需求优先研发，优先级低的需求延后研发，这样的话就涉及到需求优先级定义的标准了，在产品实践中，很多产品经理都是拍脑门决定先做哪些需求，后做哪些需求，要么就是老板拍脑门决定需求的优先级，那到底定义需求的优先级有没有原则和方法呢？
先来说说原则，在日常生活中，处理任务的优先级有四种情况：重要且紧急；重要不紧急；紧急不重要；不紧急不重要。这四种情况也是我们处理需求优先级的原则，即重要性+紧急性。把需求的重要性+紧急性统称为商业价值原则。基于这个商业价值原则，《神一样的产品经理》一书中主要阐述了需求优先级定义的四种方法。
新产品未上线这种情况指的是产品从无到有的这个过程，这种情况因为没有相关的运营数据做支撑，所以从需求对用户的重要性和紧迫性来判断需求的优先级是一种比较合理的优先级定义方法，那么如何判断需求对用户的重要性呢？
一般情况而言，用户需求重要性：基本型需求>期望性需求>兴奋型需求。
使用需求的金字塔法则来表达，金字塔的最底层是基本型的需求，往上是期望型需求，最上面一层是兴奋型需求。基本型需求是必须有的需求，没有的话用户基本使用不了产品，如果金字塔最底层被砍掉的话，这个需求的金字塔就可能站立不稳而倒下，所以基本型需求的重要性最高，期望型的需求是用户期望能有的需求，用户希望越多越好，但是如果金字塔的第二层被砍掉的话，需求的金字塔不会受较大的影响，因为最底层的需求还在，用户还能继续使用产品，所以期望型需求重要性要低于基本型需求。兴奋型需求是超出用户预期的需求，有的话可以给产品加分，没有的话也无大碍，如果我们砍掉金字塔的最顶层，需求的金字塔更加不会受到影响，因为基本型需求和期望型需求都存在，用户还能继续使用产品，所以说兴奋型需求的重要性要低于期望型需求。其实我们从金字塔的建造过程来看，也是先建造最底层，然后是中间层，最后是最高层。
需要特别注意的是每个用户心里的基本型需求、期望型需求和兴奋型需求是不完全一样的，是千差万别的，比如说有的用户认为期望型需求是基本型需求，而有的用户认为兴奋型需求是基本型需求，这也随着时间在动态变化，甚至衰减，所以产品需求优先级的定义也要根据当时的实际情况来定。
是不是明确需求的重要性之后就可以判断需求的优先级了呢，这里面还需要加上一个因素，即紧迫性。基本型需求重要性最高，且也最紧迫，所以基本型需求的优先级默认是最高的。
一般情况下，肯定是先做基本型需求，在研发基本型需求的同时，有时候因为运营、营销、销售等业务需求的迫切需要，会同时研发一部分的期望型需求（重要不紧急）和兴奋型需求（紧急不重要），主要是制造产品的亮点和卖点，在市场上与竞争对手形成差异化或者品牌区隔，也有利于产品上线初期凭借期望型需求或兴奋型需求赢得用户良好的口碑。
案例：用户需求优先级排序
案例来源于腾讯公司内部的产品培训。1998年，QQ开始规划，1999年2月Beta1，1999年5月Beta2，1999年8月Beta3。
请排版本Beta1，只能实现3个特性：
这道题难倒了很多产品经理，很多产品经理考虑到当时的网络环境和背景，对这道题的答案有较大的分歧。在这里提供两种解答方法，一种是基于腾讯当时实际情况的解答（从当时角度出发，比较现实），一种是基于智能手机金字塔的解答（从现在角度出发，比较理想）。
（1）基于腾讯当时实际情况的解答
笔者跟腾讯公司最早的一批产品经理韩宇宙Punk，曾昭朗Paul和胡俊智Kinzeer曾经探讨过这个问题，给出了当时的答案是1，3，10。至于为什么选择1，3，10？从当时角度出发，理由阐述如下：
在当时情况下，早期的IM竞争对手有，有13家左右，各有一些特色，从单纯的功能上而言，QQ的功能并不突出。真正促使QQ让用户很HI的主要有两个地方：
第一个是卡通头像，让用户活了起来，它不算是啥功能，但是是用户情感需要很重要的出口。当时QQ的头像第一批用的是迪斯尼的，因为用户对这个经典头像熟悉，容易对号入座，有情感认知。当时都是70后嘛，这一代对迪斯尼，蓝精灵等比较熟悉。这些在当时选型时，都有考虑的。
QQ和其他IM不一样的地方，是有一个聊天室，而且是客户端形态的，所有的IM都要解决一个问题，就是用户从哪来。QQ聊天室解决了用户从哪来的问题，因为早期的用户习惯聊天室，对IM还不熟悉和习惯，更谈不上熟人关系。当时的环境和现在不一样，用户上了QQ后，用户的QQ上没有人，所以聊天室，是早期QQ用户聚集的地方，并因此互相加好友，从陌生变熟悉。其他IM的用户关系，一直是相对陌生的，而QQ的关系链是从聊天室的陌生，转化为比较熟悉，是有一定的社区关系的，然后再相互加一下QQ，很好的解决了用户QQ上没有任何好友的问题，有了好友，用户才会持续用QQ。最重要的需求在于怎么解决用户持续使用QQ，所有的功能先围着这个来转。QQ客户端的聊天室是客户端形态，因此聊天室的体验比当时Web 要好很多，功能强很大，而且还引入了社交化的体系，还有金字塔管理体系，让大量的用户每天都进入固定的聊天室相互熟悉，泡妞，有很强的成熟感，这批用户后来也成为QQ论坛的核心用户。聊天室为QQ用户贡献第一批好友，有点社区关系的好友。由于有这些好友，才有持续的动力上来和这些好友进行互动。
一开始，QQ安全性很低，随便都能偷QQ，用户都还不习惯用这个产品，做得再安全又怎么样，关于安全这东西，在早期的互联网用户上，不存在这个考虑。不要用现在的安全意识来评估当时的环境。性能的话，从技术的角度咯，当时的机器就那样，软件再怎么优化也是看不出来的。第一代的密码保护是02年底才有的，02年之前的QQ暴力破解就可以得到本地密码的，很弱。03年之前的密码保护也很弱，随便进后台就可以更改密保和密码。当时的IM还太技术化，但产业环境和用户习惯未到那个层面。比如说音频视频这东西，说真的，当时56K猫上网，支撑不了这个，大家都不用，并且网恋的风行，使文字聊天更有想像空间。
正如马化腾所说的：“exe小是结果，不是规划出来的，第一个版本想写成大也写不出。简而言之，10秒内找到人聊，且头像有趣是最朴素的需求，还有一个是好友保存在服务器端，换电脑也可以恢复。”
总的来说就是表情头像让用户很HI，毕竟要找人聊天，得知到谁在线上，而聊天室解决的是用户从零关系到弱关系再到强关系的问题，解决了第一批种子用户的问题。
从某种程度上来说，在当时环境下，卡通头像属于用户的兴奋型需求，聊天室属于用户的期望型需求，看谁在线上属于用户的基本型需求。
产品跟运营是不分家的，从这个案例可以看出，虽然是新产品未上线，但是已经开始有以运营为导向的元素出现，因为运营需求的迫切需要，研发一部分需求来制造产品的亮点和卖点，在市场上与竞争对手形成差异化或者品牌区隔。
在介绍KANO模型的时候也阐述过用户需求是一个随着时间在动态变化的过程，如果以现在的角度来选择最重要的三项特性，可能就不是1，3，10的答案了。
（2）基于智能手机金字塔的解答
使用金字塔的需求层次来解答这道题目，上面已经阐述过智能手机的需求金字塔，如何评定哪些需求是基本型需求，从现在的角度和环境出发，简单方法就是：砍掉这些需求，这个产品还能用么？
砍掉卡通头像，产品还能用，产品刚开始的时候使用普通头像也是可以的。砍掉QQ表情，产品还能用，不影响使用。没有聊天记录器，就不能使用QQ聊天了吗？显然是可以的，这也解释了MSN的聊天记录保存功能并不是默认帮用户勾选上的。很小的.exe文件，在这方面分歧比较大，很多人说当时是用猫拨号上网的，网速很慢，很多人认为很小的.exe文件是最重要三项中的一项，是这样么？答案不是，试想一下，一款网游好几个G，文件很大，网速虽然慢，但是用户就不去下载了吗？显然用户还是会去下载使用，再想一下，每一个新产品刚推出的时候，都是比较笨重粗糙的，比如以前最初的计算机庞大得可以占用整个办公室，携带非常不方便，回过头来再看看今天的电脑，小巧、轻薄了很多，所以说很小的.exe文件不是最重要的三项之一，可以理解为从用户体验角度来说，文件太大，用户获取的成本稍微有点高，但是用户体验的层次是有用、能用、可用、用的爽和品牌，文件虽然比较大，但是还能用，产品前提的条件是有用。聊天室是多人聊天，一对一聊天的需求还没有满足，就去满足多人聊天需求，显然也不合理。砍掉传文件的功能，产品照样能用，用户之间还可以发文字信息沟通。视频语音也是同理。这样分析下来，反映速度快、安全性和看谁在线上是最重要的三项，这跟智能手能的金字塔需求也是匹配的。如果反映速度太慢，基本上是用不了，用户在使用过程中会崩溃。如果1.0的版本很容易就被黑客攻击，导致瘫痪，照样也使用不了，再说了，QQ上都是自己的社交关系联系人，是比较隐私的，一旦被人盗用不堪设想（尤其是2011年12月震惊圈内的因黑客攻击导致知名互联网公司密码泄露的“密码门”事件，无疑给网站主敲响了网站安全的警钟，提高了安全需求的优先级。）。要想跟人沟通，首先要知道谁在线上，这是最基本的。
此外，在产品实践中，很多产品的成功具有时效性，有的产品在当时的环境虽然成功了，但是在现在的环境下复制这种曾经成功的模式，不一定见得会成功，所以通过QQ这个案例，至少可以得出三点结论：一是需求优先级的定义要基于当时的环境和实际情况；二是用户需求是一个动态变化过程，需要适时调整；三是产品与运营不分家，在确保满足基本型需求的同时，也要适当考虑满足用户期望型和兴奋型的需求。
免费型产品已经上线这种情况指的是全部免费型产品（全部功能免费）或者部分免费型产品（有些功能免费，有些功能收费）从有到优（调优）的这个过程，这个时候因为有了运营数据的支撑，通过运营数据，能聚类分析出用户的行为，甚至可以给用户画像。那么如何定义需求的优先级呢？这里还是采用需求的商业价值原则，即重要性+紧迫性原则。前面已经阐述过，用户有需求，产品利用相应的功能或内容来对应和满足需求，可以根据功能的使用率，使用次数和重要性，形成一个需求重要性的计算公式，根据计算的结果和紧迫性来定义需求的优先级。
现在互联网和移动互联网产品形态很多，比如Web、桌面客户端、第三方平台App、WAP、iPhone客户端、Android客户端、iPad客户端等等，用户对每一种终端产品的需求是不一样的，所以不能机械地认为用户对各种终端产品的基本型需求、期望型需求和兴奋型需求是一样的，这里要区分对待。对于要做跨终端产品的公司尤其要注意。比如，在使用Web 产品时，可以使用鼠标滚轮滚动页面阅读隐藏在下面的内容，能不翻页就尽量不翻页，因为用户比较习惯；而在iPad客户端产品上，从上而下滚动页面，需要使用手指自下而上滑动，用户使用起来有点别扭，很多App产品，尤其阅读型产品，改成了手指自右向左的横向滑动阅读未读的内容，用户使用起来比较自然。
用户需求重要性的判断标准：用户基数、使用次数和类别重要性。类别重要性分成基本型、期望型和兴奋型需求三类。
对于基本型需求，比如产品的性能、安全、浏览器兼容等方面，一旦出现问题，用户不能访问使用产品的情况，应该立马放下手头的工作，利用一切可利用的资源尽快解决这方面的问题，在有的公司称为“911bug”，属于最高级别的bug，优先级最高。比如说网站被黑了，或者使用起来非常慢，用户快崩溃了，这个时候应该想方设法尽快解决，试想一下，如果用户访问或使用不了你的产品，即使你的产品功能多么地强大，做得多么地好，用户也享受不到啊，这个时候如果还是投入资源做期望型需求和兴奋型需求，等辛辛苦苦做完了，用户也就流失掉了，这是一个常识。
对于期望型需求和兴奋型需求，可以通过运营数据，形成公式计算。
需求对应相应的产品功能，用户需求重要性=功能使用用户百分比（用户使用率）x功能使用次数百分比（功能或内容使用率）x类别重要性百分比（期望型需求、兴奋型需求），注意：最底层的基本型需求不在计算范围内，因为默认为最高级别。这个需求级别公式就是综合考虑有多少用户需要、用户经常需要还是偶尔需要、对用户重要还是不重要三个因素。
比如说有功能相对来说类别重要性虽然高一些，但是使用该功能的用户数和用户次数却比较少；有的功能相对来说类别重要性虽然低一些，但是使用该功能的用户数和用户次数却比较多，那么根据上述公式计算后得出的结果有可能是类别重要性比较低的功能整体重要性要高于类别重要性比较高的功能整体重要性。
关于计算公式举例：A功能属于期望型需求，在一定时期内，假设总的用户数有100人，其中有50人使用过A功能，那么A功能使用用户百分比就是50/100=50%，在这50人使用过程中，一共使用了10000次，那么使用次数百分比就是10000/50=200，类别重要性百分比，假定期望型需求是50%，那么A功能级别数值=50%×200×50%=50。
B功能属于兴奋型需求，在一定时期内，假设总的用户数有100人，其中有30人使用过B功能，那么B功能使用用户百分比就是30/100=30%，在这30人使用过程中，一共使用了90000次，那么使用次数百分比就是90000/30=3000，类别重要性百分比，假定兴奋型需求是25%，那么B功能级别数值=30%×3000×25%=225。
可以看出B功能级别数值225要大于A功能级别数值50，所欲B功能的整体重要性要高于A功能。
对用户来说，基本型、期望型与兴奋型需求并不是一成不变的，是一种动态的变化过程。并且运营数据也在不断地发生变化，需要及时作出相应的调整！
是不是明确需求的重要性之后就可以判断需求的优先级了呢，这里面还需要加上一个因素，即紧迫性。还是得按照先做重要且紧急得需求，后做重要不紧急的需求，再做紧急不重要的需求，最后做不紧急不重要的需求。
收费型产品指的是已经上线或者未上线收费型产品（全部功能收费）或者部分收费型产品（有些功能免费，有些功能收费）。在这特别说明一下，收费型产品的需求也主要是期望型需求和兴奋型需求，因为基本型需求的优先级默认是最高级别的（重要且紧急）。
一般情况而言，收费型产品是公司的收入来源，如无特殊情况，在同等条件下，一般收费型的功能优先级要高于免费型的功能优先级。那么收费型产品的优先级如何定义呢？定义的标准就是商业价值，即重要性+紧迫性，这里的重要性主要指的是经济收益（将战略上的收益也归结经济收益，包括有形的和无形的收益），经济收益高且紧急的功能需求先做，经济收益高且不紧急的功能需求后做，紧急且经济收益不高的功能需求再往后做，不紧急且经济收益不高的功能需求最后才做。
前置后置条件指的是有时候必须先完成A功能，然后才能做B功能，从需求的优先级来看，A功能的需求优先级肯定要高于B功能的需求优先级。A功能的重要性和紧急性都要高于B功能。
总的来说，上述四种定义需求优先级的方法，在公司范围内，在特定的产品阶段，是可以搭配使用的。需求优先级定义的原则基本上是一样的，都是商业价值原则，即重要性+紧急性。
不管在哪一种方法下，基本型需求的优先级永远默认是最高级别的，至于期望型需求和兴奋型需求要根据具体的实际情况使用方法的一种或几种方法搭配使用，而不是再用拍脑门来决定需求的优先级。特别注意的是，上述的内容都是围绕需求的优先级来展开的，是从产品人员的角度来说，但是从研发人员的角度来说，毕竟受到各种人力、物力、财力的限制和影响，并不能完完全全按照产品人员确定的需求优先级来进行研发，基于产品人员确定的需求优先级，研发人员基于开发资源提出相应需求优先级的研发优先级。至于研发优先级如何定义，将在下一节管理需求中作详细阐述。
REF
产品没有标准答案，重要的是在迭代中做的越来越好。
需要带着目标和问题，有针对性地进行学习，在学习伊始能够明确自己的目标，在学习结束时能够评估自己的达成状态。
产品的本质是解决用户问题，需要以用户为中心、关注产品的长期价值。
产品经理需要是产品的资深用户，深入到用户中去。初期可以自身作为用户，通过电话等方式咨询同业如何运营，从而学习成长，了解行业潜规则、灰色地带。
面临如何平衡数量和质量的问题，即要数量还是要活跃？质量比数量更重要，质量意为活跃、留存，大于新增。新增通过投放、运营可以解决，但留存客户非常困难，留存做不好，客户会转移到同业的产品中去。
关注产品的长期发展而非短期利益。销售关注短期，如当月客户数量；运营关注中期，如3个月左右周期，关注拉取活跃用户；产品经理关注半年到一年的生态。
产品设计的关键：用户、场景、需求三方面
产品亮点：对内让研发、测试人员了解所产出产品的亮点、用户好处；对市场，推广宣传文案亮点，让用户觉得有关、有好处、更大的回报。
视角没有对错，只是不同的维度和不同的思考方式。产品经理应当能允许多种视角的存在，并将其整合，方能形成对问题更全面、更深入的理解。
用户视角：= 体验视角，最浅层的视角，是感官的东西，只是对表面的理解。不同用户的关注点不一样，如针对玩具，孩子和父母的考虑不同。仅从用户视角考虑是不足的。
产品视角：= 逻辑视角，生产逻辑、结果。替代（抄袭）角度。
商业视角：= 利益视角，专业视角，看到背后的本质，并思考规模化复制的可能。
用户的视角很容易解决，产品的视角不容易解决。
产品视角看什么?
怎么判断产品好不好?
培养产品感没有捷径:看大量的产品、体验大量的产品。这里的体验不是指泛泛得使用，而是要带着问题系统化、有深度得去思考长久以往，形成习惯，你将会拥有一种全新的看待事物的眼光。
使用产品≠了解产品，碎片化的体验用户不大，需要带着目的深度体验。
区别：模式、形态、功能、氛围
深度体验：什么样的用户，在什么情况下会用这个产品或功能，解决了用户什么问题
用户区分：3-4种用户，不要太多，如新老用户、发帖者看帖者
如何培养产品感
如何跨越“体验”门槛
测试”门槛”问题的应对方式：[一借二假法]
借：借用别人的账号来体验
假：假装投资人，联系对方产品的客服，或是约线下见面去体验产品
认识产品的正确姿势
深度体验产品:
