1. 不打算整书做笔记了，抽一些零散的点记录下。从印象来说，这本书偏向广度，而非深度，当然人家也说了，主要是为-1到3岁的产品经理写的。

2. 虽然作者本意很好，但这本书的名字，从字面意义去理解，真的给这个行业带来了很大的伤害。大部分人从表面意思去理解，导致这个岗位的专业知识得不到外行人的尊重。举个栗子，就好像大部分人都不清楚PULSE，HEART和用户体验要素五层模型，但张口闭口就聊用户体验，很无奈。

1 以用户为中心，和以老板为中心的思想

首先要区分用户(End User)和客户(Customer)。用户是真实使用产品的角色，客户是买单的角色。

既然用户那么重要，很自然地就要把他们放在中心位置。所以有个词叫UCD，User Centered Design。

公司有UCD的环境是产品经理的幸运，但对于大部分人来说，BCD是更多要面临的情况。BCD，Boss Centered Design，以老板为中心的设计。对于中小型公司来说，需求的一个很大来源不是用户，而是老板。一般来说，在这类公司中，老板反而是最接近业务，最了解用户的，加之老板的经验和阅历又超过我们，所以他高屋建瓴，高瞻远瞩，更容易抓住商机，比产品经理的观点更合理，那么这时候老板就充当了很大部分产品经理的角色和职责，起到了采集用户需求并分析筛选的作用。创业公司通常没有太多时间和精力“从用户中来到用户中去”，这一来一去公司可能就关门了。因此有时候一个问题和需求的诞生，就是靠老板凭经验拍脑袋。在这种情况下，我们应该本着实用主义的思路，绝对不能一开始就想着造反：“我要见终端用户，我听用户的，我不听的你的”，而是要尽可能的帮助老板明确问题和需求的价值，为其决定的方向提出参考建议，或协助其实现目标。唯一前提就是老板要做的事情，不违背你的价值观。

2 需求采集时，我们可能过于强势，把用户往沟里带

在需求采集的时候，特别是对于用户访谈，一定要牢记访谈的目的，并且管好自己的嘴，关于用户访谈的注意点，摘录一些：

》避免一组固定的问题：固定的问题会让被访者产生被审问的感觉，我们应该准备好问题清单，但是清单只是一个引导作用。

》首先关注目标，其次才是任务：比用户行为更重要的是行为背后的原因，多问问用户为什么这样做。

》避免让用户成为设计师：听用户说，但不要照着做，用户的解决方案通常短浅，片面。

》避免讨论技术：特别是碰到一些略懂技术的用户，不要跟他纠缠产品的实现方式。

》鼓励用户讲故事：故事是最好的帮助设计师理解用户的方法。

》避免诱导性的问题：典型的诱导问题比如“如果有xxx功能，你会使用吗？”，这种问题会导致用户毫无意义的肯定答复。

》用户访谈通常都是开放式问题，问卷调查通常是封闭式问题偏多，但也有开放式问题。

》调查问卷的设计：整体作答时间不要超过5分钟；开头通常放一些不需要思考的简单问题；很想知道的内容，需要思考的问题，较敏感的问题一般放在中间；有关被访问者个人信息的题目，一般放在最后，以免在回答前面的题目时，有所顾忌，从而影响答案。

3. 需求分析的Y理论

需求分析Y理论

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

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

伟大的需求分析师，可以无视用户想要的东西，去探究他内心真正的渴望，再给出更好的方案，就像更快的马和汽车的关系。

但是说到这里，也必须提一下，销售人员经常说“用户是为想要的东西买单，而不是他们真正需要的”，其实这话的意思是“用户是为他们自己的解决方案买单，而不是我们产品的解决方案”。这么说来，还是有一点纠结的，如果是这样我们还分析什么，按用户说的的就得了。

这个问题的本质是短期利益和长期利益的权衡。如果是一锤子买卖，卖出后不用售后，那么采用实用主义，追求短期利益，用户想要什么就给他什么，只有这样他掏钱才会爽快。但是如果你的产品是想用户长期实用的，就要追求长期利益，我们就必须找到用户真正的需求，然后给他真正合适的产品，哪怕这个过程比较坎坷。

4 满足需求的三种方式

需求的本质都是问题，也就是现实跟理想的差距，那么减小差距的方法有三种：

1. 提高现实。也就是去开发某个东西，通常来说这是最笨的方法。

2. 降低理想。不要忽视精神的力量，什么“打预防针”，“丑话说在前头”都是这个套路。

