产品经理应如何给产品做减法

1. 怎么才能做一个好的产品经理

1. 一个真心热爱产品工作的人

这些年，我带过的产品经理加起来有数十位，面试过的有上百位，我发现一个很严重的问题——90%以上的人并不是真的热爱这个职业，很多人主要是因为产品经理入行门槛低、发展前景好、收入高。

虽然我也认可转入这行的人是有眼光的，但一个不是真心热爱产品工作的人，大部分未来必然遇到职业瓶颈和发展困惑。

产品经理职业与其他职业不同，产品经理是除了老板外，最需要主动思考、主动解决问题以及推动协调各方资源的，工作的硬技能要求不多，软技能要求极高，如果没有热情，很难做的好，还很容易不开心。如果满腹牢骚也能把工作干的很出色，有2种可能，一是运气好，二是天才。

乔布斯把做产品视为其追寻人生理想的方法，稻盛和夫把工作看成自己快乐的方法，真正优秀的产品经理往往是抱有对产品极度的热情。很多人并非一定讨厌工作，虽然很累，但产品经理是一个很容易获得快乐和成就的岗位，试着转变一下思维角度，看看是否能爱上这个职业吧！给你几个热爱的理由：

• 如果儿时的梦想是发明家的话，那么产品经理是最容易实现这个梦想的捷径。

• 产品经理是最容易获得成就感的职业之一。

• 产品经理是话语权最接近BOSS的角色之一。

• 产品经理拥有无限的晋升空间，牛叉到可以封神。

• 产品经理是AI时代到来后，最懂人的人了。

• 产品经理们引领了未来世界的发展。

• 未来很多职业会消失，产品经理会更重要。

2. 一个有产品修养的人

很多年以前，我认为专业技能重要，但后来我意识到，相比硬技能，软技能和底层能力更为重要，且这是很多新手容易忽视的，而产品老人又容易进另外一个误区，有点资历就丧失修养。

在实施产品和项目时，一个产品经理的人品、情商、职业观、责任心、协作精神、担当精神、专业能力都变得非常重要，这些能直接影响到项目的成本和进展，也包括团队的信心、凝聚力、战斗力和成就感等。

网上有一些话题很有趣，是讨论一个糟糕的、没有修养的产品经理是如何搞垮一个企业或一个团队的。这几个情况可以验证一下我们的修养：

• 总是爱和同事争吵

• 遇到问题总是先以退避和自保为首要目标

• 犯了错成功甩了锅或者扯皮糊弄过关，还沾沾自喜

• 背后总抱怨这、抱怨那

• 常骂领导是个傻X

• 常说不关我的事

• 常以学历和背景来证明自己牛

• 从未承认过自己在某方面无知

3. 拥有洞察本质的能力

洞察事物本质的能力，是优秀的高阶产品经理安身立命的最重要技能。做产品，创新也好、模仿也罢都是手段，目的是解决问题，解决社会问题、用户问题、商业问题、自身问题等，解决问题就需要化繁为简、透过现象看本质的洞察力，产品经理需要在工作和生活中，不断的锻炼和提升，有以下关键要领：

a. 同理心

同理心是我们站到对方立场了解对方所思、所想，了解用户动机和立场的重要本领，提升同理心也有一些方法，首先要去掉较重的分别心，正是因为分别心，总是带有色眼镜看众生，你很难真正理解用户所思、所想，当你看不起一些人的时候，你就不会了解他们，认同他们，自然而然你也无法做出满足他们需求的优良产品。

锻炼同理心，最好的办法就是多同各种人交流，多倾听、思考他们的动机，尤其在生活中，不要老活在自己的圈子，多接触几个完全不同的圈子，你会发现社会人形形色色、缤纷万彩、绚烂多姿。

• 多同不同圈子的人交流

• 多同不同年龄的人交流

• 同3岁小孩和70岁老人交流看看

• 多同不同文化程度的人交流

• 多同世界各国的人交流

• 多想想对方为什么这么说、这么想

记住一句话，众生皆平等，若想了解对方，就要站在和他一样的高度。

b. 深度思考的能力

人，已经习惯了快思考，快思考是条件反射的思考，是我们过去经验模式和思维惯性的既定反馈，而深度思考的关键诀窍在“慢”，静下心来带有各种可能性、发散性的灵性思考，从而更容易发现事物的规律和本质以及解决办法。我们平时，遇到各种问题，可以试着通过慢思考、逆向思考来锻炼深度思考的能力，很多人打坐或冥想更容易透过现象看本质，就是这个原因。

c. 逻辑分析和提炼能力

逻辑能力很重要，透过现象看本质很多时候是种悟性，但推理需要很强的逻辑思维能力，如果你能抓住本质，而无法推理，也可能是知其然，不知其所以然。

逻辑分析往往是有条理的，但条理也会使得事情看来很复杂，很多时候，我们要在清晰的逻辑分析之后，抓住核心要领，以及提炼出核心观点和思路。这方面的锻炼，我觉得就是多思考、多练习、多实践，尤其是在梳理需求和撰写文档时能充分锻炼。

4. 空杯心态和学习力

产品精神不完全同于以往的工匠精神，过去大部分领域的创新空间是有限的，工匠精神更多是精雕细琢、注重品质，经验能力较强；而互联网和高科技天然强调创新与颠覆，所以作为产品人，创造力和创新力很重要。

这对于人们无疑提出了一个巨大挑战，以往基于经验沉淀的技艺是工匠们价值的核心体现，而产品人则要不断革掉经验的命，否者就被别人革命；所以空杯心态尤为重要，互联网发展日新月异，超强的学习能力是一个产品人保持竞争力的关键。

学习力和清空杯子的次数有关，空杯并不是把知识倒掉，而是提炼了，并且学习力的段位提升了，那么领悟新知识的能力变强。

这里需要说明一点的是，人们认为学习领悟力与年龄成反比是错误的，很多产品老人，学习能力下降不是年龄大了，是杯子满了，学习力没有升段。对此，我有如下建议：

• 成为本领域的专家

• 敢于请教比自己更资浅的人

• 敢于从失败者身上学习经验

• 跨界交流很重要，向不同领域的人学习

5. 总能解决问题

千言万语汇成一句话，就是解决问题的能力，当我们遇到巨大困难的时候，人们都是提出问题的能手，而真正能提出建设性意见、并且解决难题的人不多。

当我们有了解决问题的担当和决心还不够，又要面临如何解决问题的现实，优秀的产品经理向来知道如何做。而他们提出的解决方案往往也有ABC，并且能够推动团队去落实解决方案，当遇到挫折时也能及时反思，调整解决方案，如果遇到失败，敢于承认失败，犯了错误敢于承认错误，这才是我心目中优秀的产品经理。如下有一个小案例：

• 测试工程师A：这个bug在线上反馈，比较严重，影响了很多用户的使用，得赶紧解决。




• 技术负责人B：我们已经把问题查明了，这个问题是线上正式环境的，之前开发、预发布及灰度测试的时候都没有爆出，我们经过反复研究，无法直接修复，只能更新版本。




• 产品经理C：反馈客户很多，需要立刻解决，如果等发新版本，时间太久影响太大。有没有其他办法。




• 技术负责人B：我们反复研究了，只有这一个办法。




• 运营人员D：这问题都解决不了，是不是技术水平不够，测试怎么发现不了就上线了…




• 【测试人员和技术及运营人员开始互怼，局势有些紧张】




• 产品经理C：我们先不要指责谁的过错，先聚焦到问题上，争分多秒，怎么解决。发新版我认为是最后的最糟糕的补救方案，我们现在是否可以安排技术人员立刻先落实，另外，希望技术再认真研究一下，是否线上真的不能解决，那我们通过动态更新，发布另外一个功能，掩盖这个功能的bug，是否可行，就是将损失降到最低的方案，另外，运营上，针对已经投诉反馈的用户，我建议尽快做好安抚工作，同时，运营上有没有其他可以转移这个问题影响的方法呢？…




• 【大家回到如何快速最大限度解决问题的讨论和落实上】




