人人都是产品经理

第1章 写给-1到3岁的产品经理

为什么要做产品经理

• 坏产品：无处不在的危险

  • 产品的用户总是分为新手、专家和中间用户
  • 产品功能的改进方向：让用户更加省心

• 好产品：改变生活、改变世界

我们到底是不是产品经理

• 产品究竟是什么

  • 产品就是用来解决某个问题的东西

    • 可以是有型实物或无形服务

    • 解决问题：满足人们的需求进而产生价值

      • 价值不仅给产品的使用者，还要给产品的创造者

    • 并不是所有的产品都是商品，也有公益性、非盈利的产品

      • 工作中的产品绝大多数都是在用户目标及公司商业目标中寻找平衡

        • 只考虑用户，公司无法盈利
        • 只考虑盈利，用户留不住

• 产品经理的由来

  • 第一个产品经理

    • 美国保洁公司

      • 有专人对一个产品负责

  • 出现原因

    • 适应公司发展需要

      • 随着企业规模增大和产品的增多，无法适应部门组织机构

        • 产生的产品管理的矩阵式组织

• 互联网公司产品经理的招聘要求

  • 侧重产品“从无到有、从有到优的过程”

  • 涉及内容

    • 产品规划
    • 数据分析
    • 用户研究
    • 需求分析
    • 功能设计
    • 项目管理
    • 敏捷方法

• 互联网软件行业的产品经理概念

  • 与传统产品经理概念的区别

    • 行业形态

      • 传统行业

        • 成熟行业

          • 市场成熟、产品定型
          • 用户成熟、熟悉产品

      • 互联网软件行业

        • 新兴行业

          • 产品变化速度快

            • 用户看什么都是新的
            • 需要产品推陈出新、先入为主、占领用户主导用户习惯

    • 产品形态与成本结构

      • 传统行业

        • 实物

          • 考虑打通整个供应链

      • 互联网软件行业

        • 虚拟物品

          • 团队规模小
          • 成本更多花费在研发过程

    • 生命周期

      • 传统行业

        • 研发周期长，几年以上

      • 互联网软件行业

        • 研发周期短，几个月左右

          • 推崇敏捷方法

            • 产品经理兼顾项目管理

    • 赢利模式

      • 传统行业

        • 单一卖产品赚钱

      • 互联网软件行业

        • 产品大部分免费

        • 赢利与用户数相关

          • 重视用户研究、数据分析工作
          • 赢利问题有相关团队负责

    • 用户心态

      • 传统行业

        • 花钱用

          • 即使不爽也凑合着用

      • 互联网软件行业

        • 免费用

          • 稍有不爽就去试用新产品

            • 更重视用户体验

              • 产品经理涉及交互设计、视觉设计、文案设计

  • 非典型产品经理

    • 职责交给几个人，很少有全能型（除非事业部总经理或CEO）

  • 一线员工眼中的管理

    • 在资源不足的情况下把事情做成

      • 信息不足以决策
      • 时间不足以安排周密的计划
      • 人员不足以支持工作的强度和难度
      • 资金不足以调配

我真的想做，怎么入行

• 确定自己真正喜欢

  • 从产品设计中思考问题背后的本质
  • 思考如何设计才能平衡用户目标和商业目标

• 找到自己的位置

  • 面试官考察方面

    • 是否有激情、是否机灵好学、逻辑思维是否清晰、沟通表达是否顺畅

• 可行切入点

  • 尝试做与产品有关的事情

  • 从产品经理周边的职位做起

    • 开发

      • 预先了解需求，在需求评审会上提出自己的建议
      • 可从需求分析师入手，不断培养商业感觉

    • 运营

      • 尝试把活动做成产品
      • 练习写BRD、PRD

    • 项目经理

  • 研究公司招聘广告并做成一份调研报告

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

• 负责产品的各个方面

  • 获得能力的全面提升
  • 经常碰到全新的挑战
  • 需要提高的能力很多

• 入行头半年

  • 打杂的菜鸟

    • 熟悉需求分析相关的基本知识和技能
    • 了解产品的各个方面，功能、用户、技术等
    • 认识团队里的同事和即将合作部门的同事

• 入行半年后

  • 学习怎么做

    • 提升对用户和对需求的理解
    • 负责某些模块，但缺乏整个产品层面的权衡认识和能力
    • 写产品需求文档、配合用户体验部门做demo、跟进开发、测试、发布的过程

• 入行一年

  • 开始问做不做、做多少

    • 负责较多模块直至所有功能

    • 探索做哪些功能

      • 做用户研究

• 入行两年

  • 项目与团队

    • 了解周边团队做什么并施加影响
    • 制定规范、流程，将手头的工作分出去

• 入行三年

  • 战略与修养

    • 出色产品经理的基本修养

      • 爱生活、有理想、会思考、能沟通

第2章 一个需求的奋斗史

从用户中来到用户中去（用户研究）

