Sunqy 文档库

主题

02 · 产品思维：目标、用户、指标与需求语境 ​

产品思维不是"替产品经理想点子"，是"听懂需求背后的目标"。 当你理解了"这个功能在解决谁的问题、怎么算成功"，你写代码的方向、取舍、优先级就都有了依据。本篇给开发者一套可操作的产品思维四件套：目标、用户、指标、需求语境。

速览卡 ​

项内容
一句话定位用"目标 → 用户 → 指标 → 需求语境"四件套，让开发者在动手前看懂需求背后的业务逻辑
核心内容目标的两种类型、用户与场景、指标的拆解（北极星 + 指标树）、需求语境的四问、怎么和产品对齐
读完能回答拿到需求先问什么？怎么判断"这个功能值不值得做"？怎么用指标衡量成功？
相关板块F02 · 需求拆解 ｜ H06 · 埋点与数据 ｜ G08 · 应用形态

一、目标：先分清"业务目标"和"功能目标" ​

同一句话，产品经理和开发者的理解经常错位。分清两类目标：

类型回答例子
业务目标为什么做、对业务有什么价值提升 7 日留存、降低客诉率
功能目标做了什么、用户能用什么新增能耗趋势图表、支持导出报表

判断标准：功能目标服务于业务目标。如果说不清"这个功能服务于哪个业务目标"，这个功能很可能就是伪需求。动手前先把业务目标问出来。

二、用户：谁用、在什么场景用 ​

目标之下是用户。不搞清用户，设计就会"既要又要"：

维度要问的问题
是谁内部运维、外部客户、还是终端消费者？
场景在手机上看一眼、还是盯着大屏分析？
能力专业用户还是普通用户？要不要新手引导？
环境弱网、低端机、横屏/竖屏、离线？

一个功能的用户往往有多个角色（操作者、查看者、审批者），每个角色的诉求不同。写代码前至少列两个角色，避免"只服务了填需求的那个人"。

三、指标：把"成功"变成可观测的数字 ​

3.1 北极星指标 ​

一个产品/功能有一个核心指标（北极星），其他指标服务它。比如：

产品北极星指标
能耗管理 App日活里"查看过能耗报告"的用户占比
运维后台故障平均定位时间（MTTD）
AI 客服问题解决率（CSAT + 转人工率）

3.2 指标树：把北极星拆到可执行 ​

北极星太宏观，要拆成指标树，每个分支对应一个可优化点：

text
问题解决率 ↑
├── 答案命中率 ↑（RAG 检索质量）
├── 转人工响应快（工单效率）
└── 用户满意度 ↑（回答友好度）

指标拆到"开发能影响的一层"才有用。开发改不了"品牌认知"，但能改"答案命中率"。

四、需求语境：动手前问四句 ​

拿到一条需求，先问四句，把语境补全：

  1. 这个需求解决谁的什么问题？（目标 + 用户）
  2. 现在是怎么做的？痛点在哪？（现状，别只看未来）
  3. 怎么算成功？（指标，见第三节）
  4. 如果不做会怎样？（优先级判断）

这四问是 F02 需求拆解的上游输入。产品思维不替代拆解，而是在拆解之前把"为什么做"讲清楚。

五、怎么和产品经理对齐 ​

对齐不是"开会听需求"，而是带着理解去确认：

做法好处
复述目标："所以这次的目标是提升 X 对吧？"暴露理解偏差
主动问指标："怎么衡量成功？"把模糊需求变成可验收
给技术约束："这个在弱网下体验会差，要不要先出轻量版？"把上游语境和技术现实接上
记录结论让后续评审有依据

前端转全栈，你能从"数据链路 + 界面 + 服务端"三个视角参与对齐，这是纯 UI 或纯后端工程师难以替代的位置。

自检清单 ​

  • [ ] 能区分业务目标和功能目标，并问出功能背后的业务目标
  • [ ] 能说出功能的用户是谁、在什么场景用，至少两个角色
  • [ ] 能给出功能的北极星指标，并拆出"开发能影响"的指标树
  • [ ] 动手前完成"四问"（谁的问题/现状/成功/不做会怎样）
  • [ ] 能主动复述目标、问指标、给技术约束

常见误区 ​

误区事实
"产品思维 = 替产品想需求"是听懂目标，不是抢产品的活
"指标是分析师的事"开发必须知道成功指标，才能做取舍
"问多了显得不懂"问目标与指标是专业，不是外行
"功能上线就成功"没有指标，上线无法证明成功与否

动手练习 ​

练习 A：补全一个需求的产品语境 ​

选一个真实需求，填四件套：业务目标、用户与场景、北极星指标、指标树。写不出的项，去找产品经理补齐。

练习 B：画指标树 ​

给手上产品画一棵"北极星 → 指标树"，标出哪一层是开发能影响的，哪一层是运营/市场的事。

练习 C：演练对齐 ​

模拟一次需求对齐：对方只给一句话需求，你用"复述目标 + 问指标 + 给技术约束"三招把语境补全，看能否得到一份可拆解的需求。

相关文档 ​

本区 ​

其他域 ​