全文分2个部分，一是自我提问部分，用于加强理解。二是正文部分，用于总结反思。

自我提问部分

一、这本书讲了什么？

从人员配置、流程理解、手段使用、好产品的要素上去告诉你好产品是如何被打造出来的。

二、作者通过这本书解决了什么问题？

鼓励读者打造更好的产品

三、这本书说得有道理吗？

我实际工作经验浅，这个问题我没发解答。

四、这本书与我有什么关系？

入门前的科普读物，帮助我理解产品经理的工作内容框架；帮我解决了实习毕业1年来遇到的一些困惑；

下面是正文部分

1.人员

1）产品经理与产品营销要做好区分

①产品经理的职责是评估机会&定义产品

定义产品，指让产品在能为用户产生价值的前提下，尽可能方便用户使用。

我所在的乙方公司，产出偏定制，在如何定义产品方面并没有成熟方法论支撑，更多靠的是抄袭+无多大根据的“微创新”，能不能产生价值全靠蒙，工作内容其实就是0.8的交互设计助理+0.2的产品助理。

有能力做机会评估的人在公司只有一个，但已准备离职。

本来想着是踩坑了得赶紧离职，但仔细想想我这心态不对啊，没有东西是完美的，填坑拓荒就是你产生价值的过程啊，况且起点低就得要有起点低的玩法嘛。(苦笑ING

②作者表示以下2种职责划分会导致显著问题，有能全权定义产品的人才更有可能开发出有价值、具备可用性产品：

市场营销（运营）人员定义高层需求，产品经理负责底层产品。

这将导致产品最终负责人不明晰，还会让产品经理成为文档输出器，我前公司的产品经理，真的就是这样，因为产品经理是运营大佬负责招的...产品和运营应平级才对（产品的能力强到让大佬十分信任例外），这样产品才可能更好地去看待每一个需求，创造性也不至于被各种高层需求压制（主要是精力被压制）。

一人兼任营销与产品经理的工作。

就算是有能力，精力大多也是不够的。比如我现公司甲方TX的JIAOZI。

2）关于自己公司项目经理的设置

书中谈到有2种情况一定要设置项目经理，一是超10名开发参与的重点项目。二是采用火车头发布模式的开发团队。

在回到我们团队的项目经理，其实只能叫...制表大师。没有紧迫感、不善于发现问题、态度敷衍是他的常态。

以下部分以话题PK为例，我总结了当时疯狂延期的几个主要原因，项目经理是打杂的，俺不奢望自己会被他骂，只能自己锤自己：

①团建，但如果前期做得够快，其影响是可以大幅度降低的，还是自己专业度不够的原因

②没有给重构预留修改时间：重构做好了但修改了2天，导致后半部分预约失效

③对功能、适配测试、测试联调的理解不到位，完全不知道有这回事，根本原因是没有仔细去理解以往的全部排期过程细节

④推开发前没有给开发做二次的需求说明，从初次给设计稿到最终推开发，这期间需求可能会有比较大的变动，这个变动没有记录（有点懒，从下次活动必须开始有），导致关键的变动无法被开发知悉，导致开发错误判断开发时长，从而使得排期必须被变动

⑤对模板化和一般页面的制作时差没有概念，一般模板化的页面考虑的内容会比一般页面的多；对V4后台没有概念，腾讯的V4后台不需要重构做手机适配，而一般的活动页面则需要

教训&技巧：

①所有内容，按最宽松的时间排好时间后，再把所有能挤压的过程全部挤压1~2天回去，尽量给意外留足时间

②对不同项目所需的不同过程原理必须一清二楚

③熟记所有变动，进开发前的所有版本变动必须让开发一清二楚

3）好的产品经理应该具备什么素质？

①对产品的热情：对自己喜欢的和不喜欢的产品都能聊得来

自己目前缺一套正确理解产品的方法论，看完《用户体验要素》后开始做大批量浏览与记录。

回到面试上来，如果想投产品助理，最好在这之前要选出自己感兴趣的品类，用2~3个月的时间做深入分析做入行敲门砖。当然在这之前要更着重产品相关技能的训练。

不喜欢的产品可以选日常不得不用的产品来讲。

②用户立场

产品经理不一定得是目标人群，但一定得想办法融入目标人群，应聘前最好对公司产品的目标人群有足够的了解。

某百度大佬，接手某一产品前一定会做一个月的客服去理解目标用户。

③智力：看重解决问题的思路和方法

④职业操守：你愿意为热情加班吗

求加死我。

⑤必须值得尊重：凡是有理有据，习惯尊重他人意愿

⑥信心

刚毕业大学生一般来说是盲目自信，比如去年的我。

但自信能让自己的话更具说服力，毕竟大家都不愿意自己的时间都被狗吃了。

⑦态度：你定义了产品，你决定了方向，失败了就是你的锅。

⑧技能以及运用新技术的能力

⑨能分清工作重点：一些无关紧要的功能，必要时就抛弃

实习时为了实践给产品经理提一个SDK功能，产品为了不当面拒绝我使出了各种手段，可以说真的是很好人了233333。

⑩沟通能力：言简意赅直面本质，演讲是必备能力

一定得利用好各种机会尝试演讲，这块能力自己的确蛮弱。

2.流程

1 ）如何评估产品机会？

可以按照以下维度试着写一篇市场需求分析，暂定方向为小狗在家、猫卡

①满足了什么用户的什么需求？

②目标用户规模是否够大

③怎么确定这玩意儿能赚钱？该用什么指标？

④同类产品有哪些，定位分别是什么，我们有什么优势？

⑤这个时候推出新产品合适吗？

⑥怎么做营销？

⑦产品成功的必要条件是啥？

...

大多数人会常犯“把洗澡水和孩子一起泼掉”的错误，即一件事情，明明很有价值，但ta会因为事情太难完成而选择不去做，连0成本尝试都不愿意，倒是愿意天天玩手机做些毫无意义的事。

另外，产品脱离用户，等于鱼缸里的鱼没水，迟早渴死。

2）怎么理解产品的定义过程？

发现机会其实不难，难的是怎么在解决问题的同时还能创造商业价值。像医药业，有些病症摆在那儿，可就是没人上啊，不是不想，是做不到啊。

产品定义的过程有时真的很难，但还是容易被大佬设下期限，毕竟不能放着开发团队不干活，做了好过没做，而这种操作经常导致创业公司失败，船小没钱也掉不了头。创业阶段如果能先做出一个高保真原型去做市场验证那最好不过。

怎么看待产品定义过程中出现的争论？

在作者看来，大部分讨论无法产出结果的原因是大家的目标不一致以及对目标优先级的理解有差异，那么，按照以下思路去讨论问题，或许会是最优解

[if !supportLists]②  [endif]弄清楚是为什么用户解决什么问题

②要解决这些问题，需要达成哪些目标，目标的优先级呢？

3）学会区别线框图与高保真原型图的作用

线框图多用于前期的内部概念交流，黑白灰即可；高保真原型可直供用户进行体验，用于开发前的产品价值（渴求程度）、可用性验证（使用难易）。可以在重构阶段解决的需求验证，就不需要等开发后再做。当然一些经过验证、实现起来简单的小功能在富余状态下就没必要死脑筋花大心思做验证啦。

其实如果自己想应聘产品助理，自己花钱找设计找前端把高保真原型重构出来成本也不高。

EMMM..真要做的话，不如就拿母婴、小程序来做切入吧，反正老板也有这方面意向。高保真原型做出来，即使老板不认可，也一定程度上证明了你的能力。(原型不能展现的业务逻辑、发布要求等就用测试用例表现出来)

4）用户体验设计与实现

需求调研和用户体验设计可以一起进行；开发与测试可以交替进行，没必要非等开发完成；但用户体验设计不可与开发同步，做话题pk的时候，就因为用户体验设计这块考虑得不完善(个人专业度不够)，竟然与技术在这方面产生了分歧从而影响了开发进度。

5）评审团的职责

评估产品机会-评估产品的解决方案-评估最终产品是否适合发布

以上过程非一次性，比如可能会针对产品机会的评估按星期甚至按月开会

6）关于KOL

如何看待KOL？

基本作用是消除一般用户使用顾虑，KOL本身就是自带流量的人。KOL要么从外部挖掘，要么从内部培养。

在产品定义阶段，一般会组建6~10人的特邀KOL团体，再多产品就HOLD不住了。

KOL在产品定义过程中的作用？

①宣传：自带流量，解决了他们的需要就等于带来了一批种子用户

②时刻准确用户需求：KOL为定义产品提供宝贵建议，使产品不至于跑偏

招募KOL时需要注意的点

①如果发现招不到KOL，那就得考虑是不是产品本身其实并不能吸引到用户。

②需要保证招募到的用户不是非理性用户，非理性用户可能会因情感因素忽视理性用户通常会非常在意的内容，招募到的用户应该是要能代表一般大众的理性用户。罗永浩的粉丝不就大多是非理性用户吗？罗永浩也太把这群小众且非理性的用户当回事了，导致他开发出了各种一般人跟不会买的产品。（作者根据消费者的情感特征，把他们分为技术爱好者、非理性消费者、理性消费者、超理性消费者、跟随者）

③要始终向KOL明确产品不是为私人定做的，是为大众开发的，所以在各项产品功能的权衡上会有偏向，各位KOL也不希望自己辛苦参与做出来的产品寿命极短吧？

④KOL是产品经理的伙伴，诚信对待他们，看做合伙人也不为过。所以在产品发布前，一定要请他们看一遍，确保他们都满意，因为一旦发布，他们会非常卖力地向周围人推荐这款产品，因为这款产品是有他参与制作的，且参与程度越深，KOL越卖力。

7) 市场调研的作用与局限性

