The Iterative Eight Steps for Solving Problems – Step 2: Structuring

1. Why Structure Matters

In today’s fast-paced, data-saturated business world, solving complex problems requires more than intuition and experience.  After carefully framing the problem by clarifying the situation, identifying the complications, and formulating a clear core question, the next critical step is to structure the problem (see Exhibit 1).  This provides a logical framework that enables problem solvers to break down complexity, prioritize efforts, and make their thinking transparent and actionable.

Structuring is the process of organizing a complex problem into smaller, logically related components using systematic approaches, such as logic trees or analytical frameworks, to guide analysis and solution development.

Contrary to what many might assume, structured problem solving does not primarily begin with data or facts.  Instead, it starts with thinking frameworks—mental models that help bring order to ambiguity.  While facts support decisions, without a well-structured approach, they alone cannot lead to insight.  Clear structure enables decision makers to filter out irrelevant information, focus on what matters, and avoid being overwhelmed by the volume of available data.

Imagine an executive facing a sharp decline in profitability.  Without a structured approach, the team might jump straight to surface-level data, such as recent sales figures, headcount costs, or operational KPIs, without knowing where or why to look.  However, a well-structured approach would first break profitability down into its core components, such as revenue drivers, cost levers, and capital efficiency.  Then, it would isolate and prioritize the components most likely to explain the decline.  From there, hypotheses can be formulated and tested, resulting in efficient, targeted analysis.

This practice of “bringing order out of chaos” is an analytical necessity and a communication imperative.  Structured thinking allows leaders to simplify and explain complex problems and solutions to different groups of people, ranging from senior executives to frontline implementers.  Decomposing a problem into manageable parts makes it possible to tell a compelling story that links root causes to action plans and connects analysis to impact.

Furthermore, structure is essential for collaboration.  When solving real-world problems, teams must divide work and align around shared goals.  A common structure, such as a logic tree (see Section 4.1), serves as a roadmap for assigning tasks, sequencing analyses, and integrating findings (Rasiel 1999, pp. 8–13).  Without such a structure, teams risk working at cross-purposes, duplicating effort, or overlooking critical elements of the problem.

Perhaps the most compelling reason why structure matters is that it accelerates insight.  Well-structured problems make it easier to identify patterns, apply relevant experience, and ultimately find elegant solutions.  Just as a gem cutter examines a diamond’s internal geometry before making the first cut, the problem solver must shape the problem space before analyzing data.

Of course, structuring is not without its challenges.  It requires judgment, iteration, and the humility to revise assumptions as new facts emerge.  A rigid or poorly chosen structure can obscure more than it reveals.  However, when applied thoughtfully, structuring provides the intellectual discipline and clarity needed to navigate even the most complex business challenges.

In short, structuring is a fundamental problem-solving skill that transforms uncertainty into direction, complexity into clarity, and insight into impact.  As the following sections will explore, mastering the art of structuring unlocks the full potential of the problem-solving process.

Exhibit 1

2. The Goals of Problem Structuring

Once a problem has been clearly defined—its context understood, its complications identified, and its core question articulated—the next step is to redefine the problem in a solvable way.  The primary aim of structuring is to create a clear and rigorous logic that guides the analysis and decision-making process from start to finish.

Problem structuring plays a crucial role in answering a deceptively simple yet powerful question: “What must we understand or prove to solve this problem effectively?”

The goal of structuring is not just to divide the problem into parts but also to do so in a way that accelerates insight, facilitates execution, and enables better decision making.  A good structure is like a strategic map—it does not solve the problem by itself, but it shows you where to go, what to look at, and how to get there.

2.1 Allowing Decomposition of Complexity

Complex business challenges rarely yield to intuition alone.  They often involve multiple interacting factors—economic, operational, strategic, and cultural—that do not behave in a linear fashion.  Structuring helps decompose this complexity into smaller, more manageable parts that can be examined, understood, and addressed individually.

Decomposition is the process of breaking down a complex problem into smaller, more manageable parts that are logically distinct for systematic analysis.

This decomposition allows for a focused approach.  For instance, if a company is experiencing declining customer retention, breaking down the problem can lead to the identification of sub-issues, such as product relevance, service quality, pricing competitiveness, and customer expectations.  Then, each sub-issue can be prioritized and investigated using targeted methods and data.

2.2 Enabling Prioritization and Focus

Structuring enables decision-makers to distinguish between what is important and what is merely interesting.  Not all aspects of a problem deserve equal attention.  An effective structure enables teams to prioritize high-impact areas, allocate resources accordingly, and avoid over-analysis.

This is especially useful when time and resources are limited, as they often are in real-world business settings.  A structured approach ensures that the team directs its efforts toward elements most likely to yield actionable insights.

Prioritization is the act of ranking the elements of a problem or analysis according to their potential impact or relevance to the overall solution.

2.3 Developing Guidance Based on an Initial Hypothesis and Analysis Planning

Structuring lays the foundation for forming initial hypotheses—tentative answers or potential explanations that can be tested.  These hypotheses direct subsequent phases of problem solving by determining what data to gather, what analyses to perform, and what scenarios to model.

For instance, structuring a profitability issue could result in a hypothesis like this: “Declining profitability is primarily due to rising variable costs in our logistics operations.”  This hypothesis can then be broken down into sub-hypotheses and tested through targeted analyses, such as benchmarking supplier costs, analyzing shipping volumes, or examining fuel price trends.

A hypothesis is a proposed explanation or solution to a problem that can be tested and validated, or rejected, through analysis.

Structuring the problem also facilitates designing the work plan.  Because each element of the problem structure corresponds to a distinct area of inquiry, it becomes easier to assign responsibilities, define outputs, and set deadlines.

2.4 Enhancing Alignment and Communication

A well-structured problem is easier to communicate, both internally within the team and externally to decision makers or clients.  Laying out the problem in a logical sequence clarifies your approach, makes assumptions transparent, and helps stakeholders understand how conclusions were reached.

Whether presenting a recommendation to a board of directors or discussing next steps with a project team, clear structure enables more productive conversations and greater alignment.

2.5 Ensuring Flexibility by Adaptability and Iteration

Finally, structuring creates an evolving framework.  As new facts are uncovered and initial hypotheses are tested, the structure should be revised.  Structuring is an iterative process, not a one-time task.  As new insights emerge, sub-questions may be eliminated, reframed, or expanded upon.  This agility is essential in dynamic and uncertain problem contexts.

Iteration is the process of refining or adjusting a problem structure or analysis plan based on new insights and evidence.

3. Two Core Approaches to Structuring

There is no one-size-fits-all approach to structuring a problem.  The most effective approach depends on the nature of the problem, the available knowledge, and the time constraints.  In practice, two dominant methodologies have emerged:

  • The hypothesis-driven (or, as Bain & Company calls it, “answer first”) approach is when you start with a tentative answer and work backward to test it.
  • The issue-driven approach (or, as Bain & Company calls it, “diagnosis first”) starts with a question and works forward to explore all relevant sub-questions.

Each method has its own advantages and limitations, as well as its own appropriate context (see Exhibit 2).  Becoming proficient in both is essential for becoming a versatile and effective problem solver.

3.1 Hypothesis-Driven Structuring: “Answer First”

