怎么寻找产品需求池

❶ 新产品开发的流程

新产品开发的流程？
1、调查研究阶段
发展新产品的目的，是为了满足社会和用户需要。用户的要求是新产品开发选择决策的主要依据。为此必须认真作好调查计划工作。这个阶段主要是提出新产品构思以及新产品的原理、结构、功能、材料和工艺方面的开发设想和总体方案。
2、新产品开发的构思创意阶段
新产品开发是一种创新活动，产品创意是开发新产品的关键。在这一阶段，要根据社会调查掌握的市场需求情况以及企业本身条件，充分考虑用户的使用要求和竞争对手的动向，有针对性地提出开发新产品的设想和构思。产品创意对新产品能否开发成功有至关重要的意义和作用。
3、新产品设计阶段
产品设计是指从确定产品设计任务书起到确定产品结构为止的一系列技术工作的准备和管理，是产品开发的重要环节，是产品生产过程的开始。
4、新产品试制与评价鉴定阶段
试制后，必须进行鉴定，对新产品从技术上、经济上作出全面评价。然后才能得出全面定型结论，投入正式生产。
5、生产技术准备阶段
在这个阶段，应完成全部工作图的设计，确定各种零部件的技术要求。
6、正式生产和销售阶段
在这个阶段，不仅需要作好生产计划、劳动组织、物资供应、设备管理等一系列工作，还要考虑如何把新产品引入市场，如研究产品的促销宣传方式、价格策略、销售渠道和提供服务等方面的问题。

❷ 如何做好需求管理

需求管理从我工作的总结来看有以下几点 1.客户的需求， 从客户角度找到产品的核心的功能和用途，分析出客户对产品的要求的模型，最关注和重视的是哪些功能，并且从现有的数据和反馈中筛分出真正的客户需求，而不是从客户反馈简单判断客户是不是要这个东西，喜欢和讨厌某个功能，为什么喜欢和讨厌。。。以及客户的“建议”也需要去分析和判断。 2，公司的需求， 包括公司的商业规划，盈利的方式，盈利指标等等，以及公司高管和其他部门对产品的界面、功能、流程一些理解和要求。 3，其他部门的需求 其他部门对产品的工作量，技术门槛，资源是否满足等，以及产品项目对他们本身的利益等需求。

我们现在使用的日事清可以将让需求人员将需求输入到“收集”状态，由产品助理集中处理，视需求具体情况将需求拖拽到其他集中状态。如果拖拽到“确认”，在该需求下添加相应技术人员让其处理，技术人员会在日事清协作系统内收到通知并且需求同步到其收纳箱，方便技术人员集中处理，解决后由技术人员拖拽到“已解决”状态卡片。

❸ 如何做产品业务需求调研

怎么做需求分析？

能够像主角镇长一样找到村民真实的需求呢？

首先，需求分析应该服务于用户，所以要以用户为中心做需求分析

其次，需求分析后要形成一份PRD，让团队里的人更流程地工作，减少沟通成本

那么，它的步骤是怎样的？

第一步：给你的产品定个位

“请用一句话描述你的产品”

（结构是：主要面向XX用户，提供XX功能，具有XX特色）

这个方法谁用谁知道，如果很难描述出来的话，你的这个产品就定位有点模糊了，方向也不明确。

第二步：找到初步需求

首先，通过用户研究、头脑风暴等方法，产出用户需求示意列表

得到初步需求后，先把不可实现、不合理、价值不大、无适合场景的需求剔除。——筛选

然后，挖掘用户的目标，找到用户真实的需求。——挖掘

这里需要注意的两点是：

1、倾听用户并不等于听从用户

2、用户想要什么不等于真实需求

接着就是匹配产品定位，找出产品主要功能和特色功能。——匹配

最后就是根据项目的资源来确定需求的优先级

❹ 需求收集、分析、管理的方法

这个专栏将定期发布产品部关于产品设计方面的思考。主要有以下四个方面：1）产品规划 2）用户需求探讨 3）产品设计过程思考 4）竞品分析。

开设这个专栏的目的很简单，主要有两个，一是让公司各位同事能随时了解并参与到我们产品设计的环节中，同时能通过这样的平台给我们多提意（tu）见（cao）。二是通过这样的专栏也能倒逼我们更多地思考，提高自身的产品设计能力，从而设计出更好的产品服务大家。。

这是我们产品部的第一篇关于产品设计思路的文章，想了很久要怎么写，从什么角度开始。最后我觉得任何产品的起源都来自需求，这期就主要聊聊我们是如何收集、分析和管理需求的办法。如考虑不周的也请各位多多指正。

首先是我们如何进行需求收集的。主要有三个方面：

毕竟老板对行业和业务比我们熟悉太多，前期需要吴校和各位大佬多给我们提意见和想法，帮助我们产品方向不会跑偏。

目前我们的用户反馈包括两个环节，一是开发前我们将产品需求转化为原型DEMO，同时我们会选取对此产品最熟悉的用户并把我们的原型一一和他们进行确认，如果还有问题则继续调整原型，如无问题则可进入开发阶段。如极运营在最初的产品设计时我们与财务同事确定需求不下10次，同时也到各校区找到相应负责人进行了多轮的沟通和确认工作，收集了大量宝贵的意见。（这里要特别感谢申琴，在前期我们产品对极运营的需求一无所知时，是她在反复耐心地给我们讲解需求）

二是开发完成上线后我们通过面聊或通过《需求反馈表》给我们反馈的需求。我们目前使用的需求反馈表还用的是比较传统的excel表格，后期会考虑做成简单的系统，这样采集反馈问题更及时，反馈人也能更方便了解自己反馈需求的状态。

