沟通产品需求的要点及技巧(要点篇)

文章将围绕公司外接项目的产品从 0-1 的第一阶段(沟通需求),并结合自身实际经历,浅谈一下所总结的方法技巧,希望对大家,尤其是踏入产品的新人及做承接项目的产品经理有一定的帮助。

由于在小厂(小公司)工作,所以人员方面都是能者多劳,并且项目开展比较粗暴,基本上精简下来就是一句话:怎么最快,就怎么来,期间能省掉的都省掉。所以,我身为产品经理一职,为了产品的快速准确落地以及项目的顺利开展,沟通需求的时间和成本都需要极度控制。
当然,也正因为如此,让我经历了许多产品经理没有经历过的各种情况,也为我后来的产品之路成长打下了坚实的基础。

** 沟通 **

我们可以先来了解一下沟通是什么?它的目的又是什么?

  • 沟通是说明事物,把一件事情或一个东西,把它说得很清楚,这就是我们所要达到的目的。
  • 沟通是表达情感,有时候不说任何关于其他的事情,单纯为了表达心中的真实情感。

其实还有更多关于沟通的解释,但是我单独说这两条就够了,这也就是我们在跟客户沟通需求的过程中,需要牢牢把握的两个沟通的核心点。
我们与客户沟通产品需求,目的就是为了将需求说清楚、明白,让客户知道你的理解是否跟他想表述的一致,理解到对方最真实的情感表达,即深层次的需求,从而达到沟通产品需求的目的。

沟通需求,我们需要注意什么?

由于公司规模不大,设立的产品经理一职,也就相对应的只有我一人,所以外接项目无论大小都会通过我这边来进行客户的沟通。也因为如此,让我收获颇多,也自我总结了一些需要注意的地方以及技巧。
下面我将一一表述:

** 1. 项目背景 **

此处敲黑板!!!
每一个项目的开展,都会有对应的项目背景,项目背景包括很多,比如:该项目是怎么产生的?项目的意义在哪?项目的目的是什么?项目的组成部分有哪些等等。
因为项目背景包含很多,每一家的项目背景倾向也不一样,获取到的信息也就不尽相同,也正因为如此,导致项目背景恰恰是大家最容易忽略,且不关注的地方……
我刚来公司下半年,公司就承接了一个上市企业的光伏监控项目,当这个前后端(app 端、pc 后台)都涉及,且还包含硬件方面的项目砸在我一个产品新人手上时,我一脸懵逼,手拿着一份对方给我们的“产品文档”,完全不知道如何下手。在得知第二天将要去和客户面谈需求的时候,我更加不知所措。现在回想,当时自己的不知所措是为什么?估计是在于自己的害怕,因为不了解项目背景内容所带来的恐惧……
当时看着那份“产品文档”,其中的逆变器、采集器、辐照、装机量、pv1、pv2……让我一头雾水。
内心 OS 就是:what?这些都是啥??什么鬼!!!
我相信这种情况不仅仅是我,应该是大部分产品经理或是新人接触到一个全新,或者说领域跨度比较大的项目内容时的第一反应。
这个时候,让自己最快了解项目的办法就是仔细研究 ** 项目背景 ** 了。要记住:就算对方给的项目背景不是你想要的,或者提炼不出什么重要信息,你自己也要做一个项目背景调研。
例如:这个光伏项目,给到的信息不是太明白,那我们就去看同类的类似项目的介绍,了解项目的组成部分,开展情况,以及达到的效果目的。这样对于产品经理来说,也就能够更快的融入客户所处环境,从客户的方面思考并解决这些问题。
如这套系统,知道了它是基于硬件设备(光伏板、逆变器及采集器等)的配合使用,进行发电量、发电功率等数据的收集处理,及对这些硬件设备的工作情况进行管理,达到一个监控管理的作用,方便于多角色管理的一整套系统。
当我们在了解到这些信息之后,就对整个项目有了一个大概的轮廓,对于面谈来说,我们就能够快速带入。在有限的时间内,获取到更多对产品来说重要的信息,就不会因为在信息不对等的情况下,还要让客户在解释一遍客户认为“大家都懂的”内容,不利于我们的面谈效率。
假如:有产品经理工作内容包含类似这种,外接项目的前期需求对接沟通的话,最好是做一个小小的背景调研,让自己尽可能的和对方做到信息对等。这样在后续沟通对接当中,就会省掉很多不必要的沟通障碍,也能置身于对方来思考问题。

