Bernard Garrete, Corvey Phelps, Olivier Sibony: Cracked it!

The Most Important Skill You Never Learned

Our default approach to thinking — including about how to solve problems — is fast. This is known as “System 1” thinking. In contrast to fast thinking, slow thinking (aka “System 2”) is voluntary because it requires effortful attention and conscious deliberation.

Therein lies the core problem of problem solving — our tendency to think too fast (or too lazy) and jump to solutions. We spend too little time and effort understanding a problem, believing instead we know all we need. We unleash the associational machine in our minds, reflecting our implicit assumptions about causes and effects, on this limited information to develop a coherent and plausible story about what’s going on and why.

We all run the risk to jump to conclusions and take action without questioning the implicit assumptions — or the emotions — that dictate the way we interpret events and information.

So, are you Othello or Hamlet? Are you more likely to think — and act — too fast, or to get mired in analysis paralysis?

While we all solve problems, managers and consultants are professionals — they’re hired and paid to do so.

As Harvard professor Clayton Christensen recently observed, “Management consulting’s fundamental business model has not changed in more than 100 years. It has always involved sending smart outsiders into organizations for a finite period and asking them to recommend solutions for the most difficult problems confronting their clients.”

Managers and consultants typically specialize in particular functional or industrial areas for much of their careers, developing expertise in these areas.

Experts also use more effective problem-solving strategies in their areas of expertise, more carefully evaluate potential solutions against constraints, and more effectively monitor their problem-solving progress by refining solutions.

Even though experts are better problem solvers than novices within their areas of expertise, when they tackle problems outside their expertise or when task conditions in their fields change, they often perform like novices … or worse. Experts can become trapped by their expertise. Compared to novices, experts also are overconfident in their ability to understand problems outside their areas of expertise, leading them to develop worse solutions.

An ill-defined problem is one where the current situation, desired outcome, and path between the two are difficult to articulate. Complex problems are often initially ill-defined and typically non-routine.

Research shows that entrepreneurs often abide by the field of dreams principle: if you build it, they will come.

Just because something is unknown, however, doesn’t mean it’s unknowable. Many unknowns are unknown because problem solvers fail to spend the time, effort, and resources to recognize the unknown aspects of a problem. In facing complex problems with unknown unknowns, experts may not recognize their ignorance and instead assume they know all they need to tackle the problem.

While intelligence matters, over 80 percent of complex problem-solving effectiveness is explained by other factors — smarter is better, but it isn’t enough.

It’s unlikely that technology will help us overcome this skills gap. Although technologies help us with many challenging problems, rapid advances in big data analytics, artificial intelligence (AI), and robotics won’t make problem-solving skills any less relevant or important.

If expertise, intelligence, and technology aren’t enough for solving complex business problems, then how can we do better?

What we need is a disciplined and generalizable problem-solving method and a set of useful tools for each step of the process.

The Five Pitfalls of Problem Solving

The years 2000 – 09 were a “decade horribilis” for the record companies, who saw two-thirds of their revenues evaporate. At the heart of this disaster was the way the music industry viewed file-sharing. They framed the problem that MP3 and Internet technologies posed essentially as: “How do we stop (or drastically reduce) the illegal sharing of music files to protect the business of selling CDs?” A very different and more productive question could have been: “How can we make money in a world where technology is changing the distribution of music?” One company — Apple — asked this question.

Flawed problem definition is the first pitfall of problem solving, and conversely, stating the problem effectively is the first step (“State”) in the 4S problem-solving method we’ll introduce in the next chapter.

In October 2005, Franck Riboud, CEO of Danone, a multinational corporation with € 13 billion revenues in dairy products, beverages, and baby food, had a lunch meeting in Paris with Professor Muhammad Yunus, father of the microfinance concept and head of Grameen Bank.

The Yunus – Riboud meeting led to the creation of a yogurt-producing joint venture called “Grameen Danone Foods Limited” (GDFL), the first example of a social business involving a multinational corporation. The venture’s performance, however, didn’t live up to the founders’ expectations.

By limiting the scope of their joint venture, Yunus and Riboud narrowed down a significant global issue to a problem they could own.

The solution confirmation pitfall. Rather than beginning with the problem — child nutrition — and analyzing it to find a relevant and cost – effective solution, Danone and Grameen started from the potential solutions they had to offer.

Candidate solutions are powerful components of any problem-solving process. There is a difference between using them as hypotheses to be tested and simply assuming they’re correct.

The role of hypotheses and candidate solutions in the second step of the 4S problem-solving approach: “Structuring” problems.

Using the wrong framework — is the third pitfall of problem solving. In this example, as in most other business situations, different frameworks can be applied to the same problem.

Frameworks are like theories — they’re a way of seeing and understanding our world. They carry with them implicit assumptions about what causes what. They tell us what to pay attention to in a particular situation — what variables are important — and they provide us with a story to explain and understand it. But frameworks, like theories, have an insidious nature: by suggesting what we should attend to, they also tell us what to ignore. Frameworks frame reality.

Our choice of frameworks can blind us to important aspects of a problem, leading us to develop ineffective and costly solutions.

This cognitive bias goes by at least two names: “the law of the instrument,” coined by Abraham Kaplan (another philosopher), and “Maslow’s hammer,” after the eminent psychologist Abraham Maslow (of “the hierarchy of needs” fame).

When we face complex, human-centered problems that we understand poorly, such as the one Ron Johnson faced at Penney’s, we should avoid framing them by analogy with others situations. Instead, we should invest in understanding problems from the perspective of the people who experience them.

We should also resist the temptation to zero in on one solution, and instead generate multiple potential solutions to the problem at hand. We can then avoid “betting the farm” on one idea that may not work by prototyping and testing potential solutions to identify the best one. The design thinking path to problem solving, which we’ll introduce in the next chapter, addresses these objectives.