• 用户是需求之源

  • 人类为什么有需求

    • 需求的本质

      • 马斯洛的需求层次理论

        • 生理需求
        • 安全需求
        • 社交需求
        • 尊重需求
        • 自我实现需求

      • 理想与现实的差距，人们产生“减少甚至消除这种差距”的愿望，所以产生了需求

  • 用户与客户

    • 用户是使用产品的人

    • 客户是购买产品的人

    • 广义用户是所有与产品有关的人

      • 广义用户是需求之源

  • 以用户为中心的思想

    • 中小型公司

      • 需求很大来源不是终端用户而是老板
      • 老板的阅历多，会抓住商机创造价值
      • 老板的观点有时比产品经理更合理

    • 创业公司

      • 没有精力去做用户研究
      • 老板凭经验拍脑袋

  • 不要试图满足所有用户

    • 要区别对待广义用户，对狭义的终端用户也不能一视同仁
    • 需求太多时要进行优先级评估和需求管理
    • 一些用户自己提的需求都是互相矛盾的，所以做不到听到什么需求就做什么功能
    • 产品刚起步时要把池子做大，做一些大众功能满足一般用户的需求
    • 产品充分占据市场时要从已有的用户身上深挖用户价值
    • 也可按照其他维度划分出优先满足的需求如性别、地域、年龄段等

• 你真的了解用户吗

  • 体会真正的用户

    • 真实的用户五花八门，必须真刀真枪去研究他们

  • 描述用户

    • 产品经理可能只是老板的一杆枪，指哪打哪

    • 创建Persona（人物角色）

      • 新人进入团队可以迅速了解用户和产品
      • 老板可迅速进入状态

  • 用户研究

    • 用户研究是前提不是附属内容，必须在做产品的过程中随时纳入计划

      • 《赢在用户：Web人物角色创建于应用实践指南》

        • 用户的说和做

          • 说表现了目标和观点，做反映了行为
          • 用户的说和做经常是不一致的，但两反面都很重要

        • 定性与定量

          • 定性研究可以找出原因，偏向于了解；定量研究可以发现现象，偏向于证实。

      • 例子

        • 第一轮 听用户定性地说

          • 确定产品方向

            • 抽样用户做访谈

        • 第二轮 听用户定量地说

          • 确定需求优先级

            • 投放调查问卷

        • 第三轮 看用户定性地做

          • 设计需求怎么做

            • 找用户做可用性测试

        • 第四轮 看用户定量地做

          • 数据分析

            • 根据用户使用情况做数据分析对产品进行改进

    • 目标：实实在在的把用户当做需求之源

需求采集的大生产运动（需求采集）

• 需求采集的过程

  • 明确目标
  • 选择采集方法
  • 制定采集计划
  • 执行采集
  • 资料整理
  • 需求分析

• 需求采集方法

  • 定性地说：用户访谈

    • 常见问题及对策

      • 说和做不一致的问题

        • 让用户说和做同时进行

        • 区分用户说的事实与观点

          • 描述过程的话可信度高一些
          • 我觉得、我认为的话不可全信

      • 样本少，以偏概全

        • 选择样本要尽量随机

        • 识别出可引起偏差的因素并在访谈报告里表明

        • 以增量的形式做访谈

          • 先选择少量样本进行访谈，得出基本结论，再访谈少量样本，观察结论是否改变。有改变就增大样本量，没有改变就停止访谈。

      • 用户过于强势，带偏话题

        • 要时刻牢记访谈目的，及时纠偏

      • 我们过于强势

        • 牢记访谈目的，管好自己的嘴

    • 用户大会：邀请产品的用户集中开会，短时间获取大量信息

      • 明确目的

      • 资源确定

        • 时间、地点、工作人员、用户、嘉宾、材料、备用方案

      • 现场执行

        • 辅助工作

          • 场地布置、进场前导、主持、送客

        • 主流程

      • 结束收尾

        • 资料整理、运营

  • 定量地说：调查问卷

    • 与访谈的区别

      • 访谈提纲通常是开放式问题，适用于寻找产品方向，很深入；调查问卷封闭式问题比较富哦，大规模收集信息但不够深入

    • 注意事项

      • 作答时间不要超过十分钟
      • 开篇放置简单问题，需要思考和敏感问题放中间，个人信息放最后

    • 常见问题与对策

      • 样本与想了解的用户群体出现偏差

        • 样本选择尽量覆盖目标群体各种类型的用户
        • 保证各种类型用户样本比例接近全体比例
        • 若没法做到样本选择的合理性，在结论处进行标明
        • 将目标群体的特征定义成问题，若有偏差可以筛选出接近目标群体的子集进行分析

      • 样本过少

        • 避免使用百分比分析，使用百分比答案至少要有100份样本

      • 问卷内容的细节问题

        • 问题表述应无引导性
        • 准备不同问卷，每种问卷选项排列顺序都不相同
        • 先进行小范围试答，根据反馈修改后再大面积投放

  • 定性地做：可用性测试

    • 主要过程

      • 招募测试用户

        • 原则是尽可能代表未来真实的用户

      • 准备测试任务

        • 在实际使用中的一些典型任务

      • 测试过程

        • 观察者记录用户完成所要求的任务的过程

      • 测试结束

        • 询问用户对产品的整体看法和感觉
        • 询问用户某些操作的原因

      • 研究和分析

        • 做出一份产品的可用性列表
        • 对问题的严重程度进行分级

    • 常见问题与对策

      • 可用性测试做的太晚

        • 可用性测试在各个阶段都可以做

          • 无任何成型产品

            • 拿竞品给用户做

          • 只有纸面原型

            • 拿着手绘产品给用户做

          • 只有页面demo

            • 拿着demo给用户做

          • 产品可以运行

            • 拿真实的产品给用户做

      • 认为可用性测试太专业所以不做

        • 让同事操作几个任务，即可发现问题

      • 明确是测试产品而不是用户

        • 提前告知用户是发现产品中的问题
        • 减轻用户压力

      • 测试过程中组织者该做与不该做的

        • 开始时告知用户持续时间，让用户心中有数
        • 测试时要求用户在使用产品的同时说出自己的思考过程
        • 做测试时不要给任何的引导和指示，只做观察和记录；用户行为和预想不一样是可以提问；实在进行不下去时给予提示
        • 结束之后送小礼品。给予补偿的事在邀请时就提出来。尽快总结，将报告发给用户。

    • 产品发布后改进的方法

      • 先从部分次级页面改起
      • 新旧版本并存一段时间，让用户自行选择
      • 给一小批测试用户放出新版本做小面积实验
      • 使用用户已经习惯的风格

  • 定量地做：数据分析

    • 过程

      • 数据来源

        • 产品日志
        • 管理系统的信息
        • 网页访问情况的统计信息

      • 分析方法

        • Excel、统计软件、数据库软件或自己编写程序

      • 解读结果

      • 用户访谈

    • 常见问题与对策

      • 过于学术，沉迷科学研究

        • 不需要花费太多成本来做数据分析

      • 误读数据

        • 不要为了迎合一个观点去找数据

      • 临时抱佛脚

        • 产品设计时把数据分析的需求加进去

          • 记录某个按钮的点击次数
          • 统计每个用户的登录频率

  • 需求采集人人有责

    • 二手需求采集工具-单项需求卡片

      • 内容

        • 需求描述
        • 需求编号
        • 来源
        • 场景

    • 尽可能多的收集

      • 贯穿始终的过程

      • 有特点的需求采集方法

        • 现场调查

          • 和客户一起工作一段时间，深度了解需求

        • AB测试

          • 挑选少量用户分别测试不同内容，根据分析结果再决定产品方向

        • 日记研究

          • 研究别人写的产品分析体会

            • 注意写这种日记的往往是同行而不是主流用户

        • 卡片分类法

          • 把各种需求写在便利贴上，让用户一起讨论并完成分类

        • 自己提需求

