Structuring problems: issue trees, hypotheses and the workplan

With the problem statement signed, the Meadowlark team faces a blank whiteboard and too many possible questions. Should they start with prices, stores, members, suppliers or staff? Hana suggests they simply begin collecting data and see what it shows. Dr. Mehta stops her. Data does not tell you what to look at, she says. Structure does. If you start without a structure, you will spend six weeks collecting everything and still not know what you think.

This lesson covers three tools that turn a problem statement into a plan: the issue tree, which breaks the question into smaller questions; hypotheses, which state the team's best current guesses at the answers; and the workplan, which assigns the analysis needed to test each hypothesis to people and weeks.

Issue trees

An issue tree breaks a question into parts, and each part into smaller parts, until each branch at the bottom is something the team can investigate directly. There are two common kinds. A diagnostic tree asks why something is happening and breaks the question into possible causes. A solution tree asks how to achieve a goal and breaks it into possible levers. The Meadowlark team draws both, but the solution tree becomes the backbone of the engagement because the problem statement asks what the co-op must do.

The guiding principle for any issue tree is MECE, an acronym from McKinsey that stands for mutually exclusive and collectively exhaustive. Mutually exclusive means the branches do not overlap: no part of the problem is counted twice. Collectively exhaustive means the branches together cover the whole problem: nothing important is left out. A tree that is MECE lets the team divide the work without duplication and gives confidence that no major lever has been missed.

Profit questions have a natural MECE structure because accounting identities guarantee it. Operating profit equals sales times gross margin, minus store costs, minus support costs. Sales can be broken into members times visits times basket, or into stores times sales per store. These arithmetic trees are reliable because the parts must add up to the whole. Trees about people or markets are harder, because categories such as reasons for shopping elsewhere can overlap. Daniel writes a short check that tests both kinds.

# Two checks on an issue tree: do the numeric branches add up, and do the categories overlap?
tree = {  # grocery operating margin, fiscal 2026, millions of dollars
    "Gross margin": 76.32,
    "Store wages": -37.84,
    "Occupancy": -12.72,
    "Other store costs": -11.13,
    "Allocated support costs": -11.13,
}
total = sum(tree.values())
print(f"Branches sum to {total:.2f}; reported operating profit is 3.50 -> {'adds up' if abs(total - 3.50) < 0.005 else 'gap'}")
# Draft hypothesis buckets for 'why do members spend so little with us?' Each item is one reason
# from the interviews, tagged with every bucket a team member put it in.
tags = {
    "prices look high": {"Price", "Value"},
    "no online ordering": {"Convenience"},
    "patronage feels distant": {"Value", "Membership"},
    "limited fresh range": {"Range"},
    "short opening hours": {"Convenience"},
    "do not know they are members": {"Membership"},
    "promotions are confusing": {"Price", "Value"},
}
from collections import Counter
uses = Counter(b for t in tags.values() for b in t)
overlaps = [k for k, t in tags.items() if len(t) > 1]
print("bucket counts:", dict(sorted(uses.items())))
print("items in more than one bucket:", overlaps)

Branches sum to 3.50; reported operating profit is 3.50 -> adds up
bucket counts: {'Convenience': 2, 'Membership': 2, 'Price': 2, 'Range': 1, 'Value': 3}
items in more than one bucket: ['prices look high', 'patronage feels distant', 'promotions are confusing']

The first part confirms that the five cost and margin branches add up to the grocery division's reported operating profit of 3.5 million dollars, so the arithmetic tree is collectively exhaustive. The second part shows the problem with the team's draft tree for why members spend so little. Three reasons from early interviews were placed in two buckets each: prices that look high were tagged as both price and value, for example. The overlaps mean that the buckets are not mutually exclusive. If the team assigned one person to price and another to value, both would study the same evidence and might reach different conclusions. The team redraws the tree with three cleaner buckets: what members pay, what they get in the store, and what they get from membership.

Dr. Mehta adds two cautions. First, MECE is an ideal, not a law; some useful trees are slightly untidy, and forcing perfect categories can waste time. Second, the first level of the tree matters most, because it determines how the team thinks about the problem. A tree that splits grocery profit into prices, costs and stores leads to different work from one that splits it into members, products and places. Teams should draft two or three alternative first levels and choose the one that best matches how the client can act.

Hypothesis-driven work

A hypothesis is a provisional answer to a question, stated so that evidence can confirm or refute it. Hypothesis-driven consulting starts with the team's best guess at the answer and designs the analysis to test it, rather than collecting all available data and hoping an answer emerges. The approach is efficient because it focuses effort on the analyses that would change the team's mind. It is also risky, because a team in love with its first guess may look only for supporting evidence, a tendency psychologists call confirmation bias.

