人人都是产品经理

Date: October 11, 2022 Status: PM

读后感：

花费了大概一周时间读完了《人人都是产品经理》这本书，收获颇丰，作为大多数产品经理的第一本启蒙书，文笔轻松，读起来很舒服，也让人沉浸。

谈谈收获吧：大概对产品经理这个职业，或者说这一类人有了一定的认识，也希望能够通过对这本书的学习，在后续的生活中，运用一些产品的思想，如作者所说，一切形式都是为了实现目的手段，我认为手段多一些，总比遇事感到捉襟见肘要强，希望自己能够成为这一类优秀的人，共勉！

名词解释：

PM	Product Manager（产品经理）Project Manage（项目经理）
PD	Product Designer（产品设计师）
PE	Product Engineering（产品工程师）
PR	Public Relations（公共关系）
项目TRQ	Time（项目时间）Resource（项目资源）Quality/Quantity（品质+数量）
WBS	Work Breakdown Structure（工作分解结构）
BRD	Business Requirements Document（商业需求文档）
MRD	Market Requirements Document（市场需求文档）
PRD	Product Requirements Document（产品需求文档）
FSD	Functional Specifications Document（功能详细说明）
UML	Unified Modeling Language（统一建模语言）
UC	用例文档
QA	Quality Assurance（质量保证人员）：负责产品品质保证的相关工作，比如流程控制，不同于测试人员
PV	Page View

书籍推荐：

1. 《敏捷迭代开发——管理者指南》
2. 《敏捷估计与规划》
3. 《用户体验的要素》
4. 《赢在用户》
5. 《一目了然》
6. 《点石成金》
7. 《胜于言传》
8. 《设计心理学》
9. 《情感化设计》
10. 《交互设计之路》
11. 《软件观念革命：交互设计精髓》
12. 《GUI设计禁忌》
13. 《走出软件作坊》
14. 《Web信息架构》
15. 《产品经理实战手册》
16. 《美第奇效应》
17. 《别做正常的傻瓜》

培训推荐

1. 《需求工程》《需求管理》
2. 《项目管理》
3. 《流程管理》

Kick Off 会议主题

1. 项目背景

   • 回忆过去，为什么要做
2. 项目意义、目的与目标

   • 畅想未来，做成之后有什么好处，解决什么问题即表示成功
3. 需求、功能点概述

   • 表述现状，具体使用什么方法从“过去”过渡到“未来”
4. 项目组织架构

   • 让项目组成员互相认识，明确什么问题应该找谁
   • 关键人物、非关键人物都尽量到位
5. 项目计划

   • 项目时间点与里程碑
   • 各个时段每个人需要做什么事情
6. 沟通计划

   • 设立规矩及渠道，逼迫团队主动沟通

WBS 模板

PD 要写的文档们

文档名称	文档内容	文档用途	文档面向	文档形式
BRD	市场分析 销售策略 盈利预测	获得认可 争取资源	领导	PPT
MRD	市场/竞品分析 产品功能 优先级	商业目标—>技术实现	领导	Feature List 业务逻辑图
PRD	整体说明 用例文档 产品Demo		技术人员
FSD	产品界面 业务逻辑		技术人员

PRD

1. 总体说明：

   • 修订历史：修订日期、版本号、说明和作者
   • 项目概述：项目背景、意义、目的、目标；如此PRD不包含全部需求，说明该部分需求是什么，其他需求位置
   • 功能范围：业务逻辑图，描述系统中角色职责，与周边系统关系、全局商业规则
   • 用户范围：涉及角色、系统
   • 词汇表：专有词汇、术语、缩写
   • 非功能需求：性能需求、数据监控需求等
   • 其他说明
2. UC 部分（用例文档）：

   1. UC 概述：

      • 用例的唯一标识
      • 用例名称
      • 业务描述：商业目标、用户目的（为什么做）
      • 需求描述：需要实现的功能点（要做什么）
      • 行为者：使用人
      • 前置条件：使用该用例的前提
      • 后置条件：用例完成的后续动作
      • 其他说明
   2. UC 主体：

      • 界面描述：给出截图、洁面各种元素说明，与Demo关联
      • 业务规则：通用规则，限制条件
      • 流程描述：分为主干、分支和异常。描述用例发生过程中，由什么事件触发，系统与用户之间产生何种交互步骤。尽量以时序图、活动图形式呈现。
   3. 要求：无歧义、完整、一致、可测试
   4. UC 模板：

评审：

• 需求评审：包括PRD评审，UC评审，Demo评审
• 设计评审：概要设计与详细设计完成后，由开发描述需求理解，展示设计文档，PD，测试进行评审
• 测试评审：测试TC编写完成后，PD，开发进行评审

Bug 级别定义

建立文档规范

• 需求规范类：

  • PD 做什么：对产品和团队 PD 工作内容的总结，让新人快速了解工作职责
  • 用户体验规范：

    • 交互规范：控件规范；判断规则
    • 视觉规范：页面大小、字体字号、颜色编码
    • 文案规范：语言风格，语法模板，常用操作标准说法
  • 通用原则
