产品读书《人人都是产品经理 1.0》_商业价值

核心技能： 沟通能力、无授权领导能力、学习能力、商业敏感度、热爱产品、注重细节，追求完美、日常产品管理能力
#1 写给－1到3岁的产品经理

为什么要做产品经理

  • 坏产品无处不在：垃圾桶、路标、盲道、洗手间的门、
  • 好产品能改变世界：马桶

我们到底是不是产品经理

  • 产品：用来解决某个问题的东西。可以是无形的服务，也可以是有形的实物。
  • 产品：同时解决用户的问题和公司的问题的东西。

入行

  • 做产品的大前提是喜欢做产品（热爱产品）
  • 找准自己现在的位置：有没有激情，是否够机灵、好学，逻辑思维是不是清晰，沟通表达是否顺畅等
  • 入行切入点：现在本职工作上找到与产品有关的事情上做一些尝试，并考虑先从产品经理周边的职位做起。

一个产品经理的－1到3岁

  • 入行半年后，学习“怎么做”
  • 入行一年后，开始问“做多少，怎么做”
  • 入行两年后，项目与团队
  • 入行三年小结，战略与修养
2 一个需求的奋斗史

需求的奋斗史：从需求被发现到决定实现的过程。

产品读书《人人都是产品经理 1.0》_商业_02


需求采集的过程：明确目标、选择采集方法、制定采集计划、执行采集、资料整理。之后进入需求分析阶段。

需求分析：从用户提需求出发，找到用户内心真正的渴望，再转化为产品需求的过程。

2.1 从用户中来，到用户中去

2.1.1 “从用户中来，到用户中去”的含义：

  1. 需求或直接或间接都是“从用户中来”，所以要“到用户中去”
  2. 产品的设计过程是一个闭环，需求的源头是用户，产品发布之后，在整个产品的生命周期中，仍然要不断的“到用户中去”收集反馈，作为产品改进的依据。

正确地理解用户，是产品经理最重要的基本素质之一。
发现一个问题，然后设法将其转化为一个任务来解决。
###2.1.2 人类为什么有需求

因为生活中存在太多的问题，从而导致了不满意，而问题就是“理想和现实的差距”，于是，人类很自然地产生“减少甚至消除这个差距”的愿望，这就产生了需求。

2.1.3 用户vs客户

用户：user，有时也叫终端用户end user，是使用产品的人。
客户：customer，是购买产品的人，也是为产品付钱的人。

不同的用户有重要程度之分，我们必须、也只能有所偏重。
试图满足所有用户的需求是一个灾难，那会让产品变成一个臃肿不堪、谁都不满意的四不像。
我们无法满足所有用户的需求。
优先满足哪些用户需要和产品的商业目标结合起来考虑。
###2.1.4 描述用户－人物角色persona

产品读书《人人都是产品经理 1.0》_商业价值_03

2.1.5 用户研究的方法

产品读书《人人都是产品经理 1.0》_商业_04

  • 横向：用户的说与做
    a. 怎么说表现了目标和观点，怎么做反映了行为，用户怎么说和怎么做经常是不一致的。
    b. 既要看用户怎么做，也要听用户怎么说，虽然他说的也不一定是真话。
  • 纵向：定性与定量
    a. 定性研究可以找出原因，偏向于了解；
    b. 定量研究可以发现现象，偏向于证实。

案例：
第一轮，听用户定性地说，确定产品的方向，做什么？随机抽样40个用户做访谈，据此写出需求列表。
第二轮，听用户定量地说，确定需求优先级，先做什么？投放了20万份调查问卷，确定了需求优先级的排序。
第三轮，看用户定性地做，要先做的那几个需求，应该怎么做？一边设计，一边陆续找了10个用户来验证，做可用性测试。
第四轮，看用户定量地做，根据产品的用户使用情况做数据分析，不断改进产品。
但是，一般公司是不会在用户研究上投入这么多时间与人力，更多会视情况采用简化方案。