工具的使用

①问卷调查

需要注意2点，一是问卷没有想象中那么简单，二是调查结果不是解决方案本身，只是提供一个解决途径而已。

②数据挖掘

③拜访用户-十分好的方法，但注意成本

④人物角色

调研可根据人物角色展开，注意人物不是单一类型的，可能是多类型的。这一方法重点关注用户的行为、态度以及目标，通常用来筛选产品的重要功能（即尽可能让功能覆盖到多类型的用户）、避免团队成员将自己的需求当做用户的需求、对功能进行优先级排序、帮助成员快速达成共识从而提高工作效率

⑤可用性测试\原型测试

与人物角色一样，经常被忽视。

⑥竞品分析-常用且必备的技能

⑦用户研讨会

直接接触用户是好，但容易产生以下问题

①用户很难凭空想象自己想要什么问题的解决方式

②善于表达的人容易把控全场

③如果产品还未推出，那用户研讨很有可能就是在飘

④研讨会主持人功底要十分扎实

市场分析的作用

① 明确目标用户群体

② 用户会怎么使用产品，是否会遇到困难？

③ 用户为什么要选择你的产品，是因为什么特点么？

④ 用户希望如何改进产品？

市场分析的局限性--市场调研仅仅是为了提供决策依据

8)如何测试产品可用性和价值

