写在前面的话：

我知道我这样的笔记方法是很笨拙的，一个好的读书笔记应该是总结归纳，甚至还包括分析的。

之所以这样费力地做这件事情，是我认为，每一个想要学习产品知识的朋友，都需要一本书来建构他的知识体系。或者，说小一点，是让他对产品有一个全面的认识。

我觉得这本书，对我起到了这样的作用，他可能写的不好，但是仅仅这个目录，就抵过很多书了。

在学习完这本书之后，再去关注需求、体验、运营等某个细分领域的专业书籍，这是一个非常有必要的步骤。

所以对于这本25万多字的书，我直接引用了出来近两万，因为，我就是这么地任性嘛~

Prototype篇

1，职业选择

1.1，互联网产品经理：

负责对现有互联网产品进行管理和营销的人员，也负责开发新产品。

1.2，产品经理的工作：

按照时间跨度可以划分为战略性工作、阶段性工作和日常性工作。

a，战略性工作：为产品建立长期的战略布局；发现新产品的机会；为产品的演变、增强和引进提供建议。

b，阶段性工作：参加新产品的开发；参与年度商业计划的制定；利用公司内部、外部资源开展营销活动；

预测竞争对手的行动并制定应对方案；更新产品并进行相应的用户教育；降低成本；重新规划产品线。

c，日常性工作：收集分析竞争情报；协调开发、运营、客服、销售等资源以保证产品正常运作；执行商业计划。

1.3，产品经理在团队中的角色：

产品经理应该是团队其他成员的补集。填补团队中所有人的空白，并负责团队成员之间的沟通。要有万金油的准备和决心，什么都要懂一些，用户、同事、老板都需要你去主动沟通。

产品经理需要在工作中展示自己在战略规划、产品策划、竞争情报、协调润滑等方面的专业性，在工作中与团队伙伴建立信任关系，同事也需要在这个过程中了解团队伙伴的工作能力，在互相了解的基础上划定彼此工作的分界线。

产品经理是自己所负责产品的利益相关者，其个人利益与长期利益与产品的成败息息相关，这使得产品经理需要关注一切能左右产品成败的因素，并且尽力去填充产品所需要的一切工作。

产品经理先去了解用户的需求，接着和研发同事商量解决方案，再与老板周旋争取资源，然后把用户需求翻译成研发人员容易理解的研发设计文档，最终把产品做出来给用户使用。

2，职业发展

2.1，产品与产品经理：

产品经理的职业发展轨迹与其所负责的产品的发展轨迹息息相关。

产品经理负责的范围越是具体，这个产品就越容易在变化中消亡，产品经理就要更换工作内容甚至工作岗位。

如果产品能在竞争中获胜，或者及时地进化到最新的形态，把握住新的机会，产品经理就有机会负责更复杂、对应变能力要求更高的产品或者负责多款产品，进而可以更从容地拥抱变革。

2.2，个人能力方面：

观察能力和推理能力

产品工作中需要灵感，需要对生活保持敏锐的观察，有效地捕捉生活中有价值的点点滴滴，将这些细节积累为“阅历”和“经验”，为灵感制造一片土壤。在观察的时候，不光要用眼睛和耳朵，更要用脑子，做到知其然知其所以然，才能形成有效的记忆。

归纳推理，从个别性知识推出一般性结论，反过来，记忆一般性结论可以帮助我们去识别更多的个别性知识。

怀疑一切的精神，对于提升观察能力非常有益。

观察和细节是密不可分的，没有观察到细节的观察不能称之为观察的。

西方有句谚语：魔鬼在细节中（the devil is in the details）。

面试产品经理的时候，通常会考察对细节的关注度。

一方面可以确认他是否有真实的经验，另一方面可以判断他的观察能力，

是否认为细节是重要的，并且在观察中捕获了所有关键的细节。

推理，带着问题去思考。

想了很久都没有办法串起来的个别性知识终于碰到了可以解释它们的一般性结论，

或者，没有合适案例进行展现的一般性结论终于碰到了恰到好处的个别性知识。

警惕非此即彼的陷阱，务必要多运用开放和融合的思维方式。

在面对各种难题的时候，第一反应不应该是做简单的选择，而是要跳出来，想想如何创造用户的价值。

对于产品经理而言，自己负责的产品的表现就是自己的履历。

但是不应该仅限于此，产品经理应该以创造用户价值为使命。

Alpha篇

1，起点：概念

1.1，产品创作的六个步骤

概念，创作什么样的用户价值，满足用户哪方面的需求。

形式，对应产品形态。

风格，产品整体的风格。

结构，人机交互设计。

工艺，技术研发和项目管理。

外观，图形用户界面设计。

（确定产品概念是要确定它“满足了哪方面的需求”，而不是确定的说“做个SNS”，从形态开始是很多产品失败的原因。形式是概念的上层建筑，没有搞清楚概念就直接从形式开始，会导致产品背离用户价值，没有用户愿意使用）

不要发明轮子

a，没有几个人可以发明出来；b，没有历史性的价值。

原创概念的获取

a，受现有产品的启发。

b，出于自身的需求或者捕捉到了其他人的需求，提出概念。

c，预见用户需求的变化，提出一个超前的原创概念。

2，概念2.0

2.1，Web2.0

服务，而不是打包的软件，技术框架具有高成本效益的可伸缩性。

控制独特的、难以再造的数据源，并且用户越多内容越丰富。

把用户当作共同开发者来信任。

借力于群体智慧。

通过用户的自助服务来发挥长尾的力量。

超越单一设备层次的软件。

轻量级的用户界面、开发模式和商业模式。

2.2，蓝海战略

同时追求“差异化”和“低成本”，从而实现价值创新。

其中Web2.0中的做服务、控制独特的数据源、适用于更多的设备可以归为“差异化”，

把用户作为共同开发者、借力于群体智慧、自助服务、轻量化可以归为“低成本”。

蓝海战略成功与否取决于一款产品能不能在它的蓝海时段内达到理想的用户规模。

（为了更为有效地利用蓝海时段，控制蓝海时段的开启时间是非常重要的。）

2.3，理解低成本

