人人都是产品经理

一、写给-1到3岁的产品经理

1.1 为什么要做产品经理

1.2 产品经理是什么

产品是什么

• 用来解决某个问题的东西，比如：
  • 我们使用的物品（电脑、键盘、手机等）
  • 服务人员提供的服务（服务员等）

传统意义的产品经理

• 概念第一次出现在美国宝洁公司
  • 企业组织结构由按职能划分转变为按产品划分
• 主要职责是：负责规划产品的生命周期，负责产品的
  • 上市策略
  • 定价策略
  • 整合营销
  • 销售分销等

互联网的产品经理

• 侧重产品本身的从无到有，从有到优的过程
• 涉及：产品规划、数据分析、用户研究、需求分析、功能设计、项目管理、敏捷方法等

互联网产品经理职责与传统不同的原因

• 互联网是新兴行业，更新迭代快，最重要的是抢占高地，培养用户习惯
• 互联网提供的是虚拟服务，产品本身的复制成本几乎为0，商业模式相对较轻（不需要建厂房等重资产）
• 互联网的产品团队几十上百人，但用户却可能千万、亿级别
• 互联网的交付生命周期更短只有几个月
• 互联网的盈利模式更加多元
• 互联网用户的心态不同，因为免费用，同类产品大量存在，所以非常中用户体验

非典型产品经理

• 产品经理原本有一个人的职责，编程了一个产品团队的职责
• 按照产品划分部门
• 产品经理需要更多专业取向

产品经理需要管理什么

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

1.3 产品经理需要什么特质，需要如何准备

• 确定自己是否真的想做
• 自己要喜欢自己做的产品

二、一个需求的奋斗史

需求管理的过程

• 用户研究
• 需求采集
• 需求分析
• 需求筛选（确定项目的需求范围）
• 需求开发

需求管理贯穿其中

2.1 从用户中来到用户中去

2.2 需求采集的大生产运动

需求采集步骤

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

需求定性：用户访谈

• 采访者和被访者一对一聊天，样本一般较少几个到几十个，每个被访者花费几十分钟到几个小时
• 采访者文被访者答
• 可以了解用户怎么说（用户的目标和观点）
• 用户访谈的常见问题和对策
  • 用户说和做不一致
    • 用户阐述做了什么、步骤如何、遇到什么问题，可信度相对较高
    • 用户阐述我觉得、我认为，可信度较低
  • 样本少，以偏盖全
    • 样本选取符合数理统计学
    • 先访问5个得到基本结论，再访问5个观察结论是否变化，如果有变化继续加大样本或思考问题是否合适
  • 用户过于强势，把我们往沟里带
    • 时刻牢记访谈目的，发现话题不对，赶紧往正道扳，发现无法移到，索性放弃，避免浪费时间
  • 采访者过于强势，把用户往沟里带
    • 管好自己的嘴
• 用户访谈的其他注意点
  • 避免一组固定的问题，准备的问题清单只是引导作用，避免出现被审问的感觉
  • 首先关注目标，任务其次：比用户行为更重要的是背后的原因，多问问用户为什么这么做
  • 避免用户成为设计师：听用户说，不要照着做，因为用户的方案是短浅片面的
  • 避免讨论技术
  • 鼓励讲故事（场景）
  • 避免诱导性的问题，比如如果有xx功能，你会使用吗？（用户一般会回答是）

需求定量：问卷调查

• 问题设计上通常是封闭式问题，作答时间不要超过10分钟。
• 开篇放置简单不用思考的问题
• 需要思考的敏感的问题放中间
• 个人信息问题放在最后
• 问卷调查的常见问题和对策
  • 样本偏差，样本和目标用户不一致
    • 尽可能覆盖目标群体中的各类型的用户
    • 保证样本用户各种类型用户和目标用户比例一致
  • 样本过少
    • 要想得到百分比的答案，至少要有100份答案
  • 问卷内容细节问题
    • 问题描述无引导
    • 避免顺序偏差，问卷中选项打乱

