人人都是产品经理1.0
2020-03-17 17:44:25 0 举报AI智能生成
《人人都是产品经理》思维导图
作者其他创作
大纲/内容
第四章：我的产品，我的团队
大产品，大设计，大团队
产品之大
时间之大：产品生命周期
创新者
早期追随者
早期主流用户
晚期主流用户
落伍者
空间之大：商业、产品、技术
商业
产品
技术
设计之大
产品设计的五个层次
设计的“现实与浪漫”
基础：本能水平设计
保证：行为水平设计
升华：反思水平设计
团队之大
想当年，一个比一个猛
从几个人到一家公司
接口人存在的价值
我身边的矩阵型组织
游走于商业与技术之间
心思缜密的规划师
从概念设计到信息架构
概念设计
产品与外界的关系
产品与内部的关系
信息架构
PD的出身及其优劣势
激情四射的设计师
产品新首页诞生记
当交互设计遇到敏捷开发
信息展现设计的例子
把数据表格化
突出重点信息
数据可视化
带交互的信息展现
聊聊细节，文案设计
低级阶段：错别字，病句，错误标点
中级阶段：用词不统一，不准确
高级阶段：语言风格不统一，产品气质不统一
“阴险狡诈”的运营师
产品与运营的战与和
个人博客运营实例
一次无意识的“事件+病毒营销”
商业团队，冲锋陷阵
好产品还需市场化
定价与促销
销售与渠道
另一种产品版本细分策略
高价炮灰
低价炮灰
开阔视野的水平营销
我们还能作什么
“老板，要光盘吗”
算出来的服务策略
技术团队，坚强后盾
外行眼中的技术分工
有这两种工程师
如何与工程师合作
容易被遗忘的角落
最后的资源，老板
默默奉献着的团队
大家好才是真的好
所谓团队文化
团队文化三五事
虚无的无授权领导
管理VS领导
产品经理应该是管理者吗
如何让团队更开心
跟着我，有肉吃
第五章：别让灵魂跟不上脚步
触及产品的灵魂
以价值观为根基
战略是怎么炼成的
培养大局观
可行性分析三部曲
我们在哪儿
从市场扫描开始
PEST分析
政治法律环境
经济人口环境
社会文化环境
技术环境
真实的竞争对手分析
$APPEALS分析法
价格
可获得性
包装
性能
易用性
保证程度
生命周期成本
社会接受程度
深刻的自我剖析
SWTO分析
优势
劣势
机会
威胁
我们去哪儿
宏观上的用户需求
物流平台案例
我们怎么去
一次真实的产品预研
做吧，准备出发
敢问路在何方
产品路标规划
一切尽在掌握
低头走路，抬头看天
我们急需靠谱的会议
仰望战略会议
KPI，KPI，KPI
SMART，并不smart
多个目标间的权衡
达摩克利斯之剑
本书的源头活水
第六章：产品经理的自我修养
爱生活，才会爱产品
我总是跟门过不去
乱谈餐馆的菜单
用户创意无限
有理想，就不会变咸鱼
成功在自己手中
个人品牌建设
个人名片设计实例
我的理想之路
会思考，活到老学到老
学校里没教的东西
只有方法，没有答案
好好学习，天天向上
能沟通，在什么山头唱什么歌
我的沟通理念
职场中的点对点沟通
职场中的群体沟通
“土老板”破冰必杀技
产品经理主义
好电影是怎么做出来的
产品经理看“春晚”
无可救药的职业病
解决问题的通用思路
人人都是产品经理
第一章：写给-1到3岁的产品经理
为什么要做产品经理
坏产品时刻恶心着我们
好产品可以改变生活
我们到底是不是产品经理
产品究竟是什么
一组将输入转化为输出的相互关联或相互作用的活动的结果，即“过程”的结果
产品要同时解决用户的问题和公司的问题
产品经理概念的进化
行业形态不同
传统行业：市场、用户成熟，产品基本定型，渐变式的创新
互联网行业：三天一小变，五天一大变
产品形态与成本结构不同
传统行业：产品为实物，制作成本高，需考虑整个供应链整合
互联网行业：产品为虚拟物，更加注重产品的研发过程
研发周期不同
传统行业：几年甚至更长，评审点多，过程复杂
互联网行业：一般就几个月，推崇“敏捷开发”，快速迭代
盈利模式不同
传统行业：盈利模式单一，通过产品本身的价值赚取利润
互联网行业：产品大多免费使用，注重用户研究
用户心态不同
传统行业：花钱买产品，不爽凑合着用，不会立刻买新的
互联网行业：产品免费且雷同多，不爽可能就会换其他的
非典型的产品经理
不同类型的产品经理负责产品的不同模块，更专业化
管理的能力及表现
信息不足以决策
时间不足以安排周密的计划
人员不足以支持工作强度和难度
资金不足以自由调配
怎么入行
明确自己的位置，利用已有知识结构、资源找入行途径
从本职工作和产品相关的事情做起
产品经理生态系统
用户研究
需求管理
需求采集
需求分析
需求筛选
项目管理
评审
立项
开发
测试
发布
团队协作
战略分析
可行性分析
规划
KPI
立项开发
文档管理
流程管理
敏捷开发
个人修养
爱生活，有理想，会思考，能沟通
第二章：一个需求的奋斗史
从用户中来到用户中去
用户是需求之源
人类为什么会有需求
生活中存在太多的问题，从而产生了不满意，而问题就是“理想与现实的差距”，那么人类会很自然地产生“减少甚至消除这个差距”的愿望，于是产生了需求。
马斯洛需求理论
生理需求
安全需求
社交需求
尊重需求
自我实现
确立以用户为中心的思想
不要试图满足所有用户
你真的了解用户吗
体会真正的用户
试着描述用户
聊聊用户研究
听用户定性的说，确定产品方向，做什么
听用户定量的说，确定需求优先级，先做什么
看用户定性的做，要先做的需求，该怎么做
看用户定量的做，看用户使用情况做数据分析，改进产品
需求采集的大生产运动
过程
明确目标
选择采集方法
制定采集计划
执行采集
资料整理
方法
定性的说：用户访谈
说和做不一致的问题
尽量在用户可以和产品发生交互的场合下访谈
注意区分用户说的事实和观点
样本少，以偏概全
尽量识别出各种可能引起偏差的因素并在访谈报告里标注
以增量的方式做访谈
用户过于强势，把自己往沟里带
牢记访谈的目的
自己过于强势，把用户往沟里带
牢记访谈的目的，管住自己的嘴
定量的说：问卷调查
样本与目标用户存在偏差
样本尽可能覆盖目标群体中各类型用户
保证各类型用户的样本比例接近全体比例
样本过少的问题
至少100份调查问卷
问卷内容的细节问题
问题表述应该无引导性
被调查者选择的答案可能与该答案的排列位置有关
定性的做：可行性测试
可用性测试做得太晚
可在产品的各个阶段测试
觉得很专业，干脆不做
可简化步骤，做总比不做好
明确是测试产品，而不是测试用户
测试过程中，组织者做与不该做的事
可要求用户在使用产品过程中说出自己的思考过程
测试过程中不要有指引性的提示，只观察记录
结束测试后，尽快总结，并发给用户
定量的做：数据分析
过于学术，沉迷于“科学研究”
有意无意的误读数据
不要为了迎合某个观点去找数据
平时不烧香，临时抱佛脚
在产品设计时需要把数据分析的需求加进去
需求采集人人有责
现场调查
AB测试
日记研究
卡片分类法
自己提的需求
听用户的但不要照着做
明确我们存在的价值
用户需求VS产品需求
用户需求：用户自以为的需求，经常表达为用户的解决方案。
产品需求：经过分析，找到真实需求，并且表达为产品的解决方案。
需求分析：从用户提出的需求出发，找到用户内心真正的渴望，再转化为产品需求的过程。
满足需求的三种方式
提高现实
降低理想
转移需求
也要创造需求
给需求做一次DNA检测
把用户需求转化为产品需求
模块
子模块
功能
功能描述
商业价值描述
商业属性
商业优先级
开发量
备注
确定需求的基本属性
编号
提交人
提交时间
名称
描述
提出者
提出时间
Bug编号
需求种类知多少
分类
新增功能
改进功能
体验提升
Bug修复
内部需求
性能需求
维护需求
...
层次
基础
拓展（期望需求）
增值（兴奋需求）
分析需求的商业价值
重要性
紧急程度
持续时间
商业价值
初评需求的实现难度
工作量
性价比
活下来的永远是少数
永远忘不掉的那场战争
准备出发：打包需求
打包类似的功能点
需求依赖，功能相互之间有依赖关系
需求粒度大小问题
战场：产品会议
回顾
主题
武器：商业需求文档
项目背景
功能需求描述
非功能需求描述
资源评估
风险对策
别灰心，少做就是多做
做的少不如做的巧
尽可能的多放弃
心急吃不了热豆腐
一个需求的生老病死
需求状态
负责PD
开发工程师
项目名称
发布时间
需求管理的附加价值
统计每个“提交人”的需求数量
统计“提交时间”、“发布时间”等信息
统计每个“模块”的需求数量
统计每个“分类”的需要数量
统计需求的“商业价值”、“性价比”变化
和需求一起奋斗
第三章：项目坎坷的一生
从产品到项目
做产品VS做项目
从生命周期角度看
从具体要做的事情来看
从产出物的角度来看
产品经理VS项目经理
产品经理：靠想
项目经理：靠做
为什么让产品经理管项目
一切从Kick Off开始
帅哥美女，我们需要你
别忘了最初的约定
初评工作量
再评工作量
三点估算法
推算工期
沟通从头开始
周期
渠道
发起者
参与者
方式
项目晨会
项目日报
评审会
项目变更申请
发布预告及公告
不可或缺的誓师大会
项目意义、目的与目标
需求、功能点概述
项目组织架构
项目计划
沟通计划
任何时候都要心中有“树”
目标
经典的项目TRQ
项目的本质
项目分解任务
关键的青春期，又见需求
真的要写很多文档
文档类型
BRD
MRD
PRD
FSD
产品需求文档
总体说明
修订历史
项目概述
功能范围
用户范围
词汇表
非功能需求
其他说明
UC部分
整体说明
UC正文
对单个UC的说明
学一点UML
类图
用例图
状态图
用例文档，UC
用例概述
用例的唯一标识
用例名称
业务描述
需求描述
行为者
前置条件
后置条件
UC主体
界面描述
业务规则
流程描述
用例模板
再学一点UML
时序图
活动图
协作图
Demo也要我们做吗
概要设计与详细设计
需求活在项目中
评审：一个头两个大
需求评审
设计评审
测试评审
再看需求的生老病死
日常需求发布流程
成长，一步一个脚印
开发阶段，旁观者说
开发阶段工作内容
测试阶段，大家一起上
测试阶段的工作内容
Bug眼中的项目
Bug级别定义
Bug描述关键点
缺陷级别
所属产品、项目
Bug名称
Bug描述
Bug状态流转图
那一夜，项目发布会
发布阶段的工作内容
发布注意事项
发布标准
发布过程
以始为终，项目小结
怕什么来什么，只能拥抱变化
变更事件
搭车事件
紧急事件
山寨级项目管理
文档只是手段
建立自己的文档规范
PD常用的文档模板
商业需求文档：BRD
产品需求文档：PRD
需求规范类
PD做什么
用户体验规范
通用原则
需求管理类
用户调研
产品需求列表
产品信息结构
日常工作类
会议记录
个人日报周报
项目管理类
项目管理制度
项目任务书
Kiff Off 的PPT
项目组织结构
项目WBS（可生产进度）
项目日报周报
项目发布预告公告
流程管理类
日常发布流程
变更时间流程
模板作用知多少
让经常看同类文档的人提高效率
让写文档的新人可以尽快上手
让写作者不会遗漏考虑某些东西
多人协作与模板管理
玩转office足矣
流程也是手段
项目VS流程
概念
方案
验证
生命周期维护
流程的本质是目的
那么多评审，可以省吗
产品会议
Kiff Off 会议
TC评审
功能评审
发布评审
商业评审与技术评审
商业评审
技术评审
敏捷更是手段
从本书到实践
有计划，更要拥抱变化
迭代周期内尽量不加任务
集中工作，小步快跑
持续细化需求，强调测试
不断发布，今早交付
项目中的敏捷沟通
与外包团队的敏捷尝试
物竞天择适者生存
亲历过的特色项目
如何做好“老板项目”
T是给死的，给自己预留多点时间
Q是可变的，尽量把Q搞大
R是丰富的，越多越好
秘密行动，封闭开发
开发外包，项目外包
一路坎坷，你我同行
“三边六拍”项目
三边
边计划
边行动
边修改
六拍
“拍脑门”决策
“拍肩膀”信任
“拍胸脯”承诺
“拍桌子”骂娘
“拍屁股”走人
“拍大腿”后悔
几个项目的成败
项目坎坷的一生
一次只有七天的战斗
访谈要注意的几点
避免一组固定的问题
首先关注目标，任务其次
避免让用户成为设计师
避免讨论技术
鼓励讲故事
避免诱导性的问题
产品模块级管理
项目准备
过程管理
时间计划
项目wiki维护
项目总结
心得体会
资源预估Review
数据分析报告
需求
实施
部署
服务
前线配合
0 条评论
下一页