Hypothesis-driven structuring is a problem-solving approach that starts with a proposed solution, or hypothesis, and organizes the problem around validating or refining it.

The hypothesis-driven method is widely used in strategy consulting and decision making under pressure.  It is based on the principle that forming an initial hypothesis helps focus the analysis, speed up the work, and anchor the team’s thinking around the most important issues.

In this approach, the initial hypothesis becomes the top node in a logic tree, and a series of sub-hypotheses are derived from it.  These sub-hypotheses are then tested through analysis and data gathering.  Then, the hypothesis is refined iteratively as new information emerges.

While most strategy cases are well suited to a hypothesis-first approach, it only works if the team remains open to revising or rejecting the hypothesis as evidence accumulates.

3.2 Issue-Driven Structuring: “Diagnosis First”

Issue-driven structuring is a problem-solving approach that starts with a core question and breaks it down into smaller sub-questions for exploration and resolution.

The issue-driven method is more thorough and exploratory.  Rather than jumping to conclusions, it breaks the problem down into a hierarchy of questions, which is typically visualized as an issue tree. Each branch is a sub-question that is both mutually exclusive and collectively exhaustive (see Section 4.1.1).  The answers to these sub-questions build toward a comprehensive understanding of the problem.

This method reflects the classical Cartesian principle of starting with a broad question and breaking it down into MECE components (Descartes, 1850).

3.3 Choosing the Right Approach—or Combining Both

Exhibit 2 shows which problem-structuring mode is preferable based on the context of your problem-solving effort.  In real-world problem solving, the choice between hypothesis- and issue-driven structuring is rarely binary.  In fact, hybrid approaches are common and often recommended.

For instance, you could start with a preliminary hypothesis based on limited information and refine it using an issue tree.  Alternatively, you may start with an issue tree and then transition to hypothesis mode once some sub-issues are clear enough to test, particularly when the structure of your problem is uncertain.

The most effective problem solvers ultimately know when to use which approach and how to shift between them.  They balance speed with rigor, direction with openness, and structure with adaptability.

Exhibit 2

4. Structuring Tools: Logic Trees and Frameworks

Effective problem structuring requires more than analytical intent; it requires the right tools.  Two of the most widely used and indispensable tools in structured problem solving are:

  • Logic trees: Visual structures that decompose problems into parts
  • Frameworks: Predefined structures based on experience, theory, or domain expertise

These tools serve distinct but complementary purposes.  Logic trees are custom-built for the problem at hand, while frameworks are often borrowed from prior experience or other disciplines.  Both can—and should—be adapted and combined as the structure evolves.

Logic trees and frameworks are indispensable for bringing clarity, rigor, and shared focus to complex problems.  When used skillfully, they enable structured thinking that accelerates analysis, improves the quality of insights, and drives effective execution.

4.1 Logic Trees: Visualizing the Problem Structure

A logic tree is a visual, hierarchical breakdown of a problem (or hypothesis) into smaller, more manageable components that are organized in a logical, mutually exclusive, and collectively exhaustive (MECE) way.

Logic trees are foundational tools for problem structuring because they allow you to:

  • See all parts of the problem at a glance
  • Ensure coverage and eliminate overlap (using the MECE principle; see Section 4.1.1)
  • Sequence your analysis
  • Assign team responsibilities

4.1.1 Constructing a Logic Tree: The MECE Principle

MECE (mutually exclusive and collectively exhaustive) is a structuring principle that ensures sub-elements (1) do not overlap and (2) cover the entire scope of an issue.

A good logic tree uses MECE at every level:

  • Mutually Exclusive (“no overlaps”):
    Each branch of the tree addresses a unique issue.
  • Collectively Exhaustive (“no gaps”):
    All relevant aspects of the problem are included.

This approach prevents gaps, duplication, and confusion while promoting clear thinking.

For instance, when analyzing cost overruns, a non-MECE breakdown might list “production issues” and “supply chain and production problems” as two separate categories.  A MECE version, however, would categorize costs as distinct, non-overlapping components, such as labor, raw materials, transport, and inventory holding.  If your list requires an “other” category, it is likely not collectively exhaustive.

4.1.2 Types of Logic Trees: Choosing the Right Structure for the Problem

Logic trees are not a one-size-fits-all tool.  The type of tree you build should reflect the nature of the problem, the available information, and your approach to structuring it (whether it is hypothesis- or issue-driven).  Think of the logic tree as a mental model of your problem.  Exhibit 3 shows the most common types of logic trees, each with its own purpose and use case.

Exhibit 3

HYPOTHESIS TREES: “WHAT MUST BE TRUE?”

A hypothesis tree begins with a proposed solution or preliminary recommendation—your initial hypothesis—and breaks it down into sub-hypotheses that must be tested to prove or disprove the main idea.  This deductive reasoning method follows a top-down approach: starting from a central hypothesis, it branches into sub-hypotheses and eventually into more granular assertions.  Each layer specifies the conditions necessary for the layer above it.

This structure is commonly used in time-sensitive business contexts, especially when a plausible answer can be formed early on based on experience, expert opinion, or limited data.  The hypothesis-driven approach helps teams focus their analytical efforts on confirming or refuting specific conditions, thus accelerating insight generation.  For instance, when deciding whether to enter a new market, a team might hypothesize that “Expanding into Market X would be most profitable” (core hypothesis).  The tree would then deconstruct this claim into testable sub-hypotheses, such as “The market opportunity justifies expansion” (S-H 1), “We can build a competitive advantage” (S-H 2), and “The financial model delivers acceptable returns” (S-H 3).  Each of these sub-hypotheses is further broken down into explicit assertions, e.g., “Customers are willing to pay for solutions like ours” (A 1.3) or “Entry costs are within budget limits” (A 3.1).  Exhibit 4 illustrates this breakdown.

Exhibit 4

The interplay between necessary and sufficient conditions is central to the logic of a hypothesis tree.  A necessary condition must be true for the hypothesis to be valid, and its absence invalidates the entire line of reasoning.  In contrast, a sufficient condition guarantees the truth of the hypothesis when confirmed.  Working with a hypothesis tree involves both fact-finding and logic: you must validate the necessary conditions and ensure that, collectively, they are sufficient to validate the hypothesis.

Hypothesis trees work best when the sub-hypotheses are logically independent and collectively exhaustive, an application of the MECE principle.  This ensures that each assertion adds distinct value without redundancy or gaps in logic.

Forming a strong initial hypothesis requires more than creative thinking; it necessitates deliberate judgment.  The team must identify the right core question, consider a range of potential answers, and select the one most consistent with the initial evidence.  A “hypothesis must be falsifiable; this means it must be specific and able to be proved or disproved with data” (Friga 2009, p. 95).  It is often helpful to conduct a “quick and dirty” test (Rasiel & Friga 2002, pp. 22–24) to assess the viability of a hypothesis by asking: “What assumptions must be true for this to hold?”  If any are clearly false, the hypothesis can be eliminated quickly, saving time and resources.

Once the hypothesis tree is established, each branch defines a specific area of analysis.  As evidence is gathered, the assertions are validated, refined, or rejected, and the hypothesis is updated iteratively.  Thus, the hypothesis tree functions as both a planning tool and a dynamic guide for discovery and refinement.

