面向工程师的产品感觉（Product Sense）完全指南: 客户共情、JTBD、北极星指标、AB 测试、PMF、优先级排序与路线图 (2025~2026)

"Fall in love with the problem, not the solution." — Uri Levine（Waze 创始人）

工程师走向 Staff+ 的路上卡得最狠的一段: 产品感觉。靠技术实力抵达 L4~L5 之后，要往 L6 Staff 走，就必须具备“做什么、为什么做”的判断力。

2024~2025 年，AI 代码生成让“怎么实现”的价值相对下降，而“做什么、为什么”的判断价值上升。这篇文章要为工程师搭一套每天都能用的产品感觉系统。

1. 产品感觉到底是什么

1.1 定义

产品感觉 = 理解用户的需求、行为与情境，并做出与业务目标一致的产品决策的能力。

三个轴:

1. Customer Empathy: 谁在用、为什么用、在什么情境下用。
2. Problem Framing: 真正的问题是什么。
3. Solution Judgment: 在多个解法中选哪一个，为什么。

1.2 技术感觉 vs. 产品感觉

Staff+ = 两种感觉的整合。只有其中一种的工程师会停在 Senior。

1.3 工程师获得产品感觉之后会发生什么

• 在方案评审里问得出真正的问题。
• 能和 PM 平等对话。
• 在技术债的争论里使用权衡的语言。
• 在路线图会议上对优先级有自己的意见。
• 能创业，也能做内部创业。

2. Customer Empathy — 客户共情的三个层次

2.1 Level 1 — Data-based Empathy

• Google Analytics、Mixpanel、Amplitude 的分析。
• 同期群留存率、漏斗流失。
• 谁停留、停留多久。

局限: 数字能告诉你“是什么”，却解释不了“为什么”。

2.2 Level 2 — Observational Empathy

• User Session Recording: 用 Hotjar 或 FullStory 录下真实使用过程。
• Support Ticket 分析: 反复出现的痛点。
• NPS 与问卷: 直接问。
• Sales Call 录音: 在 Gong 或 Chorus 上听。

局限: 用户“说出来的”和“真正想要的”可能是两回事。

2.3 Level 3 — Immersive Empathy

• 拜访客户: 在他们的办公室或家里观察真实使用。
• Dogfooding: 自己每天都用这个产品。
• 客户 Shadowing: 在旁边跟一整天，观察他们的工作。
• 扮演客户角色: 如果产品的画像是 PM 或开发者，就亲自去做一遍。

例子: Airbnb 的三位创始人用一个月只用自家产品，发现“想再订一次的房源”为什么这么少 → 免费引入专业摄影服务 → 收入翻倍。

2.4 工程师马上就能开始的五件事

1. 每月和五位客户各通话 30 分钟。“上周你是什么时候用这个产品的？”
2. 订阅 Support 频道。Slack 或 Zendesk 的通知。
3. 每天使用自家产品。Eat your own dog food.
4. 监控评价网站。G2、Capterra、Product Hunt、App Store 的评论。
5. 每周听一次 Sales Call。

3. Jobs-to-be-Done (JTBD) — 问题框定的革命

3.1 Christensen 的“奶昔故事”

麦当劳奶昔销量上升的原因调查:

• 按人口统计做细分，失败了。
• 客户观察: 早上 7 点，三四十岁的男性在通勤路上购买。
• JTBD: “我需要一个能打发无聊通勤、还能把饥饿撑到 10 点的方便东西。”
• 竞争对手: 香蕉、贝果、咖啡（不是别的奶昔）。
• 解法: 早晨专用的浓稠奶昔，加上能快速出餐的装置。

3.2 JTBD Framework

“人不是在买产品，而是为了在自己的人生里做出某种 Progress 而 Hire 一个产品。” — Christensen

Job Story 格式:

When [situation], 
I want to [motivation], 
So I can [expected outcome].

例子:

• 差的写法: “客户想要一个移动 App。”
• 好的写法: “出差途中在机场候机室，我想快速确认日程，好让自己在会议前感觉已经准备好了。”

3.3 Functional/Emotional/Social Jobs