定性的做：可用性测试

• 招募测试用户（能代表真实用户）
• 准备好一系列要求用户完成的任务，这些任务是实际使用中的典型任务
• 测试过程，组织者要观察用户操作并把发现的问题记录下来
• 测试结束后，组织者可以询问用户感受
• 可用性测试的常见问题和对策
  • 可用性测试做的太晚可能于事无补
    • 在任何阶段都可以做，可以手绘/Dome等
  • 总觉得可用性测试很专业，所以干脆不做
    • 收益可能无法评估
  • 明确是测试产品，不是测试用户
    • 实测试产品是否有问题，不是测试用户是否有能力用
    • 不要让用户听到可用性测试等术语，而是陈述提提意见等
  • 测试过程中，组织者该做的和不该做的
    • 发声思维：让用户在使用过程中说出自己的思考过程，比如为了完成某个任务，用户想先做什么，后做什么，为什么要做某个动作
    • 不要有引导或者暗示
    • 结束后要有小礼品

产品改版——一次冒险

产品在挑战用户的习惯，对于改版升级，要把暴力革命编程和平演变

定量：数据分析

• 数据分析（分析师）
• 数据分析的常见问题和与对策
  • 过于学术，沉迷于科学研究
  • 数据不会主动骗人，但是我们经常无意义或有意义的误读数据
  • 平时不烧香，临时抱佛脚（产品设计之初埋点应该相应设计好）

需求采集人人有责

单向需求卡片

尽可能的采集

• 现场调查
• 日记研究
• 卡片分类法
• 自己提需求

2.3 听用户的但不要照着做

明确产品经理的价值

• 用户表达的可能是需求的表面，我们应该要挖掘出深层次的需求并给出更好的方案
• 技术分析一般是： 树干——树枝——树叶
• 需求分析一般是： 先 树叶——树枝——树干 再 树干——树枝——树叶，分总分的过程
• 方案可能有多个，重要的是进行权衡（比如长期利益与短期利益）

满足需求的三种方式

• 改变现状
• 降低理想
• 状态转移

创造需求

产品设计的最高境界

需求分析

• 需求分析过程
  • 需求转换
    • 把用户需求转化为产品需求
    • 整理分类，分模块，整合，去除不靠谱的，排优先级
    • 用户需求和产品需求不是1对1的关系
  • 确定基本属性
    • 列表如下
      • 编号 需求的顺序号，唯一性标识
      • 提交人(*) 需求的录入 PD，负责解释需求
      • 提交时间 需求的录入时间，辅助信息
      • 模块(*) 根据产品的模块划分
        • 一般来说，根据人类记忆的特点，产品有 5±2 个模块比较合理，如果超过7 个，你就要考虑重新划分
      • 名称(*) 用简洁的短语描述需求
      • 描述(*) 需求描述：无歧义、完整性、一致性、可测试等
      • 提出者 即需求的原始提出者，有疑惑时便于追溯
      • 提出时间 原始需求的获得时间，辅助信息
      • Bug 编号 将一些 Bug 视为需求，统一管理
    • 需求的种类
      • 功能性需求：新增功能、功能改进、体验提升、Bug 修复、内部需求
      • 非功能性需求：性能、可培训、可维护、可扩展
      • “产品功能需求+产品非功能需求 = 产品需求”
      • “产品需求+市场需求+开发需求+测试需求+服务需求+…… = 产品包需求”
    • 需求层次
      • 把需求分成“基础、扩展（期望需求）、增值（兴奋需求）”三层
      • 随着时间的推移需求层次会发生便跟
  • 分析商业价值
    • 重要性 重要程度，辅助确定商业价值
    • 紧急度 紧急程度，辅助确定商业价值
    • 持续时间 持续时间，辅助确定商业价值
    • 商业价值(*) 商业优先级，不考虑实现难度，群体决策
  • 初评实现难度
    • RD参与，将每个需求转化为人日（开发量）
    • 当然不可能评估精确会逐步更正
  • 计算性价比
    • 性价比 = 商业价值÷实现难度（简化为开发量）

