产品经理需求分析范文

下面小编给大家整理了产品经理需求分析范文，本文共12篇，供大家阅读参考。本文原稿由网友“Ggghhhhhh”提供。

篇1：产品经理的需求分析与调研

一个故事

一天晚上，一个孩子和妈妈走在回家的路上，突然孩子说：“妈妈，我要吃鸡腿”，但是在附近没有肯德基之类的店铺啊，妈妈犯愁了，怎么办呢?可不能饿着孩子啊，妈妈又突然想起来中午买的批萨还有一些，于是拿出来给孩子吃，孩子一看还有批萨，很高兴的接过来开心的吃着了。

鸡腿=批萨?潜在需求是：饿+好吃的

什么是需求？

广义的说：

需求来源于用户的一些“需要”，这些“需要”被分析、确认后形成完整的文档，该文档详细地说明了产品“必须或应当”做什么

误解：

1、用户说出来的就是需求2、用户说的需求就是应该做的

我们的用户是谁？

“用户”(user)是一种泛称，它可细分为“客户”(customer)、“最终”用户(the end user)和“间接用户”(或称为关系人)。掏钱买软件的用户称为客户，而真正操作软件的用户叫最终用户。客户与最终用户可能是同一个人，也可能不是同一个人。

需求开发的主要困难与对策

1、用户有他自己的想法：

“我回答了你们的问题，讲了该讲的。我还要干自己的事情，别打扰我了。你们自己想办法把活干好吧……”

2、用户说不清楚需求

“比如说买鞋子。我们非常了解自己的脚，但很难用语言说清楚脚的大小和形状。通常拿鞋子去试，试穿时感觉到舒服才会买鞋”

3、双方误解需求

有个外星人间谍潜伏到地球刺探情报，它给上司写了份报告“主宰地球的是车。它们喝汽油，靠四个轮子滚动前进。嗓门极大，在夜里双眼能射出强光。……有趣的是，车里住着一种叫做‘人’的寄生虫，这些寄生虫完全控制了车。”

4、用户经常变更需求

如果在项目开发的初始阶段，开发人员和用户没有搞清楚需求或搞错了需求，到了项目开发后期才将需求纠正过来，导致产品的部分内容需要重新开发。毫无疑问，这种需求变更将使项目付出额外的代价。

如何开发需求调查

起草需求调查问题表问题表可以有多份，随着调查的深入，问题表将不断地被细化根据经验，用户通常没有耐心回答复杂的论述题，所以问题表应当以“选择题”和“是非题”为主。制定问题表最简便的方法就是从《用户需求说明书》的模板中提取需求问题

确定需求调查的方式

与用户交谈，向用户提问题。向用户群体发调查问卷参观用户的工作流程，观察用户的操作与同等、专家交谈，听取他们的意见分析已经存在的同类软件产品，提取需求。从Internet上搜查相关资料。

[产品经理的需求分析与调研]

篇2：产品经理-需求分析的六原则

原则1：永远不要显得比客户更聪明

了解需求，而不是去批评客户。你熟悉的是产品和技术，而客户客户比你更熟悉业务的环境，客户总是知道问题在哪儿，你的工作就是要让他们自己愿意说出来，而且要深入的去挖掘问题的本质和客户的潜在需求。产品经理应该有逐步成为领域专家的意识，只有这样业务和产品才可能真正匹配。

原则2：尊重用户的现实选择

客户永远是对的，许多客户提出的需求，在经过了我们人为的过滤之后，被打上“不现实”、“不可能”的印记而束之高阁。想法一定是建立在客观上的。因为我们的产品是客观的，用户的使用也是客观的，他们的想法也是客观的，客观的就一定是存在的，存在的就一定是合理的。我们不要轻易否定用户的需求，不要轻易向用户说：你的想法是错误的。根据现状，我们需要提供最合适的解决方案，而非最好或最贵的方案。我们能够做的不一定是最好的，我们不想做的有时候往往是客户最需要的，找到最合适客户的，而不是最合适我们的。不要把客户当傻瓜。这个世界上没有傻瓜，自以为对方是傻瓜的人才真的是傻瓜，不要忽悠客户，不要欺骗客户，如果非要在这个前面加上一个期限的话，我希望是“永远”。

原则3：转述需求的人也是客户

只要是对我们的产品和业务提出需求，就是我们的客户，应该一视同仁。转述者一般会把自己想象成设计者，但是他们对产品或许很熟悉，但是对整个业务可能不熟悉，因此，他们成不了设计者。因此要考虑到第三方可能会遗漏或补充一些额外的需求。每个人都期望产品能做好，这种强烈的成功心理容易让人们产生日晕心理，从而影响我们对需求的筛选。

原则4：客户和用户要区别对待

客户是客户，用户是用户，有时候一致，有时候分离，这是我们首先要搞清楚的。产品为最终用户设计，需求的功能转换为最终用户的使用要求而确定。用户决定产品，我们需求工作基于用户，始于用户，归于用户。客户是多样的，价值导向也是多样的，我们的产品能否承载多样化的客户价值决定了产品能否实现最终的交换。因此需要时刻考虑产品真正实现客户价值。产品的最终价值是通过用户来体现的，脱离了用户的产品，就是“皮之不存，毛将焉附”。

原则5：用最简单的文字工具记录需求

所有人都能懂的东西，最不容易出错;不需要再学习的东西，最不容易出错;不要希望客户能花更多的时间来了解需求转换后的模型;保持沟通的通畅，是了解需求的保障。

原则6：天下没有免费的午餐

要得到就一定要付出，付出的量并不一定和得到的量相等，作为产品经理来说，就是要让客户尽量少的付出，尽量多的得到，但永远不会是免费的。客户的需求都是现实的，都是合理的，因为这些需求都是客观的，但我们通常习惯于用主观去看待客观。客户的要求都是可以实现的，没有不可以实现的需求，只有我们了解的不够深入的需求。成本第一还是需求第一，客户把这个问题交给了我们，我们就用用我们的智慧去解决这个问题。我们能做这事-这是所需的费用。

[产品经理-需求分析的六原则]

篇3：教产品经理写好产品需求文档

做好产品需求文档的这十步，是经过长期的实践文章和反复验证而得到的。可能这里描述的不是很全面，但他已经足够让你做一个成功的产品需求文档。做好这几步花费的时间要以项目的大小、复杂程度、个体学识、基本技能熟练度而定。

你要做的是一个让人无可争议的产品，为了做好他，你必须做好前期的准备工作。你需要去了解你的顾客、竞争对手、产品团队的实力和需要的技术。你需要从顾客、用户、竞争对手、分析师、产品团队、销售队伍、市场、公司职员等收集他们能发现的问题和可能的解决办法。这里有很多的工作需要你去完成,在“成功的产品背后”这篇文章中有详细的描述。

建立良好的交流也非常重要，它会影响着产品团队。如果你的准备工作做的够好，你也会变得越来越有信心和说服力。

2、确定产品的目的

任何一个好的产品都开始于一个需求。你必须清楚的了解这个需求，你的产品如何达到这个需求。

产品经理需要提出一个清晰、简明的价值主张，让它很容易被接受，要让产品团队、管理人员、用户、市场人员清楚的明白这个产品到底是什么意图。虽然这听起

来很简单，但是也只有少数产品才有这样的价值主张。考虑“velevator pitch

”(电梯间演讲、电梯行销)测试。假设你在做电梯的时候遇到公司CEO，他问你产品的意图是什么，你能在电梯到达之前回答这个问题吗？如果不能，你就还有

工作需要做。也许是你的说明没有针对性，他可能表现出来和其他产品做的没有什么明显区别；也许你提出的观点不能和你的用户产生共鸣；也许你解决的是一个非常规的问题，可能你想应用一种技术。这个价值主张可能需要满足公司的产品战略。注意你不需要阐述太多的细节，从某些方面来说，一个有价值的观点应当是越简越好。