• 需求管理类：

  • 用户调研
  • 产品需求列表：产品需求列表模板、需求管理文档模板，需求状态变化流程图等
  • 产品信息架构：产品的页面或功能之间的关系，如网站地图，导航结构等
• 流程管理类：

  • 日常发布流程
  • 变更事件流程：紧急发布流程、需求变更流程，需求打车流程等
• 项目管理类：

  • 项目管理制度：产品会议制度，各岗位权责利
  • 项目任务书
  • Kick Off 的 PPT
  • 项目组织结构
  • 项目 WBS：作者推荐软件“WBS Chart Pro”
  • 项目日报周报：今日/本周要闻，明日/下周看点，当前问题，所需支持，项目进展
  • 项目发布预告与公关
• 日常工作类：

  • 会议记录：会议决议、遗留问题、行动方案
  • 个人日报周报：分享工作情况

各类会议重要性：

• 产品会议：必须，决定产品方向，参会人员越齐越好
• Kick Off会议：最好有，鼓舞士气
• 需求评审：重要
• 设计评审：取决于开发人员水平，开发较强可省略，开发较弱可采取由开发进行需求描述，PD进行细节提问的形式，既能使开发了解需求，又能降低不进行设计评审的风险
• TC评审：仅次于需求评审，若测试能力不够会增加PD工作量
• 功能评审：必须，可采取线下方式，若是重要项目，开产品演示会
• 发布评审：可由开发经理决定

敏捷方法（作者推荐书籍：《敏捷迭代开发——管理者指南》和《敏捷估计与规划》）

• 有计划，更要“拥抱变化”：项目计划不断修正，在一开始的计划中留有弹性
• 迭代周期内尽量不加任务：当前迭代不变，下次迭代待定
• 集中工作，小步快跑：集中办公，站立晨会等形式
• 持续细化需求，强调测试：更早的测试，重度的测试，不断细化和补充需求，发现业务逻辑中的限制条件，异常流程等
• 不断发布，尽早交付：让需求方不断的、尽早的看到结果，并给予反馈
• 一句温暖的话：“无论最终发现了什么，我们必须理解并完全相信：每个人在其当时所处情况下，在其能力范围中，做了最大的努力”

四、大产品，大设计，大团队

产品之大

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

  用户分类：

  1. 创新者：新鲜感强，在产品初期，可帮助产品快速成长，但如果不能够持续的输出新鲜感，可能会很快的离开
  2. 早期追随者：观念新颖，需求目的较强，需要迅速能够解决其问题的产品，如果产品能够达到要求，有一定的忠诚度，并且会从需求出发为产品提出意见，对产品发展价值较大。产品上市后的早早期，可偏向“专家用户”
  3. 早期主流用户：大规模产生商业价值的用户群。产品进入该阶段，应逐步面向“中间用户”和“新手”，偏向简单易用
  4. 晚期主流用户：对于新产品有抵触心理，产品进入定型阶段，需要市场营销发力，该阶段投入人力也较小，产出快速、可预期，收割商业回报的大好时期
  5. 落伍者：最后一批用户，产品逐渐退出市场，可以更加注重利益，发挥产品最终的余热

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

  1. 商业：市场、销售、服务；销售渠道、价格策略、促销策略、服务方式等
  2. 产品：产品设计、交互体验、产品运营；功能范围、交互流程、视觉表现、运营手段
  3. 技术：开发、测试、运维；稳定性、性能、Bug数量

设计之大

• 产品设计的五个层次：

  

  1. 战略层：明确商业目标和用户需求，找准商业上价值切入点，平衡两者之间的冲突
  2. 范围层：软件类产品确定功能范围，网站类产品确定内容范围
  3. 结构层：规划产品各部分之间的关系。软件类产品明确交互设计，网站类产品明确信息架构，常见产出物为软件业务逻辑图、网站站点地图
  4. 框架层：用户能看到的东西，软件界面设计，网站导航设计，以及两者都有的信息设计
  5. 表现层：视觉设计和内容优化

• 设计的“现实与浪漫”

  Donald Norman，设计目标的三个层次：本能水平设计、行为水平设计、反思水平设计

  一些基础原则：

  1. 反馈：动作前的可预测、动作中的积极响应、动作后的可评估
  2. 容错：一些貌似多余的强制性设计，不可逆操作可以后悔
  3. 简化：充分利用用户已有的知识，利用心智模型，利用标准化，利用一切

团队之大

做的事情较小，不太重要，一个人可以负责多项工作；做的工作越来越多，越来越大，分工明确可以提高效率，也可以提高质量，专业的人来做专业的事。

从概念设计到信息架构

概念设计的产出物是产品概念图，节点通常为需求采集之后，需求筛选之前，常用一下两种方式产出：

1. 思维导图改画：需求采集后，画出思维导图，整理分类需求
2. 会议讨论

产品概念图主要描述内外关系：

1. 外界关系：上下级系统、并列系统关系；勾勒产品所处产业链结构
2. 内部关系：产品模块关系；不同角色的身份

