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