产品经理是要对产品或产品线负责的，不能只关注在需求转化上，也需要关注需求实现，两手都要抓，两手都要硬。
很多人可能都还不明白需求分析和需求管理之间的区别，通常我们说起来最多的都是需求收集和需求分析，最常见的介绍一般都说成是需求分析该如何如何，需求分析的过程如何如何，与需求有关的其他活动提及的比较少。其实需求收集和需求分析都只是需求管理过程中的一个环节。
一个项目做了很久，感觉总是做不完，就像一个“无底洞”。想尽快完成这个项目，但总是有新的需求要做。实际上，这里涉及到一个需求管理的概念。项目中哪些该做，哪些不该做，做到什么程度，都是由需求管理的过程来决定的。
通常需求管理是对需求生命周期的管理，从需求的产生到需求的结束，过程可以划分为以下几个独立的阶段：
需求收集与整理：基于现有产品的业务发展方向，通过与用户的交流、问卷调查等方式，收集到用户对于该产品业务的看法，并对这些看法进行归类整理的一个过程。
这个过程需要对产品的业务建立起一个概念模型，以便对其进行抽象描述。用户很多时候都不懂专业术语，所以需要尽可能的使用场景化的语言描述方式去进行描述。比如想调研用户的理财方式，很多用户可能不清楚“理财”的具体意思，但你问他“平时是如何管理多余的资金，是变成银行存款还是有别的方式？”可能他会更容易明白。
需求分析：围绕产品的业务核心，目的是找到实际要做的需求，并明确需求执行的优先级。
前面我们也说过，需求分析的关键是找准目标用户群体，所有的分析方法都要基于业务本身和目标用户的特性进行针对性的运用。除了要从收集回来的需求当中找到要做的真实需求外，还要基于需求的业务价值评判出需求执行的优先级。
需求定义：根据需求调研和需求分析的结果，进一步定义准确无误的产品需求。
需求定义的过程更多的是对需求进行准确的描述，从用户使用场景的角度、功能操作流程的角度等方面，对分析出来的真实需求做出完整、无二义性的定义，让其他相关人员能准确的理解需求。
需求评审：各方对需求进行确认的过程，达成统一认知和共识，使需求能够推进实现落地。
在需求评审的过程中，一定要说明清楚需求的背景、价值、意义，而不是纯粹的需求讲解，这样有助于各方对需求的理解。
需求跟踪：跟进需求的设计实现过程，保证需求的实现不打折扣，并随时关注需求的变化。
通过比较需求定义与后续工作成果之间的对应关系，建立与维护需求跟踪列表，确保产品依据需求的定义进行开发。
需求变更：当因为外部环境变化或者内部需求定义错误导致需求需要更改时，要做好变更的管控，防止因为变更而导致需求执行的过程无法进行下去。
从严谨的角度来说，定义好的需求是不允许变更的。但谁都无法保证不会犯错，且互联网环境变化速度很快，需求变更产生了是不可怕的，可怕的是变更失控，过多的变更会使需求执行的计划整体被打乱。
以上各个需求管理的环节在整个需求的生命周期当中都会实际发生，但很多小伙伴在实际工作当中可能都没有特别注意，更多的都是关注在需求分析的环节，而没有注意后续的各个环节，导致虽然找到了真实需求，但却没有办法落地，或者没有办法产品化。从用户需求转化为产品需求更多的是前三个环节，而从产品需求变成实际的产品则需要后三个环节。
前面我们有专门讲过需求收集、需求分析和需求定义，这是发现并转化产品需求的关键，需求评审、需求跟踪、需求变更则是需求落地的关键。产品经理是要对产品或产品线负责的，不能只关注在需求转化上，也需要关注需求实现，两手都要抓，两手都要硬。
需求评审是各方对需求进行确认的重要环节
需求评审的重要性体现如下：
评审过程本身也是一个知识传递过程，评审人员与产品经理一起讨论用户需求，这有助于评审人员获得用户需求的前期认识。
评审过程中可能发现不明确的或者遗漏的需求，这需要产品经理进行二次需求分析和定义。
评审过程中可能发现某些特殊需求，这时产品经理和评审人员可以群策群力共同思考解决问题的方式。
当局者迷、旁观者清。再有经验的产品经理也可能犯错，评审人员可以提出更合理或者更有建设性的想法供产品经理参考。
需求跟踪是产品经理日常必须完成的工作
产品经理每天都需要跟进当前迭代中需求的实现进度，确保需求执行的过程没有出差错，一般而言，需求的跟踪分为两种：
正向跟踪：检查已安排的每个需求是否都能在后续的实现过程中有相对应的部分，确保没有漏做的需求，并保证需求的实现程度和需求定义要求的一样。这就需要每天都与后续的各个负责实现的人员进行确认。
逆向跟踪：根据已有的交互设计稿、系统设计文档、测试用例文档等成果文档，反向检查是否包含了所有已安排的需求。
需求变更最考验产品经理需求把控能力
需求变更的原因有很多种，这里不去具体展开。产品经理要做的更多是需求变更的管控，我们都知道需求变更对产品来说坏处多于好处，也有变了之后反而好的，不过是少数。控制变更的规则比较简单：
如果需求变更带来的好处大于坏处，那么允许变更，但必须按照已定义的变更规程执行，以免变更失去控制。 如果需求变更带来的坏处大于好处，那么拒绝变更。需求变更控制过程中最难办的事情是莫过于“拒绝用户提出的需求变更请求”。产品经理要灵活的控制变更的尺度，以产品业务价值实现为导向，更多的从产品角度出发。
需求管理是一项十分重要的工作，据调查显示在众多失败的项目中，由于需求原因导致的占了很大的一部分。因此，需求管理对产品能否最终实现产生至关重要的影响。
