Chaos and Order

💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

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

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

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

1. 产品感觉到底是什么

1.1 定义

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

三个轴:

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

1.2 技术感觉 vs. 产品感觉

技术感觉	产品感觉
怎么实现	做什么、为什么
代码质量	用户体验
性能与可扩展性	留存与参与度
“正确的设计”	“正确的问题”
Framework 与 Pattern	User 与 Market

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 工程师马上就能开始的五件事

每月和五位客户各通话 30 分钟。“上周你是什么时候用这个产品的？”
订阅 Support 频道。Slack 或 Zendesk 的通知。
每天使用自家产品。Eat your own dog food.
监控评价网站。G2、Capterra、Product Hunt、App Store 的评论。
每周听一次 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 实战

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

使用这个功能的用户处在什么情境里。
他想用这个功能做出什么样的 Progress。
Functional、Emotional、Social 各自是什么。
提供同样 Progress 的其他解法有哪些。（竞争）
这个功能真的造出了这份 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 例子

公司	North Star
Facebook	DAU
Airbnb	Nights Booked
Slack	Paid Teams with 2,000+ Messages
Spotify	Time Spent Listening
Zoom	Weekly Hosted Meetings
Duolingo	DAU with Lessons Completed
Stripe	Payment Volume Processed

共同点:

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

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 的四个阶段

Idea Fit: 这个想法是否真的在处理一个真实问题。
Problem Fit: 用户是否真的感受到那个问题。
Solution Fit: 我们的解法是否解决了那个问题。
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%）

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

6.2 像样的 AB Test 协议

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

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

Must-be（必备）: 没有就不满，有也是理所当然。
Performance（性能）: 越多越满意。
Attractive（魅力）: 没有也行，有了会惊喜。
Indifferent: 根本不在意。
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. 最好的关系

最差	最好
PM 把 Spec 扔过来，工程师只管实现	一起探索 Problem 与 Solution
只盯着 deadline 的 PM + 从不问“为什么”的工程师	从“为什么”开始一起讨论
PM 装作不懂技术	PM 也理解基本的技术
工程师装作不了解用户	工程师也对用户有共情

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

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

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

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

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

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

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

10.1 书

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

Lenny's Newsletter。
First Round Review。
Reforge Blog。
Stratechery (Ben Thompson)。

10.3 Podcast

Lenny's Podcast。
Acquired (Ben Gilbert, David Rosenthal)。
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 条

13. 产品感觉反模式 10 条

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

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

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

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

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

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

开始只要三件事:

这周和一位客户通话 30 分钟。
用 JTBD 的 Job Story 写下一次的 PR description。
读一遍自己团队的 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
晋升、重组、争取预算的实战
工程师最常忘掉的五种政治力

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