要坚决杜绝“经组织研究决定，用户需要一个xx功能”这些事件的发生，要实实在在把用户当作需求之源。

2.2 需求采集

产品读书《人人都是产品经理 1.0》_商业_05

2.2.1 定性地说：用户访谈（开放式问题较多）

常见的问题和决策：
（1）“说”和“做”不一致的问题----->说+做
（2）样本少，以偏概全的问题---->增量的方式
（3）用户过于强势—>引导到主题或尽快结束对话
（4）我们过于强势—>牢记访谈的目的，管好自己的嘴

2.2.2 定量地说：调查问卷（封闭式问题较多）

时间<5min；（简单题、较为敏感的放中间、个人信息放最后）
常见问题和决策：
（1）样本偏差（样本与目标用户）
（2）样本过少
（3）问卷内容的细节（无引导性、）

2.2.3 定性地做：可用性测试

步骤：
（1）招募测试用户（尽可能代表用户群体）
（2）准备测试任务
（3）测试过程（观察用户操作过程）
（4）询问测试者的主观看法和感觉；
（5）研究和分析
常见问题和对策：
（1）可用性测试做的太晚—>（各个阶段都要做）
（2）一定要做可用性测试
（3）测试产品而不是用户
（4）用户“发声思维”，我们不做引导，只做观察和记录，

2.2.4 定量地做：数据分析

常用用户使用产品日志分析、客户管理系统里的信息、网页访问情况的统计信息等；

常见问题和对策：

（1）科研和实际生产的区别

（2）不要误读数据

（3）时刻准备做数据分析

需求：一手需求 > 二手需求

单项需求卡片：

一张单项需求卡片描述了一个用户的需求到底包含哪些内容，重点是描述用户场景，谁在什么时间，地点产生了何种需求。

产品读书《人人都是产品经理 1.0》_商业价值_06

需求采集

  • 现场调查
  • AB测试
  • 日记研究
  • 卡片分类法
  • 自己提需求（需求驱动学习）

2.3 需求分析

用户需求 vs 产品需求（转化即需求分析）
Y理论
攀梯术
满足需求的三种方式

  • 提高现实。常用的方法是开发某种产品，也是最笨的方法。
  • 降低理想。不要忽视精神的力量。“打预防针”、“丑话说在前头”等。
  • 转移需求。因为人的注意力是有限的，所以引导用户去关注其它事物

    • 产品读书《人人都是产品经理 1.0》_商业价值_07

  • 1、需求转化（用户需求转化为产品需求–头脑风暴）
    产品需求列表（feature lists功能列表）

    • 产品读书《人人都是产品经理 1.0》_商业_08

  • 每行是一个产品需求，每列是产品需求的一种属性
    用户需求和产品需求（多对多）
    2、确定需求基本属性

    • 产品读书《人人都是产品经理 1.0》_商业_09

  • 需求种类：
    产品需求=产品功能需求+产品 非功能需求
  • 分类：新增功能、功能改进、体验提升、Bug修复、内部需求等；
  • 层次：基础、扩展（期望需求）、增值（兴奋需求）–KANO模型
    3、分析需求的商业价值：方法 加权平均
  • 重要性：
  • 紧急度：
  • 持续时间：
  • 商业价值（上也有相机）
    4、初评实现难度
    工作量、开发量（人天）
  • 绝不能因为某个需求的商业价值很大就马上去做，也不能因为另一个需求的商业价值不大就不做。
  • 绝不能因为某个需求的实现难度很小就马上去做，也不能因为另一个需求的实现难度很大就不做。
  • 一切皆看性价比（商业价值/实现难度（开发量））。
    备注：
    信息架构IA-为信息和用户认知之间搭建一座桥梁，实习直观表达的载体，是研究信息的表达和传递。
    “5±2模块”二级模块

2.4 需求筛选

产品读书《人人都是产品经理 1.0》_商业价值_10


做项目，终极目标时多快好省。即范围大、时间短、品质高、资源省。