** 2. 沟通内容 **

为了第二天的面谈,我归纳着“产品文档”中描述的重点,各种假设我们双方之间的沟通场景,想着面谈时能够得到比文档更加详细的信息。
然而,现实却是不一样的场景……
双方碰面先寒暄一会,做各种准备工作,等待相应参与会议人员的姗姗到来。再然后,商务进行一些沟通工作,相谈甚欢,又花去了一些时间。最后到我们项目产品沟通的时候,时间其实相对于计划时间,已经所剩无几了。
这个时候,对于一个产品经理来说,所需要面对的实际情况就是如何在有限的时间内,通过沟通获取到对产品来说,最重要的信息。
** 1)涉及对象 **
首先,我们一定要沟通清楚,项目业务会涉及到哪些人?这些角色的参与,会牵涉到业务进行的哪部分?哪些角色是参与了我们业务的开展,但是却在客户沟通中,告知我们并不会使用到我们的最终产品?
了解项目业务涉及到的人,意味着知道了将要做的这个项目,这个产品是在这些人的使用或参与下进行的,对后续的业务流程这块,理解起来就会更加形象。
了解这些角色的参与内容,牵涉到了业务开展的哪部份,就会对角色权限这块有清晰的了解,在后续产品文档输出及与开发沟通中,就不会出现权限不明确的情况。
至于参与了项目的角色,但是在客户口述中,这套系统却不是给他们用的这种情况,这个时候就需要产品经理多多留心记录。因为这些角色及他们所涉及到的内容,说不定就是我们产品设计中的灰色地带。没有从一开始就把控好,后续就会演变成产品设计上的坑,继而影响到了整个开发。
从理论上来说,只要涉及到了项目开展进行的角色,都是系统的使用者。我们做的产品,根本上就是给他们解决问题的,那就不应该出现参与业务流程,却不使用的情况。
** 2)业务流程 **
业务流程,不用说也知道,这个肯定是我们在沟通过程中的重中之重,毕竟我们要是连业务流程都不清楚的话,产品设计是无法进行的,整个系统也就无法构建起来。
但是我们在沟通过程中,同样也要注意到一些情况。
** 情况 1:流程的不确定性 **
这种情况,在许多外接项目中经常遇见,产生这种情况的原因不尽相同。有的是因为公司较大、部门繁多、牵扯太多,需要层层确认之后,才能定下来。这就导致了:我们在一开始沟通的时候,就会碰到不确定的情况。
还有就是对方没有相对应的项目领头人,或是与我们对接需求的相关人员,并不能承担起确定的责任,这也就会产生后续流程不确定的情况。
这个时候,需要的就是产品经理的小本本,尽可能的把不确定的地方标记下来,一定要保证在有限的情况下,尽可能做到大家都无异议,并确定下来。这不仅仅是产品经理的责任,也是对客户和开发团队的尊重。
** 情况 2:流程的真实性,实际性 **
这种情况,一般出现在规模较小的公司,对自己的项目盲目乐观,对自身实力的高估,以及一些公司层面上的其他原因,让产品经理得到的业务流程并不真实,对产品设计和后续开发,产生不可估量的后果。
我在去年的时候,就做过这样一个项目,具体什么不方便说。但是可以说一下项目内容,是一套在线拍卖系统,系统包含拍卖行端的后台管理、拍卖行端的 app 及用户端 app 等,内容大致为拍卖行在后台管理上传相应的拍品。然后用户可以通过 app 来查看拍卖行的拍品,拍卖行线下正式拍卖后,通过拍卖行端 app 来进行线上线下的同步拍卖这样的一个业务流程。
直到现在,我仍然记得,这个项目的老总,亲自来到我们公司谈需求时说的话。
> “放心,你们提的这些问题,我们都能解决。“
“我们的理想情况是……“
“功能不要太复杂,但是体验一定要好……“