Web2.0强调低成本，但是这个低成本是从产品整个生命周期来看的，如果只看研发成本，运用2.0思路的产品研发成本可能更高。（个人理解为将运营成本放置到研发中，就像自动化生产成本低，但前期投入大）

UGC与举报制度，及时对“破窗”进行修补。

2.0中用户的活动会更加频繁（产生的数据更多，造成的影响更大），释放集体智慧的同时，也要想办法去驾驭集体智慧。

在中国，频繁出现的“破窗”更意味着频繁地被监管。

3，概念的过滤（一个idea的筛选）

3.1，概念的原始出处是哪里，全球最佳实践是什么？（What）

一个概念经过很多次的时间，可能已经很复杂很庞大，它主要为目标用户带来什么已经难以辨识。如果能找到概念的源头，就比较容易看清这个概念的核心是什么。

寻找全球最佳实践是因为国内的最佳实践可能是对全球最佳实践做了裁剪和变形（其中有本地化的成分），了解全球范围的最佳实践可以令产品的起点更高。

3.2，哪些用户会从中受益，他们是谁？（Who）

产品首先应该从满足用户需求出发，在判断一个产品概念面向的用户时，越具体越好，因为真正使用产品的都是真人，不是抽象出来的“用户”，他们有性别、年龄、教育程度、收入等具体属性，他们有真实的需求，有真实的场景。可用“朋友测试法”来判断，我身边的朋友会不会成为用户，他为什么要使用这款产品。（用户访谈）

其次，也需要了解这类用户的规模，以便预测自己的产品在整个市场中的地位。（概念的普及率）

最后，某类产品的普及率高并不代表立即去做这类产品就一定能够获得很多用户，还需要关注这类产品的集中度。比如即时通讯，集中度非常高，在没有实现即时通讯软件之间的互联互通之前，马太效应决定了哪一家用户数多，哪一家的吸引力就最大，一个新的即时通信产品很难抢到增量用户，也很难转化存量用户；而网络论坛这个细分市场的集中度就比较低，新产品容易生存。

3.3，这个概念为它的目标用户带来什么？

如果一句话解释不清楚这个问题，那么这个概念就有大问题，用户没有那么多耐心去理解你的概念。

不仅如此，还需要用“真实世界投射法”来验证一下。真实世界投射法是指将互联网上的概念投射到真是世界中比较普遍的事物上，通过已经被验证过的真实世界案例或规则来推断这个互联网产品概念的可行性。

3.4，进入的壁垒是否过高或过低？

如果壁垒过高，那做到的概率就很小；如果壁垒很低，人人都可以做，那你的蓝海时间就会非常短，可能难以获得足够支撑长期发展的用户规模。在分析进入壁垒的时候需要考虑三个因素：技术、成本和对特有资源的占有。

（考虑成本时，不能只考虑研发成本，把产品做出来只是第一步，还需要预测产品未来的发展规模，进而预测服务器、机架与带宽、人力、营销等方方面面的成本。所以，有时候一个概念看上去很美，但它背后需要的成本却是无底洞，使得这个概念根本无法成立。）

3.5，有无商业模式？

参考行业数据

用发展的眼光看待商业模式：在分析一款产品的商业模式时，不能只盯它的现在，还要考虑在互联网产业中的地位变化趋势，即是否具有成长性。

面向个人收费：体验经济。（体验和服务的区别，是否能向西罗列出提供的服务内容）

“制造业——服务业——体验业”的划分标准相对于“农业——工业——服务业”，一个巨大的区别是把划分视角转移到了用户。

面向企业收费：广告。

互联网广告分为，搜索广告、展示广告、分类广告、引导广告、电子邮件广告。

3.6，能否成为平台或现金牛，在公司的战略布局中处于什么位置？

平台——能通过自身的资源优势拉动其他产品的产品。

导入用户数=平台产品的活跃用户数X转换率X拉动时长

用户数：

衡量一款产品的平台性质时，它的用户数是第一个关键指标。

而一款产品的用户规模是否会变得很大，要看这款产品有没有满足用户的强需求和频发需求。

强需求和频发可以从用户上网时间的分配比例来看。比如排在前面的有，即时通讯、社交、娱乐、电子邮件等。

用户在使用一款产品的时候是否愿意跳转到其他产品尝试一下，运营商是否希望将用户转移到其他产品，也是判断一款产品能否成为平台产品的重要因素。

转换率：

平台要对用户产生影响，让他们去使用被拉动的产品，给予被拉动产品一定的展示面积和展示时间是非常重要的。

如果平台提供账号体系，用户到达被拉动产品之后可以直接登录，那就会大幅提高转换率，有很多用户都是在注册这个环节流失的。

除此之外，独特的内容、支付渠道等方面的资源优势，也是影响转换率的因素。

现金牛，利润率超高的产品。

一般而言，平台产品和现金牛产品作为公司的用户支柱和收入支柱，公司会对其进行长期稳定的投入，老板也会非常重视。但是在一款默默无闻的产品里，你产品经理可以走完整个流程，甚至获得平台/现金牛产品无法提供的自由度。而且，在做好本职工作的基础上，想想自己手头的产品是否有可能转换为平台或现金牛，未来可期。

4，获得投资（描述预期和产品经理个人能力的匹配）

概念在经过了多层过滤之后，我们会发现真正有用户价值、有可行性、有商业模式的概念并不多。接下来，我们带着杀出重围的概念进入执行的第二步——找到实现这个概念所需的投资。

4.1，你想做的产品有多大

如果是创业融资路线，首先确定自己的产品是不是能够使自己成为下一个腾讯、百度、阿里巴巴，年利润能不能达到1亿美元，有了坚定的信心和合理的发展路线，才能吸引天使投资和风险投资。

如果是公司内部向老板要求投资，老板考虑的并不全是投资回报率的问题，除了看一个产品能不能做大，老板还会关心自己的公司在整个市场中的产品线布局，如何更好地满足用户需求，如何回报社会等问题。在一家有一定规模的公司里，通常是愿意给不同类型的产品提供机会的，前提是它们能够契合老板的某个关注点。

向老板进行产品建议的时候，首先要符合公司的发展目标和资源优势。

如果你所在的公司产品线很长，那么增加新的产品就会越来越困难，因为已经没有多少空白可以去填补了。这个时候，清晰地了解公司的业务布局就显得非常重要，如果要建立独立的产品，它一定要处于业务布局中的空白地带，而不是某个现有产品增加一项新的功能就可以替代的。

