DC Blog

回首页

如何处理产品需求的经验清单
收集、处理需求是产品经理的基本功,也是最难做好的工作。
  1. 如何处理领导提出的需求。领导提出的需求一般可以分为两大类:战略需求和业务需求。战略类需求一般处理周期比较长,变动也不大。建议处理方式是定期和领导开产品战略会议,制作产品路线图,避免突如其来的产品方向变化。如果你碰到非常勤快的领导,他可能还会经常给你提一些业务需求和产品细节上的问题。出现这样的情况,可能的原因有三个:一是你对产品战略理解不够清晰,不能从战略的高度来理解和处理需求。二是做事不得法,找不到工作重点,总是做一些无关紧要的事情。三是自己太懒。领导虽然经验丰富,毕竟时间有限,需求收集不能走在领导前面,很大原因是自己不够下功夫。在腾讯,产品经理有个1000、100、10的规则,如果你能做到一般不会走在领导后面,除非你的领导下的功夫比你还大。(腾讯要求产品经理每周都要看1000篇帖子或微博、100篇博客、做10个用户访谈)
  2. 识别需求的真伪。需求有真需求和伪需求。如果你发现了一个看起来很不错的商业模式,也没有很大的市场参与者,不要以为自己发现了什么宝藏,这很可能就是一个伪需求。如果你无法判别需求的真伪,可以借助精益创业中的MVP产品模型来进行验证。例如,你打算做个XXX培训的付费课程,你不知道用户会不会付费,你可以先做出课程大纲,拿给目标人群,看他们愿不愿意为此付费。
  3. 如何处理用户的反馈。如果用户提的是产品BUG,应第一时间解决,并对用户表示感谢。对于用户提出的非BUG类的反馈,产品经理应该有自己的独立判断,能通过和用户的沟通或数据分析,发现用户需求背后的真实意图。如果你没能识别出用户需求背后的真实需求,贸然按照用户所要求的去做,得到用户认可的机率应该不会太大。例如,在马车时代用户告诉你他需要一匹更快的马,其实快马背后真正的需求是更快的到达目的地。这时候,用户给你要一匹更快的马,你可能会给他一辆汽车。
  4. 产品需求的紧急程度应该根据业务实际需要而定,而非根据需求提出方的角色。把谁的需求优先处理,需要一个判断依据,不然产品经理的工作可能会比较被动。产品需求处理顺序应根据业务需求、用户需求强度等要素来判断,而非提出需求的角色。一个只做领导需求的产品经理绝对不是一个合格的产品经理,一个懂产品的领导也不会一味的要求把他的需求优先处理。如果你处理的需求都来自于领导,这个时候你就要反思下自己能否胜任产品经理这个岗位了。
  5. 寻找“更”需求。现在很难再找到未被满足的用户需求了,提供比现有方案更好的解决方案是个不错的路子。更方便、更便宜、更好玩的解决方案可以更好的满足用户的需求,只要新方案的新增价值大于用户迁移成本,用户就有足够的动力进行迁移。这种“更”需求,优点是这些需求是已经被验证可行的存量需求,容易切入。缺点是存量市场是现有市场竞争者的赛道,创业公司要想突围,比较困难。不过从成本的角度来看,也应该优先考虑,先做存量市场,通过存量市场打开增量市场。一开始就做增量市场的话,成本太高,风险太大。
  6. 分清楚自己的需求和用户的需求。我们做需求分析的时候,很难摆脱自己过往的知识和经验。如果自己恰好属于产品的目标用户群体,那么依据自己的经验来处理需求,一般不会出现太大偏差。如果产品经理自己不是产品的目标用户群体,例如男性产品经理做女性用户的产品,这个时候就考验产品经理的需求把握能力了。
  7. 要不要从竞品那里找需求?微信张小龙曾在腾讯内部公开课上说过:不从竞品那里找需求。之所以有这么个说法,从竞品那里找需求肯定是个普遍现象。那么,我们在做产品的时候要不要从竞品那里找需求呢?我的建议也是不要直接从竞品那里找需求,尤其是对竞品功能的生搬硬套。产品要想在市场上取得一席之地,就要具备独特的用户价值,也就是独特性。从竞品那里找需求,很容易迷失发展方向,不会形成产品自身的发展逻辑。微信支付如果跟着支付宝的路子走,肯定不会有今天的成绩。
  8. 不能为了满足1%的用户需求,而干扰其他99%的用户。处理用户需求时,要确认小部分用户的特殊需求不会影响到其他大部分的用户,要找到平衡点。用户可分为不同的层次,如入门小白用户、中级用户和重度核心用户,他们对产品的功能都有各自不同的诉求。例如,如果游戏中一味的照顾付费用户的需求,免费用户就会跑,最后付费用户也没有优越感,也会流失的。
  9. 需求文档是产品研发团队沟通的纽带和基础。写需求文档容易陷入两个误区。一是产品文档是必须的。在经验丰富的产品研发团队中,可以采用备忘录的形式来快速开发、迭代产品。即通过沟通讨论,大家明白需求之后,就可以进入开发阶段,然后通过备忘录的形式来记录需求。二是产品需求文档越详细越好。其实越详细的文档越容易误解,沟通成本也非常高。优质的需求文档的一定是简洁易懂的,要学着把需求文档写少、写精。
  10. 用户量和功能复杂度成正比。用户量逐渐变大的时候,产品的功能也要跟着丰富完善。产品初期用户量小,限于成本考虑,会放弃小部分用户的需求。当用户量达到一定的量级,即使占比很少的用户,数量也会很大。这时候满足这部分用户的需求,就变的很有必要。例如多语言、大字体、语音操作等这类功能,在产品初期限于用户量和成本的问题,一般不会做。另外,产品初期为了尽快抢占市场,某些制度或限制会比较宽松,但当用户达到一定规模后,宽松的制度就会带来很多问题,就要收紧这些制度。例如BOSS直聘在开始时,对招聘信息的发布要求很宽松,只要注册就可以发布一条招聘信息。随着平台用户规模和影响力的变大,很多骗子和传销人员就盯上了这个漏洞,最终导致悲剧发生。
  11. 搭建需求收集渠道。一个自动化的需求收集体系,可以大大减轻产品经理需求收集的难度,提高需求收集效率。例如跟客服&市场部门同事沟通,定期发送客户问题反馈汇总表;开发线上用户意见收集功能,收集线上用户意见;通过产品数据分析,找到可优化的地方。
  12. 通过用户调研、问卷调查、用户访谈、信息采集等手段来挖掘的需求,只能作为参考。绝大部分用户是无法说清楚自己真正想要什么功能的。客户并不熟悉你的技术和想法,他们甚至无法理解你的意图,客户的需求是无限的,你的资源是有限的,你要用你有限的资源尽快找到突破口和卖点,找到一个值得深耕的市场。
  13. 产品价值决定需求。产品需求不可能无限延展,必须紧紧围绕一个核心价值点。例如当年暴风影音能脱颖而出,就是在满足用户视频播放需求上做了其他播放器没做的功能,提供更多视频格式的播放支持。
  14. 通过数据分析得来的需求,可靠性要高很多。例如通过分析用户的访问数据,及业务的运营数据,可以清楚了解产品的实际表现。网上的分析工具多种多样,做分析时要选择适合的分析工具。网络上现成的分析工具只能分析一些基础的信息,业务信息还是要自己建立分析模型,通过数据埋点等技术获得实际运行数据,最后通过模型得出相应的结论。
  15. 需求必须可度量、可测试。需求必需是明确的,不能模棱两可,要可度量、可测试。产品经理的工作就是理解需求,理解到应该做什么、做到什么程度,并建立起一套解决问题的方案。
  16. 没有弄清楚真实用户需求之前,不要轻易给出解决方案。一个有损用户体验的解决方案,还不如没有。在没有想明白、找不到合适的解决方案之前,就不要给出一个半桶水的解决方案。