An effective hypothesis-building process involves a structured, iterative approach that “zooms in” from broad, strategic thinking to detailed, data-driven validation.  The process begins at the “100,000-foot level,” where teams form an initial hypothesis based on the framed business problem.  This early phase typically spans one to three weeks and involves gathering high-level information, such as press releases, database searches, and expert interviews, to develop an initial answer to the question, “What decision should the client or senior management make?”  At the “10,000-foot level,” over the next two to eight weeks, the hypothesis is tested through 80/20 calculations, top-down analyses, and targeted data collection, such as sample customer calls or analogous industry reviews.  Logic trees are refined to ensure MECE structure, and assertions are adjusted based on early insights.  Finally, the remainder of the project is spent building a “bulletproof” case at the “1,000-foot level.”  This includes deep data analysis, detailed modeling, scenario testing, and validation of each assertion that supports the hypothesis.  Throughout this process, each assertion must be necessary, sufficient, relevant, specific, and capable of being converted into a persuasive exhibit.  This ensures that the hypothesis is not only logically sound, but also actionable and aligned with the reality of the client or senior management.

ISSUE TREES: “WHAT MUST BE UNDERSTOOD?”

An issue tree starts with an open-ended question and breaks it down into sub-questions that must be answered to address the core issue.  This approach reflects an exploratory, inductive style of reasoning and is especially useful in diagnostic contexts.  This approach is effective when the problem is ambiguous, unfamiliar, or has no clear solution.

The process begins with a broad inquiry, such as “Why is customer churn increasing?” or “Should we expand into Market X?”  Then, it unfolds into a hierarchy of increasingly specific diagnostic questions.  For example, the question of market expansion could be broken down into three second-level questions: “Is the market attractive?” “Can we compete effectively?” and “Is expansion aligned with our strategy?”  Each of these can be broken down further into targeted sub-questions regarding market size, regulatory risks, competitive positioning, operational capacity, and strategic fit (see Exhibit 5).

Like hypothesis trees, issue trees must adhere to the MECE principle to ensure logical clarity.  Each branch should represent a unique area of inquiry, and together, they should comprehensively cover the scope of the problem.  This structure enables teams to conduct focused, parallel investigations while ensuring that no critical dimensions of the problem are overlooked.

The strength of issue trees lies in their openness.  They are not limited by initial assumptions, making them ideal for identifying hidden causes or discovering solutions that were not previously considered.  However, this openness can make them slower and more resource-intensive, especially in time-sensitive projects.  For this reason, issue trees are often used in the early phases of a project or in conjunction with other structures.

Exhibit 5

FACTOR/LEVER TREES: MAPPING THE DRIVERS OF PERFORMANCE

A factor tree, also known as a lever tree, is a logical structure used to model the key variables that influence a specific quantitative outcome, such as profitability, revenue, cost, efficiency, or customer satisfaction.

These trees are especially helpful in quantitative analyses or early brainstorming sessions, as they provide a formula-like breakdown of how performance can be influenced (e.g., Revenue = Price × Volume).  Unlike hypothesis or issue trees, which are often used to test assumptions or explore problem spaces, factor trees reflect inherent mathematical or causal relationships between measurable components of a result.

This type of tree begins with a top-level outcome—for example, “What drives profitability in Market X?”—and decomposes it into the factors that determine the result (see Exhibit 6).  In the case of profitability, the tree might begin with the core formula: Profit = Revenue – Costs.  Each element is then broken down further: revenue into units sold multiplied by price per unit and costs into fixed costs plus variable cost per unit multiplied by units sold.  As a result, the full structure mirrors the logic of a financial equation, offering analytical clarity and strategic insight.

The primary value of a factor tree lies in its ability to support quantitative modeling, scenario analysis, and sensitivity testing.  Each branch represents a lever that can be adjusted to simulate potential outcomes.  For example, one can model the direct impact of reducing variable costs or increasing the average selling price on profitability by asking, “What happens if we lower the price by 10% or reduce fixed costs by 20%?”

Factor trees are useful for performance management, budgeting, pricing strategy, and business case development.  Since they illustrate underlying causal mechanisms, factor trees help teams transition from abstract reasoning to concrete planning.  Furthermore, when constructed correctly, factor trees naturally adhere to the MECE principle.  Each branch represents a distinct input, and together, they fully account for the performance metric in question.

Importantly, factor trees are not limited to financial outcomes.  They can be applied to any quantifiable metric, such as customer acquisition, service response time, or employee engagement, provided that the outcome can be broken down into controllable variables.  By mapping the levers that influence results, factor trees allow teams to identify high-impact interventions, conduct sensitivity analyses, and establish clear lines of accountability.

Factor trees are best suited for situations where the outcome’s structure is well understood, and the objective is to optimize performance or test trade-offs among multiple levers.  Factor trees combine the rigor of a formula with the flexibility of visual structuring, making them indispensable in operational and financial contexts.

Exhibit 6

DECISION TREES: STRUCTURING CHOICES UNDER UNCERTAINTY

A decision tree is a visual model that maps out alternative courses of action, their associated outcomes, and their respective probabilities and consequences, including risks.  Unlike other logic trees, which emphasize decomposition, decision trees emphasize choice, uncertainty, and sequential logic.  These trees are often used in scenario planning, risk assessment, and investment decisions to help visualize the consequences of various strategic paths and identify the best course of action under uncertainty.

A decision tree’s structure consists of three key components: decision nodes, which represent points of choice; chance nodes, which represent uncertain outcomes; and payoff nodes, which show the consequences of each outcome.  Starting from a central decision—for example, “Should we expand into Market X?”—the tree branches into multiple paths, depending on the available options, as Exhibit 7 shows.  Each branch then unfolds to include possible scenarios (e.g., high demand versus low demand), along with estimated probabilities and financial implications, such as net present value (NPV) or return on investment (ROI).

This method allows decision-makers to visualize the outcomes, risks, trade-offs, and opportunity costs of each option.  It enables the direct incorporation of uncertainty into the decision-making process, which other tree types do not do.  Furthermore, teams can compare the expected value of different paths by assigning numerical values to outcomes and applying probability-weighted averaging.  This allows them to choose the most advantageous course of action.

Decision trees are especially helpful when decisions must be staged, or learning occurs over time.  For example, a company may choose to test a new market, observe the results, and then decide whether to expand.  In such cases, decision trees model the initial choices and subsequent adaptive strategies, ensuring the full scope of consequences is considered.

One of the strengths of decision trees is their clarity of communication.  They make complex, multi-stage decisions understandable to a broad range of stakeholders by showing the available decisions and potential outcomes depending on external factors.  However, they also have limitations.  They can become unwieldy if too many branches or variables are included, and they require reasonably accurate probability and outcome estimations to be effective.

In practice, decision trees are often used with other types of trees.  For instance, a team might use an issue tree to explore the risks of market expansion, a hypothesis tree to test the viability of a specific entry model, and a decision tree to weigh the financial implications of each strategic option.  Thus, decision trees serve as the final step in structured problem solving, transforming insights into choice architecture.

TREE SELECTION

