《人人都是产品经理》读书笔记
人人都是产品经理
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 |
书籍推荐:
- 《敏捷迭代开发——管理者指南》
- 《敏捷估计与规划》
- 《用户体验的要素》
- 《赢在用户》
- 《一目了然》
- 《点石成金》
- 《胜于言传》
- 《设计心理学》
- 《情感化设计》
- 《交互设计之路》
- 《软件观念革命:交互设计精髓》
- 《GUI设计禁忌》
- 《走出软件作坊》
- 《Web信息架构》
- 《产品经理实战手册》
- 《美第奇效应》
- 《别做正常的傻瓜》
培训推荐
- 《需求工程》《需求管理》
- 《项目管理》
- 《流程管理》
Kick Off 会议主题
-
项目背景
* 回忆过去,为什么要做 -
项目意义、目的与目标 * 展望未来, 做成之后带来的好处, 解决了哪些问题则标志着项目的成功
-
需求、功能点概述
* 表述现状,具体使用什么方法从“过去”过渡到“未来” -
项目组织架构
- 促进团队成员之间的相互了解, 并确保能够快速找到负责处理各类事务的核心人员
- 重要岗位人员配备要到位, 并对非关键岗位人员进行重点培训
-
项目计划
* 项目时间点与里程碑
* 各个时段每个人需要做什么事情 -
沟通计划
* 设立规矩及渠道,逼迫团队主动沟通
WBS 模板

PD 要写的文档们
| 文档名称 | 文档内容 | 文档用途 | 文档面向 | 文档形式 |
|---|---|---|---|---|
| BRD | 市场分析 销售策略 盈利预测 | 获得认可 争取资源 | 领导 | PPT |
| MRD | 市场/竞品分析 产品功能 优先级 | 商业目标—>技术实现 | 领导 | Feature List 业务逻辑图 |
| PRD | 整体说明 用例文档 产品Demo | 技术人员 | ||
| FSD | 产品界面 业务逻辑 | 技术人员 |
PRD
修订历史部分记录了修订日期、版本号以及相关的说明和作者信息。
项目概述主要涵盖了项目背景、意义以及明确的目标与目的说明。
功能范围部分通过业务流程图展示了系统各角色的具体职责分配。
用户范围明确了涉及的主要角色及其对应的系统。
词汇表部分列出了专有术语及其相关定义。
非功能需求部分详细列出了系统的性能指标与数据监控要求。
其他说明部分则补充提供了其他必要的补充信息。
UC 部分(用于描述用例文档的部分)
- UC主体:
-
界面描述:呈现截图并详细说明清洁功能模块及其与演示文稿的相关联机制。
-
业务规则:阐述基本规则并设定限定条件。
-
流程描述:分为主干流程、分支处理以及异常处理,并详细说明使用场景中的操作流程。
具体而言,在某个场景中会因特定事件引发相应的操作响应,
系统将通过预先设计的交互机制与用户进行信息交换,
特别地,
该流程可采用时序图或活动图的方式进行可视化呈现。- 要求:无歧义、完整、一致、可测试
- UC 模板:


评审:
- 需求评估:涉及PRD、UC和演示文稿的评估
- 系统设计阶段完成后:
- 由开发团队阐述对需求的理解
- 并展示相关的设计文档
- 经测试部门验证
- 测试用例编写完成时:
- PD经开发团队验证
Bug 级别定义

建立文档规范

