产品修炼课

产品修炼课1:产品的开发流程和团队成员

前言

每个产品经理都应该有自己的一套方法论,别人的经验和方法可以借鉴学习,但真正的路还是要自己走,脚下的坑还是要踩过才能体会深刻。我喜欢做产品,我觉得产品可以带我们提前看到未来,可以探索脑洞大开的创意,可以享受产品发布后的喜悦;虽然苦逼的要命,但每天都面临着不确定的挑战,每天都充满了乐趣。

今天开始,我想从产品角度把之前零散的工作经验做一个系统性的整合,一方面回顾并总结之前踩过的坑,另一方面也分享给有需要的小伙伴们。

产品的开发流程

一套完整的产品开发流程包含从产品的定义、需求分析、产品设计开发到产品的上线运营,每一个环节都是相互衔接紧密配合的,最终形成产品周期的完整闭环。项目有完结的一天,但产品没有,只要有用户喜欢,产品就会持续迭代更新。

产品开发的5大流程:需求、设计、开发、测试、发布;

需求阶段

主要参与角色:、用户研究

产品经理的主要职责:就像启示录里所说的,产品职责就是评估产品机会,确定产品是否有必要做;确定产品解决方案和故事优先级,利用有限的时间和资源把产品做上线。其实这个解释相对比较宽泛,如何评估产品机会是个技术活,要考虑的因素和所需的技能都很多,感兴趣的也可以先看这篇文章《探索产品经理的方法论》

交付物:产品定位、目标用户、产品目标、故事板;个人感觉产品阶段就是把机会转化成故事;

设计阶段

主要参与角色:用户研究、交互设计、视觉设计、demo开发

产品要跟设计团队充分沟通,准确传达产品目标和定位,确保设计团队高质量的完成产品创意;

设计团队交付物:用户调研(定性)、描绘用户画像、确定用户使用场景;梳理信息架构、梳理产品流程、绘制产品线框图和低保真原型图;确定情感关键词、制作情绪板、确定视觉风格、界面及元素设计;演示demo开发;(当然这个交付物相对比较全,实际项目中根据产品的重要和紧急程度,产出相关的交付物即可),设计阶段就是把故事转化成原型的过程;

开发阶段

主要参与角色:技术master,前后端研发;

产品需协助解决开发过程中的遇到的问题,并快速做出决策;

开发团队需完成:产品的开发和实现;开发阶段就是将demo原型转化成可用的产品;

测试阶段

主要参与角色:测试、项目组成员

产品需要协助把控产品质量;

测试团队需完成:用例测试、压力测试、安全测试;

发布阶段

主要参与角色:运维、项目组成员

发布策略:灰度发布;

发布后产品需要跟进:线上产品功能验证、产品推广计划、收集用户反馈、分析点击数据、梳理迭代需求;

产品修炼课

产品开发流程及不同环节的职责范围↑

(说明:用户调研和用户画像是用研跟产品经理并行参与的,但由于部分公司会把用研并入在ued部门,因此会上图暂时把用户画像归为设计职责范围;)

产品的团队

根据产品的开发周期,一个完整的团队需要以下队员。下图中我其实还整合了敏捷团队的角色(技术master),我觉得这是个很重要的角色,他可以和产品探讨解决方案,可以把控开发质量和进度,还有全局的产品边界意识和系统架构规划能力。

产品修炼课

但是实际上很多中小型的互联网公司,其实没有这么多资源,身兼多职的情况比较多,详见上图打星的角色。营销会由产品代劳,用户研究会由交互主导,可用性测试虽然在测试环节,但大部分还是用研来主导。

产品团队的人员配比

在这里干说团队人员配比其实没有实际意义,还要看产品形态,产品所处的生命周期,目标用户群体,团队成员的熟练程度等。

在《启示录》上看到的各主要角色配比,参考下图:

产品修炼课

敏捷团队中也建议产品团队人数控制在5-9人比较合适;

拿我之前的某个产品来说,由于是针对企业内部用户的,而且是优化整合类的产品,很多技术都依赖外部团队的接口,因此我们团队的核心成员配比是:产品1,视觉0.25,开发2,测试1;

