任务说明

为产品的主要功能（服务）做价值评判和成本评估，做出性价比的排序。

一、讲授：产品原则

产品原则是对团队信仰和价值观的总结，用来指导产品团队做出正确的决策和取舍。它体现了产品团队的目标和愿景，是产品战略的重要组成部分。从形式上看，它是一系列明确的体现团队特色的产品价值准则。

制定产品原则的前提是团队至少已经完成了项目需求采集，如完成了项目需求模板。

产品原则是整个创业团队必须达成共识的准则，依赖于团队的价值观或者是创意此产品的初心。投资人或大赛评审在了解创业团队时很喜欢问一个问题：你为什么做这个项目？这个问题的答案就是初心，初心决定了团队发展空间的上限。

所以，新组创业团队要做的一件重要的事情就是制定产品原则。制定产品原则意味着决定什么重要、什么不重要，哪些原则是根本的、战略性的，哪些是临时的、战术性的。产品原则不是产品功能的清单，它是创业团队的价值宣言。好的产品原则甚至可以激发设计产品的灵感。产品原则可以让之后加入团队的创业伙伴从中了解团队创始人设立的创业目标。产品原则是一套价值判断的框架，帮助创业团队做出正确的决策。

以某电影网站为例，它的产品原则是相信社区用户的影评比专业人士的影评更有价值。如果某家制片厂希望借网站发表评论，产品团队就可以根据这条产品原则决定是否釆纳。

产品原则是否公开因公司而异。它既可以用作团队内部的指导工具，像是产品战略文档，又可以公开给客户、合作伙伴、投资人，用于向公众宣传公司的理念。

此外，产品原则还可以用来团结创业团队，让所有成员形成共同的价值观，在认识上保持一致性。这是任何产品说明文档都做不到的。

注意：仅仅罗列出产品原则还不够，还要按原则的重要性排序。所有产品都希望做到既易于使用又安全可靠，但总有需优先考虑的原则。最重要的究竟是易用性，还是可靠性。

制定产品原则时容易出现两类错误。第一类是原则过于空泛，失去了指导作用。第二类是把设计原则误当成产品原则，例如，为用户提供清晰的导航路径（方便用户完成下一步操作）属于常见的设计原则，不属于产品原则。

创业团队在产品决策过程中经常议而不决，围绕产品发生争论、冲突，原因主要有以下三点。第一，每位同事对团队的产品都有自己的看法。第二，大家都非常在乎产品，明白团队取得成绩得靠用户，只有产品才能吸引用户。第三，许多人以为自己比其他人了解目标用户，事实上并非如此。如果创业团队有清晰的产品，那么就可以避免以上这种状况的发生。

如果你所在的团队还没有制定清晰的、有关产品理念的产品原则，应该把大家召集起来讨论分析，确定团队最看重的价值理念，让大家在以下四个要点上达成共识。

第一，究竟要解决什么问题。在产品的市场切入点中，最关键的用户需求场景是哪几个。

第二，要为哪类人物角色解决这个问题。如果将目标用户分为几类，那么他们的优先级排序是什么。

第三，产品要达到什么目标。

第四，每项目标的优先级是什么，最初的最小化可行产品必须满足哪些需求。

往往团队内出现严重的意见分歧，并非大家对事实的认定有争议，而是对目标和目标的优先级有不同的理解。比如，团队首先应该确定哪个目标对用户最重要，是易用性、响应速度、功能、成本、安全性，还是用户隐私。只有先统一对产品目标和目标优先级的认识，大家才能在此共识上进一步讨论各种方案的合理性与可行性。务必认真分析产品目标的优先级（从最重要到最不重要逐项排序），让团队达成共识。切不可囫囵吞枣地把所有目标都贴上“关键”和“重要”的标签。一定要区分什么最重要，什么次重要……

即使大家已经达成共识，也应该在讨论开始前再次予以强调，最好把目标按优先级顺序写在白板上，这样每位团队成员都可以看到评估方案和制定决策的确切依据。激烈的会议争论会影响大家的斗志和工作效率。如果再出现这种情况，请先回顾产品目标和目标优先级，确保大家达成共识。

注意：产品原则也需要与时俱进，定期优化调整。

二、讲授：确定功能的优先级

理论上，性价比高，功能优先级也就高，所以应该先做。

性价比=价值/成本。其中，价值由产品功能背后的用户需求（问题）决定，成本由产品功能（解决方案）决定。

（一）价值评判

价值评判的基础原则见图3.11。

图3.10 价值评判框架

1.广度：潜在用户数×单用户价值

广度对应着潜在用户数，即一个产品将来可能覆盖的用户群体有多大。

不同产品、不同功能的定位直接决定其可能覆盖的潜在用户数会有差异，有时甚至相差多个量级。例如，面向出行这一需求，打车应用覆盖的潜在用户数可能是几个亿，代驾应用因为要求用户有车且没法开，所以其可能覆盖的潜在用户数最多只有几百万，两者差距很大。同样是餐饮服务，日常快餐和只接婚宴，潜在用户数的差距也很大。

单用户价值这个词，在不同行业能找到不同的说法。例如，电商行业的“客单价”指用户平均每次消费花多少钱；游戏行业和运营商的“ARPU”（Average Revenue Per User），是指平均每个用户在单位时间内给公司带来的收入；而对于社交应用，对应的说法也许是“活跃度”。