物色测试者

①避免你的测试者为尝鲜者

②测试者不能与你关系过于亲密

③补偿用户在测试上的花费时间、即使预约了测试时间，仍有一定比例用户会爽约

准备测试

①提前拟定主要测试项目，次要项目待富余时间测试。

②了解测试者未接触产品前如何解决产品要解决的问题，这是一个了解竞品、了解用户搜索习惯的好机会，使用了你的原型后再问这个问题，就可能导致有偏颇，感觉与锚点有关。

③用户第一次看到首页如果感到懵逼，那该原型在可用性上可能就是有问题的，要珍惜测试用户的首次使用体验。

④用户完成体验后，着重问他有无其他更好的问题解决方式以及是否会把原型推荐给其他人

⑤即使原型的次要功能不完整，也可以拿去测试，空出来的地方问问用户想要什么功能。

测试环境

①超级专业的环境有最好，没有也不强求，访谈者的主场最好

②测试时用户的神态观察，是线上测试所不具备的

③产品经理应该克服类“忠言逆耳”的障碍

测试原型过程细节

①测试开始前不要太多话，快速步入正题，越多的对话就越有可能影响用户的第一判断

②测试前要告诉用户的事项

A.这不是正式产品-保证不带过高期望

B. 请说出真实看法，不要管在场人的心态

C. 不要担心测试会出问题，只有原型会无法通过测试-让用户放松