• Functional: 功能性的任务（追踪待办）。
• Emotional: 情绪（减少焦虑、获得成就感）。
• Social: 社会性的（看起来专业）。

例子 — 购买 Tesla:

• Functional: 从 A 到 B 的移动。
• Emotional: 化解环保上的愧疚，未来感。
• Social: 环保形象，早期采用者的身份。

只看 Functional，产品设计就会失败。

3.4 面向工程师的 JTBD 实战

针对你正在做的这个功能:

1. 使用这个功能的用户处在什么情境里。
2. 他想用这个功能做出什么样的 Progress。
3. Functional、Emotional、Social 各自是什么。
4. 提供同样 Progress 的其他解法有哪些。（竞争）
5. 这个功能真的造出了这份 Progress 吗。

光是这五个问题，就能改进一份方案的 50%。

4. North Star Metric — 让所有人朝同一个方向

4.1 北极星指标的定义

"The one metric that best captures the core value your product delivers to customers." — Sean Ellis

只要这一个指标上升，产品和公司就在走向成功的那个指标。

4.2 著名的 NSM 例子

共同点:

• 是客户真正体验到价值的行为。
• 与公司收入相关。
• 可测量。
• 可提升。

4.3 NSM 的反模式

• 收入本身: 滞后指标，团队没法直接推动。
• PV 与点击: 量上涨很容易，却和价值无关（Yahoo 时代的失败）。
• 有好几个: 四个以上就不叫北极星了。

4.4 工程师的实战应用

在功能层级设计 NSM:

• 团队正在做的功能，它的 NSM 是什么。
• 这个功能怎样为自己团队的 NSM 做贡献。
• 提不动 NSM 的功能，为什么还要做。

在方案评审里只要抛出这个功能对 NSM 的贡献是什么这一个问题，团队的决策水准就会不一样。

5. Product-Market Fit (PMF) — 有没有，以及到了哪一步

5.1 PMF 的定义

"Product-Market Fit means being in a good market with a product that can satisfy that market." — Marc Andreessen

PMF 不是 On/Off，而是一个 Spectrum。

5.2 Rahul Vohra 的 PMF Survey

“如果以后再也不能用这个产品，你会怎样？”

• Very Disappointed 达到 40% 以上就是 PMF。
• 不到 40%: 还没到 PMF。

Superhuman 就是用这个方法设计了自己通往 PMF 的路径。

5.3 PMF 的四个阶段

1. Idea Fit: 这个想法是否真的在处理一个真实问题。
2. Problem Fit: 用户是否真的感受到那个问题。
3. Solution Fit: 我们的解法是否解决了那个问题。
4. Market Fit: 市场是否愿意付钱。

工程师最常掉进的陷阱: 把大量时间花在第 3 步，却没验证第 1、2 步就一路狂奔。

5.4 PMF 之后 — Scale Fit

有了 PMF 也不等于成功。Go-to-Market Fit、Channel Fit、Pricing Fit 还得各自拿下。

很多技术创业公司有 PMF，却因为没有 GTM 而失败。

6. AB Test — 实验的技艺

6.1 AB Test 失败的原因（超过 60%）

1. 样本量不足: 达不到统计显著性。
2. 测量周期太短: 一周的实验看不出长期影响。
3. Novelty Effect: 把初期效果误当成持续效果。
4. 指标选错: 只盯着代理指标（Proxy）。
5. 忽略 Segmentation: 平均值好看，某个群体却被搞砸了。
6. 外部变量: 季节、活动、市场投放的变化。
7. 实现有 Bug: A 和 B 并没有按设计真正分开。
8. Selection Bias: 分组不是随机的。

6.2 像样的 AB Test 协议

1. Hypothesis: "If X, then Y, because Z."
2. 样本量计算: 事前用 Power Analysis 算好。
3. 周期: 至少两周到一个月，考虑周内的 Cycle。
4. Primary Metric + Guardrail: 主指标 + 不能变差的护栏指标。
5. Segmentation 计划: 事先定好。
6. MDE (Minimum Detectable Effect): 想要检测到的最小效应。
7. 事前写好 Analysis Plan: 防止事后的 p-hacking。

