本文为B端产品经理提供了一套实用的策略，帮助他们克服业务团队反馈不足的难题，确保产品功能的持续优化和迭代。作者通过分享个人经验，阐述了获取准确详细的功能反馈数据的重要性，并提供了具体的方法和实践案例。阅读本文，你将了解到如何通过建立有效的反馈机制和利用关键指标来提升产品价值和团队协作效率，希望对你的产品管理工作带来实质性的帮助。
反馈做B端产品的伙伴，也许遇到过以下问题：
这些问题我在之前的工作中都有遇到，因为公司本身没有设立清晰的反馈流程，所以产品希望业务配合反馈工作比较困难。
在一段时间的摸索后，我总结出了几个办法，基本解决了这个困扰已久的问题。
如果公司有设立反馈机制是最好的，但如果并未建立机制，而你恰好也有这个问题的困扰，那么这篇文章会给你带来一些启发和帮助。
首先，为什么我们要定期拿取、分析数据呢？
因为它可以帮助我们达到3个目的：
1.检查功能是否达到预期目标
我们都希望自己的工作有价值，那么数据是能帮助确认功能价值的最优解之一。
且反馈数据能在撰写季度汇报、年终汇报时有更可靠的依据，获得老板的认可。简历、面试中也能拿出确定的数据展示给面试官，增加被录用的几率。
2.确认功能后续调整方向
有了反馈数据，我们在进行功能优化工作时不会像一只无头苍蝇到处乱撞。
明确的使用反馈、清晰的使用数据能让我们定位功能需要往什么方向迭代，具体迭代什么部分。
3.总结沉淀方法论
自媒体常有一种现象：好不容易写了一篇爆款，却不知道为什么爆了。这也是为什么很多网红会昙花一现的原因。
换在产品中也是一样的。如果我们不知道项目是为什么成功、为什么失败，那么工作的效率就会变得奇低，不仅会连续犯同样的错误，也无法依靠成功经验更高效取得成果。
通过反馈数据，我们能更清晰地知道项目成功或失败的原因。
这些经验教训沉淀下来，都会成为我们宝贵的“资产”。
在文章开头，我们总结了B端产品常遇到的几个拿取反馈数据难点：
一是业务配合意愿差；
二是项目成果难以用数据体现，无法展示产品价值；
那么接下来针对这两大问题，分享下我的解决办法：
业务配合意愿低：找准关键决策人+指定合理反馈机制
在开业务评审会议时，与业务负责人提出产品上线后需要业务方帮忙配合反馈的提议。
具体的反馈方式可以由双方商量着来，但重点是让业务负责人同意此事。
一旦获得承诺，那么我们就解锁了人类的「一致性」原则，后续更容易开口让业务配合反馈工作。
需要注意的是：这里必须找到的是业务负责人或核心业务人员。
俗话说：擒贼先擒王。这里用“擒”的字眼不太正规，但大体是这个意思。只要能说服最高层，后续几乎就能顺利开展工作。
例如有一次我需要销售人员配合每天反馈用户数据，期限是一个月，业务负责人同意后很快在群聊里同步了此事。之后虽然他没有参与反馈工作，但是有他开口了以后，我就能每天直接问销售拿数据，销售也非常配合。
虽然业务负责人同意协助反馈，但是如果反馈机制过于繁重，也非常容易引起其他人员的不满。
脱不花在《沟通的方法》中曾提到，想要让别人答应帮助你，需要满足以下条件：
如果我们设置的反馈机制占用业务人员太多时间，就算负责人同意了，依旧容易招致一线人员的不满；
如果我们设置的反馈机制超过了对方职责范围，例如让销售解答用户使用问题，对方即使想帮，也无从下手；
我们在设计一套反馈机制时，需要做到以下几点：
下面是我某一次项目反馈机制的具体做法：
项目背景：让某个业务团队测试使用客户推荐功能，以评估功能的有效性；
项目反馈机制：
1.反馈人员：销售人员*5
2.反馈时间：每天上午9:00
3.反馈内容：前一天通过功能成功触达客户数量
4.反馈渠道：群聊反馈
这个反馈机制之所以能顺利跑通，事后总结以下两点做的比较好：
1.为了方便销售人员，我把记录的工作放在自己身上，销售只需要每天开始工作前把数量直接丢群聊里；
2.只需要反馈数量，不需要反馈具体内容，例如客户为什么不回。也许这对于产品来说是非常有价值的数据，但是客户为什么不回这个问题太宽泛，销售自己也许都不知道；
因为数据记录本身不难，而打开群聊发送消息更是比较随手的事情，所以这次的反馈工作依靠销售人员拿到了很多有价值的数据。
很多时候，我们可能是为了规避风险、也可能是为了提升某个部门的人效，也可能就是把某个业务流程线上化完成了一些项目工作。
而这些内容，并不像营收数据一样容易被量化。
这种情况下，我们该如何通过数据观察自己的功能是否做到位了呢？
下面仍然分享几种办法，给大家做参考：
1）产品上线前，与相关负责人定义好项目指标。
在接到项目，或者准备开展某个项目的时候，就应该提前定好用什么指标来衡量我们是否达到目的。
定义指标时，我们关注2点：
1.因果逻辑关系成立：数据指标和产品功能是能直接关联的。
举个例子：降低人效的功能，数据指标就不能是提升营收。因为两者很难被直接证明因果关系。
2.无法定量的情况时，使用定性数据：有些功能例如某个业务流程线上化，确实没有定量数据来证明结果时，也可以使用用户反馈等定性数据。
大家可能会认为，定性数据拿出去很容易被质疑，但实际上只是我们展示的方式不对。
我举杨堃老师的例子，这是他朋友圈的截图，宣传自己某次企业培训的成果：
这张图上除了打分以外，还有打分问题、打分标准，使得整个过程更清晰可见，相比干巴巴的“企业员工平均打分xx分”，是不是更有说服力了呢？
所以这种思路同样也可以运用在我们衡量项目成果上，只要有合适的方式，定性数据也是可以被使用的。
2）产品上线后，对数据分析归类，总结问题
搜集到数据后，需要定期对数据进行分析归类，总结出数据背后导致的原因有哪些。
数据背后通常有4类问题：
1.系统问题：架构、设计的问题
2.机制问题：业务机制、流程问题
3.人员问题：人员素养、管理问题
4.特殊情况：特殊情况特殊讨论
针对不同的问题，需要有不同的解决方式。
对于产品经理来说，最好是团队内能够有定期周会来检查、探讨问题及解决办法。
如果团队内未有相关机制，也可以个人先动，总结问题后跟领导汇报，请教解决方案的方式去落实。
总结一下，针对拿取反馈数据的2大难点，解决方案如下：
1）产品上线前，与业务负责人沟通协定后续反馈工作
2）制定合理的反馈机制
1）产品上线前，与相关负责人定义好项目指标
2）产品上线后，对数据分析归类，总结问题反向推动优化迭代；
作者：Thea小里，公众号：小里产品手册
本文由 @Thea小里 原创发布于人人都是产品经理，未经作者许可，禁止转载。
题图来自Unsplash，基于CC0协议。
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。