2.4 活下来的永远是少数

需求筛选

• 需求打包
  • 做项目，终极目标就是：多快好省 ，即范围大、时间短、品质高、资源省
  • 敏捷方法，“迭代周期”，一般是 2~4 周。然后有一个人员相对固定的团队，意味着项目资源确定，此外任何时候都要保证项目品质，最后能变的量只能——项目范围。
  • 通过工作量将和人力资源进行匹配，根据需求依赖关系，重要程度，需求相似程度，分工方式，将需求打包，按照迭代周期进行分割，确定需求包
    • “需求打包”最好打包类似的功能点
    • 需求依赖，功能互相之间有依赖关系，功能与人力资源之间的依赖关系
    • 需求的粒度大小问题，在需求列表里出现的任意一行，工作量最好不要超过“5 人天”
• BRD制作
  • 都包含哪些内容
    • 项目背景：我们在哪里？为什么要做这个项目，解决什么问题，可以列出一些数据说明项目的必要性。
    • 商业价值：我们去哪里？最关键的重点！大老板们最感兴趣的，做了这个项目以后有什么价值，一定要说在点子上。一般我们还会预测一下相关数字的变化，提出这个项目的商业目标。
    • 功能需求描述：我们怎么去？通过做哪些事情来达到目标，把打好包的需求描述一下，可以用功能列表的形式表达，但最好能画出业务逻辑关系。当然我们也经常会搞点技巧性的东西，比如故意加入一些让老板砍的需求，希望老板砍完之后心有愧疚不好意思再砍我们真正想做的东西，这有点类似谈判技巧里的玩意，大家可以试试，但不要在这上面太花心思了。
    • 非功能需求描述：提一下重要的非功能需求，如果有的话。
    • 资源评估：第二个重点！大老板们要看成本，他们在了解达成项目的目标需要多大的花费以后，才能做出决策。
    • 风险和对策：有的项目会有一些潜在风险，这个时候不妨抛给老板们看一下，并且给出自己的对策，说不定你觉得是很大的麻烦，在老板那里一句话就可以搞定。而且由于信息的不对称，我们无法了解某些功能是否会与公司将来的战略冲突，这时候提出来也是让老板们把一下关。
• 产品会议，目的
  • 抢占资源（人力资源）
• 立项

少做就是多做

• 情愿把一半的功能做到尽可能完美也不要把全部功能都做成半吊子。越来越觉得当发现一个功能可有可无的时候，甚至只要是没有强烈的理由要做的时候，要明确的选择：不做！现在我们可以自我安慰了——少做就是多做！
• 尽可能多地放弃，防止过度发散

三、项目坎坷的一生

• 基本流程
  • 立项
  • 需求（开发）
  • 开发
  • 测试
  • 发布
• 管理
  • 文档管理
  • 流程管理
  • 敏捷方法

3.1 从产品到项目

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

做产品VS做项目

产品经理VS项目经理（都叫PM）

• 产品经理：
  • 靠想，做正确的事情，领导产品符合市场需求、给公司带来利润
  • 决定做什么、不做什么，保证方向正确，我要把它实现
• 项目经理：
  • 靠做，把事情做正确，用有限的时间、成本资源完成目标
  • 决定怎么做、谁来做、何时做，保证方法得当，我要把它完成

不同角色做项目经理的问题

• PD（产品经理、产品开发）
  • 加需求/变更需求，导致项目延期
• RD（工程师、研发）
  • 砍需求，导致用户体验差

3.2 一切从Kick Off开始

Kick Off（比赛开球），指项目启动大会（启动大会及准备就是立项阶段）