产品需求需要确切的指出这个产品发布的目标，同样的这个目标也有优先之分。例如，你的目标可能是：1）易用，2）零售价不足$100，3）和前期产品很好的结合。然后你需要说明如何去测算。对于“易用”这类项目，你需要明确指出产品可用性达到某个水平。这是通常用目标用户来定义。可用性工程师能测算出你的产品对目标用户的可用性，也测算出可用性问题的严重程度，同样你可以说明没有重大的可用性问题。

这里的关键就是让每个人都知道产品成功的时候是什么样，还有给产品团队在设计和实施中遇到问题如何进行取舍的指导。

3、确定用户原型、用户目标和用户任务

现在你已经明白你想要解决什么问题，下接下来就要深入了解目标用户和顾客，在这步中，和你的PD（产品设计）紧密联系非常重要。

用户原型

在这个阶段，PM需要和很多用户交流，需要花费大量的时间去直接观察和讨论。现在我们需要对用户和顾客进行分类，然后决定那一类是我们的首要用户。

比如你正在做一个像eBay一样的互联网拍卖服务，你同时拥有买家和卖家，在这之中还有使用频率少的用户和经常使用的用户，不难想象还有个别特殊的用户，比如团体公司采购者。

PM（产品经理）和PD（产品设计）需要首先确定类型是最重要的，然后尽量对这个用户群的特征进行详细的描述，以便使用这个模型去指导产品的设计。这个模型通常称其为“人物角色”。

虽然是想象的，但是应该是典型的、可行的和真实的，让你能够使用。这个想法来自与一个能代表这类用户的本质的原型。

举个例子：

“里昂是一个超级卖家，46岁，男性，居住在Fresno，经营小型摩托车配件。虽然他开着一个小店，但是他的生意大部分来自EBay,每个月平均有400多次交易。他出售的东西品种非常多，但是他最受欢迎的商品还是哈雷戴维森的负重袋。他自己拥有两个哈雷，还开着1993年的丰田皮卡。里昂已经结婚了还有两个小孩。

里昂买电脑仅仅是因为他需要使用EBay,除了eBay和电子邮件很少再使用其他东西。里昂已经在EBay上销售产品已经三年了，他学会了在eBay应该掌握的东西，他非常自豪的拥有超过5000的信用度。如果EBay更改了网站，特别是销售的过程方面，对于他来说改变习惯、学习这些变更是非常困难的。

里昂已经形成了自己的习惯，星期一列出销售的商品，星期五拍卖结束，设法让在收到货款的几个小时内出货。”

但愿这样的描述能让你了解里昂和知道他是怎么来的。当我们考虑新功能时，我就要问问自己里昂会是什么发应，为了让他能顺利的使用这个功能我们需要做什么。

注意缩小范围，让他仅仅描绘必不可少的。满足所有人是徒劳的，通常最后没人会满意，所以尽量提出几个最重要的和最流行的角色描述是非常重要的。同样，如果你不去精确的定位你的目标用户，你就只会存在模糊的概念，你会发现理解你用户的反应非常困难。你要倾向于设想，让你能更像你的用户。

用户目标（用户意愿）

一旦我们确定并描绘了我们主要的用户类型，我们就需要找出用户在使用产品中的目标(想要干什么).这听起来很简单，但是解开根本问题是非常具有挑战性的，特别当你周围的人告诉你已经解决了他们想要的。

从CEO、销售代表、工程师到客户，每个人都太兴奋而不能帮助你找到解决根本问题的办法，他们会告诉你在某个地方添加一个快捷按钮，或则添加一个功能仅仅是因为竞争对手有，或则是改变成他们喜欢的颜色。

最好的解决办法取决于清晰的了解到底什么问题需要解决，每个用户模型可能有不同的目的，需要在用户原型涉及的方面中进行寻找。有可能将来某个功能解决的问题并不是主要用户需要达到的目标之一。

用户任务（tasks，用户为达到目标使用产品而需要做的任务）

掌握了用户原型与他们的目标愿望，我们就开始着手设计任务来满足他们的目标意愿，这是产品制作进程中最核心的部分，也是创造力和创新力被激发的地方。

许多优秀的产品仅是用更好更新的办法解决一个已有的问题，有时候这种办法仅仅是应用一个种新技术，但是大部分是来自深刻的见解而使一种新方法的产生。例如TiVo（美国市场占有率第一的数字录像机）在电视节目录制的老问题上面想出一个全新的办法，让顾客更加容易地实现他们的目标并且建立了电子设备一个全新的类别。

注意我们虽然谈到了目标和任务但是还没有谈到具体的功能，这些功能都需要达到用户目标而必须的。你以后会发现许多功能都是低优先级或则是完全多余的。

以“必须功能”这个理由可以排除很多功能。讽刺的是，你用越少的功能，你的产品被发现得越来越强大。这是因为产品的功能越少，你的用户就会发现并使用更多的功能，成功的使用越来越多的功能他们就认为你的产品非常强大。这些理由都是违反我们直觉的，我们大多数人都不能和我们的用户一样，我们在自己的行业中愿意比用户花费更多的时间去探索功能和容忍复杂性。

4、定义产品原则

现在你需要开始把你的需求和用户体验定义成详细的要求。同时你仍然会面临着许多的决定和权衡，为你的产品标准做出最佳的决定是非常重要的。

在大多数的产品团队中，每个成员都有做好产品的原则，但很少有两个人有同样的想法，这些差异都会导致不可思议的结果。

尝试和制订一系列指导整个团队的产品原则是非常有价值的，这些原则需要具体到域名和项目。

用TiVo举例，在产品团队工作开始时，以下这些产品规范就被建立，并在团队里传达：

1.它是娱乐的

2.一个傻瓜式的电视

3.一个该死的视频设备

4.平滑柔顺的

5.没有模式和深层次

6.尊重观众的隐私权

7.像电视一样强大

这些规范很大的影响到产品的定义而且在很大程度上加大了难度，但是他们确实是成功产品的来源。比如易趣的口号就是：

1、易于使用 2、安全3、有趣

它将在该项目中，在面对众多问题而做出决定的时候进行指南。

5、产品原型和检验

这是一个拿出你想法的阶段，创造力和创新力拿出成就的地方。

很多人都容易犯一个常见的错误，他们对产品设计规范太有信心，结果一旦得到beta的测试他们就必须调整产品。但是肯定beta测试版并不是进行重大改变的时候，所以才会有许多首次发布的产品离目标太远。

对于许多产品来说，这个时候你可以用大量的原型做很多的实验。首先，下面的三个非常重要的测试你可能需要做。

可行性测试

一个直接的问题就是产品是否可以开发，你的工程师和设计师应当介入技术的可行性调查和探索可用办法。有些办法是行不通的，但是有其他的办法可行是非常有希望的。

工程师会发现在产品的某个阶段不可能逾越，现在知道比以后知道要好。

可用性测试

产品设计师将要和你紧密工作共同提出产品功能，让它能适应不同的用户。可用性测试常常会找出遗漏的产品要求，同时确认产品最初的要求是否是必须的。在你拿出一个成功的用户体验之前需要多做一些测试工作。可用性的目的是在真正的用户身上测试，从产品目标用户得到质量反馈的测试是非常艺术和科学的。当然产品经理和产品设计将模仿使用，但是实际是没有人能取代真实的目标用户。

概念测试（Product Concept Testing）

光是可用和可行是不足的。真正的问题是你的用户想要购买吗你的用户有多喜欢-你做的有什么价值。这测试可能与可用性测试联系在一起。

对于一部份小产品，您的想法写在纸就足够了，但是对于多数产品，为了预计产品是否达到目标，复杂用户互作用或新技术的使用、某种形式原型都是非常重要的。

原型也许是一个物理设备，或者它也许是软件产品的一个预览版本。关键是它需要足够现实，您能用原型在实际目标顾客身上测试，并

