人人都是产品经理笔记

人人都是产品经理笔记的思维导图，产品经理的自我修养如下： 爱生活，才会爱产品 有理想，就不会变咸鱼 会思考，活到老学到老 能沟通，在什么山头唱什么歌

人人都是产品经理笔记

• 写给-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评审
        • 设计评审
        • 测试评审
      • 分支主题
  • 山寨级项目管理
    • 文档管理
      • 建立自己的文档规范
        • 分支主题
        • 最适合开始做文档规范的时机是在产品1.0版本发布，进入1.1,1.2版的升级阶段，但尚未开始研发2.0的时间当口
      • 多人协作与版本管理
        • 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正好相反，前者是要更多的购买者，后者是要更多使用者，活跃度，而恰好企业产品的购买权在老板，使用者是下属
      • 解决方式：增加一个服务部门，关注使用用户/付费用户。活跃用户⊂使用用户⊂付费用户
  • 本书的源头活水
• 产品经理的自我修养
  • 爱生活，才会爱产品
    • 菜单设计
      • 根据特定人群细分版本
        • 情侣版：菜名暧昧
      • 针对特定时间、事件细分版本
        • 毕业季
  • 有理想，就不会变咸鱼
  • 会思考，活到老学到老
  • 能沟通，在什么山头唱什么歌
    • 土老板破冰必杀技
  • 产品经理主义
    • 好电影是怎么做出来的
      • 海底总动员中有鱼游动时不摆动尾巴，导演为了让用户觉得有美感改成了摆尾巴
    • 春晚
      • 目标用户是二三线城市的中年及老年人
      • 有赞助的话设计到各方的商业利益
      • 市场策略
        • 影响力太大，不能轻易变
      • 市场细分
        • 地方台。公安部晚会等