从真实工作中找到值得做的产品问题

有人提出做一个 AI 资料整理工具，访谈对象说“听起来不错”。这条反馈尚不能证明问题频繁、解决方案适用或愿意付费。产品发现要从最近发生的工作与已有选择取得证据，再决定值得验证哪一个方案。

本例围绕学习资料整理：用户可能在课程开始前寻找文档、整理来源并确认版本。所有访谈记录、候选问题与评分都是教学设定，没有真实用户经历或收入结论。

先区分参与者与工作情境

使用者、付费者、批准者与受影响者可能不是同一个人。学生可能整理资料，教师决定课程材料，机构决定采购。只访谈使用者，就可能遗漏预算、权限与组织约束；只听采购者，也可能误判日常操作困难。

把场景写成发生时间、触发事件、现有流程、目标与限制。例如“准备明天的讨论课时，需要确认三份材料哪一版有效”，比“需要更智能的知识管理”更容易调查。记录目标进展与失败代价，而不急着决定必须使用 AI。

JTBD 关注人在具体情境中想取得的进展，包括功能、社会与情绪维度。它帮助解释选择，却不是一种可以自动预测购买的公式。目标可能通过文件夹、清单、同事帮助或放弃任务实现，竞争方案要包括这些实际选择。

问最近发生的事情

让受访者讲最后一次遇到问题的过程：何时开始、先做什么、在哪里卡住、用了什么办法、结果如何。尽量围绕可回忆的动作，不要求披露无关个人故事或私密材料。必要记录与引用应先获得适当同意。

“你会不会用我的工具”容易获得假设答案。“上次怎样确认文档版本”可以取得具体线索。继续核查频率、耗时、错误和已有投入，但不要诱导对方接受预设解释。对方说“很麻烦”时，追问是哪一步与造成什么结果。

听到解决方案建议时也要回到原因。用户提出自动摘要，可能真正想解决的是不知道先读哪份；用户要求更多分类，可能源于文件命名混乱。建议值得保存，问题与方案应分别记录，避免访谈一开始就围绕功能列表。

证据强度与样本范围一起看

对方展示近期工作过程、已有替代方案与实际投入，比泛泛赞美更能说明问题。但某个个体的困难仍不能代表整个市场。记录如何找到受访者、他们是否属于目标情境，以及哪些人拒绝或没有这个问题。

主动联系已经热衷 AI 的人，可能高估对 AI 方案的兴趣。只访谈朋友，也可能受礼貌影响。应寻找不同工作方式与限制的样本，并保留反例。不能因为三个人表达喜欢就推算市场规模或收入。

访谈资料按主题整理时保留出处范围与不确定性，避免把推测改成事实。区分“每次都耗时”和“最近一次比较复杂”。记录敏感故事不是证明专业的必要条件，汇总时尽量去掉身份线索与无关细节。

在问题与方案之间反复收敛

Design Council 的 Double Diamond 描述发现、定义、发展和交付中的发散与收敛。它适合提醒团队先探索问题，再比较方案，并通过小规模测试改进。真实项目可以返回前一步，不必把它执行成不可逆的瀑布阶段。

例如访谈最初指向摘要，观察却发现用户不知道资料是否过时。问题定义可以改为“快速确认材料版本”，候选方案包括版本标记、来源清单与自动检测。每个方案解决的条件与代价不同，要按证据比较。

先明确最危险假设：用户是否真的需要版本确认，是否愿意上传资料，是否能接受人工核对，是否需要跨设备。一个漂亮界面只能测试部分体验，不能同时证明所有需求与收费假设。

排序帮助安排研究，不能证明需求

下面按频率、成本与证据三个教学分值的乘积排列候选。选择这些维度与数值是人为规则，适合展示排序怎样运行，不是经过验证的市场模型。

candidates = [{"id": "A", "frequency": 3, "cost": 2, "evidence": 2},
              {"id": "B", "frequency": 2, "cost": 3, "evidence": 1}]
def score(item):
    return item["frequency"]*item["cost"]*item["evidence"]
ranked = sorted(candidates, key=score, reverse=True)
assert ranked[0]["id"] == "A"
assert score(candidates[0]) == 12
print([(x["id"], score(x)) for x in ranked])

实际输出是 [('A', 12), ('B', 6)]。A 得分十二，B 得分六，所以 A 排在前面。分值不对应收入、用户数量或成功概率；频率与成本若只是主观猜测，乘法不会让它们变成可靠证据。

真实比较还要考虑能否接触用户、解决成本、替代方案与购买限制。把每个分值的依据写出来，并检查改变权重后排序是否翻转。若一个小假设改变就让候选换位，应优先补信息，而非把分数当确定结论。

原型实验需要能被否定

为版本确认设计一个小原型：给出几份合成资料，让参与者找出适用版本并说明依据。先规定成功条件与主要失败类型，例如选错版本、无法找到来源或不能理解状态。记录完成过程，而不只问喜不喜欢。

原型可以暂时由人工提供部分结果，但应说明能力范围，不让用户误以为已有完整自动化。实验中的人工投入与未来系统成本要分别记录。原型验证任务可用性，支付意愿与持续使用仍需要其他证据。

如果参与者不用原型也能很快完成，或者真正障碍是资料权限，就应调整问题或停止方案。负面结果节省后续投入，不能通过改变验收口径把失败重新包装成成功。继续实验前明确新假设。

商业限制在开发前验证

个人工具可能由使用者付费，组织产品可能需要审批、数据安全与采购流程。列出付款人、预算来源、试用条件与现有采购习惯，不虚构“企业一定愿意支付”的结论。行业与消费场景只是机会假设。

价格测试要避免把假设回答当承诺。更具体的证据可能是愿意安排试用、投入数据整理或进入评估流程，但每种承诺仍有范围。涉及真实收费时，需另外核对交易、退款与适用经营条件；本课不执行支付。

访谈记录要区分原话、观察与研究者推断。原话支持的范围可能很窄，不能将“昨天花了半小时”直接写成“每周浪费很多时间”。保存必要的情境信息，并把待验证推断单独标注。后来综合多个访谈时，仍应能回到具体证据，检查结论是否超过样本范围。

练习：形成一份可反驳的发现记录

选一个资料整理问题，写访谈提纲，包含最近一次情境、现有替代、频率、结果和限制。整理支持与反对证据，区分使用者与付款者。提出两个不同方案，再为其中最危险的假设设计小实验。

验收时，记录可追溯到具体情境，赞美没有被当成需求，评分有依据与不确定性，实验有明确失败条件。输出下一步决定：补访谈、测原型、改问题或停止，并说明是哪条证据支持这个动作，而不是用“市场很大”结束分析。