不做没有需求的产品经理（我的产品方法论1）

不知从什么时候开始，“方法论”一词开始给人一种假大空的感觉，许多人谈到方法论，言必称赋能、抓手、组合拳…但抛开这些略显过时的互联网大词，“方法论”还是有其积极意义的。本质上说，方法论就是指导我们工作或解决问题的指导性原则，好的方法论能让我们事半功倍。因此，在做了几年产品经理之后，我也试图总结出一套自己的产品工作方法论，并以此为纲，时时检验自己的行为是否脱纲越界。

产品经理的工作技能可以分为硬技能和软技能。所谓硬技能，是指工作中有清晰的指标并可以被观察和量化的技能，它可以带来具体的产出。对于产品经理来说，这种产出通常是指一份合格的PRD。

想要产出一份合格的PRD，我们需要经过发现问题、分析问题以及解决问题的三个阶段。这篇文章，我们先来谈谈如何发现问题。

发现问题可以理解为发现需求。产品经理的工作都是围绕需求展开的，没有需求的产品经理是岌岌可危的。因此，收集需求就是我们最先要做的事。如何收集需求，这里我总结了三个方法。

一、建立信息获取渠道

最常规的信息获取渠道就是收集用户问题反馈的聊天群。对于B端产品经理来说，如果做的是企业内部系统，那么就需要针对在使用你所负责的系统的同事，建立一个问题反馈的聊天群。通过这个聊天群，你可以第一时间知道用户遇到了哪些问题。

当然，也可以主动一点，询问用户对于某些功能的使用感受，引导他们说出内心的真实想法。如果做的是saas系统，则每个客户都需要一个问题反馈群，这种聊天群一般会由实施团队去建立，由他们将问题或需求反馈给产品经理。

另一个渠道就是在系统内上线一个问题反馈入口。这几乎是所有的saas系统都会有的基础功能，它可以在更大的范围内收集到用户遇到的问题或是诉求。在这个反馈平台上，产品经理最好是能够定期回复用户的反馈，以避免用户觉得反馈的问题石沉大海。这样可以鼓励用户更积极的反馈问题，也可以让我们更加直接的感受到用户在碰到问题时的情绪，以便我们更好的理解某个具体的问题。

再来就是问卷调查。这是效率比较低的一种获取信息的渠道，一般是新系统/功能上线一段时间后为了评估大部分用户对于新系统/功能的整体使用感受时会采用这种方式。问卷设计最重要的一点就是对于问题的描述要采用中立的语言，避免引导用户做出不够客观的答案。相对来说，用户调查需要用户付出的更多的时间成本，为了收集到更多的有效反馈，设置一个小奖励给到完成问卷的用户效果会更好。

最后就是客户走访。这是成本最大的一种方式，也是效果最好的一种方式。客户走访可以让我们当面看到用户是如何在使用系统，这很可能与我们的设想并不相同。完成相同的目的，你可能知道更便捷的操作，但是客户往往还在使用更繁琐的操作，为什么呢？也许是他不知道便捷操作；也许是他更熟悉老办法，不愿做出改变；也许老办法有额外的作用等等…这些问题的答案，往往只能在客户走访之后才能知道。

二、数据洞察

对于产品经理来说，我们除了要学会倾听用户，也要学会倾听系统。系统的反馈就隐藏在数据之中，不同于用户，系统从不说谎。

对于核心功能，我们需要每天观察它的数据波动，一旦波动超出正常范围（这个“正常范围”需要通过过往的正常数据来测定），我们就需要去搞清楚发生了什么？通常一个指标出现了异常波动，我们可以先分析其上游功能的数据变化情况。

比如我们观察的指标是gmv，那么gmv突然升高，我们可以往前看下单页面的“访问人数/人次”、“下单人数/人次”、“转化率”等，不同数据的变化所反映出的事实是不一样的。比如是访问人数突然变多，那是不是因为开辟了新的获客渠道？这可以通过对“访问用户”的来源做进一步的分析而知道。比如访问人数不变，但是下单人数突然变多，那合理的猜测就是当前产品在做活动。

当然也不排除系统出现漏洞，有用户在薅羊毛。总之，尽快搞清楚发生了什么对于产品经理来说很重要，我们是产品的第一责任人，产品的任何异常我们都应该最先知道，以便及时作出应对之策。

数据洞察的另一个现象是“预期违背”，这通常在新功能上线之后发生。比如，我们给系统做了一个新首页，同时也保留了进入旧首页的入口，我们的预期是80%以上的用户会使用新首页。但是上线之后的数据告诉我们，只有50%的用户选择使用新首页，这就是“预期违背”。通常出现这种状况，我们需要行动起来，找到典型用户聊一聊，问问他们为什么更喜欢老功能。而在这个过程中，往往是能够挖掘出有价值的需求的。

三、战略规划

前两种方法属于自下而上推进需求落地的工作方式，更多依赖于产品经理个人的主观能动性，而第三种方法则更多是自上而下的方式，更考验产品经理对于业务的理解程度和对目标的拆解能力。

产品经理在接到战略类需求时往往是公司在规划年度OKR或季度OKR的时候。由于OKR是自顶向下层层传导的，每一个产品经理都需要和自己的上级对齐年度或季度最重要的几件事，上级也会向更上一级对齐，直到老板，这就有效保障了公司自上而下目标的一致性。

对于B端产品经理来说，不光要和自己的上级对齐目标，也要和自己关系最紧密的业务部门负责人对齐目标。因为向上看，产品和业务的目标必然是会交汇的。对齐目标是简单的，但更重要的在于，如何将上级或业务部门的目标转化为自己的todo。这里我经常用到的办法是：先穷举实现目标可以采用的办法，再筛选出哪些办法是在系统层面能实现的，最后再和业务部门沟通选出ROI比较高的1个或几个作为接下来的todo。

这里我们以拆解业务目标来举个例子，比如业务侧第一季度的某一个目标是：激励线下代理商，完成代理商侧有效拉新同比去年一季度有30%的增长。

这个目标的关键信息是什么？是“激励线下代理商”，驱动他们去做拉新。理解了目标之后，第一步，先穷举出实现拉新增长的办法：1、做拉新排行榜，并以排名结果给代理商激励，刺激他们多做拉新动作。2、做辅助拉新的工具，用来增强代理商日常触达用户的能力，比如crm工具或者企微等。3、配合营销节奏做一些拉新活动，帮助代理商更容易完成拉新。4、广告投放，将更多的流量引导到线下。5、通过招商，引进更多代理商来达成这一目标。

第二步是筛选出哪些办法是我们（产品经理）可以去做的，在这个例子中，很显然前三个是合适的，后两个办法通常是业务侧自己应该去做的尝试。

最后，具体做什么，这需要产品经理和业务部门进行深入的沟通，决策的基础就建立在对业务的足够了解上。产品经理做出的系统需要业务部门的使用和推广才能发挥作用，因此目标一致是产品成功的前提。

以上就是发现问题或者说收集需求的三个方法，通过建立信息获取渠道、数据洞察和战略规划，相信每一个产品经理都能收集到足够多的需求。

但是，光有需求是不够的，哪些需求该做，哪些不该做，该做的需求应该什么时间去做，应该做到什么程度，这些对于产品经理来说，是更为重要的。美团的王慧文曾经说过，看一个产品经理是否入门，就看他知不知道哪些需求不该做。要做出这些判断，依靠的是产品经理对于问题的分析能力，那么下一篇，我们就来聊聊如何分析问题。

本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场，不承担相关法律责任。如若转载，请注明出处。 如若内容造成侵权/违法违规/事实不符，请点击【内容举报】进行投诉反馈！