• 【该问题解决后，产品经理C立刻召开复盘，如何避免这类问题重复出现】

6. 擅长掌控过程

老板和产品经理，有一个很重要的区别，老板更关注目标、结果，产品经理更关注过程，我们过去强调太多结果重于一切，殊不知，结果已经发生，我们又能如何呢？所以产品经理更应该关注每个过程的发展，一个优秀的产品经理，无论级别多高，永远要关注过程发展的关键细节和整个流程，尤其是用户和客户的实时反馈，只关注目标和结果的不是产品经理，是老板。对此，我有如下建议：

• 保持深入一线接触用户/客户的习惯，做最了解他们的人

• 如有必要，可以把和用户有关的岗位，都扮演一下（销售、客服、运营等）

• 深入团队，了解每个重要角色的工作状态和工作输出

2. 从点子到产品：产品经理的价值观与方法论

本书的产品依然注重于电商平台开发类产品，前几章内容有些可以总结的经验，以后的章节所阐述的问题很乏味，吸引不了读者，果断放弃。

刘飞

58个想法

内容简介

>> 第一部分主要讲述从粗略的点子到具体的方案，要经历的步骤。第二部分主要讲述如何落实方案，以及如何进行用户研究、需求分析和产品设计。第三部分主要讲述在落实方案的过程中要掌握的方法和管仔运理技巧。

>> 最后一部分主要讲述产品经理在工作和成长过程中要考虑的一些问题。

第1章 点子与方案

>> 在产品尚未成型、什么都没有时，作为产品经理要有建立在对厅虚市场和用户的理解上的雏形方案。在相对成熟的公司，也要清楚公司的产品是怎样从简单的点子和想法，借由基本的产品框架和定义成长为了当前的状态。这里提到的雏形方案，或者产品的框架和定义，可以称之为产品模型和商业模式。

>> 产品模型涵盖的内容不仅是基本的用户需求，还包括整个项目的产品逻辑。这个逻辑试图证明的是：无论从用户角度，还是产品设计者角度，整个项目要满足需求这件事是可以运作起来

>> 总的来说，在产品从0到1的过程中，最先要确定的就是关乎需求的逻辑是否在产品上、商业上行得通。

提出开发项目的终极问题——产品目标市场

>用户到底为什么要用你的产品？

>> 用户到底为什么要用你的产品？

>> 这里涉及两方面的问题：用户是不是有需求？你能不能满足用户的需求？

>> 思路是先定义了未来产品成为了大而全的平台应该是如何，再去倒推考虑现在的功能应该怎么配合。这是一个非常奇怪的方式，但也是很常见的错误：先想一个结论，再去找能证明这个结论的论点。

>> 产品逻辑需要解决的问题：到底你设计的产品，能不能运行？做产品逻辑时应该掌握一种方法，那就是把所有想到的关系捋清楚，并且画成流程图或者结构图，在纸上运行一遍，看是不是可以跑得通。

>> [插图]

>> 市场的存在：指的是这个市场是否成熟。比如VR市场，目前尚未成熟，用户群还是停留在只有少数极客的程度。但电商市场已然非常成熟，2015年双十一的天猫总成交额接近千亿元[插图]。需求的存在：指的是需求出自臆想，还是真实的发现？我听说过一个段子，讲的是“如果你听到身边有人一拍大腿说，‘要是有个XXX的产品就好了！’那这样的需求肯定是真实存在的”，这不无道理。用户的存在：指的是针对判定出的需求，用户群到底存不存在。比如我们的确发现有定制高端生日礼物的需求，但这个需要有多少人会存在，他们是不是足够成为支撑我们产品的用户群，这

>> 些都是要考虑的。其次，再看需求满足的逻辑是否合理。提供的可能：对于单方的产品（比如像新闻客户端、搜索引擎）来说，服务和内容是我们官方提供的，那要考虑是不是从现实层面真的可以提供；对于多方的产品（比如像外卖平台、问答平台）来说，服务和内容则是由另外一端的用户提供，他们有没有意愿也是要考虑的。发生的场景：若是只说用户存在、需求成立，但却找不到发生的场景，自然也是不合理的。比如想要提供服务的人和想接受服务的人在不同的地理区域，那就可能对接不上需求了。

>> 接受的意愿：很多时候我们的产品只考虑需求本身的合理性，而不考虑用户对它的接受程度。比如最常见的上门服务，若是各方面都很完备，但用户总是有所顾虑，不愿接受，那产品就不得不面临悲剧收场。最后，要看产品模型创造的价值是否是正面的。以上三个层面，至少要在两个不降低的情况下对另一个做提升。好的产品模型，应当是三个层面都有提升的。

>> 京东创始人刘强东在2015年12月的一次公开演讲中，提到：“创业成功需要具备四个要素：团队、用户体验、成本和效率。”后三者就是互联网产品创造价值的关键要素。效率：互联网带来的是信息化，信息化最大的价值就是提高了很多行业的效率。对于互联网产品来说，能否让一些事情变得更快捷、更有效率，让用户完成一件事更快是最重要的检验要素。成本：效率跟成本往往是对应的。如果提高效率，成本通常会降低。但如果效率提升了，成本却也随之提升，那么要反思产品逻辑是不是欠妥、整个模式是不是并没有给用户带来多大价值。体验：在当今消费升级的时代，体验也是很多产品的价值所在。能够让用户在不耗费更多成本和时间的前提下享受更好的体验，也能让产品模型足够稳

>> 固。这种检验可以对产品模型有大致的考量，也能大概知道，产品模型是不是值得真正做出产品去尝试。

>>念伏梁 环境

>> ：

>> 拓展

>> 合理性

产品的延展性

>时间上无法有突破（律师行业变化小）；空间上局限也很大（律师行业比较有差异性、圈子小）。整体上，我们就判断这个方向是暂时不具有延展性的。

那么做什么样的产品是有延展性的呢？比较有代表性的是小米科技。手机这个产品，虽然由于各种原因，也必然比常见的互联网公司做得“重”，但是它在时间上，可能性非常大。如果是一把剪刀、一个梳子，我们知道五年前是这么用，五年后可能还是这么用。手机是不一样的，我们可能隔几年就更新换代，因而也想象不到五

>> 时间上无法有突破（律师行业变化小）；空间上局限也很大（律师行业比较有差异性、圈子小）。整体上，我们就判断这个方向是暂时不具有延展性的。那么做什么样的产品是有延展性的呢？比较有代表性的是小米科技。手机这个产品，虽然由于各种原因，也必然比常见的互联网公司做得“重”，但是它在时间上，可能性非常大。如果是一把剪刀、一个梳子，我们知道五年前是这么用，五年后可能还是这么用。手机是不一样的，我们可能隔几年就更新换代，因而也想象不到五

>> 年后我们用的手机是什么样子的。

>> 那么怎样看待延展性呢？大概需要了解以下几个问题。• 想要进入的市场的状况是怎么样的？会发生怎样的变化？市场竞争环境：所在的市场现在是怎么样的状况？是巨头和一大堆创业者都在打得火热，还是没人在关心、非常冷清？大家对这片市场的态度是怎么样的？相关的技术：有什么技术会影响到这个市场的变化？在技术层面，对市场、产品的影响会有多大？比如会不会有一些发明颠覆市场的运作方式或者结构？相关的政策：有没有相关政策会发生变化？是利好的还是利空的？

>> • 面向的用户如何，会发生怎样的变化？用户群体目前是怎样的？他们属于什么结构、有怎样的特征？这些属性会发生变化吗？对于不同年龄、不同领域、不同国家地区的用户，有没有拓展性？• 产品逻辑的拓展性如何？首先，对于当前的需求，可以实现的产品方案是单一的，还是多样的？对于这些方案，可以做的事情够不够多？是不是基于它们还能开展更多服务、实现更多功能？其次，对于当前的用户可以满足的需求除了目前考虑到的部分，还有更多吗？如果用户沉淀下来，能否发掘他们更多的需求并满足？最后，对于当前的垂直领域，可不可以扩展到相近的领域（比如从美甲到所有美容业）？如果扩展到这个领域，产品逻辑上可复用的部分是不是足够多？• 商业模型的拓展性如何？赚钱的方式有一种，还是多种？每种商业模式的逻辑都成立吗？对于目前的用户，使他们成为付费用户或者说产生商业价值的可能性会因为某些因素发生变化吗？