Each type of logic tree—whether it is hypothesis-based, question-based, formula-based, or decision-based—offers a different way of analyzing a problem.  Hypothesis trees test assumptions; issue trees explore unknowns; factor trees quantify drivers; and decision trees chart strategic alternatives.  A comparison of these four issue trees reveals that they cover different perspectives and have different purposes.  They are geared to answer the following questions:

  • A hypothesis tree asks, “What must be true for the hypothesis to hold?”  Therefore, use a hypothesis tree to validate the assumptions behind the “yes” path.
  • An issue tree asks, “What do we need to understand to decide?” Therefore, use an issue tree to structure what must be understood before deciding.
  • A factor/lever tree asks, “What specific variables drive the result?” This allows us to quantify the financials at each outcome branch using the factor tree.
  • A decision tree asks, “What should we do depending on what happens?” This makes the decision tree useful for comparing scenarios and structuring final recommendations.

4.1.3 Reasoning Styles in Structuring: Inductive vs. Deductive Thinking

Although logic trees are usually classified by their structure (e.g., hypothesis, issue, factor/lever, or decision trees), the way we create and interpret them often depends on our underlying reasoning style, which can be either inductive or deductive.

Deductive reasoning moves from the general to the specific.  It begins with a known hypothesis, theory, or formula and breaks it down into testable parts or logical consequences.  This approach is common in hypothesis trees and in any tree that tests a rule-based structure, such as in finance or engineering.

Example: “If poor service is causing churn, then we should see declining satisfaction scores in support-related touchpoints.”

This mode of reasoning reflects the typical approach of developing issue trees from left to right, or from top to bottom.

Inductive reasoning moves from the specific to the general.  It begins with observations, patterns, or user feedback and builds upward to a broader insight or hypothesis.  This approach is common in early-stage issue trees, customer journey maps, and when problems are structured without a clear starting hypothesis.  This mode of reasoning is used when much is known about the logical structure of a problem, especially when the framing problem is inherently mathematical.  Inductively, it is common to build logic trees from right to left, i.e., from lower to higher hierarchical levels.

Example: “After hearing from several customers who complained about onboarding delays, we suspect that onboarding is a key driver of churn.”

Inductive and deductive thinking are not types of logic trees; they are modes of reasoning that can be applied to various types of issue trees.  Skilled problem solvers switch between these modes as they explore causes, test ideas, and refine structure.

Exhibit 7

4.2 Frameworks: Applying Existing Structures

A framework is a reusable analytical structure, often drawn from functional areas such as strategy, finance, or operations, that helps organize thoughts about recurring problems.

Frameworks are a powerful shortcut in structuring because they reflect accumulated knowledge (see Exhibit 8 for several examples of well-known frameworks).  Rather than starting from scratch, you apply a proven structure to your current problem and adapt it as needed.

Frameworks are especially useful in:

  • Structuring early-stage problem trees
  • Benchmarking known success factors
  • Supporting communication by referencing familiar models

However, frameworks must be used judiciously.  Overreliance on a favorite framework can lead to the “wrong framework” pitfall of seeing all problems through the same lens (see Section 6.3).

You must also be aware of the underlying assumptions of the frameworks you use.  Since frameworks are decompositions of particular generic problems, it is important not to use them to solve different problems or in contexts for which they are not designed.  If a framework does not fit well with the core question, do not force it.  Adapt or discard it instead.

Frameworks are mental representations of reality and changing them is justified when reality changes.  An effective problem solver not only masters a broad range of frameworks across various domains but also excels at combining these frameworks (and those contributed by other team members) into an integrative problem structure.  To solve large, complex problems, you need frameworks as building blocks and the ability to assemble them.

4.3 Combining Logic Trees and Frameworks

In practice, logic trees and frameworks are often used together.  A framework might be used to define the first-level branches of a logic tree, while the deeper levels are customized through analysis and experience.

For example, in structuring a revenue problem:

  • The top-level branches could follow a profitability framework
    (e.g., Profit = Price × Volume).
  • The next level could use industry-specific drivers (e.g., channel mix, customer churn, discounting).

For instance, Porter’s (1980) Five Forces could be employed to challenge the assertion “Industry structure allows for attractive average margins” (A 1.4) supporting the sub-hypothesis “The market opportunity in Market X justifies expansion” (S-H 1) in the hypothesis tree example in Exhibit 4.  Or the Red vs. Blue Ocean concept (Kim & Mauborgne 2004a; 2004b) could be applied to guide analyses to check on the assertion “We have a clear source of differentiation (e.g., brand, tech, cost)” (A 2.2) supporting the sub-hypothesis “We can establish and sustain a competitive advantage” (S-H 2) in the hypothesis tree example in Exhibit 4.  Moreover, the strategy framework PESTEL could be used to monitor and analyze the macro-environmental Political, Economic, Social, Technological, Environmental, and Legal factors on the respective assertions supporting the sub-hypothesis “The risk profile is acceptable and manageable” (S-H 4) in the same hypothesis tree example in Exhibit 4.

This blending of generic structure with problem-specific logic is what makes structuring both a science and an art.

4.4 Structuring for Execution and Teamwork

Problem structuring is not just an intellectual exercise; it is also a practical tool that provides a blueprint for action and drives execution.  Once a logic tree or framework is built, it becomes the operational backbone of a project.  Each branch of the structure represents a specific area of inquiry, a potential workstream, or an analysis.  When used effectively, structure enables teams to work in parallel, avoid duplication, and maintain alignment around a shared objective.

In real-world problem solving, especially in collaborative or time-constrained environments, the value of clear structure increases.  It enables distributed teams to divide and conquer the analytical workload while maintaining coherence in their approach.  When each team member understands how their work contributes to the overall structure, coordination improves, communication becomes more focused, and the integration of insights becomes seamless.

4.4.1 Structure as a Blueprint for Work

Once constructed, a logic tree can be directly translated into a project blueprint.  Each top-level branch represents a major workstream, while the sub-branches indicate specific analyses, research questions, or decision points.  This provides immediate clarity about:

  • “Who is responsible for what?”
  • “What outputs are needed from each branch?”
  • “Which branches must be tackled sequentially, and which can proceed in parallel.”

For instance, if a customer retention problem is broken down into three main causes—product, service, and pricing—three workstreams can be created, each aligned with one of these factors.  Sub-teams or individuals can then be assigned to each workstream, guided by the hypotheses or questions embedded in the structure.  This approach transforms the logic tree into a practical project planning tool.  It supports the creation of timelines, resource plans, and deliverable lists that are logically sound and manageable.

The practical function of this structure will be discussed in more detail in the later elucidations on Planning the Work of the Iterative Eight Steps for solving problems.

4.4.2 Coordination Through Common Structure

A shared structure enables better teamwork in several important ways:

  • Avoiding duplication or blind spots:
    When each team knows which part of the tree they are addressing, redundant analyses are minimized, and gaps are more easily spotted.
  • Aligning more easily on priorities:
    The structure clarifies which branches are most critical. If certain hypotheses are prioritized, workstreams can be weighted accordingly, ensuring that team effort is directed toward the most impactful areas.
  • Facilitating integration:
    Since all work is organized around the same core logic, integrating findings becomes straightforward. Each team contributes pieces of the puzzle that fit naturally into a coherent story.
  • Communicate more effectively with stakeholders:
    A shared structure provides a clear narrative backbone that allows teams to present their reasoning and recommendations in a way that is logically sequenced, visually accessible, and relevant to decision making. This approach resonates with diverse stakeholders.
  • Enabling flexibility:
    As insights emerge, the structure can evolve, and teams can adjust their focus in a coordinated way. When a branch proves irrelevant, it can be dropped. When a new question arises, it can be incorporated without disrupting the broader architecture.

