先理解运营问题，而不是先列功能
数字化项目通常始于一个明确信号：工作重复、系统之间无法共享信息、客户反复询问状态，或现有平台无法支撑下一阶段增长。
在选择技术前，记录当前流程、受影响人员与摩擦成本，避免做出外观完善但没有解决根本问题的系统。
- 什么触发流程
- 每个阶段由谁处理
- 信息在哪里被复制或丢失
- 日常工作中应出现什么可见改善
把用户角色与决策对应起来
管理层、运营人员、客户和合作伙伴使用同一系统的目的可能完全不同，权限与信息需求不能混为一谈。
列出每个角色的关键任务和必须作出的决策，从而区分核心能力与次要偏好。
- 角色与使用频率
- 行动所需信息
- 授权操作
- 代价最高的错误
定义可观察的结果
“推动数字化”这类宽泛目标无法指导产品决策。有效结果应明确哪些工作需要更快、更安全、更简单或更可靠。
结果也可以是内部运营改善，例如减少重复录入、让客户直接查看状态，或缩短完成业务所需步骤。
实用表达：目前，[人员]必须完成[困难流程]。项目应在满足[关键约束]的同时实现[结果]。
设计完整而聚焦的首期版本
首期版本不应是最终愿景的简陋复制，而应为优先用户群完成一条有意义的业务路径。
选择需要验证的用户、流程和结果，其余能力可进入后续路线图。
- 主路径必需能力
- 重要但可延后事项
- 验证后再探索
- 明确不在本期范围
尽早暴露关键约束
安全、隐私、无障碍、语言、集成和时间要求都会影响架构，晚发现往往带来不必要的返工。
梳理现有系统、敏感数据、真实时间节点、内部审批和能够确认决策的人。
- 需要连接的系统
- 个人或机密数据
- 语言与地区
- 设备和使用环境
- 决策负责人
为第一次沟通准备有效材料
无需先完成正式规格书。一页纸说明背景、问题、用户、约束和目标，就足以开始。
专业合作方应把这些信息转化为问题、备选方案、风险和具体下一步，而不是立即强推某种技术栈。
- 当前流程
- 两三个真实案例
- 正在使用的工具
- 需要参与的人员
- 初步预算与时间范围
把想法转化为可执行决策
项目界定不是开发前的文书工作，而是组织决定需要验证、保护和改善什么的过程。
当问题、用户与首期版本清晰后，估算、原型或更深入的发现阶段都会更可靠。