启示录思维导图

这是一篇关于启示录的思维导图，知识内容有关键人物及其职责、产品管理与产品营销、招聘产品经理、评估产品机会、产品原则等。

启示录

• 人员
  • 关键角色及其职责
    • 现代软件产品团队
      • 产品经理
        • 评估产品机会（product opportunity）
          • 产品创意来源
            • 公司高管的意见
            • 用户的反馈
            • 可用性测试的结果
            • 产品团队和营销团队的点子
            • 业内人士的分析
            • 某些公司借助市场需求文档（market requirements documents，MRD）来完成这项工作
        • 定义要开发的产品
          • 探索产品的解决方案
            • 基本的产品特征和功能
            • 产品的用户体验
            • 产品的发布标准
            • 有些公司借助产品需求文档（product requirements documents， PRD）来完成这项工作
      • 交互设计师
        • 目标
          • 确保产品同时具有可用性和价值
            • 可用性是指用户明白如何使用产品；价值指的是用户对产品的渴求程度
        • 负责内容
          • 深入理解目标用户
          • 设计有价值的可用的功能
          • 用户导航和产品使用流程
      • 项目管理人员
        • 可能有专职的项目经理操刀，也可能有开发经理兼任，也可能由产品经理披挂上阵
        • 核心任务
          • 制定计划
          • 跟踪进度
      • 开发团队
        • 为外部客户开发和运维产品的团队
          • 为内部员工提供技术支持的团队为IT团队
      • 运维团队
        • 负责保证服务正常运行
      • 产品营销人员
        • 对外发布信息
        • 宣传产品
        • 为拓展市场销售渠道、组织重点营销活动、促进产品销售提供支持
    • 团队成员的构成比例
      • 1. 需要多少产品经理
        • 通常每五到十位开发人员配备一位产品经理
      • 2. 需要多少用户体验设计师
        • 一位交互设计师大约可以支持两位产品经理的工作，一位视觉设计师可以支持四位交互设计师的工作
      • 3. 应该聘请专职的项目经理吗
        • 凡超过十名开发人员参与的重大项目，就应该配备专职的项目经理。此外，如果采用火车模型发布模式，必须为每次产品发布配备专职的项目经理
          • 火车模型发布：以固定的周期持续发布产品，如果某项既定功能未完成，就挪到下个周期发布的开发方法）
  • 产品管理与产品营销
    • 区别
      • 产品经理的工作是从细节上定义开发团队开发什么产品
      • 市场营销的的职责是对外宣传产品
    • 三个误区
      • 1. 由市场营销人员定义产品
        • 问题
          • 由产品营销经理或所谓的产品经理负责收集高层产品需求，然后直接交给开发团队开发。这种方式忽略了手机详细产品需求的步骤，回避探索、定义产品的艰难决策过程，也绕开了用户体验设计
        • 情况
          • 营销类产品经理可以为团队提供市场营销资源，制作数据表格，培训销售队伍，为产品命名和定价
          • 但对详细定义有价值的、可用的、可行的产品往往束手无策。常见情况是产品从一开始就因此陷入了麻烦，只能指望例如主程序猿、交互设计师、公司高管等挺身而出，担负相关工作。
      • 2. 两人分担定义产品的工作
        • 问题
          • 定义产品的工作分给两人完成，产品营销人员负责高层商业需求，产品经理负责底层产品需求
        • 情况
          • 产品营销人员负责收集高层业务需求，产品经理负责收集低层产品需求
          • 没人对最终的产品负责
            • 采用这种模式是基于错误的观点，即认为可以脱离具体需求来定义高层需求
      • 3. 一人兼任两项工作
        • 问题
          • 产品营销人员兼任产品经理
        • 情况
          • 开发企业级软件的公司，由于非常倚重销售，最容易出现这个问题。销售代表原封不动地把大客户的需求传达给产品经理，再传达给开发人员。很难开发出有价值的、可用的产品。
      • 必须清晰界定产品经理和产品营销人员的职责。产品经理负责详细定义待开发的产品，让真实的用户测试产品。产品营销人员负责向外界宣传和推广产品，负责产品发布。 产品经理与产品营销应该经常沟通、展开合作。一方面，营销人员是产品经理获取产品需求的重要来源；另一方面，产品经理是营销人员获取市场营销信息的重要来源。
  • 产品管理与项目管理
    • 互联网条件下的区别
      • 特点
        • 互联网服务类产品对网站代码的局部修改更加频繁，发布周期明显缩短
      • 应对
        • 并行开发模式
        • 火车模型发布模式
          • 强有力的项目经理
          • 多位产品经理进行协调
  • 产品管理与产品设计
    • 用户研究
      • 研究分析用户
        • 评估产品或产品原型是否符合特定用户使用习惯
          • 拟定恰当的测试项目
          • 监督测试
          • 评估测试结果
          • 提出改进方案
    • 交互设计
      • 在理解目标用户的基础上设计有价值的、可用的目标功能、用户导航和产品使用流程
        • 线框绘制
    • 视觉设计
      • 根据线框设计可见的用户界面
    • 原型制作
      • 制作产品原型并让用户试用
    • 将功能与设计相结合，满足用户需求，目标是确保产品同时具有可用性（用户明白如何使用产品）和价值（用户对产品的渴求程度）
  • 产品管理与软件开发
    • 定义正确的产品
      • 产品经理负责定义产品方案
        • 配合开发工作
          • 只定义满足基本要求的产品
          • 一旦产品进入开发阶段，要尽可能避免修改产品的需求和设计
            • 不要在此时尝试突发奇想的点子
          • 在出现问题时迅速行动，在维持产品基本功能、尽量避免修改的原则上，拿出解决方案
      • 开发团队最了解哪些产品构思可行
        • 协助产品经理完善产品定义
          • 直接面对用户，体会用户的困惑和疑虑
          • 普及最新的技术发展动向，讨论哪些技术可以用到产品中
          • 在探索（定义）产品的初期阶段参与评估产品设计，协助策划方案
    • FAQ
      • 异地沟通
        • 至少一季度见面一次
      • 业务外包
        • 外包不是为了节约成本，而是为了实现合理的人员配置
        • 要基于正确的原因——为团队寻找合适的人选
      • 重写代码
        • 所有软件架构都存在功能极限
        • 需要预留一定的技术能力（余量headroom）
          • 为用户数量增长预留空间
          • 为事务增长预留空间
          • 为新增功能预留空间
          • 在产品管理上为开发团队预留20%的自主时间，让他们自由支配。开发团队可以利用这些时间重写代码、完善架构、憧重构码库中有缺陷的部分
        • 问题解决
          • 拿出至少20%的资源进行调整
            • 预留时间
            • 把目标分成几大块，实现的证修改，让用户感受到产品的改进
            • 谨慎选择正确的产品特性，确保产品定义的正确性
  • 招聘产品经理
    • 寻找出色的产品经理
      • 个人素质和态度
      • 对产品的热情
        • 例问：最喜欢的产品？如何完善自己最喜欢的产品？
      • 用户立场
        • 必须融入目标市场
          • 我们倾向于从自己的角度去理解用户和市场
          • 目标用户的经验、喜好、价值观、知觉能力、忍受程度、技术理解很可能与我们的大相径庭
        • 例问：如何换位思考
      • 智力
        • 洞察力
        • 判断力
      • 职业操守
        • 阶段不同产品经理需要承受的义务不同
      • 正直
        • 信任和尊重
      • 信心
      • 态度
        • 承担责任
      • 技能
      • 运用技术的能力
        • 策划产品在很大程度上取决于对新技术的理解，以及如何应用技术解决相关问题
        • 提升理解技术能力
          • 参加培训课程
          • 阅读相关书籍
          • 像程序员和架构师请教
      • 注意力
        • 集中注意力解决关键问题
        • 克制不断增加功能的冲动
        • 不收关键人物或重要客户的影响
      • 时间管理
        • 熟练迅速的区分重要任务和紧急任务，合理规划和安排时间
        • 产品经理的时间应该用来改变现状，而不是疲于奔命
      • 沟通技能
        • 口头表达能力
        • 文字能力
          • 一旦决定动笔就要写到最好
          • 条理清晰、言简意赅
        • 演讲能力
          • 尽量减少PPT页数
          • 充满热情、重点清晰、数据充分、决不超时
      • 商业技能
        • 双语技能
          • 既能与程序员讨论技术
          • 又能与管理层和营销人员讨论成本结构、边际效应、市场份额、产品定位和品牌
  • 管理产品经理
    • 建设公司从建设团队开始
      • 建设产品管理团队
        • 设计一套培训计划
        • 如果无法胜任工作，管理者应该重新寻找合适的人选
        • 一旦找到有潜力、称职的人选，就应该放手让他们工作
        • 确信产品经理有足够的能力，才能够授权给他们
          • 授权给不称职的人
            • 推卸作为产品总监的责任
          • 事必躬亲
            • 那是替他们承担责任
      • 规划公司的产品战略
        • 产品总监必须透彻理解公司最新的商业战略
          • 确保产品战略直接支持商业战略
        • 与产品经理一到完成产品规划，共同实现规划
        • 坚持按产品原则研发产品
    • 如何评估产品经理的工作
      • 唯一正确的评价标准是看产品本身是否成功
      • 新指标：用户净推荐值（net promoter score, NPS）
        • 评分标准
          • 满分十分
            • 9-10
              • 推荐者
            • 7-8
              • 中立分子
            • 0-6
              • 贬损者
          • 公式
            • 推荐者所占比例-贬损者比例