4.2，你是否具备产品经理的职业修养？

投资者主要使用排除法来提升投资回报率，排除掉不靠谱的事情，排除掉不靠谱的人，剩下的公司没有明显的失败基因，成功与否就看它们的发展了。在公司内部，得益于公司已经有的资源和环境，新产品与公司平台资源相匹配的话成功的几率会比创业大很多。

产品经理的职业修养：

诚实；有所长有所短；不会去浪费时间重新发明轮子；能够在行进中不断开火，而不是纸上谈兵；

毫无怨言地主动填充团队中空白的角色；愿意倾听用户的意见和其他人善意的建议；能够团结和引领团队。

对你的用户进行有诚意的示范

社会学中有个概念叫临界量，它是指在一个社会系统中，某件事情达到了一定动量，这个动量可以让这件事情自我维持并推动它进一步成长。

很多互联网产品的真正推动力，其实正是它背后的有某种行为特征或信仰的用户群。这些产品发布前期的最重要工作就是要让它们的核心用户群达到临界量，这样才能把产品推入轨道，而使核心用户群达到临界量的常用方法，就是“灌水”。对种子用户作示范，以及一些引导性的信息。

有所长有所短

声称自己各种精通的产品经理，要么这个人不诚实，他明明知道自己不精通，却故意号称精通；要么这个人并不了解行业水平，真的以为自己很精通，这两个原因都挺可怕。一个有特长的产品经理，是勇于承认自己不懂Flash、SQL的。

在行进中不断开火

不要花太多时间在思考上面，导致决策太慢，想不清楚的问题可以先摸索一下，投资者和用户的耐心是有限的。

通过一些技巧可以最大限度地降低行动中开火的负面效果。

概念测试：焦点小组。

交互设计测试，可用性测试，也就是改善产品易用性的一系列方法。

（1）寻找一些有代表性的、符合产品潜在用户条件的用户。

（2）请这些具有代表性的用户在产品或产品原型上完成一些任务。

（3）使用体验观察室观察他们的操作，他们在哪里成功了，在哪里卡住了，不要发言，倾听他们的意见。在这个步骤中注意，可用性测试的目的是发现这类问题从而对产品进行改进，而不是教会参加测试的用户如何使用产品。

A/B测试：通过一些设置，将来访者分流到A、B两个测试环境，版本A维持现有的方案不变，版本B是我们做过一些调整后的方案，然后分析哪个方案更易于实现预定目标。

“行进中开火”是可以通过练习养成习惯的，当我了解他的好处的并且知道了一些低风险尝试的方法之后，我就内心接受了他。“想”是不够的，一定要动手去做，产品都是在做的过程中逐步被晚上的，我们需要在能开始测试的时候就尽快开始测试。

倾听他人建议

产品经理可以有自己的主张，可以非常坚持，但是不可以只活在自己的世界里不在乎用户的声音和身边的建议。

4.3，你是否对这款产品全身心的投入？

产品经理对产品的投资，首先反映在产品概念的过滤中，产品经理需要投入时间弄清楚自己到底要做什么产品。在有着严格的项目评审机制的大公司里，启动一款产品之前需要将商业需求文档（BRD）提供给公司高层进行评估，一些公司可能还会同时要求提供市场需求文档（MRD）和产品需求文档（PRD），这一系列的文档将会呈现出产品经理的先期投入。在一些不太严格的公司中，只需要向领导讲清楚为什么要做这款产品，达成共识就可以了。建议使用PPT进行面对面的演示。风投一般会要求创业公司提供商业计划书，创业公司需要讲清楚自己能不能做大，发展轨迹是怎样的，还有目前的投资结构、财务预测等。

5，把概念变成图纸（从需求到需求文档）

公司将产品研发过程放到一个项目中进行管理。项目管理是为了完成某一既定目标所进行的一次性努力，产品研发项目就是要在指定的时间段和预算内达到产品成功发布的目标所进行的项目。要推算一个概念变成真正的产品需要多少时间和预算，首先要把这个概念落实为图纸，然后邀请相关领域的专业人士（项目经理和研发经理）根据图纸中的细节一起进行时间和预算上的评估。项目启动之后，图纸就变成了所有项目成员的施工指导和沟通基础，对项目的目标起着决定性的引导作用。

5.1，以网站为例，图纸一般包括：网站结构图、网页蓝图和网页描述图。

网页结构图：描述整个网站的结构，确定网站的模块划分及网页个数。

描述方式包括按功能模块划分和用户角色划分。

Tips:注意使用MECE原则（“相互独立，完全穷尽”），分类清晰并且穷尽，可以降低理解门槛。

颗粒度问题：如果你的团队采用了敏捷开发的方式工作，那么你需要把项目的颗粒度分得更细一些，以便每天都能把自己已经完成的工作叠加到可运行的网站上。细小的颗粒度可以让团队和用户更快地看到结果，提升大家的信心，也能提高工作效率。（消灭拖延提升效率的方法，就是把任务分解成连续的、在能力范围之内的小任务。）

面向对象的思想进行网站结构的分析。把网站中一些基础的事务抽象成对象，只提供一些访问他们的方法，而且一个明显的好处是，这样做更容易达到用户任务的闭环。

（比如将登陆状态抽象为一个对象，那么这个对象的方法就有登陆、退出）

搞清楚用户闭环之后，需要去判断每个环节的背后是否都有用户真实的需求，从而验证任务重的环节是否都是合理的、必要的。

如果在设计中丢失一些环节，到了产品发布之后才发现，那会造成相当的被动，反过来，如果多出一些环节，则会造成研发资源的浪费，甚至会让用户迷惑。

是否必要思考之后，还要考虑它到底需要多大的成本。

其中包括，研发成本和非研发成本。而非研发成本往往占了成本的80%，甚至以上。它包括但不仅限于推广和培养用户习惯，以及等等。

网页蓝图：描述一个网页中所需要包含的基础元素及其在这个页面中的布局，它会由图形界面设计师最终完善惩美观的网页设计图。（图片越抽象，读者理解起来就有更大的发挥空间，原型设计应注意这点，不要限制UI的发挥）