Solving the problem is worthless if you can’t convince decision-makers to adopt the solution.

Poorly communicating the correct solution is also a problem. Brilliant communication of the wrong answer is even more harmful than poor communication because it leads to misguided and even detrimental actions.

Consequently, the fourth step in the 4S method is “Sell”.

The 4S Method

The Problem-Solving Approach of Consulting (PSAC) isn’t usually taught outside of consulting firms, and the ability of strategy consultants to “crack” tough business problems in unfamiliar fields is a large part of the consulting industry’s mystique. PSAC is a practical approach.

These foundations are based on Aristotelian logic and Cartesian method and on their modern incarnations, including the practice of “critical thinking”.

Logical thinking is a powerful tool in any setting, and business is no exception. By pushing their clients to formalize their reasoning, by rigorously testing the links in the causal chain of that reasoning, and by insisting on evidence to back up each link in that chain, strategy consultants — or any skilled user of formal logic — can sometimes overturn preconceived ideas or challenge accepted practices.

One of the tenets of formal logic is the concept of formulating and testing hypotheses.

In most organizations, there is no such thing as “a hypothesis to be proven or disproven” — proposals have proponents, precedents, and histories, and those who evaluate them know it.

Just “go with the flow” despite your doubts — a powerful phenomenon sometimes called groupthink.

Alongside hypothesis-driven problem solving, many strategy-consultants practice issue-driven problem solving.

This isn’t a guarantee against confirmation bias: your hypotheses may creep into your definition and structuring of the problem, leading you to define your problem narrowly, which constrains the solution.

Experienced practitioners of PSAC call this temptation “reinventing the wheel”: the tendency to look, at all costs, for a new, out-of-the-box answer to a problem that has an acceptable off-the-shelf solution.

Design thinking has emerged as a powerful problem-solving toolkit that integrates both creative and analytical approaches. Although developed for the design of physical artifacts, design thinking has evolved to address intangibles such as services, processes, and larger organizational systems and strategies.

In The Sciences of the Artificial, his landmark book on problem solving and design, Nobel laureate Herbert Simon argued that design is concerned with how things ought to be and with devising artifacts to attain goals.

From a logical and philosophical standpoint, design thinking is distinct from the other approaches we’ve discussed. Hypothesis-driven and issue-driven problem solving are both forms of deductive reasoning.

It will help you decide which of three possible paths to take to solve a problem: the hypothesis-driven, issue-driven, or design thinking path.

Using the 4S method

State: A Problem Well Posed Is Half-Solved. The importance of a good problem statement can’t be overstated. Einstein said, “If I had an hour to solve a problem, I’d spend 55 minutes thinking about the problem and 5 minutes thinking about solutions.” Writing a full problem statement requires you to examine five elements of the problem — abbreviated in the acronym TOSCA (Trouble, Owner, Success criteria, Constraints, Actors).

Structure: The Architecture of Problem Solving. The hypothesis-driven approach starts from an idea — a hypothesis — about what the solution might be and then tests it. For this hypothesis to be true, many things must be true. List these conditions, and disaggregate them into smaller requirements. This is what we’ll call a “hypothesis pyramid”.

The alternative is to go for an “issue-driven” path, following the second column in the flowchart. An issue-driven approach requires you to break down the problem into smaller components with an issue tree. An issue tree is a way to structure the problem thoroughly, to look at its different facets systematically, without a preconceived idea of what the solution might be. The benefit of this approach is that you can avoid the solution confirmation pitfall. The downside is that building an issue tree is more difficult and more time – consuming than building a hypothesis pyramid.

Frameworks are essential shortcuts for someone building an issue tree because they provide pre-packaged decompositions of typical, recurring business problems. Frameworks enable you to think faster. A framework encapsulates a theory to solve a class of problems, and to use a framework is to espouse a theory and the assumptions that underlie it. Solving a product design problem. You’ll probably find them difficult to break down with a hypothesis pyramid or an issue tree. Instead of a traditional decomposition, these kinds of problems call for an ideation phase. Design thinking practitioners use what they learned about what is (in the “State” phase) to then imagine what should be. They then build on this understanding to synthesize an essential set of design imperatives that an effective solution must address. These imperatives represent the benefits a solution must provide users.

Solve: Between Analysis and Creativity. However, with an issue tree, there is no guarantee the solution will just emerge like this. Issue trees disaggregate problems, but not all problems can be solved by being disaggregated.

Fresh ideas are precisely what the design thinking approach can generate.

Tim Brown, CEO of IDEO, summed it up this way in his book Change by Design: “The mission of design thinking is to translate observations into insights and insights into products and services that will improve lives.” Rather than substitute for each other, the analytical and creative approaches are complements.

Sell: while solving a problem and selling the solution are distinct stages, they should be integrated for at least two reasons. First, business problem solvers usually can, and should , interact with their audience throughout the problem – solving process .

Highlight (orange) – Page 63 · Location 1487

There’s a second reason to consider communications in the problem-solving phase, and vice versa: it ensures the two are sufficiently distinct and communication concerns don’t “contaminate” the search for a solution.

The 4S method has three paths: hypothesis driven, issue driven, and design thinking. Each path covers the four stages: State, Structure, Solve and Sell.

State the problem, after learning enough about it: – When you don’t know enough, this requires using empathy techniques.
Structure the problem, depending on the path you’re on: – With a hypothesis pyramid (if you are highly confident in the candidate solution) – With an issue tree (if you don’t have a good candidate solution, but can decompose the problem) – With ideation based on solution imperatives (if decomposing the problem is ineffective)
Solve the problem: – By performing the analyses required (first two paths) – By prototyping and testing solutions (design thinking path)
Sell the solution, focusing on the answer and your audience, not on how you solved the problem.

