AB 测试。基于大用户量比较合适，比如有一个按钮不知道是放页面的左边好，还

是右边好，而我们有 10 万用户，那就先随机挑选少量的用户发布这个按钮，1000 人放 左边，另外 1000 人放右边，然后过一段时间分析结果，再决定剩下的 98%用户该怎么 办。很明显，这也是让用户直接参与了设计，这样低成本的方法让很多传统行业的同 学羡慕不已。

用户需求：用户自以为的需求，并且经常表达为用户的解决方案。

产品需求：经过我们的分析，找到的真实需求，并且表达为产品的解决方案。 需求分析：从用户提出的需求出发，找到用户内心真正的渴望，再转化为产品需 求的过程。

伟大的需求分析师，可以无视用户想要的东西，去探究他内心真正的渴望，再给 出更好的解决方案，或者说是用户真正需要的东西，这就是本节标题的意思——我们 存在的价值。

需求来源于理想与现实的差距，那么减小这个差距就有三种方式：

改变现状。是我们最常用的，去开发某种产品，但也是最笨的办法。

降低理想。不要忽视精神的力量，什么“打预防针” 、 “丑话说在前头”这类句子想必大家都经常听到。

转移需求。因为人类的注意力是有限的，所以引导用户去关注其他事物，他就会觉得这个差距没那么可憎了。我们也可以说，人的行为是需求驱动的，想改变人的行为，可以寻找更强烈的需求展现给他，而让他不再纠结于原来的需求

需求：可以分为“新增功能、功能改进、体验提升、Bug 修复、内部需求”等。

层次：把需求分成“基础、扩展（期望需求）、增值（兴奋需求）”三层，理论 依据参见KANO模型。

性价比 = 商业价值÷实现难度（简化为开发量）

情愿把一半的功能做到尽可能完美也不要把全部功能都做成半吊子。

智能手机的金字塔需求:

第二篇：《人人都是产品经理》的读书笔记

1.写给-1到3岁的产品经理

1.1为什么要做产品经理----世界需要

Tips：好的产品不需要用户思考

例子A：路牌标识不明

例子B：Z字形的好看盲道为盲人增加行走障碍 => 花哨的视觉效果不一定好

例子C：回收、不可回收垃圾桶的区别：无标识的垃圾桶 -> 有标识的垃圾桶 -> 写明什么东西可回收什么东西不可回收的垃圾桶

例子D：宏伟得像会议室、无标识、带门把手让人不知道是推是拉的厕所门 VS 简洁的、带标识、无把手必然是推的厕所门

1.2我们到底是不是产品经理

产品是同时解决用户问题（用户需求）和公司问题（盈利）。

一个对比：

传统意义下的产品经理偏重于产品已经做好以后，怎样管理、销售，偏重于市场、商业端 软件行业的产品经理偏重于产品“从无到有，从有到优”的过程

差异的原因，导致对产品经理的要求：

原因A：传统行业较成熟，创新小，用户习惯难改变 VS 软件行业是新兴行业，要创新，占领用户并主导用户习惯 => 要求产品功能本身的规划

原因B：传统行业的产品为实物，需要打通供应链 VS 软件行业的产品为虚拟物品，复制成本低，较少考虑供应链，一个细节改进可以增加千万用户 =>要求细节

原因C：传统产业产品生命周期几年 VS 软件行业产品生命周期几个月 => 项目过程不复杂，要求兼顾项目管理

原因D：传统行业靠产品本身价值赚钱，买产品的人未必用 VS 软件产品大多免费，盈利模式多元，直接面对海量终端用户 => 要求用户研究、数据分析

原因E：传统产品用户花钱买，不爽凑合着用 VS 软件产品用户免费买，不爽换同类产品 => 要求重视用户体验

非典型产品经理，不需要全能

现在产品经理的三大变化方向：产品管理团队、事业单位经理的任用（更大权力）、更专业取向

在一线员工眼中，管理是在资源不足的情况下把事情做成的能力。通常表现为：

信息不足以决策；时间不足以安排周密的计划；人员不足以支持工作强度和难度；资源不足以自由调配。

1.3我真的想做，怎么入行

做产品的大前提是喜欢做产品，同时是喜欢做产品经理而不是喜欢做用户。

例子：对于某游戏，用户想我怎么玩可以赢更多的钱，产品经理想为什么这么设计。

对于应届生，面试官最看重的是有没有激情，是否机灵好学，逻辑思维是否清晰，沟通是否流畅。其他(比如对行业的熟悉)会次要。

对于工作几年的人，不管以前是做什么的，都可以转行做产品经理。建议先在本质工作上找到产品有关的事情做些尝试，并且考虑从产品经理周边的职位做起。

例子：原来做开发的,利用参与需求评审的机会，多思考，对需求提出合理建议。以后做产品经理，可以从“需求分析师”切入。

1.4一个产品经理的-1到3岁

作者本身学生物

入行头半年，打杂：不负责产品的任何模块，写框架已被别人搭好了的需求文档，但他好学，主动熟悉工作中的技能。

入行半年后，学习“怎么做”：以product designer的身份负责网店版的某些模块，决定某个功能怎么做，比如写需求文档，配合做demo，跟进开发、测试、发布的过程。但是很看重自己负责的模块，缺乏整个产品层面的权衡认识。

入行一年，开始问“做不做，做多少”：在完全掌控需求采集、分析、筛选的过程中学会权衡取舍，砍功能也下得了手。

入行两年，项目与团队：新项目企业邮局，学习到除产品需求以外的东西，比如项目管理、流畅、敏捷方法。体验到操心的感觉，从接受别人的会议邀请，到给别人发会议邀请；从有事才去找人帮忙，到尽量去了解周边团队在做啥，并施加影响；从一个人做事，到做好自己本职工作，其他交给团队，再到主动定规范，把工作分出去。

入行三年小结，战略与修养：参与产品的可行性研究；思考产品经理的基本修养：爱生活，有理想，会思考，能沟通；立志做老师，完成“三个一工程”：一个网站，一门课程，一本图书

Tips:公司想做的产品很多，要从中挑出值得实施的，果断放弃很重要，放弃的原则与价值观、战略有关

2.一个需求的奋斗史

Tips:相比较“接到一个任务，然后把它完成”，对于产品经理，更重要的是“发现一个问题，然后设法把其转化为一个任务来解决”。

2.1从用户中来到用户中去

2.1.1用户是需求之源

人的需求，根据马斯洛的需求层次理论，可划分为五个层次，由低到高，分别是：生理需求、安全需求、社交需求、尊重需求、自我实现需求。

产生需求的原因是：生活中存在“理想与现实的差距”，人类很自然地产生“减少甚至消除这个差距”的愿望。

通过研究需求，可以增强对用户的理解。理解用户，是产品经理的重要素质之一。

例子：小明要电钻 -> 要在墙上打洞 -> 要挂上画 -> 屋子太空旷，不温馨 => 安全需求和社交需求

用户与客户的区别：用户，也叫终端用户，是使用产品的人；客户是购买产品的人。 相对于客户的需求，我们更重视您的用户的需求 => 用户是需求之源。