[教产品经理写好产品需求文档]

篇4：产品经理如何做好需求收集

项目前期需求收集过程的效果好坏，会对软件产品的最终质量产生直接的影响。如何收集好需求，本文作者给出了一条行之有效的实际操作途径。

什么是需求收集?

需求收集，是确定和理解不同类别用户的需要和限制的过程，是需要高度协作的活动，是在问题及其最终解决方案之间架设桥梁的第一步，因此其重要性不言而喻。据调查显示50%以上产品在市场上失败的原因，是由于忽视了用户需求。

需求收集在需求开发活动中的示意图如图1：

如图1

需求收集为什么会困难?

困扰项目组需求收集活动的原因可能如下：

需求收集人员往往只关注用户反映的表面问题，而不能主动深入挖掘用户的真实需求;

需求收集人员考虑的问题时习惯干“以产品为中心”，而不是“以客户为中心”;

用户往往不清楚自己的真实需求是什么，或者不知道如何准确地描述出自己的需求“我心里很清楚，但就是说不出来”;

没有从所有可能的渠道去收集需求，需求信息来源不完整;

收集的需求没有规范记录下来，造成原始信息丢失或失真，且无法回溯;等等。

怎么做好需求收集活动?

首先，需要建立需求收集机制。其次，使用统一的需求收集系统。最后，在需求收集时，采取一定的技术和方法。

建立需求收集机制

(1).明确每个需求收集活动参与者的岗位职责

根据项目组可能的需求来源(需求来源可能包括：市场调研，竞争对手信息分析，标准和协议等等，视项目组的实际情况而定)，指定每个需求来源的收集负责人。同时，对通过各个渠道收集的需求信息，指定专门的接口人进行汇总和审核。

(2).建立需求预处理流程

对收集到的需求，除了指定专门的接口人进行汇总和审核以外，还要建立相应的预处理流程，在对需求进行预处理时，相关的讨论，决策可以通过“需求CCB会议”完成(需求CCB是指：专门用于需求讨论和决策的Change Control Board)。

一个对收集到的需求信息的预处理流程例子如图2：

如图2

项目组可以参考上例，结合自身实际情况进行适当剪裁，建立适合自己的预处理流程。

(3).周期性的重复需求收集活动

当产品处于研发过程中，或已经交付给用户使用后，项目组还需要定期从各个来源重新去收集和审视一下产品的所有相关需求，这样就可以及时获知市场和用户对产品的反应，为下一个步工作提供输入和依据。项目组可以依据自身产品的特定，指定周期性的需求收集策略，选择相应的时机。

使用统一的需求收集系统

很多项目组都采取表格的方式记录收集到的需求信息，而不是通过电子流程的方式提交，这样会到来一些问题，如：收集到的需求信息被延迟处理，项目信息无法跟踪，回溯，等等。因此，项目组有必要使用统一的需求收集系统，作为唯一，明确的入口，对需求信息进行填报和跟踪。

企业可以选择自己开发电子的需求收集系统，也可以选择购买市场上现有的产品，如：Telelogic公司的Focal Point等。如果使用自己开发的需求收集系统，就可以让系统流程和企业的业务流程相结合，而且日后维护和扩展也比较方便。

一个需求收集的二维流程图实例如图3：

如图3

在实际工作中，需求收集系统还可以和需求管理系统，变更控制系统等通过一定的接口实现集成，共同构成企业的综合需求管理平台，从而提供“完善的需求管理解决方案”。一个公司级综合需求管理平台搭建的实例如图4：

如图4

采取一定的需求收集技术和方法

在需求收集时，还应采取一定的技术和方法。一些常用的需求收集技术和方法包括：客户访谈，客户交流，市场调研，技术支持，高层拜访，竞争对手分析，查阅媒体信息，需求专题分析讨论会等等。

下面选取几种技术和方法，通过一些案例分析，进行更为详细地阐述。

(1).客户访谈

案例分析1：某次客户访谈

访谈时间：选择45-60分钟比较合适。

访谈地点：选择比较宽松的非工作环境进行。

访谈问卷：在访谈之前要事先设计访谈问卷，要注意的是问卷只是提供一个思路。

填表方式：不要采取让客户直接填表的方式。

录音：前提不要让客户发现或是事前征求客户的同意。

访谈结束：再次确认，每次访谈后要优化访谈的提纲以备下次使用。

(2).客户交流

案例分析2：

交流前的沟通：充分与客户沟通交流，重点可以以下角度考虑问题：

本次客户关系什么内容?

参与人是谁?

主要决策者有哪些倾向性的观点?

竞争对手可能方案的卖点?主推什么?

我们要住推什么?怎么避免我们的弱点?

客户预计会提那些问题?我们应该怎么回答?

交流会的讲解重点：在交流会上，可以选择以下讲解重点：

客户面临的问题是什么?

针对客户面临的问题，我们的解决方案是什么?

我们的总体方案如何?

今天交流的内容在公司总体方向中的位置?

此外，在交流时还可以自己设计一些问题并加以回答。特别需要注意的是，在交流的时候不要攻击竞争对手，但是可以多讲一些自己的成功案例和优点。

交流后的工作：交流之后，还需要完成以下工作：

分析记录和答疑;

提出项目的应对策略建议;

对交流会上遗留的问题进行跟踪直至关闭;

(3).需求专题分析讨论会

需求专题分析讨论会的目的，是在较短的时间内鼓励与会者在需求上达成共识，尽快取得统一意见。需求专题分析讨论会通常邀请客户代表参加

案例分析3

会前准备

确定所有相关的干系人，不要有遗落;

事先做好会议后勤保障;

事先准备会议相关材料，需求文档初稿，调查问卷，相关清单;

找合适的主持人：善于控制时间，维持会议“规则”，制定会议目标和议程，能够调动所有人员积极参与。

会议举行：

制定会议纪律并宣布;

支持人要把握好会场气氛，并及时化解矛盾;

记录人要做好会议记录

参与人员使用投票方式确定需求优先级;

发言人的发言时间不得超过一定长度，不能打断;

会后工作

把会上收集到的意见归类;

记录讨论后的需求;

确定下一步工作;

结束语

需求收集在客户问题及最终解决反感之间起着架设桥梁的作用，从某种程度上来讲，需求收集工作的质量决定了产品的成败，因此我们必须加强对其的重视。为了做好这项工作我们需要建立日常的需求收集工作机制，并采用统一的需求收集系统作为信息入口;同时，由于需求收集是统一的讲求技术和方法的活动，选择和的技术和方法有助于获取完整且有效的需求。

[产品经理如何做好需求收集]

篇5：产品经理需求分析技巧之别相信任何人

对于任何互联网产品经理来说需求分析这一步都是最关键的一步。如同开车：发动机决定车的速度，方向盘决定车的方向。如果方向错误，这开的越快反而越糟糕。工具/原料产品经理需求分析步骤/方法1需求分析的目的就是帮助我们确定方向。你接到的项目可能是从零开始还没有开发的，也可能是开发到了一半的。但公司找你必然是有新的需求没有实现，需要你把需求转化为可实现的内容。但是第一步你就要明白他们的真正需求是什么。2你的需求提交人（可能是你老板或者领导）会对你说：我们需要做一个SNS，让大家有个沟通交流的地方。需求分析在匡扶我看来最基本的原则就是：无论对方说什么，你都别轻易相信3如果你真相信需求提交人的这句话去给他开发一个SNS可能这个项目还没开始就已经挂在你的手里了。张嘴容易动手难，一个SNS可大可小，运营起来更是难上加难。如果你什么都信，你会发现你有开发不完的功能，你会有做不完的事情，你还会发现昨天说的事情今天就变了注意事项无论对方说什么，你都别轻易相信

[产品经理需求分析技巧之别相信任何人]

篇6：产品经理之产品需求分析（一）交互设计