The 4S method is iterative and not rigidly sequential.

State the Problem: The TOSCA Framework

The basic definition of “trouble” is a gap between an observation and an aspiration. By the same definition, “trouble” can also be a perceived opportunity. It’s the discrepancy between aspiration and reality, the dissatisfaction, which defines trouble. Don’t let interpretation (or solution ideas) creep into your definition of “trouble”.

Ask “Why now?” If the gap between reality and aspirations is a generic, eternal one — it is unlikely to provide a good basis for a problem statement.

A common prescription in problem solving is to go beyond the symptoms to interpret the problem’s cause.

A defining feature of complex problems, in business and elsewhere, is that, unlike diseases, they don’t always belong to well-defined, preexisting categories with recognizable symptoms and proven therapies.

The bar for adopting a hypothesis-driven approach should be a high one. You should define trouble as a symptom, without attribution to a known diagnosis, unless you have reason to be confident that you can make an appropriate diagnosis (and propose a candidate solution).

Observing symptoms leads to the “owner” question: whose job is it to take care of the symptoms? Most problems don’t have a single, obvious owner, but they can be stated from the perspective of a particular owner; and that choice will bear on the way the problem is defined. One virtue of having identified a problem owner is that there is someone you can ask the most critical question in problem solving: what do you want?

A more productive way to ask “why” is to ask what success will look like.

Yet, to properly define a problem, we must resist the urge to solve it too quickly. To focus on stating the problem, we need first to ignore the possible solutions. Asking the “success criteria” question is a tool to do just that.

Constraints: What Are the Limitations and Trade-Offs? In solving any problem, there are limits to what you can do. Be aware of these constraints. You should define constraints from the perspective of the problem owner. Although achieving success as you define it is your primary objective, it’s rarely your only one.

These constraints qualify the success criteria — success is success, but it can’t be achieved at all costs. You should identify these trade-offs as early as possible in the process. Second, the owner’s resources and capabilities may also impose constraints on the solution. Third, there are often constraints on the problem – solving process itself.

Discussing constraints early on can save you time and effort.

Actors: Who Are the Stakeholders?

The “owner” is usually not the sole person dealing with a problem and its consequences. The owner must contend with other stakeholders, who rarely have the same objectives (i.e., success criteria).

Stakeholder analysis is a useful technique to identify, systematically, the stakeholders and their objectives.

Now that you’ve completed the five TOSCA steps, you can write the core question you’ll answer. It should be a question, not a statement.

Does the question address the trouble that got you to consider the problem in the first place?
Is the question phrased from the perspective of the owner?
Would answering this question meet success criteria?
Does the question recognize the constraints?
Does the question consider relevant actors?

In describing the steps in the problem definition process, we’ve made them appear sequential and reasonably straightforward: spot the trouble, verify the owner, define success, identify constraints, list actors — and then, write the question. In reality, the process is more complicated.

For each component of TOSCA, many people will have different opinions, insights, and perspectives to contribute.

To state a problem well, you must integrate these various perspectives into your problem statement.

Design thinking experts call it “empathy”: to state a meaningful problem, you must put yourself in the shoes of various constituents, including the problem owner, and the other actors whose worldviews, choices, and behaviors shape the problem and may contribute to its solution.

Without empathizing with all the actors, the problem statement can’t be complete. Usually, this means conducting problem definition interviews: early in the problem-solving process.

However, interviews are sometimes not enough to get to real needs and wants. In such cases, careful observation of the actors’ behaviors may reveal their needs and expectations. Design thinking practitioners call this approach immersion.

There is no “right” problem definition, although there are many wrong ones.

The TOSCA checklist:

Trouble: a gap between a situation and an aspiration.
Owner: the person asking for this problem to be solved and who will judge a good problem definition and a good solution.
Success criteria: spell out “what success will look like”.
Constraints include:
- Preexisting objectives and commitments that constrain the success criteria.
- Resource and capability limitations.
- Time, budget, skill, or confidentiality issues.
Actors: are important stakeholders whose objectives you must understand.

Structure the Problem: Pyramids and Trees

Just because you have an idea does not mean it’s correct.

You’ll build a hypothesis pyramid from the top down. You’ll start with your leading hypothesis and break it down into sub – hypotheses that are conditions for it to be true. You might also break these first – level conditions into sub-sub-hypotheses, until they are specific enough to be proven or disproven by analyses, facts, and data.

When you’ve performed all the required analyses, you can climb back up the pyramid and say whether the leading hypothesis is right or wrong, or more interestingly, what is right and wrong in it, and to what extent.

Three sub-hypotheses are conditions that must hold (be true) for the main hypothesis to hold.

To avoid mistakes here, we must explore a distinction you may remember from your math classes between necessary and sufficient conditions. Necessary conditions are conditions that cannot be wrong if the hypothesis is true. However, necessary conditions can be true while the hypothesis is wrong.

Sufficient conditions work the other way around. A sufficient condition is enough to prove a hypothesis is true, but a sufficient condition can be wrong even though the hypothesis is true.

You can use both types of conditions in a hypothesis pyramid, provided you know the distinction between necessary and sufficient conditions: proving one sufficient condition right is enough to validate a hypothesis, while proving one necessary condition wrong is enough to reject it.

In practice, however, you’ll encounter two challenges. The first is that accepting or rejecting the leading hypothesis isn’t your only objective. It’s more often a means to solve a business problem as thoroughly as you can. The second challenge is that sufficient conditions are rare in business problems. As you disaggregate the leading hypothesis into more elementary sub-hypotheses that are “searchable” — concrete and specific enough to be (in) validated by evidence — you’ll identify many conditions that are necessary, but none that is sufficient.

