# /mckinsey-issue-tree: trees to solve any problem
**作者**: George from prodmgmt.world
**日期**: 2026-07-27T11:44:04.000Z
**来源**: [https://x.com/nurijanian/status/2081707189853642988](https://x.com/nurijanian/status/2081707189853642988)
---
Many product and business problems go wrong before people even start to study them. This happens because the team has not agreed on what problem they are trying to solve. One question can make people think about the cause, the plan, and the solution all at the same time.
Each person may answer a different question. Finding the cause, making a plan, and choosing a solution are three different jobs. When people mix them together, they can miss important facts or make weak decisions. For example, someone might guess the cause when the team really needs a plan. Or the team might talk about fixes before they know what caused the problem.
A good way to study a problem is to follow one of three clear paths. The team asks questions one step at a time and checks that nothing is repeated or left out. AI can help with these checks. The product manager still decides what problem to study, what the main problem is, and which questions the team should answer.
## Untangle the branches of thought
1. A Why-tree finds causes. Its root asks why something is happening. Its leaves list possible causes. The final output is a set of testable hypotheses.
2. A What-tree breaks down work. Its root asks which work a deliverable requires. Its leaves list analyses, decisions, commitments, artifacts, or processes. The final output is a plan in the right order.
3. A How-tree lists possible paths. Its root asks how the team might reach a chosen goal. Its leaves list concrete actions. The final output is a set of ranked options.
Use Why for causes, What for work units, and How for actions. Each leaf type supports a different decision.
## Example
Input: “Our new-user activation is underperforming. We need to decide what to do.”
The visual below uses placeholders for branch types and contains no findings about a real product.
```text
WHY: Why is new-user activation underperforming?
├── 1. [Candidate cause family A]
├── 2. [Candidate cause family B]
└── 3. [Candidate cause family C]
Output: testable hypotheses
WHAT: What does producing an activation plan require us to unpack?
├── 1. Evidence
│ └── 1.1 [ANALYSIS] Evidence the plan needs
├── 2. Choices
│ └── 2.1 [DECISION] Choice that depends on the analysis
├── 3. Agreements
│ └── 3.1 [COMMITMENT] Ownership or scope to confirm
└── 4. Synthesis
└── 4.1 [SYNTHESIS] Plan that depends on branches 1–3
Output: sequenced workplan
HOW: How might we raise new-user activation?
├── 1. [Intervention tied to a confirmed cause]
├── 2. [Intervention tied to another confirmed cause]
└── 3. [Intervention family within the stated constraints]
Output: ranked options
```
I would use Why here because the team knows activation is low but has not found the cause. How would fit if the team knew the cause. What would fit if the team needed to produce an activation plan.
## Structural checks cannot prove the tree is true
All three trees use the same MECE rule.
The branches at each level should not overlap. The branches at each level should cover all the important areas. This check helps a PM identify areas that are covered by more than one branch and areas that are not covered at all.
When I face a messy problem, I talk through the context with AI. I use the skill to draft branches, build the tree, and run the MECE checks. I keep the result in chat or copy it into Miro or another visual tool.
## Make the method repeatable
One product manager can make one problem tree by hand. But a team has to do the same work again and again. They must make branches, put them in order, check each level, and draw a clear tree for many different problems.
An AI agent can do these steps over and over. The product manager adds details about the product and decides how to describe the problem, name the main issue, and remove branches that are not needed. When everyone uses the same steps, product leaders and reviewers can understand the work more easily. They can see why the team built the tree that way and check that it covers the whole problem without repeating ideas.
When you face a new problem, first decide what answer you need. Do you need to find the causes, make a work plan, or think of different options? Then choose Why, What, or How to match that goal. Build your first tree. Next, look for one branch that is missing and one branch that repeats another idea before you use the tree.
If a product team wants to use this method again and again, it should not ask every product manager to build the whole process and check all the rules by hand. AI can do that repeated work so the team can spend more time solving the problem.
## Give your team this skill
`mckinsey-issue-tree` is one of the 243 PM skills inside AI PM OS, the shared operating system for product teams. It runs in Claude Code, Cowork or Cursor and is updated at least once every 2 weeks, on version 2.5.
Each PM keeps their own product context while the team shares workflows and review standards, so the issue trees and analytical plans come back grounded in your product, your users, and your real constraints instead of generic PM advice.
You don't have to assemble any of it. AI PM OS wires `mckinsey-issue-tree` into the team operating layer alongside workflows for strategy, research, decisions, stakeholder work, and measurement.
## AI PM OS is $499/year for up to 10 PMs. Full onboarding included.
## 相关链接
- [George from prodmgmt.world](https://x.com/nurijanian)
- [@nurijanian](https://x.com/nurijanian)
- [6.6K](https://x.com/nurijanian/status/2081707189853642988/analytics)
- [AI PM OS is $499/year for up to 10 PMs.](https://prodmgmt.world/x/ambiguous-problem_280726)
- [Upgrade to Premium](https://x.com/i/premium_sign_up)
- [7:44 PM · Jul 27, 2026](https://x.com/nurijanian/status/2081707189853642988)
- [6,619 Views](https://x.com/nurijanian/status/2081707189853642988/analytics)
---
*导出时间: 2026/7/27 23:42:25*
---
## 中文翻译
# /mckinsey-issue-tree: 解决任何问题的树状图
**作者**: George from prodmgmt.world
**日期**: 2026-07-27T11:44:04.000Z
**来源**: [https://x.com/nurijanian/status/2081707189853642988](https://x.com/nurijanian/status/2081707189853642988)
---
许多产品和业务问题在人们开始研究之前就已经出了岔子。这是因为团队没有就他们试图解决的问题达成共识。一个问题可以让人同时思考原因、计划和解决方案。
每个人可能回答的问题都不同。寻找原因、制定计划和选择解决方案是三项不同的工作。当人们把它们混在一起时，可能会忽略重要的事实或做出薄弱的决策。例如，当团队真正需要的是一个计划时，某人却可能在猜测原因。或者团队可能在找出问题原因之前就在讨论修复方案。
研究问题的好方法是遵循三条清晰的路径之一。团队一步一步地提问，并确保没有重复或遗漏。AI 可以帮助进行这些检查。产品经理仍然决定研究什么问题、主要问题是什么，以及团队应该回答哪些问题。
## 解开思想的枝节
1. Why-tree（原因树）用于寻找原因。它的根询问为什么某事正在发生。它的叶子列出可能的原因。最终的输出是一组可验证的假设。
2. What-tree（工作树）用于拆解工作。它的根询问某个交付物需要哪些工作。它的叶子列出分析、决策、承诺、制品或流程。最终的输出是一个正确顺序的计划。
3. How-tree（方案树）用于列出可能的路径。它的根询问团队如何实现选定的目标。它的叶子列出具体的行动。最终的输出是一组经过排序的选项。
使用 Why 寻找原因，What 用于工作单元，How 用于行动。每种叶子类型都支持不同的决策。
## 示例
输入：“我们的新用户激活率表现不佳。我们需要决定该怎么做。”
下图使用占位符表示分支类型，不包含关于真实产品的任何发现。
```text
WHY: Why is new-user activation underperforming?
├── 1. [Candidate cause family A]
├── 2. [Candidate cause family B]
└── 3. [Candidate cause family C]
Output: testable hypotheses
WHAT: What does producing an activation plan require us to unpack?
├── 1. Evidence
│ └── 1.1 [ANALYSIS] Evidence the plan needs
├── 2. Choices
│ └── 2.1 [DECISION] Choice that depends on the analysis
├── 3. Agreements
│ └── 3.1 [COMMITMENT] Ownership or scope to confirm
└── 4. Synthesis
└── 4.1 [SYNTHESIS] Plan that depends on branches 1–3
Output: sequenced workplan
HOW: How might we raise new-user activation?
├── 1. [Intervention tied to a confirmed cause]
├── 2. [Intervention tied to another confirmed cause]
└── 3. [Intervention family within the stated constraints]
Output: ranked options
```
我会在这里使用 Why，因为团队知道激活率很低但尚未找到原因。如果团队知道原因，How 会更合适。如果团队需要制定一个激活计划，What 会更合适。
## 结构检查无法证明树是正确的
这三种树都使用相同的 MECE 规则。
每个级别的分支不应重叠。每个级别的分支应涵盖所有重要领域。这种检查有助于产品经理识别被多个分支覆盖的区域以及完全未被覆盖的区域。
当我面对一个混乱的问题时，我会与 AI 一起梳理背景。我利用这项技能来起草分支、构建树并运行 MECE 检查。我将结果保存在聊天记录中，或者将其复制到 Miro 或其他可视化工具中。
## 让方法可重复
一个产品经理可以手动制作一个问题树。但一个团队必须一次又一次地做同样的工作。他们必须制作分支、对其进行排序、检查每个级别，并为许多不同的问题绘制清晰的树。
AI 智能体可以一遍又一遍地执行这些步骤。产品经理添加有关产品的详细信息，并决定如何描述问题、命名主要问题以及删除不需要的分支。当每个人都使用相同的步骤时，产品负责人和审查者可以更容易地理解这项工作。他们可以看到团队为什么要那样构建树，并检查它是否涵盖了整个问题而没有重复想法。
当你面对一个新问题时，首先决定你需要什么样的答案。你需要找到原因、制定工作计划，还是想出不同的选项？然后选择 Why、What 或 How 来匹配该目标。构建你的第一棵树。接下来，在使用这棵树之前，找出一个缺失的分支和一个重复另一个想法的分支。
如果一个产品团队想要反复使用这种方法，它不应该要求每个产品经理手动构建整个过程并检查所有规则。AI 可以做这些重复性的工作，这样团队就可以花更多时间解决问题。
## 赋予团队这项技能
`mckinsey-issue-tree` 是 AI PM OS 中包含的 243 项 PM 技能之一，这是产品团队的共享操作系统。它在 Claude Code、Cowork 或 Cursor 中运行，版本为 2.5，至少每两周更新一次。
每位 PM 都保留自己的产品背景，而团队共享工作流程和审查标准，因此问题树和分析计划回来时是植根于你的产品、你的用户和你的真实约束，而不是通用的 PM 建议。
你无需组装其中任何部分。AI PM OS 将 `mckinsey-issue-tree` 连接到团队操作层，与战略、研究、决策、利益相关者工作和测量工作流程并列。
AI PM OS 每年 $499，最多支持 10 名 PM。包含完整的入职培训。
## 相关链接
- [George from prodmgmt.world](https://x.com/nurijanian)
- [@nurijanian](https://x.com/nurijanian)
- [6.6K](https://x.com/nurijanian/status/2081707189853642988/analytics)
- [AI PM OS is $499/year for up to 10 PMs.](https://prodmgmt.world/x/ambiguous-problem_280726)
- [Upgrade to Premium](https://x.com/i/premium_sign_up)
- [7:44 PM · Jul 27, 2026](https://x.com/nurijanian/status/2081707189853642988)
- [6,619 Views](https://x.com/nurijanian/status/2081707189853642988/analytics)
---
*导出时间: 2026/7/27 23:42:25*