UCD，以用户为中心的设计

UBD，以老板为中心的设计，适用于没太多精力做用户研究、公司老板最了解用户且能抓住商机的创业小团队。

试图满足所有用户的需求是一个灾难，会让产品变成一个臃肿不堪、谁都不满意的四不像。 我们应该优先照顾其中一部分用户的需求。这种优先要考虑到产品的商业目标。

例如：对于已经成熟且拥有市场霸主地位的产品，比如qq，应关注核心用户的需求；对于刚刚起步的产品，先满足大量的一般用户的需求。

2.1.2你真的了解用户么？

许多用户对所有产品了解甚少。

先描述自己，创建人物角色persona是一种快速描述用户的方法。persona的内容包括：职业、预算、爱好、性格、行业信息（过去经历、当前状态、未来计划、痛处）、计算机和互联网使用情况、用户目标、商业目标

用户研究方法可用一张二维图表示：横向是用户的说和做。“眼见为实耳听为虚”，看到用户怎么做比听他们怎么说更真实，但只了解怎么做是不知道背后原因的。纵向是定性与定量。定性研究偏向于找出原因，定量研究偏向于证实。

做用户调查的目标是：坚决杜绝“经组织决定，用户需要一个xx功能”，要是实在在地把用户当做需求之源。

2.2需求采集的大生产运动

要根据资源多少采用合适的用户研究方法。若资源少，查二手资料后和同事讨论，猜测用户怎么想怎么做。

需求采集有以下步骤：明确目标 -> 选择采集方法 -> 制定采集计划 -> 执行采集 -> 资料整理 -> 下一步的需求分析

2.2.1定性地说：用户访谈

用户访谈的常见问题：

1.说与做不一致。

例子：索尼做用户调查，发现用户更喜欢黄色游戏机。当索尼让他们随意挑选游戏机时，更多用户挑的是黑色游戏机。

对策：让用户可以和产品交互的情况下访谈；要区分用户说的事实与观点。“我做了啥，遇到啥问题”这种事实比“我认为”这种观点可信度高。

2.样本少，以偏概全

例子：只找本市的用户，优先拨打留了手机的用户，愿意来公司做访谈的用户

对策：在访谈报告中注明可能引起偏差的因素；增量访谈，即先少量调查，若结论有变，再加大样本量

3.用户过于强势，把我们往沟里带

例子：漫无目的地侃

对策：；牢记访谈目的，若话题不对，赶紧往正道上掰

4.我们过于强势，把用户往沟里带

例子：在访谈时指出用户哪里理解不对，说自己产品多么好

对策：牢记访谈目的，管好自己的嘴

Tips:避免固定问题；更关注为什么，而不是怎么做；听用户说但不要照着做；避免讨论技术；鼓励讲故事；避免诱导性问题(如果有xx功能，你会使用么？)

例子：记一次用户大会的提纲（用户大会是邀请用户到某一集中地点开会）

明确目的：比如产品卖点确认，需求收集，用户体验改进。这样在争取开用户大会的资源时有说服力

资源确定：时间、地点、人物、材料、备用方案

现场执行：辅助工作、主流程

结束以后：资料整理、运营宣传

2.2.2定量地说：调查问卷

调查问卷可以挖掘出用户中大多数的沉默与骑墙一派，并且他们还是典型用户。 调查问卷与用户访谈的区别：前者是封闭式问题，后者是开放式问题

Tips:作答时间不超过10分钟；问题顺序：简单问题 -> 需要思考的、敏感的问题 -> 被访者个人信息

调查问卷的常见问题：

1.样本偏差

对策：尽可能覆盖目标群体中的各种类型的用户，比如性别、年龄、行业、收入，并保证这个比例接近全体比例；若无法做到样本合理性，在调查报告中要注明潜在的筛选条件。

2.样本过少

对策：若样本个数少于100，列出人数，而不是百分比

3.问卷内容的细节问题

对策：问题表述应无引导性，问“你是否喜欢某个产品”而不是“你喜欢某个产品吗”；准备几种形式的问卷，减少答案的顺序偏差；先小规模试答，反馈修改后再大面积投放。

例子：记这本书的实际问卷

问卷目的：收集读者反馈

样本对象：本书读者、博客读者、对产品经理感兴趣的人

调查渠道：网站、博客

时间计划：收集3个月

问卷内容：简单问题 -> 需要思考的、敏感的问题 -> 被访者个人信息

2.2.3定性地做：可用性测试

步骤：招募测试用户（尽可能代表真实用户，若主要用户是新手，则应选择对产品不熟悉的用户） -> 准备测试任务（典型任务） -> 测试过程，组织者应观察并记录 -> 询问用户的主观看法 -> 研究分析

可用性测试的常见问题：

1.做得太晚，发现问题也于事无补了。

对策：在产品的各个阶段都做可用性测试。对于无任何成型的产品，拿竞争对手的产品给用户做；对于只有纸面原型的产品，拿手绘的产品给用户做。

2.觉得可用性测试太麻烦，干脆不做

对策：只做一个用户，并简化步骤，也比不做好

3.明确是测试产品，而不是测试用户

对策：不要用“可用性测试”的术语，而是说“来试用我们的新产品，提点意见”，减轻用户压力

4.测试过程中，组织者该做和不该做的

该做的：告诉用户持续时间，做哪些事情；让用户在使用产品时说出自己的思考过程；送个小礼品

不该做的：引导与暗示

例子：产品改版的一次冒险

可用性测试做得太晚，想想后怕

Tips：对于改版，要和平演变，而不是暴力革命，要让用户逐渐适应：从部分分级页面改起；新旧版本并存；小面积实验；傍上用户已经习惯的风格

2.2.4定量地做：数据分析

关键的是对数据的解读，数据分析只能发现现象，并不能了解原因。所以数据分析常伴随用户访谈。

数据分析的常见问题：

1.过于学术，沉迷于“科学研究”

对策：重视综合性价比，不需要“显著性检验”，要的是对数据的敏感。

2.虽然数据不会主动骗人，但我们经常无意或有意地误读数据

对策：对于无意误读（例如不能用平均值来衡量收入水平），学习统计学只是；对于主动误读（在提取数据前就有结论了），保持中立态度

3.平时不烧香，临时抱佛脚

对策：在产品设计时就把数据分析的需求加进去，比如统计每个按钮的点击次数。

日志分析的商业价值

例子：分析登陆次数

在对产品熟悉的基础上，做方向性假设。这里假设有方法使某类用户更多地登录

->提取相应数据并分析,得到一些现象，最好是之前没发现的现象。这里做一张二维图，横轴时间，纵轴活跃情况。趋势可分为四个阶段。

->尝试解释。这里发现可分为两类登录：经销商登录和用户登录

->用户调研修正解释。这里是电话调研+登门拜访，发现有两个入口的登录。

->指导产品的发展方向。这里的商业价值在于：1）考核每个经销商下面的用户活跃度，来让他们更好地服务用户；2）有实际意义的是用户入口的登录，因此产品优化的重点应在用户入口

2.2.5需求采集人人有责

