从产品小白到产品经理，这是你的必备知识点

“你觉得作为产品经理最重要的三个能力是什么?”作为一名2岁的PM，我的答案是：学习能力、分析能力、执行能力。你问一名产品总监或者CEO，他可能会说，“产品感觉、管理能力，商业思维，等等。” 不同的阶段对产品经理的能力要求必然不同，作为一名产品小白，首先你要有很强的学习能力来符合这个岗位对你的要求。

产品经理的整个工作流：市场分析、竞品分析、用户研究、需求分析、产品策划、产品推进、产品管理，每一步都有一套有效的方法论，学习并掌握这套方法论，形成自己工作中的知识体系，工作起来才能少走弯路、得心应手。

1.市场分析

1.1SWOT分析

内部环境：优势(strength)，劣势(weakness);

外部环境：机会(opportunity)，威胁(threat)。

优势：公司内部充足的资源，而竞争对手不足;

劣势：公司内部缺乏的资源，而竞争对手充足;

机会：用户存在的需求还没有被满足，公司有资源满足用户的需求并且能盈利;

威胁：影响公司产品盈利的因素。

1.2商业模式

对产品的内外部环境进行分析之后，下一步就需要考虑产品的商业模式，即盈利模式。互联网产品的商业模式大致可分为以下几种：

1.3商业模式画布

商业模式画布是一张可以直观展示产品商业模式的图表

作为一名产品经理，尤其是大公司的、产品已进入成熟期的产品经理，很少有机会参与到公司对市场的决策中去，但是对产品的市场分析可以帮助我们更透彻的理解产品的定位和市场走向。

2.竞品分析

2.1如何选择竞品

A.产品经理做竞品分析的能力可以分为以下三个等级：

1)初级：能找到同类产品的竞品，照猫画虎的抄袭竞品的功能;

2)中级：能看到竞品做的动机和原因，并根据项目和公司所处的阶段来选择不同的竞品或竞品的不同阶段;

3)高级：没有竞品的时候，能够从横向和纵向对比来发现竞品。

B.选择分析的竞品可以分为三个类型：

1)核心竞品：同目标用户、同使用场景、同用户需求的第一梯队产品;

2)重要竞品：目标用户、使用场景、用户需求有一个不同，在其细分领域的第一梯队产品;

3)潜在竞品：目标用户、使用场景、用户需求不尽相同，但可借鉴性强的第一梯队产品。

2.2竞品分析的维度

竞品分析一般先分析产品的业务层、其次是功能层，最后是表现层。具体的分类如下：

市场：政策、容量、阶段、商业模式、占有率等;

资源：团队、投资方、合作方、供应链、渠道、现金流等;

数据：月活、UV、营业收入等;

运营：活动时间、活动成本、内容建设、转化率等;

功能：核心功能、非核心功能等;

用户：画像、行为等;

UE、UI：流程、主色调等。

2.3如何获取信息

1)公开信息：靠关键词在网上能搜索到的信息

例：百度/谷歌、app annie、公司财报、36kr、艾瑞/易观、微博/微信;

2)半公开信息：需要一定的统计、检测和合理的估算才能得到的信息

例：亲自体验、Excel、爬虫;

3)内幕信息：需要通过谨慎推理以及特殊方法才能得到的信息

例：沙盘推演、人际情报、黑客。

3.用户研究

3.1定性研究

定性研究的主观性偏强、科学性较差，一般样本量较小，用于直接收集用户对产品的使用习惯。

1)用户访谈

访问者提出一系列的问题，从受访者的回答中搜集用户需求，从肢体语言中洞察他们对产品的使用体验。

2)情景访谈

访问者在用户的实际工作或生活环境中与受访者进行交流，以确定受访者的使用习惯、需求和痛点。

3.2定量研究

定性研究是探索性研究，用于定性的确定用户需求，最后还需用定量研究的方法来完善和测试。

1)问卷调查

问卷调查不必解释了，需要注意的是问题的设计多而杂不如少而精，调查的用户样本量要尽可能的大。

2)数据分析