很长时间没有静下心来写点东西了，近一个月繁忙的工作让自己的心态平和了许多，

一直在想，做新的产品和改版旧产品这两者之间在具体工作方法和思路上应该是可以复制的，通过近期对于公司一款产品进行全部改版，了解到不同之处。老规矩通常上层决定要改版一个核心产品时，没有太多理性和具体的理由，能听到的都是说用户体验、稳定性和易用性存在诸多问题，除了从运营部拿到一些用户调查数据，再无其他具体的意见可以借鉴，不过截止到今天已经全部完成，提供小结以提醒自己。

通常情况下产品策划人员开始执行产品改版的同时，一定是大家已经对这款产品到了忍无可忍地步了，运营没法推广，用户使用率和在线时长寥寥无几，浪费了运营成本，也带来了二次推广行业用户接受度的考验，所以只要是公司一员都能到这个产品上面吐口水，这时候再追究最初的责任已经没有任何意义了。

1.首先要搞清楚为什么要改版？要重点解决哪些问题？

A.第一轮从运营部拿到一些数据，可以看出推广力度和用户注册数属于正常范围，只是在产品使用过程中的在线时长非常短，也就是从这里开始大部分用户很少再开启第二次使用；

B.除此之外，产品核心功能和辅助功能主次不分，附加功能繁多，功能分散，对外宣传的几个核心功能被埋没，其次挡在用户面前，还要设置一些计算机IT行业必须的信息，要命的是普通用户根本不知道怎么去配置这些信息，虽然产品有做通用标准和相关引导机制也很难使用，少一条信息则不能继续使用某一个功能；

C.因为产品本身技术和信息源的问题，使用过程中经常出现不可预估的错误和干扰验证码信息；

总体而已以上几点导致用户流失、和用户反馈的信息基本上一致的，目前急需改变的，至少可以解决部分用户量和用户粘度不够的问题。

接下来需要进一步具体化到某一个功能和某一个点的分析，评估版本工作量和版本更新安排。

对于产品功能繁多，核心功能弱化的问题，最好的办法就是快到斩乱麻，当事情往往不会如意向的那样，最好能砍的一定要砍，不能砍的想办法弱化和做到二级菜单或者需要涉及到得业务数据模块去，

既然是互联网产品，互联网产品的特点就是适合快速推广、快速上手、减少用户学习成本，剧增用户量、最好做到用户之间推荐和传递能够清晰明了，归根到底一定是很爽快的解决用户某一种需求，我们到底满足了用户实际工作中哪一个A级需求，B级以下的需求是否有必要现在全部一次推给用户。但产品本身属于行业软件产品和互联网之间，这个在当初定位时稍有不同，所以用户行业软件的技术和功能，推广运用了互联网产品推广的策略。也问题之一。

我用一个很初级的例子来对产品的需求进行分析；

如果你现在很渴，很明显目前你急需要满足的唯一需求就是喝水，这时我提供一杯水给你，是不是应该定义为A级自然需求，也可以是核心需求之一，这种需求不用太多深入分析都能够明白的，对于这种自然需求无需做用户调研和数据统计，而且也没太多意义，实际工作中有着太多这样时间在这里纠结。

继续刚才的例子，OK，满足了你喝水的需求，从生理上来说，你无需再喝过多的水了，但部分用户满足了自然需求紧着有的想要喝甜一点水、咸一点的水、苦一点的水等等…，但这属于B级或者潜意识需求，要么是我们有针对性的自己挖掘出来，或者用户会提出来。如果功能需求要分优先级的话，那么A级需求一定是要优先满足的，当然你确实渴了，我给一杯很苦的水，你也会喝，虽然你满足了这个需求，但用户会很不爽。

我想问题应该出在这里了，如果按照上面的思路，那么我们的产品是把这些需求都给到用户，但用户想要喝水之前，事实我们给的不是一杯水，而一口井，这里所说的就是挡在用户前面需要配置的信息，这时有耐心的用户会自己做木桶，做吊绳，然后去打水。OK，用户好不容易做好了这一切，把木桶丢进井里发现井水不时上下波动，要很费力才打到水（产品稳定性和易用性）打完水上来，喝了发现水是苦的，这时我想他心情不会好到哪里去，和我们一直对外宣传和标榜的纯净天然水简直是天壤之别，也就是说宣传时我们从这个产品繁多主次不分的功能选择了一两点我们认为核心的功能作为主推广点。

我觉得至少下次他是不会来这里打水了。

今天就谈到这里吧，感觉有点乱！

篇7：解剖产品想法:需求分析和需求实现

文章描述：关键在于，自己是否可以通过简单的市场调研、理性的需求分析，对一个自己中意的想法做一次解剖，洞悉其价值，这种解剖分析的过程，就是锻炼和成长的过程。

产品人总会产生各种各样的新想法，这其中极少数“应景且靠谱”的想法会成为产品、惠及网民，而更多产品想法只会成为谈资、或博文素材，比如下文中的这片想法。那么，产生不应景、不靠谱的想法是不是错误呢？我认为不是，这种“产生想法——想法博弈——想法毁灭”的过程，对于一个产品新人来说，至少算是一种对互联网市场的猜想、对用户需求的分析、对产品策划模型的创造。关键在于，自己是否可以通过简单的市场调研、理性的需求分析，对一个自己中意的想法做一次解剖，洞悉其价值。这种解剖分析的过程，就是锻炼和成长的过程。

所以，我把以下这个想法拖上解剖台，按照“产生——分解——分析——实现——再回顾——评估问题”的过程，简单评估一下其应景与否、靠谱与否。

需求产生：我在PC上阅读的时候，总会在某篇文章中发现一些“或拍案叫绝、或醍醐灌顶、或发人深省”的片段内容。每当此时，总希望轻松存储这些片段，以便收藏并回顾，又不会干扰阅读进程。提升一点儿档次的说法，即所谓的“知识管理”行为之一。

需求分解：1、在PC上阅读，所以场景有可能是浏览器、阅读器、WORD等；2、阅读过程中存储片段；3、存储快速，以后可以阅读曾经存储的内容。

需求分析：

层一：有用

●实施文字存储行为，并方便以后的回顾阅读；存储行为在阅读过程中完成，要求快速且便捷。

层二：易用

●网络存储：最好玩点儿云存储的概念，我走到哪里都可以把片段往云彩里塞、或从云彩里看。

●分类索引：分类、标签不能少，甚至注释、来源也可以有。一是方便我对内容的管理；二是说不定以后有大用处~~

●如何快速：“浏览新浪博客时，选中片段即可发布一条微博”——这种方式值得借鉴。在此过程中加入分类、标签、注释的交互过程，并淡化存储行为。造就一种“一片好知识，不知不觉已上云端”的完美感觉

●方便阅读：以某种方式让我舒服的阅读这些片段即可，比如网页方式。

层三：爱用

背景：满足了“不打扰阅读行为的快速存储、有效索引、便捷阅读”这一基本需求之后，我所积累的知识就会不断的往云端里塞啊塞。如果这个产品被我的100个其他同行使用，我们101为同好者就会不知不觉建立起一朵肥硕的云彩，关于某一类主题知识的云。

基于以上两行之背景，则会出现如下之场景：

●第一：所有知识均为用户筛选，基本全属于优质内容。

●第二：分类索引，让同主题的内容可以有效聚合，并含有注释、来源。

●第三：有了优质内容、主题聚合，分享欲望油然而生。我当然希望浏览同行们认可并收藏的知识片段。

需求实现：

现有工具：

●onenote、EverNote、wiz，

试用了WIZ，索引及分类不清楚、存储有些迟钝。另外两个没用过，EVERNOET本身50M+，软件本身就够重的，有些麻烦。客户端嘛，最大的麻烦就是要安装和管理，一台PC一种情况，带不走。

