上一次分享我们学习了第3-5章，运营喵必知的产品那些事—2、一文看懂用户、需求，从产品概念的提出到用户需求采集的方法以及基本的需求分析方法，今天的分享主要是从到底先做哪个开始到如何做的过程。
第6章 功能：细化与打包
6.1一个功能的DNA
最基础的信息，是功能的描述。必须要让技术同学看了之后，就大概知道要做什么事情。
主要展开三点：价值评估(表中的商业价值)、成本评估(表中的开发量)，功能分类(表中的分类)。
进一步总结出以下2点：
价值由产品功能背后的用户需求决定；
成本由产品功能(解决方案)决定。
实现一个功能，必须结合这两个条件，综合考量性价比。
性价比=价值/成本
6.1.1功能的价值判断
判断的流程：明确当前产品最看重的指标，考察功能，点对指标的帮助。
价值评判的三个基础原则：
广度：潜在用户数*单用户价值，用来判断产品对应的市场容量。
频度：需求频次*单次复杂度，利用高频低单价需求抓住用户，再用低频高单价需求做利润。
强度：不可替代、紧急、持久，强度的背后说的就是真实刚需。简单的判断原则：当你没有做这个产品功能时，用户是不是在设法解决，甚至已经在用某种低效的方式解决这个问题。
不同阶段的产品看中什么
产品早期验证阶段更重视""强度""，通过观察留存率来判断需求是否足够强烈。
产品获取新用户阶段，更重视""广度""。拉新是否顺利，依赖的就是需求和功能覆盖的广度是否够大。
当用户增长出现瓶颈，就需要开始对产品的用户进行激活，这时候更重视""频度""。让已有用户更加活跃，使用频次更高，贡献更大的价值。
6.1.2 几个价值判断的案例
对于功能的价值判断，借助下面两个问题：
谁的痛，有多少这样的人?（这些人是核心用户吗？人群足够大吗）
痛有多深，何时会痛？何地会痛多久，一次一次多久？（具体场景典型吗？需求刚性吗？）
实用工具，如何突破
墨迹天气，潜在用户数很大，需求频次很高。推出实景功能，和给其他产品引流。
很多工具都尽力向社区和个性化方向靠拢，都是为了让用户跟自己产生情感。一个产品要大成，靠的就是用户与你产生复杂的积极情感。
6.1.3 成本评估与性价比
成本评估
判断一个产品功能成本，涉及很多方面，有技术背景的产品经理可以粗略评估；大功能细化模块，通过团队默契，评估准确。
确定性价比
第1列为功能点，第2列为价值评估，第3列为成本评估，第4列是第2列除以第3列得到的数值。
实际操作中还需要考虑功能的分类和其他的实际情况。
6.1.4功能分类：KANO模型
第1类基础功能（基本型需求）。当这类功能没有实现时，用户对产品是极不满意的，但是这个功能做得再好，用户也认为理所当然。
做法：预留资源搞定它。
判断方法：主要靠领域知识，两个经典问题：如果产品没有功能A，你觉得如何？如果有了功能A，你觉得如何？请从很满意，一般满意无所谓，不太满意，很不满意中选一个作答。然后在模型中将两个点连线即可。
第2类亮点功能（魅力型需求）。当这个功能没有做事，用户并不会不满意或者有问题，一旦有了这个功能，用户会非常惊喜。
亮点是忠诚度，口碑传播的基础，想要低成本引流，产品必须找到自己的亮点。
常见的亮点特性：用户没见过，未经市场检验，如果被认可就能获得巨大回报这几种。
做法：早期优选成本低的亮点，大公司或很厉害的产品，把亮点打造成领跑市场的杀手锏。
怎么做出亮点，主要对用户人性的理解，因为亮点是用户想不到说不出的，必须领先一步，深刻洞察。
第3类期望功能，对产品多多益善，选择起来比较简单：先做性价比高的。
如果只通过简单的和用户交流来采集需求，最终实现了大多数只能是期望功能。必须通过深挖，对人性和价值观的理解来提出亮点。
随着时间的推移，越来越多的功能成为基础功能，行业门槛随之提升，而亮点功能则有可能创造一个全新的增量市场，必须不断创新，对市场进行有效细分。
第4类无差别功能。做不做用户对产品的感受是没有变化的。通过低成本验证的方法来决定要不要做：先通过人肉跑流程验证，然后用IT系统提升效率，实现规模化效益。
第5类反向功能。做的越多，用户越讨厌。例如百度广告。因为一个产品的用户是多种多样的，对某一类用户可能是反向的，而对另外一种用户可能是正向的。
一个KANO模型，往往只针对一种用户，通常是核心用户。在评估反向功能时，需要注意用户的多边性和用户的多样性，通过价值判断来寻找答案。
6.2 功能打包，确定mvp
决定下一个版本做到什么程度。
6.2.1 尽可能多的放弃
MVP最小可行性产品，让用户你拿着它接触用户，尽早给你用户的反馈，来改进你的产品。和需求采集阶段""尽可能多的采集""不同，这一步要""尽可能多的放弃""，目的都是为了提供更多可能的用户价值。
发布的频次并非越频繁越好，因为发布本身也要占用时间和成本。越轻量级的产品越容易打包出一个尽量小的mvp。
不完美的产品先让种子用户去用。
我们经常听到点带敏捷，试错小步快跑持续交付等这些说法，其实他们都是：尽可能早地改正错误。
6.2.2案例QQ的MVP
6.2.3 MVP的限制因素
不同功能不同对策；基础功能必须做，要留足资源；产品初创期先实现个别低成本的亮点；对期望功能，先做性价比高的；无差别功能无需做，低成本验证出来即可；对反向功能，权衡各方利益后再决定。
考虑功能依赖关系。
考虑功能的相似性。
考虑非功能需求。
6.2.4 MVP的表达产品架构图
根据表达的需要，产品架构图可以画成流程图实体关系图用例图等。
6.2.5功能分分合合的本质
不同的功能到底应该坐在一起还是分开？主要看不同用户角色背后的自然人重合度高不高，如果高则倾向于同一端搞定，如果不高则倾向于分离。
6.3 把需求和功能管起来
该做哪些做多少都想清楚了，mvp和产品架构图也确定了，需要把已经做了的，正在做的，还没做的需求和功能都管理起来。
6.3.1空间维度功能列表
表达了某个时间切片所有的功能状态。每一行是一个功能点，每一列是功能的一种属性：模块、子模块、任务描述、Feature、商业价值描述、商业属性、商业优先级、开发量、性价比、备注。
6.3.2时间维度：需求流程
从需求到功能的状态流转图，实际上是在管理某个需求的功能的完整生命周期。
第7章 执行立项，组队与研发生产
7.1从想清楚到做出来
关键步骤是需要不停的回溯去验证，而不是step by step。
7.1.1原型验证与NPS
确保有的放矢，不要努力的做错误的事。目的：考察用户是否认可解决方案。
NPS净推荐值，用户忠诚度分析指标专注于用户口碑，在产品早期验证用户价值时，尤为重要。
NPS = （推荐者数—批评者数）/总样本数 X 100%。
方法：直接了当的问用户：您是否会愿意将某某产品推荐给您的朋友或同事？根据推荐程度在0~10之间打分。
推荐者：打分在9~10分之间，是具有狂热忠诚度的人。他们会继续使用产品，并引荐给其他人，帮助产品成长。
被动者：打分在7~8分之间总体满意，但并不狂热，不会传播，可能考虑其他竞品。
批评者：打分在0~6分之间，使用后不满意，对你的产品没有忠诚度，可能有负面口碑，阻碍产品成长。
得分值在50%以上就已经比较理想。如果达到70~80%，这说明产品拥有一批忠实用户。分数太低建议，回过头明确产品定位。
7.1.2 产品委员会与关键节点
产品委员会：判断每个节点是应该加大投入，保持投入还是减少投入。参评委员会由相关部门儿的leader组成。
7.2 立项，搞定各种资源
人，就是团队组织；物，政策，支持资金等
7.2.1关于人团队组织
一群人到底为什么要聚在一起做一件事？只有想清楚了这个问题，才能搭建一支有战斗力的队伍。
组织形成的三种动力：权利，利益，共识
7.2.2关于物：政策资金等
MRD：市场需求文档，描述问题及为什么要做这个产品以及解决方案。
PRD：产品需求文档，描述产品功能怎么做。
主要包含内容：
Why：为什么要做这个产品？
What：产品mvp包含哪些功能题要做什么？
How：项目计划及风险对策等
MRD写得好，意味着各种准备工作做得到位，最终能获得各种支持就是自然而然的事。
7.3组队聊聊初创团队
7.3.1如何快速知己知彼
在非工作地点，非工作时间沟通更容易敞开。
话题：为什么要来这个团队，对一年后收获的底线预期，个人对团队的帮助，自己能做什么，自己想做什么，项目失败最可能的原因是什么？
批评与自我批评的意图是继续暴露问题，前提是沟通气氛到位。
结合以上问题，由团队提出非业务层面的改进方案，核心不要超过3点。
7.3.2小团队的沟通协作
选择合适的沟通工具；线下沟通效率高于线上；可以根据事情的重要和经济程度灵活选择沟通协作方法。
7.3.3小团队与大公司的区别
初创公司组织架构应该以目标为中心，大公司以流程为中心。
7.3.4借助第三方力量做产品
多研究市场是不是已经有现成的服务，避免重复造轮子。
用人上"为我所有不如为我所用"；分享、座谈、咨询、外包4种方式。
7.4研发生产时我们做什么
原型验证完成，产品委员会评审通过要尽力立项，需求开发测试发布其他环节，然后拿出来产品找用户验证，最后做项目总结。
把控三件事：1是文档管理，2是流程管理，3是敏捷方法。
7.4.1产品经理要不要懂技术
一底线是可以和技术人员无障碍沟通，并不要求你会写代码。
二多向技术伙伴请教，自学一些技术知识。
三根据所负责的产品决定要懂哪些技术，懂到什么程度。
四特别关注技术方案与业务场景的关联。
7.4.2如何做一个让TA们讨厌的人
开始实施之前：不说清需求价值，不去想功能细节，帮技术评估工作量，逼着技术团队承诺。
实施过程中：做了一半改需求、开发过程中消失、过度关注事件细节。
产品发布之后：发布后没有反馈、任务无节奏感。
全程适用：优柔寡断无决断、报喜不报忧、不要把他们当人。
下一节，我们将进行第8-12章的学习。
传送门：