还有个营销推广类的产品,针对C端普通用户,做品牌延伸推广并完成拉新的目标,我们的团队成员配比则是:产品1,视觉1,开发2,测试1;当然这里面运维是公共资源,没有计算在内;


产品修炼课2:产品经理应该具备的素质和能力

在人人都是产品经理的大环境下,扪心自问一下,你真的适合做产品吗?具备产品的基本素质和能力吗?

忙碌的校招季

前段时间帮忙准备了一份关于产品岗的校招标准,那先来分享下我们团队期望找到什么样的人,以及我们的培养目标。

  • 基本素质:

1. 思维活跃,有独特的见解;

2. 积极乐观,对产品抱有高度的热情;

3. 强大的责任心和团队合作意识;

  • 培养目标(中级标准):

1. 收集并评估用户需求的能力,团队沟通确定产品解决方案的决策力;

2. 产品框架设计,流程设计,低保真原型界面设计及需求文档的编写;

3. 产品优先级评估,版本规划节奏的把控;

4. 协调内外部资源,推动产品按时按质上线;

5. 上线后跟进数据和用户反馈,持续完善优化产品的能力;

产品经理的类型

入行前,就有前辈跟我说,产品经理是个横向发展的行业,你要什么都懂一点,比如市场,用户、设计、技术,这样才能跟团队角色友好顺畅的沟通,才不会被忽悠,但同时又要有自己的核心竞争力。在阿里是会分两大类型的产品:平台型和业务型。

  • 平台型PD

主要负责用户端的产品,对接设计、开发团队,对用户负责,用户体验为首位。

  • 业务型PD

主要负责产品的运营,需要对市场有较高的敏锐度,能创造更大的商业价值就是他们要考核的目标;

阿里一般简称产品经理为PD,那之后我们主要聊的都是平台型产品。

产品经理的基本素质

产品经理要心态好,不抛弃不放弃,充满正能量,像太阳一样,能自发光发热,带动感染团队。我觉得产品经理最需要具备的基本素质有以下4点:好奇心、同理心、责任心、坚持。

  • 好奇心 – 对一切事物充满好奇,多想一点

产品经理是走在前面的人,所以对任何新鲜事物都要保持一份好奇,用心去观察和探索。产品大师梁宁有提到过一句话:“未来已来,只是分布的不均匀”,又或者启示录里说的,新瓶装老酒,其实是一个意思。

举个栗子,在盒马线下门店,抬头看天花板,会看到很多的输送带和悬挂链,带着各种颜色的购物袋在头顶上滑行,感觉像是游乐场里的倒挂的空中小火车。配货员打包好商品,将袋子挂在悬挂链的挂钩上,然后商品就沿着输送带被送往配送中心。这种自助的配货方式其实在医院的药房早就有了,药剂师刷患者的医保卡,药房后端(据说是机器人)开始配药,药品通过输送带和螺旋滑梯到药剂师手里,药剂师确认后交付给患者,整个流程也就1分钟左右。

  • 同理心 – 快速变身小白用户,从用户角度发现问题

我们的产品是给用户去使用的,因此产品经理要深入到用户中,站在用户的角度去思考,感受用户之痛。

其实看微信、支付宝都是拥有上亿的用户量,但是至今我们都没看到过启动页广告。每次打开都很快,快速的完成我要做的事,用完即走。

淘宝17年底针对中老年人推出了亲情账号,之后网上就有爆出淘宝年薪40万招聘60岁以上的用户研究员,对研究员的要求只要表达能力强,广场舞KOL,有网购经历即可。由此可见,老年人更懂老年人的诉求。

用户研究中有一种方法是“人种学研究”,要求研究人员跟目标用户同吃同住同生活一段时间,深入的去观察和体会他们的生活方式和个人认知。

其实对团队成员和项目干系人,也要有同理心,多换位思考,才能更好的沟通,相处更融洽。

  • 强大的责任心

产品经理要有主人翁意识,像对待自己的孩子一样来打造产品。1岁以内的小婴儿,只会哇哇哭,父母要有足够的耐心来照顾她,感受她的诉求,小心的呵护她成长。事事亲力亲为,即使忙成狗,但是看到她的一丝微笑,心理也是最大的满足。等她到了2-3岁,会走会表达的时候,我们还要耐心的观察她,发掘她的潜能,持续的培养她,让她的未来越来越好。

