防功能臃肿 IC 优先法则

解决什么问题

B2B SaaS产品几乎必然会走向"功能臃肿(bloat)"——每个客户都有一个"我们也需要这个"的定制诉求,尤其是销售压力下,PM很容易一个个都答应下来,最终产品变得让一线使用者(IC)越来越讨厌用。需要一条清晰、可执行、不用每次都重新debate的判断线。

核心内容

Nan Yu 给出Linear内部处理这个问题的具体规则,不是抽象的"以用户为中心",而是一条非常具体的识别标准:能明确归类为"中层管理者为了报表方便,以牺牲一线执行者(IC)工作体验为代价"的功能请求,一律直接拒绝,没有讨论空间。

判断这类请求的典型特征:

提出者通常是buyer侧的把关人(gatekeeper)或中层管理者,而不是每天使用产品的人;
需求本质是"我要能追踪/报告某件事",要求IC手动填写额外的自定义字段、下拉选项等;
后果是可预测的:IC的绩效考核不基于"填对了报表字段",而是基于实际产出(比如工程师靠代码贡献拿评价),所以他们会敷衍应付——随便选一个下拉选项、留空、乱填——最终这些报表数据本身就是错的、稀疏的、不可信的,管理者以为自己在做数据驱动决策,实际决策依据是垃圾数据。

Yu指出这条规则之所以能被坚定执行,是因为**"这是个假的取舍(false trade-off)"**:一旦产品开始在这个方向上走出第一步,IC就会开始脱离(disengage),整个产品氛围随之恶化——短期看似满足了一个大客户的采购决策,长期看会侵蚀让产品被人喜爱的根本原因。同时Yu提到一个反直觉的观察:这类"必须妥协的商业压力"在实践中并没有想象的那么大——买家做采购决策的真正原因,是希望"团队变得更有效率",而Linear的应对策略是主动帮买家意识到"你以为需要的这个定制功能,恰恰就是让团队变低效的根源",从而在源头上化解掉这个需求,而不是被动接受、事后想办法弥补。

对于"一次性列出一长串诉求(laundry list)"的客户,Yu的应对方式是主动追问优先级("这10个你是同等看重吗?"),往往发现只有前3项是真正重要的,如果Linear能把这3项原生做得远超对手,后面的长尾诉求反而可以被搁置甚至放弃对比其他方案的"可定制化"路线。

一个具体案例:大量客户要求"完全自定义字段",深挖后发现40%的真实动机是"我想追踪某个大客户(如Walmart)提的功能请求"。Linear没有做"给你100个自定义字段"这种会让IC痛苦的方案,而是原生做了一个"Customer(客户)"概念,自动对接客户支持工具和CRM,自动打标签,IC完全不需要额外操作,管理者反而获得了比手动打标更准确的报表——这是"用原生功能真正解决问题背后的意图,而不是简单满足表面诉求"的示范。

适用边界

这条规则的前提是团队愿意为此承受"短期内可能损失部分大客户订单"的代价,Yu提到COO和公司整体战略层面对此有共识,这不是PM一个人能扛住的决定;
规则本身只针对"以牺牲IC体验为代价换取管理层报表便利"这一类特定诉求,不代表所有企业级/合规类需求(如SSO、SAML、SCIM)都要拒绝——Yu明确说这类"维持基本运转"的需求属于必须做的部分,不在这条拒绝规则的范围内。

关键引述 · 原话

"只要符合这个描述,我们就直接说不,没有讨论的余地,因为我们已经想清楚了,这条路我们一步都不能走。"——Nan Yu

— Nan Yu

关联卡片

与"feel-bad-like-customer"(nan-yu)配套——识别"哪些诉求是真正的核心痛点、哪些是表面诉求"依赖同一套深挖客户真实动机的方法。