从用户那里直接得到的需求，是一手需求；老板或销售人员的需求，是二手需求。

在新产品诞生前，没有用户、运营、销售时，要主动地去潜在的目标用户那里采集需求；产品运行一段时间后，用户和相关工作人员都有了，与用户的直接接触变少，但会收到中间的工作人员反馈的需求和用户提的需求。

销售人员有时只重视眼前利益，提的需求不一定好，一手需求很重要。

二手需求的理解偏差可以用单项需求卡片这个工具来弥补。

需求分析卡片的理念是：产品的需求工作不只是需求分析人员的事，而是涉及产品的每个干系人的义务，至少得参与“采集”的过程。

一个需求分析卡片，至少得有需求编号、需求描述、来源（产生需求的用户）、场景（产生该需求的特定时间、地理、环境）

尽可能多地采集需求的一些方法：现场调查，和客户一起工作；AB测试，小规模地测试A和B的情况；日记研究；卡片分类法，把需求写在便利贴上，观察用户怎么给产品划分模块；粉丝用户主动提需求

2.3听用户的但不要照着做

对于用户提的解决方案仅仅站在自己立场上考虑，对于用户提的存在明显逻辑矛盾的需求，要谨慎考虑。

2.3.1明确我们存在的价值

需求分析要做的是把用户需求转化为产品需求。

例子A：用户向福特要一匹快马，福特给了一辆车

例子B：对于“小明要电钻 -> 要在墙上打洞 -> 要挂上画 -> 屋子太空旷，不温馨 => 安全需求和社交需求”，我们可以给电钻+油画，也可以油画+强力胶，或者摆个书架，可能更省钱也更温馨。

用户需求 VS 产品需求

用户需求：用户自以为的需求，并且经常表达为用户的解决方案

产品需求：经过我们分析，找到的真实需求，并且表达为产品的解决方案。

需求分析：从用户提出的需求出发，找到用户内心真正的渴望，再转化为产品需求的过程。 需求分析是“首先：树叶-树枝-树干，其次：树干-树枝-树叶”的分析过程，既不能漏掉提炼用户需求的过程，透过需求看本质，也要让树干分解掉，好让执行人员知道要做什么东西。 这是短期利益与长期利益的权衡，只满足用户需求是短期利益，但为了长期需求，我们要找到用户的真实需求。

满足需求的三种方式

改变现状：开发某个产品，最常用也最笨的方法。

降低理想：“丑话说在前头”

转移需求：寻找更强烈的需求展现给用户，让他不纠结于原来的需求。

例子：电梯不够用

改变现状：增加电梯个数

降低理想：告诉用户，隔壁那个楼等的时间更长

转移需求：鼓励用户爬楼梯锻炼身体；电梯门口装镜子让等的人搔首弄姿不至于无聊

也谈创造需求

基于用户、产品、市场的充分理解的突发奇想有的会得到用户认可，但更多的是天马行空。 作为新人，先做用户提出的需求，而不要胡乱分析用户需求。

2.3.2给需求做一次DNA检测

需求DNA检测过程：需求转化 -> 确定基本属性 -> 分析商业价值 -> 初评实现难度 -> 计算性价比

需求转化

采集单项需求卡片 -> 头脑风暴 -> 每人分一块，转化为产品需求 -> 整理记录成产品需求列表

用户需求与产品需求是多对多的关系

过滤掉不靠谱的用户需求

例子：对于用户需求“删除之前需要确认”，产品需求可能是“数据回收站：删除的数据进入回收站。若误删，可以去回收站找回数据。”

确定需求的基本属性

这些基本属性包括：编号、提交人（针对产品需求）、提交时间、模块（5+-2）、名称（什么功能）、描述（功能具体什么意思）、提出者（针对用户需求）、提出时间、Bug编号

需求种类知多少

需求按分类分，可分为：新增功能、功能改进、体验提升、Bug修复、内部需求（比如内部数据分析）

产品功能需求+产品非功能需求=产品需求

产品需求+市场需求+开发需求+测试需求+服务需求+...=产品包需求

需求按层次分，可分为：基础、扩展（期望需求）、增值（兴奋需求）

雪中送炭要好于锦上添花

分析需求的商业价值

商业价值可用重要性、紧急性、持续时间来衡量。

这是需求列表中的最核心部分，甚至在列表中再增加一条“商业价值描述”，即卖点，说明对用户和公司会提供什么价值

对于商业价值，要在需求讨论会产品团队集体讨论，叫上干系人，比如销售、服务等

初评需求的实现难度

把技术人员代表拉进来参加讨论会，甚至让他们先自行讨论后再决定。

不考虑硬件成本，再加上在产品、开发、测试、服务中开发资源是瓶颈，开发量成为实现难度的指标。

由于需求未定，先做允许误差大的初评，在项目启动后再做更精确的评估。

性价比

性价比=商业价值/实现难度

在实际中，多跟工程师接触，实现难度会定得偏高，多跟销售运营的人开会，商业价值会定得偏高。

例子：对于Firefox的网页显示问题，虽然很好解决，但是用的人极少，所以商业价值极低，导致这个需求性价比低。

2.4活下来的永远是少数

需求筛选的过程：需求打包 -> BRD制作 -> 产品会议 -> .. -> 立项

2.4.1永远忘不掉的那场战争

以前没有战争的原因：以前公司按产品线划分部门，对于某产品，有自己的产品设计师、开发与测试人员。

现在有战争的原因：现在公司按职能划分团队，每个产品由原来的产品人员做，但是开发与测试人员是流动的，各个产品团队要竞争人力资源。

准备出发：给需求打个包

做项目的终极目标是：多快好省，即范围大、时间短、品质高、资源省。需要在这4个因素中做平衡。

在产品需求列表上，按性价比大小，对每一行需求的工作量相加，看能做多少，这就是需求打包。

需要注意的几点：

1.需求打包最好打包类似的功能点

2.需求依赖，功能互相之间有依赖关系；功能与人力资源之间有依赖关系，比如某功能只能由特定的人做

3.需求的粒度大小问题。细化粒度，发现需求中价值相对低的部分，对于需求列表里的每一行，工作量最好不超过5人天

战场：产品会议

参会人员：各个部门的老板、各个产品的产品经理和设计师

时间：一个月一次甚至更长

过程：回顾上一次产品会议通过的项目进展如何 -> 用商业需求文档争取资源

武器：商业需求文档

BRD：Business Requirement Document，商业需求文档

MRD： Marketing Requirement Document,，市场需求文档

PRD：Product Requirement Document，产品需求文档

BRD包括的内容：项目背景、商业价值（最关键）、功能需求描述（最好能画出业务逻辑关系、多加些让老板砍的需求）、非功能需求描述、资源评估（第二关键）、风险和对策

2.4.2别灰心，少做就是多做

例子：“自动上架”需求的确定，一开始只是雏形，但越讨论加的功能越多，接着因为资源限制的原因，加的功能一个个砍掉，最后发现和最初方案是一样的。这是一个“见山是山，见山不是山，见山还是山”的过程。

情愿吧一半的功能做到尽可能完美，也不要把全部功能都做成半吊子。