只怪当年太年轻,相信了对方说的,果然项目后面,崎岖不平,搞得大家都在忙着各种填坑,项目周期也对应比原先拖长了许多。
在项目沟通过程中,我们就提出了这个问题“支付怎么解决”(项目是针对法国拍卖行的,支付这块涉及到国家政策的限制),这个项目的老总就让我们放心,说他在和法国的类似支付宝一样的支付公司,正在进行洽谈合作事宜,只需要开发人员对接接口就行。
听起来是不是感觉问题一下就变简单了,但是,往往事实却很打脸。当我们项目开发差不多的时候,问题就接二连三的出现了,说好的对接呢?说好的和法国支付公司谈合作呢?
最后什么都没有,没办法,项目还是要继续,我就跟项目的老总商量了一下,重新设计和构思了一个支付流程,相比较原有的设计,多出了更多的操作流程,而且其中还严重影响到了客户的体验。后期还会增加了对方工作人员的操作难度,自然而然,也就影响到了我们的开发进度及工作量。
** 所谓的理想情况又是什么呢? **
就是认为的以自身来说,不会出现其他问题的情况,就是理想情况。但是,往往有理想,就有现实。
说好的用户可以通过 app 端购买,就可以像类似电商平台一样,获取到物流公司的接口,让用户不用繁琐操作,就能有很好的体验呢?为什么要让用户申请物流?为什么要让服务人员,确认物流信息?为什么用户不能看见物流信息?说好的理想情况就是这样么?
这就是所谓的理想情况对应的现实情况!
这又是一个因为被隐瞒而踩到的坑,后来没办法,在开发都已经差不多的情况下,又重新设计了一个对应的流程,在增加了各方的负担,牺牲了体验的情况下,最后保证了业务的正常开展。
这些因为对方没有正确告知或故意隐瞒我们,导致业务流程不清晰或不正确的情况,是一直存在的。假如不想被套路或者被开发同事鄙视的话,真的需要提高自己的“火眼金睛”,增强自己的鉴别能力,并做好相应的文档需求说明,让对方确认。这样即使是开发过程中,有需要变动的地方,也好有所依据。
现在回想,真的很感谢当时开发同事的不杀之恩。
** 3)想要达到的效果(目的) **
沟通过程中,我们一定要明确对方的最终诉求是什么?希望达到的愿景是什么?或者说希望解决的问题是什么?
我们的客户,其实并不太会直接说自己想要的目的是什么?大都说的是想要解决的问题是什么?
想要达到怎样一个效果,这个时候的产品经理,一定要把握好,这不一定是他的最终诉求,但是肯定是对方能够表达的最直接的痛点,我们需要做的就是顺藤摸瓜,了解对方诉求。
往往对方在给你诉说需要解决的问题时,通常都会顺带给你一个建议。记住:这个建议可以当作参考,但是不一定要当作最终的解决方法,因为这样做,并不是不行,但是大家扪心自问,我们这样做的话,还是产品经理吗,还需要产品经理吗?
> “我需要一辆更快的马车……“

最终需求是什么?这时候产品经理需要抓住的不是“马车”这个关键词,而是“更快”这个关键词,他应该理解用户的需求其实是在需要一个更快的交通工具上,所以汽车就被发明出来了。
这就是一个很好的例子,谨记。
这几点,基本上就是我产品路上经历过之后,总结的一些沟通方面的要点, 特别是作为项目型产品经理在沟通过程中,更加需要关注的地方,希望给大家一些启发。
 
作者 @JIN