当前位置：首页 > 实用文档 > 其他范文> 产品经理需求分析技巧之别相信任何人

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

时间：2023-06-23 07:59:26 其他范文收藏本文下载本文

产品经理需求分析技巧之别相信任何人（锦集6篇）由网友“海盐汽水”投稿提供，下面是小编为大家推荐的产品经理需求分析技巧之别相信任何人，欢迎阅读，希望大家能够喜欢。

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

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

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

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

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

一个故事

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

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

什么是需求？

广义的说：

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

误解：

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

我们的用户是谁？

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

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

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

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

2、用户说不清楚需求

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

3、双方误解需求

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

4、用户经常变更需求

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

如何开发需求调查

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

确定需求调查的方式

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1、做好准备工作

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

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

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）

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

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

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

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

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

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

什么是需求收集?

需求收集，是确定和理解不同类别用户的需要和限制的过程，是需要高度协作的活动，是在问题及其最终解决方案之间架设桥梁的第一步，因此其重要性不言而喻。据调查显示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

会前准备

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

事先做好会议后勤保障;

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

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

会议举行：

制定会议纪律并宣布;

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

记录人要做好会议记录

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

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

会后工作

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

记录讨论后的需求;

确定下一步工作;

结束语

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

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