4.4.3 From a Thinking Tool to a Management Tool

In this way, structure serves as a tool for both thinking and management.  It breaks down complexity for the sake of understanding and serves as a roadmap for organizing team activity.  Instead of relying on ad hoc planning or loosely connected analyses, the team works from a shared, visible framework that connects every effort to the core question.

Thus, structuring becomes central to collaborative execution.  It empowers teams to move faster, think more clearly, and deliver more persuasive results precisely because everyone is working from the same blueprint.

Exhibit 8

5. Structuring in Practice: From Core Question to Execution

Effective structuring is not just an intellectual exercise; it is a disciplined approach to action.  It guides how teams plan, analyze, prioritize, and communicate.  Logic trees and frameworks provide the blueprint, but problem solvers must know how to apply them effectively, especially in dynamic business contexts involving incomplete information, time constraints, and diverse stakeholders.  Starting with a clear core question, building a simple initial structure, and iterating toward depth and clarity helps problem solvers stay focused, flexible, and aligned throughout the process.

This section outlines how to apply structured thinking to real-world contexts.  It begins with a precise core question developed during the Framing the Problem step, progresses through iterative thinking, and comes to life through execution and communication.  Through iterative refinement, prioritization, and collaboration, the question evolves into a clear, actionable problem structure that guides the team’s work and adapts throughout the problem-solving process.  When applied with clarity and flexibility, structuring transforms uncertainty into direction and thoughtful questions into impactful answers.

5.1 Start with the Core Question

Every structured problem-solving effort begins with a well-defined core question.  This question defines the purpose of the analysis and serves as the foundation for all subsequent work.  It emerges from the Framing the Problem step, which clarifies the situation, identifies complications, and articulates a clear objective.

Effective core questions often take the form of:

  • “Why is [undesirable outcome] happening, and how can we address it?”
  • “What must be true for us to pursue [strategic option]?”
  • “How can we achieve the desired outcome despite the specific constraints?”

For example, a core question might be: “Why has customer retention dropped by 15% over the past six months, and how can we reverse the trend?”  From there, the team can begin building a logical, testable structure to guide their investigation.

5.2 Build a First-Cut Structure (Tree or Framework)

Once the core question is clear, the next step is to develop a preliminary structure.

This is an initial version of a logic tree or analytical framework that breaks the question down into manageable parts to organize early thinking and analysis priorities.

Depending on the context and the team’s confidence in a potential answer, this may be:

  • A hypothesis tree is built if a plausible answer exists. For example, “Retention is dropping due to lower service quality” could be the top node, which would then be broken down into sub-hypotheses (e.g., “Response times have slowed,” “Staffing levels have dropped,” etc.).
  • An issue tree is used when the problem is less defined. In this case, the team decomposes the question into mutually exclusive sub-questions (e.g., “Is the problem product-related, pricing-related, or service-related?”).

At this stage, simplicity is critical.  The goal is to create a structure that provides direction, not perfection.  Ideally, early trees should have 2–4 top-level branches.  The tree can and should be refined and expanded as the analysis progresses.

5.3 Iterate and Refine

No structure is perfect the first time around.  As the team collects data, conducts interviews, runs analyses, and has discussions, the structure must evolve.  This iterative refinement process ensures the structure remains aligned with reality and continues to guide meaningful work.  Iteration involves three key activities:

  • Pruning: Removing sub-branches that prove irrelevant, untestable, or low in impact
  • Deepening: Expanding high-potential branches with more granular levels of analysis
  • Reshaping: Revising the logic, hierarchy, and flow to reflect updated thinking and new insights to improve clarity and MECE compliance

Iteration is not a sign of error; it is a hallmark of rigor.  The best structures respond to feedback, new information, and shifting priorities.

One practical technique for guiding this evolution is the “zoom-in” model, which progresses from high-level to detailed analysis:

  • At “100,000 feet,” the team forms an initial hypothesis or working structure based on business judgment and limited data.
  • At “10,000 feet,” the team begins testing sub-hypotheses through early analyses and interviews, revealing areas for deeper investigation.
  • Finally, at “1,000 feet,” detailed modeling, sensitivity testing, and robust data gathering either validate or challenge the key assertions in the structure.

5.4 Prioritize What to Solve First

Not all parts of the structure are equally valuable.  Once the tree is in place, apply prioritization filters to focus the team’s efforts where they matter most.  This is where prioritization transforms structure into strategy.

Common criteria for prioritizing include:

  • Anticipated impact: “Which issues have the greatest influence on the outcome?”
  • Feasibility: “Which issues can be addressed with the available data and resources?”
  • Speed: “Where can insight be gained quickly?”

The 80/20 rule, also known as the Pareto principle, is a common prioritization principle that states roughly 80 percent of results come from 20 percent of the causes.

This principle is particularly useful here.  Teams should focus on the 20 percent of issues that will drive 80 percent of the solution.  Highlighting and deepening one or two driver branches allows for a sharper focus and more efficient use of time.  This step ensures that analytical effort is spent efficiently, a topic that will be discussed in more detail in the elucidations on the third step, Prioritizing, of the Iterative Eight Steps for solving problems.

5.5 Assign Workstreams Based on the Structure

Once priorities are established, they can be translated into concrete workstreams.  Each major branch can then be translated into a workstream—a distinct line of analysis, research, or data collection with clear ownership, timelines, and deliverables.

For instance, if the retention problem is divided into product, service, and pricing, one team member or sub-team could be assigned to each category.   Weekly synthesis meetings ensure that findings remain integrated and that the overall story continues to align with the core question.

This approach enables parallel progress and improves collaboration by aligning each team member’s efforts with a shared structure.  This has several benefits:

  • It makes responsibilities clear.
  • It enables parallel progress.
  • It reduces overlap and duplication.
  • It creates a natural template for integrating results later.

This aspect will be discussed in more detail in the elucidations on the fourth step, Planning the Work, of the Iterative Eight Steps for solving problems.

5.6 Use Structure to Communicate

A well-built structure is more than just a tool for analysis; it becomes the backbone of your storyline.  It shows stakeholders how the issue was understood, how priorities were chosen, and how the solution was reached.  Whether presenting to your team, a client, or senior management, the problem structure allows you to:

  • Explain what was examined and why
  • Show how hypotheses or questions were tested
  • Connect findings directly to the original problem and core question

Sharing the structure as a visual tree, slide outline, or analytical map helps align stakeholders with the project’s logic throughout its duration.  This approach demonstrates transparency, builds trust, and clarifies why certain analyses were pursued while others were not.  Furthermore, this approach reinforces credibility, ensuring that conclusions are perceived as rigorous and relevant.  In final presentations, the structure serves as the framework for the story.  Each insight is linked to a branch of the tree, and each recommendation is supported by tested logic.  Even in the early phases of a project, sharing the structure as a visual tree or outline helps stakeholders agree on the approach and establishes credibility from the beginning.