• 需求筛选
• 立项
  • 团队组建
  • 计划确定
  • Kick Off

团队组建

团队结构

• 项目督导委员会
  • 各个成员的Leader组成
• 项目经理
• 团队
  • PD（负责需求）
  • 开发经理/开发工程师（负责开发）
  • 测试经理/测试工程师（负责测试、质量保证）
  • UE（用户体验团队，负责交互视觉）
  • 服务团队（产品帮助、上线后续服务）

计划确定

开发计划

• 项目周期：2周~三四个月
• 评估工作量推算工期
• 工作量评估方法
  • 工作量 = （最乐观+最悲观+最可能）/ 3
  • 工作量 = （最乐观+最悲观+最可能*4）/ 6
• 工作量粒度，精确到人天，或者人小时
  • 1人天 = 5或6人小时
• 评估人员：开发经理和各个工程师
• 开发经理汇总各个工程师的工时
  • 注意任务无法完全并行
  • 注意研发人员费开发时间
  • 留有余地
  • 人月神话：增加人力不能线性缩短工时
  • 使用甘特图表达

沟通计划

• 沟通计划的属性
  • 周期：周或者日
  • 渠道：会议、邮件、IM群组
  • 发起者：项目经理、开发经理、测试经理主导
  • 参与者：不要遗漏边缘同事
• 常见沟通
  • 建立随时沟通的群聊
  • 晨会制度（<20min）
  • 项目日报
  • 评审会
  • 项目变更申请
  • 发布预告及公告

启动大会（Kick off、誓师大会、KO）

• 时间 15 分钟
• 传达信息
  • 项目背景
    • 做之前是怎样的难受
  • 项目意义、目的与目标
    • 解决了什么问题
  • 需求功能点概述
    • 通过什么方法
  • 项目组织架构
    • 关键人物都到场
    • 不要遗漏工作量不多的人员
    • 接口人
  • 项目计划
    • 时间点和里程碑
    • 各时段资源
  • 沟通计划
    • 确定例会/群聊/邮件组

任何时候都要心中有树

• 目标：多快好省（范围大、时间短、品质高、资源省）
  • TRQ （Time、Resource、Quality、Quantity）
  • 在保证质量的情况下，在时间要求、人财花费、项目范围上做到平衡

产品模块级项目的WBS模板

• 产品模块级别项目
  • 项目准备
  • 过程管理
    • 立项
    • 时间计划
    • 项目wiki维护
    • 沟通计划
    • 项目总结
      • 心得体会
      • 资源预估Review
      • 数据分析报告
  • 需求
  • 实施
  • 测试
  • 部署
  • 服务
  • 前线配合

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

PD（产品经理需要写的文档）

• BRD（Business Requirement Document） 商业需求文档，一般表现形式为PPT
  • 产品生命周期最早的文档
  • 涉及：市场分析、销售策略、盈利预测
  • 没有产品细节，有点像创业者给投资人看的商业计划
  • 目的是获得认可，争取资源
• MRD（Market Requirement Document） 市场需求文档
  • 实施阶段
  • 主要是市场和竞争对手分析，通过哪些功能实现商业目的，功能非功能需求分为几块，优先级如何
  • 产物一般有
    • Feature List
    • 业务逻辑图
• PRD （Product Requirement Document） 产品需求文档
  • 需求开发的过程
  • 对产品功能的进一步细化，对产品功能做具体描述
  • 主要包括
    • 整体说明
    • 用例文档（UC）
    • 产品 Demo
• FSD （Functional Specifications Document）功能详细说明
  • 类似于用例文档，经常包含在 PRD 中
  • 涉及很多技术
    • 产品界面、业务逻辑细节
    • 软硬件系统设计、数据库设计、埋点设计 —— 架构师、工程师、分析师同步进行

特别说明

• 不需要写出以上的全部文档，可能将其中几种文档合并
• 名字各个团队可能不同，但是内容大体差不多