2.4.1 需求打包

  • 最好打包类似的功能点。
  • 需求依赖，功能相互之间有依赖关系。
  • 需求的粒度大小问题。
    2.4.2 BRD文档

BRD:business requirement document,商业需求文档
PRD:product requirement document 产品需求文档
MRD:market requirement document 市场需求文档

项目背景：我们在哪里为什么要做这个项目，解决什么问题，主要列出一些数据说明项目的必要性。
商业价值：我们去哪里？重点！老板最感兴趣的。做这个项目以后有什么价值，还可以预测一下相关数字的变化，提出这个项目的商业目标。
功能需求描述：我们怎么去？通过做哪些事情来达到目标，把打包好的需求描述一下，可以用功能列表来表达，最好能画出业务逻辑关系。
非功能需求描述：如果有，提一下重要的非功能需求。
资源评估：第二大重点！说清楚达成项目的目标需要多大的花费。
风险和对策：提出潜在风险，老板会给出对策。
老板关注性价比：商业价值&资源评估
马云：少做就是多做

2.5 产品迭代

需求的周期

产品读书《人人都是产品经理 1.0》_产品经理_11


2.5.2 需求管理的附加值

统计每个“提交人的”需求数量

统计“提交时间”、“发布时间”等信息

统计每个“模块”的需求数量

统计每个“分类”的需求数量

统计需求的“商业价值”、“性价比”变化

产品读书《人人都是产品经理 1.0》_产品经理_12

3 项目的坎坷一生

产品读书《人人都是产品经理 1.0》_商业价值_13

3.1 从产品到项目（维度1）

项目：只会进行一次，包含多项相互关联的任务，并且有绩效、时间、成本和范围限制的一项工作。

