1、2020 人 人 都 是 产 品 经 理 演讲人2025-11-11目录01.第一章 写给1-3岁的产品经理02.第二章 一个需求的奋斗史03.第三章 项目的坎坷一生04.第四章 我的产品，我的团队05.第五章 别让灵魂跟不上脚步06.第六章 产品经理的自我修养第一章 写给1-3岁的产品经理第一章 写给1-3岁的产品经理为什么要做产品经理第一章 写给1-3岁的产品经理我们到底是不是产品经理产品是什么？产品就是用来解决某个问题的东西产品经理的演变分支主题产品经理之路走向尽头？ 任务越来越多，需要更加细分方向的产品经理第一章 写给1-3岁的产品经理产品经理的“管理难题”信息不足，难以决策，拍脑袋人
2、力不足资金不足时间不足如何入行JD与现实研究产品经理的招聘广告最在乎的是应聘者有没有激情， 是否够机灵、好学，逻辑思维是否清晰，沟通表达是否顺畅等其次是潜力，主要表现为对产品思路的考察应聘者在乎的是从产品经理的周边工作接触入手根据自己目前的经验找最容易入手的部分“研究几十家公司的产品经理招聘广告。我一直觉得把研究结果做成一 份漂亮的调研报告，而后去应聘产品经理是个很靠谱的事，而且我相信大家多半都很 想读这样的一份报告，可惜还没见过有人这么做。”寻找切入点第二章 一个需求的奋斗史第二章 一个需求的奋斗史01一个需求的奋斗史02从用户中来到用户中去（概述）03需求采集的大生产运动04听用户的但不要
3、照着做05活下来的永远是少数第二章 一个需求的奋斗史从用户中来到用户中去（概述）需求采集01需求分析02需求管理03需求采集常用方法 数据分析调查问卷用户访谈“需求采集人人有责”的意识需求分析01听用户的但是不要照着做02确定需求的基本属性03分析需求的商业价值04初评需求的实现难度第二章 一个需求的奋斗史需求采集的大生产运动需求采集的过程采集的方法需求采集的过程执行采集资料整理明确目标选择采集方法制定采集计划采集的方法分支主题定性地说：用户访谈1常用在新产品方向的预研时，或通过数据分析发现现象时的研究2常见问题与对策3用户大会常见问题与对策u用户“言行不一”u以偏概全u用户太能闲聊u产品经理
4、过于强势u审讯室定性地说：用户访谈常见问题与对策u关注目标u用户不是设计师u不聊技术u鼓励讲故事u避免诱导性的问题定性地说：用户访谈用户大会u成本比较高u明确大会目的u资源确定u现场u会后定性地说：用户访谈定量地说：调查问卷常见问题与对策02设计一份实际的问卷03tips01tipsu 访谈偏开放，问卷偏封闭u 适合大量用户的浅层信息收集，最好是选择题u 可以通过用户访谈的结果来辅助制定问卷的问题u 作答时间在10min之内u 有难度的、敏感的问题放在中间u 隐私问题放最后定量地说：调查问卷常见问题与对策u样本偏差u样本过少u问卷内容的细节问题定量地说：调查问卷定性地做：可用性测试1通过让实际
5、用户使用产品或原型方法来发现界面设计中的可用性问题2过程3常见问题与对策定性地做：可用性测试过程招募测试用户，注意选择目标群体准备测试任务测试过程，观察和记录用户的行为，发现问题测试结束后常见问题与对策u为时晚矣u觉得成本太高了不想做u是测试产品，不是测试用户u该做的u不该做的定性地做：可用性测试常见问题与对策 过于严谨和学术，导致数据分析的性价比并不高数据没有假，但是会有错误的解读方法临时抱佛脚商业价值转变思路 在对产品足够熟悉对基础上作出方向性假设提取相应数据分析，得到一些现象，尝试进行解释做用户调研修正解释，得到最终结论将结论用于指导产品发展方向定量地做：数据分析需求采集人人有责二手需求
6、 在产品成熟期，来自和用户有接触的（如销售）各个部门二手需求会有一定程度的扭曲，因为转述者本身并不是需求者解决办法：单项需求卡片一手需求 在产品早起，由产品经理驱动的主动采集需求采集的方法现场调查和客户一起工作一段时间01非常深入02但是受众面很窄03AB测试u适用于大用户量，成本低采集的方法采集的方法日记研究0201研究使用者（一般是同行）写的体会（日记、微博、推文等）适用于个人应用采集的方法卡片分类法将需求分解成一个个卡片让用户来决定如何组织产品的结构采集的方法自己提需求第二章 一个需求的奋斗史听用户的但不要照着做明确我们存在的价值1给需求做一次dna检测2用户需求与产品需求用户需求经过需
7、求分析变成产品需求用户需求产品需求需求分析用户需求u用户自以为的需求u经常表达为用户自己设想的解决方案用户需求与产品需求产品需求u经过我们的分析找到的真实需求u经过加工表达为产品的解决方案用户需求与产品需求需求分析u从用户的表述出发，找到其内心真正的渴望，再转化为产品需求的过程u好的需求分析师无视用户的方案，而是去探究他们真正想要的，并给出更好的方案u纠结点：要“设计师”还是要“装修队”用户需求与产品需求满足需求的三种方式需求来源于理想与现实的差距 2014一、改变现状即开发某种产品，是最笨的办法2015二、降低预期 2016三、转移需求引导用户去关注其他更重要更核心的需求2017电梯案例（P
8、69） 2018创造需求u产品设计的最高境界明确我们存在的价值就是把用户需求转为产品需求，然后确定产品需求的各种属性u分支主题给需求做一次dna检测把用户需求转化为产品需求u略给需求做一次dna检测给需求做一次dna检测确定需求的基本属性提交人、时间02编号01所属模块03名称04描述05提出人信息、提出时间06需求的种类 . . .为了支持我们的工作而产生的需求内 部 需 求 b u g 修 复 新 增 功 能 功 能 改 进 体 验 提 升060504030201需求的层次基础（雪中送炭，没你不行）扩展（锦上添花）期望需求兴奋需求增值需求 参考KANO模型 需求的类型随着当前的情况而变化，
9、扩展功能随着推广可能会变成基础功能，比如能拍照的手机 商业价值是最核心的关注点 商业价值的几个指标 重要性 紧急度 持续时间 商业优先级需求的商业价值需求的实现难度需求的实现涉及很多方面：产品、开发、测试、服务等 通常选取“开发”这个资源瓶颈来代表需求实现的难度 开发量是必须评估的，需要经验丰富的技术经理、系统分析师、架构师等来做 项目启动前初评，启动后还要继续预估，不断修正 工期与工作量工作量用“人天”做单位，但是工期涉及到人的连续性给需求做一次dna检测性价比性价比至上性价比=商业价值/实现难度是决定排期的最高指标第二章 一个需求的奋斗史活下来的永远是少数01需求筛选为什么会产生需求筛选？
10、02030405把需求打包产品会议少做就是多做需求筛选分支主题为什么会产生需求筛选？实质上是“资源永远不够”和各部门对于可占用资源的抢占“按产品线划分部门”和“按只能划分部门”导致的资源分配问题产品线划分 产品经理权利更大，有专属的资源，小团队沟通顺畅按职能划分 有利于资源共享激发鲶鱼效应效率较低把需求打包 用 获 得 的 资 源 c o v e r 项 目 需 求 列 表成本可接受范围内尽可能细化粒度细化粒度有助于选择性价比更高的每条需求的工作量最好不要超过5人天考虑需求的粒度 打包逻辑更加紧密的需求 考 虑 依 赖 关 系 ： 功 能 与 功 能 、 人 力 资 源与 功 能 回顾上一次会
11、议通过的项目情况产品会议BRD项目背景A商业价值B功能需求描述C非功能需求描述D资源评估E风险和对策F项目背景u为什么u解决什么u有什么必要性BRD功能需求描述u描述一下打包好的需求u画出业务逻辑关系u时间充足可以给个demoBRD风险和对策u让老板把关一下风险问题BRD少做就是多做 用100%的质量去做75%的数量 从“没想到去做”到“权衡利弊后不去做” 努力发现“四两拨千斤”的解决方案，先从最低成本的角度去考虑多采集是为了更全面的看待事物多放弃是在掌握了全局之后进行的去其糟粕从“多采集”到“多放弃”第三章 项目的坎坷一生第三章 项目的坎坷一生1分支主题2分支主题3从产品到项目4一切从kic
12、k off开始（立项）5关键的青春期，又见需求6产品经理在各个阶段的控制第三章 项目的坎坷一生山寨级项目管理01物竞天择适者生存02第三章 项目的坎坷一生从产品到项目做产品vs做项目02产品经理vs项目经理03什么是项目01什么是项目只进行一次包含多项互相关联的任务有绩效、时间、成本和范围限制做产品vs做项目01产品是一个解决方案，项目是一个过程02生命周期来看03具体任务来看04出产物来看05做产品是通过一次次的项目达成的，但不是项目的简单累积06产品成为臃肿的项目集合体时，就要考虑细化市场，推出产品线做产品vs做项目生命周期来看产品较长，从规划到消亡，无法明确时间01项目较短，结束时间明确
13、，从立项到验收，就结束了02做产品vs做项目具体任务来看产品注重探索和变化1项目注重计划和控制2做产品vs做项目出产物来看01产品是可批量生产的、相对通用的02项目是一次性的、个性化的2产品经理vs项目经理产品经理靠想（内部驱动）做正确的事以市场需求和商业价值为导向产品经理vs项目经理项目经理01靠做（外部驱动）02正确的做事03在时间、成本等资源约束下完成目标，以“合格完成”为导向为什么让产品经理管项目研发管理项目 倾向于简化项目，做轻松的事容易导致商业价值不足产品设计师管理项目 不断增加需求，导致各种延期影响士气第三章 项目的坎坷一生一切从kick off开始（立项）项目的沟通团队组建启动
14、计划确定tip：思维模型养成，在一次次项目中不断使用WBS方法（或其他方法）构建自己的“模板/方法论”项目督导委员会 老板参与老板背锅、买单、批准，也是对项目成员的保护被老板看见自己的努力，也有利于激发团队动力团队组织结构团队组建工作量评估三点评估法粒度比初评的时候更细，至少精确到1人天，甚至1人小时1人天=56一人小时依赖带来的时间问题，无法通过投入资源解决，反而会让场面更糟糕工期0102030405三点评估法u最悲观的工作量u最乐观的工作量u最可能的工作量u工作量=（乐观+悲观+最可能x4）/6工作量评估工作量评估工期将工作量转化为工期排期，这时候要考虑各种依赖关系工期包含了由依赖产生的等待时间还要考虑意外情况不管有多少资源，任务都会在最后一刻才完成项目的沟通1周期：日/周2渠道：会议/邮件/IM等3发起者：PM、开发经理、测试经理等4参与者：所有干系人，不要遗漏边缘者5沟通方式第四章 我的产品，我的团队第四章 我的产品，我的团队第五章 别让灵魂跟不上脚步第五章 别让灵魂跟不上脚步第六章 产品经理的自我修养第六章 产品经理的自我修养感谢聆听2020