听用户的但不要照着做（需求分析）

• 明确我们存在的价值

  • 用户需求和产品需求

    • 概念

      • 用户需求是用户自以为的需求，并且经常表达为用户的解决方案
      • 产品需求是经过我们的分析，找到的真实需求，并且表达为产品的解决方案
      • 需求分析是从用户提出的需求出发，找到用户内心真实的渴望，再转化为产品需求的过程

    • 需求分析的过程

      • 分-总-分

  • 满足需求的三种方式

    • 改变现状
    • 降低理想
    • 转移需求

  • 创造需求

    • 产品设计的最高境界
    • 典型场景：老板或开发突发奇想
    • 要脚踏实地

• 给需求做一次DNA检测

  • 把用户需求转化为产品需求

    • 过程

      • 采集的需求非常多
      • 团队举行头脑风暴，了解用户需求。每个人分一块转化为产品需求
      • 过滤掉不靠谱的需求

    • 关系

      • 多对多

  • 确定需求的基本属性

    • 编号

    • 提交人

      • 解释需求的来源，并有义务充分理解原始的用户需求

    • 提交时间

    • 模块

      • 产品的模块数在5±2个比较合理
      • 超过7个要重新划分或增加二级模块

    • 名称

      • 简介的短语描述需求

    • 描述

      • 具体解释名称里功能的意思

    • 提出者

      • 用户需求的提出者

    • 提出时间

    • Bug编号

      • 一些Bug也视为需求

  • 需求的种类

    • 分类

      • 新增功能

      • 功能改进

      • 体验提升

      • Bug修复

      • 内部需求

      • 非功能需求

        • 性能
        • 可培训
        • 可维护
        • 可扩展

    • 层次

      • 基础
      • 扩展（期望需求）
      • 增值（兴奋需求）

    • 对需求的种类区分并不绝对

  • 分析需求的商业价值

    • 衡量指标

      • 重要性
      • 紧急度
      • 持续时间

    • 是需求列表中最核心的部分，对其的判断直接影响产品未来的方向

    • 商业价值描述

      • 需求的卖点
      • 可以给用户提供什么价值
      • 对公司有什么帮助

    • 给商业价值抽象成一个指标

      • 领导决定
      • 打分取均值成本较高

  • 初评需求的实现难度

    • 衡量指标

      • 工作量

        • 开发量

          • 必须评估
          • 允许误差
          • 评估人必须经验丰富，通常是技术经理、系统分析师、架构师

  • 分析需求的性价比

    • 评估

      • 商业价值➗实现难度（开发量）

    • 不能只根据需求的难度大小去做

活下来的永远是少数（需求筛选）

