产品经理如何基于需求迭代产品（上篇）：需求调研的四个步骤
需求调研是为了明确版本迭代的内容，产品设计是基于需求出详细解决方案，需求调研和产品设计阶段都要灵活，某个已经确定下来的需求因为产品设计方案实现不了也只能被砍掉。
产品经理要为产品负责，并且以产品为手段，推动业务发展。
以产品为手段，就是把产品当做产品经理自己的延伸，用产品经理的思维和方法去解决问题推动业务发展，而产品就是思维、方法和解决方案的载体。
产品经理要通过产品表达想法，就像作家通过书表达想法，建筑师通过建筑表达想法。与书、建筑相比，互联网产品拥有敏捷迭代这一大优势，书和建筑没办法两周更新一次，但是互联网产品可以。总览产品的整个生命周期，其最小粒度就是版本，产品的版本迭代，就是推动业务的方法之一。
产品迭代，就是要基于需求进行产品设计以解决问题，一般包含需求调研和产品设计两块内容。（PS：需求挖掘和产品设计只是产品经理的工作内容之一，其他还包括项目管理、沟通交流、竞品分析、进度排期、产品培训等，实质上都是为产品迭代服务的，而产品迭代是为业务服务的。）
需求调研是为了明确版本迭代的内容，产品设计是基于需求出详细解决方案，需求调研和产品设计阶段都要灵活，某个已经确定下来的需求因为产品设计方案实现不了也只能被砍掉。
什么是需求调研和产品设计？
举个例子：有一天，产品经理在论坛上溜达，发现有个用户说他想吃鸭子。产品经理去沟通后发现，其实他是饿了，自己又喜欢吃鸭子。要不要解决这个需求呢？假设要，产品经理怎么解决呢？没条件就给个包子，有条件的给个秘制烤鸭，一碟小菜和一碗饭。
秘制烤鸭（来自百度图片）
需求调研阶段：
“发现有个用户说他想吃鸭子”→需求收集
“产品经理去沟通后发现，其实他是饿了，自己又喜欢吃鸭子”→需求挖掘
“要不要解决这个问题”→需求评估
产品设计阶段：
“没条件就给个包子，有条件的给个秘制烤鸭，一碟小菜和一碗饭。”→产品设计
下面将从需求调研和产品设计两个篇章分析。
需求调研的四个步骤
需求调研既然是为了明确版本迭代的内容，就要经过需求收集、需求挖掘、需求评估和需求评估的四个步骤。
需求收集，建立需求反馈通道和需求池，随时收集需求。
需求挖掘，洞察本质需求和场景，理解需求方。
需求评估，紧急度和重要性，尽量做即重要又紧急的。
需求分析，需求分解和边界确定，做到什么程度。
需求调研
需求收集：需求反馈通道和需求池
需求的来源包括公司、产品经理自己、运营、市场、用户等等。平常要注意建设良好的需求反馈通道，需求反馈通道可以分公司内部和公司外部。
公司内部是指内部的运营、市场、财务等部门提交的需求，随着业务发展公司每个部门都会提出各种各样的需求以便于数据增长、提升效率、减少成本、风控等。如果每个部门都每个人都想产品经理提需求，这就会出现A说要做B说不要做的信息偏差问题。所以要有一套需求提交规范，每个部门可以有个需求收集员，需求收集员向内对接部门成员统一部门想法，向外对接产品经理沟通业务需求。如果遇到部门间冲突/合作的需求，还要拉来各部门的相关人员进行讨论确定。
公司外部是指来源于用户、竞对、行业专家等人的需求。可以通过用户群、用户反馈、回访调研、微博吐槽等了解用户的需求和关注点，寻找用户的痛点，能从用户中脱引而出。可以通过使用竞对产品，查看竞对更新/帮助文档等了解竞对的发展情况和产品策略，寻找自己的差异化。可以通过行业会议、文章、当面交流等了解行业的趋势和行业未解决的痛点，创造企业从行业中突围的机会。
需求反馈通道建设起来以后，就要建设自己的需求池，把每个需求分门别类放好。关于需求池的文章有很多，我在就不再赘述了，注意记录两点：要解决什么问题和建议的解决方案。
需求挖掘：归因和同理心
每个人提的需求都是基于他自己的理解，而他自己的理解通常都是片面的，因为不了解具体情况或者只了解他那一端的产品。一个系统，暴露在人们眼前的永远只是冰山一角，没有海面下部分的承载，也不会有海面上的炫目冰山。
普通用户所提出的解决方案和需求都是有局限的，其价值不在于直接使用，而在于产品经理基于它去挖掘更深层次的需求。如果用户让你给他鸭子，你就给他一只鸭子，这就是产品经理的失职。
产品经理需要用自己的同理心，化身为用户，在他的场景下面思考需求。我一般用以下两种方法。
1.问题归因，需求的本质是什么？
当一个系统比较复杂的时候，绝大部分问题已经无法一眼看穿了，需要产品经理自己去挖掘。就像一个婴儿哇哇大哭，喂了奶不喝，摸摸额头不烫，抱起来一看原来是尿床了。这就是归因。
怎么进行问题归因？
首先，要了解问题的表现，婴儿的哇哇大哭就是不舒服表现出来的样子。
其次，了解导致问题出现的可能情况，婴儿不舒服的原因有饿了、渴了、生病了、尿床了、发现妈妈不在身边等几种。
最后，定位问题的本质所在，抱起来一看尿床了。
2.用同理心，为什么提出这种解决方案？
如果需求方只提出了解决方案却没有提出问题，也可以从解决方案中倒推问题本质，有条件的话还是向需求方求证比较靠谱。
（1）解决方案是了解需求方的一种途径，因为是建立于需求方自身对问题、产品和操作习惯等基础之上的。通过解决方案倒推需求方对产品、问题的理解和操作习惯，能够让我们更好的揣摩和理解需求方所处的角色和产品在需求方心目中的画像，以小见大，无论对后续需求评估和日常用户理解都很有帮助。
（2）解决方案也是个衡量标准。需求方提出的解决方案一般只有60分，只是能解决问题，处于需求金字塔的下方。产品经理以其为衡量标准，去判断自己的解决方案是解决了哪个层次的需求。理想状况下自然是超出需求方期望，触动需求方的G点。实际情况并不是谁的需求都要满足，因此要进行需求评估。
需求评估：重要性和紧急度
需求评估主要评估的是优先级，常用的方法有KANO模型、四象限模型、波士顿矩阵模型等。我比较常用的就是四象限模型，优先级：象限一 重要且紧急 ＞ 象限二 重要且非紧急 ＞ 象限三 非重要且紧急 ＞ 象限四 非重要且非紧急。
四象限模型
如何判断需求的重要性和紧急度？
1.重要性的判断标准，几个比较重要的情况
公司战略：产品经理是为产品服务，产品是为业务服务，业务为公司服务，公司战略落地的需求是从顶层下来，是需要优先考虑的。
利润相关：公司是要赚钱和生存的，通常客户＞用户，大客户＞小客户。
基础结构：产品是一座楼，基础结构就是地基，稍盖几层没有太大关系，如果地基没搭好就会有坍塌的风险。包括角色、实体、主业务逻辑、系统架构、账号体系等。
2.紧急性的判断标准
摸清实际情况：业务方、用户等通常会提出很多非常紧急的需求，产品经理不要被打蒙了，要先摸清实际情况，影响了多少业务，影响了多少用户，什么原因造成的等等。
根据影响评估：摸清实际情况后，根据需求的影响进行评估。核心业务高于边缘业务，影响用户多高于影响用户少，造成损失高于未造成损失等等
3.四象限模型
重要且紧急的比较少，如果多了就需要反思是评估问题还是产品基础没打好；
重要且不紧急的要多做，这些代表了产品的未来，而且要慎重，决策要慎重迭代也要慎重，要花时间去打磨他，不要急于求成，也不要一上一整个；
不重要且紧急的要少做，做多了产品容易被牵着鼻子走，还会造成资源浪费，如果多了就需要反思是不是以前产品迭代没做到位；
不重要且不紧急的要不做。
需求分析：需求分解和边界确定
需求评估后，就要对第一第二第三象限的需求进行需求分析，需求分析的目的是得出要做到什么程度，60分和90分效果和所需资源都不一样。
我通常会在需求分析时，先进行需求分解，后进行边界确定。
1.需求分解
需求分解，指思维发散，思考需求未来的发展，思考需求所触及的功能模块。
无论是业务、产品、功能或是需求，都有自己的生命周期，都是不断发展的。产品经理要基于现在判断未来。
把需求比喻成木桶，做产品就是造木桶，木桶的木板就是产品模块，木桶越大承载力越强成本也越高。需求分解的时候，产品经理要思考木桶以后要多大，木桶的木板要有几根。
2.边界确定
边界确定，指根据当前需求/业务状态、需求方心理预期确定需求的边界。
俗话说，最合适的才是最好的。如果你现在功能远远超出当前需求，可能到产品死了都还没用上，这就是对资源的浪费。如果你现在功能还不能满足当前需求，这也是对资源的浪费，下次迭代前需求方还会来找你。理想情况下，是超越当前需求一小段。具体这一段有多长，就需要根据需求重要性、业务发展情况等进行合理评估了。
边界确定就是确定木桶的高度，很高不合适很低也不合适，木桶的高度取决于要装多少水。决定了木桶高度之后，就可以去造木板了，造木板这就是产品设计的事了。
这些都是我自己的自我总结，也是我对世界的认知和总结，每个人的认知或多或少有所不同，希望能够帮助大家更好地认识这个世界。
作者 @Vency 。
关键字：产品经理, 需求调研, 需求, 产品
版权声明
本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！