>> 团队

>> ：

>> 实施合理性

>> “为什么是你们做”这句话，应该是我们在分析任何需求、实现任何产品前都应该问清楚自己的。这句话包含两个意思。其一，你们有能力做出这个方案吗？能力可能是多面的，不仅是产品设计的能力，还有技术能力、运营能力，还包括资金的情况。其二，你们比其他人做有足够的优势吗？就是在各种所需的能力上，每项跟其他竞品团队的能力有多少差距？

>> 成长建议Ⅰ

>> 要点反思• 点子落地之前，务必先“纸上谈兵”一回。• 说服身边最理性的人和最吹毛求疵的人认可你的想法。• 证明你们的团队可靠，跟证明方案本身的可靠同样重要。

第2章 找到产品核心价值

>> 第2章找到产品核心价值

>> 产品经理的经典书籍《用户体验要素》

>> 图2-1展示的就是用户体验要素的模型。虽然模型里用的词是“用户体验”，但在完整的产品设计上，这也是合情合理的一套方法论。核心价值其实就是战略层里包含的目标，也是最基本的底层支撑。要设计的功能，都要基于这个价值去做。

>> [插图]

>> 图2-1 书中的用户体验要素模型示意图找出核心价值的原因有三：第一，发现核心价值，能够选择综合考量下来最优的功能。能够创造价值的功能很多，但核心价值意味着对产品来说，这样的功能性价比最高，或者是最受用户认可、最有商业价值、对公司

>> 最有利。第二，基于相同的核心价值设计的功能，逻辑统一。逻辑一致的功能可以互为补充，用户群体相似、需求也相似，能让价值产生增益。而零散的功能，成本高，往往吃力不讨好。第三，有单一的核心价值能够让用户对产品产生认知。想要依靠多种价值打动用户在初创阶段往往特别困难。产品起初强调核心价值和核心功能，可以让用户更理解这个产品能解决什么问题。很多产品是大杂烩，用户可能都发现不了自己想要的功能，因此很快就流失了。

>> “解决问题”是产品价值所在

>> 做产品时，一定要避开这些“黑魔法”。不要以暂时的效果作为目标，以破坏用户的感受为代价，过于“热心”，有事没事撩骚用户，黏住用户

>> 确保产品真正解决问题

>> “比起有100万个普通粉，宁愿要100个脑残粉”[插图]。用尽各种办法把100万人留在平台上，但并没有解决他们的什么问题，他们对你就毫无价值，长远看不会继续留在你的平台上，从商业价值上来看他们也几乎不会产生付费意愿。但如果你有100个脑残粉，你能解决他们最实际的问题，他们会对你产生信任，不仅愿意养活你和你的团队，甚至还可以成为你的免费推销员，让你的口碑快速传播开来，这里面不会有水分——毕竟你真正解决了他们的问题。用户的“量”不重要，“质”更重要。而要让用户真正跟你的产品产生很强的关系，自然就要看解决问题是不是够好、够快、够准。在解决问题的时候，要确保产品真正能满足用户需求。最尴尬的情况是，你费尽心思终于分析出的需求，精准无比，但做的功能却扑了个空。

>> 成长建议Ⅱ

>> 在做产品时设计的功能不是为了投资人、不是为了老板、不是为了理想，而是为了用户。为用户创造真正的价值，才是有意义的功能；而能为行业甚至全社会创造价值的产品，才是真的可以长青的产品。

>> 扎克伯格曾经说过一段话，值得大家参考：“在硅谷人们总是先决定要创业，再决定要做什么，在我看来这是非常本末倒置的做法。对于真正创过业的人来说，他们知道创业本身是件非常难的事情，而真正让你能够坚持下去的是相信你在做的事情并且知道你在做的事情是在创造价值的。”

>> 要点反思• 解决不了问题的产品，只能靠补贴和红包留住用户。一旦遇到更大的红包，用户说走就走。• 问题解决得够彻底，下次用户会主动来找你。

第3章 MVP与痛点

>> 第3章MVP与痛点

>> MVP是埃里克·莱斯所着《精益创业》中提到的概念，它的目的是验证两件事：一是产品满足了用户需求；二是产品能够创造商业价值。

>> 这恰好跟前文我们提到的，初创团队的产品经理应该探讨产品模型和商业模式对应。MVP就是验证它们的手段。

>> 成长建议Ⅲ产品模型和对核心功能的设计像是指导思想，而MVP是实践的方法论。很多产品经理沉醉于自己设计的美好幻想中，或者想法变来变去，或者埋头设计出一套太过完整却不实际的方案，但就是不尽快迈出第一步，验证自己想法的对错。

>> MVP很难一击必中，创业团队要在检验中判断产品功能有没有解决问题。如果及时发现问题，快速转向，也许生机就在别处；但如果太过留恋自己的设想，一直死磕一个方向，可能下场就不怎么好看了。

>> 要点反思• 大部分在等待功能完善、交互完美、界面出色才能一炮而红的产品，往往都没等到那一天。• 产品初期做设计要多做减法。• 初期把整体流程跑通时不用特别在意是不是用“互联网方式”

第二部分 需求分析和功能设计

>> 需求分析和功能设计是产品经理日常工作的主要内容。关于如何分析需求、做功能设计，在这些年产品经理这一职业的发展中涌现出了海量的方法论。这一部分就以需求分析、用户研究和用户体验这三块比较有代表性的工作为例，讲述做需求分析和功能设计时应有的思路。

第4章 深挖需求

>> 第4章深挖需求

>> 产品经理不应只关心浮于表面的需要，而是要关心需求背后的真正诉求。阿尔伯塔大学的一门关于软件设计的课程中，用Want（需要）和Needs （需

>> 求）来区分这两者，前者是“希望在产品中看到的功能”而后者是“确定的具体问题，留待产品解决的问题”。对于很多用户表面的要求，以及形式上我们“看似”要满足的需求，很多其实都值得商榷。对待这些需求，我们最需要做的是发掘更深处它们代表的是什么、真正的问题在哪里。

>> 基于场景深挖需求

>> 要点反思• 区分用户表达的究竟是诉求，还是具体的方案。• 不断假想自己是用户，以及真正到用户场景下体验都是发掘需求本质的好方法。

第5章 用户研究

>> 第5章用户研究

3. 在高级产品经理眼里，产品架构是怎样的

一般来说，搭建产品架构这件事情，只有少数的高级PM才能胜任，绝大多数刚入门的产品经理或产品专员，还涉及不到任务这么艰巨的工作（简单的产品功能结构不算）。

经历过需求的采集、分析和筛选，我们对产品的定位和用户的需求有了越来越深刻的认识，对整个产品方向的把控和版本迭代节奏也会更有感觉。这种感觉你也可以称之为“产品感”，虽然讲得有点悬乎，可又的确存在。以我个人的经验来看，不断地了解用户需求和场景，也是积累产品感的一种良好的方式。有了不错的产品感，我们要继续往前走，才能将产品推向一个更高的高度。
产品经理之前已经将产品第一个版本的功能需求都整理好了，也输出了一份详细的功能需求列表，这个时候要做的工作就是为产品搭建一个好的架构，也就是产品设计的第三个环节——搭框架了。任何一款互联网产品都应该有一个产品架构，有了这个强大而坚实的架构作为产品的基础，我们才能将产品需求给一个一个填充进去，让产品变的丰富立体，更有血有肉起来。
那究竟什么是产品架构，产品经理又该如何态纯塌来搭建一套好的产品架构，我们来接着往下看。
什么是产品架构
任何一个产品都有自己的产品架构（也有很多人把它称为信息架构），就好比每一个人都有自己的骨骼系统一样，你的骨架大小决定了你大致的身材会是如何，每个人的身材都不一样，高、矮、胖、裤旦瘦各有不同。
有些产品的产品架构比较繁杂，例如大部分to b 的产品，如客户关系管理系统、ERP软件、电商网站的管理后台、物流管理后台、SaaS软件等；有些架构则比较轻便、简单，比如绝大多数的to c 的产品，像我最近在玩的图友、摩拜单车、直播APP映客、花椒等，当然还包括微信（虽说现在功能越来越多了，但大体架构依然是简单、清晰明了的）。
我们直接看几个例子：