Working with a hypothesis pyramid is both a fact-finding and logical challenge: you must make sure the necessary conditions are verified and that, taken together, they are sufficient to validate the hypothesis.

“Collectively exhaustive” means we’ve identified all possible conditions to provide logical support for the hypothesis. In addition to being collectively exhaustive, the conditions must not overlap. In other words, they should be mutually exclusive. MECE is a fundamental notion and a pillar of good problem solving and solution selling.

Hypothesis-driven problem solving is efficient when you start from a sound hypothesis. It saves time and energy by focusing your efforts on a candidate solution (or a range of consistent solutions). Experts and senior business people often structure problems in this way.

Hypothesis-driven problem structuring isn’t without risks. It exposes you to at least five potential mistakes:

First, hypothesis-driven thinking can creep in during the problem statement stage.
Second, once the hypothesis is stated, it immediately narrows the problem frame.
Third, the tools you use to understand and analyze the problem may implicitly limit the hypotheses you develop.
Fourth, hypothesis-driven thinking can lead you to communicate the solution before solving the problem.
Finally, hypothesis-driven problem structuring can lead to the solution confirmation pitfall.

Building a hypothesis pyramid can prove difficult. The potential confusion between necessary and sufficient conditions, logic and causality, or causality and correlation can make the pyramid’s logic cumbersome and fuzzy, although its visual representation makes it look clean and rational.

Issue-driven problem structuring draws heavily from the Cartesian method for conducting a systematic search of the truth.

Accept nothing for true without questioning it thoroughly.

Divide each issue into parts until you find adequate solutions to each elementary issue. Conduct analyses by starting with the simplest issues and ascending step by step to reach more complex issues, while keeping a sense of order and priority, especially when considering disconnected issues. Make sure nothing is omitted.

The choice to represent hypotheses as a pyramid and issues as a tree is arbitrary. We distinguish the visual representations of the two approaches to emphasize their conceptual differences.

While hypothesis pyramids consist of hypothetical statements, issue trees consist of questions.

Trying to make the issue tree exhaustive is beneficial at the beginning of the problem-solving process, but at some point, you must prune it by setting priorities and eliminating “dead-end” branches. A general rule of thumb is that 20 percent of the possible issues have the potential to generate 80 percent of the insights.

For narrowly defined problems, especially “yes or no” issues, the hypothesis-driven and the issue-driven approaches are equivalent.

In most situations, you must choose between a hypothesis pyramid and an issue tree. Our recommendation here is simple: the “default choice” should be to use an issue tree, unless there are compelling reasons to be content with a hypothesis pyramid.

Limit the use of hypothesis-driven thinking to two cases only:

You have strong reasons to believe in your hypothesis.
You don’t have the luxury of building an issue tree.

Structure the Problem: Analytical Frameworks

In principle, breaking down a problem into smaller problems is easy.

Problem structuring gets much more difficult, however, whenever the problem is more complex, or when you face a broader question.

Many problems are not genuinely unique; they belong to a class of similar problems.

Analytical frameworks are prepackaged, MECE breakdowns of typical problems. Frameworks are the building blocks of issue trees and hypothesis pyramids.

Functional frameworks are the core building blocks of business reasoning. If you read textbooks in marketing, finance, or other disciplines, or if you attend a business degree program, you’ll learn many functional frameworks.

An industry framework. Unlike functional frameworks, which we learn in classrooms and textbooks, businesspeople usually learn industry frameworks on the job. Every industry has its shortcuts to analyze the critical problems it routinely faces, and these frameworks are often embedded in the tools, methods, and decision rules it uses.

To use a framework is to adopt the mental model of the function or industry in question, with all the assumptions it takes for granted.

It’s hard to use multiple frameworks if we don’t know any. We’ll start with industry frameworks. These are the most powerful and the first place to start. Functional frameworks are the next best thing. If all else fails and you still don’t know how to break down a question into smaller parts, you must do without a framework and use elementary logic.

While revenues and costs are a MECE decomposition of profit, changes in revenues and costs are not. Costs and revenues are independent and provide a MECE breakdown of the income statement when viewed statically. From a dynamic, managerial perspective, however, this decomposition isn’t sensible.

We need a framework that indicates how the actions of a retailer such as Starbucks create value — or fail to do so. Every industry has such frameworks: they reflect the industry’s value drivers, the important levers of value creation in the business. A quick way to identify such value drivers is to look at the way companies in each industry analyze and explain their results.

To choose the right framework, you must know something about the industry. This doesn’t mean industry frameworks are eternal, immutable truths, and that importing a framework from another industry is always wrong. Changing frameworks is especially important when the industry is changing.

Frameworks are mental representations of reality: changing them is justified when reality changes. Having more than a hammer in your toolbox will help you become a better problem solver.

For each classic question in strategy, for instance, there are many (often conflicting) schools of thought, each of which claims to offer the “correct” way to think about the problem, and often a framework to reflect it.

If your problem is to engineer “nudges” that will modify people’s behaviors, the EAST framework will remind you that the behaviors you are encouraging should be Easy, Attractive, Social, and Timely.

Three styles of functional frameworks:

Formula frameworks, which connect a result and its components. Formulas are useful whenever you define the problem as computing a number and thus requiring a calculation.
Typology frameworks, which list different categories of things. Typologies are useful whenever the problem you deal with calls for a MECE list of things — options, reasons, factors, whatever — and you want to make sure you don’t forget one.
Checklist frameworks, finally, are similar to typologies, but are lists in which all elements must be present simultaneously for a condition to be true.