PRD

• 一个项目包含多个PRD、每个PRD包含若干逻辑相关的功能点（这些需求在需求打包环节进行识别，是产品需求文档中的若干行）
• 结构
  • 总体说明
    • 修订历史
    • 项目概述
    • 功能范围
    • 用户范围
    • 词汇表
    • 非功能需求
    • 其他说明
  • UC部分
    • 整体说明
    • UC正文
      • UC1
        • 视觉层面直接通过Demo表达（图片）
        • 界面细节（各种字体间隔颜色等、引用界面规范文档）
        • 交互细节（引用交互规范文档）
        • 文案细节（引用文案规范文档）
      • UC2
      • …
  • Demo
• 用例部分
  • UC整体说明：多用图表达（类图、用例图、状态图）
  • UC细节：（时序图、活动图、）
    • 唯一标识符
    • 用例名称
    • 业务描述
    • 行为者
    • 前置条件
    • 后置条件
    • 其他说明
    • 界面条件
    • 业务规则
    • 流程描述
  • 一般只包含功能性需求
• Demo（使用原型图绘制软件，如 Axure）

需求评审

• 一定要做
• 三种
  • 需求评审
    • 参与人员：PD、开发、测试，可以叫上老板、营销人员、服务人员、用户
    • 通过后：UE（用户体验）细化UC和Demo，研发修正计划、设计
      • UC 完成后需要 UC评审
      • Demo 完成分后需要 Demo评审
  • 设计评审
    • 开发完成概要设计、详细设计后进行
    • 开发讲给PD、测试听
  • 测试评审
    • 测试讲给PD、开发听

• 项目开始前
  • 产品内部讨论
  • PK需求，将需求变为需求中状态
• 项目中的需求阶段
  • 评审会，将需求变为开发中
• 项目需求阶段之后
  • 开发测试迭代
  • 将需求变为已发布

3.4 成长，一步一个脚印

需求评审通过视为项目重要里程碑，称作需求确认、需求冻结。后续变更需慎重，要走流程。

后续阶段

• 开发阶段（开发经理主导）
  • 设计
  • 设计评审
  • 编码
  • 单元测试
• 测试阶段（测试经理主导）
  • TC编写
  • TC评测
  • 冒烟测试
  • 功能评审
  • 测试

Bug管理

分级

处理流程

项目发布

• 流程
  • 发布评审
  • 预发布
  • 发布
  • 线上验证

项目总结

• 重在过程积累（周报日报形式）
• 不要为总结而总结

3.5 项目管理

核心：计划和控制

文档管理

• 建立自己的文档规范
• 常见的文档模板
  • 商业需求文档（BRD）
  • 产品需求文档（PRD）
  • 需求规范类
    • PD做什么？
    • 用户体验规范（交互规范、视觉规范、文案规范）
    • 通用原则
  • 需求管理类
    • 用户调研（用户调研前中后做什么、调查问卷用户访谈提纲怎么设计，有几块内容）
    • 产品需求列表（含需求管理流程）
      • 产品需求列表
      • 需求管理文档的模板
      • 需求状态变化流程图
    • 产品信息架构（页面跳转导航关系文档）
  • 流程管理类
    • 日常发布流程
    • 变更事件流程
      • 紧急发布流程
      • 需求变更流程
      • 需求搭车流程
  • 项目管理类
    • 项目管理制度
      • 产品会议制度
      • 各种经理指着范围
    • 项目任务书
    • KO PPT
    • 项目组织架构
    • 项目WBS
    • 项目日报周报
    • 项目发布预告和公告
  • 日常工作类
    • 会议记录
    • 个人日报周报

模板管理： 推荐使用wiki系统

流程管理

流程只是手段（长视者把目的当手段，短视者把手段当目的）

流程规范模板是团队核心竞争力，却对个人发展不利

评审/会议取舍

