发帖
雷达卡
写给产品经理实习生的一封信
各位新同学，大家好：
当我们做C端产品（如微信、抖音）时，我们研究的是人性、欲望与用户体验；而当转向B端产品时，我们的核心任务则变成了理解流程、提升效率以及合理设计利益分配机制。
在这个项目中，我面临的最大挑战并非AI算法的复杂性，而是如何在一个传统且封闭的稽查行业中，挖掘出那些支撑其运转的“隐形规则”，并将其准确地转化为可执行的系统逻辑。
以下是我在采集和理解B端客户真实诉求过程中的几点关键思考，尤其是关于“如何还原系统诞生前的原始工作模式”，希望能为你们提供一份实用的避坑指南。
一、摒弃“上帝视角”，尊重旧有规则的存在意义
许多新人常犯的错误是：认为客户当前的工作方式落后甚至愚蠢，急于用一套先进的系统去“改造”或“替代”他们。
在项目初期，我们观察到客户在布控阶段仍依赖人工蹲守路口，靠肉眼识别车牌，并手写记录信息。第一反应可能是：“这太低效了，为什么不全部换成摄像头自动抓拍？”
！！！！！！！！！！！
但请慢一步。在试图推翻任何既有流程之前，必须先弄清楚它为何存在——这就是著名的“切斯特顿围栏（Chesterton's Fence）”原则：如果你不知道一道围栏为何被建起，就不要轻易拆除它。
1. 还原“无系统时代”的行为逻辑
在没有SaaS、没有AI的时代，客户的操作规则往往源于长期积累的生存经验与现实约束。
调研过程中我们发现，一线人员有一些不成文的习惯：
- 地域偏好：某些地区的车辆会被重点盯防
- 时间规律：特定时段后基本不会出现有效线索
如果直接询问需求，客户会说：“我要高清摄像头，要24小时监控。”但如果真的照做，系统将产生海量无效数据，服务器不堪重负，反而漏掉关键目标。
我是通过以下方式深入挖掘背后逻辑的：
问痛点而非解决方案：
我问老队员：“为什么特别关注金杯车？”
答案是：私家车载货量小，利润不足以覆盖风险；大货车过于显眼，难以进入市区窄巷；唯有金杯或面包车，兼具装载能力与隐蔽性。
再追问：“为什么选择凌晨2点行动？”
回应是：此时交警已下班，路面车辆稀少，便于高速逃逸。
[此处为图片1]
最终收获：
系统的真正核心不应是“全量抓拍”，而应聚焦于“车型（面包车）+ 时间段（深夜）+ 行为特征（遮挡面部）”的智能筛选模型。
给实习生的建议：
不要轻视客户的“土办法”。那些看似原始的手工流程，往往承载着业务中最关键的风险控制点和优先级判断。你的职责不是否定它们，而是优化并固化这些智慧。
二、走进真实场景：如何获取真实的B端需求？
B端用户常常“嘴上说的”、“心里想的”和“实际做的”三者不一致。因此，仅靠访谈无法触及本质。
1. 影子追踪法（Shadowing）
不要只待在会议室听管理层汇报。我们曾跟随一线稽查队员外出执勤一次，获得了截然不同的洞察。
领导在会上说：“我们需要一个大屏，展示全市地图动态。”
但在执法车上，队员的真实反馈却是：“别搞那些花里胡哨的，我就想知道前面那个路口有没有可疑车辆经过。”
我们还注意到：白天阳光强烈时，他们会把手机屏幕调到最亮；随身携带一个小本子，记下几个熟悉的“黑名单车牌”。
这些细节直接影响了产品设计：
- 移动端App采用高对比度界面，确保户外可视性
- 开发“黑名单一键导入”功能，取代纸质记录
2. 寻找“作弊小纸条”
在任何复杂的B端岗位中，员工都会发展出自己的“捷径工具”来绕过繁琐流程——比如贴在显示器边的便利贴、微信文件传输助手中的Excel表等。
观察点建议：
- 看看他们的电脑边框贴了什么？
- 查看他们在非正式渠道传输了哪些文件？
案例：我们发现稽查员经常在微信群里发送模糊的车辆照片，互相询问：“这车是谁的？”
[此处为图片2]
产品机会浮现：
这正是“以图搜图”和“轨迹碰撞分析”功能的起点。系统应当将这类非正式协作行为正式化、结构化。
三、翻译需求：从“我要什么”到“你真正需要什么”
客户通常用“解决方案”来表达“需求”，但这往往是表象。
例如，客户提出：“我要给每个队员配一副AR眼镜，支持人脸识别。”
初级产品经理可能会立刻响应：去找算法团队，采购硬件设备。
资深PM则会追问：
- 为什么要人脸识别？→ 是为了抓捕逃犯吗？（不是，是为了抓烟贩子）
- 烟贩子经常出现在街头吗？（很少，多数藏在车内）
- 那能清晰拍到车内人脸吗？（很难，玻璃反光、车窗贴膜严重）
结论浮出水面：客户真正的诉求其实是“快速识别嫌疑对象”。
于是，在项目的最终方案中，我们弱化了昂贵且低效的动态人脸识别模块，转而强化了“车牌识别 + 手机MAC地址嗅探”组合策略。
甚至在设计一款成本控制在500元内的智能眼镜时，我们放弃了复杂的AR叠加功能，选择了最基础但可靠的“信息屏显”方案。
这一调整既解决了实际问题，又为客户节省了大量预算——而这，正是B端产品的真正价值所在。
四、总结：B端产品经理的“三重境界”
完成这个项目后，我对每一位实习生的成长路径抱有如下期待，希望你们能逐步跨越这三个阶段：
- 记录员阶段：客户说什么，你就原样记下来。
（这是不及格的表现） - 医生阶段：客户说“头疼”（表面需求），你能通过诊断发现根源是“感冒”（深层问题），并开出合适的“药方”（功能设计）。
- 规划师阶段：你不只是治好这次的病，还能为客户制定一套“健康管理计划”（即业务流程重构），帮助他们在未来更少出问题。
[此处为图片3]
最后寄语：
很多B端项目之所以成功，并非因为我们采用了最先进的技术，而是因为我们比客户自己更懂他们工作的内在逻辑。我们所做的，是用技术手段让这套逻辑运行得更快、更准、更经济。
B端项目的初始阶段，核心目标是确保产品能够无缝融入客户现有的工作流程中。首要任务是避免为客户带来额外的操作负担。如果确实存在难以规避的调整，也应以最低的学习成本为基础，提供最有效的优化方案。
在推进过程中，建议深入探究现有规则背后的成因：当初制定这些规范的原因是什么？在系统尚未上线之前，管理层在设立这些制度时考虑了哪些因素？SOP中原本关注的关键点又有哪些？理解这些问题有助于我们更准确地把握业务本质。
[此处为图片1]
希望各位在未来的工作实践中，能够更多地走进一线场景，面对面交流，反复追问“为什么”。对已有的规则保持尊重与审慎，同时对尚未明晰的逻辑保持探索的热情与好奇心。
新一代的产品人，继续前行，未来可期！
京公网安备 11010802022788号
