Building a Research Tree for Complex Questions

Hello! Last lesson, you framed a decision-oriented question and an initial hypothesis that evidence could overturn. Now you need to decide what to investigate. A research tree breaks that broad question into smaller questions, each with a clear purpose and a possible way to answer it.

This is a practical step toward your first company brief: a good tree keeps the work small enough to finish, while making it clear to an interviewer why each chart or finding belongs. Allow about 40 minutes. If you are working in 30-minute sessions, build the tree today and review its leaves in your next session.

From one decision to a map of the research

Return to the hypothetical question from the previous lesson:

Should a research team prioritize Company A over one listed peer for deeper diligence as a potential growth business, considering disclosed growth, operating margins, cash generation, and principal risks?

You cannot answer that question by collecting every fact about both companies. Nor should you treat its four criteria as a checklist whose items all deserve equal space. You need to identify the smaller questions whose answers would change the diligence decision.

An issue tree, used here as a research tree, puts the decision at its root, groups the main questions beneath it, and continues until the questions are specific enough to investigate. The Umbrex illustration shows the basic shape: a core problem, issue areas, and sub-issues with questions and data needs. Its four issue areas are placeholders, not a rule that every problem needs four branches.

In Issue Tree Example – Step-By-Step Approach with Takeaways, CraftingCases constructs a tree for an airline’s rising fuel expenditure. The industry is different, but the method transfers: define the measure precisely, divide it into meaningful components, and stop adding branches when they no longer improve the investigation.

Your company question is partly quantitative, but “which company merits deeper diligence?” is not itself an equation. Its top branches must represent distinct reasons for or against prioritizing a company. Within a branch, a numerical breakdown may help you ask sharper questions.

Build the first level around decision tests

Begin by writing the root question exactly as you intend to answer it. Then ask: What would need to be true for Company A to merit priority over the peer? What could defeat that conclusion?

For this particular decision, a useful first level is:

1. Growth: Does the disclosed record give a stronger reason to investigate Company A’s future growth than the peer’s?
2. Economics: Has Company A’s growth been accompanied by sufficiently strong operating margins and cash generation, relative to the peer?
3. Reasons to withhold priority: Do material risks or limitations in the available evidence make that apparent advantage unreliable?

These are decision tests, not three numbers to add together. The third branch matters: without it, a faster-growing company could win by default even if the disclosures are not comparable or a material risk changes the interpretation. “Stronger” also remains a question, not a finding. You have not collected evidence yet.

A familiar term for testing a tree is MECE: mutually exclusive, collectively exhaustive. At each split, try to avoid asking the same question twice, while covering what is necessary for the decision. This is easiest with an exact accounting breakdown. For a judgment about a business, the standard is more practical: give each analysis one principal home, and check that no important consideration has been omitted. Risks may affect growth and margins; you can note those connections without duplicating the entire analysis in both branches.

Umbrex’s Issue Tree Explained describes the root question, MECE branches, and the move from a branch to a testable analysis. Read the specified portions before refining your own first level.

One caution about ready-made frameworks: “company history,” “competition,” “SWOT,” and “financials” may be useful headings for a general profile, but they are a weak first-level split for this decision. They mix background, a method, and possible evidence. They do not tell you what result would favor Company A or its peer. A research tree is organized by the logic of the question, not by every category of information you might find.

Continue until the leaves are answerable

Now expand each branch by asking what you would have to establish. Keep the same Company A question throughout:

Root: Should Company A or its listed peer be prioritized for deeper diligence as a potential growth business?

1. Growth — Is Company A’s growth case stronger?

• 1.1 How has reported revenue changed for each company over the same disclosed periods?
• 1.2 Which disclosed businesses or segments contributed to that change, where comparable information is available?
• 1.3 What evidence supports or weakens the view that the recent pattern could continue?

2. Economics — Is that growth translating into a stronger business?

• 2.1 How have operating margins changed on comparable definitions?
• 2.2 Has operating cash generation broadly supported reported performance, and are there disclosed reasons for a divergence?

3. Reasons to withhold priority — Could the apparent case be misleading?

• 3.1 Which disclosed risks could materially weaken the growth or economics case?
• 3.2 Are reporting periods, business mixes, or metric definitions so different that the peer comparison needs qualification?
• 3.3 What important information remains unavailable from public sources?

This is one defensible structure, not a universal company-research template. It is deliberately shallow: enough to guide a two-page brief, without opening a separate investigation into every segment, customer group, and competitor.

A leaf is answerable when you can finish the sentence: “To address this, I would examine…” For leaf 2.1, you could examine operating-profit and revenue disclosures for aligned reporting periods, check how each company defines the measure, and present a sourced comparison. For leaf 1.3, you might examine disclosed segment trends and management’s stated outlook—but you must distinguish those observations from a prediction. If a needed segment figure is not disclosed, “not publicly established” may be the honest result.

An answerable leaf also has a decision implication. If Company A’s reported revenue rose faster but its margins weakened while the peer’s improved, leaf 1.1 might favor A and leaf 2.1 might favor the peer. The tree does not force a winner; it shows the trade-off you must explain. If the companies report materially different measures, leaf 3.2 may limit how confidently you can make either comparison.

For numerical questions, you can sometimes make a branch sharper with an identity. For example, where a business reports suitable, consistently defined data, revenue can be considered in terms of customers and revenue per customer. But do not assume those inputs are public, comparable, or meaningful for every business. A mathematically elegant branch that you cannot investigate is less useful for this brief than a modest question you can answer well.

Check the tree before researching

A first draft usually needs one pass for logic and one for feasibility.

Check the logic. Read each child question as a possible way to answer its parent. Does “How has operating cash generation changed?” help assess the economics of growth? Yes. Would “What is the company’s founding story?” normally settle which company merits deeper diligence? Probably not. Keep background only where it explains a decision-relevant finding.

Then look for overlap and gaps. If “poor cash generation” appears under both economics and risks, investigate it under economics and refer to its downside implication when drawing the conclusion. If the tree never asks whether the two companies’ figures are comparable, add that question: otherwise a neat-looking growth chart could rest on mismatched reporting periods.

Check feasibility. For each leaf, identify a plausible public-source test and what you would conclude if the information is absent. You are not gathering all the evidence yet; the next lesson turns the tree into a research plan. For now, a compact review might look like this:

Notice the wording: a finding might weaken, strengthen, or leave unresolved a branch. It need not mechanically settle the whole decision. That is especially important when researching from public materials rather than internal company data.

For a first release, resist the temptation to add a DCF, transaction multiples, a market-size estimate, and a long competitor survey merely because those are valuable skills. They belong when they answer the chosen question at the promised depth. Your later valuation and M&A cases will give those methods a clearer job.

A useful working output is a short Markdown file in the relevant company folder containing the root question, the three first-level branches, their leaves, and one line per leaf describing a plausible test. Mark any leaf “public data uncertain” rather than quietly treating an unavailable metric as known. You should be able to explain the entire structure aloud in about a minute: the decision, the main tests, and what could overturn your initial hypothesis.

Key takeaways

A research tree turns one decision into a small set of distinct questions, then into leaves you can investigate. A good leaf has a plausible test, an honest response to missing evidence, and a reason its answer matters to the decision. Keep the tree specific to your first brief; expand a branch only when doing so would improve the conclusion.

In the next lesson, you will convert these leaves into a research plan: what evidence to seek, where to seek it, which analyses and outputs to produce, and when you have enough to stop.