• 产品会议：必须有
• Kick Off：最好有
• 需求评审：必须有，但是可以将PRD、UC、Demo合并评审合并进行
• 设计评审：老团队可以省略，新人多/新团队最好有
• TC评审：敏捷过程必须有，技术参与
• 功能评审：必须有，但是形式上可能是大家自己体验
• 发布评审：开发经理决定

商业评审和技术评审

• 商业评审决定做不做，可能做出的决定：继续、重新定向、项目终止
• 技术评审决定怎么做，可能做出的决定：继续、有风险的继续、必须解决某些问题后再继续
• 两种评审必须分开放置相互扯皮浪费时间

敏捷方法

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

敏捷沟通

• IM群
• Email、日报
• 晨会、站会
• 项目计划白班

3.6 项目的坎坷一生

注意避免

• 三边
  • 边计划
  • 边行动
  • 边修改
• 六拍
  • 拍脑袋（不经过调研存在较大风险）
  • 拍肩膀（错误的激励可能带来反效果）
  • 拍胸脯（盲目乐观热情可能偏离方向）
  • 拍桌子（骂娘）
  • 拍屁股（走人）
  • 拍大腿（后悔）

四、我的产品、我的团队

一个产品的诞生需要多个部门/团队支撑

• 产品
  • 产品经理
  • 设计
  • 运营
• 商业
  • 销售
• 技术
  • 开发
  • 运维
  • 测试
• 支撑
  • 老板
  • 法务
  • 财务
  • 行政

1、大产品、大设计、大团队

产品之大

• 时间（产生生命周期），随着时间推移用户群的特性也会发生变化
  • 创新者
    • （用户量少、尝鲜者）
    • 用户新鲜感强，消费能力强，忠诚度不高，需要新鲜的东西不断刺激
    • 内测用户，刚刚上市接触产品的用户
    • 类似于设计人员，创意很多，想法比产品走的更快，产品必须做出把控，防止带偏
  • 早期追随者
    • （用户量小幅增加，与下一阶段存在鸿沟、存在需求敢于谨慎尝试）
    • 用户观念较新，需求目标性强，需要能迅速解决问题的产品，不是为了尝鲜，而是为了解决问题
    • 忠诚度较高，可以发展成种子用户，这个阶段产品可以做成偏向专家用户
  • 早期主流用户
    • （用户量快速增加）
    • 主流用户，实用主义者，偶尔听说产品，老产品可以解决问题，对新产品有期待，希望尝试
    • 产品用户从专家转变为新手，存在鸿沟，需要尽量将产品做的简单易用
  • 晚期主流用户
    • （用户量达到顶峰）
    • 老产品难以使用，才不情愿的迁移到新产品
  • 落伍者（用户量逐步减少）
    • 最后一批用户，产品开始落伍，但是落伍者不愿意接受新事物，仍在使用产品
  • 一个产品可能随着迭代，在以上阶段间来回变换，甚至同时处于多个阶段
• 空间之大
  • 商业（市场、销售、服务），决定产品的
    • 销售渠道
    • 价格策略
    • 促销策略
    • 服务方式
  • 产品（广义产品：产品、用户体验、产品运营），决定产品
    • 功能
    • 交互
    • 视觉
    • 运营
  • 技术（开发、测试、运维），决定产品
    • 稳定性
    • 性能
    • Bug数量
  • 一个组织不可能三者全部都很强，要有一个具有性价比的团队，最好是一强多优，才能避免内耗，比如：
    • Google 是技术主导的公司
    • Apple 是产品主导的公司
    • Ali 是商业主导的公司

设计之大

设计的几个方面

• 战略设计上：决定做不做、做什么
• 狭义设计上：决定做多少，怎么做
• 实施设计上：决定怎么做，何时做

产品设计的五个层次

• 战略层
  • 明确商业目标和用户需求
  • 找准方向和以上两点的平衡
