Back to Details

decision-importance-prioritization

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese
The most important part of making a decision is determining how important that decision actually is. By categorizing decisions, you can maintain high team velocity for the trivial and apply rigorous deliberation to the critical few.
做出决策最重要的部分是确定该决策的实际重要性。通过对决策进行分类，你可以在琐碎事项上保持团队的高推进速度，同时对少数关键事项进行严谨的审议。

The Classification Framework

分类框架

Evaluate every decision against two primary filters to determine its "Importance Score."
通过两个核心维度评估每一项决策，以确定其「重要性得分」。

1. Reversibility

1. 可逆性

  • Low Importance (Reversible): If the decision is wrong, can you undo it quickly without lasting damage to the brand or technical debt? (e.g., UI copy, small feature toggles).
  • High Importance (Irreversible): Is this a "one-way door"? Once shipped, does it change the data schema, API contract, or user mental model in a way that is painful to revert? (e.g., pricing changes, platform architecture).
  • 低重要性（可逆）： 如果决策失误，你能否快速撤销它，且不会对品牌造成持久损害或留下技术债务？（例如：UI文案、小型功能开关）。
  • 高重要性（不可逆）： 这是否是「单向门」决策？一旦落地，是否会以难以回退的方式改变数据架构、API协议或用户心智模型？（例如：定价调整、平台架构设计）。

2. Material Impact

2. 实质性影响

  • Breadth: How many users/stakeholders does this affect? (1% vs. 100%).
  • Depth: How much does it affect them? Does it impact their livelihood or core workflow, or is it a minor convenience?
  • 广度： 该决策会影响多少用户/利益相关者？（1% vs 100%）。
  • 深度： 对他们的影响程度如何？是会影响他们的生计或核心工作流程，还是仅带来微小的便利变化？

The 1/99 Resource Allocation Rule

1/99资源分配法则

Once classified, apply your cognitive energy and time disproportionately:
完成分类后，需将你的精力和时间进行差异化分配：

For the 1% (High Importance)

针对1%的高重要性决策

  • Spend 90% of your time here.
  • Conduct deep research, seek peer feedback, and build high-conviction models.
  • "Shoot your shot" only when the strategy is sound, as your reputation and the product's trajectory depend on these few calls.
  • 投入90%的时间。
  • 开展深度研究、寻求同行反馈，并建立高可信度的决策模型。
  • 只有当策略成熟时再推进执行，因为你的声誉和产品的发展轨迹都取决于这少数几个关键决策。

For the 99% (Low Importance)

针对99%的低重要性决策

  • Optimize for Speed.
  • Use your gut: If a decision is reversible, your intuition is often "good enough."
  • Delegate: Give these decisions to the team to build their autonomy and "trust battery."
  • Rule of Thumb: Never be the bottleneck for a reversible decision. Make a call in minutes, not days.
  • 以速度为优化目标。
  • 相信直觉： 如果决策是可逆的，你的直觉通常已经「足够可靠」。
  • 授权： 将这些决策交给团队处理，以培养他们的自主性和「信任储备」。
  • 经验法则： 永远不要成为可逆决策的瓶颈。要在几分钟内做出决定，而不是几天。

Implementation Steps

实施步骤

  1. Identify the Decision: Clearly state the choice at hand.
  2. Run the Filters: Ask, "If this is a disaster, how hard is it to fix?" and "How many people will actually notice?"
  3. Set the Deadline:
    • If Low Importance: Decide within the meeting or by the end of the day.
    • If High Importance: Schedule a dedicated "Deep Dive" or "Investment Plan" review.
  4. Communicate the "Why": When delegating or making a fast "gut" call, explain that the low stakes allow for higher velocity.
  1. 明确决策事项： 清晰阐述当前需要做出的选择。
  2. 应用评估维度： 自问，「如果这个决策出错，修复难度有多大？」以及「实际上会有多少人注意到这个变化？」
  3. 设定截止时间：
    • 若为低重要性决策：在会议期间或当天结束前做出决定。
    • 若为高重要性决策：安排专门的「深度研讨」或「投入计划」评审会。
  4. 沟通决策逻辑： 当授权他人决策或快速凭直觉做出决定时，要向团队解释：正是因为这些事项风险低，所以我们可以追求更高的推进速度。

Examples

示例

Example 1: UI Polish
  • Context: A designer asks for a decision on whether a secondary action button should be gray or light blue.
  • Application: This is highly reversible and has low depth of impact.
  • Output: "Go with your preference. This is a reversible decision; let's ship it and see the heatmaps. Don't let me block you."
Example 2: Platform API Change
  • Context: Changing the way third-party developers access merchant order data.
  • Application: This is irreversible (breaks existing apps) and has high depth (affects developer livelihoods).
  • Output: Classify as High Importance. Stop other work. Spend two weeks on a "war time" document analyzing edge cases, data policy, and developer sentiment before deciding.
示例1：UI细节优化
  • 场景： 设计师询问次要操作按钮应该用灰色还是浅蓝色。
  • 评估： 该决策具有高度可逆性，且影响深度较低。
  • 行动： 「按你的偏好来。这个决策是可逆的，我们先上线，之后看热力图数据再调整。别让我成为你的阻碍。」
示例2：平台API变更
  • 场景： 更改第三方开发者访问商家订单数据的方式。
  • 评估： 该决策不可逆（会导致现有应用崩溃），且影响深度高（会影响开发者的生计）。
  • 行动： 将其归类为高重要性决策。暂停其他工作，花费两周时间撰写「战时文档」，分析边缘案例、数据政策和开发者情绪后再做出决定。

Common Pitfalls

常见误区

  • The Analysis Paralysis Trap: Treating a reversible decision with the same rigor as an irreversible one. This kills team momentum and wastes your most valuable resource: focus.
  • The Bottleneck Manager: Requiring all small decisions to cross your desk. This drains the team's "trust battery" and makes you a single point of failure.
  • Sunk-Cost Fallacy: Sticking with a High Importance decision after the world has changed (e.g., a global pandemic). Have the humility to "throw it all away" if the original conviction is no longer valid.
  • Ignoring "Depth" for "Breadth": Making a decision because it affects few people, even if it completely ruins the experience for those specific few (e.g., power users or top-tier developers). Always weigh the severity of the impact.
  • 分析瘫痪陷阱： 对可逆决策采用与不可逆决策相同的严谨程度。这会扼杀团队的动力，并浪费你最宝贵的资源：专注力。
  • 瓶颈型管理者： 要求所有小决策都必须经过你的审批。这会消耗团队的「信任储备」，并让你成为单点故障。
  • 沉没成本谬误： 当外部环境已经变化时（例如全球疫情），仍坚持之前做出的高重要性决策。如果最初的决策依据已不再成立，要有勇气「全盘推翻」。
  • 重广度轻深度： 仅仅因为受影响的人数少就做出决策，即便这会彻底破坏特定群体的体验（例如核心用户或顶级开发者）。始终要权衡影响的严重程度。