My Secret Rainbow

产品修炼课

产品修炼课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，维护发布版本，统计问题等；应有尽有，比较适合团队管理。

原文链接