需求调研时，业务说要A，上线后，业务却说要B？高薪|生产|智能汽车|王程龙|海

编辑导读：作为一个产品经理，每天要接触到大大小小不同的需求。只有对这些需求进行分析，才能更好地了解问题，从而制定相应的解决方案。具体怎么做？本文作者基于自身经验，对此展开分析，希望对你有帮助。

文章插图
某日，渔歌群里几位产品经理的对话，大概意思：
业务和产品沟通需求的时候，业务板上钉钉的要求做数据可视化，还说不做的话要上升到老板那。产品乖乖配合业务做了，但是那些可视化功能上线后竟然没有访问量。当时提需求的业务都直奔下载。紧接着，产品经理被开发怼，你这需求怎么弄的？浪费我的资源。产品经理表示怀疑人生。
此时，渔歌群里好几位产品经理表示，他们也有类似遭遇，业务提需求的时候，旗帜鲜明的要可视化，说要看趋势、看变化，但上线后，滚犊子的全去下载了，下载的点击量永远排名第一。产品经理们又难受、又委屈，心里窝火，太难了。
产品经理们你一言、我一语的讨论，业务为什么那么爱下载数据？为什么对可视化报表视而不见？当事的产品经理说很懵逼，搞不懂业务这路数。群里有产品经理说，那是因为一开始就没搞清楚业务的需求，被业务晃点了。
群里也有小伙伴反问，产品经理为什么要搞清楚业务的需求？搞清楚了又怎样？又不会帮业务做，需求都做了的话，产品就极其臃肿，还是产品吗?所以没必要搞清楚业务需求。
渔歌回应上面的问题：
上产品前后需求为什么发生变化？为什么业务总喜欢下载？这对产品经理来说是专业域的讨论。
而为什么要搞清楚需求？用户需求是否产品化？即是专业问题，也是态度问题。
01 数据下载的必要性下载是数据产品中很常见的功能，很多用户强依赖下载，尤其2B客户，而服务业务的对内数据产品，本质上也是2B产品。
【需求调研时，业务说要A，上线后，业务却说要B？】数据产品的确应该通过可视化、诊断、解决方案将客户需要的最终结果呈现给用户，而不是让用户自行下载、分析。
但现实是，纯粹通过报表和数据产品很难完成中高阶的数据分析，甚至连初阶的数据分析都难以支持。
需要下载的原因：

2B的业务场景复杂，需要在不断分析中尝试、求证，来完成分析。不管是对内，还是对外的数据产品，想通过一步到位的可视化来满足数据分析、商业分析，难度很大，也需要大量时间、精力；
业务发展或者变化太快，新的节点不断长出来，老的节点随时消失。随着业务变化，可视化报表的有用性、易用性将大打折扣。
数据产品经理对业务理解不够，或者缺少分析思维。有时候1个数据产品经理要对接十几条业务线，要让产品经理理解每个业务，确实不现实；

所以对很多数据产品来说，无论从必要性和可行性上来说，下载都是刚需，即使数据可视化做的很好，也还是会存在下载的需求。所以不要怀疑人生，产品经理内心都很强大，不要因为这点事难受，也不值得我们难受。
通过数据可视化、诊断、解决方案去逐步解决用户问题，这的确是数据产品经理需要持之以恒去解决的，但不影响有些业务场景和有些阶段，提供下载的功能。
02 用户下载数据的动机渔歌不再赘述这个问题，在“到底什么是需求？动机才是需求”一文中，已经有阐述，只是每个业务场景下，用户下载数据的诉求会有差异，这是产品经理在产品化之前应该前置想清楚的，不然就真的被业务晃点，再被技术追着屁股打。

文章插图
如果想要解决业务强依赖下载的问题，需要先和业务沟通清楚，他们下载后到底是用来干嘛的。
事前和业务一起梳理清楚，远比事后算账重要，也比事后再让业务拿excel演示重要。事前调研不要停留在嘴喷的状态，需要拿出真章法，刨根问底，看业务平时都做哪些临时取数，给老板汇报什么数据，汇报的PPT都是什么样的。
如果只是嘴喷需求，一定不牢靠。搞清楚问题，也就是定义需求，是产品经理的最重要的工作之一。把业务日常的报表、PPT都搜集过来，认真研究，杜绝蜻蜓点水式的需求调研。
03 为什么要知道客户的动机，挖掘出真实需求？渔歌群里有位产品经理提到，反正用户的很多需求在产品上都实现不了，要么资源不够，要么产品极其臃肿，那花九牛二虎之力把客户需求搞清楚，又是为什么？什么时候该搞清楚用户需求？