人人都是产品经理

《人人都是产品经理》

推荐语：
经营自己的人生这个最大的产品。
从产品规划到产品实施，从需求管理到产品实现，从产品设计到产出输出，从个人技能到团队协作，从职业技能到学习成长。
自序：
商品解决什么需求，个人发展到战略规划，ppt，用户调研，项目经理，提炼卖点，挑bug。
做事方法和思路，用来解决任何问题，从产品经理的视角看世界。
互联网产品设计的五个层次：战略、范围、结构、框架、表现。

第一章 写给-1到3岁的产品经理
互联网、软件行业的产品经理在概念上究竟有了哪些变化，有了哪些发展?为什么会有 这些变化和发展?这会导致产品经理的职责、技能要求有哪些不同?
产品就是用来解决某个问题的东西。

• 它更多地侧重产品本身“从无到有”、“从有到优” 的过程，更多地涉及了“产品规划、数据分析、用户研究、需求分析、功能设计、项 目管理、敏捷方法”等内容，而不是如传统的产品经理那样，去做已经有了产品之后 需要做的诸如管理产品、推广和营销产品的事情。
  BRD、PRD
  BRD Business Requirement Document 商业需求文档

• 21 MRD:Market Requirement Document，市场需求文档。

• 22 PRD:Product Requirements Document，产品需求文档，在本书第 3.3.1 节的“产品需求文档，PRD”里有详细讲述。
  第二章 一个需求的奋斗史

用户研究，或者说需求采集的过程，都会有如下几步:明确目标、选择采 集方法、制定采集计划、执行采集、资料整理，然后进入下一步的需求分析阶段。
用户访谈中的偏差：用户的真实场景选择，用户的选择偏差，被用户的引导，把用户引导偏离访谈内容。应该准备好问题，确定好目标以及背后的原因条件，
调查问卷：封闭型问题，适合大用户量的信息收集。问题：样本的偏差，样本果茶，问卷内容的细节。
可用性测试是指通过让实际用户使用产品或原型方法来发现界面设计中的可用性 问题，通常只能做少数几个用户的测试，看他们怎么做，属于典型的定性研究。 测试过程和测试结束后用户的反馈。

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

需求采集卡，
现场调查，
AB测试，
日记研究，
卡片分类法，
自己提需求，

用户需求和产品需求的转化
用户需求 VS.产品需求
用户需求:用户自以为的需求，并且经常表达为用户的解决方案。
产品需求:经过我们的分析，找到的真实需求，并且表达为产品的解决方案。
需求分析:从用户提出的需求出发，找到用户内心真正的渴望，再转化为产品需 求的过程。
伟大的需求分析师，可以无视用户想要的东西，去探究他内心真正的渴望，再给 出更好的解决方案，或者说是用户真正需要的东西，这就是本节标题的意思——我们 存在的价值。

之前我们说过，需求来源于理想与现实的差距，那么减小这个差距就有三种方式: 改变现状、降低理想、转移需求。

需求检测
确定需求
确定需求的基本属性：编号，提交人，提交时间，模块，名称，描述，提出者，提出时间，bug编号。
分类:可以分为“新增功能、功能改进、体验提升、Bug 修复、内部需求”等。

通常来说“产品功能需求+产品非功能需求 = 产品需求”，而“产品需求+市场需 求+开发需求+测试需求+服务需求+...... = 产品包需求”，对这些概念感兴趣的同学 可以去查阅“需求管理”相关的资料。
层次:把需求分成“基础、扩展(期望需求)、增值(兴奋需求)”三层，理论 依据参见KANO模型 17。
分析需求的商业价值

准备出发:把需求打个包
做项目，终极目标就是:多快好省，即范围大、时间短、品质高、资源省。
第一，“需求打包”最好打包类似的功能点。 第二，需求依赖，功能互相之间有依赖关系。 第三，需求的粒度大小问题。

战场:产品会议
武器:商业需求文档