• 人力资源互相争夺

  • 两种组织结构

    • 按产品线划分

      • 对产品有利，产品经理权利更大、资源有保证
      • 各种职能的员工沟通顺畅

    • 按职能线划分

      • 对多个产品间资源共享有利
      • 产品规划决策层面更高，单个产品发展速度降低

• 把需求打个包

  • 注意点

    • 最好打包类似功能点

      • 通过可视化的业务逻辑图方便给人讲解

    • 功能互相之间有依赖关系

      • 经常存在功能和人力资源之间的依赖关系

    • 需求的粒度应相对细

      • 工作量最好不要超过5人天

  • 产品会议

    • 老板们给各个产品分配资源并纠偏

  • 商业需求文档BRD

    • 包含内容

      • 项目背景

        • 解决了什么问题
        • 列出数据说明项目的必要性

      • 商业价值

        • 分析项目的价值
        • 说在点子上
        • 预测相关数字的变化

      • 功能需求描述

        • 描述打包需求

          • 用功能列表形式表达
          • 画出业务逻辑关系

        • 故意加入让老板砍的需求

          • 让老板不好意思再砍

      • 非功能需求描述

      • 资源评估

      • 风险和对策

• 别灰心，少做就是多做

  • 要看重功能的质量而不是数量，哪怕功能不多
  • 选择性价比更高的做法
  • 尽可能多的采集需求，有了大局观后尽可能多的放弃

心急吃不了热豆腐（需求管理）

• 需求的状态

• 需求管理的附加值

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

    • 反映每个人的工作情况

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

    • 看出产品发展速度

  • 统计每个模块的需求数量

    • 看出用户的兴趣，指导产品发展方向

  • 统计每个分类的需求数量

    • 看出产品是在做新功能还是老公能优化，了解产品发展阶段

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

第3章 项目的坎坷一生

从产品到项目

• 定义

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

• 产品与项目的比较

  • 生命周期

    • 产品生命周期相对较长，关注的是整个产品从规划到制造，再到最终维护和消亡的整个过程。

      • 产品结束是不存在的

    • 项目生命周期较短，通常在项目开始以前就有明确的其实和结束时间，通过验收表示其生命周期结束了。

  • 具体做的事情

    • 产品负责人需根据各种内外部信息的变化修正自己的判断，给出适宜的创新。
    • 项目开始时就有明确的目标，注重计划与控制

  • 产出物

    • 产品可批量生产提供大量用户，相对通用；通常用有限的资源满足更多需求。
    • 项目只进行一次，每次都是定制的、个性化的需求，产出物也比较个性化。

• 产品经理与项目经理

  • 定义

    • 产品经理靠想。做正确的事，其所领导的产品是否符合市场的需求，是否能给公司带来利润

      • 关注的是产品的生命周期、产品是否能赚钱。
      • 必须能规划整个产品的架构和发展路线，确定产品的定位和受众，能预计产品的真正价值和收益。

    • 项目经理靠做。把事情做正确，在时间、成本和资源约束的条件下完成目标。

      • 按照目标完成任务就是成功的

• 产品经理兼任项目经理

  • 兼任

    • 对需求管理方便，但总增加新的需求导致项目经常无法按期完成

  • 不兼任

    • 项目经理倾向于简化项目，用户体验不好

一切从Kick Off开始（团队组建）

• 组建团队

  • 项目的组织结构

    • 项目督导委员会

      • 成员一般是项目成员的老板及其老板

        • 背黑锅、买单

    • 项目经理

      • 统筹管理整个项目

    • PD、开发经理、测试经理、UE、服务团队、各团队的职能接口人

      • PD负责项目的需求，某一个可能兼任项目经理。
      • 开发经理负责开发相关的任务、开发的时间计划与任务分配，并全程掌控设计、编码直至上线的过程。
      • 测试经理负责测试相关的任务。
      • UE（用户体验团队）负责产品给用户的展现，比如交互效果、视觉效果等。
      • 服务团队负责产品帮助的编写以及上线后的服务工作等。
      • 各职能接口人负责牵扯其他产品的协同工作

    • 工程师

• 项目计划

  • 日常项目时间

    • 基于网页的软件

      • 两周到一个月

    • 大一点项目

      • 最多不超过三四个月

  • 评估工作量推算工期

    • 开发经理分配开发任务

    • 工程师评估自己工作量

      • 公式

        • （最乐观+最悲观+最可能）/3
        • （最乐观+最悲观+最可能*4）/6

    • 工作量精确至1人天

      • 1人天通常等价于5~6人小时

    • 开发经理汇总工作量并推算出工期

      • 考虑其他时间因素影响例如例会
      • 没法并行的任务需要叠加工期

• 沟通

  • 沟通方式

    • 周期

      • 以日、周为单位，取决于项目时间长短及变化频率

    • 渠道

      • 会议、邮件等，需要在成本和效率之间保持平衡

    • 发起者

      • 一般由项目经理、开发经理、测试经理主导相应的沟通

    • 参与者

      • 发起者确定参与者，不要遗漏项目边缘的同事

  • 沟通方法

    • 项目晨会

      • 开发经理召集相关人员PD、开发、测试参加

    • 项目日报

      • 自kickoff起，项目经理每日发给项目所有干系人

    • 评审会

      • PD召集需求评审，开发召集设计评审，测试召集TC评审，产品可用后项目经理召集功能评审，项目所有干系人参与评估

    • 项目变更申请

      • 当项目发生重大变更时，项目经理与项目督导委员会沟通后确认变更

    • 发布预告及公告

      • 项目经理在项目发布前两个工作日发预告给所有感谢人，项目发布成功后发公告给所有干系人