当你与领导或同事对于某个决策有争议时，用数据说话是最简单直接的解决办法。PC端用百度统计、移动端一般用友盟，可以很方便的查看网站的PU、UV、平均访问时间、数据漏斗等关键性指标。

3)A/B测试

A/B测试用于比较两个相似的版本，除了一个影响用户行为的变量之外，其他的条件要相同。当样本量很大时，A/B测试的效果会非常显著。

比如向用户推荐福利的时候，是用“残忍拒绝”还是用“有钱任性”的文案作为关闭按钮时，对比一下就能看到点击率的区别。

4.需求分析

4.1需求来源

A.被动告知需求

1)主要业务部门：包括市场、运营、管理层等主要业务部门，可能是一个新的业务、活动或者机制的更改;

2)客服：当用户频繁咨询或投诉一个问题时，客服会将问题提交给产品经理评估;

3)用户意见反馈：用户通过挑错建议等方式反馈的问题，需主动收集，评估并及时处理。

B.主动收集或挖掘需求

1)竞品分析

竞品分析的方法在前面已经说过了，通过竞品分析我们可以挖掘部分本产品未解决的用户需求。

2)用户研究

作为产品经理，前期的竞品分析、用户研究都是在挖掘用户需求。另外，在挖掘用户需求的时候，我经常会用画脑图穷举法用来做最后的需求梳理。“遇到的问题”即用户需求，“解决办法”即相应的功能。

4.2需求类型

对于已上线的产品，在做产品迭代的时候，可以对需求池的产品进行分类，以帮助我们来确定需求的优先级。主要的需求类型有：新增功能、功能改进、体验优化、BUG修复等。

4.3需求优先级分析

我常常会用两个四象限分析法来综合评估需求的优先级，这里建议一个团队的产品经理以来做这一项评估。很多时候我们会遇到很多需求都在一个象限里，所以这里推荐两个四象限分析法，可以综合评估。

1)“用户量-使用频率”四象限

2)“见效快慢-开发难度”四象限

经过分析和评审之后基本可以决定全部需求的优先级了，优先级最高的需求在第一期的MVP(最小可行性产品)中实现，优先级较低的需求放在下一版或下几版的产品规划中分批实现。【推荐了解：黑马程序员产品经理课程】

5.产品策划

5.1业务流程图

A.什么是业务流程图?

描述具体某个业务实际处理步骤和过程的流程图。

B.为什么要画业务流程图

1)了解业务：帮助整个团队了解产品的业务是如何运转的，并且对业务流程中不合理的地方进行优化;

2)梳理需求：帮助产品经理梳理业务需求在产品线的各个阶段中功能模块之间的关系;

3)传达需求：研发工程师构建技术架构和明确技术分工会主要参考业务流程图。

C.怎样画业务流程图?

1)确定范围

确定业务流程的起点和终点，是截取某一段业务进行详细描述，还是整体业务模块进行描述。

2)确定要素

谁，在什么情况下，做了什么事，这个事需要什么前置条件，又输出了什么，是在哪里完成的?搞明白这几个问题，我们的要素就确定了。

2)梳理呈现

怎么画流程图这里不赘述了，用什么工具、怎样更精美都是不重点，重点是关键要素的搜集和确认。泳道图是常用的一种表现形式，一般横向代表用户角色，纵向代表各阶段。

4)评审确认

a.让涉众参与评审：业务流程图中涉及到的用户角色或部门要尽可能让他们参与到评审中来，切忌自己YY;

b.层次分解，重点突出：流程很复杂的，可以在一个主图里展示主要流程，在其他图里分别将主流程中待展开的流程进行展开。

5.2页面流程图

A.什么是页面流程图?

描述产品的全部页面相互间关联的流程图。

B.为什么要画页面流程图?

1)了解全局：对于整个团队，页面流程可以从表现层了解产品的全局;

2)梳理业务：反复研究页面流程图并优化，可以使整个产品变得更加简约;

3) 传达需求：设计师要设计多少个页面，前端工程师要写多少个页面一目了然。

C.怎样画页面流程图?

