产品经理如何基于需求迭代产品（上篇）：需求调研的四个步骤

产品经理要为产品负责，而且以产品为手段，推进业务发展。

以产品为手段，就是把产品当作产品经理本身的延伸，用产品经理的思惟和方法去解决问题推进业务发展，而产品就是思惟、方法和解决方案的载体。

产品经理要经过产品表达想法，就像做家经过书表达想法，建筑师经过建筑表达想法。与书、建筑相比，互联网产品拥有敏捷迭代这一大优点，书和建筑没办法两周更新一次，可是互联网产品能够。总览产品的整个生命周期，其最小粒度就是版本，产品的版本迭代，就是推进业务的方法之一。

产品迭代，就是要基于需求进行产品设计以解决问题，通常包含需求调研和产品设计两块内容。（PS：需求挖掘和产品设计只是产品经理的工做内容之一，其余还包括项目管理、沟通交流、竞品分析、进度排期、产品培训等，实质上都是为产品迭代服务的，而产品迭代是为业务服务的。）

需求调研是为了明确版本迭代的内容，产品设计是基于需求出详细解决方案，需求调研和产品设计阶段都要灵活，某个已经肯定下来的需求由于产品设计方案实现不了也只能被砍掉。

什么是需求调研和产品设计？

举个例子：有一天，产品经理在论坛上溜达，发现有个用户说他想吃鸭子。产品经理去沟通后发现，其实他是饿了，本身又喜欢吃鸭子。要不要解决这个需求呢？假设要，产品经理怎么解决呢？没条件就给个包子，有条件的给个秘制烤鸭，一碟小菜和一碗饭。

秘制烤鸭（来自百度图片）

需求调研阶段：

“发现有个用户说他想吃鸭子”→需求收集

“产品经理去沟通后发现，其实他是饿了，本身又喜欢吃鸭子”→需求挖掘

“要不要解决这个问题”→需求评估

产品设计阶段：

“没条件就给个包子，有条件的给个秘制烤鸭，一碟小菜和一碗饭。”→产品设计

下面将从需求调研和产品设计两个篇章分析。

需求调研的四个步骤

需求调研既然是为了明确版本迭代的内容，就要通过需求收集、需求挖掘、需求评估和需求评估的四个步骤。

需求收集，创建需求反馈通道和需求池，随时收集需求。

需求挖掘，洞察本质需求和场景，理解需求方。

需求评估，紧急度和重要性，尽可能作即重要又紧急的。

需求分析，需求分解和边界肯定，作到什么程度。

需求调研

需求收集：需求反馈通道和需求池

需求的来源包括公司、产品经理本身、运营、市场、用户等等。日常要注意建设良好的需求反馈通道，需求反馈通道能够分公司内部和公司外部。

公司内部是指内部的运营、市场、财务等部门提交的需求，随着业务发展公司每一个部门都会提出各类各样的需求以便于数据增加、提高效率、减小成本、风控等。若是每一个部门都每一个人都想产品经理提需求，这就会出现A说要作B说不要作的信息误差问题。因此要有一套需求提交规范，每一个部门能够有个需求收集员，需求收集员向内对接部门成员统一部门想法，向外对接产品经理沟通业务需求。若是遇到部门间冲突/合做的需求，还要拉来各部门的相关人员进行讨论肯定。

公司外部是指来源于用户、竞对、行业专家等人的需求。能够经过用户群、用户反馈、回访调研、微博吐槽等了解用户的需求和关注点，寻找用户的痛点，能从用户中脱引而出。能够经过使用竞对产品，查看竞对更新/帮助文档等了解竞对的发展状况和产品策略，寻找本身的差别化。能够经过行业会议、文章、当面交流等了解行业的趋势和行业未解决的痛点，创造企业从行业中突围的机会。

需求反馈通道建设起来之后，就要建设本身的需求池，把每一个需求分门别类放好。关于需求池的文章有不少，我在就再也不赘述了，注意记录两点：要解决什么问题和建议的解决方案。

需求挖掘：归因和同理心

每一个人提的需求都是基于他本身的理解，而他本身的理解一般都是片面的，由于不了解具体状况或者只了解他那一端的产品。一个系统，暴露在人们眼前的永远只是冰山一角，没有海面下部分的承载，也不会有海面上的炫目冰山。

普通用户所提出的解决方案和需求都是有局限的，其价值不在于直接使用，而在于产品经理基于它去挖掘更深层次的需求。若是用户让你给他鸭子，你就给他一只鸭子，这就是产品经理的失职。

产品经理须要用本身的同理心，化身为用户，在他的场景下面思考需求。我通常用如下两种方法。

1.问题归因，需求的本质是什么？

当一个系统比较复杂的时候，绝大部分问题已经没法一眼看穿了，须要产品经理本身去挖掘。就像一个婴儿哇哇大哭，喂了奶不喝，摸摸额头不烫，抱起来一看原来是尿床了。这就是归因。

怎么进行问题归因？

首先，要了解问题的表现，婴儿的哇哇大哭就是不舒服表现出来的样子。

