1704232861
人人都是产品经理2.0：写给泛产品经理 [:1704229224]
1704232862
人人都是产品经理2.0：写给泛产品经理 6.[1] 一个功能的DNA
1704232863
1704232864
俗话说，产品经理推动工程师实现功能有三宝：竞品已搞，老板想要，开发量小。如果不行，再上杀招，求求你了好不好。
1704232865
1704232866
实际工作中，当然不能这么玩。第05章中用Y模型做完了需求分析，从一堆用户需求中推导出很多产品功能，接下来，要回答Which（做哪个）和How many（这次做多少）这两个问题。
1704232867
1704232868
一个功能，涉及表6-1中所列的很多属性（更具体的介绍请参见《人人都是产品经理（纪念版）》）。
1704232869
1704232870
表6-1 一个功能的DNA1
1704232871
1704232872
1704232873
1704232874
1704232875
表6-1中最基础的信息，是功能的描述。必须要让技术同学看了之后，就大概知道要做什么事情，这里的描述，通常只是一两句话，界面、逻辑等细节，还需要等到项目中的PRD（产品需求文档）阶段才会细化。
1704232876
1704232877
在本章中，主要展开说三点：价值评估（表中的“商业价值”）、成本评估（表中的“开发量”）和功能分类（表中的“分类”）。
1704232878
1704232879
更进一步可以总结出以下两点：
1704232880
1704232881
►价值由产品功能背后的用户需求（问题）决定。
1704232882
1704232883
►成本由产品功能（解决方案）决定。
1704232884
1704232885
实现成本低，或者对应需求的价值高，这两个条件中的任一个，都不能单独作为决定去实现一个功能的理由。必须结合这两个条件，综合考量功能的性价比。理论上，性价比高的功能优先级也就高，应该先做。
1704232886
1704232887
性价比 = 价值/成本
1704232888
1704232889
不过在实际操作中，还需要考虑功能的分类，在本章的功能分类部分，会仔细分析不同种类功能各自的应对策略。
1704232890
1704232891
6.1.1 功能的价值判断
1704232892
1704232893
先说说对某个功能进行价值判断的流程。
1704232894
1704232895
►参照“产品原则”里“目标”部分的定义，明确当前产品最看重的指标是什么，可以是数字化的KPI，比如注册用户数达到10万，也可以是某些关键结果，比如“建立起线上自动化的专家入驻全流程”。如果有多个指标，则需要对这些指标加权合并[2] 。
1704232896
1704232897
►考察每个功能点实现后，对上述指标的帮助大不大。如果大，则这个功能的价值就大。因为每个产品不同时期的指标不同，所以评判各个功能价值的标准也各有差异。通常用半定量的方式来衡量，比如最简单的大、中、小，或者5.4.3 、2、1等评分标准。
1704232898
1704232899
接下来介绍图6-1中三个功能价值评判的基础原则。
1704232900
1704232901
1704232902
1704232903
1704232904
图6-1 功能价值评估的框架
1704232905
1704232906
广度：潜在用户数 *单用户价值
1704232907
1704232908
简单来讲，广度对应着潜在用户数，即一个产品将来可能覆盖的用户群体有多大。不同产品、不同功能的定位，直接决定其可能覆盖的潜在用户数会有差异，有时甚至相差一个或多个量级。
1704232909
1704232910
同样是面向出行这一需求，如果是打车应用，覆盖的潜在用户数可能是几个亿，如果是代驾应用，因为要求用户有车且没法开，可能覆盖的潜在用户数最多只有几百万，二者相差两个量级。同样是餐饮服务，日常快餐和只接婚宴，潜在用户数的差距也很大。