• kickoff会议

  • 时长

    • 15分钟

  • 内容

    • 项目背景

    • 项目意义、目的与目标

    • 需求、功能点概述

    • 项目组织架构

    • 项目计划

      • 项目时间点与里程碑
      • 各个时段需要的资源

    • 沟通计划

• 项目管理

  • 本质

    • 保证项目质量的前提下，在时间要求、人财物花费、项目范围三点上做平衡。

  • WBS模板

    • 一边做项目，一边形成自己的WBS模板

关键的青春期，又见需求（需求开发）

• 文档

  • 文档类型

    • BRD商业需求文档

      • 产品生命周期中最早的文档
      • 内容涉及市场分析、销售策略、赢利预测等
      • 通过PPT给大老板展示，没有产品细节
      • 为了获得认可，争取资源

    • MRD市场需求文档

      • 产品实施阶段
      • 通过什么功能实现商业目的，功能、非功能需求有哪几块，功能优先级等
      • 常见产出物有Feature List、业务逻辑图等
      • 从商业目标到技术实现的关键转化文档

    • PRD产品需求文档

      • 对产品功能的进一步细化
      • 包含整体说明、用例说明、产品Demo等
      • 对产品功能做具体描述

    • FSD功能详细说明

      • 比较像用例文档
      • 会出现很多技术的内容，要确定好产品界面、业务逻辑的细节

  • PRD的详细说明

    • 文档结构

      • 总体说明

        • 修订历史

          • 写清楚每次的修订日期、版本号、说明和作者，便与追溯

        • 项目概述

          • 描述项目的背景、意义、目的、目标等，描述业务领域知识，可参考kickoff中PPT的内容。

        • 功能范围

          • 业务逻辑图，重点描述系统中角色的职责、与周边系统的关系、全局的商业规划等

        • 用户范围

          • 对涉及的角色、系统做简单说明

        • 词汇表

          • 对设计的专有词汇、术语、缩写等进行说明

        • 非功能需求

          • 如性能需求、数据监控需求等

        • 其他说明

      • UC（用例文档）部分

        • 整体说明

          • 对所有用例进行说明

          • 给出用例的可视化表示

          • 说明各个用例之间的关系

          • 表示方法

            • 类图
            • 用例图（最关键）
            • 状态图

        • 正文

          • 用例文档

        • 对单个用例的说明注释

          • 视觉层面的描述通过demo表达
          • 界面细节，引用界面规范文档
          • 交互细节引用交互规范文档（出错提示的方式等）
          • 文案细节引用文案规范文档（各种提示方案等）

  • UML

    • 类图

      • 描述系统中出现的各个对象之间的关系，以及和外部系统的关系，即对业务领域描述

    • 用例图

      • 描述各个用例之间的关系

    • 状态图

      • 表达系统里实体的状态转换，贯穿多个用例

  • 用例文档UC

    • 主要内容

      • 概述

        • 用例的唯一标识

        • 用例名称

        • 业务描述

          • 商业目标
          • 用户目的

        • 需求描述

        • 行为者

        • 前置条件

        • 后置条件

        • 其他说明

      • 主体

        • 界面描述

          • 给出截图，界面上各种元素的说明

        • 业务规则

          • 用例的通用规则

        • 流程描述

          • 分主干、分支和异常三种

  • UML

    • 时序图

      • 描述事物变化在时间上的先后顺序，善于表达对象的交互

    • 活动图

      • 接近流程图，描述各种动作如何引起系统变化

    • 协作图

      • 表达不同对象之间如何相互影响

    • 构件图

      • 表述软件实施

    • 部署图

      • 描述硬件结构

  • Demo

    • 用例中放demo截图
    • 若要表现更多交互和视觉细节，必须存在demo
    • demo会经历从低保真到高保真的过程

  • 概要设计与详细设计

    • 不以写的东西是需求还是设计群职责，而以“技术”和“业务”区分
    • PD与开发一起写生沉淀出产品规范，避免细枝末节的数据经常重复

• 需求活在项目中（需求评审）

  • 评审

    • 需求评审

      • PRD评审、UC评审、demo评审的统称，需求相应部分完成之后进行评审会上PD把PRD和UC说给开发测试听，Demo主要由UE主讲
      • 一般做完比较大粒度PRD后进行评审，以尽早发现问题
      • UC和Demo做完后都要进行评审

    • 设计评审

      • 概要设计和详细设计完成之后进行
      • 开发工程师把对需求的理解以设计文档的形式说给PD、测试

    • 测试评审

      • 测试开始执行之前进行
      • 测试工程师把对需求的理解以TC的形式说给PD、开发听

  • 需求的生老病死

    • 项目开始之前

      • 产品团队分析需求的商业价值的需求讨论会、多个产品间的产品会议上，活下来的需求会确定需求负责人，状态变为“需求中”

    • 项目中的需求阶段

      • 项目启动后，PD对需求的开发召集需求评审会，确认后状态变为“开发中”

    • 需求阶段之后

      • 组织功能评审会，若功能上线，需求状态变为“已发布”

    • 客户反馈问题或有更好解决方案

      • 视为一个新需求或Bug，重新进入阶段

