求知 文章 文库 Lib 视频 iPerson 课程 认证 咨询 工具 讲座 Modeler   Code  
会员   
 
  
 
 
 

需求的人也是客户

 

2011-2-25 来源:网络

 

  大部分行业的大部分产品经理必须承认,其实我们很少能有机会能够和终端客户面对面的,原因很多,时间上的,精力上的,市场上的,这其实就给产品经理出了一个自相矛盾的问题:既然市场客观要求我们要亲自接触客户,但是现实的情况却往往不能提供这样的条件。
对于从事企业消费类产品管理的朋友来说,对于需求的获取或许还稍微好一些,并且也会有更多的机会能够直接接触到终端客户,但是对于从事大众消费类产品管理的朋友们来说,这样的机会就少之又少了。

  我个人现在也在为这个事情头疼,虽然说公司也强调产品经理应该尽可能多的处于一线,但是往往许多公司内的事情就把产品经理们折腾个够呛了,对于跑一线的事情往往是心有余而力不足了。因此,对于大部分的产品经理来说,我们获得市场需求的主要途径就是经过第三方的反馈。

  这个第三方所涉及的范围就比较大了,有代理商的,有经销商的,有销售部门的,有技术部门的,也会有高层的,总之,他们对产品的需求犹如洪水一样会不断的朝你涌来,面对这样的情况,我们又该如何应对呢?

  在这种情况下,我们通常会面对一个最为核心的问题:这些第三方往往认为他提的需求就是市场最需要,应该在新产品中必须要实现的。

  也就是说,第三方喜欢并且习惯于充当产品设计者的角色。

  01年的时候,我负责一款大众消费类的桌面软件,因为有一款软件已经在市场上占据了绝对的优势,无论是从品牌知名度,还是产品本身的性能上,我们都无法与其直接抗衡,但是,这个产品是基于公司整体竞争战略的,属于冲击市场的产品,是为我们的主力产品服务的,一般来说,对于这种产品,公司往往会重点考虑成本而不是产品本身,但是中国许多软件公司(包括许多互联网公司)的情况大家都比较清楚,基本上都是技术起家,一把手基本上都是技术高智商,业务低智商,他们习惯于对每一个产品指手画脚,把自己的一些想法或影或软的加入到新产品中去,而那些往往是思路不错,但是市场并不需要的想法。

  因为刚开始做产品管理时间不长,缺乏斗争经验,并且无论是从从业经验还是资历上,肯定都无法和这位老大相提并论了,虽然我隐隐约约感觉他的想法有些不符合市场的要求,但是我又没有足够的依据来支持我的观点,因此,就稀里糊涂的定在了新产品的规划中。

  产品上市后,果然印证了我的猜测,用户对于这些和产品定位几乎没有任何关系的应用根本不买账,不断在公司产品论坛里抱怨这些无用的应用使自己的电脑资源空被消耗,影响到了正常产品正常应用的使用,而对于公司来说,平添了许多的开发成本,其中有一个应用我记得非常清楚,公司并没有实力进行开发,是购买第三方的,花了不少钱。

  从这个案例中可以看出,通常第三方要充当起产品设计者的角色,往往不会考虑得非常全面,要么是不知轻重缓急,要么是做捡了芝麻丢了西瓜的事情,但无论怎样,对于公司来说,都是成本的无谓付出。

  其实这也是从侧面印证了为什么产品管理能够逐渐兴起的重要原因,就是公司期望产品管理者能够为企业评估出一个性价比最高的业务解决方案,并最终实现。

  老汤的一个观点我比较赞同,就是“产品经理对于企业来说,最能体现价值的地方就是通过自己的工作,让企业有限的资源流向到最有价值的产品上”。

  其实不止是技术部门喜欢充当产品设计者的角色,许多销售部门的同事也喜欢和产品管理者在业务上较真,他们往往认为自己是在第一线工作的,接触客户的机会要比产品管理者多的多,因此,他们也就想当然的认为自己是最了解市场需求的,因此,对于产品管理者的产品规划和设计,往往是横挑眉毛竖挑眼,有时候甚至是不屑一顾。

  因此,产品管理者在做需求分析的时候,最不想遇到的情况就是:第三方一般会把自己想象成设计者。

  其实他们这样想象倒也无大碍,只要产品经理心里有谱就行,而现实的问题往往是我们不得不面对高层和强势部门给我们的压力,甚至更窘迫的是,有时候产品经理就成了这些需求反馈部门的代笔者,他们想的需求是什么样的,我们要做的就是用文档记录下来,按照一些朋友的话,产品经理咋感觉就是一个写文档的呢?

  有朋友会说了,为什么你对于第三方反馈上来的需求如此态度强硬,甚至是反感呢?

  这里澄清一下啊,第一,我不是反感需求多,需求越多,越有助于我们更全面的了解市场,第二,我不反感这些第三方,他们是我们的同事,是和我们一同战斗的伙伴,我们之间是互相帮助,互相支持的关系。

  我所要说明的是,因为种种原因,他们反馈上来的需求往往已经不是我们这些产品经理所期待的最原始的需求了,也就是说,这些需求或多或少的出现了遗漏、增加、删减的情况。

  出现这种情况的原因有客观的,也有主观的。

  客观的原因更多的是和第三方的素质、能力,所依赖的反馈渠道,反馈工具,信息规范等有很大的关系,这个就不说太多了,因为这需要企业从整体上来规范和加强信息反馈制度的建设,当然也不仅仅限于是市场需求反馈这一信息链。

  重点说一下主观上的原因。

  产品团队中的每个人都希望产品能够做好,能够在市场上有出色的表现,但是,我们必须承认,也正是因为每个人都有这种美好的期望,而造成了许多团队成员在反馈需求的时候容易出现以下几种情况。

  1、对于自我关注的需求,习惯于夸大其词

  我们经常会遇到这样的情况,一个级别本来并不高的需求,但是就是因为提出这个需求的第三方非常希望能够实现,他往往会增加许多形容词和量词来给我们一种压力,通常的有“这个需求非常(类似的还有:相当;十分;绝对;等等)重要”,“我接触的客户几乎(类似的还有:全部;差不多;大部分;百分之XX;等等)都期望有这个需求”,等等。

  有时候确实能够让我们这些产品管理者不明真相,花了很多的时间去验证这个需求的重要性,如果果如其言也好,但怕的就是名不副实。

  2、对于自我不太关注的需求,习惯于修修剪剪

  这种情况也非常普遍,一个本来能够对我们非常有启发,也是客户非常期望的需求,在经过第三方的反馈后,可能就是轻描淡写了,这还不是最严重的,最严重的是他们自己就成了一个过滤器,把许多他们并不关注的需求在没有经过正规的需求筛选过程处理后,自己就筛选掉了,给我们的只是他们包装好的需求集,或者说是已经丢掉了许多有价值信息的需求。

  因此,国外有许多有经验的产品管理者告诫后来者,不要完全相信第三方提供给我们的数据,即使是专业的数据分析公司也不要相信,有营养的还是那些没经过什么加工的粗粮。

  老汤好像有一篇博客就是说这个事情的:《产品经理工作法则一:相信自己的双腿,不要相信自己的耳朵! 》,推荐大家看一下。

  3、对于自己想到的需求,习惯于私自增加

  这个本来是没有问题,大家有好的想法,我们是非常欢迎的,即使是目前不能实现的,我们都会关注并长期跟踪的,但是问题就出现在第三方在反馈这个需求的时候,不是说这是我个人的想法,而是把这个需求包装成是客户的需求,如果再加上第一种情况,这就让我们 这些产品经理确实难辨真假了。

  因此,需求分析原则三第二点强调的就是:第三方可能会遗漏或补充一些额外的需求。

  这里再加一句,这些额外的需求不一定是客户提出的。

  那么,有朋友又会说了,对于这种对需求自由发挥的情况,我们是要坚决制止,还是睁一只眼闭一只眼呢?

  两种思路都不可取,坚决制止,难免会影响团队成员的积极性,毕竟不能一棒子打死一片,广开言论的渠道还是必须的,睁一只眼闭一只眼也不行,那样会让自己消极懈怠,增加自己的工作量和公司的成本。

  那么,应该用什么样的态度来对待呢?

  其实并不难,就是“对第三方的自由发挥不应抱怨和生气,而是将其视为客户”。

  其实这个态度里有一个核心的词,是什么呢,就是“客户”。

  先抛开一些客观前提,我们可以想一下,如果我们把需求反馈者不分为直接和间接,从我们产品经理的角度看,只要是提需求的,就是我们的客户,其实这个问题就比较好解决了。

  公司应该有一套客户信息反馈制度和流程,让现在的第三方反馈者和终端客户进入到一样的信息反馈体系中,对于我们来说,就不太容易受到同事或者上级这种特殊身份的影响,并且对于需求的分析,我们也会更加独立,而不太容易受到第三方个人情绪的影响。

  当然,这只是一种理想的状态,正如刚才说到的,这是抛开了客观前提的,但是有一些客观前提也会很大程度影响到这个信息反馈系统的运转。

  例如,你现在的公司是否有公开的反馈系统,是否有可行的反馈制度,是否有统一的反馈工具,是否有统一的反馈信息标准,等等吧,这些客观条件如果没有或者不够完备,同样也会影响到我们对需求的分析工作。

  在这篇文章中,我简单做了一个需求反馈文档模板,大家可以下载下来看看,一个模板就是一个工具,本身没有任何意义,它必须存在于具体的环境中才能发挥相应的价值,等这个系列完成后,我考虑整理一下我以前在需求反馈体系建立中的一些个人经验,详细来谈这个该如何去做。

  总结一下需求分析第三个原则的中心思想:

  1、需求分析第三个原则:第三方也是我们的客户。 只要是对我们的产品和业务提出需求,就是我们的客户,应该一视同仁。

  2、原则第一点:第三方一般会把自己想象成设计者。 他们对产品或许很熟悉,但是对整个业务可能不熟悉,因此,他们成不了设计者。

  3、原则第二点:第三方可能会遗漏或补充一些额外的需求。 每个人都期望产品能做好,这种强烈的成功心理容易让人们产生日晕心理,从而影响我们对需求的筛选。

  4、原则第三点:对第三方的自由发挥不应抱怨和生气,而是将其视为客户。 客户是第一位的,而他们又是我们的客户,因此,我们应该心平气和的对待他们的想法,无论这些想法是出于公还是出于私的。



需求分析方法—把测试流程图表化
敏捷需求分析五大关键因素
写好市场需求文档的10种技巧
需求分析中减少客户摩擦的法则
软件项目需求管理复杂性分析
EPC-事件驱动的流程链
更多...   


软件需求分析与管理实践
业务建模与业务分析
软件需求分析与管理
软件需求分析师
面向产品的需求分析与管理
IT规划体系与实践


北京 软件需求分析与管理
某知名基金 软件需求分析
联想 业务需求分析与建模
财税领域某IT服务商 测试需求分析
医疗行业 面向产品的需求管理
某知名IT服务商 测试需求分析>
某高新技术公司 测试架构、需求分析
更多...