天猫商家工作后台
这是天猫商家的工作后台，看到左侧这一排满满的导航菜单了吗，是不是感觉超级复杂，光店铺管理就有超过10个二级菜单，要梳理好淘宝、天猫这种量级的电商平台产品架构可真不是一件简单的事。不过我也常常好奇一点，这么复杂的后台，卖家们都能清楚地知道每一个功能在哪里么。
复杂架构的产品，对产品经理的能力要求较高，需要产品经理能提供功能完备、结构严谨的架构系统，让用户能通过操作流程来使用各个功能。所以这样一个架构的特点是，它会带来一定的学习成本，有些甚至需要对产品的用户进行培训（像淘宝开设了淘宝大学以及淘宝社区）。这种架构产品的用户群体一般比较聚焦，只针对某一类人群，需要对海量功能进行合理整合、灵活布局来聚焦核心用户场景。

脸萌官网
再来看一个例子，这是曾经爆红一时的脸萌app的产品官网，仔细分析一下这个官网的产品架构，是不是超级简单，简单到只剩下2个菜单——首页、关于我们。这里要注意一点，即使是简单的2个菜单（有些官网只有一个菜单），也依帆圆然构成了完整的用户体验，因为通过这个架构，网站的目标和用户的需求都已经得到了充分的满足。当然，如果你想要重新定义网站的目标，或是用户的需求发生了变化，那你就该去准备重新调整产品架构了。
轻架构的产品，它的目标就是提供给用户一个简单明了的信息架构，让用户使用方便、体验流畅。对于产品经理来说，设计轻架构的产品，难点在于体验和创新。我们可以通过给产品做减法来不断聚焦用户的核心使用场景，让用户简单易上手，等产品的用户体量上升到一个新的台阶的时候，再去拓展产品的使用场景，延展产品架构。
典型的几个产品架构模型
Jesse James Garrett在《用户体验要素》这本书中，为我们系统阐述了互联网产品的几个典型的产品信息架构模型。第一种信息架构模型比较符合我们产品经理对产品架构的理解和定位，后面三种信息架构模型，你可以当作是第一种模型的补充，或者你也可以把它当作页面级别的信息架构梳理。
第一种，层级结构（hierarchical structure）

层级结构模型
书中原文是这么来描述这种产品架构的——“在层级结构中，节点与其他相关节点之间存在父级/子级的关系。子节点代表着更狭义的概念，从属于代表着更广义类别的父节点。不是每个节点都有子节点，但是每个节点都有一个父节点，一直往上直到整个结构的父节点。层级关系的概念对于用户来说非常容易理解，同时软件也是倾向于层级的工作方式，因此这种类型的结构是最常见的。”
这种伞状式的产品架构，恐怕是互联网、移动互联网产品中使用最多的一种信息结构，比如我们使用频度最高的微信、手q，以及各类to c 的移动APP，甚至是复杂的to b 类产品，都是使用这种产品架构进行产品设计。这种架构的特点是符合人类的认知习惯，因为人类天生就有分类的习惯，比如书桌，我们会习惯把书籍放在一起，把录音卡带等放到一边；又比如我们的衣柜，我们一半会将不同季节的衣服放在不同的位置。在生活中，整理物品是为了更容易地找到自己需要的东西。
下图是蜻蜓fm早期版本的一个层级信息架构：

蜻蜓fm的产品信息架构
在使用层级结构的时候，需要注意层级的深浅和宽窄这个问题。
大家都有过逛商场的经验，其实有时候做产品和逛商场很相似，有的商场设计的比较合理，很容易地能够让逛商场的用户找到想要的商品品类，有的商场设计却经常让你迷路，来来回回折腾好几次。在确定产品架构的时候，考虑产品架构的深度和广度成为了产品经理的一道必选题，就拿淘宝APP和唯品会APP来说，淘宝属于广而深的架构，唯品会则属于浅而窄的架构（相对）。在偏深度的架构中，用户操作起来效率不高，用户获取信息、完成目标任务的路径增多，但是相对而言，减少了用户选择的入口。在偏广度的架构中，用户面对的入口增多，在选择入口的时候比较费时，但是减少了用户的操作路径。

广度和深度的架构模式
宽而浅的产品架构和窄而深的产品架构，各有优势和劣势，具体使用哪一种产品架构，关键是要结合自身产品的定位、业务特性、发展阶段和用户特征及使用场景来进行取舍和判断。
第二种，自然结构（organic structures）

自然结构模型
原文描述如下——“自然结构不会遵循任何一致的模式。节点是逐一被连接起来的，同时这种结构没有太强烈的分类概念。自然结构对于探索一系列关系不明确或一直在演变的主题是很合适的。但是自然结构没有给用户提供一个清晰的指示，从而让用户能感觉他们在结构中的哪个部分。如果你想要鼓励自由探险的感觉，比如某些娱乐或教育网站，那自然结构可能会是个好的选择；但是，如果你的用户下次还需要依靠同样的路径，去找到同样的内容，那么这种结构就可能会把用户的经历变成一次挑战。”
事实上，这种形态的产品架构一般在to c 的游戏、娱乐、资讯产品里面运用的比较广泛，例如优酷视频、好奇心日报等。当然，很多时候自然结构是应该结合层级结构来进行思考的，比如用户进入好奇心日报这个网站，可能的一种使用方式是，用户心里已经有一个明确的资讯目标，想看一下最近商业有发什么大故事，所以用户会点击上方的“全部分类”，选择电影，选择商业板块然后进行浏览。也有另一种使用方式，就是毫无目标，直接就是这么从上到下浏览下去，看到自己感兴趣的文章标题便点击进去。

好奇心日报官网
自然结构很适合轻架构产品的浏览式形式，尤其比较适合to c 类的娱乐休闲类产品，因为这类产品的目标用户，绝大多数时候的使用场景都是无聊式地浏览，并没有明确的用户目标，也不需要解决什么特定的任务。
第三种，线性结构（sequential structures）
依旧来看下原文描述——“线性结构来自于你最熟悉的线下媒体。连贯的语言流程是最基本的信息结构类型，而且处理它的装置早已被深深地植入我们的大脑中了。书、文章、音像和录像全部都被设计成一种线性的体验。在互联网中线性结构经常被用于小规模的结构，例如单篇的文章或单个专题；大规模的线性结构则被用于限制那些需要呈现的内容顺序对于符合用户需求非常关键的应用程序，比如教学资料。”
说的直白一点，所谓线性结构，就是你用一个讲述故事的方式去给用户介绍你的产品，多见于产品专题页、帮助文档的设计。其实这部分也没什么可讲的，关键是讲述故事或者问题的时候，你的思路是否清晰，很多时候这部分工作也会由运营的同事替我们代劳。

金山快盘专题页
上图就是金山快盘做的一个活动专题页，通过线性结构讲故事的方式来将自己“100G空间永久免费”的活动宣传出去。
第四种，矩阵结构（matrix structure）

矩阵结构模型
书中是这么描述矩阵结构的：“矩阵结构允许用户在节点与节点之间沿着两个或更多的“维度”移动。由于每一个用户的需求都可以和矩阵中的一个“轴”联系在一起，因此矩阵结构通常能帮助那些“带着不同需求而来”的用户，使他们能在相同内容中寻找各自想要的东西。
举个例子来说，如果你的某些用户确实很想通过颜色来浏览产品，而其他人偏偏希望能通过产品的尺寸来浏览，那么矩阵结构就可以同时容纳这两种不同的用户。然而，如果你期望用户把这个当成主要的导航工具，那么超过三个维度的矩阵可能就会出现问题。在四个或更多维度的空间下，人脑基本上不可能很好地可视化这些移动。”
看了上面这段话，你的第一反应是不是想到了下面这个产品设计界面：

