人人都是产品经理笔记
2019-04-25 09:57:46 8 举报AI智能生成
本人是半年工作经验的产品经理，该脑图的大框架是《人人都是产品经理》的目录，每一个小分级是本人认为重要/有启发的点，以及自己在工作中遇到的实例。
作者其他创作
大纲/内容
人人都是产品经理笔记
写给-1到3岁的产品经理
为什么要做产品经理
我们到底是不是产品经理
一个产品经理的-1到3岁
需求：一个需求的奋斗史
从用户中来到用户中去
需求采集的大生产运动
用户访谈
开放式问题，用于找产品方向
用户访谈的常见问题和对策
说和做不一致
1.讨好访谈者心理，说访谈者希望听到的答案
2.没想过这个问题，现场编
对策：结合“说”和“做”。比如把“你喜欢哪个颜色的游戏机”改成“挑一个颜色的游戏机送给你”
样本少，以偏概全
1.愿意做访谈的用户已经与普通用户有差异了
2.区域性
策略：增量方式，先根据5个用户的访谈得出结论，再做5个观察结论是否有变化直至趋于稳定
避免诱导性问题，例如“如果有这个功能你会使用吗”
“沉默的大多数”容易被初始发表观点的人引导
调查问卷
作答时间不超过5分钟，开篇放无需思考的问题，中间放关键问题，个人信息放最后
封闭式问题
调查问卷的常见问题和对策
样本偏差：调查到的用户与想要调查的用户群不一致
会做问卷的人，即是一种筛选，这种隐性筛选实际上很多
对策：将目标人群的特征定义成一系列问题，在回收问卷后进行筛选
样本过少
样本过少时不要用百分比
避免诱导性问题
可用性测试
主流程
测试过程中让用户去完成测试任务，观察其中的问题
招募测试用户
准备测试任务
测试结束后询问用户的主观感受和看法
可用性测试的常见问题和对策
做的太晚，发现问题也来不及改
mvp，原型图时就可以用纸笔去让用户做
觉得太专业所以不做
实际上可用性测试发现问题的效率很高
测试过程中组织者该做和不该做的
测试过程中让用户边做边说出来自己的思路
不要有任何引导
产品改版的一次冒险
改版时不及早做用户测试且预留时间解决问题的话，万一用户不满意是会出现必须把版本回滚的灾难性事件的
对策
新旧版本并存
小面积试用
ab测试？
数据分析
通常数据分析只能发现一些现象，之后需要通过用户访谈寻找原因
数据分析的常见问题和对策
误读数据
为了证明某个预设好的观点去找数据
尽量保持数据中立
要取平均值是有前提的，比如一个超级富豪和1000个0收入者就不行
需要数据的时候没有
平时打好点
日志分析的商业价值
在对产品足够熟悉的基础上，先做出方向性假设，再提取相关数据并分析，得到一些现象，最好是之前没发现过的，然后尝试解释，之后通过用户调研调整修正解释，最终指导产品发展方向
需求采集人人有责
需求
一手需求
通过前四种用研方式发现的需求
二手需求
由销售，客服，老板等提过来的需求
需求采集卡片
作用是提需求过来的人把需求全部写清楚，这样就不用反复引导询问
所以有人会在内部IM工具的签名上写明提需求的格式
需求采集方法
现场调查
和客户一起工作一段时间
AB测试
日记研究
同行对产品的分析
卡片分类
粉丝级用户自己提需求
听用户的但不要照着做
原因
用户提的需求是站在他个体的立场上
即使合理，也要深挖本质需求，参见福特
明确我们存在的价值
用户需求vs产品需求
用户需求
用户自以为的需求，经常表达为用户提供的解决方案
产品需求
经过分析，找到的真实需求，并且表达为产品的解决方案
需求分析
从用户提出的需求出发，找到用户内心真正的渴望，并转化为产品需求的过程
是一个分总分的结构
从用户提出的“树叶”分析到本质“树干”，再展开为表现层的“树叶”
满足需求的方式
提高现实
即开发某种产品
降低期待
“丑话说在前头”
转移需求
引导用户关注其他事物
需求分析方法论
分支主题
产品需求列表
需求的基本属性
需求的种类
需求的价值
需求的成本
工期和工作量的区别，举例，生孩子要10人月
活下来的永远是少数
需求pk
组织架构
以产品线组织的组织架构
由产品经理直接对手上的产品负责，有直接对接的技术、测试资源
优点：适合创业期
以职能线组织的组织架构
所有产品一个部门，所有技术一个部门，所以需求pk变多
优点：适合成熟期，逼迫内部鲶鱼效应
BRD与PRD
少做就是多做
情愿把一半的功能做到尽可能完美也不要把全部功能都做成半吊子。
四两拨千斤，小改动带来大效果
心急吃不了热豆腐
需求DNA
需求的生命周期
需求简报
一个需求的奋斗史
项目：项目的坎坷一生
从产品到项目
项目的定义
只会进行一次，包含多项互相关联的任务，并且有绩效、时间、成本和范围限制的一项工作。
做产品VS做项目
从生命周期的角度来看
产品
生命周期较长，关注的是整个产品从规划到制造，再到最终维护和消亡的整个过程。
项目
生命周期较短，在项目开始以前就有明确的起始和结束时间，通过验收则表示项目生命周期就算完成了。
从具体要做的事情来看
有更多的探索
基本是在执行预设的任务
从产出物的角度来看
通用的
个性化的定制的
产品经理vs项目经理
产品经理靠想，做正确的事
项目经理靠做，把事做正确
一切从kick off开始
项目计划
工作量评估
brd初评->项目经理初评->细化到个人自己评估
工作量=（最乐观+最悲观+最可能*4）/6
1人天=5~6人时
风险点
沟通从头开始
干系人权责不明确，出工不出力
对需求的理解不一致
遗漏了利益相关方（业务方，各bu，或者以为只需要前端修改漏了后端），最后无法发布
项目管理方法
WBS
又见需求
文档
BRD商业需求文档
产品生命周期中最早的文档，其内容涉及市场分析、销售策略、盈利预测等，通常是给大老板演示的ppt，比较短小精练，没有产品细节，有点像创业者给投资人看的商业计划，主要是为了获得认可，争取资源
MRD市场需求文档
获得老板们的支持后，产品进入实施阶段，需要写出MRD，要有更细致的市场与竞争对手分析，包括可通过哪些功能来实现商业目的，功能、非功能需求分哪几块，功能的优先级等。实际工作中，PD在这个阶段常见的产出物有产品的Feature List、业务逻辑图等，这是从商业目标到技术实现的关键转化文档
PRD产品需求文档
PRD是对产品功能的进一步细化，文档主要包含整体说明、用例文档、产品Demo等，会对产品功能做具体描述
FSD功能详细说明
Functional Specifications Document比较像用例文档，经常包含在PRD中，从这步开始会出现很多技术的内容，产品界面、业务逻辑的细节都要确定，比如网页上的某个表格中的数字，应该左中右对齐？保留几位小数等，有点像“概要设计”。与此同时，硬件系统的设计、数据库设计、表结构设计等工作，也开始由架构师、系统分析师们编写了。
UML图
流程图
时序图
用例图
泳道图
交互图
axure
概要设计与详细设计
业务方面由产品定（输入字数限制等）
技术方面由技术定（在数据库如何存储）
需求活在项目中
需求评审
PRD评审
设计评审
测试评审
山寨级项目管理
文档管理
建立自己的文档规范
多人协作与版本管理
wiki
流程管理
项目vs流程
项目只做一次，流程就是类似的项目一直做，总结出来的东西
流程的本质目的
不对个人产生依赖，人走了事还能做
评审会议可以省吗
敏捷方法
拥抱变化
一开始的计划中间要留有一些弹性
迭代周期内尽量不加任务
集中工作，小步快跑
团队小，迭代周期短，每日站立晨会
持续细化需求，强调测试
测试驱动项目，用于补充和细化需求，比如业务逻辑的限制条件、异常流程等
不断发布，尽早交付
大问题分而治之
物竞天择适者生存
项目案例
老板布置的项目
time resource quality中的T已经定了
Q即项目范围一般是有一定灵活性的，越上面的老板给出的要求越抽象
把Q搞大合理算出巨大的R，让老板自己去砍，同时一定要提供优先级让老板知道往哪里砍
R因为是老板要求，一定给够，要狮子大开口
备注：强势的老板会把Q也定了，R还是不足的。
备注：与老板产生分歧，只要不违背自己的价值观，就尽心尽力完成任务
封闭开发
集中到会议室开发
一路坎坷，你我同行
三边六拍
三边：边计划、边行动、边修改
六拍：脑门、肩膀、胸脯、桌子、屁股、大腿
几个项目的成败
过不了压力测试
需求阶段叫停，转移给别的团队
市场调研阶段认为不值得做
早一步是先驱，再早一步是先烈
成功发布，之后不断升级运营维护，项目上线后也有很多事情需要做
外包，延期半年发布
一个只有七天的项目
项目的坎坷一生总结图
团队：我的产品，我的团队
团队图
大产品，大设计，大团队
产品之大
时间之大：产品生命周期
五种用户
创新者
新鲜感强，消费能力强，但忠诚度不高，喜新厌旧，尝试新技术甚于解决实际需求
因为经常给产品提意见，因此可以用于帮助产品快速成长
早期追随者
观念比较新，但是需求目的性很强，需要迅速能够解决其问题的产品，反复确认对自己有用后再尝试，忠诚度比创新者高
对产品发展价值很大，提的问题很多是从需求出发的，将来可以发展为产品的种子用户
早期主流用户
产品大规模产生商业价值的用户群，生活中最常见的一批人，听到过新产品，但绝对正在用的老产品也能解决问题就不会去更换，但也希望试一下新产品
需要的是一个简单易用的产品
《跨越鸿沟》里说的鸿沟就是冲出“早期追随者”进入“早期主流用户”阶段
真正获得商业回报的开始
晚期主流用户
对新产品心存抵触，例如家中长辈，他们不愿意学习新产品
是微笑曲线右半边上翘的嘴唇发力的时候
这个阶段是需要营销创新的地方，是收割商业回报的大好时期
落伍者
空间之大：商业、产品、技术
商业
由市场、销售、服务等部门考虑，他们决定产品的销售渠道、价格策略、促销策略、服务方式等
此处是狭义的，由产品设计、用户体验、产品运营等部门来考虑，决定了产品的功能范围、交互流程、视觉标示线、运营手段等
技术
由开发、测试、运维等部门考虑，他们决定了产品的未定型、性能、Bug数量等特性。
设计之大
任正非“先僵化，后优化，再固化”
《用户体验要素》
《设计心理学》《情感化设计》
团队之大
接口人
组织结构
职能型
相同职责的人划分在一个部门
eg.产品部门，技术部门
项目型
各种职责的人组成一个个的项目组
eg.BU
矩阵型
两种的结合
其实结合方式可以叠加，转置
产品团队，游走于商业与技术之间
心思缜密的规划师
狭义产品团队
产品 经理和产品规划师
产品设计师
功能级的设计
之前实习干的比较像这个
需求分析师RA
从概念设计到信息架构
概念设计
需求采集之后，需求筛选之前
产出：产品概念图
例图的效果是产品成型后才能画得出的，实际工作中在这个阶段可以用思维导图替代
表达：
产品与外界的关系
产业链结构
产品内部的关系
模块为单位
信息架构
《web信息架构》
激情四射的设计师
用户体验部门
用户研究员
交互设计师
视觉设计师
前端工程师
交互设计与敏捷开发的权衡
信息的呈现方式
字不如表，表不如图
文案
统一语言风格
阴险狡诈的运营师
负责把产品“卖出去”，让产品从“叫好”到“叫座”，获取更多用户
做裂变，病毒营销
运营负责带来用户，产品负责留住用户
产品与运营的矛盾
运营的KPI拉来了垃圾流量
制定KPI时不只看pv，更要看用户留存
营销本书的案例：李开复喝浙大咖啡
商业团队，冲锋陷阵
好产品还需市场化
定价与促销
成本导向，需求导向，竞争导向
销售与渠道
直销
分销
渠道
经销，赚差价
代理，赚佣金
渠道的推拉战术
《美第奇效应》
《水平营销》
需求维度
吃包子填饱肚子
替换
中药包子、美容包子
结合
画红心表白
反转
做包子教学
目标维度
中国人
外国人，主打神秘的东方膳食
宠物市场
地点和情景维度
场景是吃
抢包子竞技活动
造活动
时间维度
早上
夜宵
体验维度
包子和文化结合，皇城包子
有形的产品或服务
肉馅换成水果沙拉
加习惯
夸张
每个一斤重
旺仔小馒头
品牌特征
找到外国人做包子的方法改良后引进中国
换序
宣传健康
使用或购买
每天买
月付
倒序
预定
我们还能做什么
案例：通过一个光盘让传统企业用户去使用了e网打尽
技术团队，坚强后盾
容易被遗忘的角落
老板
最好的资源
背锅
问老板要让老板做选择题->做判断题（说出自己对于几种解决方案的考虑）
法务、财务、行政、IT
大家好才是真的好
所谓团队文化
虚无的无授权领导
行政上产品经理没有下级，但是做产品的过程中需要领导整个团队
如何让团队更开心
送礼物
高级的小玩意>低级的大玩意
吃不掉、用不掉、送不掉、扔不掉
对方想买却舍不得买
不要让对方选择
小奖不如没奖
项目开始前就给出承诺
送两件就分两次给
涨工资不如发奖金
战略：别让灵魂跟不上脚步
概要
产品设计要根据商业目的出发
难玩的游戏让玩家反复尝试，从而在过关后产生更大满足感
触及产品的灵魂
以价值观为根基
阿里巴巴的价值观
客户第一（把“客户，员工，股东”哪个放在第一位都没有对错）
培养大局观
不否认帕累托改进，但是大多数时候做改进的时候有得必有失，有时候只看到好处可能是因为站的低，这个时候可以向上级请教
美团pc版下单方式的改变
可行性分析三部曲
决定的是“做不做”
产品战略的具体制定，在项目管理里交“可行性分析”，在产品设计层次的角度叫“战略层”，在公司层面可能叫“战略规划”
我们在哪儿
市场扫描
PEST分析
political
economic
social
technological
这个分析可以用于那篇分析什么产品能取代微信的文章
竞品分析
经典方法：$APPEALS分析法
实战做法
试用产品
打电话给客服、销售套词
看行业分析报告
自我（自己的公司）分析
SWOT分析
我们去哪儿
宏观上的用户需求
选择细分市场和目标用户
个人用户
地域、年龄、收入
企业用户
员工数、年收入、行业
阿里巴巴案例
每一个层次的人群都是不同的细分市场，也对应着不同的产品
1 史前时期，仅仅听说过电子商务
静态网站
2 电子商务真正价值的萌芽，体会到这玩意有用
企业邮箱，搜索引擎推广
3“开源”主导的管理需求
统计分析工具、SEO
4“节流”主导的管理需求
CRM、OA等信息系统
5 整合应用阶段
ERP
我们怎么去
从“我们在哪儿”到“我们去哪儿”的策略
定价策略、推广策略、渠道策略、服务策略、财务策略、技术策略等
一次真实的产品预研
原因：公司组织架构重组，需要了解自己负责的产品如何与新公司的产品整合以发挥最大作用
手段
1 作为用户试用新公司的各个产品
2 向各个产品的产品经理要以下文档
产品介绍文档
产品的愿景、定位、发展规划
personas文档
产品的试用账号密码
产品最近的运营数据
3 考虑自己的产品与对方产品整合的每一个方案的弊端，采用SWOT分析，从产品用户，公司本身的角度考虑
做吧，准备出发
敢问路在何方
定好路标
一切尽在掌握
低头走路，抬头看天
我们急需靠谱的会议
发出会议邀请
注明时间、地点、议程、每一项议程的估计时长
需要讨论的文档初稿
与关键人物（老板）提前确认好事情，串供
明确的主持人和记录人
所有事情尽量在会上达成一致，给出会议决议
罗伯特议事规则
“所有人提供意见，少数人讨论，一个人拍板”
仰望战略会议
KPI，KPI，KPI
SMART
案例
原因：销售部门KPI与产品部门KPI正好相反，前者是要更多的购买者，后者是要更多使用者，活跃度，而恰好企业产品的购买权在老板，使用者是下属
解决方式：增加一个服务部门，关注使用用户/付费用户。活跃用户⊂使用用户⊂付费用户
本书的源头活水
产品经理的自我修养
爱生活，才会爱产品
菜单设计
根据特定人群细分版本
情侣版：菜名暧昧
针对特定时间、事件细分版本
毕业季
有理想，就不会变咸鱼
会思考，活到老学到老
能沟通，在什么山头唱什么歌
土老板破冰必杀技
产品经理主义
好电影是怎么做出来的
海底总动员中有鱼游动时不摆动尾巴，导演为了让用户觉得有美感改成了摆尾巴
春晚
目标用户是二三线城市的中年及老年人
有赞助的话设计到各方的商业利益
市场策略
影响力太大，不能轻易变
市场细分
地方台。公安部晚会等
0 条评论
下一页