成长，一步一个脚印

• 开发阶段

  • 开发经理会带着普通工程师一起设计，若涉及数据库和硬件系统也会带上运维人员
  • 设计完成之后，会组织一次设计评审，审核工程师对需求的理解
  • 评审通过之后进入编码阶段。编码完成后，可进行代码评审工作。
  • 工程师对自己的代码进行单元测试，自测后从开发环境提交到测试环境。
  • 项目的主体部分提交测试之后，开发完成。

• 测试阶段

  • 设计和编码时，测试工程师细化和调整侧四季花，完成TC编写的任务
  • TC编写完成，测试经理组织TC评审，确认大家对需求的理解是否一致
  • TC评审通过，待开发提交测试以后，测试迅速进行冒烟测试，以确认软件基本功能正常。
  • 正式开始测试的同时，PD组织产品功能评审。
  • 此阶段，PD准备商业相关工作，面向用户的功能、卖点介绍的文档。

• BUG

  • 描述

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

• 项目发布

  • 代码更新

    • SVN管理员负责项目每日代码更新

  • 发布评审

    • 需要运维人员确认
    • 系统改动比较大的项目要分模块分步骤发布

  • 预发布

    • 预发布环境尽量模拟生产环境上的真实状态

  • 发布

    • 填写发布申请单

  • 线上验证

• 项目小结

  • 产品经理发布“项目发布报告”

  • 写一份项目小结

    • 心得体会
    • 遇到的问题及解决方案
    • 资源评估是否合理
    • 根据数据监控得出了什么结果

• 拥抱变化

  • 变更事件
  • 搭车事件
  • 紧急事件

山寨级项目管理

• 文档管理

  • 建立自己的文档规范

    • 文档类型

      • 需求规范类

        • PD做什么

          • 对产品和团队PD工作内容的总结，让新人快速了解工作职责

        • 用户体验规范

          • 交互规范
          • 视觉规范
          • 文案规范

        • 通用规则

      • 需求管理类

        • 用户调研
        • 产品需求列表
        • 产品信息架构

      • 流程管理类

        • 日常发布流程
        • 变更事件流程

      • 项目管理类

        • 项目管理制度
        • 项目任务书
        • KIckoff的PPT
        • 项目组织结构
        • 项目呀WBS（可生成进度）
        • 项目日报周报
        • 项目发布预告与公告

      • 日常工作类

        • 会议记录
        • 个人日报周报

  • 模板的作用

    • 让经常看同类文档的人提高效率
    • 让写文档的新人可以快速上手
    • 让写作者不会漏考虑某些内容

  • 多人协作与版本管理

    • 产生文档管理的本质需求是多人合作、协同办公

• 流程管理

  • 流程的本质目的

    • 将项目过程进行固化，与规范、模板的作用类似，这就是团队的竞争力

  • 评审会议

    • 产品会议

      • 必须有，决定产品方向

    • Kick Off会议

      • 最好开一下，鼓舞士气

    • 需求评审

      • 分PRD/UC/Demo评审，任意两个或三个都可合并

    • 设计评审

      • 开发能力很强可忽略
      • 可让开发讲述需求，PD提问

    • TC评审

      • 重要性仅次于需求评审，纯技术，商业团队可不参加

    • 功能评审

      • 项目干系人都参与

    • 发布评审

      • 开发经理决定是否需要

  • 商业评审与技术评审

    • 商业评审决定做不做，是产品会议与功能评审

      • 三个决定

        • 项目继续
        • 重新定向
        • 项目终止

    • 技术评审决定怎么做，是需求、设计、TC、发布评审

      • 三个决定

        • 项目继续
        • 有风险的继续
        • 必须解决某问题后再继续

• 敏捷方法

  • 特点

    • 有计划，更要拥抱变化

      • 项目计划要不断修正，强行遵守没有意义。计划一开始就要留有一些弹性

    • 迭代周期内尽量不加业务

    • 集中工作，小步快跑

      • 项目迭代周期较短，一般为两到四周
      • 每日小于20分钟的站立晨会，每个人只说三个问题，昨天做了什么？今天要做什么？遇到什么问题，怎么解决需要什么帮助？

    • 持续细化需求，强调测试

    • 不断发布，今早交付

  • 项目中的敏捷沟通

    • 建立项目的邮件列表
    • 每日站立晨会
    • 项目看板

物竞天择适者生存

• 几个特色项目

  • 老板项目
  • 封闭项目
  • 外包项目

第4章 我的产品，我的团队

大产品，大设计，大团队