网页描述表：包含一个网页中所需要展示的元素以及背后的逻辑，并不包换这些元素在页面中的布局。

这个表的作用是，将产品经理的工作和交互设计师的工作分开，产品经理关注要向用户传递什么信息，交互设计师关注如何更好地将信息传递给用户；向研发团队说明信息背后的逻辑，方便他们实现。

5.2，图纸（设计文档）的用户和书写规范

产品设计文档是伴随着产品整个生命周期的连接概念与执行的重要工具，它帮助产品团队与研发团队和高层领导达成共识，进而明确研发计划并指导整个研发过程。

设计文档的用户

首先是产品团队，一份产品设计文档在走出产品部门之前，必须在产品内部达成共识；然后是研发团队，由他们确认其可执行性和研发成本；接下来，它会和研发部门给出的评估意见合并在一起交给公司的领导，领导确认项目周期，拍板给资源；项目启动之后，设计文档会回到研发团队指导具体的研发工作，同时也会进入测试团队，帮助测试团队制定测试计划；有时候，公司外部的合作伙伴也需要查看产品设计文档，以便完成一些合作项目。

设计文档的书写规范：

（1）保持简短

“代码越少，BUG就会越少”。对于产品团队来说，简短的文档更容易撰写。

技巧：将需求与需求之外的东西分开，保持需求的简短，把需求之外的东西放到附录、图表和FAQ中。

（2）消灭错误

错误的文档会浪费研发团队大量的时间，导致产品团队在研发面前抬不起头。

错误有很多种，产品逻辑层面的错误，多个需求相互矛盾的错误，还有错别字层面的低级错误。

在撰写需求文档的时候，产品团队应对产品逻辑进行充分的讨论和测试。

避免使用“复制黏贴”在不同位置解释同一个事情，会埋下更新不同步的祸根。（用链接的方式确保一份说明）

（3）别对他人的工作指手画脚

如果你碰巧是一个技术专家，私下和研发沟通即可。别把应该写进技术设计文档中的内容写在产品设计文档中。

（4）用适当的表述方式展现需求

如果叙述性的文字说不清楚，而用表格比较容易，那就使用表格。

选取适当的方式展现特定的信息，使信息能够快速有效地被受众理解。

（5）使用肯定的语言

产品设计文档是最终提交给研发团队的文档，含糊不清的东西应该已经全部被消灭了，最终提交的内容都是确切的，可被执行的。

强调一点：沟通！！！

产品设计文档是产品经理开展工作的必要手段，可以帮助产品团队归档所有的思路和细节，以减少后续工作中的重复沟通，但是，千万不要过于关注文档而忽视了沟通。产品设计文档是在产品经理与交互设计师和相关的研发同事（甚至包括测试同事）充分沟通之后，大家都明白为什么要做和怎么做之后才开始撰写的。文档的模板不重要，大家对文档所描写的产品特性都已经很清楚，归档后大家能对照它开展工作，这才是关键。

6，关注用户体验

用户体验影响产品口碑，口碑影响产品成败，产品成败影响产品经理的利益。

用户体验三要素：别让我等，别让我想，别让我烦。

6.1，别让我等，用户耐心有限

绝对速度、响应速度、稳定性问题。

人对连续动画的感知大概是0.065秒，超过这个时间他就会觉得在这里进行操作太浪费时间。

调查显示：用户倾向于认为打开速度较快的网站质量更好、更可信，也更有趣。

绝对速度一定要及格，在及格的基础上越快越好。

以网站速度为例：

减少HTTP请求数：减少不必要的请求、合并文件、优化缓存。

使用内容分发网络：设定拥有最少网络跳数和响应速度最快的服务器会被选定。

压缩网页元素：元素越小，下载所需的时间就越短。

把样式放在网页的HEAD部分：把CSS放置到HEAD部分可以提高界面加载速度。

把脚本文件放在网页底部：在JS下载完毕之前，后面的元素的顺序显示将被阻塞。

把样式表和脚本放在外部文件中：减少文件数，从而减少HTTP请求数。

减少DNS查询次数、缓存Ajax等。

除了绝对速度，还有响应速度。对于用户的操作，不管返回的结果的绝对速度时快还是慢，都要及时响应。

响应问题之所以普遍存在，因为大家往往把响应问题归结为性能问题。一个按钮点击之后没有响应，测试团队、产品经理和研发团队首先想到的都系统的执行速度太慢，认为性能问题解决了，响应问题也就不是问题了。但是，更多的情况下，性能的提升无法满足用户对响应速度的需求。所以我们应该单独对待响应问题，将它与性能问题分开看。保证一款产品的响应，只完成用户任务的程序模块是不够的，还需要有专门负责响应用户操作的程序模块，而且这些响应模块应该拥有最高的优先级别。

Tips:如果牺牲数据的完整性，可以换取更好的速度和响应，同时降低服务器的开销。那么，如果完整性的牺牲处于可容忍的范围之内，用完整性来换取速度、响应和服务器开销则是最好的选择。

稳定性问题，危机管理。加强信息的披露和与用户的沟通，争取用户的谅解和支持。

6.2，别让我想

懒惰是人性的重要组成部分，用户通常不喜欢被强迫进行思考或学习，如果你的产品不是唯一的选择，那么用户很可能因为不会用而放弃使用。

A.包装好你的网站

LOGO（标示）

可以让用户轻松知道你是谁，他浏览到网站中的任何一个网页，都能知道这是你在提供服务。

是什么

单靠LOGO不能有效告诉用户每个模块是什么，还需要提供更具体的信息告诉用户当前这个模块是什么。

带来什么好处

简单明了地告诉用户你能带来什么好处，通常是一句slogan，点名独特卖点，激发用户尝试使用的兴趣。

B.关注用户及其任务，给予明确的指引

在做产品的时候，由于投入了太多精力去做设计、研发，有时候会发生关注产品本身多于关注用户的现象。

围绕用户及其任务进行设计，给予用户醒目、清晰的指引，以便帮助他们尽快地进入下一步，最终完成任务。

指引信息首先要醒目，让用户能够很容易地扫描到。

指引信息在产品界面中所处的位置、它的尺寸和它与周围环境的反差是醒目与否的决定因素。

