A B2B software company is deciding whether to enter Market X. The CEO asks, “Should we enter next year, and what could make the launch fail?”
Sales can estimate demand. Finance can model acquisition cost and payback. Product can assess localisation. Legal can review regulation. Operations can examine onboarding and support capacity. If all five teams leave the room with those assignments, they may return with useful work and still have no shared view of which findings should change the decision.
The sequence in this article is designed to prevent that. A Problem Statement fixes the decision boundary. An Issue Tree gives the team a useful partition of the question. MECE tests the quality of that partition. A Driver Tree exposes variables worth prioritising, and a Hypothesis Tree turns uncertainty around those variables into claims that evidence can move. Research starts once the important leaves have become specific, owned questions.

Before You Draw a Tree, Define the Decision
McKinsey’s seven-step problem-solving process places problem definition before decomposition. An open-ended market-entry question can otherwise expand into market size, competition, product, regulation, pricing, channels, staffing and almost anything else that seems relevant.
For Market X, the boundary needs to specify the decision itself, the outcome the company cares about, the time horizon, the customer/product/geographic scope, the criteria that would make entry acceptable, and the baseline alternatives. In this case the baseline could include not entering, delaying entry, or testing with a smaller pilot first. Those fields are a practical synthesis used here for teaching, rather than a universal standard.
Wording matters as well. “How do we successfully enter Market X?” has already removed no-go from the answer space. “Should we enter Market X, and what conditions would need to hold if we do?” leaves entry, delay, narrower scope and no entry available to the evidence.
That is enough definition to begin decomposition. It does not require every assumption to be settled in advance.
The Same Problem Can Have More Than One Useful Cut
An Issue Tree divides the bounded question into pieces that can be investigated, prioritised and eventually owned. There is no need to assume that a single partition is uniquely correct. McKinsey’s problem-solving guidance explicitly recommends trying different logic-tree cuts because each cut can reveal a different aspect of the problem.
For Market X, an economics cut could ask about:
- reachable demand;
- conversion;
- price and contribution margin;
- sales and service cost;
- entry investment and ongoing operating cost.
That tree is useful when the immediate concern is whether the business can work economically.
An execution-readiness cut would organise the same decision around regulatory readiness, product/localisation readiness, channel readiness, sales capacity, and onboarding/support readiness. It is better suited to the question of whether the company can execute within the required timetable even if the economics look attractive.
The choice between those cuts should be made on usefulness. A branch such as “other market factors” does little for research ownership. Splitting the tree into twenty tiny branches also adds little if none of them can change the go/no-go judgement. A good cut creates questions that matter to the decision and can later be assigned without losing the logic that connects them.