• 产品之大

  • 时间：产品的生命周期

    不同时期的产品与市场。用户都有其特点，最佳状态就是彼此之间完美配合

    • 五种群体

      • 创新者

        • 新鲜感强，消费能力强，但忠诚度不高，需要新鲜的东西（新技术）不断刺激。
        • 产品刚上市或未上市的主流用户。
        • 经常提出意见和建议。

      • 早期追随者

        • 观念较新，需求目的性很强，需要迅速解决其问题的产品。不会马上试用，忠诚度较高。
        • 会从需求角度提很多想法。

      • 早期主流用户

        • 典型的实用主义者，产品大规模产生商业价值的用户群，生活中最常见的人群
        • 产品要做的简单易用

      • 晚期主流用户

        • 与早期的区别是心态上的。对新产品心存抵触
        • 如果营销和创新做得好，可在投入较少的情况下获得大量回报

      • 落伍者

        • 最优一批用户，附加值很低

    • 现实中的阶段有的可能很长有的可能很短，或同时处于多个阶段。

    • 不管处于什么阶段，都要明确目前的市场与用户，再决定做什么产品，什么功能满足其需求。

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

    • 方面

      • 商业

        • 主要由公司里的市场、销售、服务部门来考虑，他们决定产品的销售渠道、价格策略和服务方式

      • 产品

        • 狭义的产品部门包括产品设计、用户体验、产品运营等部门来考虑，他们决定了产品的功能范围、交互功能、视觉表现、运营手段的结果

      • 技术

        • 主要由开发、测试、运维等部门考虑，他们决定了产品的稳定性、性能、Bug数量等特性

    • 任何一个公司在这三方面都有它的强项和弱项，不可能也没必要三个方面都很强。一是构建性价比团队考虑，二是如果都强互相压不住反而造成内耗。

• 设计之大

  • 产品设计的五个层次

    • 战略层

      • 明确商业目标和用户需求，找准方向，重点是解决两者间的冲突，找到平衡点。

    • 范围层

      • 明确做多少，软件类产品确定功能范围，网站类产品确定内容范围。

    • 结构层

      • 考虑产品的各个部分互相之间是什么关系，软件类产品主要做交互设计，网站类产品主要做信息架构。

    • 框架层

      • 软件类产品做界面设计，网站类产品做导航设计

    • 表现层

      • 包含视觉设计和内容的优化，决定最终产品的气质

  • 设计目标的三个层次

    • 本能水平设计

      • 基础，产品要有用

    • 行为水平设计

      • 保证，产品要能用

      • 三个原则

        • 反馈
        • 容错
        • 简化

    • 反思水平设计

      • 升华，用的爽

• 团队之大

  • 设计职位，降低用人单位与求职者两边的沟通成本。

  • 设置接口人

  • 矩阵型组织

    • 职能型组织和项目型组织的融合
    • 横向是产品线、业务线，对客户负责；纵向是资源线、行政线，为了资源共享。
    • 双领导：产品经理管事，部门经理管人，不能兼任

游走于商业与技术之间

• 心思缜密的规划师（狭义的产品团队）

  • 概念设计与信息架构

    • 产品概念图

      • 思维导图或会议室讨论

      • 在需求采集之后，需求筛选之前

      • 表达重点

        • 产品与外界的关系

          • 产品与上下级系统、并列系统的关系

        • 产品与内部的关系

          • 产品模块之间的关系

• 激情四射的设计师（用户体验部门）

  • 职责

    • 用户研究员

      • 一般没有专人来做，PD充当

    • 交互设计师

      • 负责人机交互界面、用户操作流程的设计，必须要了解很多商业的内容，理解功能的商业价值

    • 视觉设计师

      • 负责视觉设计，即用户第一眼看到的效果

    • 前端工程师

      • 运用前端技术进行Web页面的开发

  • 交互设计与敏捷开发

    • 交互设计的理念是精雕细琢，敏捷开发推崇做的要快
    • 交互设计适合传统领域、成熟公司，时间充裕的；敏捷开发适合新兴行业、创业公司，时间紧迫的。

  • 信息展现

    • 数据可视化

  • 文案设计

    • 文案问题的级别

      • 低级阶段：错别字、病句、错误标点
      • 中级阶段：用词不统一、不准确
      • 高级阶段：语言风格不统一、产品气质不统一

• “阴险狡诈”的运营师

  • 产品与运营

    • 没有运营，产品走不出去，只能慢慢消亡；运营只能把人带来，把人留住要靠产品。
    • 运营担负着商业指标，急一些看到结果

商业团队，冲锋陷阵

• 好产品还需市场化

  • 定价与促销

  • 销售与渠道

    • 通过渠道销售的产品，新增或改动功能的时候，要考虑渠道内管理人员及渠道商的培训成本
    • 选择渠道销售，说明对互联网的应用能力不足，要转变相应设计思路
    • 渠道终端用户一般是企业，要考虑与个人用户的区别
    • 渠道政策都要有相应的系统支撑

  • 产品的版本细分

    • 做功能区分，打细分市场

    • 为了促进销售，利用消费者心理，纯策略性地做出“炮灰版”

      • 在原版本基础上，添加鸡肋功能做一个价格高出很多的“高价炮灰”
      • 删掉核心功能做一个价格稍低的“低价炮灰”

  • 水平营销

    • 创新思维

技术团队，坚强后盾

