《人人都是产品经理-苏杰》
2023-12-05 14:23:05 158 举报AI智能生成
登录查看完整内容
《人人都是产品经理》的读书笔记
作者其他创作
大纲/内容
《人人都是产品经理-苏杰》
传统行业
互联网、软件行业
图片
二者对比
产品经理概念
用团队的力量来代替单一的产品经理
产品管理团队
把产品强调为一个事业单位，即事业部，产品经理担任事业部总经理
事业单位经理的任用
需求分析师
产品负责人
行业专家
缩减产品经理的责任，让他从事更加专业化的工作
更专业取向
岗位变化方向
1. 产品经理岗位和工作说明（第1章 写给-1到3岁的产品经理）
理想与现实的差距
减少甚至消除这个差距的愿望
需求的产生
User，终端用户，使用产品的人
用户
Customer，购买产品的人
客户
用户VS.客户
结合产品的商业目标考虑
产品售卖原则
大客户目标：大客户盈利
大多数用户目标：用户数、活跃数
服务用户原则
用户需求的优先级
用户研究的方法
行为比语言更加真实有效
用户怎么做
了解需求背后的原因
用户怎么说
说与做
识别需求，找出原因，偏向于了解
定性
发现现象，证实需求，判断需求程度
定量
定性与定量
用户研究
用户需求调研概述
“说”与“做”不一致
增量访谈，根据结论是否改变决定是否继续访谈
样本少，以偏概全
把握主题，否则尽快结束
用户过于强势引导
我方过于强势引导
常见问题与对策
用户访谈
设置群体特征问题，识别目标群体
样本与目标用户的偏差
调查数量不足时谨慎给出百分比
样本过少的结论问题
避免引导性问题
设置不同选项顺序问卷，避免顺序偏差
进行问卷调查试验
问卷内容设置问题
调查问卷
产品各个阶段都可以做，尽早做
可用性测试做得太晚
简略地做和少做好过不做
认为可用性测试复杂而不做
寻找一般用户，在真实环境使用
测试产品而不是用户
“发声思维”，引导用户说出思考过程
及时总结调查结果并反馈用户
其他注意事项
可用性测试
注重分析活动的性价比
过于学术，沉迷研究
学习统计学，避免先验思维
有意或无意的数据误读
增加系统数据分析非功能需求
系统不支持数据分析
数据分析
现场调查
挑选少量用户进行功能不同设置的试验
AB测试
研究产品设计者的使用体会
日记研究
了解用户对产品功能的模块划分和系统结构认识
卡片分类法
自己提需求
其他需求采集方法
必需信息：需求编号、需求来源、需求描述、（需求场景）
单项需求卡片
与一手需求相对的二手需求
需求调研方法
定性地说
定量地说
定性地做
定量地做
用户自以为的需求，不一定是其真实需求
用户需求
经过分析找到的用户真实需求，表达为产品解决方案
产品需求
用户需求VS.产品需求
需求分析
问题本质：缩小理想与现实的差距
响应需求，开发产品或功能
改变现状
降低理想
转移需求
满足需求的方式
并非一定要以开发方式响应需求
用户需求转化产品需求
需求层次：基础、扩展（期望需求）、增值（兴奋需求）
确定需求的基本属性
满足后“一般”到“非常高兴”
未实现“略感遗憾”到“非常懊恼”
重要性
紧急度
持续时间
分析需求的商业价值
初步评估开发工作量
初评需求的实现难度
计算需求的性价比
需求分析过程
打包类似的功能点
打包有依赖关系的功能点
在需求管理成本可接受范围内粒度尽量细
需求的粒度问题
需求打包
项目背景（市场分析）、商业价值（盈利预测）
功能需求描述、非功能需求描述、资源评估、风险与对策
文档模块
吸引用户的往往是关键功能点
避免质量问题降低用户好感
实现高质量的少量功能
考虑不做开发的变通方式
需求“少做”的理念
商业需求文档
需求采集、需求分析、需求筛选、立项
跟踪需求的生命周期
需求进入研发阶段
2. 需求调研和投入研发（第2章 一个需求的奋斗史）
本质区别：产品是解决问题的东西，项目是产出东西的过程
生命周期
产品不断演进，要求创新和修正
项目目标明确，注重计划与控制
具体工作
产品相对通用
项目满足特定需求
产出物
二者区别
项目通用需求沉淀形成产品
产品根据项目定制需求发展市场细分产品
项目孵化产品
做产品VS.做项目
产品经理：做正确的事，即做能盈利的产品。重规划
项目经理：正确地做事，保质保量完成项目。重执行
产品经理：产品不光要满足需求，还要保证按期交付
项目经理：项目不光要按期完成，还要保证使用效果
二者之间的平衡
产品经理VS.项目经理
3.1 从产品到项目
通过管理人员的方式支持项目
通过重要决策的方式支持项目
项目督导委员会：项目成员的领导
相关岗位关键成员
团队组建
安排开发评估个人工作量
+工作依赖
+其他工作
研发经理推算工期
评估工作量：研发经理
项目计划：开发计划、测试计划、发布计划
里程碑节点：需求完成、编码完成、发布上线
编织项目计划：项目经理
开发阶段，研发经理召集
项目晨会
项目全程，项目经理编写
项目日报
需求评审、设计评审、测试用例评审、功能评审
评审会
项目经理与项目督导委员会
项目变更申请
确定沟通方式
项目背景
项目意义、目的与目标
需求、功能点概述
项目组织架构
项目计划
沟通计划
召开项目启动会
商业需求文档中的项目背景、商业价值、需求描述
3.2 项目启动工作
商业需求文档，BRD
市场与竞争对手分析
实现商业目的的功能
功能的优先级
市场需求文档，MRD
总体说明：修订历史、项目概述、功能范围、用户范围、词汇表、非功能需求、其他说明
类：由类名，属性和方法组成
接口：一系列操作的集合，指定了一个类所提供的服务
泛化关系：表示类与类，接口与接口之间的继承关系
实现关系：表示类与接口之间的实现关系
依赖关系：表示一个系统负责构造另一个系统的实例，或依赖另一个系统的服务
关联关系：表示一个系统的实例与另一个系统的一些特定实例存在固定对应关系
关系
类图：描绘各个对象间的关系，以及和外部系统的关系
参与者：使用该系统的人或事物
用例：系统的某项完整的功能
泛化关系：表示不同技术(各个子用例)实现同一业务目的(父用例)
包含关系：一个用例可以包含其他用例具有的行为
扩展关系：在完成某个功能的时候偶尔会执行另外一个功能
关系: 定义用例之间的关系
用例图（用户模型图）：描绘系统中各个用例之间的关系
初始状态、终止状态
状态：状态名称+系统或对象要进行的活动
转移：从一个状态到另一个状态的转移
事件：状态转移的诱因
守护条件：事件发生的特定条件
状态图：表达系统里实体的状态转换
说明各个用例之间的关系
整体说明
用例标识、用例名称
业务需求描述、产品需求描述、行为者
前置条件、后置条件、其他说明
用例概述
界面描述
用例通用规则
私有流程规则写到流程描述
业务规则
主干流程
分支流程
异常流程
流程描述
时序图
活动图
协作图
使用图形描述
用例模板
用例主体
用例内容
用例注释
用例部分
Demo/原型图
描述业务而不是技术
细节设计引用规范
需求和设计间的界线
产品需求文档，PRD
产品界面
业务逻辑
硬件系统、数据库、表结构设计
功能详细说明，FSD
需求评审：PRD、UC、Demo评审
只有在设计人员能力很强的情况下可以省略
设计评审：概要设计、详细设计
若省掉则PD需要做更加细致的功能验证
测试评审：测试用例
功能评审：确认产品功能是否与设计相符
技术评审和商业评审分开，避免商业人员打击技术人员，或被技术人员带入细节讨论
技术评审
文档管理
流程管理
已定计划内尽量不加任务
集中办公，定期沟通
阶段需求持续细化，重视测试反馈
敏捷方法
产品经理的项目管理
3.3 需求开发过程
3. 产品的项目过程（第3章 项目的坎坷一生）
部门：市场、销售、服务
产品定位、定价与促销、渠道政策、服务方式
商业
阿里巴巴
部门：产品设计、用户体验、产品运营
功能范围、交互流程、视觉传达、运营手段
产品
苹果公司
部门：开发、测试、运维
产品稳定性、基本性能、Bug数量
技术
Google公司
大产品
战略层：明确商业目标和用户需求，找到两者平衡点
范围层：确定功能范围和内容范围
结构层：交互设计（业务逻辑）、信息架构（站点地图）
框架层：界面设计、导航设计、信息设计
表现层：视觉设计、内容优化
产品设计的组成部分
阅读书目：杰西·詹姆斯·加勒特《用户体验要素》
本能水平设计
行为水平设计：反馈、容错、简化
反思水平设计
产品设计的水平升级
阅读书目：Donald Norman《设计心理学》
大设计
按工作职责划分部门，相同职责的人在一个部门
部门，部门经理
人力利用率高，适合防守型业务
职能型组织
按项目或产品划分部门，把各种职责的人组成一个部门
事业部，项目经理或产品经理
利于快速推进，适合进攻型业务
项目型组织
横向产品线、业务线，纵向资源线、行政线
双头领导，用人的产品经理提建议，养人的部门经理做考核
全攻全守
矩阵型组织
大团队
4. 产品、设计和团队（第4章 我的产品，我的团队）
0.价值观：企业性质、目标、经营方式的取向
1.使命：为什么而存在，做什么事
2.愿景：希望成为什么
公司的战略
PEST分析：政治法律环境、经济人口环境、社会文化环境、技术环境
市场扫描
$APPEALS分析法：产品价格、可获得性、包装、性能、易用性、保证程度、生命周期成本、社会接受程度
试用竞争产品
看行业分析报告
竞品分析
SWOT分析：企业优势、劣势、机会、威胁
自我分析
在哪儿？
细分市场
目标用户
目标需求
去哪儿？
怎么去？
战略思考/可行性分析
产品长期的时间规划
最小单位：产品版本
规划周期：产品大版本周期的3~5倍
产品路标规划
产品计划
明确目的，聚焦议题
协调参会人员，识别并优先确保关键人物
分发会议材料
会前准备检查
会前准备
明确支持人和记录人
达成一致结果并记录：“会议决议”和“遗留问题”
会中安排
发送参会人，抄送相关领导
1.传达会议决议，写明决定人
2.同步遗留问题，写明责任人和处理计划
会后同步
组织会议
5. 产品的战略工作（第5章 别让灵魂跟不上脚步）
0 条评论
回复 删除
下一页