6.3 Airbnb 与 Booking.com 的案例

• Booking.com: 同时运行 1,000 个实验。一年约 1,000 个里，90% 是 NULL 或 Negative，只有 10% 带来改进。
• 教训: 实验绝大多数都会失败。实验文化的意义在于快速发现失败。

6.4 工程师的实验 Mindset

• 每做一个功能之前先问“这个能用实验验证吗？”
• 把失败的实验重新框定为学习。
• 理解置信区间（掌握统计基础）。
• Launch 不是实验的结束，而是持续监控的开始。

7. 优先级框架

7.1 RICE 框架

• Reach: 会覆盖多少用户。
• Impact: 影响有多大（1、2、3 分）。
• Confidence: 有多确信（0.5、0.8、1.0）。
• Effort: 要花多大力气（Person-Month）。

RICE Score = (R × I × C) / E.

7.2 Kano Model

从用户视角对功能做分类:

1. Must-be（必备）: 没有就不满，有也是理所当然。
2. Performance（性能）: 越多越满意。
3. Attractive（魅力）: 没有也行，有了会惊喜。
4. Indifferent: 根本不在意。
5. Reverse: 有了反而讨厌。

策略: 必备型要守住，把投资放在魅力型上做差异化。

7.3 ICE — 轻量版

• Impact、Confidence、Ease 各 10 分。
• 总分高的先做。

比 RICE 更快，也更适合在会议上直接用。

7.4 工程师如何在优先级会议上做贡献

• 只有工程师才看得见的成本: 技术债的累积与维护成本。
• 只有工程师才看得见的价值: Future Optionality 与平台效应。
• 用数字讲出来: “现在不做，六个月后就要做 X 重构，要花 Y 周。”

8. Roadmap 设计 — 3 个月、6 个月、2 年

8.1 Now / Next / Later 框架

• Now（接下来的 1~3 个月）: Commit，具体。
• Next（3~6 个月）: 已排优先级，可能变动。
• Later（6 个月以后）: 方向性的，保持弹性。

8.2 Outcome-based Roadmap

不用功能清单，改用 Outcome + 实验:

Q1 Outcome: Free→Paid 转化率 10%→15%。
Experiments:
- 改进 Onboarding checklist
- Paid Trial 的好友邀请激励
- Usage-based pricing 实验

好处: 就算某个具体功能失败了，注意力仍然集中在达成 Outcome 上。

8.3 Lean Roadmap (Opportunity Solution Tree)

Teresa Torres 的 Continuous Discovery:

• Outcome: 目标。
• Opportunities: 3~5 个问题或机会。
• Solutions: 每个机会 2~3 个想法。
• Experiments: 对每个方案做验证。

它化解了自上而下路线图的僵硬。

8.4 两年 Vision + 90 天 Tactical

• 两年 Vision: 不变，定住团队方向。
• 90 天 Tactical: 每三个月 Review 与 Adjust。
• 每月: 检查 Progress。
• 每周: Blocker 与 Shift。

9. 设计工程师 + PM 的关系

9.1 最差 vs. 最好的关系

9.2 工程师在与 PM 的关系上该投资什么

1. 理解 PM 的 Why: 把 OKR 与 NSM 内化。
2. 共享 Customer Empathy: 一起看 Session 与 Ticket。
3. 解释 Tech Constraint: 用 PM 听得懂的语言讲 Trade-off。
4. Proactive Proposal: 主动先提“这样做怎么样？”
5. Respect Product Thinking: 丢掉“PM 就是写 Spec 的人”这种偏见。

9.3 没有 PM 的团队里的工程师

在创业公司和小团队里，工程师会兼任 PM 的角色:

• 亲自 Lead 客户通话。
• 起草 OKR 与路线图。
• 掌握优先级决定权。
• 度量成果。

这类经验，对走向 Staff+ 或者创业都是很强的资产。

10. 产品感觉学习资料 Top 15

10.1 书