●阅读器，比如谷歌。可以在有限内容源内收藏、分享内容，但其与需求本身还有着本质差异：阅读器，并非知识管理工具，不能对片段精华的知识进行有效的存储、管理、索引。

实现方式：

●客户端——沦为现有工具之列，加入竞争。另外，客户端+网页的方式，也加大了用户的理解和管理成本。内容源：可以照顾各种内容来源，包括网页、WORD等。

●浏览器插件——比客户端轻、比“下面的方式”重。内容源：比客户端缩小一圈，可以照顾所有网页内容。

●某阅读器文摘功能——最轻，内容源也最小，限于阅读器订阅的内容。有可能背离最初需求，沦为第二种“现有工具”。

最终方式：浏览器插件+云端存储+网页展示。

靠谱吗？回顾需求

即，回顾最初的需求是否得到了很好的满足，应该从虚拟场景中判断，功能是否抓住了用户的痛点（分析用户需求：在场景中寻找痛点）:

●场景一：我安装了浏览器插件，以后无论在网络中阅读到任何对于自己有价值的内容，均可“选中内容——选填标签、分类、注释，并自动记录来源——完成云端存储”。

●场景二：我若需回顾自己积累的网络文摘，便可以“点击浏览器上的插件按钮——打开网页——按照预设分类及标签阅读浏览”。

●场景三：承接场景二，我还可以在网页中“点击公共标签、公共主题分类——浏览他人产生的优质文摘内容——关注某用户及其文摘知识 or 点击文摘来源，直接到来源网页浏览 or ……”，社区形成。

问题：1 用户对于“阅读过程中记录精华、笔记类内容，并作为知识管理、回顾阅读”的需求有多强？2由用户产生的“片段化的文摘、笔记类内容”，其可读性、可分享性有多强？

●第一个问题，决定了这个产品本身的“产生意义”。

●第二个问题，决定了这个产品“到底是做一个纯粹的知识管理工具，还是借用户产生优质内容之东风，做一个知识分享社区。”

解剖完毕。我对于这个想法的评估，最后简单归结为以上两个问题。当然，由于个人能力和阅历所限，我这种自娱自乐式的解剖，会在过程中产生各种偏差或偏执。所以，最好的方式，是邀请其他同事、同行一起围观解剖台，对自己的想法评头论足，以保证下刀精准、方向正确，从而让自己这次需求分析的锻炼过程，更具备群众智慧和参考价值。

总之我认为，产品人就是要不断产生想法，然后毁灭想法，再产生，再毁灭…………直到这种反复自我毁灭的过程中，拼杀存活下来一些惠及网民的好产品，自己也就可以欣然的修成正果、立地成佛了~

篇8：产品经理需求分析技巧之如何处理随口提及的需求

互联网产品经理在需求获取的过程中会遇到各种各样的要求，但请先相信一点：无论你是多么优秀的人或者是拥有多么强大的资源你都无法满足所有需求。也正是因为这点我们才要进行需求的分析和过滤，所以才需要互联网产品经理这样的一个职位来处理这些需求。我们会遇到随口提及的我们觉得没有意义和没有价值的需求，这些需求多数是出自老板。尤其是老板的一些随口提出来的需求。这样的需求没有经过任何确定，可能只是老板的随口一句话（或者你觉得只是一时冲动或者应景的话而已），但是接下来你会面临以下问题（这是只针对不按照规定流程随口提出的需求）。步骤/方法1首先，分析可能出现的情况：1、可能你做了，他说他没说过。2、可能你没做，他说怎么还不做。3、你问他到底做不做，他说我在会上说的那么清楚，你开会干什么去了2然后，如有必要先尝试去获取更多的信息，关键是看需求提出方到底想清楚没有，同时证实自己的判断。3最后，如果自己觉得没必要的需求，但是对方坚持要做（很可能是老板支持），这时候就看需求涉及到的工作量的大小。 如果工作量一般，那么做法就是不做，如果工作量很大，那么做法就是先做一点点注意事项按照我上面说的办法，如果当相关人员问起进度的时候如何回答？如果工作量一般，直接告诉他完成时间。问：那XX功能怎么样了？上周就说要做的。答：这个功能正在弄，后天就能弄完了他关心的是最终结果，而并不是现在的进度。如果工作量很大。问：那XX功能怎么样了？上周就说要做的。答：初步设想已经在上周发给你了，你把认为你需要修改或者有问题的地方告诉我，我们就可以进行下一步了将任务抛给对方，如果对方真想做就会回复你，如果不是真想做就会无视你。

[产品经理需求分析技巧之如何处理随口提及的需求]

篇9：分析阿里巴巴产品经理职位

为了达到高的面试筛选成功率，技巧非常重要，但更重要的还是对需求招聘的职位的理解，这是成功招聘的前提。如果说应聘技巧是房子中华丽的装修的话，那么招聘需求分析就是房子的根基。

一、职位描述

我们希望你有专业的背景-

具有计算机或通讯等相关专业背景，作为一个技术类产品经理，懂技术是必须的。

- 你擅长数据分析，对经济和社会新闻有一定理解，我们更是鼓掌欢迎;

- 如果你了解电商业务或有开发经验会获得加分。

我们希望你有开拓的思维

- 逛过坛子，织过微博，耍过手机、偷过菜、打过怪或喜欢互联网;

- 你遇到问题，愿意和大家交流，也可以通过搜索引擎找到答案;

- 有想法、不甘平庸，愿意大胆尝试，为人乐观激情;

我们希望你有全面的素质

- 强悍的逻辑思维能力，能发现事情的本质、发现掩藏在表象之下的真实需求，可以很好的完成需求收集、分析，让产品真正的满足用户需求;

- 倾听、理解、表达、沟通的能力，可以站在不同角色帮助沟通对象提出满意的解决方案，并且取得预期的结果;产品也一样，好的产品是需要拥有不同技能的同事一起帮你才有可能为用户所知、所用、所喜爱的;

所以在这个团队合作中，融洽的性格可以使你在坚持原则上更具有一些人格魅力

- 做事情耐心严谨，可以做好产品文档撰写、产品管理等基本工作;

二、职位分析

懂技术

互联网产品真正要做出来，是离不开技术人员的。对于技术人员而言，产品经理是提出产品创意的人，是参与设计产品的人。产品经理从用户需求角度分析，挖掘用户目标，从而做出产品的原型。并能在技术人员开发产品的时候提出这样或是那样的建议。所以，和技术人员的沟通很重要。

数据分析

如今是大数据的时代，对于数据的分析，一方面可以加强与研发人员的沟通，因为研发人员喜欢量化的东西;另一方面，数据有助于我们做需求的分析，客户的需求经常变，所以需要对收集的数据进行进一步的分析，以确定客户真正的需求是什么。如果没有数据的分析能力，就会导致逻辑混乱，影响产品的开发。在产品的推广阶段，同样也是要用到数据分析，通过数据可以知道产品有哪些不足，从而能及时对产品做出改进。降低消费者使用时需要付出的脑力和体力的成本。

对经济和新闻有一定的了解

这是一种跨领域能力。洞察力往往是第一时间联系每天的业界新闻以及综合新闻打下的深厚的基本功才有可能实现的;所以产品经理要有开阔的视野。做产品必须要多看，多想，多积累。而这一切的基础在于多看。嗅觉敏感是能否成为好PM的前提。倘若一名产品经理能够了解经济和新闻，就能及时把握时代的脉搏，把握商机。就能够看清未来的走势，对商业模式的现有状态和未来状态有一个比较全面的把握。明确通过什么方式跳开现有的模式，以达到未来商业模式的高度。对互联网行业的把握是很重要的，行业发展趋势，用户热度趋向，取得成功的产品与失败的产品区别在哪里，都应该去关注，并且思考。

逛过坛子，织过微博，耍过手机、偷过菜、打过怪或喜欢互联网

