人人都是产品经理读后感（持续更新）

自序部分
1、学会用产品经理的视角去看待问题
2、互联网产品设计的五个层次——战略、范围、结构、框架、表现

Chapter1入门
1.2
互联网、软件行业的产品经理在概念上发生了变化和发展

产品是什么？
产品的狭义概念：被生产出的物品；产品的广义概念：可以满足人们需求的载体。
直白理解：产品就是用来解决某个问题的东西。解决问题即满足人们的需求
产品这个东西，可以是有形的实物，也可以是无形的服务

产品经理的出现是为了适应公司发展的需要。随着企业越来越大，产品越来越多，越来越复杂，原来按职能划分部门的组织结构已经无法适应，所以出现了产品管理的矩阵型组织。
产品经理的职能变化：
现今产品经理的概念：更多侧重产品本身“从无到有”、“从有到优”的过程，更多地涉及了“产品规划、数据分析、用户研究、需求分析、功能设计、项目管理、敏捷方法”等内容，而不是如传统的产品经理那样，去做已经有了产品之后需要做的诸如管理产品、推广和营销产品的事情。

互联网、软件行业的产品经理更重视产品功能本身的规划，需要“对市场发展趋势有敏锐的洞察力和创新意识及良好的分析、研判能力”，要能不断改进产品，要“深入了解业务，挖掘用户的多种需求，不断推出有竞争力的产品”，“制定所负责产品线的发展蓝图和实施路线图”。

IT行业产品特点及产品经理要求：

1、互联网、软件产品多为虚拟物品，公司相对而言显得较“轻”，不管是团队，还是成本花费，都更加集中在产品研发
的过程中。
2、IT行业主要生产虚拟产品。虚拟物品的复制成本极低，所以重点资源会投入在产品本身，较少考虑实体经济里供应链上下游的事情。于是，对产品经理来说，需求分析、设计的细节尤为重要。一个细节的改进就可能增加成千上万的用户。
3、同时，虚拟物品的研发周期较短，于是产品经理也经常兼顾项目管理，这样自己可以在项目完成度和产品质量之间做平衡，对产品无疑也是一件好事。

4、互联网产品的盈利模式较特殊，大部分为免费产品。由于互联网、软件产品面对终端用户，而且通常是面对海量的用户，用户数多了，自然就能盈利。所以，互联网、软件行业的产品经理会更重视用户研究、数据分析等工作，要“负责用户研究，把握用户需求，实现用户需求”，而盈利则交给另外的团队负责。

5、互联网或软件产品大多免费且雷同产品多，因此容易被替换。因此产品经理更重视用户体验，相应的，出现了很多产品经理会涉及的工作内容，如交互设计、视觉设计、文案设计等。

（8.27更新）
1.3入行问题
这一部分介绍给我的感觉是，产品经理的招聘广告听起来给人一种这个职位能让你得到能力的提升，但是其实实际上可能也有很大的工作量。因为公司产品经理的职责界定还不太明确。一般说要承受压力，是因为有可能会为团队的问题承担责任。沟通良好，产品经理要与多方沟通，这个很有必要。
文中提到一句话让我印象很深刻：你说自己喜欢产品，到底是喜欢做用户，还是喜欢做产品经理？
我仔细想了想，我虽然有意往产品这方面发展，但现在可能更喜欢玩应用。我现在的素养可能离产品经理还有一段距离。我应该尝试着用产品经理的视角去看待应用乃至周围一切可以称之为产品的东西。
想做产品经理，可以从“需求分析师”这个职位切入，在这个过程中培养商业的感觉。也可以从项目经理切入，多数产品经理都要带项目，从项目经理切入更有优势。
这章最后介绍了一个办法——研究几十家公司的产品经理招聘广告。把研究结果做成一份漂亮的调研报告，而后去应聘产品经理。这点我目前还不是很理解。等过些时日参透了会再回来和大家分享。