1. 《Inspired》 — Marty Cagan（产品团队的原则）。
2. 《The Lean Startup》 — Eric Ries（实验文化）。
3. 《Escaping the Build Trap》 — Melissa Perri（Outcome）。
4. 《Competing Against Luck》 — Clayton Christensen（JTBD）。
5. 《Hooked》 — Nir Eyal（习惯设计）。
6. 《The Mom Test》 — Rob Fitzpatrick（客户访谈）。
7. 《Measure What Matters》 — John Doerr（OKR）。
8. 《Trustworthy Online Controlled Experiments》 — Kohavi。

10.2 博客与 Newsletter

9. Lenny's Newsletter。
10. First Round Review。
11. Reforge Blog。
12. Stratechery (Ben Thompson)。

10.3 Podcast

13. Lenny's Podcast。
14. Acquired (Ben Gilbert, David Rosenthal)。
15. This Week in Startups (Jason Calacanis)。

11. 90 天产品感觉启动包

11.1 Month 1 — Empathy Foundation

• 每周和五位客户通话。
• 每天使用自家产品。
• 每天在 Support 频道待 10 分钟。
• 每周看一次客户评价网站。

11.2 Month 2 — Framing

• 用 JTBD 格式重写三个功能。
• 和团队讨论 NSM 与 Guardrail。
• 每周看一小时 Session Recording。

11.3 Month 3 — Judgment

• 用 RICE 给路线图重新排优先级。
• 亲手设计一个实验。
• 写一份 90 天 Outcome 文档。

12. 产品感觉检查清单 12 条

• 每月和五位客户聊 30 分钟。
• 每天使用自家产品。
• 订阅了 Support 频道。
• 熟悉 JTBD 的 Job Story 格式。
• 理解并共享团队的 NSM。
• 用 PMF 阶段诊断过自家产品。
• 理解 AB Test 的基础统计。
• 使用 RICE 与 ICE 排优先级。
• 采用 Outcome-based Roadmap。
• 能和 PM 进行平等的产品对话。
• 每季度做一次 Customer Deep Dive。
• 持续摄入书籍与 Podcast。

13. 产品感觉反模式 10 条

1. “工程师只管实现”: Staff+ 无望。
2. 把功能需求原样实现: 无视 JTBD 与 Opportunity。
3. “卖不出去是市场部的锅”: 没意识到 PMF 缺失。
4. 只追短期指标: 无视留存与 LTV。
5. 对 AB Test 结果做樱桃采摘: 只挑自己想要的结果看。
6. 没有 NSM 就干活: 没有方向地做功能。
7. 把客户“说的话”照单全收: Ford 的“更快的马”陷阱。
8. Feature Factory: 功能数量 = KPI。
9. “No Time for Discovery”: 忙着执行，不做验证。
10. 敌视 PM: 放弃了学习的机会。

14. 收尾 — 产品感觉是一块肌肉

"Good judgment comes from experience. Experience comes from bad judgment." — Mulla Nasrudin（推测）

产品感觉不是天生的。它是你和用户一起度过的时间的函数。

每周 5 次客户通话 × 10 年 = 2,500 次通话。这份积累会把你变成另一个工程师。

对 2026 年的工程师来说，产品感觉是通往 Staff+ 的 Tier-1 路径。技术实力会被 AI 抵消，但对用户、市场、业务的理解，依然属于人的领域。

开始只要三件事:

1. 这周和一位客户通话 30 分钟。
2. 用 JTBD 的 Job Story 写下一次的 PR description。
3. 读一遍自己团队的 NSM，用一句话写下你在下个 Sprint 里的贡献。

三个月后，你的方案评审会是另一种质量。

下篇预告 — “工程师的政治力: 组织、权力、决策、Alliance 与 Political Capital 的设计”

如果说产品感觉是“做什么”，组织政治力就是“怎么让它通过”。下一篇会讲:

• 权力(Power)的定义 — Jeffrey Pfeffer 的《Power》
• Political Capital 的积累与支出
• Alliance 与 Stakeholder Mapping
• 冲突的种类与化解 — Lencioni 的 5 Dysfunctions
• “Push vs Pull”的影响策略
• Good Politics vs. Bad Politics
• 晋升、重组、争取预算的实战
• 工程师最常忘掉的五种政治力

我们要丢掉“政治是脏东西”的偏见，去设计良善而有效的政治力。下一篇继续。