But when a problem is complex, the issue tree used to tackle it isn’t just a juxtaposition of two or three ready-made analytical frameworks. In your problem-structuring approach, you’ll need a “cement” to hold these blocks together. You’ll also need a basic material to fill the holes when no handy framework is available. This is when you’ll need logical decompositions. Logical decompositions, as the name implies, include all the ways to break down a problem that are MECE in a purely logical sense.

Charlie Munger, vice chairman of Berkshire Hathaway, once advised aspiring businesspeople to “have models in [their] heads…, multiple models. As Munger suggests, you must constantly strive to broaden your personal “library” of frameworks.

Frameworks are rarely “the” method to structure a problem. They are, however, building blocks of the method — an integrative issue tree or hypothesis pyramid.

To structure problems thoroughly, and increase our chances of developing valuable solutions, we must be willing and able to leverage and integrate the different perspectives and frameworks of different contributors.

To structure large, complex problems, you need frameworks as building blocks and the skill to assemble them — this is the art and practice of building issue trees and hypothesis pyramids.

Solve the Problem: Eight Degrees of Analysis

You now have a solid hypothesis pyramid. Your task as a problem solver is straightforward. You must identify, for each elementary hypothesis:

what you must know to test the hypothesis
how you will get that information

These two steps are the “analyses” and the “sources”.

The resulting “analysis plan” tells you what you must do to confirm, disprove, or modify the hypotheses.

We can identify eight degrees of analysis, which increase in complexity:

Hypotheses that can be taken as a given without further analysis.
Analyses requiring hard numbers that are easy to identify, if not always to obtain.
Assessments based on facts that are not numbers.
Hypotheses that can be settled by simple analysis beyond the facts.
Hypotheses that force you to make assumptions.
Hypotheses based on a special type of assumption: internal plans.
Assumptions that call for technical expertise.
Assumptions that are, irreducibly, a matter of judgment.

Two considerations, however, are universal.

First, start with the critical, “make or break” hypotheses, especially when they’re relatively easy to test.
Second, some analyses you identify may be too difficult, or even impossible, to conduct.

Once you’ve defined and structured the problem, established the analysis plan, and planned the work, it’s time to perform the analyses. Your solution will only be as good as the analysis it’s based upon.

As any experienced analyst in any field will tell you, there’s no foolproof way to avoid all analytical errors. Because we focus solely on analytical work, we assume the problem is defined and structured correctly.

Good analysis starts with good data:

Get the right numbers.
Adjust the right time frame of time series.
Get the right qualitative data.

When we hope to understand the reasons for a change (the loss of customers) by focusing on what is still here after that change (the remaining customers), we are guilty of survivor bias.

You will conduct much of the analysis not only by using hard data, but also by making assumptions.

The cardinal rule of assumptions is that they must be explicit. Making assumptions explicit has another benefit: it facilitates dialogue with your audience. How to make realistic assumptions — or how to get your audience to accept them as realistic. Get physical to be realistic. Check that all your assumptions are consistent with one another.
Benchmark your assumptions.
Test sensitivities. When you are 90 percent certain that a number you estimate lies within a certain range, you’ll typically be wrong at least 50 percent of the time.

Detailing, benchmarking, and testing your assumptions with your audience may seem unnatural. You might think that you’re expected to project confidence in your calculations, and fear that by sharing your hypotheses, you’re exposing weaknesses.

These fears are misplaced. Pretending we can be certain of things that are difficult to predict isn’t confidence — it’s foolishness.

Now that you have the data and have made the assumptions explicit, you must run the numbers. The following tips can help you minimize that risk:

Beware of percentages — they’re treacherous.
Orders of magnitude are your friends.
If it looks wrong, it probably is.
If it looks right, it may still be wrong.

Now that you have your data, assumptions, and calculations, it’s time to look at the analysis and ask “So what?” to draw conclusions.

One type of evidence that requires especially careful challenge is correlation data. It’s useful, however, to remember that a test of statistical significance doesn’t guarantee that a correlation is meaningful in the ordinary sense that lay people understand.

Statistical significance measures the extent to which the correlation you observe is a reliable piece of evidence, but it doesn’t tell you why the two variables are correlated, and the reason may have nothing to do with a cause–effect relationship. How should we use correlations? Two words: very carefully.

While a correlation between two variables is not a sufficient condition for causation, a statistical association is a necessary condition.

Good analysis is the heart of good problem solving. But while brilliant insights in problem definition and structuring sometimes occur, they’re rare in the analytical work. Good analysis means proceeding with rigor and avoiding mistakes. The “Solve” stage of the 4S process, when it entails a hypothesis pyramid or an issue tree, is all about disciplined execution.

Recognize eight types of analysis, in increasing order of complexity:

Facts:
- existing data
- easy-to-find numbers
- non-numerical facts
Fact-based analyses (e.g., how much can you reduce overheads?)
Analyses based on assumptions, which should be stated (e.g., synergies)
Internal plans and forecasts, also based on assumptions (e.g., sales plan)
Expert input (e.g., legal opinion)
Judgment calls (e.g., anticipation of stakeholder response)

Common analytical mistakes include:

Misleading data (did homicides in the UK really increase by 21 percent?)
Disputable time frames (what time period to evaluate Jeff Immelt?)
Biased samples (only dissatisfied customers? only remaining customers?)
Assumptions that are unrealistic, inconsistent, untested, or hidden: Check: physical plausibility, internal consistency, benchmarks, sensitivities
Numerical errors: Check: percentages, orders of magnitude, “surprises”
Data interpretation errors, especially with correlation data: Does correlation reflect causation? Reverse causation? Common cause? Coincidence?

Redefine the Problem: The Design Thinking Path