1)找出所有的页面：找出所有物理层面的、真实存在的页面，切忌不要像业务流程图一样具体到某个功能和模块;

2)用有向线条关联：把所有相关跳转页面用有向线条关联，页面流程图较复杂的可以反复研究如何让其更简约的呈现;

3)增加条件判断：从上一个页面跳转至下一个页面的条件是什么，在页面流程图里体现出来，对于设计师来说非必须，但是技术来说可以了解业务。

5.3功能结构图

A.什么是功能结构图?

描述功能之间从属关系的图表。

B.为什么要画功能结构图?

1)梳理需求：帮助产品经理思考并清晰产品的功能模块及其功能组成，避免在产品需求转化为功能需求时，功能点出现缺失;

2)传达需求：对于不确定的产品样式问题，可以一种较为简洁明了的方式来表达;

3)提高效率：发现功能结构不合理的地方可以快速做出调整，避免在产品设计的细节上浪费时间。

C.怎样画功能结构图?

1)提炼主要功能模块：我们可以通过业务流程中涉及到的功能需求去提炼出主要功能模块;

2)细化功能粒度：根据自身业务，将主要功能模块拆分到更细的粒度。

5.4信息结构图

A.什么是信息结构图?

从产品的实际页面中将数据抽象出来，组成分类的图表。

B.为什么要画信息结构图?

1)梳理信息：帮助产品经理梳理产品的信息组成，避免信息内容在展示过程中出现遗漏和重复;

2)传达需求：作为技术建立数据库的参考依据。一条信息的存储有很多附加属性，具体的是存成字段还是数据表，还是中间表或者关联表，这些都需要在完成PRD之后与数据库技术人员进行讨论。

C.怎么画信息结构图?

1)将产品的全部信息进行罗列，建议使用脑图;

2)将产品的信息进行梳理使其结构化。

5.5原型图

在产品策划阶段，产品经理通过业务流程图、页面流程图、功能结构图和信息结构图确定了产品都有哪些页面、页面里有哪些功能和信息、哪些操作是如何跳转的之后，就需要通过原型图将我们的产品直观的表达出来。

对于设计师，原型图是最重要的参考物，他们关心的是产品各元素之间的排版和布局;对于研发，原型图是他们了解功能，评估功能复杂程度，边界条件是什么，异常情况怎么处理的最直接的参照物;对于测试，他们需要通过原型图辅助写测试用例，以及原型图是否穷尽各个场景;对于领导，他们的事情比较多，原型图的易读性也成了他们最关心的产出物。

画原型的工具一般使用Axure，网上的教程有很多，不会的同学可以自学。这里想说一下什么样的原型图才算得上专业。

1)设计符合用户的认知模型

相同属性的功能进行分组，相近属性的功能放在一起。例如：我的资料、我的订单、我的收藏、我的资产会归纳放到“我的”里边;“加入购物车”和“立即购买”经常会放在一起。

2)交互逻辑无缺失

例如：商品列表页浏览前和浏览后的文案的颜色有无区分?商品列表页过长时导航栏是否需要悬浮置顶?

3)异常场景不遗漏

例如：页面加载失败时提示用户什么?用户从WiFi切断到数据流量时提示用户什么?

4)关键字段有规则定义

例如：发布时间的字段是显示年/月/日还是月/日?显示月/日的话跨年了怎么办?发布时间在一天以内的话是显示多少个小时前还是显示月/日?

5)极限情况有定义

例如：用户名最长为多少字?页面没有数据时展示什么?页面数据过多是怎么展示?

6)全局组件有说明

全局组件指的是产品通用的组件，例如：断网、操作成功、操作失败、正在加载、空数据界面、404等。

6.产品推进

产品策划的方案，主要是原型图，经过部门内评审、技术可行性评审、公司高层评审(根据项目的实际情况而定)之后，就进入到了产品推进阶段。这个阶段你需要经历的过程有编写产品需求文档(PRD)，需求对接、设计跟进、前端跟进、研发跟进、测试跟进和上线跟进。本阶段涉及的专业性知识不多，但是雷区却不少，我结合自己的工作经验来分享一下哪些雷区是你需要避开的?