淘宝的宝贝详情页
矩阵式的信息结构，需要将多种信息内容放置在一个页面里，所以它的重点和难点是在于如何做好信息分层，让信息更加有效率地传达给自己的目标用户，这个问题我们放在后面来讲。
总体来说，产品经理了解这几个典型的产品信息架构模型，对于后期自己设计产品架构的时候，会更加明确应该朝哪个方向进行努力。这就好比一个建筑师在设计房屋之前，都需要先有足够的建筑设计知识，其中搭建建筑物的框架便是其中少不了的重要一课。
在具体的工作场景中，大多数产品经理从事的工作基本会分为两个大类，一类是C端产品经理，负责和普通用户打交道，更考验对用户痛点和兴奋点的把握和拿捏；另一类则是B端产品经理，负责和企业用户打交道，更考验对业务本质和行业战略的思考。那么，具体这两种类型的产品该如何来搭建产品架构呢？
To C 类的产品如何搭建产品架构
先简单介绍下业务背景：
2014年开始变热的O2O行业，已经迅速从表层变革进入深水区，很多O2O相关商业模式被验证错误或者迅速发展壮大，这个过程无数创业公司创立和倒下。除了商场、吃喝玩乐商户、线下服务商户等成为O2O热点之外，到家模式也成为一个新热点，美甲的、按摩的、泡脚的手艺人很多都变成了流动作业（典型如河狸家），如果说吃喝玩乐等希望辐射的是商圈流量，那到家服务无非希望搞定社区这块“富矿”。
15年初，当时我所在的公司正好也看中社区O2O这个行业（当然是老板有相关资源，又觉得市场前景广阔），而做社区O2O，有个绕不开的门槛——物业，如果有谁愿意费力气去啃物业这块儿硬骨头，就能有机会赢得未来。
于是我们就组建了一个小团队，先去做了一番市场调研，看一下市面上的这些社区O2O产品都做了哪些连接社区居民的服务，得出了这么一份竞品分析报告：

竞品分析报告
把玩了几十款APP后，我们发现只有少数几家公司的产品做了向业主提供在线支付物业费、停车费的服务，更别谈业主可以在线报修，呼叫安保等服务。
总的来说，当时的社区O2O还不算是一片红海，仍然有市场空间和机会进行切入。以产品的开发背景来说无非是两类APP，一类是“叮咚小区”“小区无忧”为代表的第三方创业公司，一类便是开发商自有的“住这儿”“彩之云”等移动端应用。
第一类像“叮咚小区”这种平台模式，没有用户基础，只靠烧投资人的钱来铺地面工作，当时来看是圈了不少小区，但是由于没有根基，用户随时会被抢走，想要做到成规模的应用不知道要烧多少年。目前传闻好像已经倒闭了，估计资本的钱也烧的差不多了吧。
第二类应用大都停留在试水阶段，扮演配合物业的角色，还没找到完整的盈利模式。“彩之云”可以算得上其中的优秀代表了，其垂直电商模式或许可以成为一个突破口，同阿里争夺“最后一公里”。
而当时的BAT等巨头还都持观望态度，没有太大动作，又或者是等待哪一家创业公司做起来之后再进行投资收购。很明显，大家都把这块难啃的骨头放在了一边。
由于当时公司在房地产物业这块有相关资源，所以，我们团队将产品的切入点定位在了物业公司，物业服务站和物业从业人员这里。而后，通过相关小区的试点，验证产品可行性后，再将产品的使用场景拓展到进行车位信息化管理、社区商户平台——商户通过物业平台入驻小区并投放广告、为成熟的业委会提供在线管理平台、社区教育等等。当时，产品的名字暂时就命名为“乐业安居”，正有让社区的老百姓拥有了我们的产品，就能安居乐业的意思。
经过一系列的产品设计准备工作，就要开始搭建APP的产品架构了。结合之前的市场调研及产品路径规划，以及团队对O2O的理解，梳理了一下我对社区O2O产品架构的规划思考，主要由4个tab组成：
社区：负责连接人与人，这个部分可以满足邻里之间人与人的交流沟通，你既可以在这里发布相关信息寻求帮助或需求交换，也可以在这里找到志趣相投的邻居一起去做一件事情。包括后期的业委会、居委会等等，都可以在这里展示相关信息。
物业：负责连接人与物业，这个部分就是通过移动互联网来改善业主和物业的连接效率，让物业的服务成本降低，效率提高，也提升业主的用户满意度。
周边：负责连接人与O2O服务，这个部分就是第三方O2O（如家政服务、维修服务、养老服务、社区教育等）、电商团购的综合展示舞台，通过整合资源可实现有自己特色的O2O社区服务。
我的：负责管理与”业主“有关的所有信息，如”我的报修“、”我的缴费“、若后面产品拓展做了社区教育，则还可能有”我的课程“等等。

社区o2o的产品架构
当然，第一个产品版本的开发，打算就先做2个部分——”物业“和”我的“，既然是从物业作为切入点，就先把这个点做好，后期在相关小区试点可行后，立即迭代产品，再引入其他功能让产品的使用场景变得更加丰富起来。
如果你仔细分析，应该可以看出这里面的框架逻辑——连接。
这里就涉及到对O2O最本质的理解，它的本质是什么？O2O本质其实就是用互联网去改善消费者和服务提供者的连接，让他们之间的连接变得效率更高、成本更低。所以整个产品架构都是围绕着连接去做的功课，连接人与人，人与物业服务、人与其他服务，这样对于用户来说，他们对你产品的认知逻辑就会非常清晰，每一次打开产品的时候，都能够轻松地找到自己想要的东西。
就这个案例，我们尝试着来做一点总结：
1. 做好分类
前面我们就已经说过一点，人类天生就有分类整理的习惯，有这个习惯也是为了更方便地找到自己所需要的东西。超市里的商品摆放也是如此，所有的商品需要按照不同的分类，摆放在不同的货架上，并且上面还要贴上相应的指示牌，告诉用户这是什么商品区域。
我们常用的Windows 资源管理器也是一个极佳的例子，试想一下：如果我们将自己电脑上的所有文档都归存在一个盘里，而且这个盘并没有文件夹的形式让你分类管理你的文件，word文档、excle文档、ppt文档、pdf文档、视频文件、图片格式文件等都混杂在一起，那你想要找到自己需要的文档也则太难了。幸好在Windows 资源管理器模式下，我们可以创建文件夹，并且可以按照文件的名称、修改日期、类型、大小等进行排序和分组，这样才方便了我们更加快捷地找到自己所需的信息和文档。
同理，网站或者移动APP应用也是如此，信息越多，就越需要组织和整理。我们可以根据逻辑习惯来对信息进行分类整理，如上面所举的例子，就是根据社区O2O“连接”的逻辑进行分类的；当然，也可以直接去探究用户的想法，了解用户的使用习惯。一个好的产品经理，往往也是这个行业的资深人士，或者称为行业专家。因为只有产品经理自己本身对所处行业有极深的理解，他才能更准确地命中产品架构的脉门，有时候甚至是一击而中。
2. 平衡用户与商业
对产品架构的设计，一方面是要了解用户的信息需求，另一方面也要了解整个产品的商业目的和诉求。一般情况下，用户目标和商业目标之间肯定存在着矛盾，比如用户都不想看广告，但企业又希望能够把自己的业务和广告推荐给用户（典型如微信的朋友圈广告）。如果一个产品只满足用户的目标，产品体验当然会不错，但这个产品也很难走的长远，毕竟企业的终极目标是要盈利的。
这个时候，如何平衡用户与商业，就成为考量产品经理的功底的重要一环了。在这方面，我们向微信团队进行学习，微信在平衡用户体验和商业目标这一块做的非常好。还记得2015年1月份的朋友圈广告么，当时一经推出，便立刻成为了朋友圈的热门话题，大家都争相在广告底部进行点赞和评论，仿佛品牌一下子就成为了我们身边的朋友一样，在朋友圈直接与我们分享故事和内容。而在社区O2O这个案例中，我们也将周边这种带有业务、广告性质的功能，放在了后面的版本进行迭代开发，并没有立即尝试进行产品的商业化，这也是一种平衡的体现。