6. Common Pitfalls in Structuring—and How to Avoid Them

Although structured problem solving is a powerful approach for navigating complexity, it is not without its pitfalls.  Even the most experienced practitioners can fall into traps that undermine the clarity, objectivity, or practical value of their approach.  These pitfalls often emerge not from a lack of effort, but rather from cognitive bias, misapplied tools, or overconfidence in initial assumptions.  These pitfalls can lead to wasted time, flawed conclusions, or missed opportunities, especially when a structure is hastily or reflexively built.

Recognizing these risks is crucial not only to avoid mistakes but also to cultivate a disciplined and critical mindset when structuring problems.  An effective problem structure is logical, practical, aligned, and flexible.

This section outlines the most frequent pitfalls encountered when building logic trees and problem structures, along with guidance on how to recognize and avoid them.  Recognizing these patterns ensures that your efforts remain methodologically sound, contextually relevant, and decision-focused.  Understanding and actively avoiding these pitfalls significantly improves your chances of crafting a valuable structure.

6.1 Confirmation Bias: The Hidden Distorter of Structured Thinking

Confirmation bias, the tendency to favor information that supports pre-existing beliefs while ignoring or downplaying contradictory evidence, is one of the most pervasive and insidious cognitive pitfalls in structured problem solving.  This bias often operates unconsciously, shaping the way analysts form hypotheses, interpret data, and draw conclusions.  In structured approaches, such as hypothesis trees, confirmation bias can undermine the integrity of the entire structure.

When teams adopt a hypothesis-driven approach, they start by proposing a solution and then trying to validate it.  While this can accelerate analysis, it also creates fertile ground for selective attention.  Teams may unintentionally design their logic trees to test only the most favorable conditions or misinterpret ambiguous data as supporting evidence.  In some cases, disconfirming facts are dismissed as outliers or anomalies rather than being treated as legitimate signals.

The danger lies in the illusion of rigor.  The structure may appear logical and MECE, the analyses may be sophisticated, and the exhibits may be persuasive, yet the underlying reasoning may be flawed.  If the hypothesis is flawed but never seriously challenged, the final recommendation may be confident yet incorrect.

Avoiding confirmation bias requires deliberate effort.  One effective safeguard is to formulate alternative hypotheses with the same discipline as the leading hypothesis and actively consider them.  Encouraging devil’s advocacy within the team, where individuals challenge prevailing assumptions, can expose weak spots in logic.  It is also critical to engage with clients or stakeholders early on, not only to validate the hypothesis, but also to test how well it resonates with their experience and institutional knowledge.

A simple yet powerful test is to ask, “What evidence would disprove our hypothesis?”  If the answer is unclear, or if such evidence has not been sought with equal rigor, then confirmation bias may already be at work.

In structured problem solving, intellectual honesty is as important as analytical precision.  Recognizing and counteracting confirmation bias is essential for the credibility of the process and the quality and impact of the resulting decisions.

6.2 Narrow Framing: Defining the Problem Too Tightly

Narrow framing occurs when a problem is defined from an overly restricted perspective based on initial assumptions, organizational habits, or stakeholder expectations.  Rather than viewing the problem in all its strategic, operational, and contextual complexity, the analysis begins within predetermined conceptual boundaries, often excluding critical dimensions that deserve attention.

This pitfall often arises under time pressure or when decision makers prematurely push for immediate solutions.  For instance, a decline in customer retention could be viewed solely as a marketing issue, overlooking deeper causes, such as service breakdowns, product fit, or internal operational failures.  Structures built on narrowly framed questions may appear logically sound and internally consistent but risk producing incomplete diagnoses and suboptimal solutions.

To counteract narrow framing, problem solvers must regularly revisit the Framing the Problem step during the structuring process.  It is essential to explore alternative ways of asking the core question and consider multiple angles before settling on a structure.  This is especially important in ambiguous or high-stakes environments where the true causes of the problem may not be obvious.

Open-ended questioning, stakeholder interviews, and issue-driven structures are effective tools for guarding against premature narrowing.  Above all, teams must cultivate the discipline to pause, reframe, and ask, “Are we looking at the full picture—or just the part we’re most familiar with?”

Broadening the frame does not mean overcomplicating the analysis.  Rather, it ensures that the structure reflects the real complexity of the problem, not just its most visible symptoms.

6.3 The Wrong Framework Pitfall: When Familiar Tools Mislead

Frameworks are powerful tools for structured problem solving.  Based on accumulated experience, they offer reusable mental models that can bring clarity to complex situations.  However, their effectiveness depends entirely on contextual fit.  One common pitfall is applying a familiar or preferred framework to a problem it was never designed to solve.

This mistake often stems from disciplinary bias.  For example, a finance leader might default to a return-on-investment model, and a marketer might use a customer journey map, even when these tools fail to capture the real dynamics of the problem.  The comfort of the familiar can overshadow the necessity of appropriateness, resulting in structures that seem rigorous but are misaligned with the actual drivers of the issue.  Using an ill-fitting framework introduces two major risks: it distorts the decomposition of the problem and embeds flawed assumptions into the analysis from the outset.  For example, using Porter’s Five Forces to analyze an internal efficiency problem could result in a clean yet irrelevant structure.

To avoid this pitfall, problem solvers must critically assess the underlying assumptions and boundaries of any framework they consider.  A useful test is to ask, “Does this framework match the nature of the question we are trying to answer?”  If the answer is “no”—or only partially—then the framework should be adapted or replaced.

Skilled practitioners typically start with generic or familiar structures, modifying them to reflect the specific logic of the problem at hand.  In more complex cases, combining multiple frameworks (e.g., industry-specific and functional) can result in a more accurate and nuanced structure.

In short, frameworks should be treated as starting points, not prescriptions.  The most effective solutions are shaped by the needs of the problem, not the habits of the solver.

6.4 Lack of MECE: Overlaps, Gaps, and Logical Weakness

One of the most fundamental principles of structured problem solving is the MECE rule: mutually exclusive and collectively exhaustive.  A structure is MECE when each branch of a logic tree addresses a distinct issue with no overlap and when, together, the branches fully capture the problem space with no gaps.  Violating this principle often results in an analysis that is confusing, redundant, and incomplete.

A lack of mutual exclusivity typically manifests as overlapping categories that blur the boundaries between issues.  For instance, categorizing “customer service” and “customer experience” as separate branches without clear definitions may result in duplicated work or unclear accountability.  Conversely, a lack of collective exhaustiveness occurs when important components of the problem are omitted altogether.  This is often signaled by the presence of an “other” category—a red flag that the decomposition is incomplete.

The consequences of a non-MECE structure are subtle yet significant.  It can lead to the misallocation of resources, unproductive debates over ambiguous terms, and analytical blind spots that skew recommendations.  Even when the underlying data is accurate, flawed structuring logic can undermine the credibility and impact of the findings.

Avoiding this pitfall requires rigorous discipline when building the tree.  When building a logic tree, ask yourself three key questions about each level:

  • “Are the categories clearly defined and logically distinct?”
  • “Do they together fully cover the core question?”
  • “Would any stakeholder reasonably disagree about where something belongs?”