③ 测试的重点是能否轻松完成任务和是否喜欢某项功能，如果用户提到元素不好看应该修改，那就跑题了。

④ 了解是什么情感驱动了用户使用产品，再问问还有什么事物能满足这种情感，这类型的事物或许就是你产品的竞争对手。

9) 两种主要的开发方法

敏捷开发鼓励人们相信重构和快速重新设计架构的优势，但生搬硬套对大众软件大概率是不可行的，毕竟敏捷开发从一开始就是针对定制客户的产物。（那什么样的敏捷开发方式才是适合大众软件的呢？）

比如Scrum?极限编程？

瀑布式开发方法

① 仍是当前热门开发方法之一，瀑布式开发方法的特征？

A.与敏捷一样被分成固定阶段

B.过于理想化，以为人们能预见所有问题，强调流程开弓没有回头箭

②为啥瀑布流经久不衰？

A.无回头箭式的开发流程预测性更强，更易给管理层安全感，因为结果相对可预测

B.使用敏捷开发方法后，产品定义过程可能会变得敷衍，导致不断返工，这一返工过程在很多时候会被视作效率低下

3.手段

1）推动上司助力的正确方式？

只挑了自己做的不好的3点来谈

①为每一次的项目波动记录好原因、时间、造成的影响，便于定责的同时也便于反思自己

②多提建议，少抱怨

回顾自己2次的主要工作经历，抱怨这种情况的发生基本都出现大家都互相熟悉后，因为自以为跟大家很熟悉了随便说都行，但其实这样真的很减分，特别是在你之前做得很好的情况下。

多提意见少抱怨这种心态应该成为常态。

③多用数据和事实说话

专业知识的匮乏是我近期话语权低下的主要原因，近期也是在恶补特定领域的知识。每一个建议能够有依据有事实支撑是我一直想做到的。

2）善用身边人

原公司产品不大愿意接受他人建议，即使跟主管唠嗑也总是在工作范围内，感觉他还是有点小自负2333。

无差别唠嗑有时候是能产生巨大收益的2333，比如打个快车跟司机唠嗑发现了E巴士，一句话就帮我省了上千小时和上万RMB。

3）如何理解用户：技术接纳曲线&情感接纳曲线

产品的技术&情感接纳曲线（来自简书用户江畔见月）

情感分类曲线是对技术分类曲线的一种补充，技术分类只区分了看法，但无法说明用户的消费心理。

虽然非理性与理性消费者有着同样的消费情感需求，但情感需求强弱程度不一便导致了他们在购买行为上存在差异。而因技术、因愤怒恐惧孤独等极端情绪产生的非理性购买需求数量总是会比理性消费者少，因为人们对某一领域知识的了解程度总是相对固定，这便意味着特定领域的痛点永远只有早期市场的少数人能深切感受到。

非理性消费者中，技术爱好者是最不需要被关注的群体，毕竟他们的需求不是主流需求，而尝鲜者却是我们应该重点关注的，因为他们的情感需求，很多时候就是理性消费者放大之后的情感需求。

非理性消费者的情感需求可以借助马斯洛模型分析，情感需求有多迫切，一般来说就越容易成功。

购买matebook时我是以一个非理性消费者（尝鲜者[社会认同]+技术狂热者[轻薄炫酷]）的身份购买的，而matebook本身主打的中高端市场，这种在马斯洛情感需求上偏高层的产品定位，大概率得走价不走量。

总之，不要对生活中他人的不满情绪视而不见，有不满才有新机会嘛。

4）如何理解用户：技术接纳曲线&情感接纳曲线

说是这么说，但如果真拿什么事情按这个金字塔去做分析，大概率是没啥用的，有些事情本身就特别复合，因此这里得引出冰川模型中提到的3个动机，影响力、亲和度以及成就感去替换掉上面的“精神性价值需求”。

按着冰川模型，一般人在满足安全、生理需求后，往上追求的将会是影响力、亲和度、成就感，不同人对这3点的渴求程度总是会高低不一。

5）产品经理每日思考清单

产品能吸引目标消费者的关注吗？

产品的设计是否人性化，是否易于操作？

产品能在竞争中取胜吗？

我了解目标用户吗？