做项目 VS 做产品

  • 从生命周期的角度看
    产品(长）-项目（短）
  • 从具体要做的事情看
    产品（不断修正自己的判断，给出适宜的创新）
    项目（有明确的目标，更注重计划与控制）
  • 从产出物的角度看
    项目的产出物经过改造会成为通用的产品，有的产品经历个性化定制实际也是一个项目。
    产品经理VS 项目经理
  • 产品经理product manager：内部驱动。做正确的事，靠想。
    项目经理project manager：外部驱动。把事情做正确，靠做。
    产品经理管项目

一个事物必然有它的两面。如果你只看到了一面，说明你只看到了一部分，这时你一定要跳出去，寻找另一面，之后再努力寻找“对立”背后的“统一”。
##立项
做项目的本质是在保证品质的前提下，在时间要求、人财物花费、项目范围三点上做平衡。
1 团队组建

  • 项目督导委员会（买单背锅-获批准进行任务执行）
    • 项目经理
      • PD
      • 开发经理
      • 测试经理
      • UE
      • 服务团队
      • …

2 计划确定

  • 评估“工作量”–“三点估算法”（最乐观、最悲观、最可能的工作量）
  • 推出“工期”
    注：关键路径、里程碑（监控点）

3 沟通

  • 周期：日、周（Eg：晨会、日报、评审会、项目变更申请、发布预告及公告）
  • 渠道（考虑成本效益）：会议、邮件
  • 发起者
  • 参与者

项目启动大会

  • 时间：<15min；
  • 内容：
    - 项目背景
    - 项目意义、目的与目标
    - 需求、功能点概述
    - 项目组织架构
    - 项目计划（项目时间点、里程碑、资源【每个人每个阶段干什么事】）
    - 沟通计划

4 WBS（Work Breakdown Structure）:工作分解结构

需求

1 需求文档写作：

BRD 商业需求文档 最早期 PPT;老板、获得认可，争取资源；
MRD 市场需求文档（Feature Lists、业务逻辑图） ；老板、商业目标到技术实现
[PRD 产品需求文档，技术人员]（原型+各种图）(javascript:void(0))
FSD 功能详细说明，技术人员

2 评审

  • 需求评审：PRD评审、UC评审、 Demo评审的统称。于需求的相应部分完成以后进行，评审会上pm把PRD和UC说给开发和测试听， Demo评审则由UE主讲。
  • 设计评审：在概要设计与详细设计完成之后进行，由开发工程师把对需求的理解以设计文档的形式说给pm、测试听。
  • 测试评审：俗称TC评审，是在TC编写完成、测试开始执行之前进行，由测试工程师把对需求的理解以TC的形式说给PM、开发听。

需求评审会需要：一个能做决定的人；一个与此项目有关的产品接口人。
需求评审通过：里程碑

开发

测试

产品读书《人人都是产品经理 1.0》_商业_14


TC

TC的内容：测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等。bug

1、bug级别的定义标准

2、bug状态流转图

产品读书《人人都是产品经理 1.0》_产品经理_15

发布

SVN管理员：代码版本管理员、负责项目的每日代码更新。
发布标准
发布过程
发布手续和各种表签字画押
项目发布公告！！！安慰一下众战士！！！
项目总结！！！

3.1 项目管理（维度2）－文档管理、流程管理、敏捷方法

计划与控制，就是项目管理。

PART1:文档管理

  • 建立自己的文档规范

    • 产品读书《人人都是产品经理 1.0》_商业价值_16

  • 文档模版的作用
    1 让经常看同类文章的人提高效率
    2 让写文档的新手快速上手
    3 让写作者不会漏考虑某些内容

  • 产生文档版本管理的本质需求是多人合作，协同办公。(SVN)

PART2:流程管理

流程的本质：
当年的英雄把自己的个人经验转变成显性知识表达出来，而对于经常做的事情，就可以用流程这种形式固化、传承，后人在做这些事情的时候起码不会太无助。在这点上，规范、模版的作用也类似，这也是团队核心竞争力的一种。
注：
UED:used.taobao.com
DCP (Decision Check Points）商业评审点
LMT(Life-Circle Mangement Team）生命周期管理团队
评审：
商业评审：产品会议、功能评审
技术评审：需求评审、设计评审、测试评审、发布评审

PART3：敏捷方法

  • 有计划，更要“拥抱变化”
  • 迭代周期内尽量不加任务
  • 集中工作，小步快跑
  • 持续细化需求，强调测试
  • 不断发布，尽早交付

敏捷沟通：在任何情况下，我们都要做好手头的事情，确保“这事就算对公司来说黄了，我们也要通过这件事情有所收获。”

**注：**瀑布模型vs敏捷方法

物竞天择适者生存

1 老板项目(TRQ)

  • 时间T是给死的。我们最常犯的错误就是把老板的偏好当成规则。老板只是一时说最好怎样，结果我们理解成必须怎样，那就亏大了。
  • 数量Q（项目范围）是可变的。列出需要的功能、优先级、所需的资源，让老板选。
  • 资源R是丰富的。项目优先级较高。
4 我的产品，我的团队

产品读书《人人都是产品经理 1.0》_商业价值_17

4.1 大产品，大设计，大团队

4.1.1 产品之大

  • 时间之大：产品生命周期

    • 创新者innovators：新鲜感强，消费能力强，忠诚度不高，需要新鲜的东西不断刺激。
    • 早期追随者early adopters：观念比较新，需求目的性强，需要迅速能够解决问题的产品。信息达人，不盲目试用，忠诚度高。
    • 早期主流用户early majority：实用主义者，是产品大规模产生商业价值的用户群。
    • 晚期主流用户late majority：对新产品存在抵触。
    • 落伍者laggards：附加值较低的最后一批用户。

      • 产品读书《人人都是产品经理 1.0》_商业价值_18


  • 空间之大：商业、产品、技术

    • 商业：在公司里主要由市场、销售、服务等部门来考虑，他们决定产品的销售渠道、价格策略、促销策略、服务方式等。
    • 产品：包括产品设计、用户体验、产品运营部门等部门来考虑，他们决定了产品的功能范围、交互流程、视觉表现、运营手段等。
    • 技术：主要由开发、测试、运维等部门考虑，他们决定了产品的稳定性、性能、bug数量等特性。

4.1.2 设计之大

产品设计的五个层次

  • 战略层：明确商业目标和用户需求，找准方向，重点是解决两者之间的冲突，找到平衡点。
  • 范围层：明确“做多少”。对于软件类产品，确定功能范围。对于网站类产品，确定内容范围。
  • 结构层：考虑产品的各个部分相互之间是什么关系。
  • 框架层：用户可见的东西。对于软件类产品主要是界面设计，对于网站类产品主要是导航设计，两者都有的是信息设计。
  • 表现层：视觉设计和内容的优化，比如页面配色、字体字号等。

设计的三个层次

  • 第一个层次，本能水平的设计是基础，产品要有用。
  • 第二个层次，行为水平的设计是保证，产品要能用。
  • 第三个层次，反思水平的设计是升华，是难以捉摸的“用得爽”。

4.1.3 团队之大

产品读书《人人都是产品经理 1.0》_产品经理_19

  • 如何设计各种职位，让各种人（职员）与各种事（职责）相互匹配。
  • 接口人存在的价值
  • 矩阵型组织

4.2 产品团队

产品读书《人人都是产品经理 1.0》_商业_20


规划师VS 设计师

  • 规划师更多的是“结构化思维”，保证产品有用，能满足用户的某些需求，让产品“从无到有”。
  • 设计师更多的是“形象化表达”，保证产品好用，能让用户用起来舒服，让产品“从有到优”。

用户体验部门

  • 用户研究员user researcher：利用各种方法进行用户研究，给产品决策提供建议。
  • 交互设计师interaction designer：负责人机交互页面、用户操作流程的设计，典型的工作有导航设计、信息设计，必须了解很多商业的内容，理解功能的商业价值。
  • 视觉设计师visual designer：主要做视觉设计，即用户第一眼看到的效果，比如页面结构、配色方案、字体字号、按钮的形状、颜色、大小、质感等。
  • 前端工程师web developer：运用前端技术进行web开发，实现产品体验的良好传达。

运营师

4.3 商业团队

团队组成：市场、服务、营销

4.3.1 好产品需要市场化

  • 定价与促销：

当自己对某个领域不熟悉的时候，做起事来总会把问题想象得很复杂，把自己知道的所有知识都用上，而真正的高手，是可以一下子就找出问题的关键，然后用最简单的办法搞定。

  • 销售与渠道：

销售：直销vs分销（通过渠道（代理or经销））
注：代理：赚佣金；经销：赚差价

  • 产品的版本细分
  • 做功能区分，打细分市场。
  • 为了促进销售，利用消费者心理，纯策略性地作出“炮灰版”。
  • 水平营销

纵向营销是进化，水平营销是革命；

  • 需求维度
  • 目标维度
  • 地点与情景维度
  • 时间维度
  • 体验维度
  • 有形的产品与服务
  • 品牌特征
  • 使用或购买
    ###4.3.2 我们还能做什么
    数据分析：
    提供支持，提供核心功能与卖点
    部门视角
  • 服务部门是为昨天的利润工作，给已经购买产品的客户提供承诺的价值。
  • 销售部门是为今天的利润工作，把产品变成利润，争取更多的客户。
  • 开发部门是为明天的利润工作，确保明天我们有优秀的产品可以卖。
  • 研究部门是为后天的利润工作，了解趋势、发展科技，保证永远处于领先的位置。

4.4 技术团队

  • 开发团队：负有架构、编码等职责
  • 测试团队：做功能、性能等各种测试等工作
  • 运维团队：管理产品的数据库、服务器、软件配置

合作：超级理性的人很明白“没有规矩，不成方圆”的道理，他们喜欢被规则管而不是被人管。
##4.5 支撑团队
老板、财务、法务、行政

让老板做问答题➡️让老板做选择题➡️让老板做判断题。

5 产品的灵魂：战略

5.1 说战略

产品和产品经理（产品帮PM，互相帮助，PM帮产品）

战略如何炼出来

  • 以价值观Value为根基
  • 思考公司或产品的使命Mission和愿景Vision

培养大局观：站得高看得远

  • 帕累托改进

5.2 制定战略：可行性分析

产品战略的具体制定，在项目管理里叫“可行性分析”，在产品设计层次的角度叫“战略层”，在公司层面可能叫“战略规划”。
完成“可行性分析”，也只是决定“做不做”，还完全没到“做多少”、“怎么做”的阶段。
###（1）我们在哪儿

  • 价值观

  • 使命

  • 愿景

  • 行业（市场扫描）

    PEST分析

  • 竞争对手（竞品分析）

a $APPEALS分析法：太过冗杂
b 上网搜相似产品+看行业分析报告+咨询公司

  • 自身情况（自我分析）：行业积累、技术积累、缺点

SWOT分析法

（2）我们去哪儿

  • 细分市场是什么（需求场景）？

需求层次
战略管理和市场细分方法：安索夫矩阵、BCG矩阵、波特五力模型、GE矩阵、战略地图、SPAN战略定位分析、价值链分析法等
电子商务三流：信息流、资金流、物流

  • 目标用户是谁？

  • 解决他们的什么问题（需求）？

    注释：

    CRM 用户关系管理软件
    OA 办公自动化软件
    SCM 供应链管理软件
    HRM 人力资源管理软件
    ERP 企业资源计划

（3）我们怎么去（策略）

  • 用什么产品满足需求？
  • 产品的核心竞争力？

5.3 执行战略

1 产品路标规划Roadmap（指明方向）

产品读书《人人都是产品经理 1.0》_商业_21


2 靠谱的会议（修正方向）

  • 开会和做产品是一样的，不要试图在一个会议中解决很多问题。
  • 大会决定小事，小会决定大事。大小只参会人数。
  • 要想让会议不流于形式，就要把会议本身变成形式。
  • 所有人提供意见，少数人讨论，一个人拍板。《罗伯特议事规则》
  • 会议记录

    • 产品读书《人人都是产品经理 1.0》_商业_22


5.4 绩效考核

SMART原则

  • 具体specific：绩效考核要切中特定的工作指标，不能笼统。
  • 可度量measurable：绩效指标是数量化或者行为化的，验证这些绩效指标的数据或信息是可以获得的。
  • 可实现attainable：绩效指标在付出努力的情况下可以实现，避免设立过高或过低的目标。
  • 现实性realistic：绩效指标是实实在在的，可以证明和观察。
  • 时限time bound：注重完成绩效指标的特定期限。
    产品设计的好坏是假的，用户体验的好坏也是假的，只有商业利益的多少才是真的！

多个目标间权衡：产品设计、用户体验都是假的，只有商业利益是真的！

6 产品经理的自我修养

就业保障会降低一个人的竞争力，职业保障可以提高竞争力。假设有一天，公司突然不需要你了，这时候你不用去找工作，而是有一堆公司马上排着队请你去，这才是真正的保障。

  • 个人品牌建设
  • 只有方法，没有答案。
  • 会思考，活到老学到老
  • 沟通不是为了说服，而是更好地认识世界。

提需求用户的分析思路

骂得人是不是典型用户？他的观点能代表多少人？他的影响力有多大？他是不是只是“嗓门大”的用户？他说的是不是解决方案？他的本质需求是什么？把他的需求加入需求列表里应该标什么级别？什么属性？…

解决问题的通用思路

为了什么？做什么事，解决什么人的什么问题？何时做？谁来做？效果如何？

  • 为了什么？
    做某件事情“为了什么”，是大前提。
  • 做什么事，解决什么人的什么问题？
    事前需要考虑的，其中“什么问题”和“什么人”是指用户需求和目标用户，“做什么事”是从用户需求转化而来的产品需求。
  • 何时做？谁来做？
    事中关注的重点。项目和团队，重点是计划、控制和执行。
  • 效果如何？
    事后需要讨论的。主要是总结、反馈一类的观点，都是对这个问题的回答，想清楚了才能持续改进，不断提高。