做产品又何尝不是呢,我们要主动去发现用户的需求痛点,寻求解决方案,排除万难推动方案上线,持续观察分析方案是否真的解决了用户痛点,是否有更优的方案,持续的迭代中,让自己的产品越来越好,变成用户和自己喜欢的样子。

  • 坚持坚持再坚持

拥有了前面3颗心,剩下的就剩坚持了。

产品修炼课

产品经理的能力

  • 取舍的能力

真正考验产品能力的是做减法。在有限的时间和资源里,要实现价值最大化,我们要舍弃什么。之前有个前辈说:“一定做最主要的,可要可不要的坚决不要,把有限的资源投入到有价值的功能上”。

举个之前做年度账单的栗子,因为要赶在年底前发布,资源也有限,那首次营销类活动体验也不能太差,因此我们只能坎功能,直到砍到只剩主干为止;

产品修炼课

  • 节奏感 – 做好产品的迭代

“唯一不变的就是变”。刚开始我很抵触变化,担心给团队带来重复性的工作,担心会影响项目进度,后来使用了敏捷方法后,发现变化随时可以有,只要把控好节奏,合理调整就可以了。敏捷的三大原则:主张简单、递增迭代、拥抱变化。

我们现在的迭代节奏是每周发一个版本,项目里程碑的颗粒度已经精确到小时。比如周四晚要发布,那周三午饭前就要发出提测邮件,午饭后要开下期需求评审和上期总结会。当然这个节奏我也还在试验中,建议大家可以根据团队的规模和外部资源配比来设定,每个节奏维持3周左右,根据实际发现的问题再针对性的调整,最终摸索出最适合自己团队的迭代节奏。

  • 主动推进 – 对自己的产品负责

这是产品经理最容易忽略的一项能力了,敏捷开发团队里没有项目经理的角色,因此产品经理就要承担起项目推动的责任。我的产品需要展示这个数据,需要团队A来提供数据接口,那OK,去找A团队负责人,确认我要的东西是否能提供,什么时候能提供,以哪种方式给到,对接人是谁。这点可以和基本素质里的责任心并行提升,其实都是对自己的产品负责,为团队清除障碍,保证项目顺利前行。

  • 闭环沟通

衡量一个人是否靠谱最重要的一点就是闭环沟通。修炼课1中我们提到了产品开发流程,在流程中每个环节每个角色都需要产品去沟通传达产品定位和目标。沟通就是信息发送方和接收方对信息的编码解码过程,中间势必会造成信息传递上的偏差。建议沟通中采用抛出问题,讨论方案,总结问题的方式,一定不要忽略了讨论后的总结环节。

产品修炼课

  • 专业能力

这方面网上有很多文章介绍,比如市场调研、用户研究、竞品分析、数据分析等,每一点都是需要深入探索和研究的,静下心来,多看,多做,多总结,是个逐步提升的过程。


产品修炼课3:评估产品机会的价值和方法

本文会解答以下3个问题:为什么产品经理要具备评估产品机会的能力?有什么可提升的方法?哪些人最适合用这套方法?

评估产品机会的价值体现

在第1课中,我们提到产品开发流程的需求阶段,产品经理的主要职责就是:评估产品机会,这个概念是启示录里提到的。是的,互联网界从来不缺创意和机会,真正缺的是能准确识别出有价值的创意,抛弃不成熟的创意的人。而这个人要么是老板/CEO,要么就是产品经理。

  • 产品经理最大的价值点在于:

能快速准确的识别出有价值的机会;

能在有限的时间和资源的情况下,按时按质的把想法和机会落地,变成用户可用的产品。

其实大部分中低层级的产品经理做好第2点就可以了,因为第1点很难由自己主导,但这一点却是决定产品经理是否能晋级的更高级别的重要能力体现。

  • 为什么要产品经理培养评估产品机会的能力?

评估产品机会放到用户体验要素里其实就是战略层要考虑的问题,如果产品经理能把自己的思维定位到战略层,那离晋级也不远了。

大部分产品经理都没机会去评估一个产品的机会。那没关系,我们可以缩小粒度,比如从评估一个需求的机会来练手,关键是锻炼思维模式。