3. 转移需求。因为人的注意力是有限的，引导用户去关注其他事物，他就会觉得这个差距也没有那么不可接受了。比如说我们可以寻找更刺激的需求展现给用户，而让用户不再纠结于原来的需求。

5 需求的DNA检测

5.1 理解用户需求 

5.2 把用户需求转化成产品需求 

5.3 分析产品需求的商业价值 

5.4 初步评估产品需求开发量(实现成本) 

5.5 计算产品需求性价比 商业价值 ÷ 实现成本

这里我们详细说说“5.4 初步评估产品需求开发量(实现成本)”。

通常在这个阶段，需求其实是不明确的，只粗略知道要做哪些内容，而具体怎么做根本还没考虑，所以有的技术人员会觉得无法评估开发量，这很正常。技术人员会说你们不明确每个需求怎么，他们就无法评估开发量。而产品人员会说你们如果不评估开发量，我们就没法确定哪些要做哪些不做。于是就死循环了，这类先有鸡还是先有蛋的问题，其实也无需纠缠。

一句话：在需求检测阶段，开发量是一定要评估的，这个评估叫初评，允许误差，并且通常由经验丰富的技术人员来评估。

相对于初评，在项目启动之后，还会有精确评估，而这时候需求也明确了应该怎么做。

同时，需要注意的是，绝对不能因为某个需求的实现难度很小就马上去做，也不能因为一个需求的实现难度很大就不做。

6 职能型 VS 项目型(产品线型)

按产品线划分的团队对产品本身是有利的，产品经理权利更大，可以按照自己的想法做，资源有保证，产品规划更清晰而不容易改变。此外，各种职能员工都是一个产品成员，归属感强，目标感强，所有人都对产品负责。

按职能划分的团队对多个产品的资源共享有利，可以让资源流向更需要的地方，保证对核心产品的投入，但是效率不高，而且在这种情况下，产品规划的决策权在更高层面决定，单个产品的发展速度会有所减低。此外，资源战争可以把鲶鱼效应从产品内部扩大到整个公司，使产品经理和设计师们更抓狂地位产品苦苦思索，这是好事。

两种组织结构，就像一攻一守的感觉。产品创业初期，需要全速发展，更适合项目型(产品线型)结构，产品经理带头向前冲。而当公司有多个产品慢慢成熟后，要做的事情通常比创业的时候少，或者说没那么急，就更适合职能型组织稳扎稳打，追求资源共享，同时促进各个产品团队之间相互学习。

除了书里提到的职能型和项目型，实际工作里，更多的还是矩阵型，矩阵分为弱矩阵，平衡矩阵和强矩阵。

7 战场：产品会议

一般来说产品会议一个月一次，当然也和产品性质有关，有些产品周期较长的，也有三个月一次的。

当某个产品团队开始登场的时候，先回顾上一次产品会议通过的项目，现在进展如何，是否需要调整时间进度，是否需要追加资源，是否有重大需求变更，已经发布的项目数据表现如何，有什么问题等。这样一方面是为了让大老板们更新各个项目的信息，更重要也是为了积累经验，让今后的产品会议决策越来越合理。

回顾之后，就是最关键的部分了。我们会拿出准备好的商业需求文档(BRD，MRD，PRD等)，每个产品都会拿出三五个，占满2~3倍的潜在开发资源。BRD通常包括项目背景，商业价值，功能需求描述，资源评估，风险和对策等内容。

大老板们会决策哪些事情立项，哪些事情暂缓。

在这里要注意，BRD转化为项目也并非是一一对应的，可能多个BRD合并成一个项目，也可能一个BRD拆分成多个项目。

8 少就是多

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

关于项目管理，我的入门书是微软的《快速软件开发》，里面提到了很重要的一点，一直深以为然，“用户永远不是要在规定的时间内，拿到一个不能用的软件，而是希望得到一个可用好用的东西。”，所以微软就各种跳票吗。相对的呢，MVP似乎在讲你东西先上，上了再改。

一来，可能是我没有真正理解MVP的理念；二来，可能也跟企业状态有关，成熟的企业不着急，初创企业只能赶紧上。

很多事情，我们不要觉得吃苦耐劳才是贡献，而是应该直接从目的出发，四两拨千斤才是最巧的。

还有一个现象，内部(技术层面)的大改，往往是外部(商业层面)的小改动，反之亦然。

9 发布计划评审