1)PRD编写不细致

技术在开发时会按照你的PRD来执行，如果你对需求的描述不够细致甚至是逻辑缺失，会导致技术在开发时加入自己的理解来实现，最后达不到产品预期。其次，因为需求描述不完整导致在开发过程中新增需求，是技术最痛恨的事情。为了不增加研发工作量，PRD编写越细致越严谨越好。

2)需求对接不透彻

设计师、前端、技术和测试会根据你的原型图和PRD来开展相关工作，有时候你以为需求已经通过原型图和PRD表达的很清楚了，但是在需求的理解上一定存在信息不对称的情况。集体需求对接会是必不可少的，将需求的对接做到尽可能的透彻，对接会结束之后一定要给相关人员发邮件;在产品推进过程中，要及时与相关人员沟通和跟进，将需求理解不透彻导致返工的风险降到最小。

3)需求中途变更

前期的需求分析、方案评审等环节，产品经理是必不能偷工减料的，一旦对某一环节的忽略抱有侥幸心理，最后的后果就是研发过程中需求变更。如果需求中途变更，一方面会增加相关人员的工作量，另一方面会损害自己的口碑。如果中途因为一些事先没有预料到的因素，比如领导临时变更需求，作为产品经理要做好需求管理，实在需要变更的要尽量说服相关人员，推动大家去完成。

4)技术砍需求

一个需求有时候从技术的角度来考虑，为了减小自己的工作量或者根据他们自己对业务的理解，会出现砍需求的情况。产品经理需要做的首先是倾听，合理的话可以讨论，不合理的话要拿出我们的用户研究、需求分析结果以及需求对接邮件据理力争。

5)工作进度模糊

在需求对接会上，项目规划和确认是必不可少的一环，相关人员需要根据工作量评估自己工作的时间节点，大家根据约定的时间来完成工作。如果缺失这一环节就会导致工作进度模糊，上线日期延期。其次，根据项目的需要可以考虑每日站会和阶段性的产出物评估会。

7.产品管理

7.1产品发布

前面所有的工作都做完之后，最后就需要让产品发布上线。绝大多数情况我们做的都是产品迭代更新的发布，面对版本更新，如果用户的使用习惯发生了改变，用户一般都是不愿接受的态度。面对这种情况，需要我们用非技术和技术的手段去规避。

A.非技术手段

1)以网站公告、app推送、短信或邮件的方式预先通知用户;

2)严格控制产品的测试和验收质量，确保更新内容的可靠性，避免上线之后又撤回的尴尬。

B.技术手段

1)A/B测试：页面或流程设计A/B两个版本，随机让比例相同的两部分用户使用，通过数据分析选择效果好的版本作为正式版本发布给所有用户。

2)平滑部署：让一部分用户继续用A版本，另一部分用户开始用B版本，如果用户对B版本没有反对意见，再逐渐扩大B版本的使用范围，直至全部迁移。

3)增量发布：将所要发布的功能本身进行分割逐渐发布，注意更新的节奏，确保产品的稳定性。

7.2版本管理

前边在需求分析时已经提到，产品经理需要做好需求池管理，根据需求的优先级来规划产品的版本。一般我们可以将产品的生命周期划分为探索期、成长期、成熟期和衰退期四个阶段。通过对多个app的迭代时间进行研究，发现不同阶段的产品迭代周期大致如下。

探索期和成长期：最重要的核心用户是种子用户，他们最大的特征是忠诚度不高，有很强的好奇心，迭代频率为小步快跑，2周左右迭代一次;

成熟期：最重要的用户是主流用户，他们更注重产品的体验和稳定性，因此这个阶段的迭代周期适合大小结合，小需求(新增功能、bug优化)小步快跑，1个月左右迭代一次;大需求(新增模块，UI改版)的迭代周期可以保持在3个月1次。

衰退期：最重要的用户是相对“固执”的主流用户，只要产品还能满足他们的需求并确保使用体验，他们是不会轻易放弃产品的，因此这个阶段的迭代更新会是节奏相对较慢的小需求迭代，迭代周期可以在2个月左右。