销售功能请求预算

核心机制：每季度给 head of sales 一个固定的产品资源预算，让他自己 force-rank。

1. 给预算：用 story points 或研发资源的固定比例（如 10%）都行。预算归 VP of Sales 所有，任何人不能抢（除了 CEO）。一旦有了预算约束，"周一要 HubSpot 集成、周三要 SAP、下周一又要 Salesforce"的风向式需求会自动消失——他会开始自己做取舍："也许我其实不需要那个 HubSpot 集成"。
2. 按季度节奏：不管你一天发多少个 release，客户实际只能消化一年 2 次大 release、至多按季度感知。所以季度预算符合客户侧的真实节奏。
3. 每周 VP Sales × VP Product 例会：过三件事——当前在建什么、未来两个季度计划什么、要不要改。季度中途可以推翻（"百万美元的单子，我们是创业公司，可以停下一切"），但要明示成本："这个集成已写完 80%，越晚改代价越大，而且你的预算已经用掉了。"要"假装客观"地把选择权和代价摆给销售。
4. 双方各自开团队会：销售团队 30 分钟 whiteboard force-rank 需求——Lemkin 的观察是 100% 的情况下，会议结束时的排序和开始时不同；产品团队 15 分钟 review 销售的优先级，常有 magic moment（"这个 HubSpot 集成我上家做过，一天就能写"/"可以 2 万美元外包给我认识的 agency 下周交付"）。
5. IC 层请求向上推：rep 找 PM 吃饭聊需求是好事（这也是去 office 的理由之一），但 PM 的正确回应是"我会向我的 boss 推荐"，决策必须推到 VP 层——否则一次性的 VP 级张力会变成一百次 IC 级消耗。

健康度判断：product 和 sales 之间存在张力是好公司的标志。 没有张力说明你们根本不在 deal 里。张力需要结构来承载，否则会撕裂组织。