其次，了解致使问题出现的可能状况，婴儿不舒服的缘由有饿了、渴了、生病了、尿床了、发现妈妈不在身边等几种。

最后，定位问题的本质所在，抱起来一看尿床了。

婴儿哭泣

2.用同理心，为何提出这种解决方案？

若是需求方只提出了解决方案却没有提出问题，也能够从解决方案中倒推问题本质，有条件的话仍是向需求方求证比较靠谱。

（1）解决方案是了解需求方的一种途径，由于是创建于需求方自身对问题、产品和操做习惯等基础之上的。经过解决方案倒推需求方对产品、问题的理解和操做习惯，可以让咱们更好的揣摩和理解需求方所处的角色和产品在需求方心目中的画像，以小见大，不管对后续需求评估和平常用户理解都颇有帮助。

（2）解决方案也是个衡量标准。需求方提出的解决方案通常只有60分，只是能解决问题，处于需求金字塔的下方。产品经理以其为衡量标准，去判断本身的解决方案是解决了哪一个层次的需求。理想情况下天然是超出需求方指望，触动需求方的G点。实际状况并非谁的需求都要知足，所以要进行需求评估。

需求评估：重要性和紧急度

需求评估主要评估的是优先级，经常使用的方法有KANO模型、四象限模型、波士顿矩阵模型等。我比较经常使用的就是四象限模型，优先级：象限一 重要且紧急 ＞ 象限二 重要且非紧急 ＞ 象限三 非重要且紧急 ＞ 象限四 非重要且非紧急。

四象限模型

如何判断需求的重要性和紧急度？

1.重要性的判断标准，几个比较重要的状况

（1）公司战略：产品经理是为产品服务，产品是为业务服务，业务为公司服务，公司战略落地的需求是从顶层下来，是须要优先考虑的。

（2）利润相关：公司是要赚钱和生存的，一般客户＞用户，大客户＞小客户。

（3）基础结构：产品是一座楼，基础结构就是地基，稍盖几层没有太大关系，若是地基没搭好就会有坍塌的风险。包括角色、实体、主业务逻辑、系统架构、帐号体系等。

2.紧急性的判断标准

（1）摸清实际状况：业务方、用户等一般会提出不少很是紧急的需求，产品经理不要被打蒙了，要先摸清实际状况，影响了多少业务，影响了多少用户，什么缘由形成的等等。

（2）根据影响评估：摸清实际状况后，根据需求的影响进行评估。核心业务高于边缘业务，影响用户多高于影响用户少，形成损失高于未形成损失等等

3.四象限模型

（1）重要且紧急的比较少，若是多了就须要反思是评估问题仍是产品基础没打好；

（2）重要且不紧急的要多作，这些表明了产品的将来，并且要慎重，决策要慎重迭代也要慎重，要花时间去打磨他，不要急于求成，也不要一上一整个；

（3）不重要且紧急的要少作，作多了产品容易被牵着鼻子走，还会形成资源浪费，若是多了就须要反思是否是之前产品迭代没作到位；

（4）不重要且不紧急的要不作。

需求分析：需求分解和边界肯定

需求评估后，就要对第一第二第三象限的需求进行需求分析，需求分析的目的是得出要作到什么程度，60分和90分效果和所需资源都不同。

我一般会在需求分析时，先进行需求分解，后进行边界肯定。

1.需求分解

需求分解，指思惟发散，思考需求将来的发展，思考需求所触及的功能模块。

不管是业务、产品、功能或是需求，都有本身的生命周期，都是不断发展的。产品经理要基于如今判断将来。

把需求比喻成木桶，作产品就是造木桶，木桶的木板就是产品模块，木桶越大承载力越强成本也越高。需求分解的时候，产品经理要思考木桶之后要多大，木桶的木板要有几根。

木桶（来自百度图片）

2.边界肯定

边界肯定，指根据当前需求/业务状态、需求方心理预期肯定需求的边界。

俗话说，最合适的才是最好的。若是你如今功能远远超出当前需求，可能到产品死了都还没用上，这就是对资源的浪费。若是你如今功能还不能知足当前需求，这也是对资源的浪费，下次迭代前需求方还会来找你。理想状况下，是超越当前需求一小段。具体这一段有多长，就须要根据需求重要性、业务发展状况等进行合理评估了。

边界肯定就是肯定木桶的高度，很高不合适很低也不合适，木桶的高度取决于要装多少水。决定了木桶高度以后，就能够去造木板了，造木板这就是产品设计的事了。

这些都是我本身的自我总结，也是我对世界的认知和总结，每一个人的认知或多或少有所不一样，但愿可以帮助你们更好地认识这个世界。

Vency，两年经验产品经理，欢迎交流微信号：vency277136551，追求用户、技术、商业、社会价值的统一

搜索关注公众号 Vency不二或者vencybu2，向你们分享我或系统或粗放的深度思考

下一篇：产品经理如何基于需求迭代产品（下篇1）：产品设计的高内聚低耦合