（9.7更新）
第二章：一个需求的奋斗史
缩略图很精简：



这一章仅仅局限于有一堆需求的时候应该“做哪些”、“做多少”的问题。
做产品首先要进行需求采集。“用户是需求之源”，我们要拥有“以用户为中心的思想”。但是用户提出的需求很多，产品经理需要通过需求分析计算出需求的“性价比”筛选出合适的需求。

（看到书中写到第三章有关于产品需求文档、用例文档怎么书写我很想翻过去看，但是做事要循序渐进，忍着先。）
1、用户研究，或者说需求采集的过程，都会有如下几步：明确目标、选择采集方法、制定采集计划、执行采集、资料整理，然后进入下一步的需求分析阶段。

2、采集方法主要有：



2.1用户访谈。
作者的意见是用户访谈经常用在新产品方向的预研工作中，或者通过数据分析发现现象以后，去探索现象背后的原因。
我看了用户访谈中会出现的问题，首先作为一个用户，我可以理解这些出现的问题。但是看完文章后，试想如果作为一个产品经理，自然要去解决这些问题。
首先，用户说和做不一致。
解决方案：其一、让用户同时说和做——成本高
其二：自行区分——“一般来说，诸如“我做了什么，步骤如何，碰到了什么问题”这类事实的可信度更高一些，而“我觉得、我认为”这类的观点，则需要带着大大的问号去听。”
第二，样本少，以偏概全的问题。
方案其一、在访谈报告中标明会引起偏差的因素；其二、增量访谈。
关於这点，我觉得现在网络调查可能就会好很多，首先面向群体较广泛，其次作为互联网或软件行业，通过网络调查得到的用户意见多是使用过产品的用户提出的，比较可靠。当然网络调查也存在“说和做不一致”的可能性，要注意区分或者采取别的方式辅助。
第三，用户过于强势，把我们往沟里带。

方案：时刻牢记访谈的目的。这个我估计需要锻炼和经验。
第四，我们过于强势，把用户往沟里带。这与第三点有点类似。同样要牢记访谈的目的，并且管好自己的嘴。

在此也贴上作者给出的《软件观念革命：交互设计精髓》的注意点：
► 避免一组固定的问题：固定的问题会让被访者产生被审问的感觉，我们应该准

备好问题清单，但清单只起一个引导作用，并不用照着读。

► 首先关注目标，任务其次：比用户行为更重要的是行为背后的原因，多问问用

户为什么这么做。

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

片面。

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

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

► 避免诱导性的问题：典型的诱导问题是“如果有××功能，你会使用么？”一般来说用户会给出毫无意义的肯定答复。

2.2调查问卷
调查问卷相对于用户访谈略显封闭，适合大用户量的信息收集，但不够深入，一般只能获得某些明确问题的答案。但两者之间也是有联系的，经常需要通过前者的开放式问题，为后者收集具体的封闭式问题。
调查问卷的注意点：1、时间控制在10分钟以内
2、顺序安排：开篇一般放一些简单的不需要思考的问题；很想知道的内容，需要思考的，较敏感的问题一般放在中间；而有关被访者个人信息的题目一般放在问卷的最后，以免应答者在回答这些问题时有所顾忌，进而影响其他答案。
调查问卷能够消除有群体讨论性质的方法的弊端。要知道用户中“沉默与骑墙的总是大多数”。但它也会出现相应的问题：
第一，样本的偏差，即样本与想了解的目标用户群体出现偏差。这有可能是因为成本或资源有限等等。

方案其一：在报告中标明潜在的筛选条件，让读者知道数据获得的方法和来源；其二：把目标群体的特征也定义成一系列问题，放入问卷中，筛选出接近目标群体的子集。
第二，样本过少的问题。文中说这是新手常犯的错误，但是我觉得这其实应该算是一个常识，只有数量基值够大，结果才有随机性和代表性。

第三，问卷内容的细节问题。

