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