• 流程
  • 评估产品机会
    • 确定待解决的问题
      • 目的
        • 淘汰馊主意，避免浪费时间和金钱
        • 挑选合适的产品机会，团结团队，理解产品，整合资源
      • 评估
        • 产品价值
          • 产品要解决什么问题
        • 目标市场
          • 为谁解决这个问题
        • 市场规模
          • 成功的机会有多大
        • 度量指标/收益指标
          • 怎样判断产品成功与否
        • 竞争格局
          • 有哪些同类产品
        • 竞争优势
          • 为什么我们最适合做这个产品
        • 市场时机
          • 时机合适吗
        • 营销组合策略
          • 如何把产品推向市场
        • 解决方案要满足的条件
          • 成功的必要条件
            • 在调研过程中发现的特殊需求
            • 确定必要条件的任务不是描述解决方案，而是搞清楚产品的依赖因素和约束条件
        • 继续或放弃
          • 根据以上问题，给出评估结论
    • 开发新产品/维护旧产品
      • 区别
        • 开发新产品
          • 为老用户提供了更多选择
          • 吸纳新用户
        • 维护旧产品
          • 提高老用户的满意度
          • 吸纳新用户
      • 例子
        • 产品公司往往雇佣上百人的客服团队提供售后服务，如果能提高产品的易用性，能够大幅减少客服人员的数量，降低成本，同时提高用户满意度和用户净推荐值
    • 产品的收益模式
      • 公司财务
        • 帮你了解产品
          • 公司财务结构
        • 帮你了解用户
          • 交易记录、支付信息、客户数据和经营报表
        • 确认商业上的可行性
          • 评估商业模式是否合理
  • 产品探索
    • 定义正确的产品
      • 分析创意
      • 收集用户需求
      • 了解新技术
      • 拿出原型并测试
      • 从全局角度思考产品方向，兼顾短期需求和长期规划
    • 正确的开发产品
      • 开发
      • 测试
      • 发布
    • 产品经理必须在执行阶段转换工作重心，采用流水线方式并行开发产品，一旦1.0版本的产品开始进入项目执行阶段，就开始定义2.0的产品，原则就是不要让这种做法干扰正在执行的项目
  • 产品原则
    • 定义
      • 是对团队信仰及价值观的总结
      • 用来指导产品团队做出正确的决策和取舍
      • 从形式上看，它是一系列明确的、体现团队特色的产品价值准则
    • 作用
      • 了解企业文化
      • 公司创始人设立的企业目标
      • 作为一套价值判断的框架，能够帮助公司做出正确的决策
      • 团结产品团队，让产品经理、产品设计师、开发团队和营销团队形成共同的价值观
    • 错误
      • 原则过于空泛，失去了指导作用
      • 把涉及原则误当成产品原则
      • 意见冲突
        • 现状
          • 没完没了的会议
          • 会议中无意义的争论
          • 子主题
        • 原因
          • 每位同事对公司的产品都有自己的看法
          • 大家都非常在乎产品
          • 许多人以为自己比其他人了解目标用户
        • 解决
          • 达成共识
            • 究竟要解决什么问题
            • 要为那类人物角色解决这个问题
            • 产品要打到什么目标
            • 每项目标的优先级是什么
              • 确定哪个目标对用户最重要
                • 易用性
                • 响应速度
                • 功能
                • 成本
                • 安全性
                • 用户隐私
              • 从最重要到最不重要逐项排序，让团队达成共识
                • 不可囫囵吞枣打上关键、重要的标签
                • 一定要区分什么最重要，什么第二重要
                • 讨论开始前再次予以强调
              • 制定决策的过程和依据必须完全透明
                • 务必告诉大家决策的依据和理由
  • 产品评审团
    • 定义
      • 所有决策者做到一起，把产品推向市场共同制定决策
    • 难点
      • 既要为高管指定产品决策、监督产品流程提供透明的信息，又要避免高管插手干预产品团队的具体工作
    • 目标
      • 决定产品战略方向
      • 从宏观上监督公司产品的研发流程
      • 合理配置资源
      • 产品评审团不指定公司的商业战略，而是在给定商业战略的条件下，提出与之相匹配的产品战略
    • 成员组成
      • 首席执行官（CEO）/首席运营官（COO）/部门总经理（GM）
      • 产品管理总监/副总监
      • 用户体验设计总监/副总监
      • 市场总监/副总监
      • 开发总监/副总监
      • 网站运营总监/副总监
      • 客户服务总监/副总监
    • 职责
      • 四个里程碑
        • 评审产品战略和产品路线图
          • 启动评估产品机会
          • 选择值得投入精力的产品
          • 请产品经理进行评估产品机会
        • 根据评估产品机会的结果，决定是否开始定义产品的解决方案
        • 评审产品原型、用户测试结果、成本估算明细，决定是否开发
        • 评审最终产品、产品品质、发布计划、社会效应，决定是否发布产品
      • 目标
        • 监督产品原发流程，制定关键决策
    • 注意事项
      • 小公司通常负责评审所有产品，大公司根据业务单位大小设立若干个产品评审团
      • 产品评审团不负责评审对产品细节的更新或修正。
      • 评审团不负责具体的产品设计工作
      • 在【2】号里程碑处由于产品解决方案尚未形成，不可凭直觉估算产品的成本，至多只能估计大致的项目规模；但在【3】号里程碑处，应该仔细估算开发时间和成本，让公司上下做好准备
      • 尽量避免讨论具体执行策略
      • 产品评审团开会的频率取决于具体产品进度
      • 评审团还应该回顾分析产品上市后的表现，根据业绩进行反思之前的决策是否明智
      • 在会议召开前，产品经理最好逐一向产品评审团成员做简要汇报，存在疑问应及时解决，避免在汇报过程中措手不及
  • 特约用户
    • 背景
      • 若干知名人物公开声明使用过
        • 大大降低潜在用户的顾虑
      • 只有一两家
        • 误认为是针对特殊用户群的定制产品
    • 方法
      • 流程
        • 物色测试者
          • 人数
            • 6位积极活跃的目标用户
            • 可以招募8-10人，从中进行筛选
            • 要求在目标用户中有一定影响力
          • 企业级产品可以去同类产品展销会寻找特约用户
          • 可以在分类网站上发布广告
          • 大众产品可以邀请自己的亲朋好友参加测试，但要避开过于亲密的人和科技行业从业者
          • 可以通过公司网站进行招募
          • 建议定期开展原型测试活动
          • 去街头巷尾采集测试者
          • 邀请测试者上门，应当补偿为此损失的时间
            • 爽约
              • 一般为30%
              • 前一天致电可以把这个比率降到5%-10%
              • 注意尽量不要发邮件
        • 准备测试
          • 事先拟定测试内容
            • 着重主要项目
          • 机会只有一次
            • 如果待测产品是点评餐馆的服务网站
              • 先不要让测试者登陆产品原型的页面
              • 只提供空白的浏览界面
              • 看看他们会访问那些点评网站，使用谷歌这种搜索引擎，还是使用OpenTable这样的订餐网站
              • 他们点菜的习惯是什么
            • 原型是有假设的内容，直接让测试这使用原型就无法获取这些宝贵信息
          • 观察测试者能否从原型首页看出产品要解决什么问题，哪些地方最吸引它们
          • 完成测试任务后通过聊天获取更多信息
            • 是否用过同类的网站
            • 原型是否比他常用的好
            • 净推荐值（NPS）
              • 多少可能向朋友推荐这款产品
          • 为每个问题的答案打分，以此记录原型的表现
          • 不必等到原型完整完成后在测试，可以先测试主要项目
            • 如果遇到功能上的死胡同，问问他们接下来希望发生什么
        • 测试环境
          • 配备单项透明镜和闭路监视器
            • 但星巴克让测试者更放松，回答问题更坦诚和开放
          • 用户的办公室也可以
            • 同理如上
          • 远程测试
            • 尽量选择面对面
          • 尽可能安排一个主持
        • 测试原型
          • 测试前不宜与测试者交谈过多
          • 寒暄之后务必告诉测试者：
            • 这只是测试原型，不是正式产品
            • 请说出真实的看法，不必碍于情面有所保留
            • 被测试的对象是原型，不是测试者，不必担心测试失败
          • 尽量让测试者保持平和的情绪
            • 不要问误导测试者的问题
            • 多观察用户操作，少听抱怨
          • 测试时尽量保持安静，不要给测试者提示
            • 测试者在没有提示的情况下顺利完成测试项目
            • 测试者遇到麻烦，但通过反复尝试最终完成了测试项目
            • 测试者受挫，最终放弃
          • 尽量避免提示测试者，更不能进行引导
            • 如果测试者上下滚动页面，看可以问问他想找什么
        • 更新原型
          • 如果两三个用户反映了一样的问题，就需要解决
          • 如果没法让测试者对原型产生兴趣，或无法让远行变得足够简单易用，应该放弃这个创意
      • 成为特约用户的好处
        • 参与构思创意，解决他们手头的问题
        • 提前使用产品
        • 降低用户成本
      • 产品经理的收获
        • 为定义产品和开发产品提供与建议与协助
        • 提供调研便利
        • 定期组织用户进行小组讨论
        • 特约用户第一时间试用，迅速反馈意见
        • 如果满意，特约用户会乐意公开推荐
      • 注意事项
        • 不要收取参与费用
        • 特约人数绝不能超过十个
        • 如果寻找特约用户时遇到困难
          • 可能解决的问题不那么重要
          • 初步验证产品创意是否有价值
          • 需要重新考虑产品计划
        • 确保特约用户是产品的目标用户
          • 很容易把产品尝鲜者（early adapter）当成用户
          • 尝鲜者常常能容忍产品的不足和缺陷，依据他们的建议最后很可能只适合他们自己而不是整体用户
        • 需要向特约用户说明要开发面向大众的通用产品
          • 小众产品的生命周期比较短
            • 结束后售后也会结束
          • 需要承诺不是昙花一现
        • 应当视特约用户为合作伙伴
        • 合作贯穿产品研发的每个环节
        • 正式产品发布前一定要先请特约用户试用
        • 和营销团队合作
          • 无色特约用户
          • 协助提高特约用户受关注的程度
        • 平台产品要将特约用户换成六个应用
  • 市场调研
    • 作用
      • 工具
        • 用户调查
          • 设计调查问卷
            • 结合具体情境
            • 措辞清楚
            • 不要先入为主
          • 结果为获得解决方案提供了一条途径，但不是解决方案本身
            • 哪怕所有用户都选了A，我们依旧可以通过提供B更实际的解决他们的需求
        • 产品使用分析
          • 添加分析工具
        • 数据挖掘
          • 产品分析
          • 账单信息
          • 产品数据
        • 拜访用户
        • 人物角色
          • 用户特征记录
            • 通过与用户交流，确定典型的目标用户类型
            • 在理解各类目标用户的特征的基础上建立的人物原型
          • 重点关注
            • 用户的行为
            • 用户的态度
            • 用户的目标
          • 主要用途
            • 人物角色可以用来筛选重要的产品功能
              • 有助于决定谁是目标用户
                • 假设目标用户为A，即应添加对A的重要功能
              • 也有助于决定谁不是目标用户
                • 假设某项功能只针对B，就该被淘汰
            • 避免将自己的需求当成用户需求
            • 有助于对用户类型的优先级进行排序，识别需要重点考虑用户体验的地方
            • 可以方便地向团队描述产品的目标用户，他们怎样使用，他们关心什么
            • 可以帮助团队达成共识
          • 注意事项
            • 需要明确角色，老少皆宜是自欺欺人
            • 与目标用户面对面交流
            • 邀请多样化的用户参与产品原型测试
        • 可用性测试
          • 观察用户使用反应，收集反馈意见
          • 从用户的视角重新审视产品
        • 同类产品分析
      • 问题
        • 谁是目标用户
        • 用户会怎样使用产品
        • 用户能想明白怎样使用产品吗？障碍在哪里？
        • 用户为什么选择你的产品
        • 用户喜欢产品的哪些特点
        • 用户希望如何改进产品，增加哪些功能？
    • 局限性
      • 无法回答最根本的产品问题：打造什么产品
      • 探索/定义产品的过程则要回答如下问题
        • 采用什么技术来更好的解决产品要解决的问题
        • 设计什么样的用户体验
      • 成功的产品基于两点认知
        • 深入理解用户需求
        • 明白什么样的解决方案在现阶段是可行的
  • PRD
    • 要求
      • 完整描述用户体验
        • 用户需求
        • 交互设计
        • 视觉设计
        • 用户需求和用户体验是密不可分的
      • 准确描述软件行为
      • 方式需要直观
      • 应该可以修改
      • 以一个主体代表产品
        • 并列按优先级排列
          • 需求列表
          • 线框图
          • 实体模型
  • 用户体验设计
    • 开发与测试可以交叉进行
    • 用户体验设计与软件开发无法交叉进行
      • 前期架构决策极大制约后期开发工作
        • 进入开发阶段在就开设计思路非常困难，且越往后修改的成本越高
        • 心理上会打击开发人员的斗志，引发消极心态
      • 用户体验设计要保证产品同时具备可用性和价值
        • 需要尽早繁复的验证设计思路
        • 优秀的用户体验设计师一两天内要尝试几十个点子
      • 验证设计思路必须使用高保证原型
        • 产品原型应该可以随意修改
        • 产品开发应该以固定的原型为基础
      • 用户体验必须是全面而连贯的
    • 先后顺序
      • 用户体验设计应在软件开发前完成
      • 需求调研和产品设计可以同步展开
      • 产品开发和测试可以交叉进行
      • “第零次迭代（sprint zero）”
        • 先完成产品设计工作
        • 交由开发人员开始迭代开发
        • 更详细定义待开发任务
  • 基本产品
    • 不再试图定义最终产品，转而定义只满足基本要求（价值、可用性、可行性）的产品；一旦产品定义完成，通过了用户测试，他就是不可风格的整体，去掉任务和元素都不可能获得预期的效果
    • 产品设计流程
      • 只设计基本功能的高保证原型
        • 可以吧复杂度降到最低
        • 把开发时间减到最少
      • 邀请开发人员参与设计原型
        • 指出设计误区
        • 评估分析尚不确定的是否可行的功能
        • 协助估算各种功能的直接成本和间接成本
      • 请真实用户测试产品原型
  • 产品验证
    • 证明产品的价值、可用性、可行性
    • 在正式开发、部署产品之前，验证产品说明文档描述的产品是否符合预期要求
    • 三项验证
      • 可行性测试
        • 邀请架构师和开发人员参与技术调研，明确在现有的技术条件下能否成功开发出产品
      • 可用性测试
        • 突出产品的功能特性，让不同类型的用户都能明白如何使用
          • 重在观察用户如何设法完成必要的操作
        • 规划多次迭代测试
        • 清镇市用户来试用可用原型
      • 价值测试
        • 重在观察用户如何设法完成必要的操作
  • 平滑部署
    • 用户对更新产生反感的原因
      • 事先没有收到通知，觉得措手不及
      • 没有时间学习适应新版本，也没有提供旧版本方便用户在过渡阶段使用
      • 新版本无法正常运行
      • 新旧版本不兼容，无法访问旧版本数据
      • 添加的功能和特性毫无必要
      • 应付接二连三的更新，用户疲惫
      • 新版本修改了用户已经习惯的使用方式和操作流程
    • 措施
      • 通过公告、群发邮件、在线教程等提前通知用户
      • 加倍做好测试工作
      • 如果更新版本会影响大规模的用户，应该采取并行部署或者增量部署的方式降低风险
  • 快速响应阶段
    • 稍微延长项目周期，观察用户反应，预留时间进行快速响应
    • 评估产品
      • 明确可量化指标
        • 页面访问量
        • 注册用户数
        • 访问停留时间
        • 会员转换率
        • 订阅数
      • 借助网络工具进行数据搜集
  • 合理运用敏捷方法的十大秘诀
    • 产品经理即产品负责人
    • 使用敏捷方法绝不等于省略产品规划
    • 产品经理和设计师的工作进度应该比开发团队领先一两个迭代周期
    • 把产品设计工作拆分成独立的部分
    • 产品经理的主要任务是定义有价值的、可用的产品原型和用户故事
      • 可以用产品原型和用户故事替代产品需求文档和功能说明文档
      • 3个优势
        • 可以请用户测试
        • 强迫产品经理全面认真地思考问题
        • 向开发团队明确的描述每次迭代周期需要完成的任务
    • 让开发人员自主划分迭代周期产品经理和交互设计师必须出席每天的晨会
    • 除非达到了要求，否则不要轻易发布新版本
    • 每次迭代完成后，产品经理应该向团队展示产品现状
    • 团队内展开敏捷培训
  • 瀑布式开发
    • 基本原则
      • 采用阶段式开发
        • 撰写书面需求说明文档
        • 设计高层软件架构
        • 设计底层细节
        • 编写代码
        • 测试
        • 部署
      • 采用阶段式评审
        • 灭个阶段进行评审，评审后才能进入下一阶段
    • 存在的问题
      • 产品验证严重滞后
        • 产品经理必须等到软件开发的尾声才能看到产品
          • 可用性无法验证
      • 变更计划代价不菲
      • 无法适应快速的市场变化
  • 大公司如何创新
    • 20%法则
      • 20%工作时间用来从事创新研究
    • 臭鼬工程
      • 员工低调进行创新研究，拿出阶段性成果
    • 主动观察
    • 改善用户体验
    • 收购小公司
    • 子主题
• 双击编辑文本