• 范围层
  • 明确做多少即确定软件产品功能范围、网站产品的内容范围
  • 需要做好需求采集、分析、筛选、管理、开发
  • 最重要的是防止遗漏
• 结构层
  • 考虑产品各个部分相互关系
  • 对于软件类产品，主要工作是交互设计——业务逻辑图
  • 对于网站类产品，主要工作是信息架构——站点地图
• 框架层
  • 软件界面设计，网站导航设计
• 表现层
  • 视觉设计，配色、字号、间距等

团队之大

• 创业团队
  • 小而精悍，个个一顶三，一人做多件事，各个都是全能型人才
  • 团队灵活，没有流程
• 团队成长成公司
  • 组织变大，多人做一件事
  • 出现接口人（避免时刻Oncall，无法专心工作）
  • 分工明确，流程严格

组织结构

• 职能型组织
  • 相同职责的人划分在同一个部门
  • 利于资源共享、不利于达成一致
  • 适合大规模运作型公司或部门，计划经济
  • 防守型组织
  • Leader 部门经理
• 项目性组织
  • 各种职责人组成项目组或产品线
  • 团队目标一致，有利于快速推进项目，会造成资源浪费
  • 进攻型组织
  • Leader 项目经理
• 矩阵型组织
  • 行政相关归属于部门经理（养人）
  • 一段时间内归属于一个项目经理（用人）
  • 双头领导，两者不能兼职，部门经理决定考核，产品经理提供建议

2、游走于商业和技术之间（广义产品）

产品团队主要包括如下角色

• 狭义产品经理
• 运营
• UE
  • 视觉
  • 交互
  • 用研

狭义产品团队

• 产品经理带领产品规划师、产品设计师和需求分析师
• 产品经理、产品规划师偏向产品前期规划如
  • 市场定位
  • 版本发布计划
  • 思考焦点是商业目标、用户需求
• 产品设计师
  • 侧重功能设计
  • 思考功能细节
  • 编写需求文档

规划师：从概念设计到信息架构

• 概念设计的产物是产品概念图，从需求中发觉需要做什么，并整合为合理的系统
  • 为内部而做
  • 抽象出概念实体
  • 理清楚概念关系
  • 确定系统的边界
  • 确定系统与外部系统关系
• 信息架构
  • 为外部用户而做
  • 基于概念设计，怎么做具体模块划分，导航结构
• 两者都要以用户为中心，让产品更加接近用户心智模型

设计师：将产品形象化、具象化让产品从好到优

• 用户研究员（一般没有专门岗位、由PD充当）
• 交互设计师，负责人机交互界面、用户操作流程设计典型工作是导航设计、信息设计
  • 比如：设计注册流程一页搞定还是分几个下一步
• 视觉设计师（与交互设计师界限较模糊），负责字体颜色布局等
• PD 要把关设计师的想法不能偏离商业目标

文案设计

• 低级阶段：错别字、病句、错误标点
• 中级阶段：用词不统一、不准确（新建、创建同时出现）
• 高级阶段：语言风格不统一、产品气质不统一
• 文案越少越好，用户会凭感觉使用产品，一般不会去看帮助

运营师

• 现在是酒香也怕巷子深的时代
• 把功能点转换为卖点，需要让用户知道产品有什么用
• 运营人员可能只看重新增、不在乎留存，白费功夫

3、商业团队，冲锋陷阵

• 前线团队：市场和营销，负责
  • 价格策略、促销策略、销售计划、渠道管理
• 服务团队：包括
  • 客户服务
  • 技术支持
  • 服务策划
• 在项目进行过程中不要忘记商业团队
  • 评审叫上他们
  • 产品演示会叫上他们
  • 上线前提供PPT或者组内培训

好产品需要市场化

• 市场化的几个主题
  • 包装（对互联网产品就是portal、登录页）
  • 定价
  • 销售
  • 渠道（电话直销、上门直销、网上直销、线下渠道加盟）
