互联网产品经理几种必备文档的介绍
【摘要】
互联网产品经理几种必备文档的介绍
【全文】
BRD Business Requirements Document，商业需求文档。这是产品声明周期中最早的问的文档，再早就应该是脑中的构思了，其内容涉及市场分析，销售策略，盈利预测等，通常是和老大们过的ppt，所以也就比较短小精炼，没有产品细节。
商业需求文档重点放在定义项目的商业需求。BRD要能说出客户碰到的一个或多个商业问题，并且通过公司的产品能够解决这些问题。接着一个 —— 通常是新产品或者现有产品的改进来解决这些问题。BRD也可能包括一个高级的商业案例，例如收益预测，市场竞争分析和销售/策略。BRD通常是由拥有产品经理，产品营销经理或者分析师头衔的人撰写的。在小公司，可能由高级主管或者甚至创始人撰写。BRD通常是一份连续的1-3页Word文档，或者不超过10页的Powerpoint文档。
MRD Market Requirements Document，市场需求文档。获得老大的认同后，产品进入实施，需要先出MRD，具体来说要有更细致的市场与竞争对手分析，通过哪些功能来实现商业目的，功能/非功能需求分哪几块，功能的优先级等等。实际工作中，这个阶段PD可能的产出物有Mind Manager的思维图，Excel的Feature List等。
市场需求文档(MRD)重点放在为一个被提议的新产品或者现有产品的改进定义市场需求。与BRD指出商业问题和解决这些问题的解决方案不同，MRD更深入提议解决方案的细节。它包括一些或者所有这些细节：
a. 解决商业问题所需要的特色 b. 市场竞争分析 c. 功能和非功能需求 d. 特色/需求的优先级 e. 用例
MRD通常是由拥有产品经理，产品营销经理或者行业分析师头衔的人撰写的。MRD通常是一份连续的5-25页Word文档，或者正如之后描述那样在一些机构中甚至更长。
PRD Product Requirements Document，产品需求文档。进步一细化，这部分是PD写得最多的内容，也就是传统意义上的需求分析，我们这里主要指UC(use case)文档。主要内容有，功能使用的具体描述(每个UC一般有用例简述、行为者、前置条件、后置条件、UI描述、流程/子流程/分支流程，等几大块)，Visio做的功能点业务流程，界面的说明，demo等。Demo方面，可能用dreamweaver、ps甚至画图板简单画一下，有时候也会有UI/UE支持，出高保真的demo，开发将来可以直接用的那种。
产品需求文档(PRD)重点放在为一个被提议的新产品或者现有产品的改进定义市场需求。与MRD侧重于从市场需要角度看需求的不同，PRD侧重于从产品本身角度看待需求。通常在特点和功能需求上更深入细节，并也可能包括屏幕截图和界面流程。在那些MRD不包括具体需求和用例的机构中，PRD就包含这些具体内容。PRD通常是由拥有产品经理，行业分析师或者产品分析师头衔的人撰写的。PRD通常是一份连续的20-50页Word文档，或者针对复杂产品甚至更长。
提醒：一些机构将这里描述的MRD和PRD合并成一个文档，并称最后的文档为MRD。在这种情况下，MRD包括本段描述的内容，也包括上一段描述PRD的内容，并且可能超过50页。
FSD Functional Specifications Document，功能详细说明。有一点像“概要设计”，这步就开始往开发衔接了，产品UI、业务逻辑的细节都要确定，细化文档并保持更新。相应的，有很多内容，比如表结构设计，要由项目经理来编写了。
功能规格文档(FSD)把焦点集中在实现，定义产品功能需求的全部细节。FSD可能通过一张张的截屏和一条条功能点来定义产品规格。这是一份可以直接让工程师创建产品的文档。与MRD和PRD侧重于以市场需要和产品角度看需求不同，FSD把重点放在了以表格形式定义产品细节，再让工程师实现这些细节。FSD也可能包括完整的屏幕截图和UI设计细节。FSD通常是由拥有产品分析师，工程领导或者项目经理头衔的人撰写的 – 作者通常属于工程部门。通常一个连续几十页的Word或类似文档。
写好MRD的10种技巧
MRD-“市场需求文档”，是产品经理或者产品市场经理编写的一个产品的说明需求的文档。这些文档用于计划一个新产品或修正一个已有的产品，是被工程师团队开发产品时使用。
在硅谷的一些公司，MRD仅仅覆盖high-level的功能。在这种情况下，产品经理通过创建了另一个文档-通常指的是PRD(产品需求文档)来定义更加详细的产品需求。
在本文中，我用术语“MRD”泛指所有那些由产品管理和/或产品市场团队创建的，为工程师团队传达产品需求为目的的文档。
写好MRD的10种技巧
1、从用户角度的编写
从用户角度编写需求内容。使用“用例(Use Case)”和“用户角色(User Personas)”来达到这个。考虑用以下两种方法来详细说明你们公司正在开发的SFA(sales force auation)软件的“Login”的功能性。
方法A：
用户通过一个要求用户提供证书的登陆界面，然后软件允许用户带着特定的权限进入系统。软件鉴别这些证书，在鉴定通过的基础上允许用户访问那些他们有权限访问软件的功能部件。
方法B：
Mike是一个销售经理，Cathy是一个销售代表。当他们打开软件，他们看到登陆界面。他们通过用户名和密码进入系统。如果用户名和密码是正确的，他们能登进系统。一旦登陆进系统，Mike能访问软件所有的功能部件。Cathy只能访问那些对销售代表有有效的功能部件。
哪个方法更加容易阅读和理解?就我的看法,毫无疑问，"方法B"。还有，它同时减少了令人烦恼的阅读!
2、使用Screen Shots 使用Screen Shots或者mockup来你的想法。我们中很多人都听说过“一张图片好比一千个文字”。当提到写MRD的时候，一个screen shot好比一千个文字!
举个例子,看看下面这个screen shot，你需要多少字来描述?我想可能不只一千个字。
3、用简单的语言编写
在我超过11年的行业中，我通常注意到的(更多是令我懊恼)一件事是用很做作的语言来写的MRD。我想这个主要是因为MRD听起来是正式的和专业的原因吧。
相反，想象你写的MRD是写给你的在工程师团队工作的朋友。你的目标是帮助他理解你需要什么，以便于他能开发产品实现这些需要。这个将有助于你避开陷入那些令读者人厌烦(有时他们会把MRD撕碎然后再碎片喂给碎纸机)的用做作的语言的陷阱。
还有：
a)保持简短的语句，把长的语句分解成多个小的语句。 b)避免大篇幅的连续文本，把他们分解成多个小的章节。 c)把大块文本内容分解成，screen shots，表格、重点列表等等。
4、小心的使用模板
我发现MRD模板非常有用。他们的几个好处包括： a) 模板提供了一个标准的格式，使那些不得不阅读大量MRD的读者更加容易阅读。
b) 模板让新的产品经理快速的写MRD变得容易，因为公司与公司之间的MRD内容是不同的。
c) 模板确保你不会忘记所有需要在MRD中覆盖描述的部分;
然而，一些公司过分的使用模板。一个硅谷最大的公司之一有一个所有部分被强制使用的近60页的模板。我觉得这个让人觉得非常难以忍受并且有几个负面的作用：
a) 产品经理害怕但又不得不写MRD - 几乎和不得不和Dick Cheney去南德克萨斯打猎一样(译者按：副总统Dick Cheney在南德克萨斯打猎时意外的打伤了和自己一起去的打猎伙伴)。
b) 工程师团队害怕但又不得不阅读MRD。 c) 写MRD和读MRD都需要花大量的时间。
我你使用MRD模板，但确保他们不要过分的长。还有如果需要，确信产品经理可以灵活的跳过模板某些部分和创建新的内容。
5、区分需求的优先级
在这些年里，我从来没有碰到一个工程师团队实现了MRD里包括的所有特性的没有删减的项目-通常由于那些我们控制之外因素!
这就是说作为MRD作者的产品经理，当出现需要决定取舍的时候，应该提供一个办帮助让他们决定那些特性要实现那些可以推迟。
区分需求的优先级是一个最好的能帮助完成这个事情的办法。我发现把需求分等级就像P1，P2，P3...这样工作的刚刚好。在这个分类中-P1是最高优先级，P2是第二高优先级等等。
最好的决定一个已经明确的需求的优先级方法这个需求实现后的好处-包括你的客户和你的公司。在实际实践中，最好是和其他多种因素一起综合决定。
我推荐你只要包括P1，P2，P3的需求在你的MRD中，在多数的项目中更低的优先级可能未必会实现。还有这样也让MRD变得更加容易读。
6、说明"是什么"和"为什么"，但不要"如何" 产品经理为理解客户的需求负责，然后基于这些理解定义什么和为什么需要开发. 有一件比任何事情让开发者发疯就像在几英里外都能听到的汽笛在他们耳边尖叫一样的是一个令人痛苦的详细描述了怎样实现每一个需求细节的MRD。
考虑你们公司正在开发的以下两种描述CRM“Login”功能的方法。 推荐-描述“是什么”
Mike是一个销售经理，当他打开我们的CRM软件，他会看到一个登陆界面...登陆界面建议提供“记住我”复选框。如果Mike在点击登陆按钮之前选择了该复选框，我们的软件将记住并且在他下次来到登陆界面时自动填写他的名字。
不推荐-描述“怎么样”
Mike是一个销售经理，当他打开我们的CRM软件，他会看到一个登陆界面...登陆界面建议提供“记住我”复选框。如果Mike在点击登陆按钮之前选择了该复选框-将通过Javascript 保存他的名字以cookie的方式写到他的硬盘。当cookie写到硬盘后，用户名和密码将被发送到服务器。下一次Mike来到登陆界面时，Javascript 将读取他的cookie，成功读取后，Javascript 将是适当的DOM命令填充登陆页面上的用户名。好的产品经理擅长理解用户的需求和描述什么需要实现，好的工程师擅长决定怎么样实现它。好的工程师希望能自由的决定怎么样最好的实现用户希望得到的东西。
我注意到有背景的产品经理尤其喜欢描述“如何实现”。如果这些描述的就是你，应该从现在开始不要再做这样的事了。工程师们将会感谢你。
附：这里有一些例外的情况-当在描述“是什么”中描述“怎么样”是必要的，当描述“是什么”的最好的方式和/或唯一的方式就是描述“怎么样”的情况。
7、覆盖非功能性需求
尽管功能性需求描述产品的功能，非功能性需求描述系统特性，如：
a)性能 b)可伸缩性 c)可用性 d)国际化 e)等等... 我注意到因为许多产品经理和产品市场人员认为这些是“技术细节”，而在MRD中被忽略。我发现这些是我的MRD中非常重要的一部分，工程师们会非常感激在MRD中定义这些需求。
要点：当写非功能性需求的时候，尽可能的是使他们可度量(可测试)。否则，QA不能测试它们，你将没有办法知道完成的产品是否已经实现了这些非功能性需求。
8、评审&修正
我有一个朋友-我们叫他Matt(他的真名叫Steve)。Matt在硅谷一家成功的公司做产品经理工作。最近我在午餐的时候碰到他是告诉我一个非常有趣的故事。
他们雇用了一个有三年的产品经理。在他被雇用的几个月里，不知何故他让他的产品经理同事和工程师一样疏远他。
他是罪犯?他基本上认为他的MRD就像一个法令。他写了它，但不想和任何人评审或在反馈的基础上修改它。他仅仅想工程师团队没有问任何问题的拿着它并实现它们!
不要像Matt的同事那样。确信做到和你的产品经理伙伴和工程师团队评审你的MRD。保持一个敞开的思想然后在评审反馈的基础上更新MRD。这将帮助你写出更好的MRD，工程师将喜欢你(或者至少少恨你一些)，你的团队也将创造更好的产品。
9、定义市场目标和定位
大部分我看到过MRD在覆盖了市场目标(谁将买和使用户你的产品)和定位(与竞争对手的产品比你的产品定位怎么样的)的方面做的很好。
我还看到过一些没有描述市场目标和定位的MRD，他们通常会这样争辩：“为什么工程师们需要知道这些?拿到定义了什么是需要的还不够吗?”
这些问题(谁将买和使用户你的产品和与竞争对手的产品比你的产品定位怎么样的)的确有一些正面价值，我发现许多工程师想知道为什么一个产品或特性要开发，谁将使用他们，什么是他们可以另外选择办法。
这些信息帮助他们和产品组的其他成员想象最终用户并从而更好的为创造成功的产品工作。我的建议的尽可能的(在MRD中)包含这些信息。- 它们不一定要很详细，只要包含几个段落就足够了。
10、包含一个术语表
如果你的MRD使用了新术语或在非通用的地方是使用了常用术语-确保在MRD后面包含一个术语表。
当你像这样说“我们的软件将提供SME用户通过选择WAP或PSMS开MRC帐单”时，术语表将确保你的所有读者(有些可能不是技术人员)理解你的意思是什么。
1.如何做好需求分析?
今天谈谈产品需求分析的具体落地，不教大家怎么去辨别真伪需求，也不谈虚的方法论，客观说，产品经理这个层次，大多数是没能力和眼力去决定一个需求做与不做的，这需要的不仅仅是经验阅历，以及专业能力，更重要的是需要学会借势和博弈，观主有很长一段时间，关闭需求的占比保持在三分之二以上，连大BOSS的需求也照关不误，这并不是观主多厉害，而是引导了对方自己去关闭自己的需求，关于这点，之后有机会再说。
假设：在你面前有一个需求，是必须要做的，我们该从哪几个方面着手?
1)搭建设计框架：
框架越大越完善，需求置于其中思考，就越周全。
a.设计背景：
第一步：探寻需求本质，需求实现后，到底会带来哪些改变;
第二步：比较当前现状，需求未实现前，现状到底是怎样的?
第三步：在公司战略/商业模式/业务目标/用户痛点中，找到需求的价值立足点，说白了，要和公司大方向契合，两个产品经理做同一个需求，看的远的那个，才会真的把需求实现的更好!
举例：天猫的创立，在一定意义上，就是为了解决淘宝假货遍地的问题，用品牌来约束商品质量。
b.设计动机：
需求是一种目的，而设计是推动着业务向目的前进的过程和手段。
所以，设计动机，说白了就是为什么设计?即如何根据需求目标，去剖析得到设计目标，这个设计目标，是必须要起到支撑需求目标的作用的，在这个基础上才能进一步规划设计思路。
c.应用场景：
前两点完成后，大家往往会忽略应用场景，缺乏这点的设计框架，是无法形成闭环的，应用场景，简单的说，就是你这个需求，在经过设计实现后，在什么样的情况下被谁去触发和操作。
很多设计，有时本身没有好坏，要看用在何处，一个好的设计框架的作用就是帮你全面思考和分析，在这点上，应用场景是十分重要的一环，不以场景为条件的设计，都是耍流氓，通用型设计在这个个性化的时代，已经不再能让用户妥协和买单!
举例：比如o2o常用的关注公众号送礼功能，整个设计的框架，就是如何在线下快速地推的应用场景下，去实现所有人(用户和地推人员)的快速操作和反馈，降低时间成本带来的用户拒绝和流失。
2)确定需求抓手：
说白了就是设计的切入点。
a.涉及模块和流程：
需求的实现，会牵涉哪些模块和功能和流程，新增还是修改还是拓展?
b.影响模块和流程：
需求的实现，会影响哪些模块和功能和流程，新增还是修改还是拓展?
这点很重要，很多产品往往会聚焦需求本身涉及的部门，而忽略带给其余模块流程的影响。
这里说个原则：任何公司，不管资源多寡，原则上，尽可能借用现有的功能，尽可能小的去改动成熟体系，尽可能减少不必要的联动。
c.需求底线：
这点也非常重要!!!
观主带了那么多团队，遇到太多的产品经理，聊完需求，都不清楚需求方的底线在哪，作为产品经理，不仅仅是为需求方在服务，你要考虑方方面面，比如公司的资源和成本等等，同时，需求永远是做不完的，而需求方永远是急切的，如何去客观的根据一个需求的价值和投入来综合判断很重要。
为什么要知道底线?底线就是你灵活设计的余地，如果两个需求摆在你面前，资源永远是有限的，如何把一个更重要的需求做的尽可能完善，同时最低成本去满足另外一个需求，取决于你是否知道每个需求的底线!
3)提出解决方案：
也就是你的设计思路，这是产品经理的基本功，不展开说，观主一直习惯，做好解决方案后，先不和需求方沟通，先自己放空一下后，换个人格来自我质疑，把整个设计反案过一遍，确认每个可能存在问题的点，都可以对答如流，再去找需求方(傲娇一下：七年多产品生涯评审均一轮过，无反复!!!)
4)规划具体功能：
设计方案一旦确认，就是具体功能的设计，还是要在设计框架和抓手下综合思考，相信各位也看出来了，观主觉得需求落地最核心的就是设计框架和抓手，在前两点思考全面的前提下，后续功能设计这些，不会有太大问题，都属于产品经理的基本功了!
顺带插一句，在具体功能设计中，还是有很多技巧的，比如可以通过试纸测试去低成本试错。
5)制定核心指标：
在大数据时代，做一个需求，实现只是其一，要养成持续关注其成长的习惯!
所以，需求分析时，就需要考虑，哪些数据是与这个需求有关，或者能证明需求的价值的?同时如何去埋点获取这些数据?观主经常遇到产品经理，只想着分析数据，不思考如何埋点。
6)切分需求路线：
这一点，和需求底线有关，一般如果一个需求在初期，只实现最基础的目标(即只达到需求底线)，那在其之后，会有后续的需求版本和规划，这就是需求路线，制定一个清晰的需求路线，让需求方可预见未来，也是让自己更全方位的去思考和规划!
总结：大多数产品经理喜欢关注如何设计功能去解决问题，殊不知，最重要的是动手(具体设计功能)之前的框架和切入点梳理，还是老话：站的高!niao的远!(想的远!做的好!!!)
在产品经理的招聘要求中，经常看到的字眼是：产品方案、产品需求、项目管理、用户研究、沟通能力……文档的输出是一个最直接的体现。在公司每个人都很忙，多数人无法和其他人当面交流，除了我们做的产品之外，其他同事认识我们的过程，很多时候就是文档，产品从立项到上线，每个阶段都需要有文档输出。
以下从7个阶段说明产品经理需要输出哪些文档。
1. 立项阶段
产品经理需要进行市场分析、用户研究、竞品分析等，输出的文档有：
市场与竞品分析报告：市场容量背景，竞品数据、操作流程、用户体验、优势、用户构成等;
用户研究报告：这个部分内容很多，根据实际进行选择具体方法输出不同形式的总结，譬如问卷调研、用户访谈、用户观察、头脑风暴等等;需要考虑的问题是这个产品是满足哪一类用户的哪一项需求?解决用户的什么问题?是提升效率，还是更加有趣好玩?
产品立项评审申请：在以上的市场与竞品分析、用户分析基础上，提出立项申请，包含项目背景、项目目标、产品形态、项目投入与产出等。
2. 产品需求阶段
立项成功后，就开始进入产品需求阶段，这时就要更加深入的分析用户需求，准备如下文档：
产品策划需求，包含：产品目标、需求概述、产品逻辑、主要功能特性、数值策划;产品交互设计稿;
数据需求文档：产品关键指标、指标体系、计算逻辑、数据上报、报表样式等;目的是产品上线后对产品的评估，用户行为数据的分析，对产品优化提供决策参考;
产品运营方案：产品上线发布策略、产品运营后台设计，产品营销推广，内容运营，运营工作安排，持续运营优化等;
客服文档：包含产品说明、产品逻辑、用户有可能遇到的常见问题解答等内容，如果产品相对复杂，需要对客服进行现场培训指引;
3. 开发实施阶段
产品进度文档：不少公司的产品经理、项目经理是同一个人，因此，产品经理会全程跟进开发过程，及时输出进度邮件;建议开发过程中的问题解决，尽量采用邮件进行备忘;
4. 测试阶段
产品体验邮件输出：测试过程中，产品经理要进行产品内测体验，明确测试关键点，输出体验邮件，注意其中的数据测试部分，保证数据准确上报;测试后的产品优化改进文档;
5. 灰度发布
灰度确认邮件：灰度发布前，结合前期的各项文档，检查产品是否可用?灰度逻辑是否清楚?产品风险是否有规避措施?产品数据是否可以正常上报?运维监控告警是否到位?
产品体验报告：灰度发布过程中，产品经理必须及时跟进产品体验，例如内部同事体验、首批灰度用户体验反馈、产品可用性测试等;
数据分析报告：按日输出，根据既定产品目标，在灰度中评估产品是否有助目标达成，满足既定的各项标准后，再继续放量;
6. 正式上线
上线总结：产品上线绝对是一个里程碑，这时产品经理需要输出产品总结报告，总结经验，发现问题，答谢项目成员。
7. 产品运营
产品运营报告：按时间分，有日报、周报、双周报、月报，各自产品重要程度与阶段、运营节奏不同，分别选择适合的输出周期，建议在新产品上线初期，按日输出产品数据日报，按周进行产品分析周报。一般的报告内容有：当前产品数据指标、数据走势分析、竞品比较、产品体验分析、产品迭代优化进度等。在产品的持续运营过程中，数据分析、用户CE、用户反馈收集报告等贯穿始终。
经历过很多次网站改版，对网站改版的计划做个小结，帮助需要的产品经理。
改版文档里有几点是必须写的：
1、改版目的
清晰知道为什么改版，新的网站战略定位，如何在保持原有优势的情况下，突出新产品。
2、现状分析
包括现有整体架构、内容维护体系、社区状况、存在问题分析，清楚现有状况，才能知道改版需要调整什么。
整体架构：回顾旧网站架构，明确枝干，保留主体产品系列;修剪分支，确定有特色的辅助产品，去除流量太低的副产品。
内容维护体系：确定内容维护团队的工作量，为改版后的产品工作量分配打基础，快速弄清楚新产品上线后原有团队是否可以高效率进行维护。
社区状况：分析社区中的热门、冷门板块，为改版提供发帖量、PV、用户活跃度、话题趋势数据。
存在问题：用列表列出旧网站存在的各个问题(架构、UI、功能、人员后勤服务、页面代码、技术、硬件用户体验等问题)，改版网站可以根据这些问题逐个击破。
3、改版内容
列出改版要做的调整，不需要十分详细，当对这次改版不是很清楚的人问起的时候，产品经理可以一项项精简快速的列举出来。
4、新产品
网站改版，除了对旧产品做调整更新，重点还有新产品。单独列出新产品，说明新产品形态、模式、方向、能带来的效能，吸引老板和投资者注意力。
5、新版架构
详细列出新版的架构细节，细到首页、频道页、SNS、社区、管理后台、广告系统、数据中心、电商等的具体设置。
6、时间安排
改版预期的时间安排，如果改版比较复杂，需要分成一期、二期。。。，描述每期完成的内容，通过时间节点完成每项工作。
7、人员安排
安排本部门人员与直接配合其他部门人员工作时间、内容，使每项工作按部就班进行。
8、维护团队
对原有维护团队重新调整，各人分配到新的产品模块，使新版上线后可以有条不紊的工作，提供给用户各种先进、有效的功能内容。
9、硬件系统
改版一般还是原班人马进行，大多不会更换程序语言，主要是硬件方面的调整。对产品支撑需要的服务器、防火墙硬件系统，强大的硬件系统，才能充分提供给产品快速、功能强大的后台服务，加载速度更快、搜索能力更强、同时在线人数更多永远是改版的主题。
10、经费预算
人员工资、软件采购、硬件采购预算，小公司老板比较关心做这次改版花了这么多人力物力到底是多少，列出经费预算让工作安排比较心里有数。
本文由：http://【郑州网站建设-郑州天石科技】提供
产品经理必备技能之数据分析
数据分析往往是从文本上反应产品的各类信息。但是，产品经理在做产品的各个阶段时不能一味的依靠数据分析。这时就需要我们有精确的数据分析的技能。首先要了解数据分析的三点核心：
1.什么是数据分析?(What) 2.为什么数据分析?(Why) 3.如何数据分析?(How)
下面我们将以实例的形式重解读第二个问题和第三个问题。大致分为以下几步：
第一步：确认数据分析的对象
产品名称：企查查APP V9.1.8 产品愿景：中国企业信息搜集的综合体，为投资者、金融相关从业者等提供企业的一站式信息服务。
分析范畴：产品迭代、产品优化、产品分析/验证
背景概述：自定义。注意，数据指标的制定远比数据分析过程要重要的多或者说更加富有创造性。
第二步：制定数据分析指标
1.商业模式/盈利方式分析：免费增值模式，先做成流量入口，后期分享流量红利扩大转化率。
2.了解产品现状/定量分析产品 2.1 用户分析 用户规模：
用户群体可大致分为个人、企业，分析个人和企业用户的人数比例，明确整体分布情况。 每月/周/日的新增用户、流失用户、回流用户的比例走势，选择恰当的走势变化渠道;
用户质量：产品粘性及病毒性的反应，体现在用户的活跃度上，一般包括，日活跃(DAU)、周活跃(WAU)和月活跃(MAU); 采用同期群和用户分类的分析方法，特定用户群体的特定分析过程，用户质量也是渠道或营销活动效果的间接体现，以便后期及时的调整和处理;
用户质量的标准制定，包括忠诚用户、联系活跃用户、流失用户等等，为反应不同指标设置特定的用户质量指标;
2.2 应用分析：
启动次数，某日/周/月的启动次数占所选时段总启动次数的比例，直接反应生活时间成本; 版本分布，对开发和维护的意义非常深刻，展示累计用户排名前10的各个版本变化趋势，可以帮助了解每个版本的新增用户，最新版本的升级情况，目前的哪些版本状况;
使用情况，统计周期内，一次启动的使用时长;一天内启动应用的次数;用统一用户相邻两
次启动间隔的时间长度;
设备终端和错误分析也是很有必要的;
2.3 行业分析：
a. 行业数据可以帮助了解行业内应用的整体水平，各个指标的数据、排名及趋势，有助于衡量应用的质量和表现;
b. 了解行业数据，了解自己的APP在整个行业的水平，通过多个维度对比自己产品与行业平均水平的差异，从而知道产品的不足之处。
业务场景：
1. 首页支持企业名称、人名、品牌名等信息的模糊查询，并且在搜索系统之下直接提供四个维度的一级辅助搜索条件。
2.企业信息维度算是一款企业信息服务平台的资源性优势，也是一款内容应用的核心模块。不同类型的用户对不同类型的信息感兴趣的程度各有不同，因此，要记录和挖掘用户行为特征数据。
产品分析：
企业信息查询第一级别的功能是搜索，第二级别的功能是条件搜索;理论上讲，后者在搜索的精确程度上要更加有优势。
数据指标：
1. 不同检索维度的搜索量;
结论：以信息检索维度的搜索量，选出哪些企业信息搜索维度置于条件搜索中，并决定其分
布的顺序和位置;
2. 不同描述维度的查询量
结论：
a. 以信息描述维度查询次数，区分重要企业信息，量化区分不同信息的关注度和用户价值; b. 交叉分析不同维度的信息，用户属性，比如：行业+查询维度，综合分析不同特征的用户群的核心关注点。
c. 内容受欢迎程度及需求的迫切程度，面向不同类型的用户，比如：普通用户、企业用户，内容分级、资源分层更好地配合免费增值模式、会员等级产品形态。正对不同用户特征给予不同的需求满足形式都是值得尝试和探索的，单
一、传统的直销的商业模式或许有被迭代升级的可能;
小结
产品数据分析意义在于指导产品设计，传达感性认知背后的理性意义。无论数据分析的结论积极还是负面，都是产品价值映射，作为产品经理，我们必须投以客观的态度。
如果你喜欢我们的文章，欢迎加入我们。
12.15
貌似现在一个很常见的IT业新职位就是产品经理，很多大牛都自称产品经理，不过它确实是一个对个人综合素质要求非常高的职位，人称“产品灵魂的设计师”。有志于成为优秀产品经理的朋友来看看下列哪些方面的能力可以帮助你更好地朝自己理想中的状态迈进。
一、沟通能力
成功的产品经理必须是优秀的沟通者。
从我所认识的优秀产品经理们分析来看，他们所具有的最共同特征是“在工作中具有优秀的口头及书面沟通技巧”。
为什么沟通很重要?在许多公司，产品经理最为一个决定性角色扮演着沟通枢纽的角色，如下图所示。
而在不同角色间有效沟通能力，往细了说，就是与不同的个性类型沟通的能力，即在用不同角色沟通的时候讲不同的“语言”。对于有效沟通来说，重要的是你使用目标听众的“语言”。
例如，大多数工程师倾向于是“内向型”，而大多数销售/市场专员倾向于“外向型”。这意味着，与工程师沟通相较而言，和市场专员沟通时需要使用“另一种语言”。同样地，当你和主管沟通时，相对于“树的级别”而言，你必须把更多的表述重点放在更高层次的“森林级别”，然而许多产品经理却错误的依然跟主管们在谈论着这颗树是多么的美丽。
二、没有权力的领导
成功的产品经理拥有在没有正式的权力下也能成为优秀的领导的能力。
多数公司，产品经理被期望在多个领域扮演“领导角色”。这包括领导项目团队，领导产品策划和路线图，领导跨部门沟通等。
然而，在多数这样的情况下产品经理并没有统筹这些部门的权利。
没有权力如何领导别人?我想说，使用联合影响，谈判，关系网和其他类似技巧。
没有权力是否可能领导?我对此的想法被这个问题总结的很好，我的回答是个反问：甘地和马丁·路得金有多少权力?
三、学习技巧
这点，用我个人的话来说，就是优秀的产品经理擅长做不擅长的事。
优秀的产品经理必须具备快速学习的能力，市场变化很快，新技术总是拔地而起。“差异化产品”在今天不到6个月内产生，有时甚至更快。
我认为多数公司在雇佣产品经理时会犯的一个错误是-他们看重“强悍的专业知识”。
举个例子，一个做软件安全的公司，他们寻找一位拥有5年以上软件安全方面工作经验的产品经理。我认为这是一个错误的方法。相反，51230.com的邵光荣老大哥就说过，他们产品部门招人，反而都是新手优先，因为怕过多的经验会限制创新能力和个性发挥，这也难怪，人家做的就是充满个性的婚恋网站。
当然，更好的方法是，寻找一个拥有适当工作经验的产品经理，并且拥有快速学习的能力。这种方法对我来说实现的很好，我手下那些最好的产品经理在被雇佣以前，都没有他现在所从事工作的专业知识。
四、商业敏锐度
成功的产品经理对基本的商业原则也有很好的理解。
他们了解如何辨认市场机会，竞争分化的重要性，创造成功产品的策略，定价，促进，合作，分析，声明，及其他。
这并不意味着他们需要工商管理硕士学位。实际上，我接触过的多数成功的产品经理并没有工商管理硕士，但是他们对商业基本原则都有着充分的了解。
五、热爱产品
成功的产品经理对产品有一种固有的爱。
他们因跟上市场上新产品的步伐而高兴，和他们的到手的一样多。他们注册了大量的“betas”网站，下载最新版本的软件并使用，等等。
他们为设计好的产品而高兴，即便并不是他们公司制造的。他们讨厌设计糟糕的产品，即便是自己公司制造的。
他们热爱创造伟大的产品，无论它是一个全新的产品，还是改进现有产品。
六、关注细节
任何事务是由细节组成的，关注细节,是创造伟大产品的必要基础。
SteveJobs曾经说过：
iMac不仅仅是颜色或是半透明或是外壳的形状。iMac的本质是使每一个元素集中在一起成为最出色的消费电脑。在我们最新的iMac，我坚定我们摆脱了风扇，因为使用一个不会一直嗡嗡作响的电脑工作让人更愉悦。
扔掉风扇不仅是Steve一个固执的决定那么简单，他背后需要一个巨大的工程，计算出如何更好的处理电源功耗，以及如何更好的通过机器散热。这是我们产品出发的核心点，顾客购买我们，就是为了让我们去解决所有这些细节，所以他们容易和喜欢使用我们的电脑。
成功的产品经理观注细节不仅仅是提到产品性能，并且在竞争力分析，项目计划，和几乎每个他们主要负责的活动。
我的话：同样，这种细节体现在你所做的报告中、计划中、任务策划书中。在内容上，请尽可能的描述到实施细节;在表现上，请尽可能的体现一个产品设计师的UI设计细节。如果一个连报告都不能让人愉快阅读的产品经理，怎么指望做出来的产品能有优秀的用户体验。
七、常规的产品管理技能
一个产品经理需要这些技巧来完成日常任务。他们包括写市场分析报告和需求分析报告，执行竞品分析，创造产品路线，陈述产品性能和利益，定义用户界面，等等。
每个公司都需要这样的技能。这一技能放在最后，是因为我认为拥有上述六点的产品经理很容易学到这些技能。
总结
也许这七项素质还不够，那就通过学习能力去学习更多吧，无论是专业素养还是个人成长，学习和提升从来都是无止境的。
推荐阅读：
产品经理必备知识（精选6篇）05-22
产品经理必备技能如（通用6篇）10-26
产品经理必备知识手册（共6篇）07-01
产品经理必备技能培训（共6篇）06-11
产品经理互联网文档（通用6篇）04-27
互联网产品经理文档（通用6篇）05-24
产品创新与产品经理11-20
产品经理调研05-21
产品经理产品理解（推荐9篇）10-13
产品经理产品分析（精选9篇）12-14