发布计划的评审也很重要，需要运维人员确认。特别是对系统改动较大的项目，可能需要分模块分步骤发布。对于用户影响较大的升级，有时候需要采用灰度发布，即让一部分用户先用新版本，然后收集反馈之后再决定是否大范围发布新版本。而且在发布计划中，还要加上回滚方案，一旦发布不成功，就赶紧把产品退回原来的状态。

10 流程和竞争力

路况(软硬件环境)与开车水平(个人能力)的要求成反比，做流程的目的，就是改善路况。

团队的核心竞争力就是把隐形知识转化成显性知识的能力，个人的核心竞争力是把显性知识转为成隐形知识。

对于流程管理，有句话叫：先僵化，后优化，再固化。

11 老板项目

老板项目，就是老板忽然跟你说，我们要做个什么什么，然后你只有执行的份儿。那回顾一下，对项目来说核心的点T时间，R资源，Q范围。对于老板项目来说：

T时间，是给死的。我们可以试图商量下，因为很多时候我们常把老板的偏好当成规则，老板只是一时说最好怎样，我们就理解成了必须怎样，那就亏大了。当然也确实在很多时候，时间就是给死的。

Q范围，是可变的。一般越大的老板给出得指示就越具战略性，越不具体。所以具化出来的Q就可大可小，这是需要我们发挥的地方。开始可以尽量施展聪明才智天马行空，把Q尽量搞大，并合理算出对应的R资源投入。然后就让老板看看R是否合适，如果他给不了对应的R，就会主动砍Q了。当然我们应该尽职地帮老板排列好建议优先级和所耗的资源，好让老板知道刀应该砍向哪里。

R资源，是丰富的。老板项目，通常来说资源都是比较丰富的。在要资源的时候，千万不要试图帮老板节省，这样反而不好，老板可能会觉得你思路不开阔，不带劲。

当然，也有时候你发现，TQR老板都给你定好了，那你也别废话了，老老实实干活呗。更悲剧的是，R是不足的，T也是固定的，Q还不能砍，这就只能上最后一招了，加班。这种项目太多了，也只能期望公司明天会更好。如果这种项目加班还做不完，就还是撤吧。

最后谈谈老板项目到底好不好？从个人角度，如果是纯项目经理，这就是本职工作，无所谓好坏。如果是产品经理，老板项目就没什么成就感，还可能老板的项目目标你根本就不认同，这时候也只能说只要不违背自己的价值观，就尽心尽力完成项目。否则就据理力争，如果争取失败，要不调整自己的价值观，要不就放弃这份工作。从好处的角度来说，老板项目能接近老板，能接触老板的思路和眼界，算是一个提升。

12 开发外包，项目外包

这类项目，最大的体会就是：任何一个项目开始的时候，合作的多方必须要明确合作模式，划分权责利。

既然是项目外包，项目管理的方法就应该由乙方定，乙方也应该主动向甲方收集需求，并维护PRD等文档。

如果是开发外包，那么项目管理需求工作就由甲方主导比较合适。

还有一个教训就是，做任何事，权责利要尽早划分，而且权责利也要划分对等，有权力的人，可以享受事成的好处，也要承担失败的损失，千万不能只是因为你有能力做某事，就把任务接下来，这样对谁都不好。

13 项目的成败

13.1 项目的发起通常是自上而下的，就算是自下而上的发起，也要在充分获得高层支持后才靠谱，无论哪个项目，没有高层强有力的支持，几乎就是白搭，而且自己的努力全然白费，也会很失落。

13.2 产品一定要时机合适，不能领先市场太多。一句老话说：早一步是先驱，早两步是先烈。

14 用最简单的方法，触碰问题的关键

当自己对某个领域不熟悉的时候，做起事来总会把问题想象得很复杂，把自己知道的所有知识都用上。而真正的高手，往往可以一下子找到问题的关键，然后用最简单的办法搞定。

15 跟工程师配合

工程师是一帮超级理性的人，他们其实很明白没有规矩不成方圆的道理，所以他们喜欢被规则管理，而不是被人管理。

16 大家好才是真的好

公司最大的财富就是人，是团队，只要人在团队在，哪怕现在的产品没有了，也还有重新起来的机会。

17 推荐图书

产品经理的第一本书，水平营销，用户体验要素，赢在用户，点石成金，设计心理学，情感化设计，软件观念革命：交互设计精髓，交互设计之路，公司进化论，创新者的窘境，罗伯特议事规则，人月神话，UML基础案例与应用