• 定价与促销，一些常见的策略
  • 按功能区分打细分市场（比如手机定价）
  • 促进销售策略性的给出炮灰版
    • “高价炮灰” 在原有基础上添加一些鸡肋功能出一个价格高很多的高级版
    • “低价炮灰” 删掉核心功能提供同一个价格稍低的版本（炮灰版本成本要足够的低）
  • 向传统行业学习
• 给市场同学提供数据分析等技术支持

4、技术团队、坚强后盾

几种技术设计和评审

• 编码设计
• 数据库设计
• 测试设计

两种工程师

• 技术痴迷者，刚刚工作不久的新人或者少数工作很久一致醉心于技术的大牛
  • 优点：项目遇到难点，是攻坚的主力
  • 缺点：乐于在项目中尝试各种新技术，盲目创新
• 实用主义者，只把技术当做工具的工程师，典型KPI导向
  • 公司考核什么他们做什么
  • 尽量少做事，做简单的事，稳字当头

如何与工程师合作

• 技术人员最看重流程（特别是需求变更流程）
• 工程师希望交流避免情绪化
• PD需要提高自我修养，使文档更加精简全面易懂，可以了解一些技术

如何与业务人员合作

• 业务人员个个能说会道
• 思维逻辑性和严密性不如工程师
• 可能因为想到某个主意后会非常激动，需要PD将事

5、容易被遗忘的角落

支撑团队

• 老板（上级/领导）
  • 不要把老板当做老师，心存敬畏
  • 起初，菜鸟什么都不和老板说，但是这样会走偏
  • 后来，什么事都问老板，让老板给出答案，这样太累了
  • 接下来，让老板做选择题，选出几种可行方案，让老板选择
  • 最好的方案，让老板做判断题，给出可选方案后，给出自己的建议，让老板觉得是否合适做判断
  • 这样老板的回答可能就是“嗯”，此时你可以承担更大的责任了
• 法务
• 财务
• 行政

6、大家好才是真的好

团队文化：开心就好

无授权领导

管理者VS领导者

• 管理更像科学，领导更像艺术；
• 管理靠的是权力，领导靠的是魅力；
• 管理者强调稳定，领导者喜欢冒险；
• 管理者依法治人，领导者以德服人；
• 管理的对象是行为，领导的对象是思维；
• 管理管正确的做事，领导管做正确的事；
• 管理是一步一个脚印，领导是不走寻常路；
• 管理者注重短期目标，领导者注重长期发展；
• 管理者是职业经理人，领导者是企业家和创业者；
• 管理是汽车的制动系统，领导是汽车的驱动系统；
• 管理是告诉团队怎么做，领导是告诉团队为什么做；

产品经理应该是管理者么

• 产品经理必须是一个好的领导者
• 如果产品经理是管理职位
• 优点：
  • 管理岗位利于拥有话语权
  • 管理岗位利于获取信息
  • 管理岗位利于争取资源
• 劣势
  • 管理岗位有很多行政工作
  • 管理岗位会让人脱离群众
• 让优秀的产品经理在专业线路上拥有高级别；对于产品、业务的决策有充分的话语权；可以参与管理会议的业务讨论；可以拥有临时的资源支配权，并给管理层提供同事的考核建议；但不负责管理者的行政工作，而是继续和同事打成一片，用产品证明自己。

如何让团队更开心

• 大中之小不如小中之大
• 有用的不如无用的
• 需要的不如想要的
• 有选择不如无选择
• 小奖不如没奖
• 晚说不如早说
• 一次送不如两次送
• 公开不如不公开（薪资）
• 涨工资不如发奖金
• 奖励或送礼的目的并不是真正给对方最大的效用，而是要让对方开心，并且感激和记住你

跟着我，有肉吃

• 没事与同学们多聊聊天，成为朋友，多帮团队争取利益，真心地对大家好