Peer reviews and structured critique sessions can help identify non-MECE groupings before they lead to analytical errors.  In practice, many logic trees evolve toward MECE compliance through iteration.  As understanding deepens, overlapping or vague categories are refined, and missing elements are added.

Ultimately, a MECE structure is more than just a formal exercise in neatness.  It is a foundation for clear thinking, efficient teamwork, and sound decision making.

6.5 Mistaking Correlation for Causation: A Logical Misstep

A frequent and often misleading error in problem structuring is assuming that correlation implies causation.  This occurs when two variables are observed to move together, and one is prematurely assumed to cause the other without adequate evidence or logical reasoning to support the claim.

In structured analysis, especially when using hypothesis trees, this error can compromise the validity of entire branches.  For example, a team might observe a decline in customer satisfaction scores alongside a drop in revenue and conclude that satisfaction is the root cause of the revenue loss.  While this may be true, correlation alone does not establish causation.  For example, both could be driven by a third factor, such as a product quality issue or a competitor’s new offering.

Mistaking correlation for causation often results from the desire to confirm a compelling narrative, especially when early patterns appear to align with the working hypothesis.  This tendency is amplified when time is limited or when data availability drives the analysis more than strategic logic.

To avoid this error, problem solvers must apply a higher standard of proof when asserting causal links.  This includes identifying plausible mechanisms and exploring alternative explanations.  Where possible, they should also conduct controlled comparisons or temporal analyses to assess directionality and influence.

A useful rule of thumb is to ask, “Why would one factor cause the other, and how do we know that’s what’s happening?”  If the mechanism is unclear or the evidence is weak, the relationship should be treated as a hypothesis to be tested rather than a fact to be acted upon.

Maintaining this discipline ensures that structured problem-solving remains rooted in logic, observation, and analytical integrity.  A compelling story is not enough; it must withstand causal scrutiny.

6.6 Over-Structuring and Analysis Paralysis: When Rigor Becomes Rigidity

Structure is meant to enable insight, not inhibit it.  Yet, one of the most counterproductive tendencies in structured problem solving is over-structuring.  This occurs when the pursuit of a perfect logic tree or framework becomes an end in itself.  This often leads to analysis paralysis, a state in which teams spend excessive time refining their structure instead of advancing the analysis or generating actionable insights.

The impulse to over-structure usually stems from a desire for completeness, precision, or perceived rigor.  Teams may feel compelled to anticipate every possible sub-issue or analytical path before beginning any real investigation.  As a result, progress stalls, decisions are delayed, and energy is consumed by abstract refinement rather than practical movement.

While structural soundness is important, it must be balanced with a bias for action.  Early in a project, a rough first-cut logic tree is often more useful than a polished, over-engineered structure.  Iteration is the natural mode of structured problem-solving; the tree should evolve in response to new data, emerging insights, and shifting priorities.  Waiting for the “perfect” structure is unrealistic and undermines the agility needed in most business contexts.

To avoid analysis paralysis, teams should adopt a pragmatic mindset.  They should aim for clarity, not perfection, and seek early momentum rather than structural elegance.  One practical approach is to apply the 80/20 principle by focusing first on the top 20 percent of issue areas that are likely to yield 80 percent of the insight.  Subsequent refinements can then be guided by real learning rather than theoretical design.

Ultimately, a structure’s value lies not in its complexity but in its ability to focus thinking, enable collaboration, and guide decisions.  A structure that is used, tested, and adapted is far more valuable than one that remains pristine but is never implemented.

6.7 Stakeholder Exclusion and Miscommunication: Structuring in Isolation

Even the most logically sound problem structure can fall short if developed in isolation from key stakeholders.  One of the most common—and costly—mistakes in structured problem solving is treating structuring as an internal exercise owned solely by the analytical team without sufficient engagement from people who understand the context, have decision-making authority, or will be affected by the outcomes.

This pitfall typically manifests in two ways.  First, excluding stakeholders during the early stages of structuring can lead to misalignment between the structure and the organization’s actual priorities, constraints, or mental models.  Teams may build logic trees based on inaccurate assumptions, outdated views, or an incomplete understanding of the real drivers behind a problem.  Second, even when the structure is well-designed, poor communication about its logic, intent, or conclusions can result in stakeholder confusion, resistance, or a lack of buy-in.

Both of these dynamics can derail an otherwise solid problem-solving effort.  Stakeholders may reject recommendations not because they disagree with the logic but because they feel disconnected from it—or worse, blindsided by it.  In complex organizations, influence and insight are often distributed.  Excluding these perspectives can lead to overlooking critical information and losing support when it matters most.

To avoid this problem, the process of problem structuring must be treated as collaborative and communicative.  While not every stakeholder needs to be involved in every step, relevant parties—including senior sponsors, frontline implementers, and subject matter experts—should be engaged at key moments.  Validating framing, hypotheses, and assumptions early on can prevent the need for major revisions later.  Similarly, sharing evolving structures, such as logic trees, issue maps, or high-level outlines, builds transparency and alignment.

In addition, structured communication is essential.  Problem solvers must not assume that the logic of their structure is self-evident.  They must explain how the problem was broken down, why certain branches were prioritized, and what the structure implies about next steps.  A visual tree can be a powerful tool for guiding discussions, but only if accompanied by a clear narrative that resonates with the audience.

Ultimately, structuring is not just an analytical exercise; it is a vehicle for collective reasoning and shared ownership.  The more inclusive and well-communicated the structure, the more likely it is to drive meaningful action and sustained impact.

7. Integrating Design Thinking into Structured Problem Solving

Structured problem solving, which is grounded in logic trees, hypotheses, and frameworks, is a proven methodology for overcoming complex analytical challenges.  However, it has its limitations, particularly when applied to ambiguous, emotionally charged, or human-centered problems, such as innovation, customer experience, and organizational culture.  In these situations, rigid structures can constrain exploration prematurely or overlook the subtleties of human experience.  This is where design thinking offers a valuable complement.

Design thinking is an approach to problem solving rooted in empathy, creativity, and iterative exploration.  Although design thinking is often associated with innovation, user experience, and product development, its principles are increasingly relevant to business problems where structure alone may fall short.  Integrating design thinking into structured analysis enables teams to expand the scope of the problem before narrowing it, ensuring that solutions are analytically sound, desirable, feasible, and contextually grounded.

7.1 When Classical Structuring Falls Short

Traditional, structured approaches, such as hypothesis- or issue-driven methods, assume certain preconditions, including a clearly defined problem, access to reliable data or prior knowledge, and alignment among stakeholders.  However, these assumptions do not always hold, especially when addressing challenges related to human behavior, organizational culture, or innovation.  For example, when launching a product in a new market or improving employee engagement in a hybrid work environment, logic trees may overlook the emotional or experiential aspects of the issue.

Consider the example of declining employee morale.  A classically structured approach might frame the problem in terms of workload, compensation, or leadership—categories that are logical but potentially superficial.  Without first exploring how employees experience their work, the structure may overlook underlying factors such as a lack of autonomy, recognition, or sense of belonging.

In such situations, the structure can become too narrow too early, locking teams into a limited view of the problem and filtering out insights that do not fit the initial framework.

7.2 When to Introduce Design Thinking

