第二篇 —— 项目启动阶段怎么做：PM、UI、UX 如何共同理解业务、用户与机会
一个项目成不成，很多时候在“开始做”之前，其实就已经埋下了结果。
现实工作中，很多项目之所以后面越做越乱，并不是因为中途谁执行得不够认真，而是因为项目在启动阶段就没有把最关键的几件事想清楚：
- 这个项目到底要解决什么问题？
- 这个问题是谁的问题？
- 为什么现在必须解决？
- 解决之后，希望带来什么业务结果？
- 这个问题是真问题，还是表面问题？
- 这是一个功能问题、体验问题、表达问题，还是商业问题？
- PM、UI、UX 三个岗位，在这个阶段分别应该做什么？
很多团队一进入项目，就急着做三件事：
- 开始列需求
- 开始画页面
- 开始讨论功能
但真正成熟的团队，在项目启动阶段更重视的是另一件事：
先建立对“业务—用户—机会”三者关系的共同理解。
因为如果这一步没有做好，后面的 PRD、原型、设计稿、开发排期，都会建立在不稳固的基础上。
项目也很容易陷入一种典型状态：
- 做得很忙
- 讨论很多
- 页面很多
- 文档很多
- 但所有人理解的其实不是同一个问题
所以，项目启动阶段最重要的，不是“立刻产出方案”，而是先完成一次高质量的判断：
这个项目为什么值得做，以及应该从什么角度开始做。
而这一步，从来不是 PM 一个人的事，也不是 UI 和 UX 后置参与的事。
相反，越是好的项目，越会在启动阶段就让三者进入同一个问题空间。
一、为什么项目启动阶段最容易被低估
很多人会觉得，项目启动阶段不就是“开个启动会、对个目标、然后开始干”吗？
实际上，项目启动阶段是整个项目中最具战略价值、也最容易出错的阶段之一。
因为它决定了后续所有动作的起点。
如果启动阶段判断偏了，后面就会出现三类非常典型的问题。
1. 误把表面诉求当成真实问题
这是最常见的一类错误。
比如业务方说：
- “我们想新增一个会员弹窗，提高转化。”
- “我们要做一个提醒功能，减少客户流失。”
- “我们想优化首页，感觉现在太普通了。”
- “我们需要做一个新版本，让用户更有高级感。”
这些都是很常见的“需求表达”，但它们通常都只是表层方案，并不等于真实问题本身。
举个 ToC 例子。
某工具类 App 的业务团队提出：
“希望增加一个‘限时优惠弹窗’，提升会员购买率。”
如果团队直接进入执行，PM 可能会开始写需求，UX 可能开始画弹窗流程，UI 可能开始设计促销界面。
但如果稍微往前追问一步，可能会发现：
- 用户不是没看到优惠，而是没理解会员价值
- 当前主要流失发生在“试用结束”而不是“进入会员页”
- 不同用户群对价格敏感度完全不同
- 真正的问题不是“缺弹窗”，而是“价值感知不足 + 决策链路断点”
也就是说，业务方提出的是一个想做的动作，而项目真正需要解决的是一个转化问题。
如果不先区分这两者，项目一开始就会偏。
2. 误把内部视角当成用户视角
项目启动时，团队很容易从自己的角度看问题。
比如：
- 业务方从目标和 KPI 出发
- PM 从需求池和版本节奏出发
- UI 从界面表现和风格升级出发
- UX 从流程可用性出发
- 研发从实现成本和架构限制出发
这些都合理，但如果没有一个共同过程去对齐，很容易出现一种现象：
每个人说的都对，但说的不是一件事。
例如一个 ToB 项目，管理层提出：
“我们要提升销售跟进效率，所以增加一个‘客户意向标签系统’。”
PM 可能理解为：
- 给客户增加标签字段
- 支持筛选和分类
- 提升线索管理效率
UX 可能理解为：
- 销售在什么场景下打标签
- 标签如何帮助后续动作
- 标记流程是否顺手
UI 可能理解为：
- 标签显示方式
- 列表和详情页的信息层级
- 状态颜色和视觉区分
如果没有进一步讨论“真正的效率问题到底在哪里”，大家会很快投入各自熟悉的解法。
但最终上线后，销售可能还是觉得不好用。为什么？
因为真正的问题可能不是“少标签”，而是：
- 客户状态定义不统一
- 跟进动作和标签没有形成闭环
- 标签过多，反而增加决策负担
- 销售人员不知道何时必须打标签
- 管理层想看的是阶段推进，不只是静态分类
所以，项目启动阶段最重要的，不是“谁先动”，而是先把问题放到业务视角 + 用户视角 + 使用场景里重新看一遍。
3. 误把“立刻产出”当成“高效推进”
很多团队对“效率”的理解是：
- 赶紧定方向
- 赶紧拆需求
- 赶紧出原型
- 赶紧评审
- 赶紧开发
但项目启动阶段真正的效率，不是马上开始做，而是：
尽早减少错误判断、错误方向和错误投入。
启动阶段花 2 天把问题想清楚，通常比后面花 2 周返工更高效。
尤其在下面这些项目里，启动阶段的判断质量几乎决定项目成败：
- 复杂 ToB 流程产品
- 影响核心转化的 ToC 改版
- 多角色协作系统
- 0 到 1 新功能探索
- 存在多部门诉求冲突的项目
- 涉及技术约束较强的项目
所以，从项目管理角度看，启动阶段不是“预热”，而是决定后续投入是否值得的判断阶段。
二、项目启动阶段到底要解决什么问题
一个成熟项目在启动阶段，至少要回答六个问题。
这六个问题，也是 PM / UI / UX 三方必须对齐的基础。
1. 我们到底在解决什么问题
注意，这里不是问“我们要做什么功能”，而是问：
- 当前项目想解决的核心矛盾是什么？
- 这是业务问题、用户问题，还是组织效率问题？
- 这个问题是否足够重要，值得一个项目投入？
比如：
ToC 例子
“会员购买率低”不是问题定义，
更好的定义方式可能是：
- 新用户进入会员页后，无法快速理解付费权益，导致付费转化低
- 试用用户在试用结束节点缺少价值回顾和决策引导，导致正式订阅率低
ToB 例子
“审批太慢”不是问题定义，
更好的定义方式可能是：
- 当前审批流程中关键信息展示不完整，导致审批人频繁跳转查看详情，降低处理效率
- 审批节点责任边界不清，导致流程停滞和重复沟通
问题定义越具体，后面方案越容易收敛。
2. 这个问题是谁的问题
很多项目会默认“用户都一样”，但真正有效的启动阶段，一定会追问：
- 谁是主要用户？
- 谁是实际使用者？
- 谁是决策者？
- 谁是付费者？
- 谁受到的影响最大？
尤其在 ToB 项目中，必须区分：
- 使用者
- 管理者
- 采购者
- 决策者
- 维护者
举个例子，某企业知识库系统启动一个“智能搜索优化”项目。
如果不区分角色，团队可能以为“用户搜索不到内容”就是统一问题。
但进一步看，会发现：
- 一线员工：想快速找到答案，提高处理效率
- 主管：想统一团队知识口径
- 管理员：想降低知识维护成本
- 企业采购方：关注培训效率和知识沉淀价值
不同角色，问题重点不一样。
项目如果只按“一个用户”来理解，很容易失焦。
3. 为什么现在要做
项目不是“永远可以做”，而是总要在某个时间点启动。
所以启动阶段必须回答：
- 为什么是现在
- 这件事和当前业务目标的关系是什么
- 不做的成本是什么
- 现在做的机会窗口在哪里
这个判断非常重要，因为它决定项目优先级是否成立。
例如：
ToC
- 某功能与新用户增长节点高度相关
- 某订阅策略改版恰逢大促节点
- 某体验优化关系到核心转化漏斗
ToB
- 大客户上线前必须补齐某能力
- 当前投诉集中暴露某流程问题
- 公司战略转向，需要补充平台能力
如果没有“为什么现在”的说明，很多项目看上去都“值得做”，但实际上不一定适合此刻投入。
4. 这个问题到底值不值得做
这一步其实是机会判断。
不是所有问题都值得变成一个项目。
项目启动阶段必须做一个基本判断：
- 影响面有多大
- 价值有多大
- 成本有多高
- 风险有多大
- 是否有更轻量的替代方案
这就是我们常说的“价值判断”。
例如：
某 ToC App 想做“个性化主题皮肤商城”。
从体验和品牌层面看，似乎有空间。
但如果当前产品连核心留存都不稳定，这个项目再有想象力，也可能不是当前最优先项。
某 ToB 平台想做“自定义仪表盘拖拽布局”。
从产品能力上看很高级，但如果大多数客户当前最痛的是报表口径不一致，那么“展示层灵活性”就未必比“数据可信度”更值得优先投入。
所以，项目启动阶段不是“看到机会就开工”，而是要做取舍。
5. 这个问题应该从哪个角度切入
同一个问题，不同切入角度，会导向完全不同的项目方案。
例如：
业务方说：提升新用户留存
可能的切入角度有：
- 功能价值理解不足
- 首次使用路径太复杂
- 激励机制不够
- 内容供给不匹配
- 新手引导策略问题
业务方说：提升销售跟进效率
可能的切入角度有：
- 跟进提醒缺失
- 客户信息展示不清
- 录入动作太重
- 阶段推进规则不清
- 团队协同信息不同步
项目启动阶段最关键的，不是急着选方案，而是先做“切口判断”。
这个阶段 PM、UX、UI 都要参与，因为：
- PM 更擅长看业务目标与优先级
- UX 更擅长看用户路径和阻力点
- UI 更擅长看信息表达和操作效率问题
如果只从一个岗位出发，切入角度往往不完整。
6. 我们怎么判断项目后面做得对不对
这是很多团队启动阶段最容易漏掉的一步。
项目一开始就应该想：
- 成功的标准是什么
- 我们后续看什么指标
- 什么结果说明方向对了
- 什么结果说明方案需要调整
例如：
ToC 会员项目
成功标准可能包括：
- 会员页点击开通率提升
- 试用转正式订阅率提升
- 页面停留时长变化
- 用户对权益理解度提升
ToB 跟进提醒项目
成功标准可能包括：
- 跟进逾期率下降
- 商机推进周期缩短
- 销售漏跟进投诉减少
- 功能使用率达到预期
如果启动阶段没有提前定义结果判断标准，后面很容易变成：
- 项目做完了
- 页面也上线了
- 但没人真正知道它到底有没有价值
三、PM、UI、UX 在启动阶段分别做什么
这是这一篇最核心的部分之一。
很多人以为，启动阶段就是 PM 的主场，设计师后面再进。
这种理解在今天已经不够用了。
更成熟的启动方式应该是：
PM 主导方向判断，UX 补充用户与场景洞察，UI 提前介入信息表达与体验预判。
三者不是同时做同样的事，而是从不同专业角度，帮助团队更早把问题看完整。
1. PM：定义问题、判断价值、收敛方向
PM 在启动阶段的核心职责，不是立刻写需求，而是先完成三层判断。
第一层：问题判断
PM 要明确：
- 当前要解决的核心问题是什么
- 这是症状还是根因
- 是单点问题还是系统问题
第二层：价值判断
PM 要回答：
- 这个问题影响什么业务目标
- 值不值得投入
- 优先级是否成立
- 当前阶段做它是否合适
第三层：方向判断
PM 要决定：
- 项目从哪个角度切入
- 目标用户是谁
- 第一阶段范围如何控制
- 哪些先不做
也就是说，启动阶段的 PM 最重要的工作，不是“把方案说满”，而是把问题讲清、把方向收紧、把目标框出来。
PM 在启动阶段常见输出
- 项目背景说明
- 问题定义
- 目标拆解
- 用户与业务影响分析
- 初步范围与边界
- 成功指标草案
- 初步里程碑判断
2. UX：补齐用户视角，把“业务诉求”翻译成“真实使用问题”
UX 在启动阶段不能等 PM 把需求全部写完再介入。
因为很多真正影响项目方向的判断，本来就需要 UX 提前参与。
UX 在启动阶段重点看四件事：
第一，用户是谁
- 核心用户是谁
- 高价值用户是谁
- 新手和老用户是否有差异
- 不同角色用户的目标是否一致
第二，用户当前怎么做
- 用户现在如何完成任务
- 哪一步最费劲
- 哪一步最容易放弃
- 哪些动作是高频，哪些是低频但高价值
第三，用户为什么这样做
- 用户目标是什么
- 用户犹豫点是什么
- 用户认知偏差在哪里
- 用户说的问题和真正的问题是否一致
第四，问题是流程问题、认知问题还是表达问题
这是 UX 在启动阶段特别重要的判断。
例如同样是“用户不完成购买”，原因可能完全不同：
- 看不懂价值
- 操作流程太长
- 缺少信任感
- 价格比较成本高
- 关键信息出现太晚
如果启动阶段没有 UX 的判断，项目很容易把“用户不转化”简单理解成“要做更刺激的运营动作”。
UX 在启动阶段常见输出
- 初步用户问题假设
- 关键场景描述
- 用户路径草图
- 主要阻力点判断
- 研究计划或轻量访谈提纲
- 初步机会点分析
3. UI：提前参与信息表达判断，而不是等方案确定后再“出视觉”
很多团队会把 UI 放在很后面，认为启动阶段还没到 UI 发挥的时候。
这是一个很常见的误区。
因为很多问题，表面看像需求问题或交互问题，本质上其实和信息表达密切相关。
UI 在启动阶段虽然不一定马上产出高保真设计，但应该提前介入看三件事：
第一，当前问题是否与信息层级有关
例如：
- 关键价值没有被优先看到
- 页面重点不明确
- 主操作和次操作区分不清
- 状态表达混乱
- 信息密度过高导致理解成本上升
第二，当前问题是否与界面模式有关
例如：
- 这个场景是不是根本不该用弹窗
- 列表页是否应该切换为卡片模式
- 当前表单结构是否过于线性
- 页面布局是否限制了操作效率
第三，后续表达和规范成本是否可控
例如：
- 这个方向是否会引入新的组件模式
- 是否与现有设计系统冲突
- ToB 场景下是否支持后续扩展
- ToC 场景下是否符合品牌调性
UI 提前参与的意义，不是“抢 UX 的工作”，而是帮助团队尽早发现：
有些问题不是功能不够，而是表达方式错了。
有些问题不是用户不会用，而是页面没有让用户快速理解。
UI 在启动阶段常见输出
- 当前界面问题初判
- 信息层级与重点表达建议
- 界面模式风险提示
- 设计系统影响预判
- 视觉方向初步建议
四、三者在启动阶段到底怎么一起工作
这一部分，我们按之前讨论的思路，讲“协同判断”和“工作方式”，不再混乱拆散。
项目启动阶段，PM、UI、UX 并不是各做各的。
更合理的方式，是围绕同一个项目，完成四轮协同判断。
第一轮：统一问题定义
这一步的目标是：
把“别人提来的需求”翻译成“团队真正要解决的问题”。
典型输入可能来自：
- 老板或业务部门
- 客户反馈
- 销售诉求
- 数据异常
- 市场变化
- 产品团队主动发起
这时三者关注重点不同：
PM 关注
- 这个问题和业务目标的关系是什么
- 值不值得变成项目
- 是短期补丁还是中长期能力建设
UX 关注
- 这是不是用户真实问题
- 问题是否存在关键场景差异
- 用户目标和业务目标是否有冲突
UI 关注
- 当前问题里是否包含明显的信息表达问题
- 是否有界面层级、状态传达、操作引导方面的根本缺陷
这一步的结果，不是立即确定方案，而是形成一个统一表述：
我们真正要解决的问题是什么。
第二轮：统一项目目标
当问题定义清楚后，三者要进一步统一项目目标。
注意，项目目标不是一句空话“优化体验”或“提升效率”，而应该尽量可判断。
例如：
ToC 会员项目
不说“优化会员页体验”，而说：
- 提升试用用户转正式订阅率
- 降低用户对会员权益的理解成本
- 提升核心功能价值感知
ToB 审批项目
不说“优化审批流程”，而说：
- 缩短审批人完成处理的平均时长
- 降低因信息不完整导致的跳转查看次数
- 提升复杂审批场景下的操作准确率
在这一轮里：
PM 负责
把项目目标和业务结果挂钩
UX 负责
把目标转译成用户行为与体验目标
UI 负责
预判哪些目标可能涉及重点表达、页面结构和视觉引导
第三轮：统一切入点
同一个问题可能有很多做法。
启动阶段非常重要的一件事，是尽早统一“我们第一刀从哪里切”。
例如一个“新用户留存低”的问题，切法可能有：
- 优化注册流程
- 优化首次引导
- 强化核心价值展示
- 做激励体系
- 调整首屏内容推荐
- 缩短首个任务完成路径
这里三者的分工是：
PM 判断
- 哪个切法和当前业务目标最相关
- 哪个切法最符合资源与节奏
- 哪个最适合作为 MVP 验证
UX 判断
- 哪个切法最可能降低用户阻力
- 哪个切法能最直接改善任务完成率
- 哪个切法更符合用户当前决策路径
UI 判断
- 哪个切法在表达上最有改善空间
- 哪个切法对页面认知成本影响最大
- 哪个切法更适合快速验证
统一切入点的意义是：
避免项目一启动就什么都想做，最后什么都做不深。
第四轮：统一验证方式
在项目启动阶段，三者还要提前统一一件事：
后面怎么判断这个项目方向是不是对的。
这是协同里非常容易被忽视、但非常关键的一步。
例如：
ToC
- 看会员页点击率还是订阅率？
- 看留存还是任务完成率？
- 看首屏停留还是功能使用深度？
ToB
- 看任务完成时长？
- 看错误率？
- 看培训成本？
- 看客户反馈满意度？
- 看功能使用覆盖率？
在这一步：
- PM 更偏结果和业务指标
- UX 更偏任务完成、路径顺畅、可用性表现
- UI 更偏信息理解效率、关键操作识别、表达一致性反馈
这样做的好处是：
后面项目推进时，团队不容易出现“大家在做同一个项目，但各自按不同标准判断成败”。
五、项目启动阶段的一个可落地 SOP
下面给你一个更适合培训和实际工作使用的启动阶段 SOP。
这部分你后续拿去讲团队培训会很有用。
Step 1：接收项目输入
输入可能来自：
- 老板或业务诉求
- 客户需求
- 数据异常
- 用户反馈
- 团队主动优化提案
此时先不急着下结论，只做信息收集。
Step 2：PM 做初步问题归类
先判断这是：
- 业务增长问题
- 用户体验问题
- 界面表达问题
- 流程效率问题
- 系统能力问题
- 组合型问题
这一步输出初步项目背景和问题草案。
Step 3：UX 做场景与用户问题初判
快速看：
- 主要用户是谁
- 核心任务是什么
- 当前阻力点在哪
- 是否需要补充访谈 / 走查 / 用户反馈分析
这一步输出初步用户问题分析。
Step 4：UI 做表达与模式风险初判
快速看：
- 是否存在明显信息层级问题
- 是否存在界面模式不合理
- 是否需要考虑组件、规范、视觉方向影响
这一步输出表达与设计风险提示。
Step 5：三方对齐会议
围绕四件事达成共识：
- 问题定义
- 项目目标
- 第一阶段切入点
- 后续验证方式
注意：
这不是方案评审会，而是项目理解对齐会。
Step 6：决定是否进入正式立项 / 需求定义
如果判断：
- 问题成立
- 价值成立
- 方向成立
- 切入点清晰
再进入后面的需求调研、研究、方案定义阶段。
如果没有成立，就应该继续补充信息，而不是硬推进。
六、ToB 和 ToC 启动阶段，三者协同重点有什么不同
这个部分也很关键，因为你的专栏一直强调 ToB + ToC 全场景。
ToC 项目启动阶段更强调“机会判断 + 用户行为判断”
ToC 更常见的启动问题是：
- 用户为什么不转化
- 用户为什么留不住
- 为什么某功能打开率低
- 为什么用户理解不了价值
- 为什么流量来了但没形成行为
所以 ToC 启动阶段，三者协同重点一般是：
PM
- 商业目标、增长目标、转化结果
UX
- 用户动机、决策路径、行为阻力
UI
- 价值感知、首屏表达、转化引导
例如注册、订阅、内容分发、裂变、活动转化等项目。
ToB 项目启动阶段更强调“流程问题 + 角色问题 + 复杂度判断”
ToB 更常见的启动问题是：
- 流程效率低
- 多角色协作混乱
- 信息展示不完整
- 配置能力不足
- 培训成本高
- 客户投诉某个步骤不好用
所以 ToB 启动阶段，三者协同重点一般是：
PM
- 业务流程闭环、角色边界、平台价值
UX
- 任务效率、异常场景、认知负担
UI
- 信息组织、状态表达、组件模式、一致性
例如审批、CRM、ERP、工单、知识库、报表平台等项目。
七、启动阶段做到什么程度，才算真正做得好
这一点是为了体现“能力标准”，也是你这套专栏和普通内容拉开差距的地方。
一个项目启动阶段做得好，不是开了会、写了背景、分了工，而是至少满足下面几个标准。
合格标准
- 能说清项目背景
- 能描述主要问题
- 能知道项目大致目标
- 三方知道自己要参与什么
这只能算“启动了”。
熟练标准
- 能把表面诉求和真实问题区分开
- 能识别项目涉及的是业务问题、体验问题还是表达问题
- 能完成 PM / UX / UI 三方基本对齐
- 能明确第一阶段切入点和初步验证方式
这说明团队已经具备比较成熟的启动能力。
优秀标准
- 能快速识别问题根因和错误切法
- 能在启动阶段就减少后续返工风险
- 能把业务目标、用户目标和设计目标统一起来
- 能让三方围绕同一个问题工作，而不是各自产出
- 能为后续需求定义、方案设计和项目推进建立稳定基础
这才是高水平团队的启动能力。
八、结语：项目启动阶段不是“准备动作”，而是第一次真正的项目判断
很多团队把启动阶段看得太轻。
但实际上，项目启动阶段不是热身，而是项目第一次真正开始发生的地方。
因为从这一刻开始，团队要做的已经不是“接一个需求”，而是：
- 定义问题
- 判断价值
- 识别用户
- 统一目标
- 选择切口
- 约定后续验证方式
更重要的是，这个阶段不能只是 PM 一个人想清楚，
而必须让 PM、UI、UX 三个角色从一开始就进入同一个问题空间。
因为只有这样，后面的需求、原型、界面、评审、开发、验证，才可能真正围绕同一个方向推进。
所以这一篇最想强调的一句话是：
项目启动阶段真正要启动的，不是流程，而是三方对问题、用户与机会的共同理解。
当 PM 不再只看需求，
UX 不再只等方案，
UI 不再只接设计，
而是三者从启动阶段就一起进入项目，
项目的质量，往往就已经向前迈了一大步。