Design thinking is a disciplined process for solving human-centered, complex problems that are poorly understood by solution developers. This approach puts the observation and discovery of human needs at the core of the problem-solving process. Design thinking has a bias for action by promoting iterative testing of assumptions about potential solutions. It requires solution developers, known as designers, to translate their insights about the people experiencing the problem, known as users, into explicit assumptions about what users want and don’t want in a solution. This is done by developing concepts of possible solutions and then translating them into prototypes that can be iteratively tested using feedback from the actors who are expected to implement the solution.

In practice, design thinking consists of five iterative phases. The five phases — Empathize, Define, Ideate, Prototype, and Test.

The core features of design thinking, beginning with the tension between divergence and convergence. Alternating between divergence and convergence is at the heart of design thinking. Decades of research show these are the engines of creative problem solving.

In his book Change by Design, Tim Brown, CEO of design firm IDEO, explains that divergence creates options for choices at each phase of the design thinking process, while convergence is about making choices.

Concrete and Abstract. The design thinking process requires problem solvers to move between the concrete world of real people, artifacts, and experiences, and the abstract world of models, theories, and ideas. It also requires designers to alternate between analysis of data from the concrete world and synthesis of these data for the creation of future solutions.

Empathizing consists of three broad activities: observation, engagement, and immersion. Each represents an “in-the-field” research orientation designed to get close to and understand people in their natural settings.

To begin the Empathy phase, you’ll need to initially define and frame the problem you’re trying to solve and scope the project. In the language of design thinking, this is known as a design brief.

Before beginning your observation efforts, there are a few things to do. You’ll need to identify who to observe (users) and where to observe them, and define what you want to learn about them. There are three fundamental approaches to conducting observations. The most common is to participate in the activities of the users and disclose that you’re observing them. In some situations, you may choose to observe activities overtly without participating in them. Shadowing is a widely used example. Finally, in some cases, you may choose covert participant observation.

Engagement allows you to ask “why?” to get at the motives and reasons behind their behaviors and thinking. Semi-structured interviews are one of the most widely used approaches for engaging with users. Semi-structured interviews rely on a predefined set of open-ended questions that guide the conversation. In designing the interview protocol that you’ll use to structure your conversation, remember that the purpose is not to validate assumptions or test hypotheses, but to explore.

Immersion. An extreme approach to participant observation is immersion — when you simulate being a participant and record observations about your own experience.

The Define stage is where you transition from the concrete to the abstract, from observing how and why people act, think, and feel to developing abstract representations of them and their experiences. You’ll use analytical tools to synthesize your observations into a coherent understanding of the problem, which you’ll reflect in the form of models: empathy maps, journey maps, and user personas.

The objective of the Define phase is to develop an actionable and meaningful problem definition. What is specific to the design thinking approach is that you define the problem from the perspective of users. This is often called a POV statement.

A POV statement identifies a particular type of user, a fundamental need the user is trying to fulfill, and insights about why the need exists and what is important to the user in fulfilling the need. Needs are emotional or physical necessities or desires, expressed as verbs — something with which users need help. Solutions are nouns and are developed to satisfy needs. Insights are unexpected findings about how users act, think, or feel that you can leverage in your problem-solving effort.

A widely used tool for organizing and synthesizing observations of individual users is an empathy map. A user empathy map is a template laid out on a single large page, table, or whiteboard and divided into six sections. The six sections reflect summary observations about the user along these dimensions:

Think and feel
Say and do
Hear
See
Pains
Gains

Journey Maps. Another useful tool for organizing data about each person you observed is a user journey map (also known as an experience map). A journey map is a time-ordered model of the activities.

A journey map captures each element of the overall user experience. A generic way to frame the phases of any experience is the 5Es model

Entice
Enter
Engage
Exit
Extend

Insight Cards. Another tool for structuring observations is the insight card. An insight card summarizes an unexpected finding about how a user acts, thinks, or feels.

Although the method for synthesizing structured qualitative data across cases of individual users goes by different names in the design thinking world (such as affinity diagramming, mind mapping, and saturate and group), it consists of a few core steps: search for patterns in the observations across users, cluster similar observations together into themes, and identify how the themes are related to each other. A goal of this synthesis exercise is to define design imperatives, the equivalent in the design thinking approach of the “Success Criteria” in the TOSCA problem statement. Imperatives are statements of what the solution must do and how users should experience the solution, phrased in such a way that they are independent of the actual form and implementation of the solution.

User Personas. The user persona is a powerful way to convey the results of your data synthesis that will guide your solution development. A persona is a vivid and realistic description of a fictional character that represents a composite of real users.

Define the POV Statement and “How Might We” Design Goal. Once you’ve completed your personas, you’re ready to close the Define phase by developing a POV statement for each persona.

“How might we” questions energize and direct the search for potential solutions. They flow from your POV statements and design imperatives. A good “how might we” question is broad enough to stimulate many ideas for solutions, but narrow enough to provoke you and your team to think of specific, novel ideas.

The Empathize and Define phases were concerned with learning as much as possible about an existing problem. The purpose of the Ideate, Prototype, and Test phases is to use what you learned from the first two stages to identify what could be, and ultimately what should be, the solution.

Structure and Solve the Problem Using Design Thinking

Once you’ve defined the problem from the user’s perspective and synthesized a set of design imperatives, you’re ready to generate ideas for solutions, known as concepts. A concept is an approximate and concise description of the solution artifact.

Concepts are typically two-dimensional representations in graphic and/or text form.

In the Ideate phase, you’ll continue to operate in the abstract realm, but you’ll shift your focus from analyzing and synthesizing what is to imagining what could be for your users.

Guidelines for Ideation:

Diversify the Team. If you want to increase the volume and variation of ideas generated, then you need access to diverse problem solvers, including users.
Defer Judgment. Being critical kills creativity.
Go for Quantity. Generating more ideas can increase the chances of finding new and valuable solutions.
Be Visual. As we explained in the Define phase, always seek to make your thinking visible and mobile.
Stay Focused. In the pursuit of generating greater volume and variety of ideas, it’s easy to lose focus on the problem and the users.

In his book Thinkertoys, author Michael Michalko describes 33 techniques to aid in the production of innovative ideas.

Analogical Thinking. Analogies are comparisons of the similar features of two things. We need a method to help us create analogies. Here’s how to do it:

Identify the critical aspects of your problem.
Search for problems in different settings that share characteristics of your problem and identify their solutions.
Evaluate the extent to which your problem resembles the source problem.
Evaluate if the candidate solution might help solve your problem.

Brainstorming. Brainstorming is probably the most well-known, widely used, and extensively researched idea generation method. The design firm IDEO has codified these principles into the following brainstorming rules, which its members follow diligently:

Defer judgment
Encourage wild ideas
Build on the ideas of others
Stay focused on the topic
One conversation at a time
Be visual
Go for quantity

Brainwriting. This is a variation on group brainstorming and was developed to overcome some of its challenges. In brainwriting, participants independently generate a targeted number of ideas (e.g., three or four), or as many ideas as they can, without interacting with each other. Participants then share ideas with one another.

Morphological Analysis. Fritz Zwicky, the brilliant Swiss astrophysicist who discovered dark matter while at Caltech, developed this method for structuring complex problem solving. Morphological analysis reflects a well-established insight from research on creativity, invention, and innovation: new and useful solutions to problems typically result from combining existing artifacts (e.g., ideas, concepts, technologies) in novel ways. Morphological analysis treats artifacts as bundles of different attributes. To use this idea generation method, you first must identify the different attributes of the solution, such as its various performance dimensions, functions it must perform, physical characteristics, and so on. The purpose is to break down the artifact (product, process, system, or strategy) you’re designing into its essential aspects. Once you’ve identified the attributes, you then determine the different possible states in which each attribute can exist. Once you’ve identified the attributes and states, you can arrange them in a morphological matrix by listing the attributes as the column headings and the possible states for each underneath in the rows.

SCAMPER builds on this insight by offering a checklist of idea-spurring questions. The acronym SCAMPER stands for Substitute, Combine, Adapt, Modify, Put to some other use, Eliminate and Reverse.

After diverging by generating many solution concepts, the second step in the Ideate phase is to converge by determining which ones to carry forward into prototyping and testing. Concept evaluation is best done using a structured approach. The objectives and criteria you develop should address three broad areas: user desirability, technological and organizational feasibility, and financial viability.

Although concept selection is a convergent process, it’s unlikely you’ll identify a dominant concept to prototype immediately. Concept evaluation and selection is usually iterative.

To evaluate and select concepts, follow this six-step process:

Construct the selection matrix.
Rate the concepts.
Rank the concepts.
Combine and improve the concepts.
Select one or more concepts.
Reflect on the results and process.

The Prototype phase is where you transition back from the abstract realm to the concrete. The core idea of prototyping is to make your abstract concepts tangible so that users can meaningfully interact with them and you can learn from these interactions.

Prototyping is an essential part of design thinking and disciplined problem solving for three reasons: learning, risk management, and communication.

How to Prototype? Below is a simple four-step planning method:

Define the purpose of the prototype.
Establish the level of approximation of the prototype.
Outline the experimentation plan.
Create a schedule.

The purpose of testing is to learn. You test with users to refine your solution and to refine your understanding of the people for whom you are designing and the problem they face.

How to Test?

Choose a setting and sample of users.
Develop a feedback collection format.
Communicate the prototype.
Collect feedback.
Interpret the feedback.
Reflect on the results.

The promise of design thinking is that it demystifies creativity. It represents a disciplined process and a set of tools that can empower you to generate and pursue new ideas for solutions to challenging problems.

Sell the Solution: Core Message and Storyline

Although it may be apocryphal, Truman is reputed to have demanded, when frustrated by a lack of a clear policy recommendation, “Give me a one-handed economist. All my economists say, ‘on the one hand… on the other hand.’”

The underlying flaw is typical: the writer is reporting his problem-solving process instead of explaining the recommendation and its rationale to the problem owner.

This mistake is pervasive. Because we’ve spent so much time engaged in the problem-solving process, it becomes the de facto structure we use to articulate our solution.

It’s tempting to tell the story of the search instead of telling the story of the solution. This is, however, an ineffective approach to selling a solution.

Barbara Minto is a former McKinsey consultant and the creator of the “pyramid principle”. Her approach is based on an old and well-established insight — people can better understand and remember a set of ideas if they can mentally organize these ideas around a coherent pattern or logical structure.

For business recommendations, Minto argues that the most efficient communication structure is a top-down pyramid that starts with communicating the core message — the “governing thought” — head-on, and then turns to a “key line” of arguments that support it, while also announcing the plan of the report.

Stating the governing thought and the main points of your presentation from the get-go is critical to selling your solution effectively. Having a relevant core message isn’t enough. It must also be concise and set a clear direction.

While you save a punchline for the end of a speech to wrap it up, you state a governing thought from the get-go to pave the way for a dialogue in which you will answer the audience’s questions.

Using the pyramid principle to develop an elevator pitch means you must formulate your core message concisely and be able to answer in a few words the first questions that come to the mind of the problem owner.

Idea of managing the conversation is very important. Monopolizing airtime by not allowing the problem owner to interject is ineffective and risky. You don’t want to be seen as “preaching”. Engaging in a dialogue is also risky, because it can get out of control. The core message must trigger a conversation, but a conversation you can drive.

