题干与适用场景
一家 B2B SaaS 公司有 1,200 家客户和 85,000 名周活跃用户。客户成功、支持运营和客户经理都说需要“一个内部工具来提高效率”，但没有给出统一问题。你有 2 周做发现、1 个工程小队做 6 周实现，工具应优先复用现有 CRM 与工单系统，不能新增编制或重建平台。
请说明你会问什么、如何识别真正的工作流问题、先服务哪类用户、如何定义 MVP 与成功指标，以及何时继续投入、调整方向或停止。
面试官考察点
- 能否把模糊请求拆成用户、任务、频率、痛点和业务结果。
- 能否用证据验证问题，而不是直接接受“做一个工具”的方案。
- 能否在 2 周发现和 6 周工程约束下切出可交付的 MVP。
- 能否处理不同团队目标冲突与既有系统集成边界。
- 能否用分层指标和停止规则验证价值，而不是只报告上线或满意度。
回答前需要澄清的问题
- “效率”具体指什么：处理时长、重复录入、错误率、响应等待，还是跨系统切换？
- 哪个角色最常遇到这个问题，发生频率和后果分别是什么？
- 当前流程怎样完成，哪些步骤在 CRM、工单系统或表格之间往返？
- 这个问题影响收入、客户留存、合规，还是只影响员工便利性？
- 2 周内能接触多少用户和真实操作记录，哪些数据允许查看？
- 6 周后必须交付可用流程，还是允许先交互原型和人工服务？
30 秒回答框架
我会先把“效率”改写成可观察的工作任务，再按角色、频率和影响排序。两周发现阶段结合访谈、流程观察、工单与 CRM 数据，验证谁在什么情境下损失了什么。MVP 只解决一个高频且可量化的工作流，优先复用现有系统接口，保留人工兜底。指标同时看任务完成时长、重复录入次数、错误率、采用率和用户结果，并预先设定继续投入、调整或停止规则。
分步骤深入解答
第一步：把请求改写成问题假设
把“需要一个内部工具”改写为“某角色在某任务中因某个摩擦导致某个结果变差”。例如，客户经理可能在 CRM 和工单系统之间重复复制信息；支持运营可能更关心分派延迟。先写出多个假设，不把实现形式当成问题本身。
第二步：按证据梯度安排发现
先观察真实流程和最近案例，再用半结构化访谈解释原因，最后用日志、工单和 CRM 数据估算规模。访谈中的偏好是线索，不是需求证明。每个假设都记录支持证据、反例、未决问题和下一步验证。
第三步：选择目标用户和优先级
用频率、影响、可触达性和解决可行性排序。高频、影响明确且能在现有系统边界内改善的工作流优先；低频但高风险的流程需要单独的安全或合规评估，不能因为用户数量少就自动忽略。
第四步：切出六周 MVP
MVP 只覆盖一个端到端任务，例如从工单读取客户上下文、生成结构化处理草稿，再由员工确认后写回 CRM。先不做新的权限中心、全量报表或跨团队平台。接口失败时保留原流程，让员工能查看、编辑和撤销结果。
第五步：处理团队分歧与集成约束
让各团队用同一张流程图和指标树讨论，而不是比较谁的功能清单更长。确认 CRM、工单系统的权限、写入规则、速率限制和数据保留边界；无法在六周内安全接入的部分改为导出、人工确认或延后。
第六步：定义指标与停止规则
领先指标包括目标流程采用率、完成时长和重复录入次数；结果指标包括错误率、客户响应时间和返工量；护栏指标包括权限错误、数据泄露事件、员工投诉和系统失败率。若采用率上升但错误率或返工量超过阈值，就暂停扩展并回到问题验证。
第七步：安排验证和发布
先用原型和人工模拟验证流程，再在一个团队、一个任务类型上灰度。设置基线、对照组或前后对比，按角色和任务切片观察结果。每周复盘证据，决定扩大范围、改动假设、继续人工服务或停止项目。
高质量示范回答
我不会直接接受“做一个工具”。我会把效率拆成具体任务，先找出哪个角色在什么流程中重复录入、等待或出错，再用两周观察、访谈和 CRM、工单数据验证规模。按照频率、影响、可触达性和六周内的可行性排序，选择一个高频且结果可量化的工作流。MVP 只完成从现有系统读取上下文、生成可编辑草稿、员工确认后写回的闭环，权限和写入失败时保留原流程。指标包括采用率、完成时长、重复录入、错误率、返工量和客户响应时间，并监控权限错误、数据泄露和系统失败率。先在单一团队灰度，预先约定扩大、调整或停止阈值；如果效率改善伴随错误或返工上升，就暂停扩量并重新验证问题。
常见错误
- 把“内部工具”当作需求，直接画页面或列功能。
- 只采访管理者，不观察一线员工的真实流程。
- 用一次满意度调查替代行为数据和结果指标。
- 同时服务三个团队，导致六周内没有完整闭环。
- 忽略 CRM、工单系统的权限、写入和保留限制。
- 只看采用率，不设置错误、返工和隐私护栏。
- 没有停止规则，把项目投入当成继续投入的理由。
追问及应对
如果三个团队都说自己的问题最重要，你怎么选？
要求每个团队用同一套频率、影响、证据和可行性标准提供案例。优先级由可验证的结果和六周内完成闭环的能力决定；其余问题记录为后续假设，而不是用政治影响替代排序。
如果业务方坚持一次性交付全平台，怎么办？
把全平台拆成共享约束与首个工作流。先交付一个可撤销、可观测的纵向切片，用真实指标证明价值，再决定哪些接口和权限值得平台化。无法在六周内安全验证的范围不进入本轮承诺。
如果 MVP 采用率很低，但访谈都说喜欢，如何排查？
回看实际任务路径、触发时机、写入权限和失败日志，比较“知道工具存在”与“在工作中使用”的差异。观察是否增加确认成本或破坏原流程；修正阻力后再做小范围实验，而不是用更多宣传掩盖行为缺口。
如果效率提升但错误率也上升，你会继续吗？
先按角色、任务和错误严重度切片，暂停高风险场景扩量。若错误超过预设护栏，回到人工确认、缩小范围或调整流程；只有在错误可接受且结果指标持续改善时，才继续投入。