作为一名产品经理，不仅要对自己公司的产品要熟悉，还要熟悉竞争对手的产品。正所谓是知己知彼，百战百胜。一名好的产品经理，应该具有从用户出发的思维方式以及很好的创新能力。所以，必须经常去用互联网的产品，把自己当初一名用户，去体验，去思考。为了能够让用户体验更好，就不要闭门造车，而要多用用其它软件。好的设计是建立在不断的使用和分析的基础上的。培养产品的感觉。只有这样才能热爱自己的产品，使用自己的产品，传播自己的产品。

你遇到问题，愿意和大家交流，也可以通过搜索引擎找到答案

这是考察解决问题的能力。在产品创立的过程中，会遇到各种BUG，这时候，首先你能够不需要人在背后推动，自己也能够去寻找问题，寻找一切能够让产品变得更完美的改进方向;但个人的能力是有限的，当遇到问题时，和大家进行沟通和交流能够使得问题得到更好的解决。

有想法、不甘平庸，愿意大胆尝试，为人乐观激情

人的状态决定产品的状态。一个优秀的产品经理，在合适的时候需要能够敢于跳出这个禁锢，更创新的推动自己产品进化。况且，产品的设计并不是一帆风顺的，当遇到各种各样的挫折时，乐观的精神是必须的，

强悍的逻辑思维能力，能发现事情的本质、发现掩藏在表象之下的真实需求，可以很好的完成需求收集、分析，让产品 真正的满足用户需求。

有很多产品看似普通简单，但实际却寓意很深，涉及到的领域也非常广，如行为学、伦理学、心理学等等。你需要根据表像来发现更深层次的东西。你要分析用户真正的需求在哪里，产品如何黏住用户，开发和运营的流程都要分析清楚，以及你应该清楚地知道下一步该做什么，怎么做。这都要求有很强的逻辑思维能力。

倾听、理解、表达、沟通的能力，可以站在不同角色帮助沟通对象提出满意的解决方案，并且取得预期的结果

在产品开发前期，产品经理需要与老板沟通以便争取资源，开发的过程需要与技术人员，交互设计师等表达产品意愿，需要进行不断的沟通和交流。在运营过程中则需要与销售人员，运营人员打交道。当然，产品经理也需要深入了解用户，倾听用户的心声。所以在这个团队合作中，产品经理应该要善于倾听，理解，然后很好地表达自己的想法。

做事情耐心严谨，可以做好产品文档撰写、产品管理等基本工作

产品经理应该熟悉撰写原型文档、需求说明书、流程图等，以便于研发人员了解用户需求，理清思路，加快开发进程等)。所以产品经理需要严谨的态度，做好每一份文档，以减少研发人员的理解成本。再着，总会遇到沟通和交流上的阻碍，这是产品经理应耐心解释产品意图，产品开发工作，与开发人员沟通好。

[分析阿里巴巴产品经理职位]

篇10：产品经理如何进行数据分析

对于产品经理而言，看明白数据是一件很简单的事情，但是要想从数据中挖掘其背后更深层次的内涵，看懂数据背后的逻辑是一件非常不容易的事情。往往一个决策的成功或失败，总能归咎到对数据的理解上。

值得欣慰的是，随着接触到的用户越来越多，对于用户心理模型和业务逻辑的理解越发的透彻，产品经理对数据的理解能力也将越来越强。

1、不配看数据

产品经理对待数据的态度不应该像市场分析者或财务人员一样。我们看数据，更多是需要了解数据背后用户的行为逻辑和期望需求。这就要求我们看到数据的时候，必须第一时间想象到用户是如何创造出这些数据的，为什么会创造出这样的数据。

作为一个产品设计者首先必须告诉自己：“I’M Not User” ，如此同时还要再把自己模拟成一个平凡的用户，不停的反复的去用自己的产品，和同类产品。我向来认为，一个做移动互联网的产品设计师，不有事没事换手机 玩，不是好的产品设计师;一个电子商务的产品设计师，不每周在网上买一件东西，不是一个好的产品设计师。

在某个用户体验设计的会上，某知名教授大讲他所在公司搞到的facebook的数据，说他的理解、说他的分析，说facebook如何没戏。刚开始 听着蛮有根有据，后来越听越不对味，突然他冒出来一句“虽然我从来不用facebook”… 我当场昏厥。这种人，不配分析facebook的数据，更不配去评论。、

要想有资格去看数据，通过数据给产品设计提供有效的依据。方法很简单，也很有效：把自己当作一个平凡的用户，不停的用自己的产品，和同类产品。有，且只有这么一个方法。

2、为了看数据而看数据

和做可用性测试一样，测试之前不能说没有“关注点”，发现什么就是什么。那样什么也发现不了，即使发现了，价值也不大。数据拿到手里，没有目的的去看，不如不看。

在做产品设计的数据分析之前，首先应该搞清楚自己需要什么样的数据来说明什么问题。一个数据对于不同的产品、不同的环境、不同的用户类型，得到的结 论应该是不一样的。传统的市场研究中，对于数据的分析往往是根据“硬属性”，比如他们对于用户的分析基本都是根据“人口属性”的数据，他们得到的结论也很少结合现实环境。这样的结论，对于(互联网的)产品设计基本上没有太大的参考价值，特别是如今个性化需求越来越强，用户行为越来越独特的时候，“人口属性”很不能代表用户背后的行为逻辑。

比如，想了解“有购物搜索需求的网民”具备的主要特征，这个时候“年龄、学历、性别、收入、婚姻状况、消费能力、信息获取方式、上网条件、..”可能都是对我有参考价值的数据，但那些才是最重要的呢?分析后很快就可以发现，比较而言“年龄、收入、上网时间、上网条件”都不是最重要的，“消费能力”、“信息获取方式”在这里才是最重要的特征。这些数据背后才更能代表用户的行为逻辑和需求。(如果不是很明白这个结论，稍后再《Desing IT.》第8篇左右会谈到)。

3、不筛选数据

做一个优秀的设计者，首先必须善于“提问”。“提问”的水准和设计水平基本成正比。要什么样的数据，什么样的数据可以帮我解决这些问题和疑问？这个很简单，一罗列你可以想到很多很多。但，事实上数据类型到达一定数量后，类型越多，反倒越不利于对于结论的判断。因为，不同数据类型之间会产生相互的干扰，有些时候次要问题可能会战胜主要问题，影响最终的结论。

在实际项目中，解决了主要问题，次要问题可能就会很自然的被稀释了。获取数据也一样，必须搞清楚什么样的数据最能说明这个问题?确定这些会使分析过程的精力更加集中。把主要的几个问题想穿、打透，其他问题很快就会迎刃而解了。

很多时候不是解决不了问题，而是想解决的问题太多；很多时候不是数据不够，而且想要的数据太多。还比如，想要了解如何解决“购物搜索”的需求，其实 只要关注好“信息获取方式”、“消费能力”、“决定购买的因素”基本就能解决很多问题，盯着“用户是男是女，8岁还是80岁”，只能是耗费精力。

不去筛选数据，还有一个很大的危害就是：“因为没有筛选，所以不能把关心的数据点看透彻”。

比如，很多人都在夸开心网的推荐做的好，很多用户在上面找到了自己的“同学”，于是定论为“算法的技术好”。其实如果专注关心“开心网为什么打通用户关系这么快”的人，经过详细分析后是不会得到“技术好”这个结论的。根据我的观察，我比较赞成麦田的结论：“开心网把校友录的数据库用进去推荐算法里面了”， 我甚至认为开心网的推荐里面不只是用了“校友录”的数据库，还有更多其他数据库。 (麦田对于数据的分析虽然是偏市场和运营性的，但其实对于产品设计的促进一样很大，而且他确实是一个观察数据很细，研究数据很深的人)

4、不关注数据采集的方式和方法

当我们为某个项目寻找方向或者确定某个决策，需要一些数据的支持，以便了解状况并确定思路。这个时候，不仅需要给出“需要什么样的数据”这个需求，同时还应该包括如何得到这些数据。