从广度的角度，“潜在用户数×单用户价值”可以用来判断产品对应的市场容量。具体操作时，经常先从一些细分用户切入，再逐步扩大到所有潜在用户。比如，2016年第二届中国“互联网+”大学生创新创业大赛第四名的ofo共享单车，就是先攻高校内部，再扩张到校园外。

2.频度：需求频次×单次复杂度

频度是指需求频次的高低，不同的需求，频次差异会非常大。

有些需求每天都会出现一次甚至多次，如叫外卖；有的需求每周最多出现一次，如看电影；有的需求也许每个月只出现一次，如交水电费、还信用卡；有的需求每年出现一两次，如车险、出境游等；有的需求甚至有可能一辈子只出现一次，如结婚。

很容易就能得出结论，高频高单价的需求极少，低频低单价的需求不值得做。常见的策略：先利用高频低单价的需求抓住用户，因为高频场景和用户互动的机会多，而低单价的轻决策场景可以降低用户进入门槛，容易引流；再用低频高单价的需求做利润，因为单价高了，可以切分的蛋糕才大。之所以采取这样的先后次序，是因为必须有海量用户做基础，低频需求的总量才足够大。比如，汽车后市场（买车以后产生的各种消费）就很典型，用高频低单价的洗车增加客流量，甚至通过补贴来抓牢用户，然后用低频高单价的保险、保养、修车来赚取利润。

“需求频次×单次复杂度”，让我们在广度之余，可以从频度的视角再一次对市场容量进行验证。

不同价位、不同频次需求的处理策略总结，见图3.12。

图3.11 不同价位、不同频次需求的处理策略

3.强度：不可替代、紧急、持久

强度指的就是真实刚需。一个需求是不是真的，是不是刚性，有一个简单的判断原则，就是问自己这样一个问题：“当你没有做这个产品功能时，用户是不是在设法解决，甚至已经在用某种低效的方式来解决这个问题？”如果答案是肯定的，那么说明需求真的很强烈。

三个判断的角度：

第一，可替代性。可替代性用来说明一个功能是不是很容易被其他功能替代。越是不可替代的功能，其需求强度越大。

第二，紧急程度。需求紧急程度也可以作为衡量需求强度的判断原则。需求紧急程度和需求强度成正比。

第三，持续时间。持续时间是指一个功能做好之后，用户有效使用的周期是多久。使用周期越长的功能，其需求强度相对越大。

4.不同阶段的产品看重什么

第一，在产品的不同阶段，对上面提到的广度、频度、强度上会有不同的侧重点。产品早期的验证阶段，更重视“强度”。用户留存率够高，产品在将来才会有好的发展，而留存率高就要求产品背后的需求足够强。这一阶段的产品还在不断试错，寻找最能打动用户的切入点。创业者关注的问题是“有没有人愿意为此付费”“哪些人迫切地愿意为此付费”。

第二，验证完毕，产品进入大面积拉新（获取新用户）的阶段，这时更重视“广度”，这个阶段的产品需要快速增长，希望通过各种推广来占领更多市场份额，以尽快与对手拉开差距。工作重心依然是围绕核心功能做优化，同时可以获取大量的用户反馈。这一阶段创业者关注的问题是“有没有更多的人愿意为此付费”“有多少人”。

第三，当用户增长出现瓶颈时，就需要开始对产品的用户进行激活。这时更重视“频度”。在拉新阶段，通常的策略是先攻“单用户获取成本”低的场景。例如，如果你要主攻白领人群，那么上下班时间的写字楼电梯口就是一个好机会，在这里单位时间内能获取的新用户数肯定高于你在路边寻找。但是，当这类机会都饱和后，拉新成本就会越来越高，这也就意味着用户数没法一直保持高速增长。这时再想扩大产品的价值，应该怎么办？在每个用户身上挖掘更大的潜力是个好办法，所以这个阶段适合做频度，让已有用户更加活跃，使用产品的频次提高，贡献更大的价值。这一阶段创业者关注的问题是“如何让愿意为此付费的人更频繁地付费”。

（二）成本评估与性价比

判断一个产品功能的成本，有很多方面的考量，如人力、时间、金钱等，甚至也可以把风险看作广义的成本。日常评估时，没法面面俱到，所以通常先判断成本的瓶颈（整体中的关键限制因素）在哪里，然后用对成本瓶颈的评估来简化完整评估。

此时评估的目的是确定功能的相对成本的高低，从而确定性价比。功能A与功能B相比，哪个相对成本较高一点，哪个较低一点，只需要知道对比关系就可以，如“高、中、低”的评价或者“5-4-3-2-1”的不同分值。然后，用半定量的价值和半定量的成本，就可以计算出半定量的性价比，即性价比=价值/成本。

三、实做：输出项目优先级列表

（一）优先级模板

纵轴代表“难易程度”，由下向上表示由“易”到“难”。横轴代表“重要程度”，由左到右表示由“不重要”到“重要”，如表3.4。

表3.4 优先级模板

（二）填写优先级模板

之前，我们分析出了项目最主要的功能（服务），接下来的工作有以下三点。

第一，将提取出的关键功能（服务）按优先级填到模板中。

第二，将项目优先级列表文档上传至云端。

第三，团队讨论、制定产品原则，然后上传至云端（此工作可选）。