微信广告
3. 重要的功能设置快捷入口
产品架构应该是结构清晰、合乎逻辑的，让有明确目标的用户能够快速找到所需信息；有不确定目标的用户，通过浏览和寻找，一点点地明确自己需要的信息；没有目标的用户，则可以在探索中激发需求。所以，对于后两者用户来说，如果重要功能和常用功能隐藏地太深，则很有可能会让他们对产品丧失兴趣。
为重要功能和常用功能设置快捷入口，就好比在原有的产品架构上搭了一个“快捷通道”，典型如微信将“购物”放在了“发现”这个菜单里，手Q的“购物”入口改成了“京东购物”，京东和腾讯的“联姻”，由微信和手机QQ社交应用入口、朋友圈、朋友群、公众号、广点通，以及线下推广共同组成了多场景的京东社交购物生态，汇聚了庞大的社群流量，为京东带来了不少的新用户和成交增长。
当然，快捷入口的设置也是一个需要权衡的过程。必要的快捷入口可以提高用户的使用效率，也能满足产品一定的商业目标，但是如果快捷入口过多（尤其是参杂太多商业目标的快捷入口），产品也会变得混乱和复杂，这个时候就会让用户的使用效率下降，有点得不偿失了。所以你会看到，微信这款产品，并没有把所有的业务都通过快捷入口的方式展现出来，而是通过在“我－－钱包”里面，展示其他的第三方服务。这么一来，这些功能隐藏地如此之深，产品的用户就不会觉得微信是一款复杂而混乱的产品了。

京东微信手机QQ购物两周年庆典
当然，在业余时间我们自己把玩产品的时候，也可以试着去解构一下其他公司的APP产品，看下他们的产品架构是如何搭建的，又有什么地方是值得学习和借鉴的，这也是一个非常重要的学习手段。
说一下我常用的方法，分三步来走：
拆解产品骨架，将所有模块和功能点画成思维导图
分析重点功能的使用场景与流程
分析次要功能的使用场景与流程
当然，分析产品的时候需要考虑很多因素，不仅是从产品设计出发，还要从行业背景、公司战略、运营、实际资源等情况出发，才能得出更接近真相的答案。
To B 类产品如何搭建产品架构
To B类产品（通常都是后台产品）的设计非常具有挑战性，因为To C类的前台产品，大家都已经培养起了使用习惯，对功能有一定程度的理解，见过的模式足够多，能够建立起一定的产品模型，也容易找到参照物去模仿。但是To B类的后台产品，你几乎没有什么竞品可以参照和模仿，所以在搭建产品架构的时候则要求产品经理非常懂业务，非常考验PM的核心竞争力——业务知识储备、结构化思维和系统性抽象能力。不同行业的产品可能做整体架构的思路也不一样。
稍微简单类比一下，产品架构复杂程度的感觉由弱到强是这样的——
设计或者操控以下交通工具：
自行车
汽车
飞机
火箭
宇宙飞船
……
是不是感觉到难度越来越大了，不过我们也算是了解了复杂产品的架构是怎么样的了，其实依然还是有对应的方法去进行设计的。在对后台产品搭建产品架构的时候，往往有两种思路可供参考：
1.按功能模块来进行划分
什么叫按功能模块来进行划分？如下图：

按功能模块来划分
如果一个后台产品的目标用户比较单一，且用户需求也比较统一，并没有出现说某个用户只需要使用其中某一个功能模块的时候，且功能和功能之间并没有太多的逻辑关系，往往可以尝试使用按功能模块来进行划分的方式。比如网络移动统计，它的目标用户就是互联网公司内部的运营人员、产品人员，且运营和产品关注的数据绝大部分是可以通用的，也就是说用户需求还是比较统一的。
2.按业务逻辑来进行划分
另一个划分逻辑，是按业务逻辑来进行划分。很多公司内部的信息管理系统，都是采用这种产品架构来进行设计的，因为这个产品的目标用户往往涉及到多方角色，既有公司的业务人员，如市场、销售、客服、前台等，又有公司的职能部门人员，如人事、财务、行政等。这个时候再采用功能模块来进行后台的产品架构梳理，则显得不是那么适用了。
按业务逻辑来进行划分，则要求产品经理在规划系统时要思考这个系统的作用到底是解决了什么问题，再具体一点就是——解决了哪些用户的哪些问题。在这个大的环境下确定了之后，在需求的收集和分析的阶段，就应该按照业务角色来进行相关的工作，而后到了梳理产品架构这一步才能更得心应手一些。如下图所示，一个研发管理的子系统，就对应了这么多不同角色人员的不同需求。

按业务逻辑来划分
那么，产品经理在做to b产品的时候，进行业务规划和产品架构之前需要储备哪些方面的能力呢？
需要有一定的技术理解能力，帮助自己理解清楚信息在不同的系统之间是怎样交换、存储、耦合和解耦的。
要有基本的商业逻辑思维，比如节省成本、提高营收、提升效率等。
业务的整合需要对所在行业及业务本身有深刻的理解，同时对公司整体的运行逻辑也要有一定的认识，如销售、市场、财务、运营、产品、技术等。
需要有更强的抽象能力。不仅是把一个工作流程抽象成一个功能，而是要把一个业务抽象成一个系统，并且知道这个系统在产品中所处的位置；不是理清任务与任务之间的关系，而是要清楚业务与业务之间的关系，这样的关系最后是如何交织和演化在一起，共同促进产品繁荣的。
最后，这里提供几个优秀的后台产品供大家参考和研习：
淘宝的商家后台
有赞微商城的后台
微信公众平台后台
总结来说，产品架构这件事情涉及的面非常广，上至产品的宏观计划，下至产品的功能模块，囊括产品的目标及愿景、用户需求、商业需求、数据业务流程和设计框架，还涉及到产品的生态结构，所以要搭建好一套产品框架并不是件易事。产品经理在这条道路的学习上，也要做好一个漫长的认知迭代准备。
好的产品架构具有怎样的特性
好的产品架构对于一个产品来说是非常重要的一件事情，就如同人的骨架之于人，房屋的框架之于房屋，是起到支撑、引导、承重的作用。说回到互联网产品，好的产品架构要具备的几个特征，总结起来大致是这么几个点：易用性、稳定性、可扩展性。
什么是易用性呢？人的天性是懒惰的，试想如果用户在一次简单的使用产品后能记住每一个操作，而且能重复使用，不用刻意学习具体的操作，使用起来一定是很“爽”的。对于产品经理来说，我们必须竭力让用户能够方便地使用产品，这就需要产品架构上能够提供一个清晰的路径导航，让用户不会产生迷路等不爽的用户行为了。
什么是稳定性呢？这部分又通常和后台的技术架构有所关联，当产品不断演进和迭代的时候，系统的架构是否能够承受那么多用户的同时访问，在性能和响应速度方面有没有什么影响。所谓的稳定性原则，就是说你提供的服务一定是稳定可靠的，是能及时响应需求的，尽量避免类似APP上突然有提示失败、服务器异常、空等情况。
易用性和稳定性，就不再多用文字解释了，我们来看看产品架构的可扩展性。
可扩展性其实是在传达一个信息，就是要求产品经理在设计产品架构的时候，就要去多思考未来这个产品是否会新增加功能或者内容，也就要求产品经理要有产品规划的意识。如果一个新做的产品刚上线没多久，因为要新增功能，导致页面的信息架构重新调整，相关人员怨声载道，产品的使用用户也会增加对产品的认知成本。可见，产品架构的可扩展性是有多重要，产品经理需要根据实际情况及未来可预见的规划进行构思，争取将产品的维护成本降到最低。

4. 产品经理---“需求”篇

一、需求是什么？

不是用户说要什么，是为了解决什么问题，甚至是为了解决的这个具体问题底层满足的是用户的什么普遍需求。

看透用户的能力，是天赋也是可以培养的。像乔布斯就是天赋，他不做任何竞品调研，他知道用户要什么。