Use MECE to Inspect the Cut
Barbara Minto’s familiar MECE formulation is mutually exclusive and collectively exhaustive. Applied carefully, it is a way to inspect a grouping for overlap and obvious omissions within its declared frame.
Consider an execution-readiness level containing “sales capability”, “channel strategy”, “insufficient revenue” and “find a distributor”. Those siblings belong to different logical types: capability, method, outcome and proposed solution. Their labels can be made visually parallel without fixing the underlying structure.
Omission causes a different failure. If product, regulation, sales and support are covered while onboarding capacity is missing, and each new customer requires substantial implementation work, the launch timetable may be wrong even though the tree looks complete.
Four questions are usually enough to expose these problems: are two branches answering the same question; are different logical levels mixed; is an obvious decision-relevant category missing; and what boundary is the claim of completeness being made within?
That last question prevents MECE from being overclaimed. Rittel and Webber’s work on wicked problems and Checkland’s work on soft systems both deal with settings in which the problem boundary or the relevant viewpoint is itself contested. In such cases, completeness depends on which objectives, stakeholders, time periods and system boundaries have been admitted to the analysis.
Turn the Chosen Cut Into Measurable Drivers
A clean Issue Tree still does not tell the team which uncertainty deserves attention first. A Driver Tree connects an outcome to quantities or operating levers that can be measured and compared. Bain’s value-tree examples use the same broad move, linking higher-level results to operational levers so attention can be directed towards what is likely to matter.
For teaching purposes, Market X can be reduced to a deliberately simple relationship:
Expected entry value = reachable customers × conversion × contribution per customer - launch / operating costs
The simplification makes previously loose questions easier to investigate. Market size becomes the number of customers the company can actually reach in the segment it can serve. Channel quality becomes a combination of realistic channel terms, conversion and acquisition cost. Purchase willingness affects conversion, price and contribution per customer rather than living as a yes/no box.
It also creates a basis for prioritisation. If a reasonable range of 8,000 to 10,000 reachable customers barely changes the decision while conversion moving from 2% to 6% flips the economics, the conversion assumption deserves earlier work.
The edges in that tree need to keep their evidence status. Some are arithmetic decompositions. Some describe operating relationships. Others may represent causal mechanisms that the team currently believes. The latter remain hypotheses until independently supported; putting them into a Driver Tree does not establish causality.
Build Working Hypotheses Around the Uncertainty That Matters
A long list of drivers can still produce a long, unfocused research backlog. Hypothesis-driven work gives the team an order of attack by stating a provisional explanation and asking what evidence would alter it. McKinsey’s operating-diagnostics work describes this as putting hypotheses on the table early and then validating, disproving or refining them with evidence.
For Market X, three competing hypotheses cover different failure mechanisms.
H1: Channel economics are the constraint
Assume reachable demand is sufficient, but partner-channel acquisition cost makes entry unattractive. The relevant evidence is partner terms, pilot or benchmark acquisition inputs, conversion assumptions and contribution per customer. H1 weakens if credible partner terms put acquisition cost materially below the current assumption while plausible conversion is preserved.
If H1 is right, partner fees, revenue share or lead costs should absorb too much contribution under otherwise reasonable assumptions. The work therefore concentrates on channel economics rather than collecting more general market-size material.
H2: The timetable is blocked by regulation or localisation
Here demand may be adequate, but approvals, data requirements, product changes or compliance work create a critical path longer than the acceptable launch window. Requirements and credible lead-time estimates are the useful evidence. The hypothesis loses force if the necessary work can run in parallel or reliable lead times are much shorter than expected.
H3: The initial ICP is hiding the viable segment
The aggregate market may look mediocre because materially different customer groups have been averaged together. Segment-level demand, conversion and willingness-to-pay evidence should reveal whether a narrower segment has stronger economics. If sensible segmentation produces no stable difference, this explanation should be downgraded.
These are management working hypotheses. They are not formal null and alternative hypotheses, and this article is not extending into p-values, experimental design or causal-inference methods. Their purpose is operational: make the current belief visible and specify the observation that would cause it to move.
A Leaf Needs a Question, Evidence and an Owner
The bottom of a tree is only a location. It does not make a label executable.
Take a leaf under H1: partner-channel acquisition cost may exceed what contribution economics can absorb. To make that a workstream, the team needs to ask what acquisition cost follows from realistic partner terms and conversion, identify the partner terms, pilot or benchmark acquisition inputs, conversion assumptions and contribution per customer required to answer it, and assign the work to an owner. Growth / GTM plus Finance is one illustrative ownership split.
The decision implication also belongs in the workstream. If the constraint remains binding, the response could be to redesign the channel, narrow the segment, change the economics, delay entry, or choose no-go.
The useful pattern is therefore:
Leaf → Question → Evidence needed → Owner / workstream → Decision implication
A label such as “brand is weak” fails this test. Weak awareness, weak trust, poor channel access and lower sales conversion attributed to brand are different propositions. Until the team states which one it intends to investigate, “research the brand” is an assignment without a stable question.
Know When the Boundary Itself Is the Problem
Trees work best when the team has a sufficiently stable problem frame. They become less reliable when the disagreement is over the frame itself.
Suppose the CEO defines success in Market X as profitability within two years, the strategy team values a regional foothold, and product sees entry primarily as a way to learn about a new industry. Ten additional branches under “Market X success” would place those objectives on the same page without resolving which objective should govern the decision.
The same warning applies when stakeholders reject the scope, when important feedback loops make the boundary highly dynamic, or when the unresolved issue is who has the authority to decide what belongs inside the problem. This is the territory highlighted by wicked-problem and soft-systems literature.
When those signals are present, surfacing the competing success definitions, stakeholder views or system boundary comes before another round of decomposition. A stakeholder or systems method may be needed before the team returns to an Issue Tree.
Stop When the Structure Is Ready for Research
There is no target branch count. A useful stopping test is whether the structure can now be handed to people who know what to investigate and how the result connects back to the decision. The following readiness gate is a practical synthesis used in this article, not a standard issued by a single institution:
- The decision and boundary are explicit, including what currently sits outside the frame.
- The chosen Issue Tree cut produces distinct, decision-relevant research questions.
- Overlap and visible omissions have been checked relative to that boundary.
- Priority drivers are measurable or explicitly marked as hypotheses requiring validation.
- Working hypotheses have evidence requests capable of changing the team’s belief.
- Priority leaves have an owner and a decision implication.
- Any unresolved stakeholder or boundary disagreement remains visible.
Once those conditions hold, another layer of boxes can easily create task volume and false precision without improving the decision. The structure has done its job when the next investigation, its evidence requirement, and the way that evidence could change the decision are already clear.
References
- McKinsey & Company, How to master the seven-step problem-solving process, 2019.
- McKinsey & Company, Barbara Minto: “MECE: I invented it…”, 2018.
- Bain & Company, Reaching Full Potential in Medtech Services, 2018.
- McKinsey & Company, How good are your internal operations—really?, 2022.
- Horst W. J. Rittel & Melvin M. Webber, Dilemmas in a General Theory of Planning, 1973, DOI:
10.1007/BF01405730. - Peter Checkland, Soft Systems Methodology: A Thirty Year Retrospective, 2000, DOI:
10.1002/1099-1743(200011)17:1+<::AID-SRES374>3.0.CO;2-O.