很多时候，我们只提出需要什么样的数据，并不去提出要求如何得到这些数据的方式、方法，完全依靠调研者的经验去获取数据，这是不可取的。因为这样来的数据对结果的帮助是不准确的，甚至往往会出现误导。因为调研过程中不同的方式方法，得到的结果会不一样。

比如，还是要做一个购物搜索的网站，你给出的“需求”不应该只是“用户目前获取信息的方式”、“搜索的商品类型”等，还应该包括数据的来源，以及获取的方法。现有搜索网站?问卷?电话?…

不同的方式方法，渠道，得到的数据是不一样的。不同水平的人采集到的数据结果也是不一样的。

往往我很同情国内的同行，大家能找到靠谱的数据真的少的可怜。就拿行业数据来说，基本上国内没有一家第三方机构可以提供靠谱的数据。XX统计局就不说了，比如商业机构艾瑞，他的数据丝毫不具备可信度。最根本的，我们可以去看看尼尔森在欧美(不要看国内的尼尔森，那是同样的不靠谱。跟他们合作过一次，东西做的一塌糊涂)的一些问卷，从问卷设计的逻辑、采集方式、统计方法，甚至包括“埋地雷”的方法，都高出国内这些数据提供商一大截。(比如一个细节：去 尼尔森在欧美的一些问卷试试，如果你是玩的心态，很快就会被说“谢谢你参与调查”。因为，他们很快就通过“地雷”判断出你并非真正的采集对象，很快就把你踢走了，而国内的你可以随便玩)

有些时候，如果实在没有办法，去做小量的抽样数据，也比那这些不靠谱的数据去分析强。

5、只用定量数据，没有定性数据

还说那个最老土的例子：

沃尔玛每天总重要的事是“想尽一切办法，把货架摆好，让顾客更快的找到，更快的走掉”。事实上，当他们的MBA(商业数据分析)人员通过庞大的数据处理系统发现，啤酒和尿布的销售曲线惊人相似的时候，他们其实只能得到一个“结论”。但，这些知识定量的数据，并不能挖掘出本后的顾客行为，以及为什么会造成这 个现象。这个时候，如果靠“分析”、“猜测”是不能得到正确结论的，方法只能是去结合“定量”的研究，通过具体观察和调研了走到用户身边，最终才能了解到 “因为，在美国一般都是男人去买尿布的，而在沃尔玛就算买1美元的东西也要排队半个钟结帐，男人们这个时候就顺手拿了啤酒犒劳一下自己”。

海量的定性数据，只能告诉我们结论，不能告诉我们背后的原因。同样，如果只有定性的数据，往往看到的现象可能是片面的，结论可能是有偏差的。

有时候，定量更多的是为了定性。

6、其他常见的数据分析误区：

（1）、只关心数据结果，不关心过程

比如，就知道那个广告的流量大，没注意那个广告比别的大三倍。

（2）、只看大数据，不看小数据

比如，只发现交易量疯狂增长了，没注意虚假交易疯狂上升了。

（3）、只看数据表象，不看发展过程

比如，只知道现在的行业分布均衡，没发现曲线的前方已经出现裂痕。

[产品经理如何进行数据分析]

篇11：百度产品经理教你把握需求及正确决策

在中国的互联网公司中，百度作为BAT三巨头中的“B”，拥有者一系列为用户称道的产品，尤其是以百度百科、百度知道、百度贴吧等搜索引擎周边产品，隐隐已经成为了搜索引擎的标准被指。那么，到底为什么百度能够规划和设计出如此多的优秀产品呢？又为什么百度的竞争对手在这些领域纷纷折腰呢？请看来自百度的产品经理的回答。

任何一个产品人员，要理清产品的分析和决策思路，首先要弄清楚什么是产品。产品的核心价值，是用户使用该产品的终极意义。例如军大衣和比基尼都是用来穿的，但是前者的核心价值是御寒，后者的核心价值是性感。手机虽然变化多端，但核心价值是语音沟通，所以如果通话音质不行的话，这个手机再炫再酷，也会被用户舍弃。

互联网产品也是同样道理。很多产品在外表看起来是一样的，但是如果深挖的话，用户为什么要用?最根本的好处是什么?答案是非常迥异的。例如一个是百度知道，另一个假设是在线购物网站的疑难问答平台，产品形式可以相似，但本质完全不同。前者的核心价值在于“让人们更便捷的获取信息，找到所求”，而后者则应该是一种高效的在线客服手段。这个本质差异就导致了很多要点和细节上的产品决策差异。

所以对一个产品进行分析之前，首要问题，便是弄清楚用户为什么要用这个产品，它带给用户最根本的好处是什么。

要解答这样一个问题，并不容易，很多失败的产品在一开始就没弄明白用户用它的理由，注定了后面的失败。在产品研发前，百度搜索引擎产品人员首先要解答这个问题。

百度的产品决策原则

搜索引擎产品部门在招聘产品人员时，应聘人员尤其是对互联网充满热情的学生常常积极地抛出自己的各种想法，却没有仔细分析为什么做?该不该做?

外界也常常有人提出一些疑问，为什么百度不做这个产品?为什么百度不做那个产品?

在《李彦宏的百度世界》里，阐述过百度的产品决策原则：“无论百度推出什么产品，总是遵循三个原则：有需求、有优势、有收益。”

首先是需求导向。无论是客户需求还是用户需求，归根到底都是需求。先有需求，才再有动作。借用一个经典小故事，有两个卖鞋的人去岛屿上开拓市场，一个回来后跟老板说：“那里没有市场，根本没有人穿鞋。”另一个回来后跟老板说：“那里市场可大了，大家都还没有鞋。”这个问题如果放在产品决策上，应先问需求，先摸清楚对于这群用户来说，他们穿鞋的好处、不穿鞋的好处，再决定下一步。

其次，在有效满足需求方面，我们有无优势。用户体验是一个完整的过程，对于用户的终极需求的满足，才是真正有价值的。

“视频搜索”这个想法在搜索引擎产品部很早就有考虑和接触，但早期互联网资源非常有限，资源的下载是一个致命的瓶颈，搜索做得再好，对用户最终获取并观看这个视频并无多大的帮助，因此当时没有介入；到了后期，由于专业视频分享网站的兴起，用户视频体验得到了巨大的提升，且资源众多，从用户搜索关键词里很容易能发现大量视频搜索需求，百度在搜索方面的优势能为找视频的用户提供更多更好的便利，而网页搜索通用搜索解决方案并不能完全满足视频搜索的特殊需求，因此视频搜索诞生的时机到了。后续经过产品设计、产品研发，成为一款大量用户使用的搜索产品就是顺理成章的事情了。

最后是要符合百度使命，专注于搜索，增强公司的核心竞争力，才能保持旺盛的生命力，并且推动搜索领域更深远的发展。现在大家看到，百度网页搜索、MP3搜索、图片搜索、知道、贴吧、百科等每一款产品都拥有庞大的用户群，并互相关联、互相促进这并不是偶然现象，也不是百度为了整合产品而做的整合，而是它们的诞生恰恰就是为了有效地满足用户需求的，它们本身构成了搜索引擎的整体架构，也是百度最核心的产品竞争优势。

对产品的正确决策

产品经理或产品设计师的责任就是保证产品的成功，从产品的决策到产品是否能符合预期地完成开发上线，当然最核心的是在前期需求，解答一个产品为什么做和做成什么样子。

产品人员在把握产品决策原则的基础上，要有敏锐的洞察力，要能作出正确的判断，还得具备两个必要条件。

第一，他自己就是产品的忠实用户。百度产品部门的每位同事，对互联网应用充满热情和兴趣，主动地成为相关产品领域最熟练的一线用户，带着真实的使用目的，能和用户站在一起，而不是带着审视检查的角度，后者往往当局者迷，不能洞悉真正的需求。比如贴吧的产品人员在学生时代不是骨灰级论坛潜水者就是知名论坛的风云人物；网页搜索的某位产品人员搜索引擎爱好者，进入百度前就热衷于发现各种搜索引擎妙用。