首先，问题表述应无引导性。这一点我觉得我要注意，细节决定成败嘛。

其次，答案的顺序会影响调查者的选择。这个倒挺新鲜。文中提到：“有研究表明，对陈述性选项被调查者趋向于选第一个或最后一个答案，特别是第一个答案；而对一组数字，如价格和打分，则趋向于取中间位置。”
要解决这些问题，作者建议可以准备几种形式的问卷，每种形式的问卷选项排列的顺序都不同。
重要的问卷为了避免上述问题，还有个通用的办法就是先进行小范围的试答，根据反馈修改后，再大面积投放，这和互联网产品的灰度发布有着同样的

理念。（灰度发布听着类似游戏内测，它是互联网产品发布上线的一种常用形式，先让少量用户看到新产品，利用他们的反馈进行修正，逐步把新产品展现在所有用户眼前。）

2.3可用性测试
首先了解定义：可用性测试是指通过让实际用户使用产品或原型方法来发现界面设计中的可用性问题，通常只能做少数几个用户的测试，看他们怎么做，属于典型的定性研究。
其步骤包括：1、招募测试用户——需要代表真实用户。
2、准备测试任务——事先准备，应当是一些实际使用中的典型任务。
3、测试过程——组织者要把发现的问题记录下来。
4、测试结束——询问用户看法
5、研究分析——分析记录并产出一份产品的可用性问题列表，并对问题的严重程度进行分级，使得我们可以根据项目进度来选择哪些优先处理。
常见问题与对策：
1、可用性测试做的太晚，发现问题也于事无补。
对策：可用性测试在产品的各个阶段都可以做。不同阶段不同做法。
2、总觉得可用性测试很专业，所以干脆不做。
作者认为做总比不做要好，哪怕只做少量用户，减少资源，都可以发现不少问题。
3、明确是测试产品，而不是测试用户。这点貌似主要是为了减轻用户压力。
4、测试过程中，组织者该做的和不该做的。

首先要求用户在测试过程中说出思考过程。
其次不要有任何的引导和暗示。这里有句话让我印象挺深刻的：“一切的错都是产品和我们的错，用户绝对没有错。”用户至上。
最后提出，邀请时要说明会对用户付出时间补偿，结束后送个小礼物，一方面以示感谢，另一方面可以建立长期友好关系。
优秀的产品都是靠着不断的升级、优化、改版才逐渐获得认可的。对于改版，除了“可用性测试”要在足够早的时候做以外，发布后也是有一些方法改进的。
比如先从部分次级页面改起；再如新旧版本并存一段时间，并允许用户自由选择；三如小面积试验，选择一小批测试用户放出新版本，监测效果，做用户调研；四如傍上一个用户已经习惯的风格。
2.4数据分析
靠数据说话是无可反驳的。
常见的数据来源有用户使用产品的日志、客户管理系统里的信息、网页访问情况的统计信息等。

数据分析的方法，简单的可以用Excel，复杂一点有统计软件和数据库软件，甚至可以自己写程序解决（哎呀程序猿的优势啊）。
数据分析只能发现现象和问题，关键在于你如何解读数据，找出原因。因此数据分析后常常会进行用户访谈，了解用户的心理。
数据分析的常见问题与对策：
1、过于学术
对策：注重性价比（我觉得就是要切合实际，可行）
2、误读数据
对策：尽量不要“为了迎合一个观点而去找数据”，减少利益牵扯。
这点说的容易，真正做到还是很难的。作为应试教育的“产品”
3、平时不烧香临时抱佛脚，这点是说在你想要进行数据分析时却发现没有数据可用
对策：在产品设计时就把数据分析的需求加进去，方便产品的可持续发展。
数据分析如何转化为商业价值？
在对产品足够熟悉的基础上，先做出方向性的假设，再提取相应的数据并分析，得到一些现象，最好是之前没发现的现象，然后尝试解释，接下来做用户调研修正解释，最终指导产品发展方向。