读书：人人都是产品经理(1)－需求篇

读书：人人都是产品经理(1)－需求篇

Web设计就是“不要让用户思考”，好产品改变世界。任何一个产品用户多可以分为新手、专家和中间用户：给新手使用的产品的一大设计准则就是－无需阅读说明书就能上手。

产品就是用来解决某个问题的东西，同时需要解决用户的问题和公司的问题，一个都不能少！产品功能持续改进过程，其改进方向是：让用户更加省心。

产品管理矩阵式组织，负责规划产品的生命周期，负责产品的上市策略、定价策略、整合营销策略、销售与分销策略。

产品经理招聘广告：根据公司战略，负责产品发展的长期规划，保证业务指标；深入了解业务，挖掘用户的多种需求，不断推出有竞争力的产品；根据产品实施效果及业务发展状况，不断改进产品；组织资源实施产品，对其效益负责；对市场发展趋势有敏锐的洞察力和创新意识及良好的分析、研判能力，能够深刻把握用户需求；制定所负责产品线的发展蓝图和实施路线图。工作职责说明产品经理要做什么，职位要求是说需要什么人。

管理能力，就是在资源不足的情况下把事情做成的能力－学会分配管理资源：信息不足以决策、时间不足以安排周密的计划（办法总比困难多）、人员不足以支持工作强度和难度、资金不足以自由调配！

产品早期决策十分重要，参与初期战略规划，其实早期要做的东西很多，真正实施只是其中的一部分，面对那么多极具诱惑的产品，果断放弃很重要，放弃的原则就是价值观和战略等。出色的产品经理：爱生活、有理想、会思考、能沟通。

产品与商业（市场服务团队）、支撑（财务法务团队）和技术（运维架构团队）都有关系－整天给别人发会议请求。

---

第二章  一个需求的奋斗史

从用户中来到用户中去－以用户为中心，体会真正的用户，为我们提供可持续发展机会－需求来自数据分析、问卷调查、用户访谈等，需求采集人人有责。

需求分析过程：产品经理要听用户的但不要照着做，必须明确我们存在的价值是将用户需求转化为产品需求－给需求做一次DNA检测，确定需求的基本属性、分析需求的商业价值、初评需求的实现难度－计算出需求的性价比。少即是多，有意识的“尽可能多地放弃”。

需求的本质是问题，是理想与现实的落差，发现一个问题，然后设法将其转化为一个任务来解决，理解用户是产品经理最重要的素质之一。相比您的需求，我们可能更重视您的用户需求。终端用户是使用产品的人；而客户是购买产品的人、为产品付钱的人－以用户为中心的思想，以老板为中心的行动。

马斯洛需求层次理论：生理需求、安全需求、社交需求、尊重需求、自我实现需求－减少理想和现实的差距。

优先满足哪些用户需求和产品的商业指标要结合起来考虑－无法满足所有用户的要求。

Persona人物角色：用她进入状态，让了解用户，理解产品，让老板需要时利用它了解状态。

产品过程中随时将用户研究纳入计划《赢在用户：Web人物角色创建和应用实践指南》用户研究方法－怎么说表现了目标和观点，怎么做反映了行为，用户怎么说和怎么做经常是不一致的；定性研究可以找出原因偏向于了解、而定量研究可以发现现象，偏向于证实。

用户研究（需求采集）过程：明确目标、选择采集方法、制定采集计划、执行采集、资料整理，然后进入下一步的需求分析阶段（定性vs定量，说vs做）。

1.定性地说：用户访谈（提纲的开放式问题），问题包括说做不一致（尽量让用户和产品可交互、区分事实和观点）、样本少，以偏概全（识别偏差因素，少样本得出结论－增量验证结论）、用户过于强势往沟里带（牢记访谈目的，话题不对往回收或者尽快结束，不在不合适的对象上花费太多时间）、我们过于强势把用户往沟里带（牢记访谈目的，管好自己的嘴）《软件观念革命：交互设计精髓》

避免一组固定的问题：固定的问题会让被访者产生被审问的感觉，应该准备好问题清单，但清单只起到一个引导作用，并不用照着读。