当然，在整个用户反馈环节，我们也有需要反思的。比如需求调研覆盖的面还不够广，覆盖的层次还不够多，包括各大区不同岗位层级的用户还没来得及全部沟通到位，后续我们也会在此投入更多精力。

从进公司到现在，产品部已经完成两版的竞品分析报告，也分析了大量教育类产品，从中收获非常多。无论是对整个行业软件水平的了解，还是学习借鉴优秀产品，都帮助我们对行业内产品有了更深的了解，后期有机会我们会把这些分析报告整理后发出，希望引发大家更多的思考。不过关于竞品分析，有一点需要我们注意的： 竞品毕竟是竞品，它的业务场景可能和我们不一样，不能直接，需要辩证的分析它存在场景的价值和意义。

就在前段时间有老师给我们提出，学而思和新东方都在课堂上使用答题器收集学员课堂学情数据。于是我们在网上也做了相应竞品调研，看了很多课堂使用答题器的视频，发现确实通过答题器收集学员学情数据很方便，既能调动课堂氛围还能产生学情数据。但随着调研深入，同时我们也到学而思和新东方线下课堂去体验，发现他们线下面授课无一例外都没用到答题器，只有双师模式才在运用。对这一现象，我们认为，基于现有的线下小班授课的课堂答题器数据采集的迫切性不高，学员只要通过举手或老师挨个查看学员作业就能很快收集到班级学情数据。而双师模式需要一个老师覆盖几个班，上百人，同时还是远程教学，实时掌握学员学情数据就必须通过答题器这种模式实现。从另一方面答题器的成本也相对较高，不仅是软硬件投入成本，还包括课堂、课后管理成本都会带来较大麻烦。我想这也是答题器虽然已经很成熟但仍在传统课堂中使用不高的主要原因吧。

当然除以上几种需求收集方式外，我们目前还缺少通过数据反馈中收集需求，比如通过在产品中对功能进行数据埋点，获取各功能使用情况的数据，从中了解用户的使用频率及习惯来获取需求。这个部分我们会在后续开发中逐步加入，毕竟人可能会说谎，但数据不会。

需求收集完，自然是需要对需求进行分析、过滤、筛选，从中去伪存真和优先级排序。首先我们需要区分收集上来的需求是真需求还是伪需求。有时真的很难区分，很多需求看起来都无比真实，但还原到实际场景却是个伪需求。

举个我自己提伪需求的例子，当时我刚到极客，希望快速提升产品逼格，于是联系到一家自动批改数学主观题作业的公司。那家公司在做主观题数学作业批改上确实很牛，在2016年通过它们的高考机器人参加北京数学卷考试得了105分。我当时希望能通过引进它们的自动批改作业功能，帮助咱们的老师减轻工作量。但后来我把这个产品推荐给老师时，存在两种截然相反的态度，一种是认为有这个功能太好了，能帮助老师减轻工作量，甚至可以完全可以不要助教了。另一种认为其实老师批改作业的时间也占用不到太多，必要性不强。后来我们产品也经过多次内部沟通、讨论，到实际上课和作业批改场景里实地调研，发现确实有问题。一来是我们很多老师本来就有助教，这些批改作业工作会交给助教完成。即使没有助教，我们的班级都是小班教学，一个班也就十几二十个学生，每次作业也就不到半小时能搞定，而且老师在实际批改作业时还能快速了解孩子学情状况。这个自动批改作业的需求虽然从表面粗略一想完全合乎需求，但还原到真实场景里却就不是那么回事。

从这件事里也让我总结出如何识别伪需求的两个心法： 1）任何需求必须还原到具体应用场景去思考和分析 2）不要看用户怎么说，关键看用户怎么做。

需求去伪存真后，还需对真实需求进行优先级排序，分清需求的轻重缓急和节奏对产品设计也非常重要。现在我们的做法是把收集上来的每一个需求都录入到禅道（软件项目管理平台）的需求池里，每次规划下一个版本时我们会从需求池里根据轻重缓急把需求重新梳理和设计，并把需求移到下一个版本中进行排期开发。

这里需要重点讲讲我们关于需求优先级排序的方法。很多人讲把需求优先级通过紧急、重要两个维度生成四个象限， 重要紧急〉重要不紧急〉紧急不重要〉不重要不紧急 。当然，这个处理需求的原则没有问题，但没有定义什么需求重要什么需求紧急。其实紧急这个维度很好判断，取决于 交付时限、任务依赖 。交付时限是指需求最终截止期限，如果过期上线将对业务有较大影响。任务依赖是指该需求是某个流程中的一环，如果缺失这一环将对整体流程造成影响。但重要这个维度就很难的定义，我认为重要维度有两个因素： 影响范围、商业价值 。影响范围很简单，是指能满足多少用户的需求。商业价值是指该需求能对用户带来多大价值或给公司带来多大的竞争优势。

分清了重要和紧急的定义，我们就可以以量化的方式对优先级进行排序。量化的方法就是把重要和紧急两个维度满分设置为5分，分别定义需求两个维度的分值然后两项相乘就得出该需求的总分，最后根据总分再进行排序。

当然，以上需求管理办法主要适用已经上线的产品功能迭代，新项目开发需求还不适用。因为新项目开发会利用大量研发资源，也存在一定风险，而现在来自各个部门越来越多的新项目需求，这样的需求开发与否以及优先级排序就不能只在产品部内部进行决策，需要上升到公司级层面共同决策。因此后期我想可以通过在公司内部成立<产品评审委员会>的形式，召集公司产品智囊团在更大范围内对产品方向、规划进行探讨和决策。

以上是本期产品部关于需求收集、分析及管理办法的分享，过程中肯定有不完善的地方，也希望大家多多批评指正，帮助我们及我们设计的产品共同成长！

再次感谢大家利用宝贵时间看完此文，我们下期见！