目前一个流行的做法是用不透明或者半透明的边框将提示信息与其他噪声信息隔离开。

其次指引信息要清晰，被扫描之后能够被用户有效理解，进而被执行。

尽量使用简单有力的暗示性措辞，例如“立即购买”、“马上加入”。

C.尽可能降低用户的学习成本

打开即会使用产品可以减少用户的思考。一个好的产品各个功能都要符合自解释原则，尽量通过图形和文字让用户能根据他以前的常识和经验就能上手，实在做不到就用注释或鼠标悬停提示进行说明，或者将相应的帮助信息放在这个功能旁边让用户可以顺手查看。

中国式产品的精华所在——傻瓜到只有一次操作。

递进显示——只显示与用户当前任务相关的功能，隐藏其他功能。

越复杂的东西越难被理解、学习和记忆，所以要牢记奥卡姆剃刀定律——如无必要，勿增实体。

化繁为简，有些装置现阶段是必须的，但是可以通过一些手段让它们自动运行起来，从而让用户感觉不到它们存在。

数据的可视化，用户看不懂数据，也不关心数据。

6.3，别让我烦

用户都是喜欢偷懒的，如果你的网站操作效率很低，会让用户烦躁，进而导致不好的口碑。

优化操作步骤

完成任务的难度与其所需步骤平方成正比，那么，缩短完成路径就是帮用户偷懒。

一次又一次地进行重复操作令人厌烦，合并重复操作可以提高用户效率。

优化指点设备运动轨迹和眼球运动轨迹等细节

菲兹定律，使用指点设备到达一个目标的时间与连个因素有关。

一个是设备当前位置和目标位置的距离，距离越短，时间越短。其次是目标的面积，面积越大，时间越短。

将用户的视线保持在一条直线上（通常用竖线），是最常见的优化手段。

温柔的提示

弹出对话框的做法会降低效率，打断用户当前的任务。换一种没有中断感的提示。

避免骚扰

避免强塞一些用户不想要的信息或者任务。

除了功能性的骚扰，还有视觉和听觉的骚扰，例如跑马灯和背景音乐。

避免用户出错

丰田的“Poka-yoke”（防差错）理念，通过预防、校正和警告等方式降低和消除人工劳动中出现差错的可能性。

自动：自动完成任务，或者出现错误时自动校正。

隔离：通过区域划分，禁止用户进入危险区域。（或者将用户的注意力聚焦在有价值的内容上）

校验：利用形状、密码等进行校验，确保不会误操作。

顺序：将流程编号，依次执行。

指引：通过形状、颜色等对用户进行有效的指引，让他不需要停下来想就能知道接下来应该干什么，

警告：将不正常的情况通过文字、颜色、声音等媒介及时通知用户，提醒用户进行修正。

缓冲：利用各种方法避免差错带来的伤害。（例如，自动保存功能）

避免给用户造成压力

用户喜欢消灭数字，但是一个大的数字会给用户带来压力，因为消灭它不再是一件轻松的事情，用户可能迫于压力而任由这个数字继续增长下去而永远不再阅读这个Feed。（例如，将3132显示为1000+等）

7，管理项目

7.1，项目经理和产品经理的关系

产品经理不一定具备项目管理经验，他考虑的更多的是为什么要做和做成什么样，对于如何把产品构思落地做好，很可能不是专家。

项目经理是利用有限的资源在期限内把事情做成专家，他只对项目负责。他负责项目的计划、执行和验收，并不对整款产品负责。

项目目标，产品经理提需求和确定的权力，

项目管理，项目经理说了算，产品经理在项目过程中提出改动需要项目经理的认可。

7.2，实现一款产品需要的资源

表现层

负责将信息展现给用户，然后负责和用户进行交互，用户的操作都是表现层应予以响应，然后通过网络传输给服务器端的业务逻辑层进行处理。

业务逻辑层

体现用户的任务以及任务流程的地方，在经过业务处理之后，他指挥表现层进行表现，也指挥数据持久层对数据进行CRUD（建立、读取、更新、删除）操作。

数据持久层

负责保存业务数据，用户创建账号之后要把他的账号和密码保存好，下次回来的时候才能顺利登陆。

辅助系统

负责实现一些相对对立的、低耦合度的功能。

实现一款产品的流程：

首先需要产品经理提出产品概念，梳理好用户的任务。

设计团队中的交互设计师会和产品经理一起设计表现层的信息展现和交互；

图形用户界面设计师会为交互设计增加形状、色彩、质感等视觉元素，确定产品在表现层的最终展现。

研发团队中的系统架构师会根据产品经理的产品设计文档规划好业务逻辑层需要做的事情并确认要存储哪些数据，也会确定表现层、业务逻辑层、数据持久层和辅助系统都需要哪些技术，并且估算不同用户规模下需要的服务器数量和带宽；

研发同事会按照系统架构师的规划领取自己的研发任务，这些研发任务完成后会被组合好安装到服务器上。

测试团队通过测试确认产品是否符合产品设计文档，测试通过后通知产品经理进行最终的测试和体验。

这一切完成之后，产品就可以发布了。

项目经理的工作内容是明确项目目标，制定好项目计划，确保项目所需要的人力资源和服务器等资源到位，带领项目顺利地走完上述流程，实现项目目标，如果团队中没有专职的项目经理，那么一般由产品经理和研发经理扮演。

7.3，项目经理在管理项目的时候关注什么

对结果进行预期

项目是有期限的，项目经理的首先目标是把项目完成，并且尽可能在时间期限内完成。

项目经理能够预期和控制的，主要是对资源的评估，特别是团队成员的能力进行评估，就可以预期项目是否能完成。

让所有人上船

在项目成员到位的情况下，调动大家的工作意愿至关重要。

用胡萝卜带领大家上船，告诉他们船上或者彼岸有他们想要的东西，漂亮的履历，提升能力，改变世界。

投其所好，当大家都上了船，一起划桨离开了码头，那意味着每个人都做了真正的投入，只有同舟共济驶向彼岸。

把事情完成

项目会被细分为若干个子项目，将所有子项目完成，项目就完成了，关键的关键在于完成。

A.沟通问题