The overall plan of the recommendation report you’re putting together is called the “storyline”.

Forget the presentation software for a while, and turn instead to your word processor. Don’t produce visuals before you’ve zeroed in on the story you want to tell.

If your governing thought is clear from the onset, you can develop your storyline top-down, based on the pyramid principle. Usually, however, the top-down approach is too difficult to implement.

Instead of trying to invent a core message from scratch, you’ll start with the elementary findings and try to group them in logically similar groups until they cohere into a consistent pattern.

So what? It’s by answering this question that we’ll craft a storyline. Let’s try to build the pyramid bottom-up by grouping the elementary findings into a key line. Summarizing isn’t enough. You must synthesize findings and overcome contradictions by constantly asking the “So what?” question. In doing so, you can find new ways to cluster findings and make them cohere in a higher-level synthesis, which is necessary to induce a core message.

When ordering the different points in the key line and at lower levels in the pyramid, we recommend always starting with the most important items.

While the grouping pattern is the most popular way to build a storyline, another option is possible: the “argument” pattern. An “argument” follows a key line of reasoning that goes from premises to conclusions. The core message results from a stream of arguments in which each new point is logically connected to the prior point. Such a linear logic differs from groupings, in which every key-line point is connected to the core message, but independent from the other points in the key line.

The most convenient and common way to build an argument is to use the “situation–complication–(question)– resolution (SCR)” key line.

Groupings are the workhorses of storylines. They’re robust: if your audience disagrees with one of several reasons you’re giving for your governing thought, it may still agree with the overall message.

Grouping patterns are better suited to simple problems, where audiences are already convinced by the essence of the solution. Argument patterns are preferred when your story is complex, when you must convince people.

The ultimate objective of solution selling isn’t to gain intellectual support for your solution, but to trigger action. Your recommendation report should convey actionable recommendations, not mere analyses or reassessments of the problem.

Sell the Solution: Recommendation Report and Delivery

If you’re about to pitch your solution to the problem owner, it shouldn’t be the first meeting you’ve had with her since she entrusted you with solving the problem.

The final presentation of your recommendation (if there is one) shouldn’t be a “big reveal” where you’ve built up suspense by withholding information about the solution, only to reveal it in the final meeting. Instead, your final presentation should be the culmination of an ongoing conversation with the problem owner and other stakeholders.

Using PowerPoint can be an effective way to deliver your message, if you have one.

The most important thing to remember about PowerPoint presentations is when to prepare them — or rather, when not to: not before you have a storyline.

Develop two documents: a slideshow for presentation, and a full report to be left behind as reading material. Unless the presentation and report are professionally produced for a high-profile event, this solution is rarely implemented.

The guiding principle is to build a modular document that mirrors your storyline. While the whole document will provide exhaustive coverage of the storyline, you can use selected pages for a presentation or discussion.

The storyline must provide the overall structure of the report.
The governing thought and its supporting key line become the executive summary.
Each key – line point, with its supporting messages, becomes a section.
Each elementary message in the storyline becomes a page in the report or slide in the presentation.

If you follow this principle, your report will include four kinds of pages (or slides):

The executive summary page with the governing thought and the key line.
One storyline page for each key-line point.
One content page for each elementary message.
As many backup pages as needed.

The action title concisely conveys the message. A message title is like a headline in a magazine, not an item in a table of contents.

Trackers help to keep the audience on track. The role of the tracker is to locate each page within the overall plan of the presentation.

Finally, the content is the heart of any content page. Most content pages should show facts, but not all facts are numbers to be shown in chart form. An advantage of numbers is that, because they represent quantities, you can easily establish comparisons between them — such as percentages, rankings, or changes over time — that are easy to represent with computer graphics.

The key to effective data visualization is to know what you want to see jump off the page:

Time Series. One analysis you will visualize frequently is the variation over time of a variable, such as sales or profit. We typically represent time series data graphically as a line or a column chart in which time progresses from left to right.
Split. Another popular visualization is to compare different parts in a whole. The classic template is a pie chart that depicts the split (in percentage or actual values) of a variable across categories. If you want to show how the sales split evolves over time, comparing several pie charts will be awkward and difficult to interpret. Stacked columns work better.
Waterfall. You might want to decompose a total value into both positive and negative components, such as inflows and outflows of cash, or positive and negative sources of change in a number. Traditional split charts can’t do the job. A “waterfall” chart works well.
Ranking. You can also compare categories by ranking them based on a particular metric. Horizontal bar charts are better than column charts for rankings.
Frequency. Distribution If the number of categories you must compare is large, a frequency distribution is appropriate. A frequency distribution is a column chart where the height of the column indicates the frequency.
Correlation. You might also want to compare two variables rather than one to show whether the relationship between them follows an expected pattern. A paired bar chart will fit this purpose.

Conceptual charts are visuals that illustrate qualitative reasoning and ideas, such as frameworks, structures, relationships, or processes. One of the most popular examples of a conceptual chart is an organization chart. We recommend using conceptual charts sparingly.

Presentations with fewer slides are better. They leave more time for discussion. Focusing on fewer messages helps ensure your audience understands all the points you’re making.

Slides are simply crutches for presenters — a cheat sheet that helps us remember what to say and appear in command of the meeting. Your aim in your presentation isn’t to read your slides, but to engage the audience in a conversation.

But holding the meeting is the right choice: adults learn by discussing, not solely by listening or reading.

Some highly regarded business leaders, such as Jeff Bezos at Amazon, forbid the use of PowerPoint presentations in their companies.

The purpose of any communication is to convey a message. The backbone of any solution selling is a compelling storyline. Without it, visuals are useless, which is why we insist that the storyline precedes the slides.