最爽就是“四两拨千斤”

例子：肥皂生产时有漏包问题，请了一堆专家解决，最后拿着电扇对着生产线末端吹，把控肥皂盒吹掉。

技术上的大改动往往是商业上的小改动。

尽可能多地放弃

例如：对于“评论”功能，若不放弃一些需求，要被自己折腾死。这些需求比如：“考虑评论翻页”、“考虑评论带图片”、“考虑被人引用后可否修改”。

有资源空出来，去做意义更大的功能或产品。

2.5心急吃不了热豆腐

一个需求的生老病死

1.需求采集，转2

2.待讨论，转3

3.需求讨论会，若暂缓，转6，若通过，则进入需求打包，转4，否则拒绝

4.需求打包通过的，转产品会议5，若不通过，转暂缓6

5.产品会议通过的，转开发，若不通过，转暂缓6

6.暂缓状态，满足重启条件后，转2

需求管理的附加值

统计每个“提交人”的需求数量=>某个人的工作情况

统计“提交时间”、“发布时间”=>产品发展是增速还是减速

统计每个模块的需求数量=>用户对哪些模块感兴趣

统计每个分类的需求数量=>产品是在成长期还是成熟期

统计需求的商业价值、性价比变化=>看产品的发展空间有多大

有一些专业的需求管理方法和工具，比如Rational RequisitePro

和需求一起奋斗

产品经理的重要素质之一---热爱产品

3.项目的坎坷一生

3.1从产品到项目

做产品 VS 做项目

1.做产品时间周期长，从规划到制造到维护，没法确定合适结束；做项目时间周期短，有明确的起始和结束时间。

2.做产品要不断修正判断，给出创新；做项目目标明确，像执行任务

3.产品面向大量的通用用户；项目相对个性化

例子A：找裁缝给自己做件衣服，是做项目，裁缝的设计被服装厂拿去生产，是做产品 例子B：某网站在国庆前要做一个专题，是做项目；新闻频道持续更新，是做产品 做产品的过程，是通过一个又一个项目实现的

产品经理VS项目经理

产品经理靠想，做正确的事，看其所领导的产品是否符合市场需要，是否能给公司带来利润，内部驱动，最重要的是判断力与创造力。

项目经理靠做，把事情做正确，在时间、成本和资源约束的条件下完成目标，外部驱动，最重要的是执行力与控制力。

为什么让产品经理管项目

让项目经理管项目，他们会倾向于简化项目，尽量少做，但做出来的东西商业价值不足，用户体验不好。

让产品经理管项目，关于导致不断加需求导致项目无法按期完成，影响团队士气。 要有个平衡。

3.2一切从kick off开始

立项过程：需求筛选 -> 立项（团队组建 -> 计划确定 -> kick off）

帅哥美女，我们需要你

产品经理没有行政上的管理权，要向不同团队的主管要人

PD新人不适合做项目经理，因为和团队没混熟，沟通会不顺畅

项目督导委员会由项目成员的老板组成，他们负责承担责任，以及提供资源。下面是项目经理。项目经理下面是PD、开发经理、测试经理、UE（用户体验团队）、服务团队

别忘了最初的约定

立项阶段的项目计划，要再次评估工作量并推算出工期，除了更准确，还要考虑谁来做。 估算的工作量=（最乐观+最悲观+4*最可能）/6

按每人工作5-6小时算，留出余量时间，还要考虑任务间的依赖关系，尽量不加班。

沟通从头开始

常用沟通方法：项目晨会、项目日报、评审会、项目变更申请、发布预告及公告

不可或缺的誓师大会

15分钟的kiff off传达的内容包括：

BRD里的项目背景；项目意义目的目标；需求、功能点概述；

项目组织架构（让项目成员互相认识、关键人物要到场来确认方向正确）；

项目计划（项目的时间点与里程碑、每个人在各个阶段做什么事情）；

约定沟通计划

任何时候都要心里有“树”

做项目的本质是在保证品质的前提下，在时间要求、人财物花费、项目范围三点上做平衡 WBS：Working Breakdown Structure，工作分解结构

可套用WBS模板来方便项目管理。WBS模板像一棵树，比如

--产品模块级项目

----项目准备

----过程管理

------立项

------时间计划

------项目总结

--------心得体会

--------数据分析报告

----需求

----实施

----测试

----服务

3.3关键的青春期，又见需求

新人可以先做一些执行层面的任务来熟悉产品和团队。可以写文档来练手。

3.3.1真的要写很多文档

BRD、MRD是写给老板看的

PRD、FSD（功能详细说明，相当于概要分析），是写给技术人员看的

产品需求文档,PRD

PRD的模板目录：

1）总体说明

1.1）修订历史

1.2）项目概述，参考kick off

1.3）功能范围，给出业务逻辑图，角色职责、与周边系统的关系，全局商业规则

1.4）用户范围

1.5）词汇表

1.6）非功能需求，如性能需求、数据监控的需求

1.7）其他说明

2）UC部分（用例文档）

包括视觉层面的描述（通过demo表达）,界面细节（如文字对齐），交互细节（出错提示），文案细节（提示文案）

学一点UML：类图、用例图、状态图

略

用例文档：UC

略

再学点UML：时序图、活动图及其他

略

Demo也要我们做么

Demo最好由UE部门的人做，也就是美工。

Demo会经历从抽象到具体的过程：纸面demo -> 线框图(用word,PPT,visio) -> 视觉效果图（PS，dreamwaver）

概要设计与详细设计

1.不以写的东西是需求还是设计区分，而以业务或技术区分。例如，某编辑框长度由PD确定，但如何在数据库中存储由工程师决定

2.细枝末节的设计要沉淀出产品规范。

3.3.2需求活在项目中

评审，一个头两个大

评审的目的在于防止问题随时间放大

三次评审：需求评审（UC评审+demo评审）、设计评审、测试评审

需求评审会中两类人要在场：能做决定的人；此项目相关的产品接口人

再看需求的生老病死

几个重要的会议：

项目开始前的需求讨论会，PD带着自己的需求为有限的开发测试资源PK，若通过状态变为“需求中”

项目中需求阶段的需求评审会，PD收集意见反复修改需求，若通过状态变为“开发中” 项目中需求阶段以后的和开发、测试人员确认细节 -> 开发提交测试以后的功能评审会，让项目干系人确认功能

3.4成长，一步一个脚印

需求冻结后修改需求要更慎重

开发阶段，旁观者说

设计 -> 设计评审 -> 编码 -> 单元测试

测试阶段，大家一起上

TC编写 -> TC评测 -> 冒烟测试（类比于电路板基本功能检查） -> 功能评审 -> 测试（回归测试、性能测试）

商业准备工作同步进行：PD写卖点文档、产品更新公告；运营的做策划推广方案；服务的做产品帮助

Bug眼中的项目

Bug描述的几个关键点：缺陷级别，所属产品、项目，Bug名称，Bug描述

Bug的几种状态：open（发现bug），rejected（否认bug），updated（l开发确认后修复中），fixed(修复后更新到测试环境)，closed（测试验证通过），reopened（验证不通过），deferred(暂不修正)