首先，项目经理在日常的沟通中发现大家经常出现语言不通的地方，然后对这些地方进行更精确的命名以减少歧义，并且在日后的沟通中不断强化。

B.理解问题

在经过沟通达成共识之后，确定好了执行方案，过了一段时间再去检查执行情况。防止由于大家知识结构不同所造成的执行方案理解偏差。因此，项目经理有必要监控执行的过程以实现控制执行效果和执行时间的目的。

C.需求变更

这种情况一般会引起两个问题，研发任务的调整导致项目周期变长，确认变更的过程本身就花费了太多时间。

在变更的时候，不要忘记更新网站结构图、网页蓝图和网页描述表这三份产品设计文档。

D.风险应对

对项目中的资源和实施环节，需要预先评估其风险，往最坏的方向去想，然后考虑如果发生了这样的情况，是否可以忍受，或者是否有办法补救。

E.承诺一致

对一些承诺总是无法兑现的同事，需要时刻检查项目进度并判断完成时间。

对项目进行可视化管理

Excel创建的甘特图（体现项目活动与持续时间的图标）

Tips：产品经理的万金油身份只是候补角色，如果已经有同事在响应的岗位上工作，千万不要越俎代庖。

在你无法独自完成整款产品，需要同事共同努力的时候，你会发现同事的工作结果与你的预期总会存在一定的偏差，这是因为每个人都是独立的个体，即便有各种精确的沟通手段，也无法做到心灵同步，甚至有时候你自己也不确定到底想要什么结果。产品经理需要真心地接受同时的工作结果并容忍其偏差，不能容忍意味着所有工作都将由你独立完成，然而你并不能负担。

8，检查与处理

8.1，PDCA框架

测试：PDCA框架可以帮助你实现产品的持续改进。

从公司视角来看，PDCA循环是从指定年度商业计划开始的。各个产品都做好自己的商业计划，确定发展目标和达到发展目标所需要的关键任务，计算自己所需的预算，公司将这些商业计划汇总，确定公司的收入和成本目标。商业计划制定完成之后，公司授予产品部门申请的资源（经费、人员名额等），产品部门开始按照计划执行所有的关键任务，执行结果通过周期性的《产品运营状况简报》呈现给老板。老板可以通过运营简报检查商业计划的执行情况，对于计划之外的情况给予及时的处理意见，指导产品部门进行下一步的工作。年度结束之后，公司按照产品部门达到的发展目标授予年终激励，进入新一年的PDCA循环。

PDCA的颗粒度还可以更细，比如确定概念，过滤就是一种对概念的检查。检查环节有两项重要工作：一时确认结果与计划是否符合，二是确认执行结果与应用环境是否相符。

频繁使用自己的产品是一名产品经理应该养成的职业习惯。频繁使用产品，可以感受到一些不容易觉察到的效率问题，以及其他一些可以改进的空间。

8.2，用户参与（CE）

借助群体智慧的用户参与，其主要方法有：

提供一个明显的反馈入口，将用户引导到反馈论坛发表他们的投诉和建议，并进行及时的回复和处理；

订阅产品关键字的搜索结果，了解官方反馈论坛之外的反馈，同样给予反馈和处理；

建立或加入核心用户群，第一时间获取他们的想法，也可以很方便地测试一些产品概念；

通过用户行为录像工具或跟用户回家的方法，追踪单个用户的使用行为，发现他的使用障碍在哪里，解决这些问题；

对流失用户进行回访，分析流失的原因，改进产品降低用户的流失率。

Tips:当我们去向用户了解使用产品中遇到的问题时，很容易带有一种保护自己工作成果的防御形态，这是CE的大忌，会阻止我们进行换位思考去考虑用户的痛苦，不能“切身”体会这些痛苦就会丧失改进产品的动力。

8.3，测试驱动研发（TDD）

TDD是一种敏捷开发的思想，既然所有功能点都需要测试，而且是反复测试，为什么不把测试工具提到最前面并自动化呢？TDD要求在写任何代码之前，先写好它的测试代码，以保证所有的功能点都被自动化测试所覆盖。

如果只是研发出了产品功能，但是对其测试不充分，这个功能就附带着测试债务，并且随着时间推移，测试债务会越隐藏越深，偿还成本会越来越高。TDD正是从一开始就解决测试债务的方法，当产品变得很庞大时，TDD依然可以快速有效地检测各个功能点，这对于没有运用TDD的产品来说是一项不可能完成的任务。

从研发驱动测试到测试驱动研发，是一个巨大的转变，其中涉及研发流程、测试人员的编程能力、研发平台对自动化测试的支持程度等环节，而且，在测试驱动研发出现之前，那么多研发驱动测试的产品也获得了成功，所有这些因素都影响了TDD的普及。

回到产品层面，检查应注意以下几点：

用户对产品的核心概念是否了解，是否接受？

图纸是否覆盖了核心概念？是否在核心概念之外设计了太多东西？

用户对图纸（虚拟功能、虚拟体验）怎么看？

项目结果与图纸是否相符？是否进行了全面的测试？

用户对项目阶段性的结果（功能、体验）怎么看？

是否形成了用户任务的闭环？

是否存在流失率超高的任务节点（比如注册）？

9，网站分析

9.1，网站分析系统

和网站一起上线的，应该还有网站分析系统，它是衔接产品研发项目和产品运营阶段的重要环节，是我们观察产品运营情况的眼睛和耳朵，可以帮助我们对执行结果进行检查。

网站分析通过对用户行为进行研究，为网站改进提供决策依据。遵循以下两大原则：

A，可行动。别只是为了分析而分析，而是要为改进而分析，网站分析的最终目的是促进网站的改进。

B，以用户为中心。用户们的目的是什么？这些目的达成了么？没有达成的原因在哪里？

9.2，如何网站分析

分析工具：购买或者使用插件。

建立并维护业务数据模型

建立一套业务数据模型，把网站的重要指标性数据和用户行为联系起来。

有了这套数据模型，当数据产生波动之后，就可以快速定位到用户行为的变化，进而确定如何行动。

对产品更新、营销进行专项验证，评估效果，总结经验

染色标签等方法，确定出专项所影响的用户，然后分析行为，验证结果。

监护产品的健康状况，确保产品完成KPI