当思维模式定型后,再有新需求进来,就不会手足无措的照单全收;竞品出了一个新功能,我们也不会立刻跟风执行;也不用再担心老板经常冒出的一个个新想法了。因为产品经理已经本能的通过自己的思维和决策力,过滤掉了一些价值点不高的需求。

评估产品机会的方法 – 产品画布

之前在《探索产品经理的方法论》这篇文章中提到过评估产品机会的方法论。经过反复尝试,我目前常用的方法就是在自己绘制好的画布上填空。可能我是设计出身,不喜欢看大段的文字,更喜欢看直观的可视化的图表。

绘制自己的画布模板:

我结合《精益创业》和《启示录》两本书里提到的方法,总结了比较适合自己的画布模板,如下图:

产品修炼课

  • 有了画布模板,之后每个产品都是在画布上填空

上图画布上的数字编号是我思考或者着手准备的顺序,无关对错,大家可以不断尝试,找到适合自己的思考方法和工作方式。但是不管做什么,第1步一定是确认问题所在。

第2步就是锁定用户群体,也就是最终使用我们产品的人。

第3点其实更像是产品定位,每个产品都应该有个清晰的定位,为了后期在横向发散时,产品方向不偏移。比如有赞:为商家提供移动端的开店服务工具,围绕这个定位,有赞横向扩展了业务范围,帮商家管店,管钱,管货,管客户。

前3点都在描绘产品的美好创意,第4点有点泼冷水了,开始落地想方案了,因为并不是所有的创意都有切实可行的方案来支撑。

第5点,如何推广自己的产品,一款新产品上市面临最大的问题就是如何让用户知道。

第6、7点是投入和产出,也是领导层比较关心的问题,投入资源可以,能给我带来哪些实际的短长期的收益。

第8,如何评判一个产品的成功和失败,用哪些指标来衡量。

第9,外面有哪些类似的产品,我们区别于竞品的优势是什么。

举个案例,去年春节前我们策划了一个寄祝福的活动,目的是为了提升用户对我们品牌的认知度和情感依赖,意图打造一个线上虚拟物品的寄递平台。在向上层推方案的时候,我们就尝试了发了这么一个画布过去,因为临近春节,时机也恰好合适,因此方案很快就被立项了。因为隐私问题,下图画布里我抹掉了部分数据。

产品修炼课

验证产品机会

从产品层面评估完产品机会后,最好邀请用户和团队干系人一起参与验证,测试产品的创意和用户/市场的需求是否契合。

  • 契合分3个维度:

问题-方案的契合:产品的解决方案是否解决了用户日常的代办工作、痛点、以及期望得到满足的额外惊喜。

产品-市场的契合:验证用户是否真正想要我的产品和方案。精益创业里提到一个测试方法,问用户是否愿意花xx钱来购买xx产品,哪怕你的产品是免费的。

商业模式契合:证明我的产品的商业模式是可实现和和盈利的。

举个之前做年度账单的例子,我们是做了前2个维度的契合。在确定好产品方案后,我们有发送问卷来邀请用户试用我们的产品,并对点击查看的欲望和二次分享的欲望进行打分,以及活动每个页面进行评分。最终根据实际反馈数据,进行局部优化调整后,项目才正式进入设计和开发阶段。

多这个验证的环节其实也就多1天的工作量,但是大大提升了我们产品成功的机会。因为这是第一次做活动,没有基础数据做参考,刚开始产品指标定的很模糊。但作为产品经理,通过这轮验证,让我心里更有底,可以更准确的制定产品目标。其实拿这份数据出来,对跨部门的协调推动和团队的信心也起到很大的作用。

哪些类型的产品经理适合使用画布

产品画布的方法推荐给那些表达能力不是特别强的产品经理们,如果你想找高层要资源来支持自己的想法,可以试试这种方式,更直观明了,一张图发过去对方1分钟就能看懂是要干嘛,要投入多少成本,成功几率有多大。

而对于技术不是特别强的产品经理来说,把这张图发给团队成员,大家也能很快的了解产品经理的想法,甚至会主动想办法帮助产品经理去达成目标。


产品修炼课4:产品经理和用户故事userstory

用user story来代替prd,不仅清晰直观,还能提升团队的沟通效率;玉米大人分享一些写故事和切故事的方法及注意事项。