二、需求的本质

贪、嗔、痴---贪婪、憎恨、固执

每个人都逃脱不掉对名、利、权的追逐，每个人！

三、需求的分类

1.基本型需求、期望型需求、兴奋性需求（注：需求所属类别不是一成不变的，会随时间变化）

2.娱乐、归属感、沟通、意见领袖、利益、获取支持和资讯、自我情感表达、爱和被爱、社交、分享、安全、尊重

四、需求与产品

产品功能、产品内容都能与 需求分类2 一一对应，不信可以试试哦~

五、获取需求

定性分析主要依靠分析者的直觉和经验，对分析对象进行判断；

定量分析是依据数据和模型，对分析对象进行数量上的评估

*具体获取方式：

1.行业调研分析

行业调研报告分析

竞品调研

业内专家、资深专业人士

2.用户调研分析

用户访谈

调查问卷

3.经验分析

自己变成用户

观察法和用户日志分析法

挖掘用户需求：根据需求本质，进行拓展

4.运营数据分析

六、需求评估

识别并定义需求类型

1.KANO模型

用于判断需求是 基本型、期望型、兴奋性或其他可疑。

基本型需求：需求痛处。一旦实现了一定的数量脊桐，再增加该类需求，用户的满意度都不再提升缺配；

期望型需求：需求痒处。需求的增加与用户满意度呈线性增长；

兴奋性需求：需求暗处。只要实现一部分，用户满意度明显提升；

2.减法

专注！专注！专注！

产品定位减法

产品价值减法

产品场景减法

3.产品专家评审

4.A/B测试

六、需求优先级

1.要基于背景和现状

2.满足基本型需求的同时，为了运营要适当加入 期望型、兴奋性

3.需求是动态变化的，要实时调整

4.研发难度

原则：重要紧急程度、经济收益紧急程度

七樱扮坦、管理需求

1.估算工作量

2.需求变更

本文参照《神一样的产品经理》，推荐阅读！

5. 怎么样才算一个合格的产品经理

优秀的产品经理需要这些特质：

1.识别市场机遇

对市场现状的了解和分析能够帮助产品经理构想产品的愿景和战略，它决定了产品是什么，能为用户带来什么样的价值，甚至产品是否能活下去。

2.用户意识

人们很容易掉入“这个东西这么好，怎么没人用呢“的思维陷阱，尤其是当一个人在ta的岗位工作越久，学习到更多专业的知识后，更容易被“厉害的功能”绑架。产品经理应该始终站在用户的角度去思考问题，清楚地了解用户的需求和痛点，真正地为用户解决问题，提供优质的用户体验，才能留下用户。

3.逻辑思维

产品经理的逻辑思维应贯穿在整个产品生命周期。需求阶段的归纳总结能力、分析推理能力；设计阶段的产品架构能力、流程判定的能力等，都需要逻辑思维的支持。它不仅仅是帮助研发团队将需求和任务顺利完成，更决定了你的愿景是否能够通过产品准确地传达给用户。

4.分析能力

你做出来的产品和功能用户真的需要吗？怎样的路径、什么样的文案可以更好地引导用户？大数据使得我们能够通过收集和分析用户的种种行为数据，来了解用户的习惯和偏好，也为产品的优化提供了可靠的数据支撑。但数据如果没有被对比，没有被有效地分析，它就仅仅是数据而已，不会成为驱动。

5.沟通能力

产品经理需要同时具备跨层级沟通（从高管到员工）和跨部门沟通（从用户代表到研发工程师）的能力，能将业务需求清晰、准确地传达给工程师，同时能理解技术实现的大体过程和难度，将其再反馈给业务部门，是团队协作中的重要一环。

7. 项目管理能力

项目管理是为了保证产品能按照预期、保质保量的上线，而产品经理作为项目的发起者，是最理解项目目标和业务需求的人，自然要参与到项目管理中来，把控项目，从而保障团队始终朝着统一的目标前进。项目管理需要对整个项目的研发流程进行监控，同时要保证各个环节以及各个团队角色间能够有条不紊、高效地协作。

6. 产品经理最重要的技能是什么

产品经理最重要的技能是什么

1）需求痛点挖掘：这是一种读心术，真正洞悉用户深层次的核心诉求以及人性，知道用户到底想要的是什么，而不是用户要什么就提供什么。优秀的产品经理总是能够提出解决用户核心需求的方案，并且能够超出用户预期，总是能够精准把握用户的人性和心理。

2）需求分析评估能力：这是一种判断术，能够精准判断哪些需求该做，哪些需求不该做，是做加法还是做减法。优秀的产品经理总是能够强有力地说服别人为什么要这么做，这需要很深的产品功力，而且对自己的判断非常自信，有自己的独立思考能力，并且始终如一坚持自己的判断。

3）超强沟通能力：善于沟通，和市场、运营、开发、测试等多端对象都能进行无缝沟通。这是一种洗脑术，将合适的信息在合适的时间、合适的地点，通过合适的方式传达给合适的人。优秀的产品经理总是能够强有力地说服团队和别人按照自己指定的方式执行，实现自己的想法，并不是强制别人，而是让别人自愿和自发地去做。

4)顶层思考的能力：每个产品都需要做框架性的抽象，既包括系统性架构，也包括商业性架构；

A.逻辑性强：尤其是在应对较大的系统时，需要极强的逻辑思维能力，做产品框架的构建。

B.商业思维：需要懂商业，懂格局，要能够站在更高的层次看问题，从而做出更有利于公司、有利于行业、有利于社会的决定(产品符合未来的市场，并有商业模式)。

有帮助请及时采纳哦⊙∀⊙！ 谢谢

7. 产品经理如何提升需求分析能力

作为产品经理，需求分析能力非常重要，这里分享一下需求的基础。
第一，洞察行业动向。产品经理的一项重要职责，就是产品规划，而规划的基本，就是你的产品，是否在行业发展的趋势上。这一点最重要，因为你的产品，甚至你的企业，存活的基础，就是社会需求，没有需求的产品，是卖不动的。而如何做，个人觉的，如果公司实力够大，最好可以投入一些资源，找专业的机构协助，获得最真实的数据，如果公司无此实力，建议follow行业内的领跑者。
第二，洞察自身长短。有些产品好，但是很遗憾，自己的实力无法做，那怎么做？要明确自己的长短，自己能够覆盖到的市场细分，能否建立起自己的核心优势，核心优势也可以看做一种核心竞争力，无外两点，1、不可复制性，2、资源稀缺性。1无不用讲，2的话，举个例子，火车上卖盒饭的，就是掌握了渠道的稀缺性，即便饭菜口味一般，可能也不缺销路。
第三、洞察用户的购买习惯。这也要通过市场调研完成，所谓购买习惯，一是用户的购买要素构成如何，品牌？质量？价格？还是什么？举个例子，路边摊的打火机，一两块钱一只，这时候消费者的诉求，只有“火”，所以，产品方面，无需去考虑什么颜色，样式，等等，永远重要的一点就是“成本”。同样是火机，Zippo的诉求就完全不一样，要内涵，收藏价值等等。决定这个的就是你的“用户细分”和“定位”。
第四、掌握以上，再思考具体的执行方式，用什么手段获取最真实的信息，等等，可以去网上或书上获取信息。

8. 产品经理的核心价值 怎么做产品

产品的核心价值

每个做产品的人，都会时常把“核心价值”挂在嘴边。很多产品新人都会认为，只要满足用户需求，不就有价值了吗。但反观目前市面上做成功的产品，强大如微信，控制了那么大流量入口，仍然十分克制，优先级最高的两个Tab仍然是聊天列表和通讯录，其余几十个功能，都收进发现和钱包中。如知乎，有流量可以做广告，有用户可以做会员体系，有服务可以做增值，如果单纯为了赚钱，那么有很多种方式，但知乎的核心价值仍然是高质量的答主和其产出的高质量内容。这么做无法体现产品的核心价值，更可能破坏核心价值。一旦高质量的答主和KOL流失，那么整个知乎社区必定崩解。反观目前知乎的发展，给优秀答主和知名机构加标注，给用提供识别优质内容的手段；给知名答主出电子书，上线付费问答值乎，开启专栏文章打赏以及付费讲座平台知乎live，另外好把精华内容制作成知乎日报，在其中添加广告，所有推出的功能和产品，都围绕高质量的答主和其内容做服务。

