《人人都是产品经理2.0》读书笔记 Day7 功能:细化与打包

第5章中做完了需求分析,推导出了许多功能,现在要开始回答Which(做哪个)和How many(做多少)两个问题。

一个功能存在很多属性,如下表所示:

《人人都是产品经理2.0》读书笔记 Day7 功能:细化与打包

表中最基础的细节是功能描述,要让技术同学通过一两句话了解到需要做什么,之后再通过PRD进行细化。

在本章中主要展开说三点:价值评估、成本评估和功能分类


价值判断

价值判断需要从三个角度入手——广度,频度,强度,如下图所示:

《人人都是产品经理2.0》读书笔记 Day7 功能:细化与打包

广度用公式可以表示为“潜在用户数*单用户价值”。这个公式表明判断一个行业的潜力(或者说市场容量)需要综合这两个因素来看,一般来说潜在用户数当然越多越好,但有一些潜在用户数低,但是单用户价值高的行业也可以做。单用户价值在不同行业有不同的说法,电商行业称为“客单价”,游戏行业和运营商称为“ARPU值”,社交应用中对应的说法或许是活跃度等等。

频度用公式可以表示为“需求频次*单次复杂度”。和广度公式同理,一般来说频次越高越好,但是有一些单次复杂度高,单价高的需求也可以尝试去做。高/低频次和高/低单次复杂度可以构成一张二维图,对四个象限的理解如下:

《人人都是产品经理2.0》读书笔记 Day7 功能:细化与打包

一般来说,常规的策略是高频低单价抓用户,再低频高单价做利润

强度是通过需求的可替代性、紧急程度和持续时间判断的,当产品不可替代,对其的需求紧急且持久时,我们就可以称之为刚需。判断一个产品是不是刚需很简单,当没有这个产品功能时候,用户是否只能自己设法解决,甚至只能用低效的方式解决,如果回答是肯定的那么用户对这个功能就存在刚需。

在产品的不同阶段,对广度、频度、强度会有不同的侧重。产品早期更重视“强度,去验证用户是否认可产品且会反复使用;验证完毕进入拉新阶段后,更重视“广度;当用户增长出现了瓶颈,就需要对产品的用户进行激活,这时候更重视“频度”。当然在产品真正实现的过程中,真实情况更多是各个环节相互渗透,交替出现。


成本评估

判断一个产品的成本,需要考虑诸多因素,人力、时间、金钱等等,在很难对成本面面俱到评估的情况下,通常会先判断成本瓶颈,如互联网的成本瓶颈是开发工程师的工作量,那一般就会把“开发量”视为成本的高低。

在产品设计早期一般只需要“初评”,不需要做太精细的评估,但是细化的程度仍然是一个很考验团队默契程度的事情。如果细化后工作量确实比预想大,那就可以将一个大功能分成小模块,按性价比分期实现。

但是有时候一些基础功能,即使性价比很低,但也是非做不可的。如何正确处理这一矛盾,就需要引入KANO模型在针对产品经理语境优化的KANO模型中,横轴代表产品功能实现度,纵轴代表用户满意度,根据这两个变量的变化关系可以绘制出不同的曲线,不同类型的曲线代表了不同的功能,其中基础功能是必须要实现的功能点产品经理主要靠其领域知识判断某个功能是否为基础功能;亮点功能是能带给用户惊喜的功能,是忠诚度和口碑传播的基础,这一点主要依靠产品经理对人性的理解;期望功能对产品而言多多益善,主要根据性价比的高低进行实现优先级的排序。某个功能属于这三种功能中的哪种功能是随时代变化的,比如有一些亮点功能可能随着时间推移逐渐变为了期望功能,甚至是基础功能。

《人人都是产品经理2.0》读书笔记 Day7 功能:细化与打包

再来说无差别功能,做不做都不影响用户对产品的感受,在设计产品时对于这种功能肯定是要避而远之的,那如何判断无差别功能,就需要用到我们此前提到过的低成本验证。

《人人都是产品经理2.0》读书笔记 Day7 功能:细化与打包

最后一个就是反向功能,这类功能做得越多用户越讨厌,但是在这里要思考一个问题,对于不同的用户类群可能KANO模型是不同的,比如百度的招标广告可能用户非常讨厌,但是对于广告的投放者肯定希望自己投放的广告越多越好。评估反向功能时候要注意到用户的多边性和多样性,在多种用户利益之间寻找平衡,如何判断用户重要程度,就需要价值判断相关的知识了。

《人人都是产品经理2.0》读书笔记 Day7 功能:细化与打包

完成了价值评估和成本评估之后,基本解决了Which的问题,接下来该解决How many,即功能打包,确定MVP

最小可行产品(MVP)是指“用户愿意用,最好愿意付费”、“用户易于使用”、“团队有能力实现”的最小功能集合,其特色就是制作成本极低,但是能展示最终产品的主要特色。在设计MVP阶段,产品经理要学会“尽可能的放弃”,但这种放弃不是丢掉更多功能,而是不要集中完成,分批对功能实现迭代。

所以如何完成功能打包和确定MVP呢?这就要根据不同的功能设计不同的对策,之后考虑功能的依赖关系、功能的相似性、非功能需求等等。

当确定好了MVP之后,可以用一张产品架构图将MVP的结构表达出来。根据表达需要,产品架构图可以画成流程图、实体关系图、用例图等等。

当以上一切都准备完成后,需要将所有已经做了的、正在做的、还没做的需求和功能都管理起来,可以从两个维度进行管理:空间维度-功能列表以及时间维度-需求流程。

在这一部分作者列举了很多案例,个人感觉MVP的设计和项目的管理也是需要在案例和实操中寻找经验的,在这里就不一一列举,感兴趣的同学欢迎翻阅原著。

#文章纯属个人观点和对本书的理解,期待与大家的沟通和讨论QAQ

本文来自苏格兰圆脸大胖鸡,本文观点不代表PmTemple立场,转载请联系原作者。原文链接:

发表评论

登录后才能评论
分享本页
返回顶部