使用Quality Center管理，所有操作都有记录

那一夜，项目发布

发布评审 -> 预发布 -> 发布 -> 线上验证

使用SVN管理代码版本

对于用户影响大的升级，采用“分流发布”或“灰度发布”，即让一部分用户先用，再决定更大发布的时机

正式发布前要填写“发布申请单”，让关键人物签字

发布时间一般选择在晚上

以终为始，项目小结

发布后在公司邮件组里发“项目发布公告”，做好内部宣传 + 物质奖励或聚餐 -> 发布后半个月内写项目小结

项目小结内容：遇到何问题，如何解决和避免；商业目标是否达到；资源评估是否合理 通过写项目的日报或周报，项目小结就水到渠成

怕什么来什么，只能拥抱变化

对变更事件，制定流程做控制，对于过大过晚的变化，项目经理有权决定是拒绝，还是上报大老板定夺

对搭车事件，找内容相关的项目，尽早而不要在需求冻结后再提

对紧急事件，由高层老板确认后自上而下推动

对于多个项目并行时的资源不足，遵循“慢车让快车”的原则

3.5山寨级项目管理

3.5.1文档只是手段

建立自己的文档规范

把文档除去公司的烙印，融入自己的理解，以后不管在哪工作，只要做的还是产品，这份文档规范就是一笔财富

模板作用知多少

模板本质作用：让经常看同类文档的人提高效率；让写文档的新手可以尽快上手；让写作者不会漏考虑某些内容

对于成熟的团队和产品，在项目开始前就约定好各种模板、规范与流程。这些模板、规范与流程最好在产品1.0版发布，进入1.1版的升级阶段，但还未研发2.0的时候迭代生成。 偶尔为之的事情不必形成模板。

多人协作与版本管理

产生文档版本管理的本质需求是多人合作，协同办公

windows系统的共享文档(互斥修改) -> google docs（不顺手） -> wiki (随时更新整个产品的PRD)

玩转office足矣

3.5.2流程也是手段

项目 VS 流程

项目只做一次，追求可行解；流程要反复做，追求最优解

流程的本质目的

随着产品越来越大，个人英雄主义就变得无用。这些英雄把个人经验转变成显性知识表达出来，而对于经常做的事情，就可以用流程这种形式固化、继承，后人在做这些事时起码不会显得太无助。在这点上，规范、模板的作用也类似。这就是团队的核心竞争力。

那么多评审，可以省么

产品会议：必须有，决定“做不做，做多少”很重要

kick off会议：最好开，鼓舞士气

需求评审：分别是PRD，UC,demo评审，根据实际情况合并部分评审

设计评审：开发实力强可以忽略

TC评审：省的话，验收测试要更细致

功能评审：必须有

发布评审：不一定

商业评审与技术评审

商业评审决定“做不做”，是产品会议和功能评审

技术评审决定“怎么做”，是需求、设计、TC、发布评审

技术评审要避免抓闲人、科普会、批斗会的情况

3.5.3敏捷更是手段

从书本到实践

瀑布模型（假定人是可以任意取代，需求在项目开始时就确定） -> 敏捷方法

敏捷方法的特点：有计划，更要拥抱变化；迭代周期内尽量不要加任务，可以移除一部分任务到下一次迭代；集中工作，小步快跑；持续细化需求，强调测试（需求在开始时无法细化）；不断发布，尽早交付，把大问题分而治之

项目中的敏捷沟通

即时通信IM群、每日站立晨会（小于20分钟，每人3个问题：昨天做什么？今天做什么？遇到啥问题，如何解决，是否要帮助？）、项目看板

与外包团队的敏捷尝试

例子：作者是甲方代表，负责项目实施的乙方是家大外企。甲方想用敏捷方法，乙方想用传统瀑布模式，因此冲突不断。表现在：项目外包使甲方不愿意砍需求；敏捷导致提交测试的产品与最初需求间有变化，这在公司内部运行得很好，但由于甲乙方没有一起办公，配合困难；乙方缺乏敏捷的经验和意识，在没有详细设计文档的情况下技术人员按自己想法开发测试，没有与需求人员沟通

3.6物竞天择适者生存

3.6.1亲历过的特色项目

如何做好老板项目

时间是给死的

质量是可变的，把质量搞大，派出各种功能的建议优先级和所耗资源，让老板砍功能 资源时丰富的，尽量多要

秘密行动，封闭开发

临时的团队在一个会议室办公，交流方便，但是环境差，让人疲惫，时间上限最好是两三个月

开发外包？项目外包？

略

3.6.2一路坎坷，你我同行

边计划，边行动，边修改不可怕，这在敏捷开发常见，关键是目标和原则不可变。 拍脑门，拍肩膀，拍胸脯，拍桌子，拍屁股，拍大腿也不可怕，怕的是不吸取教训。

几个项目的成败

例子：做了5个项目，大部分是失败的，这很正常。

第一个项目没有过压力测试。

第二个项目转移给别的团队，没有高层支持，在需求阶段叫停。

第三个项目在市场调研阶段叫停，因为收集的信息让我们觉得不值得做。

第四个项目成功，发布后不断升级、运营。

第五个项目和其他公司合作，开始规划宏伟，但最后延期半年。

一次只有七天的战斗

略

4.我的产品，我的团队

4.1大产品，大设计，大团队

4.1.1产品之大

时间之大：产品生命周期

不同阶段的5种用户：创新者（极少，尝鲜使用） -> 早期追随者(较少，需求目的性强，专家用户) -> 鸿沟 -> 早期主流用户（较多，中间用户和新手，想尝试新产品） -> 晚期主流用户(很多，中间用户和新手，抵触新产品，此时营销手段很重要) -> 落伍者（较少） 不管哪个阶段，先明确主打哪种类型的用户，再决定做什么产品满足相应的需求

空间之大：商业、产品、技术

大产品的铁三角：商业（产品定位、定价与促销、渠道政策）、产品（功能完成度、交互流程、视觉传达）、技术（产品稳定性、基本功能、bug数量）

任何一个公司必有它的强项与弱项，它不可能也没必要再这三方面都很强，一是因为构建“性价比团队”的考虑，二是因为都强的话互相压不住反而造成内耗，所以更重要的是找到自己公司的那个突出刀尖，即公司的DNA

例子：Google是技术主导，Apple是产品主导，阿里巴巴是商业主导，现在加大对技术的投入

4.1.2设计之大

新人会考虑不全面，分不清啥是精华，啥是糟粕，建议学习产品的人先看几本入门的书，学习华为的任正非引进管理体系时的策略“先僵化、后优化、再固化”

产品设计的五个层次

从抽象到具体，从概念到完成

战略层：商业目标和用户需求

范围层：明确“做多少”，功能规格说明和内容需求

结构层：交互设计，信息架构，这里的产出物包括软件的业务逻辑图、网站的站点地图 框架层：界面设计、导航设计、信息设计，确定页面长什么样子

表现层：视觉设计，比如页面配色、字体字号

我用五个层次来写书