下图是用户体验要素的Web模型，核心价值就是战略层包含的目标，也是最底层的支撑。要设计的功能，都要围绕核心价值去拓展。

参考一下

为什么一个产品急需发现且明确核心价值？

1. 发现核心价值，能够选择综合考量下来最优的功能。一个产品能够满足用户需求的点也很多，能够做的功能有很多，但围绕核心价值的功能性价比最高，也最受用户认可，最有商业价值，对公司最有利。

2. 基于相同的核心价值设计的功能，逻辑统一。逻辑一致的功能可以互为补充，用户群体相似，需求相似，就好比如2仅仅是2，但2*2=4。围绕同样核心价值设计的功能能够彼此增益。而零散的成本高，吃力不讨好，让产品定位渐渐模糊，用户群体也越来越不清晰。

3. 有单一的核心价值能够让用户产生认知。想要依靠多种价值，满足用户多种需求的产品在初创阶段往往很困难。产品起初强调核心价值可以让用户更容易理解这个产品解决什么问题，满足什么需求。如我们要聊天就想起微信，要骑单车就想起摩拜 OFO，要看新闻就想起今日头条。假如把微信、摩拜、今日头条放在一个产品里，你会怎么认知这个产品。

那么，如何找到核心价值，什么样的功能才算体现核心价值。

围绕核心价值的功能的衡量标准：离开了它，产品就不能真正解决用户的实际问题。

用完即走

张小龙在2016年初的公开演讲上，探讨了微信的设计理念以及它的四个核心价值点。他提到一个观点：

我想跟大家分享微信的一个基本价值观，我们认为一个好的产品是用完即走的，就是用完了我就走了。一个好的产品不是黏住用户，我们认为任何产品都是一个工具，对于工具来说，好的工具就是应该最高效率地完成用户的目的，然后尽快离开……

“用完即走” 的概念激起了热烈的讨论，有人说你腾讯流量这么大，肯定是用户体验至上，有资本提供用完即走的服务。但我们创业型产品，当然是希望能够更多地黏住用户，提高使用频率，提高用户活跃度。

说起一个产品，很多产品就会根据指标来衡量这个产品，日活、月活、单次使用时长、打开率等各类指标。只关心概念上指标的产品经理，就会把焦点放在怎么去活跃用户、吸引用户上，产品会做得比较肤浅，更多地是在做用户运营的工作。产品经理关注的是真正解决用户的问题，而用户不够活跃，可能是多方面的，不能牺牲产品围绕核心价值的逻辑一致性来完成运营目标。简单打个比方，你卖饮食并不是因为好吃美味，而是做活动，做推广，这样看起来数据好、用户多，但其他做得美味的商家会轻松把你打败。火如今年的喜茶，虽然品牌溢价高，性比价低，但产品本身真的很不错。

用完即走并不是不要粘性，而是在用户的问题之中恰到好处地解决问题，解决完问题后，就不要强硬地留住用户，不然反而引起用户反感，破坏用户对产品的认知。

买一辆车，你到达目的地了，你会因为里面空调特别凉爽，所以一直待在里面吗？此时，你为了粘性，硬生生把用户锁在车里，用户会爽？用户还敢买你的车用你的车吗？吹空调不是车应该做的事了。

显然，张小龙提到的用完即走，是十分合理的。用户粘性，应该是围绕核心价值去做的粘性，而不是附加价值上做的粘性。产出稳定、性能好、起速快、毛病少的车，下次用户换车自然还会选择这个品牌。但用户不会单单因为一辆车的空调好而选择一辆车。搞清楚这个逻辑很重要！

如果来关注用户粘性的产品经理来做，甚至会把KTV、个人影院甚至娱乐方面的VR游戏等放进车里，留住用户然后投入各种广告，而不是去关注设计，打造车子。这就违反了整个产品逻辑，失去了核心价值，结果只能是没有解决到用户出行的核心需求，却因为把这么多功能塞进那么小的车内空间而产生更多的问题。

朋友圈里有各种新闻、营销内容、鸡汤段子，当然能够提高用户粘性，但如果这样设计，未来朋友圈很可能就变成一个今日头条这类纯信息内容的产品，而不是社交产品。想要跟亲朋好友分享生活的用户就会渐渐流失，那么整个功能就失去它原本的意义。此后，微信多了个今日头条的入口，辛苦打造的熟人社交朋友圈，就会消失。

微信现在搜索的范围很广，朋友圈、文章、公众号、小说、音乐、表情，这是搜索下的四个分类，搜索界面下还有一个 “看一看” 的入口，可以看出微信也在承载更多信息和资讯阅读的价值，但可以看出微信在这方面的节制，仍然在不破坏核心价值的上进行尝试，也把这些功能隐藏得足够深。

为了吸引用户而去做的功能，往往会产生更多问题。但为了围绕产品的核心价值，为了解决用户问题而去吸引用户的功能，将使产品获益无穷。不要短视，以产品暂时的目标为指引。

要确保产品是真正解决用户的问题，你用尽各种方法将大量用户留在产品上，但并没有从实际上解决他们的什么问题，他们就对你毫无价值，长远看，是不会继续留在你的产品上，从商业价值上看他们也几乎不会产生付费意愿。如过去三年大火的O2O概念，很多产品都是一补贴，用户量和活跃度就上来，补贴一没用户就大量流失。就是因为没能从实际上为用户解决问题。

以下几个问题需要注意：

1. 方法看似可以，但实际上很糟糕。如强迫用户看大量的新手指引，然后填写测试题。看似解决了问题，实际用户体验很糟糕，用户都不愿意看指引就已经离开你的产品。对于这种情况，我们可以使用轻量级的指引，如使用场景下的浮层提醒，谨慎地去指引用户。

2. 方法看似可以，但可行性差。这点无须过多阐述，为了增加美观度吸引用户而增加大量动效，最后导致大量用户手机性能不足以支撑，出现卡顿、闪退等问题，那最后的结果是得不偿失的。

3. 方法看似可以，但问题却不需要解决。如设计师会觉得老人机上的字体过大，不美观，这看似是个问题，其实不是问题。老人机就是为了老人而服务的，相较于老花眼而需要的大字体，美观性对于他们来讲，根本没有价值。

用超过预期的方式解决问题

在考虑产品的核心功能时，不仅要判断是不是真正满足了用户需求，还要判断是不是以超预期的方式满足。

假如用户原本在用产品A，那么要用户转移到我们的产品上来，不仅仅是做到比A好，而是要超预期的好。我们把超预期给用户带来的愉悦感和实际好处记为X，把用转移产品的心理成本（新产品的陌生感，尚未建立的信任感）记为Y1，把用户转移的实际成本（比如学习新产品的成本，注册、转移资料花费的时间，损失掉产品A上的积累）记为Y2。

故必须保证X > Y1 + Y2.

这样的产品看似简单，我们往往会低估了竞品的问题，以为对方的产品多么糟糕，模式不行，所以我们的产品肯定行。但问题是，竞品不好不代表你的产品能好，产品目前状况不好的原因有很多，可能是市场不成熟，可能是用户需要被教育，还没有培养起习惯，甚至是用户的问题根本不需要解决，就是你的产品和竞品所处的行业长远看基本要死掉。所以超预期X很难估量，也很难清楚Y1和Y2的值。

所以说产品经理的工作更多是在实际摸索中展开，没有什么理论能帮助到你，只能实践出真知。在摸索的过程中逐渐对Y1和Y2有了大概的判断，然后判断自己产品的X要做到大于Y1和Y2行不行。很多产品经理认为好的产品只要X>0就行，但实际上至少大于Y1+Y2，不然就算市场是蓝海，你提前进入建立起一定的市场壁垒，但只要别人一进来，你就会死掉。