在业务数据模型中，有一些相对关键的指标可以反映出网站的经营状况，比如日收入和日活等，我们诚挚为关键绩效指标（KPI），老板会通过考核这些指标来评估产品的运营状况。

对产品的关键指标进行预测，为商业计划提供数据支持

参与年度商业计划的制定，计划中收入预期和成本需求不是拍脑袋想出来的，是靠业务数据模型和历史数据推测出来的。

9.3，一些通用的方法

细分

过多地关注整体数字是没有意义的，每天盯着PV并不能把PV盯上去。产品经理需要关注组成PV的更细节的数据，只有这样才能找到可以改进的具体的点，然后通过点的改进最终影响整体数据。

对比

孤立地看一个时间点的数据是没有价值的，要么结合历史数据看趋势，要么结合竞争对手的数据看表现，只有经过对比，数据才能告诉我们现在的情况究竟怎样。

Tips:当我们面对一堆数据的时候，会有一种天然的抵触心理，这种抵触源自于对数据分析所带来的回报认识不足。

面对公司资源的时候容易产生一种错觉，认为公司的资源都是公司买单，所以无需精打细算，可以尽情使用。这并不是试试，投资总是有限的，浪费是要付出代价的。公司给我们免费的资源之后，如果我们挥霍无度，那么当公司重新评估各款产品的资源分配时，就会砍掉我们的资源甚至我们的产品。

9.4，产品运营状况简报

产品运营状况简报是产品团队与老板对话的中要桥梁。

通常来说，它包含两大块内容，KPI完成情况及预测、产品计划与执行情况。

KPI完成情况与预测

如果你的团队里有产品运营经理，准备这一部分内容理论上是他的工作。

老板会通过KPI对产品进行数字化的管理，看几个关键的绩效指标是否在稳定朝着既定目标增长，这对老板来说是非常高效的，可以让他快速了解多款产品的经营状况。

在简报这部分，一方面，我们要在简报中展示过去的成绩；另一方面，我们还要预测未来，告诉老板今年能不能有效完成计划。如果KPI出现特殊的波动，产品运营经理和产品经理需要及时分析原因寻找解决方案，要尽可能保证产品的平稳发展，同时需要应对老板的提问避免陷入被动。

产品计划与执行情况

产品团队展示他们在想什么和做什么。

产品经理需要向老板展示整款产品的功能规划以及路线图，营销经理需要向老板展示营销活动的规划和执行方案，然后介绍当前时间段产品计划的完成情况——哪些完成了，哪些在进行中，哪些取消了，已经完成的计划取得了什么成效，有没有数字上的体现，等等。

通过简报与老板建立周期性的良性沟通非常重要，这个沟通渠道可以帮助产品团队赢得老板的注意力，进而获得决策效率的提升和一些资源上的支持。同时这也是产品经理进行自省的好工具，可以帮助我们梳理工作脉络，保持对产品的清晰认识。

10，拉动

产品经理要学点营销，这样可以更好的和营销经理进行配合，或者，你的团队没有营销经理，你要顶上。

10.1，平台拉动

拉动进来的用户总数=平台活跃用户数X转化率X拉动时长

转换率与以下因素有关

展示面积、展示时间（在3.6有相关的说明）

平台用户和被拉动产品目标用户的重叠度

封闭体验

如果用户使用A产品的体验叠加上使用B产品的体验，相对于使用A产品加B产品的竞品可以获得增值或低成本，那么我们可以说A产品和B产品的组合形成了封闭体验。

拉动时长主要受拉动手段和市场预算的影响。可以把拉动手段大致分为三类：广告、植入和融合。

广告：广告能否持续投放，主要取决于ROI。当用户达到一定规模后，整体收入抵消掉公司运作成本还有一定的利润，只要持续投放广告可以保证持续的利润，那么广告就能成为一种持续性的拉动手段。其中，搜索关键字广告由于直接与用户的搜索目的相关，封闭性体验强于普通展示广告，所以它的点击率更高，单次点击成本更低。

植入：让用户在不知不觉中受到影响并且隐约感觉到产品的实力。植入和广告的区别在于，植入是“偷偷地”影响用户，广告是明目张胆的影响用户。当我们决定使用植入的时候，一定要把握好分寸，以用户猜不透这个产品出现在这里有没有花钱为界，如果用户能猜到肯定是花钱出现的，那就不是植入而是广告。

互联网的植入主要有三种方式：

把入口放到平台中，使它看上去就像是平台的一部分。

把产品的品牌或展示放到某个内容中，通过内容在平台中的传播触达用户，例如软文。这种植入方式的关键在于创造用户价值，作为载体的内容知识性或趣味性一定要够强。比如，当我们寻找内容载体的时候，一定要选择比自己的产品范畴更大，同时又有一定封闭体验的内容，这样才能构成不着痕迹的植入。

将产品的品牌或入口放到用户“身”上，他们在平台中活动的同时就传播了产品。

融合：被拉动产品和平台融为一体，成为平台不可分割的一部分，用户从使用A平台变成了使用A平台+B产品。

融合带来的转换率自然最高，拉动时长自然最长，但是它对用户重叠度和封闭体验的要求也最高，通常来说平台还得是自家的才行。被拉动产品和平台不是主观上想融合就能融合的，如果用户重叠度低或封闭体验不够强，强扭的融合很可能导致用户离开平台。

如何选择平台，如何确定拉动手段？

首先用大致的拉动成本过滤出可能的平台，同时也要通过用户规模、展示面积、用户重叠度等条件对平台进行重要性排序。然后从具体拉动手段的成本和封闭体验两个方面最终确定拉动手段及其优先级。

10.2，口碑拉动

形容自己的产品比竞争对手的好，无外乎“人无我有，人有我优”。即是硬指标（我优）和差异化（我有）。

硬指标，需要真正的内行解读后才能传播，例如苹果的retina display并非行业尖端，但是这种面向大众的硬指标宣传方式，降低了内行的门槛，让更多的人可以口碑自己。

差异化，运用蓝海战略，让口碑变得更加坚实。

11，持续更新

用户对产品的忠诚度和产品的更新频率有关。

史玉柱讲解游戏开发，所有游戏的失败都集中在了这“三关”上：