Design thinking is particularly useful when:

  • Problems are ill-defined, ambiguous, emotional, controversial, or complexly human.
  • Innovation or experience design is central.
  • “Classical” structures fail to yield new insights.

Examples of such contexts include customer experience design, digital product innovation, cultural transformation, and any problem where traditional data may be insufficient or misleading.

In these cases, design thinking provides an alternative entry point.  Rather than beginning with hypotheses or frameworks, it starts with empathy.  Through interviews, observation, journey mapping, and immersive research, teams develop a deeper understanding of the people involved and the nuances of their experiences.  These insights can then inform or reshape the structured analysis that follows.

This empathic inquiry serves as a diagnostic tool and a source of reframing.  It enables teams to view the problem differently, sometimes yielding unexpected insights that would not emerge from structured decomposition alone.

7.3 How the Approaches Complement Each Other

Rather than competing methodologies, “classical” structured problem solving and design thinking are complementary modes of inquiry.  Each has unique strengths:

  • “Classical” structured problem solving emphasizes logic, breaking issues down into subcategories, clarity, prioritization, and communicating through trees. This approach is excellent for execution, communication, and data-driven decision-making.
  • Design thinking emphasizes empathy and creativity. It prioritizes user-centric exploration through immersion in the user experience and communicates through stories and prototypes. Design thinking is ideal for discovering unmet needs, generating new ideas, and reframing challenges.

The two approaches are not mutually exclusive.  When combined thoughtfully, the two approaches create a powerful synthesis.  Design thinking expands the problem space, while structured analysis sharpens it.  Together, they transition from discovery to direction.  The strongest problem solvers know when to switch from logic to empathy—and back.

7.4 Structuring After Design Thinking

Once design thinking has yielded insights about user needs, hidden frustrations, or unspoken expectations, or has reframed the problem, structure reenters the process.  Teams translate observations into structured problem statements, build logic trees around newly discovered pain points, and prioritize interventions.  They break down user needs and define experimentation plans or implementation workstreams.

For instance, through qualitative interviews, a team may discover that onboarding friction is a key driver of customer churn.  This insight becomes the basis for a hypothesis: “Reducing onboarding complexity will improve retention.”  Then, a hypothesis tree can be constructed to test this idea by identifying and validating the conditions under which it might hold, as well as testing which features or solutions best address these conditions.

Likewise, frameworks such as journey maps or experience pyramids can be adapted into structured diagnostic tools.  The key is to transition from open-ended exploration to targeted problem-solving guided by newfound knowledge.

7.5 Blending Both Approaches

The most effective problem solvers know when to shift between structured logic and human-centered exploration.  They resist the urge to rush into frameworks when empathy is needed and avoid staying in ideation mode when action is required.  Instead, they establish an iterative process of exploring broadly, synthesizing insights, applying rigorous structure, and testing, refining, or reframing as necessary.

Structure without empathy risks rigidity.  Empathy without structure risks chaos.  Together, however, they create a problem-solving approach that is both analytically rigorous and emotionally intelligent—one that solves the right problems in the right way.  Great problem solvers blend both, expanding the space with design thinking and narrowing it with structure to drive action.

8. Key Takeaways: The Power and Practice of Structuring

Problem structuring is not just a preliminary step; it is the foundation upon which the entire problem-solving process is built.  A well-structured problem provides direction for analysis, guides collaboration, enables clear communication, and accelerates decision-making.  It transforms complexity into clarity and ambiguity into action.

Several key insights emerge:

  • Structure turns ambiguity into action.  By breaking down complex challenges into smaller, logically connected components, teams can prioritize and gain focus, direction, and alignment, regardless of how uncertain the terrain initially appears.  This allows teams to convert ideas into action and align communication and collaboration.
  • Framing precedes structuring.  A problem must first be carefully framed—its context understood, and its core question clarified—before it can be decomposed effectively.  Without framing, structuring risks precision without purpose.
  • MECE thinking is essential.  When building hypothesis trees, issue trees, or factor models, applying the MECE principle (mutually exclusive and collectively exhaustive) ensures logical soundness and analytical completeness.
  • Tool choice depends on context.  Logic trees are custom-built structures that guide analysis.  Hypothesis-driven trees are ideal when a plausible solution exists, and speed is essential.  Issue trees are best for open-ended, diagnostic problems.  Factor/lever trees support quantitative analysis, and decision trees map choices under uncertainty.  Each has its place, and expert problem solvers know when and how to combine them.  Additionally, proven analytical frameworks that shape early thinking can be incorporated into a tree structure for optimal results.  Use the hypothesis-driven approach when speed, clarity, and prior experience are important factors.  Opt for the issue-driven approach when the problem is novel or exploratory.  Integrate design thinking when ambiguity, human-centered issues, or innovation dominate.
  • Beware of cognitive traps.  The structuring process is susceptible to common biases and missteps, such as confirmation bias, narrow framing, over-structuring, and stakeholder exclusion.  If not addressed deliberately, these pitfalls can undermine even the most logically elegant structure.
  • Structure must adapt to reality.  Structuring is not static; it evolves as new facts emerge, hypotheses are tested, and priorities shift.  Iteration is not a flaw, but rather a feature of rigorous, real-world thinking.
  • Design thinking complements structure.  When facing human-centered, ambiguous, or emotionally charged challenges, integrating empathy-driven exploration with logic-based structuring yields more effective and grounded solutions.
  • Communication is integral to structuring.  A good structure not only guides analysis but also frames the story.  Whether aligning a team or presenting to executives, the structure becomes the backbone of a compelling, transparent, and actionable narrative.
  • Mastering problem structuring requires developing analytical discipline and creative flexibility.  It is the art of identifying what matters, organizing it clearly, and using that clarity to produce meaningful results.  With practice, structure becomes a mindset that enables individuals and teams to solve problems with confidence, coherence, and lasting impact.

References

Conn C, McLean R (2018) Bulletproof Problem Solving (Wiley, Hoboken, NJ).

Descartes R (1850*) Discourse on the Method of Rightly Conducting the Reason, and Seeking Truth in the Sciences (Sutherland and Knox, Edinburgh, United Kingdom).

Friga PN (2009) The McKinsey Engagement: A Powerful Toolkit for More Efficient & Effective Problem Solving (McGraw-Hill, New York, NY).

Garrette B, Phelps C, Sibony O (2018) Cracked it! How to Solve Big Problems and Sell Solutions Like Top Strategy Consultants (Palgrave Macmillan, Cham, Switzerland).

Kim WC, Mauborgne R (2004a) Blue Ocean Strategy: How to Create Uncontested Market Space and Make the Competition Irrelevant (Harvard Business School Publishing, Boston, MA).

Kim WC, Mauborgne R (2004b) Blue ocean strategy. Harvard Business Review 82(10):70–80.

Porter ME (1980) Competitive Strategy (Free Press, New York, NY).

Rasiel EM (1999) The McKinsey Way: using the Techniques of the World’s Top Strategic Consultants to Help You and Your Business (McGraw-Hill, New York, NY).

Rasiel EM, Friga PN (2002) The McKinsey Mind: Understanding and Implementing the Problem-Solving Tools and management techniques of the World’s Top strategic Consulting Firm (McGraw-Hill, New York, NY).