第一轮搭建框架，精细到第四级目录，介绍每一级的主要内容

第二轮填充文字，把积累的文字做剪切

第三轮理顺逻辑

第四轮调整风格，增加图表和照片。使书更生动活泼

第五轮后期制作，编辑同学和前辈帮忙评审

对应互联网产品设计的五个层次：战略、范围、结构、框架、表现

设计的“现实与浪漫”

设计的三个层次：

第一层次：本能水平。产品要有用，满足用户的某种需求

第二层次：行为水平。产品要能用好用，顺利解决用户的问题，在反馈（比如鼠标样式的改变）、容错（比如不可逆的操作可以后悔）和简化（利用用户已有知识和标准化，比如复制都是ctrl+c）上做好。

第三层次：反思水平纯心理需求，比如像花一样的台灯、iphone

4.1.3团队之大

想当年，一个比一个猛

略

从几个人到一家公司

创业小公司，一人做好几件事

成熟公司，有了分工，人员可分为商业、产品、技术、支撑四大块。

接口人存在的价值

问题过滤，合并相似问题，会由相关部门中比较资深的同学来担任

最好接口人跟公司里多数人已混熟，减少部门合作时的陌生人之间的沟通成本

我身边的矩阵型组织

职能型组织：把相同职责的人划分在一个部门里，有利同类资源贡献，但部门只对“上面”负责，不对客户负责。

项目型组织：把各种职责的人组成一个个项目组，有利快速推进项目，但是会资源浪费。 矩阵型组织是上述两种组织的融合。

最好不由一个人兼任矩阵型组织的“双头领导”，而是让管事的产品经理提供建议，官人的部门经理决定对员工的考核。

4.2游走于商业与技术之间

4.2.1心思缜密的规划师

PD（Product Designer）是产品经理及其带领的产品规划师、产品设计师和需求分析师（RA，Requirement Analyzer）。产品经理和产品规划师，更偏向产品前期的规划，比如产品的市场定位、各个版本发布的时间计划，商业目标、用户需求是思考的重点。产品设计师侧重于功能级的设计，在某个模块上很像一个小产品经理。即PD偏市场、用户，RA偏实现、技术。

从概念设计到信息架构

产品概念图是概念设计的产物，产生于需求采集之后、需求筛选之前。我们要通过概念图来理清思路，找到应该“做什么”，并将其整合为一个系统。

画出产品概念图的方法：1）在思维导图上改，比如对需求做简单分类，写些注释；2）大家在白板上讨论改进

概念图要重点突出两点：1）产品与外界的关系；2）产品内部的关系：不涉及数据流，重点描述不同角色在系统里的身份

概念设计是为了团队沟通，完成后，开始信息架构，信息架构是为了设计更合理的方式，把信息传递给用户。

PD的出身及其优劣势

PD的出身各种各样，你之前做的事情是你擅长的，是你的优势，也是你的劣势。

例子：开发工程师转产品经理，可以在初期就判断那些事情不靠谱，但是会让技术压倒商业，在业务逻辑没确定时就考虑过细的实现难度问题。

4.2.2激情四射的设计师

规划师让产品有用，满足用户的某些需求；设计师让产品好用，用户用起来舒服。

用户体验部门的职责可细分为：用户研究员、交互设计师（做导航设计、信息设计等）、视觉设计师（俗称美工）、前端工程师

产品新首页诞生记

->e网打进的产品Portal改版：加重营销内容，将访客转化为付费用户。

->确定Portal需要哪些页面和导航菜单的结构（比如首页、产品介绍、用户社区、客服中心等）

->确定每个页面的元素（以首页为例，有大Banner广告位，用户登录入口、卖点宣传、媒体报道等）

->PD手绘纸面demo

->UE制作线框图demo

->UE制作视觉效果图，PD安排销售、服务等做demo评审

->上线后的持续监控和改进

当交互设计遇到敏捷开发

交互设计适用于传统领域、成熟公司；敏捷开发适用于新兴行业、创业公司

信息展现设计的例子

例子：显示若干城市12个月的降雨量

表格 -> 按雨量标记不同颜色的表格 -> 用雨滴大小表示数据 -> 在地图上标上城市，用户可滑动时间轴看到雨量变化

聊聊细节，文案设计

文案问题分为三个级别：错别字、病句、错误标点；用词不统一、不准确；语言风格不统一、产品气质不统一

产品的文案越少越好，用户都是凭着自己的感觉使用产品

4.2.3“阴险狡诈”的运营师

运营师：不是直接向用户介绍功能，而是有个“把功能转化为卖点”的过程。

产品与运营的战与和

运营只能把人带来，而把人留住要靠产品

运营有时为了更直接的商业目标，比如PV(Page View)，做了短视的事情，一段时间后PV就下降，PV背后的目的----增加网站用户数没有达到。

个人博客运营实例

KPI定为体现高用户数的“RSS订阅数”

推广方法：发出以《产品经理值得...》系列的重量级博文；UCDChina、CSDN专家博客、QQ群转载；把文章转给有想转化的人；与优质博客互相推荐；QQ群邮件

一次无意识的“事件+病毒营销”

作者一搏文：用脸盆给开复一行人倒咖啡。该博文访问爆发的原因是开复写了个微博作回应。 该事件有娱乐性且无恶意；这大大宣传了开复老师、创新工场和作者博客；微博很强大

4.3商业团队，冲锋陷阵

销售增加新客户，服务稳住老客户。当有项目的评审会时，要叫上他们，避免最后的产品演示会上出问题。

4.3.1好产品还需市场化

定价与促销

网店版的SaaS模式(Software as a Service，软件及服务)决定了我们采用租用模式。 考虑到用户理解困难，采用付费进阶版+免费普及版的定价方式

促销：免费试用 -> 买一送一 -> 过年过节送红包 -> 与其他付费产品打包销售 => 主要目标是“付费用户数”而不是“收入”

销售与渠道

渠道分为“推”和“拉”。推是集中力量做渠道工作，用高额利润刺激渠道主动推销产品；而拉是通过PR（Public Relationship公关）、广告、传播等手段启动市场，刺激消费者，促使渠道来找厂商。新产品靠推，老产品靠拉。e网打进靠的是推。

产品设计要考虑到渠道：

1）改动功能时要考虑到渠道人员的培训成本

2）通过渠道来销售而非直销，那么要考虑到终端用户的互联网使用能力不足

3）终端用户是企业，要考虑到#5@p问题

4）多级定价，开#5@p的流程，渠道政策等要与相应系统支撑

另一种产品版本细分策略

产品版本细分有两类：

一是做功能区分，打细分市场，比如笔记本的高中低端产品

二是为了促进销售，利用消费者心理，纯策略性地做出“炮灰版”。常用手法有：1）做一个功能不会强大多少但贵很多的“高价炮灰”，让消费者觉得商家真正想卖的那个版本很便宜。这么做的目的是抢市场。2）删掉核心功能做一个价格低一点的“低价炮灰”，消费者会觉得买和卖那个便宜版本的都是脑残。这种消费者心理就是不对功能、价格做理性分析，而在乎的是“相对实惠”。