我跟用户故事的渊源

记得13年初有参加过敏捷咨询师Daniel Teng一个工作坊,导师给我们布置的任务就是每组从自己日常生活的痛点出发,自由发散的去想一个创意点;之后团队成员自己分角色扮演不同的用户类型,上去讲故事;然后从故事里抽离出产品需求,根据需求在卡片上画低保真的原型;每个团队依次把原型卡片贴在白板上,按用户体验流程去讲;最后大家投票评选出公认的价值点高的产品。

当时只觉得整个过程很有趣,并没有真正放在心上。我真正开始写用户故事,是在去年使用快速迭代的开发方式后,每次完成几个独立的用户故事,快速上线给用户验证,及时发现问题,快速调整。使用下来不仅不用写长长的prd文档了,团队沟通效率更高了,用户和公司高层都能更快的看到我们的产品的更新迭代。

论讲故事的重要性

  • 什么是用户故事?

用户故事(user story)是从敏捷开发scrum中提出来的。是从用户的角度来描述用户渴望得到的功能,它是一个独立完整的、可直接上线交付的、有一定业务价值的最小粒度的产品。

举个微信的栗子:微信1.0上线了楼层式的单人会话,用户可以在手机上给好友发送文字和照片,以实现在手机端即时免费聊天的目的。1.2版本上线了多人会话,用户可以在手机上发起一个群聊,并邀请相关好友入群,以实现在手机上展开小群组的讨论的目的。这2种会话方式 是针对同类用户的不同场景,每个故事都是相对独立的,又给用户完整的体验,当然业务价值也是显而易见的。

  • 用户故事的价值体现:

告别prd,通过讲故事来提升团队效率

早些年我们写需求文档,前面几页都是标准的模板,关于项目背景、目标、风险等的描述。但现实中开发要么不看文档,要么打开导航,直接跳着找跟自己相关的,漂一眼界面原型图和大概流程,就开干了;而且在需求评审会上,把这10p+的prd文档讲完,没个2小时真搞不定。

上图是我们之前写的prd模板↑

我们写prd的目的是什么?告知团队成员我这个需求的背景或者问题是什么、用户群体有哪些、要实现的目标是什么,解决方案是什么;这些都可以通过一个个短小精悍的用户故事来阐述。

  • 故事+意义=品牌,通过故事来触达人心

不但产品需求可以通过讲故事来简化,后续的营销也离不开故事。记得17年底的时候,顺丰官网的大banner是个微视频,一个老父亲小心翼翼的把户口本递给顺丰小哥,小哥双手接过并微微点头;画面一转,看到一对新人满脸笑容的拿着户口本和结婚证从民政局出来。然后配合顺丰的slogan“承诺,为每一份托付”。

怎么写故事

  • 用户故事的颗粒度

敏捷中有提到epic,即史诗级的故事,然后才是user story,其实故事粒度还可以更大,大到为什么做这个产品。在梳理产品需求的时候可以由粗到细,先列出粗颗粒的epic,然后切分成小颗粒的user story,用户故事一定要切分的够细,最后是进行分组和排序,产出用户故事地图,也就是我们常见的迭代版本清单。

  • 写故事四字法:起承转合:

其实我们小时候写作文也是用的这个方法,先介绍故事的主人翁及故事背景,然后在这样的背景下,主人翁想要什么或者想达到什么样的目的【前面都是起】,但是现实中遇到了哪些问题或困难导致很难实现目的【承】,后来他做了什么事或者哪些努力【转】 ,最终历尽千辛万苦实现了目标【合】。

接下来我们结合产品经理梳理需求的思路来提炼重点:

主人翁—user(角色)

故事背景—scene(场景)

想要什么或者想达到什么样的目的—Want(目的)

遇到了哪些问题—defect(问题/不爽)

他做了什么事或者哪些努力—Action(行动)

举个栗子:

小c的工作需要经常出差,有次忘记定酒店了,当时已经很晚了,跑了一天也很累,晚上还要发工作汇报邮件,小c想快速的找个最近的酒店安顿下来。当他在手机上找酒店的时候,还要点开详情页,去看看当晚还有没有空房,有些有空房的价格又高出很多,最后还要到酒店设施里确认下有没有wifi。于是小c就背着电脑包在马路边盯着手机找了好久,找到酒店后我还要把酒店地址贴到百度地图里,最终跟着导航找到了酒店。

  • 用户故事的标准模板:

As a, I want to, so that.

作为一个xxx(某类用户),我要xxx(做一件事),从而达到xxx(某一结果或动机)。

套用这个模板的示例:作为出差在外却没有预定酒店的人,我要找到我现所在地点步行距离内的经济酒店,从而能够睡觉休息、上网处理邮件。

这里有提到角色,其实角色就是交互设计里经常提到的用户画像persona,后面我会单独一章来分享我对persona的理解。不过在之前的文章《产品设计中数据观点和用户画像–课程内容整理》中,有一小部分是对persona的描述,感兴趣的可以先看下~

  • 总结:

个人觉得四字法更适合粗颗粒的史诗级故事,而故事模板更适合细粒度的用户故事。或者说四字法更适合需求梳理初期,可以直观的看到用户使用场景和痛点,而痛点就是我们要解决的问题,而故事模板则更适合技术团队沟通。

如何切故事

  • 为什么要切分故事?

其实user story就是被切分后的epic。在实际项目中,越是高优先级的故事,颗粒度要越小,描述越具体,这样做的好处是:小的故事大家在理解上不容易产生偏差,而且更容易完成,故事越大不确定性就越大(比如外部依赖,前置关联,临时需求插入,团队人员请假等)。

  • 如何切故事?

按工作流程:比如请假流程,可以把简单的首尾故事先切分出来,创建请假单,审批请假单,然后中间各个环节的审批流转作为独立的故事。

按功能操作:比如一般的后台报表都有增删改查的功能,可以按增删改查来切分。

按功能类型:比如接在线支付,微信、支付宝、银联可以拆分为3个故事来完成,当然每个下面还可以再切。

按内容范围:比如酒店详情页,先支持查看酒店基本信息和价格,再支持查看周边交通,地图位置等。

按用户需求层次:把性能和稳定性方面的考虑拆分成独立的新故事;

(说明:这些切分方法部分来自于Richard Lawrence,想了解更多切分方法的可以自己去看下)。

注意事项

  • 从用户是视角来讲故事;
  • 把握好用户故事的粒度:

自己在前期梳理故事,或者给高层讲故事时,故事粒度可以粗一些;但是给技术团队讲故事,粒度要足够细,足够具体。

  • 故事并不是越多越好:

一般一个迭代5-10个故事,维护2-3个迭代周期的故事就可以了,让那些价值不高的故事从你的待办清单里消失吧~(数据仅供参考,具体还要看迭代周期的长短和团队资源的配比,我这个是5天一个周期,2个开发人员的工作量,当然我的故事拆的非常小)。

  • 要有验收条件:

即符合什么要求的故事才算可交付的,也是给测试人员一个测试依据。

写在最后

关于用户故事我也是最近1年才开始使用,踩的坑还不够多,写这篇文章前我又把相关的书和资料都看了一遍,修修改改的写了1整天,希望有经验的小伙伴可以一起交流探讨~~~


产品修炼课5:评估userstory的优先级

通过一个核心+5个基本法则的方法来评估用户故事的优先级;

回顾

刚接手一个新项目,在产品定位、目标等大方向都确定后,我一般会先从两方面入手,用户和产品的边界。用户即真正使用或消费产品的实实在在的人,根据人物特性抽离出用户角色和简单的用户画像;产品边界即我们产品跟外部产品的关联和依赖关系。之后开始写较大颗粒的故事、排序再排序;写小颗粒的故事、排序再排序;依次循环。

在上一节《产品经理和用户故事user story》中,我们已经写了很多故事,也根据一定的规则对故事进行了简单的切分和分组。那这一节我们重点来评估故事的优先级。敏捷的核心思想就是时刻响应变化,因此产品经理日常投入精力较大的一部分就是调整故事优先级。

在《产品经理应该具备的素质和能力》中,有提到产品经理的第一项能力就是取舍。需求永远做不完,但资源总是稀缺,时间永远有限,与其同时做完3个故事,每个故事的用户体验做到50分,不如集中精力把一个核心故事做完整,把用户体验做到90分。