产品是否有别于市面上的其他产品？我能在两分钟内向公司高管清楚的阐明这些差别吗？能在一分钟内向客户解释清楚吗？能在半分钟内向经验丰富的行业分析师解释清楚吗？

产品能正常运行吗？

产品是否完整？用户对产品的印象如何？销售业绩如何？销售任务能否顺利完成？

产品的特色是否与目标用户的需求一致？产品特色是否鲜明？

产品值钱吗？值多少钱？为什么值这么多钱？用户会选择更便宜的产品吗？

我了解其他团队成员对产品的看法吗？他们觉得产品好在哪里？他们的看法是否与我的观点一致？

4.什么是好的产品

1）在大公司如何创新？

为什么在大公司创新比较困难？

①风险厌恶，所有既定的流程、条框很大程度上都是为了规避风险

②为了节约开发资源而存在的矩阵式管理，创新者需要有能力确保得到足够的支持

常见创新途径

①20%法则

公司主动给出20%的工作时间，供员工自由发挥

②臭鼬工程

阶段性地给出成果，再尝试说服

③新方法解决旧问题

比入改善用户体验

④收购小公司

创新过程中需要使用到的手段

①了解决策的拍板方式，每家公司都不同，不要抱怨。

②人脉-设计、开发、发布工作，如果想开展臭鼬工程，没私人关系推不起来，多少优秀产品都是以这个方式诞生的；多进行信息的交流，有付出才有收获。

③为了推动产品进度，有时候你得五项全能，抱怨就等于项目受阻。

④不要轻易因为某些事情撕破脸皮，除非事情对你真的非常重要，还千万要就事论事，不客观只会让你的话语权越来越低。

⑤开项目立项会前，最好私下先和预参加会议的人员达成一致意见，不然一旦会上有反对言论，在准备不够充足的情况下你会十分被动，且这种反对言论很难被挽回，因为反对者要脸；如果可以的话，最好先获得你上司的认可，让他成为你的“得力助手”；平时多向你的同事宣传你的原型，让他们在参与过程中认可你，潜移默化的作用很是恐怖。

⑥学会信任你的伙伴，充分放权。你需要更多实践思考哪些事情是你应该做的，以及怎么把事情做对。

2）打造TO C\TO B\平台产品的十大要点

to C 产品

①可用性：产品即使有优势，但交互上让人难受、颜色让人感到恶心，那产品就等着凉。

②人物角色：人过多产品经理就得抽象出有代表性的用户类型辅助后续判断

③扩展性：不仅是功能新增上的扩展性考量，系统负载方面的性能考量也是不可忽视的一个点，用户爆量带来的服务器过载是分分钟击垮服务器的，如果这方面的考量不到位，项目可能会受到极大影响。

④稳定性：运维人员了解一下

⑤客户服务与良好的用户社区管理

⑥用户隐私保护

⑦擅用口碑营销：鼓励用户分享以吸引新用户

⑧全球化：段位不够，不说了，难受

⑨平滑部署

to B 产品（这一块不太懂，略记）

①可用性、稳定性

②尽量避免做出定制产品，要极可能面向大的群体

③使用特约用户，人多就用户角色

④销售渠道的需求，系统集成与增值服务商需求不一（不懂）

⑤产品安装维护便捷、尽可能简化升级流程、

平台产品（这一块不太懂，略记）

平台产品指一类基础软件，应用开发者能在其基础上开发应用程序。

3）如何打造富有创意的产品？

①明确产品经理的职责是定义产品（有价值、用户可用性、技术可行性）和评估机会，要与产品营销区分开，

②关注用户体验，用于体验与可用性同样重要

③机会评估，一是要用更为便捷的评估方法取代市场需求文档，二是动手评估前，要先明确产品为谁在什么场景下解决了什么问题。

④特约用户：绝对不能离开用户闭门造车，让用户参与原型的体验，是避免资源被浪费的重要方法之一

⑤善用人物角色：决策依据的来源之一

⑥使用原型：是关键步骤，目的一是强迫产品经理深入定义产品方案，二是让真实用户直接参与，获取可信体验效果数据，三是高效地向团队展示设计思路，降低理解成本和出错机会

⑦原型测试：必备技能，知道如何有效地获取用户反馈

⑧知道用户的行为与要求是两回事，数据通常由行动产生