需要注意的是“炮灰版本”的成本要足够低。

开阔视野的水平营销

垂直营销是渐进的，水平营销是革命的。

例子：卖包子。

垂直营销：包子做成大、中、小，再做32种不同的馅。

水平营销：

目标维度：本来目标是中国人。替换：搞些灯笼、竹叶做背景，卖给外国人。

时间维度：一般早上吃包子。替换：做夜宵包子，里面放中药，吃了睡的香。

需求维度：原本是要填饱肚子。替换：美容包子可以养颜，精品包子拿来送礼。

4.3.2我们还能做什么

老板，要光盘么

花两千块就买了账号和密码？=> 做企业级产品不能像个人网络应用这么玩，要结合传统。 例子：对“e网打进”，老板提出“提高用户的活跃度”

治标的运营活动：发现很多用户从未使用过产品，对KPI提出自己观点：在活跃用户和付费用户之间，应该增加使用用户的概念。

治本的用户研究：分析问题原因

1）渠道商失责，用户没用过产品 => 营销辅助计划，大力推广品牌；对经销商人员进行服务和销售的培训

2）产品太虚，记不住账号、地址 => 发起“鸡毛信”项目，产品实体化

3）产品没人用 => 发起“天使计划”，找人帮用户使用软件

4）网站流量低，产品难以发挥作用 => 产品转型

明确目的：解决“记不住账号”的问题

用PPT说服老板，申请预算和资源做“光盘内容、盘面、光盘包装”

联系包装供应商

具体设计：在光盘里设计了个很土的“安装软件”，其实是在用户桌面加一个登录页面的快捷方式，事实证明很有用。

Tips：当该产品困难时，可以考虑换市场。

算出来的服务策略

略

4.4技术团队，坚强后盾

外行眼中的技术分工：

软件架构师，开发经理，开发工程师，数据库管理员

测试工程师，质量保证人员

配置管理员，系统管理员

有这样两种工程师

技术痴迷者，但有时钻研技术而搞出用户不需要的功能，需要PD和他们充分沟通。

实用主义者，做简单的事，稳字当头，是人见人爱的“老狐狸”，但有一部分人是不思进取。

如何与工程师合作

1.重流程。用规则管理，而不是用人管理。

2.沟通。避免情绪化，不要把对人的反感转移到对此人观点的反感上。

3.PD要提高自我修养，懂一点技术。

4.5容易被遗忘的角落

最好的资源：老板

老板是资源的提供者，也是背黑锅的人。如果顶不住的时候，向老板喊救命。

把老板当促使自己成长的资源：开始遇到问题，问老板怎么做（问答题） -> 自己搜集资料，选出几种解决方案，让老板选（选择题） -> 加上自己的选择，和老板探讨（判断题）

默默奉献着的团队

法务、财政、行政

4.6大家好才是真的好

公司最大的财富是人。即使产品没有了，如果人在，也能重新杀出一条血路。

4.6.1所谓团队文化

团队文化的三五事

午餐时的赌局，输的人收拾残局；某人的“休假知会”邮件；马云的白雪公主造型

4.6.2虚无的无授权领导

管理 VS 领导

略

产品经理应该是管理者么

产品经理是管理者的优势是：利于拥有话语权，利于获取信息，利于争取资源。劣势是：有很多行政工作，会让人脱离群众。

好的公司会设计出管理、专业两条晋升线路，专业这条线路就可以扬长避短。

如何让团队更开心

奖励或送礼的目的不是真正给对方最大的效用，而是让对方开心，并且感激和记住你。 例子：在不太贵的礼物类别中选一个贵的礼物，比与之相反的好；最要是吃不掉、送不掉的礼物，比如刻着对方名字的水晶奖杯；送想买不舍得买的礼物，比如1000元高级餐券；涨工资不如发奖金

跟着我，有肉吃

略

5.别让灵魂跟不上脚步

5.1触及产品的灵魂

不要脱离产品战略来讨论设计的优劣

例子：对于希望用户点击的按钮，要设计得大一些；对于危险性高的仪器，要反复确认，“难以上手”。

以价值观为根基

例子：对于公司里用上不了台面的手段为公司创造利润的销售员，是去是留，由价值观决定。

战略是怎么炼成的

价值观 -> 战略 -> 流程规范、组织结构、激励机制等

培养大局观

当觉得战略有问题时，多和老板讨论。可能因为我们考虑问题比老板简单，所以做出不同的判断。这样与高手的讨论会培养自己的大局观。

例子：非目标用户占了实际用户的大半，可以暂不讨论原先的目标用户定位是否有问题，可以想这些非目标用户也许就是一个新的市场机会。

5.2可行性分析三步曲

5.2.1我们在哪儿

从市场扫描开始

PEST分析，分别是

政治法律环境（political factors）：诸如国际关系、方针政策、政治局势等。例如在荷兰合法的性工作者在中国就不合法。

经济人口环境(economic factors)：诸如宏观经济政策、经济基础结构、消费结构、收入水平等。例如奢侈品行业不要考虑农村地区。

社会文化环境(social factors)：诸如风俗习惯、审美观念、宗教信仰、教育水平等。例如在回民居住区卖猪肉铺子肯定卖不出去。

技术环境（technological factors）：诸如自然地理因素、科学技术发展。例如几分钟内从上海到北京不现实。

真实的竞争对手分析

常用方法：上网搜，试用，假装用户去和对手的客服、销售套词；看行业分析报告，但是要注意作者与机构的背景；请咨询公司做调研；公司里的老人“拍脑袋”。

深刻的自我分析

常用方法：SWOT分析

例子：对应届生求职，优势是：有激情，不在乎薪水；劣势是：没经验，短期内做不出贡献；机会是：重视人才储备的公司越来越多；威胁是：大多数时，公司更喜欢能直接上岗的员工

5.2.2我们去哪儿

宏观上的用户需求

任何行业可以根据收入水平、地域、员工人数、所属行业划分为很多小市场。如果想一口全吞下，注定被噎死。

例子：产品的目标用户是中小企业，要满足他们对电子商务的软件需求，。每个层次的企业，就是不同的市场，对应不同的产品。

第一层：仅仅听说过“电子商务”，只是赶潮流建个网站，但网站常年不更新。

第二层：了解到电子商务的意义，会去找经销商在百度或阿里巴巴留下信息。

第三层：出现“开源”主导的管理需求，出现在线客服，SEO服务（搜索引擎优化），和推广配套的统计分析工具。这时的关键点是把“访客变客户”，“流量变销量”。

第四层：“节流”主导的管理需求，用CRM（客户关系管理软件）、进销存软件代替小本子、excel，也出现了OA(办公自动化软件)、SCM（供应链管理软件）、HRM（人力资源管理软件） 第五层：整合应用阶段，处处都是电子商务，即ERP（企业资源计划），此时公司不是中小企业了。

阿里的每个产品，是满足特定层次上的需求，比如企业建站服务满足第一层，客户关系管理系统满足第四层。

可以用战略管理和市场细分工具来获取宏观需求，比如BCG矩阵、波特五力模型、战略地图等。

物流平台的案例