首先关注目标，任务其次：比用户行为更重要的是行为背后的原因，多问问用户为什么这么做。

避免让用户成为设计师：听用户说，但不要照着做，用户的解决方案通常短浅片面。

避免讨论技术：特别是碰到一些略懂技术的用户，不要与其纠缠产品的实现方式。

鼓励讲故事：故事是最好的帮助设计师理解用户的方法。

避免诱导性问题：比如“如果有xx功能，你会使用吗？”，毫无意义的肯定答复。

定量地说：调查问卷，适合大用户量的信息收集，时间不超过五分钟（开始简单问题，中期需要思考的较敏感的问题，最后个人信息题目）《长尾理论》，覆盖多类型用户，男女比例等，灰度发布，先小范围再大范围。

定性地做：可用性测试，让实际用户使用产品或原型的方法发现界面设计中的可用性问题（招募测试用户：尽可能代表真实用户、准备测试任务、测试过程观察记录、测试结束用户的感受、分析和研究）－不同阶段都可以做，太晚了；需要5个左右的用户才可以发现大部分的共性问题；明确是测试产品而不是测试用户；测试过程中，组织者可以告诉持续时间做那些事情－不要引导和暗示而且观察和记录，结束后小礼品，实在不行再提示，建立长期用户参与设计的氛围。

产品改版可以循序渐进，同时存在版本，小面积实验用户测试，一些页面修改，模仿用户习惯的风格。

定量地做：数据分析，数据敏感商业敏感，数据不会骗人但可能有意无意误读数据，做决策的时候把数据分析需求加进去。

日志分析的商业价值：在对产品足够熟悉的情况下，先做出方向性的假设，再提取相应的数据并分析，得到一些现象，最好是之前没有发现的现象，然后尝试解释，接下来做用户调研修正解释，最终指导产品发展方向－数据分析。

需求采集人人有责，可以用单项需求卡片

生孩子－新产品诞生前从无到有，产品人员采集需求，拉需求；养孩子－运行后有销售和服务，大家一起养，推需求。二手需求卡片让需求分析工作成为每个干系人的义务－至少参与采集的过程，理想状态是产品的所有干系人都参加过需求采集培训，然后在日常工作中养成主动提交需求给产品人员的习惯。

可以用模板降低提交需求成本节省时间，描述一个需求包含的内容，重点描述用户场景，谁在什么时间、地点产生了何种需求：需求编号（报告采集时刻和采集者）、需求类型（功能非功能等）、来源（who产生需求的用户：最好有联系方式，用户背景材料－教育职业岗位等）、场景（ where,when重要信息，用来理解需求发生场景）、描述（what，尽量主谓宾，不要加入主观修饰语句）、原因（Why，为什么，采集者的解释）、验收标准（如何确认需求被满足了－尽量量化语言，无法量化语句解释）、需求重要性权重（满足后1一般到5非常高兴；未实现1略感遗憾5非常遗憾）、需求生命特征（When，需求紧急度，时间持续性）、需求关联（which关联人，关联业务，关联物－用户系统设备和其他产品）、参考材料（引用）、竞争者对比（1差到10好：竞争者满足需求的方式，用户客户对该方式的评价）

产品部门至少应该和销售、服务等部门有平等的地位，坚持不懈地从终端用户那里直接获得需求，才能保证需求可持续发展（接地气）。需求采集应该贯穿始终，大生产运动，不怕荒谬就怕遗漏。

需求采集方法（需求驱动学习）：现场调查、AB测试、日记研究、卡片分类法、自己提需求。要听用户意见，但不能照着做－深翻用户内心根本的需求。

用户需求vs产品需求

用户需求：用户自以为的需求，并且经常表达为用户的解决方案。

产品需求：经过分析，找到真实需求，并且表达为产品的解决方案。

需求分析：从用户需求出发，找到用户内心真正的渴望，再转化为产品需求的过程。分－总－分的过程，一方面不能漏掉提炼用户需求的过程，透过现象看本质，也不能停留在本质上，继续把树干再重新分解成树枝、树叶。

技术分析：树干－树枝－树叶任务分解