第二，他必须能站在大多数普通用户的角度去思考问题。百度产品部门不要求任何专业背景、技术背景，只要你能精确地把握和尊重普通用户的体验，在这一点上的要求近乎苛刻。你不能因为你懂得各种搜索技巧，就期望普通网民像你一样。当设计常用功能时，这样的思考是被拒绝的：“如果用户不明白，可以去看帮助文档”“这个问题用快捷键去解决”……而实际上面临的判断要难得多。

当然，搜索引擎作为信息获取的入口点，汇集千千万万网民的需求和使用习惯，百度的产品人员更能通过直接的数据来分析用户的行为，从他们比较集中的搜索请求中发现产品问题和产品诉求。这也是制胜的法宝之一。

产品的创新思路

为什么要创新?李彦宏说过，“创新的目的是为了更好地满足需求，不为创新而创新”。产品和技术部每天都在进行着创新的尝试，但新技术、新功能、新概念只是工具或手段，产品设计更关注“为什么创新”。

百度产品体系的重大创新是搜索社区，百度的贴吧、知道、百科、空间等，构建了一个完整的搜索社区体系，我们回顾一下当年贴吧上线时首页的那句话：互联网上的信息，和人脑中的信息相比，只是沧海一粟百度过去几年的经验证明，类似贴吧这样的搜索社区模式，在将人们的隐性知识转化为显性知识，并借以提升搜索引擎的核心价值方面，是极其成功的。所以，贴吧是一个伟大的创新，相对全球而言更是独一无二的，而贴吧所代表的搜索社区的产品创新模式和不懈实践探索，更是百度对搜索领域做出的杰出创新贡献。

有些人认为横空出世的东西才是创新，只有推倒重来的东西才是创新，但是不要忽略一点，有些创新是“润物细无声”的，有些创新是细节的，但它们至关重要，同样推动着某一领域的进步。

比如在图片搜索领域，很多人都会觉得以图搜图、颜色筛选、人脸识别这些内容识别技术看起来很新颖，认为只有提供了这样的功能才是创新。在百度产品部的图片搜索组，早期几乎每一位新同事都对这些服务好奇，但经过了一段时间的用户行为分析和思考，才能理解使用筛选功能并不一定是有效解决用户问题的最好方法，应用各种用户需求识别技术、图片识别技术优化搜索结果排序，将用户更需要的图片直接排列在用户的眼前，这也是重要“润物细无声”创新。

有很多不明白互联网产品工作的人问：“怎么保证你的想法是客观的?”“怎么保证你需要的就是大众需要的?”面对这样的问题，很容易让人想到去做调研，调研的方法很容易让人想到是问卷调查。但实际上，产品设计和改进的很多方面是你没法通过直接问用户得到你想要的答案的，就像你没法通过直接询问用户的每一次搜索需要什么来指导搜索结果更准确。其实，用户实际的行动已经实实在在地告诉了产品人员，比他自己说得更多、更真。当互联网产品的用户群体达到一定规模，他们的行为数据具备统计意义时，会比纯粹的市场调研行为更加可靠和直接，那是非常珍贵的财富。

[百度产品经理教你把握需求及正确决策]

篇12：产品经理：用AxureRP做产品的需求管理

本文作者@朱军华Ronzhu 面对众多的产品设计需求，产品设计人员要想一一理清楚就已经是一件不容易的事，更何况要将这些需求清单全部都变成可演示的产品原型，

对于没有研发背景的产品经理来说，从需求检查清单到需求文档是一个较难理解的技术鸿沟，因此对于这部分产品经理来说，有相对来讲比较贴近最终产品实际的原型，对产品的需求管理会容易很多。

研发背景是指参与过产品的需求分析、产品设计、产品开发、产品测试、产品运营这样完整的过程。特别是没有开发之前的产品阶段经验的，对产品的需求管理会比较模糊，没有一个清晰可视化的指引，产品经理在管理产品的时候会比较累，也比较的被动。

再者对产品设计人员来说，一个产品的原型并不是只有一个版本，且设计多个需求时，部分设计可以重用，也能提升产品设计的效率。

AxureRP经过这么长时间的使用，已经渐渐深入人心，不过很多人看到AxureRP的第一反应就是原型设计，其实AxureRP还可以做很多其他的事情。就像很多其他工具那样活用起来，虽然说术业有专攻，但在要求不高的时候，AxureRP绝对可以用来做产品的需求管理。

•首先其自带的共享协作功能，就是很好的将需求化整为零，又最终归集在一起的应用;

•其次是其站点地图管理模式可以清晰的反应出整个产品的结构，类似产品的需求检查清单，可以逐一确认;

•再者AxureRP可以用来做版本管理，每次改动都可以记录下来。

AxureRP的共享协作功能类似开发人员用的集成开发环境，可以将需求分成各个小项，由各个不同的产品设计人员设计，然后最终归集在一起做统一验证，当然这里有一个设计风格统一的问题，这个应该每个公司都有一套特定的设计规范的，至少某个产品的设计风格是有统一标准的。

需求拆分后，首先要保证每个单独的需求都有完整的Story可描述，原型设计完成之后可做单独的演示验证;其次要保证每个拆分后的需求合而为一之后是一个整体，这里不讲求无缝对接，只求大体上没有问题即可，这样在做完整性验证的时候，就不会出现断层的情况，就要求在开始原型设计之前要确定好整个产品的需求检查清单，对每一条需求list指定对应人员进行设计，

大家在共享任务里领走各自的所负责的部分，在设计完成后提交即可，且每次改动规定必须先签出到本地，这样可以不影响实际的原型整体。

AxureRP的站点地图面板可以很好的展现产品的层次结构，可以直接将需求检查清单按照产品的模块构成维护成树形的结构，每个需求对应一个节点，这样可以清晰的看出哪些做了哪些没有做，而且这样设置之后也有利于协作的时候分派，汇总之后也不会导致结构混乱。

如果不能按照这样的方式进行设置，也可以在设置好对应的产品信息架构之后，将里面的节点和需求检查清单里面的list项进行关联，以便备查。

参考《AxureRP介绍–站点地图面板》和《AxureRP介绍–架构图和流程图》。

产品的设计版本管理可以依托AxureRP的站点地图面板来进行，将每次相对较大的调整都复制出一个版本节点来记录，这里改动是否需要新建版本由各自的产品设计人员来把握，目的是为了对每个设计版本可以进行追溯，尽量减少改过来又改回去的返工情况。

而且进行版本管理之后，也可以清晰的看出每个需求节点的需求变动情况，前前后后改动次数较多的就说明有问题了，要么是需求分析阶段的问题，要么就是产品设计人员没有理解需求的本质，总之可以针对性的进行分析和解决。

AxureRP还可以自动生成需求设计说明书，只不过所生成的问题如果要实现图文并茂，就需要额外的注释。

一、是在设计的时候就写好注释，本文所介绍的方法，在协作的时候就可以要求不同的设计人员将各自所设计的功能进行注释;

二、是手工的补写，对于较大的设计项目来说，这个比较困难，必须有一个人了解整体的设计细节。

AxureRP还有很多隐性的功能是可以发掘的，比如模板的重用、页面的说明等。

如果现行公司内没有很好的需求管理工具的话，AxureRP是一个不错的选择，可以在内网搭建一个小型服务，将产品原型的生成目录发布上去，就可实现在内部的访问，非常的便捷。

作者博客：IT民工

需求分析岗位职责

需求分析模板

需求分析小结

产品经理工作总结

产品经理职责

产品经理需求分析范文.doc

将本文的Word文档下载到电脑，方便收藏和打印

推荐度：

点击下载文档