The team agrees on five hypotheses after its first week of interviews and data review, each tied to a branch of the tree:

• H1: shrink, meaning food lost to waste, damage and theft, is the largest single cause of the low gross margin.
• H2: members see Meadowlark's prices as too high, which drives them to discount stores for their main shop.
• H3: a few stores account for most of the division's weak results.
• H4: younger members would shop more with the co-op if they could order online and see the value of membership more often than once a year.
• H5: a larger range of private label products would lift gross margin.

Each hypothesis is written as a statement that could turn out to be false. Sunita's view about discount competition appears as H2; Doug's view about costs is partly H3; Colin's view about younger members is H4. Writing all three into the plan tells the executives that their views will be tested fairly, which helps build trust. H5 comes from the wholesaler, which promotes its private label brand to member co-ops.

For each hypothesis the team asks what evidence would prove it wrong. If shrink at Meadowlark were close to the peer benchmark, H1 would fail. If members rated prices similar to competitors in the survey, H2 would weaken. If losses were spread evenly across stores, H3 would fail. Writing these disconfirming tests in advance is the best defence against confirmation bias, because the team commits to what it will accept before it sees the data.

The day-one answer

Some consulting firms ask teams to write a day-one answer: a one-page summary of what they would recommend if they had to answer on the first day, based only on hypotheses and experience. The purpose is not to commit to that answer but to make the team's thinking explicit so that it can be tested and improved. The Meadowlark team's day-one answer reads: fix shrink and promotions, reshape a few losing stores, and launch a digital membership offer for younger families. Dr. Mehta tells them to keep the page and compare it with the final recommendation; the differences will show what they learned.

Grace raises a fair concern: does a day-one answer bias the team? Dr. Mehta agrees that it can, and suggests two safeguards. Assign one team member each week to argue the case against the current hypotheses. And show the hypotheses to the client early, inviting challenge, so that the managers' knowledge can correct the team's guesses before analysis begins.

The workplan

A workplan turns the tree and hypotheses into tasks. For each hypothesis, it lists the analyses needed to test it, the data sources, the person responsible, the expected output, often a sketch of the chart the team hopes to produce, and the week it is due. Sketching the expected chart before doing the analysis, sometimes called a ghost deck, sounds odd but is useful. It forces the team to decide what an answer would look like and what data would be needed to draw it, which prevents analyses that produce numbers nobody needs.

The team divides the work by hypothesis rather than by analytical technique. Daniel, the plant controller, owns H1 and H3, which depend on store data. Grace owns H2 and H5, where her grocery experience helps. Hana owns H4 and the member survey. Each hypothesis has a deadline before a steering meeting, so the team can report progress. The plan also includes tasks that are not analyses: preparing for steering meetings, writing the storyline and rehearsing.

A good workplan also lists what the team will not analyse. The team considered a full review of supplier terms with the wholesaler but decided against it: the co-op has little power to change them, and Grace's conflict safeguards make the topic awkward. It also decided not to build a detailed model of each department in each store, which would take weeks and add little beyond the store-level view. Choosing what not to do is part of structuring.

At Cedarline, Leo and Owen use a different first level. Their question is about sequencing several plans, so their tree splits it into constraints, namely cash, management time, union commitments and systems capacity, and dependencies between the plans, such as the digital inventory view that the supply chain changes require. Their hypotheses are about order: for example, that the people plan must come before the supply chain changes because the warehouse cannot absorb new processes while turnover is high. The tools are the same; the structure follows the question.

Choosing which analyses to run

Every hypothesis could absorb weeks of analysis, so the team needs a rule for what to do first. Dr. Mehta offers one: run the analyses that could change the decision, in order of how cheaply they can do so. A quick comparison of Meadowlark's shrink with the peer benchmark could confirm or refute H1 in a day, so it comes first. A detailed study of every department's waste by day of week is valuable only if H1 survives, so it comes later. This is the 80/20 principle applied to research: a small share of the analyses usually provides most of the insight.

She also asks the team to estimate, for each planned analysis, what result would make them change course. If no plausible result would change the recommendation, the analysis is interesting but not necessary. Daniel had planned to model the effect of interest rates on the co-op's borrowing costs; when the team realizes that no reasonable rate would change the grocery strategy, the analysis moves to the list of things not to do. Teams that apply this test finish on time; teams that do not often run out of weeks before they reach the analyses that matter.