略

5.2.3我们怎么去

这一步的关键是“策略”：定价策略、推广策略、渠道策略、服务策略、财务策略、技术策略。。正确的策略保证我们是在“做正确的事”。

一次真实的产品调研

目标：让当前产品与另一子公司B的现有产品整合以发挥最大作用。

当时的山寨做法：以用户的身份对B公司产品的网站访问了下，确定三个相关性大的产品 -> 向这些产品的产品经理要了如下文档：产品介绍文档、Personas文档、产品的试用账号密码、产品最初的运用数据 -> 对疑惑的地方，记下来，和对方产品经理聊聊 -> 考虑整合的每一种方案的利弊，用到了SWOT分析 -> 最后觉得怎么做都问题多多，只好“多害相权取其轻”，选定一个方向，给出几个备选方案向老板汇报

5.3做吧，准备出发

5.3.1敢问路在何方

产品路标规划

路标规划是产品的长期规划，上面最小的单位是产品的一个版本或一个重大活动，细化后通过若干个项目实现。典型的规划周期是产品大版本周期的3-5倍。

过一段时间要对路标规划做回顾，并修正。

例子：作者的“三个一工程”，三个里程碑错开时间资源。

一切尽在掌握

计划的最重要作用是提前做好准备。

例子：作者的博文，有严格且弹性的写作计划和发布计划，在文章发布前通读，做好预发布。有一定文章储备后，可以做定时发布。

5.3.2低头走路，抬头看天

我们继续靠谱的会议

所谓的靠谱会议有：

不要试图在一个会议中解决很多问题；

确定好参会人员中的“必选”和“可选”；

提前和关键人物讨论好关键议题，让最后的会议变成形式；

参考《罗伯特议事规则》，即“所有人提供意见，少数人讨论，一个人拍板，做到“效益与公平”；

做好会议记录，不让拍板人反悔。

仰望战略会议

务虚的战略会议是经验丰富的人在掌握极多信息的基础上做出的预测与判断。

5.4KPI,KPI,KPI

KPI,即Key Performance Indicators，关键业绩指标。

企业战略难以让每个员工理解并为之奋斗，分解为基本战斗单位KPI后就好办了。

SMART，并不smart

SMART是指Specific、Measurable、Attainable（可实现的）、Realistic（现实性）、Time bound。

例子：项目发布4周后，每周访客数在“70到700之间”的网站，访客转化率提高1.5倍。 不要片面追求数字，甚至做违背企业战略的事情。KPI不是目的，是手段。

多个目标间的权衡

做产品必须面对的问题是商业目标与用户目标的权衡。

用户会被分成新手、中间用户和专家。给专家设计的产品，要让人适应产品，比如乐器。给新手设计的产品，要让产品适应人，比如公共设施。

长期目标与短期目标的权衡：用户长期使用产品满足了公司战略，但对于创业公司或新产品，如果不“短视”，就会被淘汰。

达摩克利斯之剑

不合理的KPI要改变KPI本身。

例子：销售部门负责KPI是用户数，产品部门负责KPI是活跃度

->销售部门为了KPI，把产品卖给非目标用户。产品部门希望用户都是目标用户。两者产生了矛盾。

->大家一起负责KPI不是好办法，到到最后是没人负责。

->重组为三个KPI：用户数（由销售部门负责）、使用率（使用用户/付费用户，服务部门负责）、活跃度（活跃用户/使用用户，产品部门负责）

5.5本书的源头活水

6.产品经理的自我修养

6.1爱生活，才会爱产品

一个人在有了积极乐观的人生态度后，才可以发现生活的美，才会爱上做产品这样一件改变世界的事情。

我总跟门过不去

例子：围绕某餐厅的斜着的门讨论，发现这个门设计的奥妙：门不对着任何座位，这样不会有人在吃饭时被进出的人弄得不爽；装修一般饭菜很贵的店，适合新顾客，比如开在风景区，装修很好饭菜一般的店，适合老顾客，比如开在商业区的这一家。

例子：横店电影城秦王宫的门：入口顺畅，这好比吸引用户注册，出口弯弯曲曲，两边都是纪念品店，是要从旅客上榨点油水。

乱谈餐馆的菜单

分析战略层的商业目标与用户目标。比如单位食堂的商业目标不一定是赚钱，路边小店的菜单不一定要精美，干净就行。

例子：目前这家店周围是写字楼和学校，目标人群是白领和学生，人均价格在50元左右。菜单可以根据不同标准细分版本：

针对特定人群：对情侣，菜的名字可以暧昧一些，比如“一心一意”、“爱在你心口难开”。 针对特定时间：对每年6月的大学生散伙饭，推出“我们毕业了菜单”，融入不舍与祝福。 菜单中菜类的顺序，是否配图，标价方式，都可以去想。另外电子菜单虽然功能强大，但是成本巨大，不予考虑。

用户创意无限

例子：写一句话做签名，不停上线、脱机、上线，就可以借MSN从桌面右下方弹出，让好友们不断看到。常用方法：剧透、表白求婚、广告位招租。

例子：用户把windows回收站当做文件夹、毛巾放在微波炉里转干。

面对用户错误使用产品，只要不与产品战略冲突，不妨将错就错。这也算是另类的UGC了。

6.2有理想，就不会变咸鱼

一个人与一家公司一样，最重要的是内驱而不是外驱。

作者的理想：自己改变世界->多了解世界，告诉更多的人，大家一起去改变世界。

成功在自己手中

热爱生活把“要做的事”变成“想做的事”；学会思考，提升能力，把“要做的事”变成“能做的事”；寻找理想，把“要做的事”、“能做的事”整合成“想做的事”。

个人品牌建设

给自己留下些东西：主动建立流程，把它们画出来；主动管理文档，建立文档模板库；把自己的工作实战心得写出来。

就业保障会降低个人竞争力，职业保障会提高个人竞争力。如果去找工作，有一堆公司排队请自己去，这才是真正的保障。

个人和公司是一起成长的。

个人名片设计实例

战略层：用户需求：真实感（公司名片把人符号化，个人名片通过爱好、经历、专长展示有血有肉的人）、亲切感（公司名片把别人当客户，个人名片把别人当朋友）、专业感（名片是某种媒介）

范围层、结构层：正面标准个人信息、反面标签云展示爱好、经历、专长。

框架层、表现层：找美工和淘宝印刷帮忙搞定。

我的理想之路

三个一工程：一本书、一个站（iamsujie）、一门课（面向创业型团队、互联网行业的课）

6.3会思考，活到老学到老

学校里没教的东西

学校教育的欠缺：

教知识（怎么做）不教思维（应该做什么，为什么要做）；

教解题不教选题（产品经理应该追求“性价比”而不是“完美”）；

教努力不教取巧（是否独立解决问题不重要，充分调动团队、用最有效的办法解决问题才是本质）；

教受教不教施教（产品经理要多多写博客，在交流中成长）

只有方法，没有答案

略

好好学习，天天向上

知道多少知识并不重要，重要的是在各种应用场景下，能提取出多少知识。

6.4能沟通，在什么山头唱什么歌