文案设计

文案问题的三个阶段：

1. 低级阶段：错别字，病句，标点符号错误
2. 中级阶段：用词不统一，不准确
3. 高级阶段：语言风格，产品气质不统一

好产品还需市场化

包装、定价、促销、销售、渠道

1. 渠道：直销和分销；通过渠道销售的产品，改动产品时，需要考虑公司内部渠道管理人员、及渠道商的培训成本；渠道销售代表终端用户对互联网应用能力不足，需要改变设计思路；渠道的终端用户一般是企业，需要考虑企业与个体用户的差异；渠道介入代表流程繁琐，需要相应的系统支撑；保证渠道服务质量，进而控制合作公司保障产品的整体体验
2. 版本细分

   1. 做功能区分，打细分市场：手机型号、电脑硬件级别等
   2. 促进销售，利用消费者心理，策略性的做出“炮灰版”
3. 水平营销：

   1. 需求纬度
   2. 目标维度
   3. 地点与情景维度
   4. 时间维度
   5. 有型的产品或服务
   6. 品牌特征
   7. 使用或购买

如何与工程师合作

1. 流程：喜欢被规则管理而非被人管理
2. 沟通：避免情绪化。每个人都希望自己被认同，可能导致思路变形，不再考虑产品的优劣，而是为了说服对方；有些人会将对人的反感转移到对此人观点的反对上；沟通的主动性会决定互动的氛围，也会决定信息是否顺畅
3. 提高自我修养：文档质量要足够高，准确，全面，简洁，及时更新，保持最新；对不同的工程师可以讨论不同的内容；让业务人员冷静下来，让技术人员兴奋起来。

最好的资源：老板

事情我做，黑锅你背

1. 问答题：问老板怎么做
2. 选择题：收集资料，给出几种方案让老板选择
3. 判断题：给出解决方案的同时，加上自己的建议，学习老板的判断方法；老板给出授权后，可以帮忙承担责任

默默奉献的团队

1. 法务：政策法规相关问题、知识产权问题
2. 财务：财务流向（用户、经销商、厂商），预付款尾款处理、发票开具、退款流程等
3. 行政与IT：后勤团队

产品经理应该是管理者吗

• 优势：

  1. 话语权
  2. 获取信息
  3. 争取资源

• 劣势：

  1. 行政工作
  2. 脱离群众

• 解决方法：

  在专业路线上拥有高级别，对产品、业务的决策有充分的话语权；参与管理会议的业务讨论；拥有临时的资源支配权，并给管理层提供同事的考核建议，但不负责行政工作，与同事打成一片，以产品证明自己

  如何让团队更开心

  项目经费使用：

  1. 大中之小不如小中之大：高级的小玩意儿
  2. 有用的不如无用的：吃不掉、用不掉、送不掉、扔不掉
  3. 需要的不如想要的：想买却舍不得买
  4. 有选择不如无选择：会有“放弃了另一种选择的患得患失”
  5. 小奖不如没奖：人做事的内在动力与奖励挂钩，就变成了经济交易，就会有性价比的衡量，所以小奖不如不奖；与之相反，小惩罚会让人觉得心安理得，还不如不惩罚
  6. 晚说不如早说：在期待的过程中，让员工的快乐最大化
  7. 一次送不如两次送：好消息要分开说，坏消息要一次说
  8. 公开不如不公开：薪资会互相比较，导致心理不平衡
  9. 涨工资不如发奖金：有较大的回旋余地，且涨工资的激励效果不大

别让灵魂跟不上脚步

触及产品的灵魂

• PD的三个境界：

  1. 产品帮助我们
  2. 产品与我们互相帮助
  3. 我们帮助产品

可行性分析三部曲

我们在哪；我们去哪；我们怎么去

• 我们在哪

  1. 市场扫描：PEST分析

  2. 竞品分析：

     1. 上网搜
     2. 行业分析报告
     3. 咨询公司

  3. 自我剖析：SWOT分析

• 我们去哪：根绝客户需求进行方向确认

• 我们怎么去：简单来讲就是“策略”

我们急需靠谱的会议

1. 不要试图在一个会议中解决很多问题（目标明确）
2. 确认参会人员，不漏人，不多人；会议开始前再次确认是否能够到场
3. 会议邀约提前进行，并且附上会议文档初稿，对于重要人物可重点确认，必要时可提前面谈，节约会议时间
4. 明确的主持人：掌握整体时间进度、控制每人的发言时间、均衡发言机会，保证议题不走偏；记录人：如实做好记录，尤其是“会议决议”和“遗留问题”
5. 所有人提供意见，少数人讨论，一个人拍板决定

产品经理的自我修养

爱生活，有理想，会思考，能沟通。

1. “充分沟通”是不存在的
2. 沟通不是为了说服，而是为了更好地认识世界：每个人都无法保证自己的观点是更好的，观点不同很正常，关键是要充分表达，在表达的过程中磨合，找出最优解；推销自己的想法，最好的方式是引导对方主动说出来

产品经理主义

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