-
需求规范类:
-
PD 的职责是什么?PD 是不是一种系统性的方法?它主要是对产品和团队进行PD工作的梳理与记录吗?通过这样的总结性的工作方式可以让新加入的人快速了解各个岗位的具体职责是什么吗?
-
用户体验规范:
-
交互规范:
- 控件使用标准及逻辑判断规则
-
视觉规范:
- 页面尺寸、字体大小及颜色编码标准
-
文案规范:
- 语言表述风格
- 标准的语法框架
- 常见操作术语的标准用法
-
通用原则
-
-
需求管理类:
-
用户研究
-
产品需求清单:包含产品需求记录表、流程规范文档等内容;此外还包括相关图表如状态变更流程图。
-
产品结构布局:网站页面及功能间的关联关系
在流程管理方面:
常规信息发布流程
其中包含紧急信息发布流程、需求变更处理流程以及特定场景下的打车需求处理流程等
-
在项目管理领域中涉及的各类组织架构及流程安排
-
组织架构中采用的产品会议制度及其各岗位职责与利益分配
-
项目的任务书
-
启动会的PPT演示文稿
-
项目的组织架构图
-
采用WBS方法进行分解,并推荐使用WBS Chart Pro软件进行可视化管理
-
每日的工作重点包括今日/本周的重要事项、明日/下周的关键看点、当前存在的问题、需要的支持资源以及整体进展情况。
-
日常事务处理相关领域:
-
会议记录:会议决策、遗留事项、具体方案
-
个人日报周报:汇报工作进展
各类会议重要性:
- 产品会议:是必要环节,在制定产品方向时至关重要。为了取得最佳效果,请尽可能多地召集相关人员参与。
- Kick Off会议:最好开一次,在启动项目初期能够激发团队士气。
- 需求评审:是一项关键步骤。
- 设计评审:根据开发团队的能力来定夺是否需要进行。若开发能力强则可省略;若开发能力较弱,则建议由开发人员负责描述需求,并让测试团队提出细节问题。
- TC评审:次于需求评审的重要程度。若测试资源不足可能会影响测试工作量。
- 功能评审:必须进行一项重要工作;如项目较为关键,则可在线下形式进行;若特别重要,则有必要组织一次产品演示会。
- 发布评审:由开发经理负责决定是否进行。
敏捷方法(作者推荐书籍:《敏捷迭代开发——管理者指南》和《敏捷估计与规划》)
- 基于规划的基础上灵活应对不确定性是必要的策略
- 在当前迭代阶段无需添加新的工作项 并根据情况确定下一步迭代的任务
- 需要专注的工作时间段可以通过站立会议等方式实现小步快跑的效果
- 不断细化需求的过程不仅包括早期阶段还包括后续阶段的需求确认与补充工作
- 定期向客户汇报进展是建立信任的有效方法 并及时收集反馈意见以优化后续工作安排
- “无论结果如何我们都要理解每个人在其能力范围内尽了最大努力。”这句话传递出坚定的信息有助于团队士气和协作精神的维持
四、大产品,大设计,大团队
产品之大
时间之大:产品生命周期
用户分类:
- 初创期的产品:具备强烈的创新活力,在其发展初期便能显著推动产品的成长。
- 早期追随者的定义是具有新奇想法并能有效满足市场需求的产品。这类企业通常能在推出新产品后迅速获得较高忠诚度的客户群体支持,并通过持续的技术改进来提升产品质量。
- 成熟期的主要客户群体规模较大且具有稳定的购买力。针对这类客户群推出的功能较为基础的产品更容易被接受。
- 成熟期的主要客户群体对于新技术持保留态度。此时企业应集中资源用于营销推广工作以最大化现有产品的销售效果。
- 衰退期的核心客户仍然为企业创造可观的价值。企业在这一时期应当关注如何利用剩余的功能为企业创造最大的效益。
空间之大:商业、产品、技术
商业方面涉及市场需求分析与资源调配;在渠道布局方面注重客户触达与资源优化,在定价方案制定中强调竞争分析与客户价值挖掘,在营销手段应用中突出效果评估与客户维护
在产品设计阶段注重用户体验塑造与技术实现方案优化,在操作流程构建中强调用户体验友好性与效率提升,在视觉效果打造上追求美观性与功能性统一,在运营模式创新中突出客户价值创造
从研发过程管理到系统稳定性的保障,在性能优化方面注重用户体验提升与系统响应速度改进,在软件质量把关环节重视功能完整性与易用性保障
设计之大
产品设计的五个层次:

- 战略层面:准确把握商业目标与用户需求。
- 应用层面:针对不同类型的产品(如软件类应用),确定具体的功能范围;同样适用于网站类应用的产品。
- 结构层面:规划产品内部各组成部分之间的相互关系。
其中针对软件类应用需要明确交互设计,
同样对于网站类应用则需要明确信息架构,
常见产出物包括软件业务逻辑图和网站站点地图。 - 框架层面涉及用户体验的核心要素:
包括界面布局、导航系统以及两者的整合设计。 - 表现层面主要关注产品的视觉呈现与内容优化。
其中视觉设计涉及界面布局、颜色搭配等元素;
内容优化则包括信息组织与呈现方式。
设计的“现实与浪漫”
Donald Norman, 三层设计维度: 第一层本源设计, 第二层行为导向设计, 第三层认知反思设计
一些基础原则:
- 反馈:预见性的预判,在行动过程中给予即时反应,在行动后进行有据可依的评估。
- 容错:看似多余但必要的严格规定,在某些情况下能够反向调整。
- 简化:充分运用已有知识,在心智模型的基础上工作,在标准化工具的帮助下完成工作,并非无限制。
团队之大
从事的工作范围较小(程度不高),单个人的工作量相对较少;但是随着工作的数量不断增加(规模不断扩大),分工明确有助于提升工作效率(同时能够保证较高的质量水平),让专业人士专注于各自领域。
从概念设计到信息架构
概念设计的产物是产品概念图,在需求采集之后至需求筛选之前阶段形成节点元素。这些节点元素主要采用以下两种方法生成:
- 思维导图改画:需求采集后,画出思维导图,整理分类需求
- 会议讨论
产品概念图主要描述内外关系:
- 外界关联主要体现在上级与下级系统的互动以及并行系统的协作;明确产品的产业链布局。
- 内部联系主要涉及各产品模块之间的交互与协调;明确各角色在系统中的职责定位。
文案设计
文案问题的三个阶段:
- 低级阶段:用字不规范、语病较多、标点使用不规范
- 中级阶段:表述方式不够统一、表述不够严谨
- 高级阶段:语言表达风格存在差异、产品气质表现不一致
好产品还需市场化
包装、定价、促销、销售、渠道
-
渠道:直销和分销;通过渠道销售的产品,在产品进行调整时(改动产品时),需要考虑公司内部渠道管理人员以及与之合作的经销商都需要投入培训资源;而渠道销售代表面对终端用户时(终端用户对互联网应用能力不足),则必须具备较高的技术指导能力以弥补其互联网操作技能相对欠缺的问题。针对企业客户与个人客户的差异性需求(企业与个体用户的差异),应分别制定不同的服务标准和运营策略。此外,在推广过程中(流程繁琐),可以通过现有系统平台来辅助操作并提高效率。确保各环节的服务质量能够有效提升产品的使用体验。
-
版本细分
- 按照功能模块进行细分市场定位(做功能区分):如手机型号、电脑硬件级别等不同定位的产品
- 增强市场吸引力(促进销售):通过巧妙的设计策略推出"次优版本"(策略性的做出"炮灰版")
-
水平营销策略:
-
需求层次
-
目标方向
-
具体场景与实施地点
-
时间框架
-
明确的产品和服务形态
-
品牌形象要素
-
使用场景或购买行为
如何与工程师合作
- 流程:更倾向于遵循系统化的管理方式而非依赖他人。
- 沟通:尽量保持理性,在与人交流时应避免情绪化的表达。每个人都希望自己被认同,在与他人互动时可能会因渴望获得认可而影响判断。有些人在面对负面情绪时可能会将其转嫁到对某一特定观点的反对上。沟通者的主动性会直接影响交流的整体氛围,并进而影响信息传递的效果。
- 提高自我修养:要求文档质量达到高水平,并确保其准确无误、全面详尽以及简洁明了,并定期更新以保持最新状态;对于不同类型的工程师可以讨论各自领域相关内容;让业务人员能够保持冷静并理性分析问题的同时也让技术人员充满热情地投入到解决问题中去。
最好的资源:老板
事情我做,黑锅你背
- 问答题:向老板请教
- 选择题:收集相关资料, 给出几种方案让老板进行选择
- 判断题:在提供解决方案的同时, 提出个人意见;在获得授权后协助完成任务
默默奉献的团队
- 法务部门:涉及法律条文相关事务以及著作权和专利事务。
- 财务部门:负责资金流动情况(包括用户、经销商及厂商的资金),预付款项的结算处理、发票领用流程以及订单款项的退款处理流程。
- 行政部与IT部门:由后勤团队负责日常运营工作。
产品经理应该是管理者吗
优势:
1. 话语权
2. 获取信息
3. 争取资源
劣势:
1. 行政工作
2. 脱离群众
解决方法:
在专业行列中处于较高层级,在产品和服务决策中拥有充足的发言权;在管理会议上就相关议题展开深入讨论并提出建设性意见;获得一项临时性使用权,在此期间可协助管理层对团队成员进行绩效评估,并提供考核建议;不对日常行政事务负责,在工作中与团队成员建立良好合作关系,并以产品性能作为自身价值体现
如何让团队更开心
项目经费使用:
- 小中之大胜过大中之小:高级的小玩意儿
- 无处可施比有用的东西差很多:吃不掉、用不掉、送不掉、扔不掉
- 想要的东西不一定非要得到:想买却舍不得买
- 没有选择权比有选择更好:会有放弃另一种选择后的患得患失
- 没奖胜过小奖:人的内在动力与奖励相关联时会变成交易行为,在衡量性价比时发现即使有奖励也有局限性。相比之下惩罚者会觉得心安理得所以还是不要惩罚比较好
- 早说胜过晚说:在员工期待的过程中让他们的快乐最大化
- 分开传递好消息分开传递坏消息能避免员工接收到坏消息后的负面情绪积累
- 不公开薪资会导致相互比较引发心理失衡
- 发奖金比涨工资更有灵活性也更有激励效果涨工资只能带来有限的效果
别让灵魂跟不上脚步
触及产品的灵魂
- PD的三个境界:
1. 产品帮助我们
2. 产品与我们互相帮助
3. 我们帮助产品
可行性分析三部曲
我们在哪;我们去哪;我们怎么去
我们在哪
1.
市场扫描:PEST分析