产品修炼课

学会评估优先级不单是产品经理的能力,同样适用于我们的日常生活。比如:我现在要完成本职工作,要写文章看书听鸡汤,要跑步游泳打球,要遛娃聚餐购物……,看似很多事情要做,但是当我把每个待办列出来,重新分类组合,并按优先级排布到每周的特定时间里后,生活也变得有条不紊了。

评估故事优先级的方法

推荐一个核心+5个基本法则:一个核心:确定产品目标;5个基本法则:1. KANO模型;2. CFS评分;3. ROI;4. 重要紧急矩阵;5. 前置需求;

  • 一个核心:确定产品目标

任何故事都是围绕着目标展开的,比如微信,初期最根本的定位是做通讯工具,他会花大量的精力在提升通讯速度方面;

比如寄快递,我2季度的产品目标是订单量达到xxx,围绕着这个目标,我们梳理出可能达到目标的几个维度,针对每个维度再做一层层的故事细化;

产品修炼课

  • 基本法则1:KANO模型

KANO模型是对用户需求进行分类和优先级排序的有效工具,感兴趣的可以去wiki上查看相关介绍。KANO定义了需求的3个层次:基本需求,期望需求,惊喜需求;后来我们团队内部又有同事对此进行了细化,可查看下图:

产品修炼课

  • 基本法则2:CFS评分

这个方法是我之前做交互的时候学到的,很奇怪,网上对这个方法的介绍很少,我这里稍微延伸一下;

什么是CFS?

C:Commonality普适性。

在我们的persona中,有哪些类型的用户会使用该功能?预估用户数大概有多少?

F:Frequency频繁性。

这个功能可能被使用的频次,是天天都会用到,还是偶尔一次?

S:Severity严重不可替代性。

这个功能有没有可替代的方案,用户没有这个功能就无法正常工作了?还是无关紧要,锦上添花的功能?(这里跟KANO有共通之处)

如何使用?

CFS有一套评分规则的,依照下图规则给每个故事进行打分,然后将得出的3个分值相乘,乘积最大的优先级最高。CFS就像一个标尺,我们可以依据统一标准快速的将所有故事进行排序。

产品修炼课

举个栗子(微信运动)

产品修炼课

说明:T=C*F*S的总和

  • 基本法则3:ROI(投入产出比):

完成一个需求所要投入的成本(资源、时间等),产出哪些收益(单量、用户数、业务扩展等),说白了就是投入成本低,产出高的先做。当产品发展到一定的规模,我们是继续投入精力把现有体验从80提升到90分?还是用同样的资源,去开辟新的增量市场?举个栗子,之前收到一个需求,在我们公众号在线寄件页新增一个国际寄件的入口,评估下来这个需求大概需要2人2天完成,但当时我们的资源全部都投入在小程序的研发上,而小程序的研发是个长期的工程,那最终我们暂停小程序,优先上线了国际寄件的业务,不仅对外宣传了我们公司的业务实力,而且带动了国际件的单量增长。

  • 基本法则4:重要紧急矩阵法

很简单也比较通用,直接看下图;

产品修炼课

  • 基本法则5:前置需求

比如微信的微信红包和绑定银行卡2个需求。通过CFS来看,微信红包肯定比绑定银行卡得分高多了(C&F值都很高),但是用户要先能绑定银行卡,才能发红包,绑卡是发红包的预动作,因此当然绑定的需求优先级高了(此处不要钻牛角尖,当然你可以请朋友给你转账,每次通过余额来发红包)。

维护故事的工具

这个完全看个人喜好啦,个人用过的有Excel文档,jira,leangoo。

Excel是我最早使用的工具,给大家截图看下大概的模板。

产品修炼课

个人比较喜欢leangoo,在制作用户故事地图的时候,操作空间大,清晰直观,但是功能相对单一。

现在我大部分时间都在用jira,虽然体验不大好,但胜在功能完善。产品维护待办故事清单,查看燃尽图;master进行sprint版本管理,跟进开发进度等;测试提bug,维护发布版本,统计问题等;应有尽有,比较适合团队管理。

原文链接

- Posted in: Columns

- Tags:

0 条评论 98 次阅读

  1. 既来之,则言之。

发表评论

Top