一上来印象不好，用户会走；缺乏细节的魅力和值得憧憬的体验，玩家不愿意继续尝试；

玩了一段时间“审美疲劳”会无聊，这时候没有足够丰富的玩法吸引，玩家自然流失。

“印象关”和“体验关”需要有效的核心概念和良好的用户体验，通过“无聊关”则需要保持产品的更新，最好可以找一些能够源源不断地生成更新的功能，比如用户生成内容、用户与用户之间的交流等。

管理用户期望

从用户角度来讲，他对你的产品的期望有个理想水平，当然他也知道这很难达到，所以他还有一个适当水平，也就是他能够接受的底线，理想水平和适当水平之间是用户的容忍区域。反过来，如果一款产品总是宣称自己下一步的改进将会多么地具有革命性和跨时代，不断提高用户的期望，最后即使做到了80分，在用户心目中也只有50分。

产品更新包括两个要素：一个是更新本身，一个是更新的频率。

以固定的频率进行更新对于保持用户的热情非常有效，在更新一些需要花费较长时间的重要功能的时候，穿插着进行一些小的功能以保证更新的频率，可以避免用户由于长时间没有看到更新而流失。

客户端产品的更新不能太慢，一方面体验问题要及时修复，另一方面公司是通过运营月报来进行KPI考核的，如果不能一个月发布一个版本，产品就会失去了影响KPI的能力，所以成熟的公司通常采用月版本的更新频率。

产品的更新包括功能更新、内容更新、热点事件应激反应等几类。

原有的升级功能和发布新功能都属于功能更新，这也是用户感受最明显的更新。功能更新的概念一般来自于竞争对手和自己的用户，想要做好功能更新，一定要做好竞争情报和CE这两块基础工作，不要忘记你是在为用户服务。

更新的产品功能很多，如何确定优先级？

可以按照成本和效益划分象限，效益高，成本低的优先。

成本很好评估，但是效益不太容易评估。可以借助最小可行性产品（MVP）来进行一些测试。

MVP是指用最低的成本实现一个尽可能展现核心概念的产品，产品团队可以通过它手机到尽可能多的用户反馈和数据，从而评估这个产品能带来的效益。

相比于用户看到的棋面，产品经理在下的是一整盘棋，有很多规划用户是不理解的，所以用户对当前更新的理解只是从自己的视野出发的。而用户在参加一些概念测试的时候，往往不够深入，仅靠几分钟的体验就给出的结论是经不起推敲的。所以当用户提出需求的时候，我们应当关注他们更深层次的、没有直接提出来的需求；当用户表示很满意或者很反感的时候，我们要确认自己的测试手段是否足够有效，不妨让他们用上两星期再看。

产品经理在兼听的同时，一定要清楚自己的底线在哪里，哪些地方可以有弹性，哪些地方要死守。

如果你的产品包含一些内容，那么保证这些内容定期更新的同时，也要注意保证这些内容的质量，不要出现破窗。宁可更新的速度慢一点，也要保证内容的质量。

对热点事件进行应激反应，一方面可以满足现有用户关注热点事件的需求，另一方面也可以借助流行趋势来星那更多的用户。

12，优雅降级

对产品的运行环境进行分析，让产品在不健全的环境中通过有损运行的方式来保持部分核心体验的方法，就是优雅降级。

优雅降级的核心是取舍，产品保持可用和“别让我等”是必须坚持的底线，用户也愿意在这个前提下接受部分体验的损失。

当我们针对多种运行环境制定了多套优雅降级策略之后，我们的产品虽然没有增加用户能够明确感知的新功能，但产品的可用率和用户满意度肯定会有所提升。当然，优雅降级是有产品设计成本和研发成本的，在用户规模不大的时候，优雅降级和其他用户能明确感知的新特性相比肯定属于更新排序中优先级比较低的，但随着用户规模的增大，优雅降级的效益会增大，优先级会变高。

13，竞争情报

竞争情报需要研究的因素

竞争对手信息：创始人背景、公司沿革、财务状况、用户规模、组织结构、激励体系等。

用户信息：性别、年龄、地域、兴趣爱好等。

市场信息：规模、趋势、份额划分等。

技术信息：对手使用了什么技术来提升用户体验、降低运营成本。

产品信息：核心概念、流量分布、体验上的细节，我们的产品与之相比，优势与不足。

环境信息：社会环境和产品使用环境。

竞争情报的基本原则

全景>精确

弄清楚研究对象是蚂蚁还是大象，比知道他的血型更重要。CI强调连续的信息流，连续代表着信息会被不断地刷新，所以能够体现数量级即可。

一手信息>二手信息

一手指的是亲自调查可靠的信息源，不要不屑于自己动手实验和调查，情报的真实性高于一切。

多节点>单节点

发动更多的人一起收集竞争情报，就能达到更全面的效果。

人脑>电脑

电脑可以帮助我们处理一些信息，但是要在信息中提炼和发展出可以影响决策的内容，离不开人脑的分析。

产品需求>个人喜好

关注情报的范围应该锁定在产品周围，不要参杂过多的个人兴趣，这样会影响判断，也会浪费时间。

促进变革>精美的报告

不要忘记搜集情报的最终目的，在CI的过程中确定自己要做什么并且动手去做才是最重要的。

5W1H分析法

WHY——为什么这做，原因是什么？

WHAT——目的是什么，如何衡量？

WHERE——针对什么地点？

WHEN——什么时间完成？

WHO——谁负责，有谁参与？

HOW——如何实施，需要多少资源？

可以通过哪些手段搜集情报

搜索引擎，第三方评测，相关人士进行访谈，焦点组和调查问卷等调研方法。网站分析系统，聚合器的订阅。

访谈的技巧：热情、委婉、区间、重复、启发。

如何确定情报是否齐备，唯一衡量的标准是我们的研究目的。

比如我们要提交一份关于群组的建议，筛选市面上最成功的几个案例进行调研，进而判断我们可以选择什么样的产品形态，进入这个市场能够为公司带来哪些利益，就可以了。

情报如何生效？

产品团队内部可以决策的部分，直接融入到简报中，作为后续计划的缘由转变为产品动作是最有效的办法；

产品内部难以决策的部分，需要公司层面决策的部分，可以编写PPT向老板宣讲，争取立项。