2.
竞品分析:
上网搜
行业分析报告
咨询公司
3.
自我剖析:SWOT分析

我们去哪:根绝客户需求进行方向确认
我们怎么去:简单来讲就是“策略”
我们急需靠谱的会议
- 避免在一个会议上处理众多问题(目标明确)
- 确保参会人员数量准确(不多不少),并提前确认能否到场
- 提前发出会议通知并提供会议文档初稿;对于重要人物需重点跟进,并可在必要时进行面对面交流以节省时间
- 明确的主持人:需具备掌控会议节奏的能力(包括时间管理、发言分配等),确保议题不跑偏;记录员:需如实做好记录特别是"会议决议"和"遗留问题"
- 所有人提供意见,并通过少数人讨论最终由一人决策

产品经理的自我修养
爱生活,有理想,会思考,能沟通。
- 真正有效的交流渠道并不存在。
- 沟通并非旨在说服他人接受自己观点的方式;相反,则是为了增进彼此的理解与认知:每个人都无法确保自己的见解是最为卓越的;不同见解普遍存在;关键在于积极地表达自己,在这一过程中进行磨合与调和;推销自己的想法最好的方式则是通过引导对方自然地释放出来。
产品经理主义
为了什么?做什么事,解决什么人的什么问题?何时做?谁来做?效果如何?
本文由 mdnice 多平台发布
