起点不一定是缺少某项功能。有时，问题在于任何人都无法依据收到的信息作出决定。
到问题发生的地方观察
假设一家技术服务企业收到现场服务申请。这是一个虚构示例。客户向销售说明需求，运营再次索取背景资料，行政部门随后又发现缺少授权。每个人都在工作，但整个流程让大家反复回到同一个问题。若立即提出开发应用，就会遗漏一个问题：这一改变究竟能解决哪一部分困难？
可以选取一项具体申请，回顾每个人收到了什么、能够处理什么，以及在哪里必须等待。结果可能指向工具能力不足、职责不明确，或某项要求提出得太晚。它们是不同的问题，尽管从外部看，都像是协调不畅。
区分操作不便与影响工作完成的问题
并非每项令人烦恼的任务都需要技术项目。偶发例外或许通过沟通就能解决。若困难反复出现、影响多个团队，并使客户迟迟得不到答复，就值得作更全面的审视。描述后果可以帮助判断其重要性：哪项决定被搁置、谁必须返工，以及哪些信息丢失了。
在示例中，复制地址可能只是操作不便；未了解进场条件就派出技术人员，则可能导致服务无法进行。确定优先级，需要看完整个流程。如果现有记录不足以衡量情况，最好承认这一点，并开始观察。给方案填上未经验证的节省数字，并不会让项目更清晰。
先说明应改变什么，再选择工具
一个有用的表述是：安排现场服务的人，在分派任务之前，应收到客户需求、相关授权及进场条件。这说明团队需要具备什么能力，但尚未决定应该配置现有功能、连接系统，还是开发专门的解决方案。
Wiwo 的公开服务包括面向营销、销售与运营的自有软件、开发与集成，因此可以从问题本身开始讨论。如果某项职责仍无人负责，增加更多界面也无法解决尚未作出的决定。如果团队已有共识，只是数据未能送达需要它的人，技术讨论就有了更明确的目标。
判断何时值得进一步探索项目
当团队能够解释情况、指出受影响的人，并描述工作中可以观察到的改变时，就具备了向前推进的基础。同时也要承认未知事项，例如信息是否可用、现有系统的条件，或不同地点之间的差异。这些问题属于范围讨论，而不是提前堆砌功能的理由。
与 Wiwo 交流时，可以带上这份问题表述，以及能够分享的代表性情境。询问现有软件可处理哪一部分，哪些事项还需进一步界定。下一步应回应已识别的需求：可能是探索解决方案，也可能是先建立内部共识，或收集更多信息。选对问题，本身也是一项技术决策。
常见问题
怎样避免把一份困扰清单变成功能清单？
按受到影响的决策或交付结果归纳困扰，说明缺少什么结果，并与相关人员一起检查原因。之后，再根据这一结果比较技术选项，而不是针对每个表面症状购买一项功能。
与 Wiwo 交流前，是否必须先计算投资回报？
可以从有记录的具体情况及其后果开始。已有的有效记录能补充背景；如果尚无记录，应说明这一限制，并提出需要观察什么。无需编造改进百分比，也能解释问题为何重要。
