B端产品的一个特点是:需求会一直变化。相信每一位程序员都遇到过不断修改的需求,除了抱怨客户之外还有更好的办法吗?
我们要把握一个核心:帮客户解决问题
需求变更的成本是巨大的,虽然不能做到100%的需求解读率,但却可以不断优化。
- 对于客户的需求整理成功能点进行确认,有条件的可以现场模拟一遍。有歧义的地方要通过人人能懂的方式确认。
- 解读懂言外之意,有些需求客户不愿意表达出来或者说没有直接表达出来能力
- 必要时候抢回需求的主动权对客户进行引导:功能满足需求但不满足客户理想状况时,需进行详细的产品说明告诉其我们的这样设计的优势,没理由让落后的方案替代好的方案
- 不要直接说不,比如客户提了一个需求不适合植入到我们的产品或我们产品中有更适合的功能替代时,不能直接说不否则接下来的沟通基本不会成功。
- 抓住比较在意的点,可以是业务相关的也可以是业务不想关的。过去有两个项目发现了甲方负责人比较在意的点,后续沟通就往这个点上靠让我的沟通变的非常Easy
- 在对领域有一定的认知后,就可以结合其他领域的一些知识对产品的走向进行预测,将可能出现的问题提前解决,避免出了问题后用户觉得你的整个方案都不行。
一些误区
误区一:用录音来证明客户当时是这样说的,(证明客户错了不是我们的目的,只有没能解决问题才会出现这样的沟通场景)
误区二:客户甲乙的需求互斥了,让对方去解决。你猜猜对方会去解决吗?这种情况是一般是需求关键点采集有误在多调研下,或者可以对其中一方进行引导,如果是特殊情况下就区分谁的权重较高。
本文来自博客园,作者:尾牙衣子,转载请注明原文链接:https://www.cnblogs.com/sunpan/p/17237222.html