满足需求的三种方式：做用户真正需要的功能或服务，减少理想与现实的差距的方法包括提高现实、降低理想、转移需求。产品设计的最高境界－创造需求！但需要一个过程，立足实际。

需求DNA检测过程（需求分析）：需求转化－确定基本属性－分析商业价值－初评实现难度－计算性价比。

用户需求转化为产品需求－团队统一记录用户需求的形式，头脑风暴全面了解用户需求，Excel功能列表（条件格式、筛选、单元格有效性、单元格锁定、隐藏等）－模块、子模块、Feature、任务描述、商业价值描述、商业属性、商业优先级、开发量、性价比、备注。

需求基本属性：编号（唯一性标识）、提交人（负责解释需求）、提交时间、模块（根据产品模块划分－5+-2超过七个重新划分）、名称、描述、提出者、提出时间、BUG编号。

需求属性（分类）：新增功能、功能改进、体验提升、BUG修复、内部需求等

需求属性（层次）：基础、扩展（期望需求）、增值（兴奋需求）Kano模型

产品功能需求+产品非功能需求（性能、可培训、可维护、可扩展……）=产品需求，产品需求+市场需求+开发需求+测试需求+服务需求+……=产品包需求。

需求的商业属性：重要性、紧急度、持续时间、商业价值－商业价值优先级－需求卖点，可以给用户提供什么价值，对公司有什么帮助－产品团队集体讨论+必要干系人，提交人先陈述理解，会前做好功课。

绝对不能因为某个需求商业价值大就马上去做，也不能因为某个需求商业价值不大就不做；反之亦然，工作量－开发量（谁是瓶颈）－初评允许有误差（鸡蛋评估问题）－评估乘以系数。

不要试图满足所有客户，一切皆看性价比=商业价值/实现难度。

需求筛选（需求PK）：需求打包－BRD制作－产品会议－后面再立项。

按产品和职能各有所长－鲶鱼效应。做项目的多快好省终极目标：范围大、时间短、品质高、资源省。

需求打包：最好打包类似功能点－业务逻辑图方式可视化；需求依赖，功能间互相有依赖，提升与平衡团队成员能力，需求粒度大小问题（经验表示最好不要超过5人天）。

战场：产品会议（一月或者几月一次－取决于产品性质），回顾上次会议通过的项目、进展如何、是否需要调整时间进度、是否需要添加资源、是否有重大需求变更、已发布项目数据表现如何、有什么问题等=汇报+积累经验，使用商业需求文档为武器，拿出三五个占满2-3倍的潜在资源（产品间争夺为辅，产品内争夺为主）。

武器：商业需求文档BRD/MRD市场需求文档/PDR。BRD（可以搞个有意义的名字）包含项目背景（我们在哪里？为什么做这个项目？解决了什么问题，可以列出一些数据说明项目的必要性）、商业价值（我们去哪里？老板最关心这个，说到点子上，数字变化）、功能需求描述（我们怎么去？哪些事情达到目标，最好有业务逻辑关系，加点东西让老板砍）、非功能需求描述、资源评估（成本，第二个重点）、风险和对策。  性价比：最少资源获得最大商业价值。

100%的质量去实现75%的数量－吸引用户只是功能模块中的一两个点，有闪光点－见山是山，见山不是山，见山还是山。情愿把一半功能做到尽可能完美也不要把全部功能做出半吊子。做的少不如做得巧，动手前思考有没有成本低，收效大的解决方案－很努力地做错误的事情不好！尽可能多地放弃，在资源有限的情况下找到最有价值的需求，然后把它做好。

需求管理：需求状态（待讨论、拒绝、暂缓、需求中、开发中、测试中、已完成）、负责PD（主人，进入需求中确定）、开发工程师（进入开发中确定）、项目名称、发布时间、备注（重启条件，被拒理由，相关文档等）

需求管理的附加值：统计提交人的需求数量、统计提交时间、发布时间等消息、统计每个模块的需求数量、统计每个分类的需求数量（需求简报）、统计需求的商业价值、性价比变化。

成为产品经理最基本的素质之一就是热爱产品了。公司决定战略前提下，好的产品对我们的帮助要远远大于我们对产品的帮助。