如何发现真实问题，而不是接收表面需求

多数失败项目，不是因为团队不会做，而是一开始就做错了题。表面需求通常只是某个人提出的解决方案，而不是真正的问题本身。

AI 时代尤其如此。因为现在太容易说出这些话：

• “我们做个 chatbot 吧”
• “我们加个智能推荐吧”
• “我们接个 agent 吧”

真正成熟的产品经理，不会直接接单，而是先回到问题本身。

表面需求与真实问题的区别

PM 的价值，不是把 A 写成需求单，而是把 A 还原成一个能被验证的问题定义。

问题发现的五个关键追问

一个问题陈述模板

好的问题陈述至少要包含四个元素：

1. 谁遇到问题
2. 在什么场景下发生
3. 当前损失是什么
4. 为什么现有方法不够

例如：

“客服团队在处理重复性订单问题时，需要跨三个系统查找信息，导致首响时间长、培训成本高、用户等待体验差。现有 FAQ 与话术库分散，无法支持快速检索与一致回答。”

这就比“我们需要一个 AI 客服机器人”成熟得多。

用一个简单方法给问题打分

def problem_score(frequency: int, pain: int, business_impact: int, urgency: int) -> int:
"""给问题做一个粗略优先级评分。"""
return frequency * 2 + pain * 3 + business_impact * 3 + urgency * 2
candidate_problems = {
"重复回答退货政策": problem_score(5, 4, 4, 4),
"智能推荐商品": problem_score(3, 3, 5, 2),
"自动生成营销文案": problem_score(4, 2, 3, 2),
}
for name, score in candidate_problems.items():
print(name, score)

这类评分法不是为了“绝对正确”，而是为了让团队停止凭感觉争论，转而用一致标准比较问题。

发现问题时最容易犯的错

案例演练：企业网站线索转化

表面需求：给官网加一个 AI 对话框。
继续追问后，可能发现真正的问题是：

• 海外访客找不到合适产品信息
• 询盘表单转化率低
• 销售收到的线索质量参差不齐
• 网站内容更新慢，FAQ 不一致

这时解法就不一定是“先上聊天机器人”，也可能是：

• 先重做信息架构
• 先整理 FAQ 和产品知识库
• 先优化表单与线索分类
• 再考虑在高意图页面放 AI 咨询入口

课堂案例：把“官网加 AI 对话框”重写成问题发现练习

案例背景

销售团队抱怨官网线索质量不高，于是市场团队提议“加一个 AI 对话框提升转化”。

教学拆解

PM 应该带团队依次确认：

1. 线索质量差，到底是“量少”还是“质量差”
2. 用户进入官网后最常在哪些页面流失
3. 现有 FAQ、案例、产品页是否本来就很难理解
4. 表单设计、字段与提交门槛是否本来就有问题

课堂结论

如果官网信息结构本来就差，那么第一优先级可能是重构内容与表单，而不是直接加 AI。

练习题

1. “做个 chatbot”为什么通常只是表面需求
2. 问题发现阶段为什么一定要看现有替代方案
3. 什么时候你会判断“先别做 AI”

标准答案提示

• 需求提案常常是一种解法，不是问题定义
• 如果不知道用户现在怎么解决，就无法比较新方案价值
• 当数据太差、流程太乱、规则已足够、风险过高时，都要谨慎

从问题发现走向下一步

发现问题之后，下一步不是立刻写 PRD，而是先把目标定义清楚：我们到底想改善什么结果，目标值是多少，哪些事情明确不做。

本章 checklist

• 我是否把表面需求还原成了一个问题陈述
• 我是否确认了用户、场景、频率、损失和替代方案
• 我是否避免过早把 AI 当成默认答案
• 我是否能用一段清楚的话向团队解释“为什么这个问题值得做”
• 我是否识别出当前问题背后其实可能是流程问题或内容问题

本章小结

• 表面需求通常只是某种解法提议，不是真正的问题定义
• 发现真实问题，要追问用户、场景、频率、损失与替代方案
• 问题定义越清楚，后续 AI 适用性判断和 MVP 切分才越稳

下一节：02-用户访谈与问题挖掘方法论 — 结构化用户访谈流程，把"我想要 X"还原成真正的问题与场景。