人人都是产品经理
- 互联网产品设计的五层架构——战略、范围、结构、框架、表现。
写给-1到3岁的产品经理
为什么要做产品经理
- 对一个产品，用户总是分为新手、专家和中间用户。
- 坏产品，无处不在的危险
- 好产品，从垃圾桶到洗手间
我们到底是不是产品经理
- 产品就是用来解决某个问题的东西。
- 产品就是要同时解决用户的问题和公司的问题。
- 涉及产品规划、数据分析、用户研究、需求分析、功能设计、项目管理、敏捷方法。
- 职位目的：想要更了解产品与它面临的竞争情况，最终目的是要满足顾客的需求。
- 管理的能力，其实就是在资源不足的情况下把事情做成。
我真的想做，怎么入行？
- 最在乎应聘者有没有激情、是否够机灵、好学，逻辑思维是否清晰，沟通表达是否顺畅等。
- 先在本职工作上找到与产品有关的事情做一些尝试，并且考虑先从产品经理周边的职位做起。
- 练习一下BRD、PRD。
一个产品经理的-1到3岁
- 产品经理不仅仅是做需求
- 学过的知识可以不重要，重要的是练好思维方式，学会学习。
一个需求的奋斗史
一个需求的奋斗史
从用户中来到用户中去
- 用户是需求之源
- 因为生活中存在太多的问题，从而产生了不满意，而问题就是“理想与现实的差距”，那么人类会很自然地产生“减少甚至消除这个差距”的愿望。
理解用户是产品经理最重要的素质之一。
- 用户是使用产品的人，客户是购买产品、为产品付钱的人。
- 不同的用户有重要程度之分，我们必须、也只能有所偏重。
- 不要试图满足所有用户。
- 优先满足哪些用户需要和产品的商业目标要结合起来考虑，简单说就是看KPI是什么。
- 你真的了解用户嘛
- 体会真正的用户
- 试着描述用户
- 怎么说表现了目标的观点，怎么做反映了行为，用户怎么说和怎么做经常是不一致的。
- 定性研究可以找出原因，偏向于了解；而定量研究可以发现现象，偏向于证实。
需求采集的大生产运动
- 需求采集过程：明确目标、选择采集方法、指定采集计划、执行采集、资料整理，然后进入下一步的需求分析阶段。
- 定性地说：用户访谈
- 注意点
- 避免一组固定的问题
- 首先关注目标，任务其次。比用户行为更重要的是行为背后的原因。
- 避免让用户成为设计师。
- 避免讨论技术。
- 鼓励讲故事。
- 避免诱导性问题。
- 定量地说：调查问卷
- 不要超过10分钟，敏感问题放中间，个人信息问题放最后。
- 注意调查问卷的设计
- 定性地做：可用性测试
- 可用性测试在开发的任何阶段都可以做
- 定量地做：数据分析
- 在对产品足够熟悉的基础上，先做出方向性的假设，再提取相应的数据并分析，得到一些现象，最好是之前没发现的现象，然后尝试解释，接下来做用户调研修正解释，最终知道产品发展方向。
- 需求采集人人有责
- 关注一手需求，其实是二手需求。
- 需求采集方法：现场调查、AB测试、日记研究、卡片分类法、自己提需求
听用户的但不要照着做
- 明确我们存在的价值
- 用户需求：用户自以为的需求，并且经常表达为用户的解决方案。
- 产品需求：经过我们的分析，找到真正的需求，并且表达为产品的解决方案。
- 需求分析：从用户提出的需求出发，找到用户内心正真的渴望，再转化为产品需求的过程。
- 满足需求的三种方式：改变现状、降低理想，转移需求。
- 产品设计的最高境界——创造需求。
- 给需求做一次DNA监测
- 把用户需求转化为产品需求
- 需求种类
- 分类：新增功能、功能改进、体验提升、BUG修复、内部需求
- 层次：分为“基础、扩展（期望需求）、增值（兴奋需求）”，可参考KANO模型。
- 分析需求的商业价值
- 确定商业价值后，还要初评需求的实现难度（工作量、开发量）。
- 一切看性价比
- 性价比 = 商业价值 / 实现难度（简化为开发量）
活下来的永远是少数
- 永远忘不掉的那场战争
- 做项目，终极目标就是：多快好省，即范围大、时间段、品质高、资源省。
- 需求的粒度在可行的情况下尽量小。
- BRD（Business Requirement Document）、MRD（Market Requirement Document）、PRD（Product Requirement Document）
- BRD内容：项目背景、商业价值、功能需求描述、非功能需求描述、资源评估、风险和对策。
- 别灰心，少做就是多做
- 情愿把一半的功能做到尽可能完美也不要把全部功能都做成半吊子。
心急吃不了热豆腐
产品经理最基本的素质之一——热爱产品。
- 在高层决定公司战略的前提下，好的产品对我们的帮助会远远大于我们对产品的帮助。所以，产品经理的前若干年，好的公司，好的产品，好的老板，很重要。
项目的坎坷一生
项目的坎坷一生
从产品到项目
- 会有一个已经“结项”的项目，但不可能有一个已经“完成”的产品。
- 项目的定义：只会进行一次，包含多项目互相关联的任务，并且有绩效、时间、成本和范围限制的一项工作。
- 产品经理——靠想。产品经理是做正确的事，其所领导的产品是否符合市场的需求，是否能给公司带来利润。内部驱动。最重要的是判断力和创造力。
- 项目经理——靠做。项目经理是把事情做正确，把事情做得完美，在时间、成本和资源约束的条件下完成目标。外部驱动。最重要的是执行力和控制力。
- 一个事物必然有它的两面，如果你只看到了一面，说明你只看到了系统的一部分，这时你一定要跳出去，寻早另一面，之后再努力寻找“对立”背后的“统一”，正如黑格尔所说的“正反合”。
一切从KickOff开始
- 做项目的本质就是在保证品质的前提下，在时间要求、人财务花费、项目范围三点上做平衡。
- 沟通从头开始。
- 有自己的WBS（Work Breakdown Structure,工作分解结构）文档。
关键的青春期，又见需求
- 真的要写许多文档
- BRD，商业需求文档。这是产品生命周期中最早的文档，其内容设计市场分析、销售策略、赢利预测，短小精炼，通常给老板演示PPT，主要为了获得认可，争取资源。
- MRD，市场需求文档。获得老板支持后，进入实施阶段，需要写出MRD，需有更细致的市场与竞争对手分析，包括可通过哪些功能来实现商业目的，功能、非功能模块，功能的优先级等。这是从商业目标到技术实现的转化文档。
- PRD，产品需求文档。PRD是对产品功能的进一步细化。文档主要包含整体说明、用例文档、产品Demo等，会对产品功能做具体描述。
- FSD（Functional Specifications Document）,功能详细说明，从这步开始会出现很多技术的内容，产品界面、业务逻辑的细节都要确定。与此同时，硬件系统的设计、数据库设计、表结构设计等工作，也开始由架构师、系统分析师编写了。
- 学一点UML（Unified Modeling Language，统一建模语言）：类图、用例图、状态图、时序图、活动图及其他。（用visio画）
- 字不如表，表不如图。
- 用例文档，UC，是需求人员写给开发人员看的一种最基本的文档。
- 需求活在项目中
- 写作 --> 评审 --> 修改 --> 评审
- 评审：需求评审、设计评审、测试评审
日常需求发布流程
成长，一步一个脚印
- 开发：设计 --> 设计评审 --> 编码 --> 单元测试
- 测试：TC（Test Case）编写 --> TC评审 --> 冒烟测试 --> 功能评审 --> 测试
- BUG
- 项目发布：发布评审 --> 预发布 --> 发布 --> 线上验证
- 作为项目经理，应该时刻做到为团队成员争取各种精神、物质奖励。
山寨级项目管理
- 计划和控制，就是项目管理。
1.文档只是手段 - 建立自己的文档规范。
- 模版的作用
- 让经常看同类文档的人提高效率
- 让写文档的信任可以尽快上手
- 让写作者不会遗漏考虑某些内容
- 只制订却不执行的规定，只会反过来降低已有规定的权威性。
- 多人协作与版本管理：Wiki
- 用版本号管理文档
- 流程也是手段
- 长视者把目的当手段，短视者把手段当目的。
- 个人的核心竞争力是把显性知识转化为隐性知识的能力，而团队的核心竞争力是把隐性知识转化为显性只是的能力。
- 商业评审的三个决定是：项目继续、重新定向、项目终止。
- 技术评审的三个决定是: 项目继续、有风险的继续、必须解决某问题后再继续。
- 敏捷更是手段
- 从书本到实践
- 有计划，更要“拥抱变化”。
- 迭代周期尽量不加任务。
- 集中工作，小不快跑。
- 持续细化需求，强调测试。
- 不断发布，尽早支付。
- 敏捷沟通：项目看板、项目墙。
- 任何情况下，我们都要做好手头的事情，确保“就算这事儿对公司来说又黄了，我也要通过做事有所收获”
物竞天择适者生存
- 亲历过的项目特色
- 老板项目、封闭开发、项目外包
- 一路坎坷，你我同行
- 边计划、边行动、边修改。
- 80%以上的项目是不成功的。
我的产品，我的团队。
我的产品、我的团队
大产品，大设计，大团队
- 产品之大
- 时间之大：产品生命周期
- 产品生命周期里的五种用户：创新者、早期追随者、早期主流用户、晚期主流用户、落伍者。
- 空间之大：商业、产品、技术
- 商业、产品、技术，任何一个公司必然有它的强项和弱项，它不可能也没有必要在这三方面都很强，一是因为构建“性价比团队”的考虑，二是因为都强的话互相压不住反而造成内耗，所以更重要的是找到自己公司、或团队、或产品的那个突出的刀尖，也就是所谓公司的DNA。
- 在找工作的时候必须调查清楚自己的职位在公司里是不是最受重视的，是不是强势方，这很重要。
- 设计之大
- 产品设计的五个层次
- 战略层：明确商业目标和用户需求，找准方向，重点是解决两者之间的冲突，找到平衡点。
- 范围层：明确“做多少”。
- 结构层：考虑产品的各个部分互相之间是什么关系。
- 框架层：
- 表现层：视觉设计和优化。
- 设计的目标分为三个层次：本能水平设计是基础，产品要有用；行为水平设计是保证，产品要能用；反思水平设计是升华，是难以琢磨的“用的爽”。
- 反馈：动作前的可预测、动作中的积极响应、动作后的可评估。
- 容错：一些貌似多余的强制性设计，不可逆操作可以后悔。
- 简化：利用用户已有的知识。
- 团队之大
- 偶尔为之的事情追求可行解，经常为止的事情最求最优解。
游走于商业与技术之间
- 心思缜密的规划师
- 从概念设计到信息架构
- 画概念图，表达出产品与外界、内部的关系。
- 激情四射的设计师
- 规划师更多的是“结构化思维”，保证产品有用，能满足用户的某些需求，让产品“从无到有”；而设计师更多的是“形象化表达”，保证产品好用，能让用户用起来舒服，让产品“从有到优”。
- 阴险狡诈的运营师
- 运营负责把产品卖出去，让产品从“叫好”到“叫座”，让更多的人愿意使用产品。
- 事件+病毒营销
商业团队，冲锋陷阵
- 我们觉得某样东西虚知识因为对它不熟悉而已。
- 销售是增加新客户，服务是稳住老客户。
- 好产品还需市场化
- 当自己对某个领域不熟悉的时候，做起事来总会把问题想象得很复杂，把自己知道的所有知识都用上，而真正的高手，是可以一下子就找出问题的关键，然后用最最见到那的方法就搞定。
- “高价炮灰、低价炮灰”
- 开过视野的水平营销
- 我们还能做什么
- 服务部门是为昨天的利润工作，给已经购买产品的客户提供承诺的价值；销售部门是为今天的利润工作，把产品变成利润，争取更多的客户；开发部门是为明天的利润工作，确保明天我们有优秀的产品可以卖；研究部门是为后天的利润工作，了解趋势、发展科技，保证永远处于领先位置。
- 维护一个老客户的成本大约是开发一个新客户的成本的四分之一。
技术团队，坚强后盾
- 超级理性的人很明白“没有规矩，不成方圆”的道理，他们喜欢被规则管理而不是被人管理。
- 思路的变形：不再考虑产品怎么做更好，而是去想如何说服对方。
容易被遗忘的角落
- 最好的资源：老板
- 让老板做问答题 --> 选择题 --> 判断题。
大家好才是真的好
- 所谓的团队文化。
- 虚无的无授权领导
- 管理岗位的优势：
- 管理岗位利于拥有话语权
- 管理岗位利于获取信息
- 管理岗位利于争取资源
- 管理岗位的劣势：
- 管理岗位有很多行政工作
- 管理岗位会让人脱离群众
- 让优秀的产品经理在专业线路上拥有高级别；对于产品、业务的决策有充分的话语权；可以参与管理会议的业务讨论；可以拥有临时的资源支配权，并给管理层提供同事的考核建议；但不负责管理者的行政工作，而是继续和同事打成一片，用产品证明自己。
- 赠送礼物和激励员工的艺术
- 大中之小不如小中之大。
- 有用的不如无用的。
- 需要的不如想要的。
- 有选择不如无选择。
- 晚说不如早说。
- 一次送不如两次送。
- 公开不如不公开。
- 涨工资不如发奖金。
- 奖励或送礼的目的并不是真正给对方最大的效用，而是要让对方开心，并且感激和记住你。
别让灵魂跟不上脚步
触及产品的灵魂
- 产品的灵魂——战略
- 以价值观为根基
- 培养大局观
可行性分析三部曲
- 我们在哪儿
- 确定公司的价值观、使命、愿景，关于公司、市场、竞争对手现状的各种背景信息的采集与分析。
- 市场扫描（PEST分析）、竞品分析、自我分析（SWOT分析）
- 小的成功靠朋友，大的成功靠对手
- 我们去哪儿
- 宏观上的客户需求
- 我们怎么去
- 一次真正的产品预研
做吧，准备出发
1.敢问路在何方
- 产品路标计划
- 低头之路，抬头看天
- 开会和做一个产品一样，不要试图在会议中解决很多问题。
- 会议要有明确的主持人和记录人。
- 所有人提供意见，少数人讨论，一个人拍板。
产品经理的自我修养
- 爱生活，才会爱产品
- 有理想，就不会变咸鱼
- 会思考，活到老学到老
- 只有方法，没有答案
- 能沟通，在什么山头唱什么歌
- 理论上严格意义的“充分沟通”是不存在的。
- 沟通不是为了说服，而是为了更好地认识世界。
- 职场的点对点沟通
- IM：成本最低，适合不紧急不重要的沟通。
- 电话：成本适中，适合紧急不重要的沟通。
- 面谈：成本最高，适合紧急且重要的沟通。
- E-mail：成本始终，适合重要不紧急的沟通。
- 尽快找出对方感兴趣的、熟悉的、擅长的、自己也懂一点的话题，从而破冰成功。
- 产品经理主义
- 解决问题的通用思路：为了什么？做什么事，解决什么人的什么问题？何时做？谁来做？效果如何？