BRD 怎么写，都包含哪些内容。 项目背景:我们在哪里?为什么要做这个项目，解决什么问题，可以列出一些数
据说明项目的必要性。
商业价值:我们去哪里?最关键的重点!大老板们最感兴趣的，做了这个项目以 后有什么价值，一定要说在点子上。一般我们还会预测一下相关数字的变化，提出这 个项目的商业目标。
功能需求描述:我们怎么去?通过做哪些事情来达到目标，把打好包的需求描述 一下，可以用功能列表的形式表达，但最好能画出业务逻辑关系。当然我们也经常会 搞点技巧性的东西，比如故意加入一些让老板砍的需求，希望老板砍完之后心有愧疚 不好意思再砍我们真正想做的东西，这有点类似谈判技巧里的玩意，大家可以试试， 但不要在这上面太花心思了。
非功能需求描述:提一下重要的非功能需求，如果有的话。 资源评估:第二个重点!大老板们要看成本，他们在了解达成项目的目标需要多
大的花费以后，才能做出决策。
风险和对策:有的项目会有一些潜在风险，这个时候不妨抛给老板们看一下，并 且给出自己的对策，说不定你觉得是很大的麻烦，在老板那里一句话就可以搞定。而 且由于信息的不对称，我们无法了解某些功能是否会与公司将来的战略冲突，这时候 提出来也是让老板们把一下关。
从 BRD 中的“商业价值”、“资源评估”两个重点中大家可能也发现了，其实本 质上大老板们也是在追求那个词——性价比。大家都希望花费最少的资源获得最大的 商业价值。
商业价值(如图 2-19 所示)，给老板们看他们最关心的指标，比如魔方计划就聚 焦在“活跃用户数”上。
功能需求描述，这里给出了业务逻辑图(如图 2-20 所示)，若能给出一些简单的 Demo 更好，让老板们提前看到产品完成后的样子，很可能成为争取资源的加分因素。
资源评估(如图 2-21 所示)，我们会根据团队的实际情况，重点评估主要功能对 产品设计师、用户体验师、开发工程师的人力需求。

第三章 项目的坎坷一生
项目管理：产品需求到产品管理，确定团队成员、时间计划、沟通方法，约时间、发会议邀请。
从产品到项目
产品VS项目
产品经理靠想，做正确的事，产品要符合市场需求，带来利润。关注产品生命周期，规划整个产品的架构和发展路线，确定产品的定位和受众，预计产品真正的价值和效益。内部驱动，实现产品，输入。
项目经理靠做，事情做正确，在时间、成本、和资源约束的条件下完成目标。按照目标完成项目。若不能盈利也是产品规划的失误。外部驱动，完成任务。

项目计划：

Kick Off会议，誓师大会
项目背景，
项目意义、目的与目标
需求、功能点概述：做什么
项目组织架构：负责人
项目计划：时间节点
沟通计划：时间调整

文档：BRD、MRD、PRD、FSD。
PRD内容：修订历史、项目概述、功能范围、用户范围、词汇表、非功能需求、其他说明。
视觉层面的描述，页面大小，颜色，字体，字号。
界面细节，引用界面规范文档
交互细节，引用交互规范文档
文案细节，引用文案规范文档

UML：类图、用例图、状态图

需求评审

测试

Bug描述：缺陷级别、所属产品项目、Bug名称、Bug描述。

项目管理
文档：建立自己的文档规范
流程管理
项目VS.流程

商业评审与技术评审

第四章 我的产品我的团队

产品生命周期：
创新者、早起追随者、早起主流用户、晚期主流用户、落伍者。
商业、产品、技术
设计：战略层、范围层、结构层、框架层、表现层。
搭建框架、填充文字、理顺逻辑、调整风格、后期制作。

设计师：
规划师“结构化思维”，让产品“从无到有”，设计师“形象好表达”，让产品“从有到优”。用户研究员、交互设计师、视觉设计师、前端工程师。

KPI
用户数、活跃度

第六章 产品经理的自我修养
爱生活
好心态
思考学习
沟通

做什么事，解决什么问题，何时做，谁来做，效果如何。