• 工程师、技术人员

  • 分类

    • 编码设计

      • 软件架构师、系统分析师、开发工程师、开发经理

    • 数据库设计

      • 数据库管理员

    • 测试设计

      • 测试工程师、测试经理

        • 功能测试
        • 性能测试

    • 软件配置管理员

      • 用SVN管理代码、软件版本的变更、每日构建等

    • 系统管理员

      • 硬件管理

    • QA质量保证

      • 流程管理、文档管理，常与测试归属于同一个部门

  • 风格

    • 技术痴迷者

      • 技术攻坚的主力
      • 少数没有责任心

    • 实用主义者

      • 工作有一段时间的经验者，做事求稳
      • 少数不思进取

• 如何与工程师合作

  • 工程师看重流程
  • 沟通中避免情绪化，争论过程中要考虑吧产品怎么做更好而不是说服对方
  • PD要不断提高自我修养

容易被遗忘的角落

• 老板

  • 要把老板当做最好的资源

• 法务

  • 搞定产品中一切与政策法规相关的问题

• 财务

  • 特别照顾付费产品

• 行政与IT

  • 负责办公资源的正常运转

大家好才是真的好

• 所谓团队文化

  • “不正经”和死气沉沉

• 虚无的无授权领导

  • 产品经理应该是管理者吗

    • 优势

      • 管理岗位利于拥有话语权

        • 产品经理最大的激励是成就感

      • 管理岗位利于获取信息

      • 管理岗位利于争取资源

    • 劣势

      • 管理岗位有很多行政工作

      • 管理岗位会让人脱离群众

        • 容易忽视别人意见
        • 官民之间的天然隔阂

  • 奖励或送礼的不敌并不是给对方最大的效用，而是要对方更开心，感激和记住你。

第5章 别让灵魂跟不上脚步

触及产品的灵魂

• 产品经理的三层境界

  • 产品帮助我们
  • 产品与我们互相帮助
  • 我们帮助产品

• 价值观

  • 价值观是与个人对周围客观事物的意义、重要性的总评价和总看法

  • 价值观体系是对诸事物的看法和评价在心目中的主次、轻重的排列次序

  • 企业的价值观是企业决策者对企业性质、目标、经营方式的取向做出的选择，是员工所接受的共同观念，是长期积淀的产物。

    • 企业做事的基本指导原则

• 战略

  • 取决于

    • 使命

      • 为什么存在，要做什么事情

    • 愿景

      • 希望成为什么

  • 表现于

    • 团队文化
    • 价值观

• 培养大局观

可行性分析三部曲（产品战略的具体制定）

• 我们在哪儿

  • 市场扫描

    • 针对整个行业

    • PEST分析机会与威胁

      • 政治法律环境
      • 经济人口环境
      • 社会文化环境
      • 技术环境

  • 竞品分析

    • ￥APPEALS分析法

      • 通常作为指导方阵

    • 实战做法

      • 上网搜
      • 看行业分析报告
      • 请咨询公司

  • 自我剖析

    • SWOT分析

      • 优势劣势机会威胁

• 我们去哪儿

  • 宏观用户需求

    • 细分市场

• 我们怎么去

  • 产品预研

做吧，准备出发

• 敢问路在何方

  • 产品路标规划

    • 是一个产品乃至产品线层面上长期的时间规划，路标规划上最小的单位，可能是产品的一个版本或相关的一个重大活动，细化之后都要通过好几个项目来实现。

• 低头走路，抬头看天

  • 正式会议

    • 开会和做一个产品是一样的，不要试图在一个会议中解决很多问题

    • 会议前做好准备工作，不要漏人不要叫闲人

      • 大会决定小事，小会决定大事

    • 提前1-3天告知关键人物，会钱确定其是否能到会

    • 做好会议记录

  • 战略会议

KPI，KPI，KPI

• SMART原则

  • 具体
  • 可度量
  • 可实现
  • 实性
  • 有时限

• 权衡多个目标

第6章 产品经理的自我修养

爱生活，才会爱产品

• 充满动力

有理想，就不会变咸鱼

• 目标明确

  • 做事应内驱不是外驱
  • 成功在自己手中
  • 建设个人品牌

会思考，活到老学到老

• 方法得当

  • 学校里没教的东西

    • 教知识不教思维
    • 教解题不教选题
    • 教努力不教取巧
    • 教受教不教施教

能沟通，在什么山头唱什么歌

• 团结前进

  • 充分沟通是不存在的

  • 沟通不是为了说服，而是为了更好的认识世界

  • 职场中的点对点沟通

    • IM

      • 成本最低，不紧急不重要

    • 电话

      • 成本始终，紧急不重要

    • 面谈

      • 成本最高，紧急且重要

    • email

      • 成本适中，重要不紧急

  • 职场中的群体沟通

    • IM群
    • 电话会议或视频会议
    • 会议
    • 群体邮件

附录：它山之石可以攻玉

产品经理的主要职责

• 市场调研
• 产品定义与设计
• 项目管理
• 产品宣介
• 产品市场推广
• 产品生命周期管理

产品经理的核心技能

• 沟通能力
• 无授权领导能力
• 学习能力
• 商业敏感度
• 热爱产品
• 注重细节，追求完美
• 日常产品管理能力

XMind: ZEN - Trial Version