做 B 端产品，最怕的就是被错综复杂的业务逻辑绕进去，如果团队对真实场景没感知，很容易闭门造车。最近我们团队做用户访谈栽了个跟头，痛定思痛复盘了整个过程，才发现：在各类需求调研手段里，用户访谈其实是弄懂业务最快的方法。面对面聊，能直接抓到对产品决策最有价值的信息，也能在最短的时间里跟对方建立信任。

拿我们做过的一款安检项目管理产品来说。一开始大家纯靠脑补，行业报告倒是看了不少，监管类型和处罚条例也摸清了，但真到了系统该怎么用的时候——角色怎么交接、项目怎么流转、用户具体点哪个按钮——就全卡壳了。后来我们硬着头皮去做了深度访谈，这才把角色和流程的缺口补上。更惊喜的是，聊出了两个特别关键的业务细节：一个是安检员查一个包裹时，经常得连续录好几条违禁品，所以我们赶紧加了个“快速新增”的功能，省得他们来回点；另一个是，管理层真正看重的不是流程走没走完，而是检出率和处理率，于是我们又顺势加了个监控看板，帮他们盯紧核心数据。

其实，用户访谈并不是一成不变的。按严格程度来分，它大概有三种样子。最死板的是标准化访谈，像流水线一样，问题顺序都定死，好处是数据好对比，适合街头快问快答，但挖不深；最自由的是非标准化访谈，只给个大方向，随便聊，能挖出不少深层的情绪和背景，但很容易聊飞；夹在中间的半标准化访谈，是我们最常用的。手里有大纲，但聊的时候可以根据对方的回答随时拐弯，抓取那些没预料到的灵感。做安检产品时，受访者懂业务但不懂系统，半标准化就特别好用，既防着新手访谈员跑题，又让业务专家有足够的空间把细节讲透。



那半标准化访谈到底什么时候最管用呢？主要是三种情况。一是议题特别复杂的时候。想搞清楚用户为什么这么做、心里怎么想的，死板的选项根本没用，得靠弹性对话一层层往下挖，才能摸清背后的原因。二是用户行为很复杂的时候。B端用户往往是老手，他们的动作经常受好几个因素影响，这时候千万别居高临下地去“审问”，而是要把他们当共创信息的合伙人，不迎合也不反驳，客观引导，让干货自己冒出来。三是聊到敏感或隐私的时候。比如生活状态、心里的小九九，只有在一对一的半标准化环境里，对方卸下防备，你才有可能听到那些平时不好意思说出口的真实想法。

知道什么时候用还不够，还得会聊。做 B 端，愿意配合访谈的人本来就少，人家还怕泄露隐私或机密，随便聊聊很容易变成走过场。要破这个局，第一步得先把信任建起来。问正事前，得老老实实交代清楚你想干嘛，让人家觉得被尊重了。上来就瞎打听业务底细，人家只会防着你。第二步，得用业务共鸣来打开话匣子。一开始就算有大纲，对方可能也不爱说话，或者一肚子苦水想倒。这时候别硬拉，先抛个接地气的问题，比如“平时干活最烦哪一步”，让他们在痛点上吐槽一会，等情绪发泄完、觉得你懂他了，再顺理成章地切回主线。第三步，得把一问一答变成真正的深聊。信任有了，就得顺着他们的思路把典型场景还原出来，而且一定要死磕那些不常见的特殊情况。B 端系统能不能用，往往就看对这些边缘情况兜底兜得好不好，遇到老手，必须把他们处理意外时的真实动作抠清楚，绝不能让含糊的说法给后面的设计留坑。

访谈快结束的时候也有讲究。临走前，最好把聊到的业务逻辑像讲故事一样给对方顺一遍，这不光是礼貌，更是为了二次核对，万一你们理解岔了或者漏了啥，这时候还能及时补救。道谢时，得跟人家说清楚这些信息会怎么用在产品上，让这事有个交代。访谈结束，才是整理结果的冲刺时刻。尽量在六个小时内把结论写出来，趁记忆还热乎；要是实在来不及，也得先快速过一遍录音找找感觉，再去抠疑点。如果条件允许，拿着初稿去找没参加过访谈的其他业务同事对一下，经常能补上盲区，让整个流程图真正闭环。

做 B 端产品，用户访谈是绕不开的，但它绝不是拿着大纲走过场，而是特别考验实操和同理心的事。只有在实操中不断复盘、随时调整，每一次跟用户的对话，才能真正帮产品往前走一步。