1 FRAMING THE PROBLEM

The ability to frame business problems to make them susceptible

to rigorous fact-based analysis is one of the core skills of

a McKinsey consultant. More than that, it is the hallmark of

a McKinsey-ite: if you can’t solve problems in a structured,

hypothesis-driven manner, you’re unlikely to make it through the

door of the Firm.

Data

Intuition

Managing

• Team

• Client

• Self

Presenting

• Structure

• Buy-in

Analyzing

• Framing

• Designing

• Gathering

• Interpreting

The McKinsey problem-solving process begins with the use of

structured frameworks to generate fact-based hypotheses followed

by data gathering and analysis to prove or disprove the hypothesis.

A hypothesis greatly speeds up your quest for a solution by sketching

out a road map for research and analyses that will guide your

work throughout the problem-solving process, all the way to the

presentation of your solution. Given the value of this methodology

to Firm alumni in their post-McKinsey careers, we begin with an

examination of ways to adapt that process to businesses beyond

the Firm.

In this chapter, we will show you how to apply structure to

your business problems and how to go about devising initial

hypotheses that will speed up your own decision making. Because

structure is the basis for the McKinsey problem-solving process,

let’s start there.

STRUCTURE

Although McKinsey & Company often uses the term fact-based

to describe it, the McKinsey problem-solving process begins not

with facts but with structure. Structure can refer to particular

problem-solving frameworks or more generally to defining the

boundaries of a problem and then breaking it down into its component

elements. With either approach, structure allows McKinsey

consultants to come rapidly to grips with the issues facing them

and enables them to form initial hypotheses about possible solutions.

The benefits of structure transfer readily beyond the confines

of the Firm, as our alumni have shown. The facts, as we will see,

come later.

THE McKINSEY WAY

Let’s start by summarizing the ways McKinsey consultants apply

structure to their business problems.

Feel free to be MECE. Structure is vital to McKinsey’s factbased

problem-solving process. For McKinsey-ites, structure is less

a tool and more a way of life. One Firm alumnus summed up his

McKinsey experience as “Structure, structure, structure. MECE,

MECE, MECE.” The concept of MECE (pronounced “mee-see”

and an acronym for Mutually Exclusive, Collectively Exhaustive),

is a basic tenet of the McKinsey thought process. Being MECE in

the context of problem solving means separating your problem

into distinct, nonoverlapping issues while making sure that no

issues relevant to your problem have been overlooked.

Don’t reinvent the wheel. McKinsey has leveraged its experience

with structured problem solving through numerous frameworks

that help its consultants rapidly visualize the outlines of

many common business situations. Your organization may have its

own frameworks, and you should take advantage of them if possible.

Otherwise, develop your own problem-solving tool kit based

on your experience.

Every client is unique. Frameworks are not magic bullets.

McKinsey-ites know that every client is unique. Simply trying to

squeeze every organization’s problems through the appropriate

frameworks will only get you so far. If anything, this lesson is doubly

true for McKinsey-ites once they leave the Firm.

LESSONS LEARNED AND IMPLEMENTATION

ILLUSTRATIONS

How does McKinsey’s structured problem-solving approach fare

beyond the specific conditions of the Firm? Extremely well. Our discussions with McKinsey alumni have led us to several specific

conclusions about the suitability and adaptability of structured

thinking:

• Without structure, your ideas won’t stand up.

• Use structure to strengthen your thinking.

Let’s see what these lessons look like in practice.

Without structure, your ideas won’t stand up. Think about

your company and the way you and your colleagues formulate and

present business ideas. Do you use a consistent structure or at least

emphasize the need for internal coherence and logic in your problem

solving? Or do people usually arrive at decisions ad hoc,

without a recognizable structure or factual support? When

McKinsey-ites exit the Firm, they are often shocked by the sloppy

thinking processes prevalent in many organizations.

Most of us are not blessed from birth with the ability to think

in a rigorous, structured manner; we have to learn how. Unfortunately,

that skill is not part of most university curricula, and few

companies have the resources or the inclination to teach it to their

employees. McKinsey and some other strategy-consulting firms are

exceptions to this pattern. Even some of the most highly regarded

companies in American business don’t always stress structured

problem solving, as Bill Ross learned when he joined the Transportation

Division of General Electric:

GE people move quickly when new situations arise. It’s part

of the culture. The mind-set seems to be “once we have identified

an issue, let’s wrestle it to the ground and move

quickly,” and they’re great at doing it. Rarely do people take

the time to examine the issue and develop a clear plan of

action. The structured approach really surprises a lot of peo-

ple. I think just focusing people on that has allowed me to

add value.

Many highly successful organizations don’t apply structured

thought even to their core competencies, as Paul Kenny describes

at GlaxoSmithKline:

From a scientific point of view, a lot of the research organization

is rather serendipity led: you invest in research, you

may have a direction, but often that direction will change

as a result of information you find. Some of the best drugs

on the market today were found more by luck than by

design. Then, thinking back, we realize that we could have

redesigned these clinical trials in a way to shape the product

more appropriately for the market. There are concrete examples

of ways to increase value by making more-commercial

marketing decisions earlier on in the pipeline, and designing

products from the very beginning to have the right characteristics,

rather than just letting them evolve from the R&D

pipeline however they emerge.

If structured thinking is hard to find at GE and GlaxoSmith-

Kline, two of the world’s most respected and successful companies,

one can imagine that it may be a pretty rare coin in many

organizations.

Further complicating matters, the corporate cultures of some

organizations have been imbued with the wrong types of structure.

In another example from GlaxoSmithKline, a linear, deductive

thought process got in the way of sound decision making:

We have a project leader who wants to switch his drug from

its current twice-a-day formulation to a once-a-day formulation.

The drug is at an early stage in research, and it’s a standard rule that once a day is better than twice a day. It’s

easier for people to take, so ultimately there’s a marketdriven

push to develop the once-a-day dosage. He has presented

this as a binary decision: either we invest in it, or we

don’t. But the idea of thinking through the various options

that might really be possible in a MECE way, opening out all

the possibilities and then considering or rejecting them independently,

hasn’t really occurred to him.

In fact, there are a number of options, including launching

as a twice-a-day formulation, getting through a lot of the

development risk that way, then moving to a once-a-day formulation

once the drug has proved efficacious and marketable.

Taking the all-or-nothing approach may not

necessarily be the best way to create value; the incremental

sales may not be worth the incremental costs and risks.

Between inappropriate thinking processes and the complete

absence of structured thought, there appears to be a lot of room for

someone with a McKinsey Mind to add value.

Use structure to strengthen your thinking. In all sorts of

places—whether huge corporations, new economy start-ups, or

even nonbusiness organizations such as nonprofits and government

agencies—McKinsey-ites have been able to apply structured

thinking in ways that allow them to add value to their organizations.

For example, making strategic decisions requires understanding

the capabilities of your organization and how to utilize

those capabilities to maximize performance. That’s what Jim Bennett

did during his tenure as chairman of retail banking at Key

Corp.:

I became chair of the retail bank at a time when we really

needed to grow our operation. It was a third of the company,

and we had to grow at 10 percent per year for the rest of the

company to do well. I had to determine whether that was possible or not. Of course, this depended on understanding

how good we were. The only way I could come to grips with

that was to lay out an issue tree.* By the time I was done, I

had a MECE issue tree with all the branches covered by

yes/no questions. That proved very useful to me as the line

manager and chief strategist of Key Corp.’s largest business

in making sure that we were on the right track with our performance

improvement program.

I did it myself and then exposed others to it and the general

idea behind it. The issue tree in and of itself probably

strikes people as a bit “consultanty,” but when I’ve been able

to translate it into a communicable message, it’s never failed

me in any setting, anywhere.

Another example of the successful application of McKinsey

frameworks in a large organization comes from Bill Ross, who was

then at GE:

The biggest “framing the problem” issue I found involved

the big question, “Do we know where we are going in the

long term and have we developed our growth strategy?” The

answer in many cases was no. I worked individually with

some of the other general managers and then actually used

McKinsey to put together a workshop with the senior leadership

team to talk explicitly about our growth strategy. This

allowed me to start feeding them information and expose

them to some of the previous frameworks that I learned at

McKinsey. When they saw those, it triggered light bulbs in

their heads.

Large, cash-rich corporations might seem the ideal place to

apply McKinsey techniques. After all, most of McKinsey’s clients

fit that description. What might surprise you, however, is how effective these same techniques can be in the short-of-cash, shortof-

time, short-of-people environment of a New Economy start-up,

as Omowale Crenshaw discovered at Africa.com, a Web portal for

the African continent:

We had to survey the marketplace and decide how to

develop products and services for our particular target markets:

African ex-pats and the “Africa-interested.” That

meant analyzing a number of industries such as African

wine, or African home-decorative accessories, furniture, and

art, and making a decision as to which of them would be sufficiently

attractive to our target markets. By allowing us to

come to grips quickly with the market sizes, the competitive

environment, the key players, etc., the structural frameworks

that I learned at the Firm helped us decide which of these

markets made sense for us.

Structuring your thinking can add value outside the confines of

the business world. Sylvia Mathews was deputy chief of staff to

President Clinton, so she should know:

Problem solving at the federal government level tends to be a

little more complicated than in the business world, in that it

involves things that are less tangible than valuation of companies,

profit, loss, etc. But the same techniques still apply.

When I was in charge of the State of the Union production in

1996, in August (the President delivers the State of the Union

address in January), I started by doing something that I

called the Pillars Project. It covered every area of the State

of the Union and put all our policy examples together in the

same framework and with the same approach to show what

we were going to try to achieve over the second four years.

We then assembled them into documents that the President

and Vice President could respond to over their vacations. We framed the issue very clearly: What is the problem?

What are its dimensions? What are we going to do? And it

laid out a number of things that we could try in a limited

way to increase our chances of success. We covered the various

issues stemming from each problem: you might want

to do something, but is it achievable, do we have the

resources financially, can we get the congressional support,

and what are the political ramifications?

Now that you’ve seen how useful structured thinking can be

in almost any sort of organization, let’s discuss how you can apply

it in your own business and career.

IMPLEMENTATION GUIDANCE

As we’ve seen, structured thinking is an important element in any

businessperson’s problem-solving arsenal. How should you use this

weapon? First, you must understand that structure doesn’t exist

in a vacuum; you have to wield it with a goal in mind. In the context

of framing and solving business problems, your goal is to

bring order out of chaos.

Today’s executives and entrepreneurs have access to far more

information than they can possibly use. They can manage this surfeit

of data only by filtering out all but the most relevant facts. The

appropriate structured framework will allow you to do this much

more efficiently, thereby increasing the probability that you will

arrive at a solution in a reasonable amount of time—and add value

to your business. As Omowale Crenshaw observes:

One of the things that was very clear from my McKinsey

experience—and this definitely applies in an entrepreneurial

environment—was that the skill set that I have allows me

to make some sense of ambiguity, of all the possible paths we could take. We have limited resources and limited funds, so

we can’t go everywhere; we have to start following these

paths one at a time. A framework helps you prioritize your

options. We save so much time and energy by not going

down the wrong path. That’s the key. Not necessarily knowing

what the right path is, but not going too far down the

wrong one.

The role of senior management in this is to structure “reality”

in order to make it easily graspable. Executives do this by defining

the scope of the problem at hand in order to see all its ramifications—

the links to other factors and the whole scope of

consequences. They can then disregard unimportant factors and

concentrate on prioritizing the options available to the organization.

This allows them to communicate the (potentially complex)

problem and its solution in easily understandable terms, to make it

clear to those who need to execute management’s directives.

We will examine gathering the data and communicating the

solution in later chapters, so let’s turn now to defining and simplifying

the problem. In the generic approach to framing the problem,

McKinsey-ites put this concept into practice by breaking the problem

before them into its component elements. Why? In most cases,

a complex problem can be reduced to a group of smaller, simpler

problems that can be solved individually. The problems McKinsey

handles are either extremely complex (“How can we maintain

shareholder value in the face of competitive pressure and union

demands when our core market is shrinking?”) or stated so

broadly as to be insoluble without further clarification (“How do

we make money in our industry?”). Separating out the individual

pieces of the problem will make it easier for you and your team to

identify the key drivers of the problem (see Chapter 2) and focus

your analysis accordingly.

This technique works not only for business problems, but also

for complex problems in other realms, such as politics. For

instance, Francesco Grillo, formerly with McKinsey’s Rome office,

is now a public-sector consultant and policy adviser to the Italian

government. He used these same techniques with great success on

problems such as unemployment in the European Union, reform of

the Italian electoral system, and the evaluation of the economic

impact of programs funded by the European Commission.

The most common tool McKinsey-ites use to break problems

apart is the logic tree, a hierarchical listing of all the components of

a problem, starting at the “20,000-foot view” and moving progressively

downward. As an illustration, let’s look at that fine old

blue-chip firm Acme Widgets. Let’s suppose that Acme’s board has

called your team in to help answer the basic question “How can

we increase our profits?” The first question that might pop into

your head upon hearing this is, “Where do your profits come

from?” The board answers, “From our three core business units:

widgets, grommets, and thrum-mats.”

“Aha!” you think to yourself, “that is the first level of our logic

tree for this problem.” You could then proceed down another level

by breaking apart the income streams of each business unit, most

basically into “Revenues” and “Expenses,” and then into progressively

smaller components as you move further down the tree. By

the time you’ve finished, you should have a detailed, MECE map

of Acme Widgets’ business system, along the lines of Figure 1-1

(page 12).

Remember, when you are drawing a logic tree, there may be

several ways to break apart a problem. Which one you choose will

affect the way you view the problem and can either reveal or

obscure critical issues for your team. For instance, instead of drawing

your logic tree of Acme Widgets with an organizational hierarchy

(by business unit), you might want to look at it from a

functional perspective (production, sales, marketing, research, ful-

fillment, etc.). This perspective could point your team in other,

potentially useful directions. Just make sure, whichever view you

take, that your logic tree is MECE, so that you miss nothing and

avoid confusion.

In a real-life example of a logic tree at work, Naras Eechambadi,

when he went to First Union after leaving McKinsey, had to

put together the business case for his customer information management

unit in order to get funding approved by the president of

the corporation:

The question boiled down to, “If we are going to produce a

return on investment for the company based on how we

build and leverage customer information, where are the

sources of revenue and profit? Where is the money going to

come from?” I came up with a MECE breakdown showing

how we could make money by adding or selling more products

and generating more revenue from existing customers,

cutting costs to serve the existing customers, reducing the

attrition of existing customers, or being much more effective

and efficient in bringing on new customers. And I was able to bounce around the problem and say for each of the

pieces, “How much more money can be expected? What is

the economic benefit? And at the end of the day, what is the

cost of doing all these things?” That’s how I built my business

case, by breaking down and reconstructing the problem,

figuring out where the pieces were.

The logic tree is one framework among many that McKinsey

consultants use and an especially popular one for them to take

with them when they leave the Firm. Like any framework, it helps

you clear away the clutter of a complex problem and bring order

out of chaos by building a simplified representation of the real

world. Jeff Sakaguchi, who left McKinsey’s Los Angeles office to

become a partner at Accenture, sums up the usefulness of the

frameworks he learned at the Firm:

The whole framework-driven approach is really trying to

think about, “How could you organize this?” Every framework—

all the way down to the simple two-by-two matrices

we use day in, day out—are an attempt to frame the problem

around some nifty set of three, four, or five balls or boxes

or triangles or whatever you need to create a simple representation

of a complex problem. McKinsey was masterful

at that. I’ve really tried to adapt that for my work.

When employing logic trees or any framework, bear in mind

your eventual audience. Tailor your presentation of that framework

accordingly. As Bill Ross discovered at GE:

I find that, although frameworks work great internally at

McKinsey, when you go outside McKinsey you have to be

careful about their use. Many people will see a framework

and automatically start getting defensive. We heard it a lot at

McKinsey: “Oh, you’re taking an approach that you used on somebody else’s problems and trying to apply it to me. My

problems are different.” We knew that wasn’t the case; we

were just trying to get the thoughts started, giving ourselves

a systematic checklist for what the key issues are and how

to present those key issues. You have to be careful about

introducing frameworks because they can carry a fairly negative

connotation, especially if they are overused. Instead of

reusing an old framework, use the concepts from the framework

to generate new ideas that help solve the problem at

hand.

Finally, remember that structure is only the beginning. You still

need to develop a strong hypothesis, devise and perform the right

analyses to draw your conclusions, and communicate those conclusions

effectively. We will address these issues further on in the

book, beginning in the next section of this chapter, with formulating

the initial hypothesis.

EXERCISES

• If you can, think of some frameworks that are commonly

used in your business or that you learned elsewhere. Can

you apply them to your current work? If not, how could

you apply them?

• Look at your organization. Can you lay out your sources

of profit in a MECE logic tree? How about the process by

which you generate products or deliver services?

• Think of a common, but complex, nonbusiness process,

say, a wedding or a vacation. Can you come up with a

MECE structuring of all the tasks that need to be done in

order for this process to work? What are the key elements

of the process (e.g., for a wedding, getting the guests there

on time, making sure the groom shows up)? Write them

out in the form of a logic tree. Can you come up with a different

grouping—say, by responsibility—that is still

MECE?

HYPOTHESIS

Having reduced the problem to its essential components through

the use of appropriate frameworks, you are ready to embark on the

next step in the process of framing it: forming a hypothesis as to its

likely solution. McKinsey believes, and the experiences of McKinsey

alumni demonstrate, that using an initial hypothesis to guide

your research and analysis will increase both the efficiency and

effectiveness of your decision making.

THE McKINSEY WAY

As we did with structure, let’s begin our exploration of using

hypotheses by recapping the relevant principles espoused by

McKinsey.

Solve the problem at the first meeting. McKinsey-ites learn that

it is much more efficient to analyze the facts of a problem with the

intent of proving or disproving a hypothesis than to analyze those

facts one by one to determine which answer they will eventually

provide. For a start, a hypothesis provides you and your team with

a problem-solving road map that will lead you to ask the right

questions and perform the correct analyses to get to your answer.

A good hypothesis will also save you time by pointing out potential

blind alleys much more quickly and allowing you to get back

to the main issues if you do go down the wrong path.

You generate your initial hypothesis by drawing conclusions

based on the limited facts that you know about the problem at

hand without doing a lot of additional research. For a consultant

new to the industry in question, this might mean spending a few

hours reading press articles and annual reports; someone with

plentiful industry experience might just jot down a few preliminary

thoughts. Ideally, you would then spend an hour or two meeting

with your teammates and hashing out some likely answers to the

problem.

Your next step is to figure out which analyses you have to perform

and which questions you have to ask in order to prove or disprove

your hypothesis. One way to lay out these questions is with

an issue tree. The issue tree, a species of logic tree in which each

branch of the tree is an issue or question, bridges the gap between

structure and hypothesis.* Every issue generated by a framework

will likely be reducible to subissues, and these in turn may break

down further. An issue tree is simply the laying out of issues and

subissues into a MECE visual progression. By answering the questions

in the issue tree, you can very quickly determine the validity

of your hypothesis.

Proper prior preparation. McKinsey teams rely on brainstorming

to develop and test their initial hypotheses. Brainstorming

McKinsey-style, however, requires that all the team members come

to the meeting prepared, having absorbed all the facts currently

known to the team and having spent some time thinking about

their implications. Sometimes, especially for team leaders, it helps

if individuals have their own initial hypotheses already developed,

so that the team can bat them around, but it’s not essential. Just

don’t come into the meeting thinking you know the “answer.” Be

prepared to learn.

In a white room. Brainstorming is about generating new ideas.

Check your preconceptions at the door. Everyone in the meeting

must be able to speak his mind and share his knowledge. For your

brainstorming sessions to succeed, you should follow these rules:

First, there are no bad ideas. Second, there are no dumb questions.

Third, be prepared to “kill your babies” (i.e., to see your ideas get

shot down, and to pull the trigger yourself if necessary). Fourth,

know when to say when; don’t let brainstorming drag on past the

point of diminishing returns. Last and most important, get it down

on paper.

The problem is not always the problem. Every consultant faces

the temptation of taking the client’s diagnosis of his problem at

face value. Resist this temptation. Just as a patient is not always

aware of the meaning of his symptoms, so are managers sometimes

incorrect in their diagnoses of what ails their organizations.

The only way to determine whether the problem you have been

given is the real problem is to dig deeper, ask questions, and get the

facts. A little skepticism early on in the problem-solving process

could save you a lot of frustration further down the road. What’s

more, you will be doing your client a service by getting to the real

problem, even if, sometimes, your client doesn’t like it.

LESSONS LEARNED AND IMPLEMENTATION

ILLUSTRATIONS

For McKinsey alumni, hypothesis-based decision making has

proved extremely portable. It doesn’t require a lot of resources to

implement; it can be done in teams but, if need be, also on one’s

own; and it is applicable across a wide spectrum of problems. Our

questioning of former McKinsey-ites has produced two good reasons

why you should rely on an initial hypothesis in your own

problem-solving efforts:

• An initial hypothesis will save you time.

• An initial hypothesis will make your decision making more

effective.

An initial hypothesis will save you time. Most people, when

faced with a complex problem, will start at the beginning and

wade through all the data until they come to the end—the solution.

This is sometimes referred to as the deductive approach: if A, then

B; if B, then C; . . . if Y, then Z. When you form an initial hypothesis,

you leap all the way to Z, and it’s easier to work your way

backward from Z to A. One simple example of this is a pen-andpaper

labyrinth or maze, the kind you sometimes see in the Sunday

comics or in puzzle books. Anyone who plays with these can tell

you that it is easier to solve the maze by tracing the route from the

finish to the start rather than starting at the beginning. One reason

for this is that by already knowing where your solution is, you

eliminate a lot of paths that lead to dead ends.

Forming an initial hypothesis will allow you to work through

the labyrinth of your business problem more quickly. It saves you

time partly because it allows you to start drawing conclusions

based on limited information—which, at the beginning of the

problem-solving process, is usually what you have. This holds

especially true when you are trying to break new ground where

nobody has the information you seek, as Omowale Crenshaw discovered

when figuring out how to open up Africa to E-commerce:

Sometimes at McKinsey we had the luxury of leveraging so

much data—the whole analysis paralysis—that we didn’t do

anything, nor did our clients. When we were starting our

Web portal, we had to figure out what mattered when we

really didn’t have enough data on one side or the other. We

just had to say, “OK, realistically, what do we know about

the largest three or four or five markets? What are our guesstimates about them?” We were figuring it out on the

back of an envelope, trying to be mostly right versus precisely

wrong, and making some hypotheses from that. We

would say, “OK, if we assume that the market size is X,

what do we have to believe?”

Then the process became iterative: “We think the market

size is X, and if the market size is X, then Y must be true,” so

we went and looked at Y. As we started doing that, it

became much more apparent that we were on the right

track. We’re still struggling with the actual size of the market,

but we feel much more comfortable that we’ve done the

actual due diligence as it relates to tapping into any and

every resource we could think of.

Finally, an initial hypothesis saves you time by forcing you and

your team to focus only on those issues that can prove or disprove

it. This is especially helpful for those who have trouble focusing

and prioritizing. You may even know of a few such individuals in

your own organization.

An initial hypothesis will make your decision making more

effective. Not only does the hypothesis-driven approach make your

problem solving faster and more efficient, it allows you to assess

multiple options quickly. As a result, your decision making

becomes more flexible and therefore more effective. As CEO of a

brand-name consumer goods manufacturer, McKinsey alumnus

Bob Garda, now a member of the marketing faculty at the Fuqua

School of Business at Duke University, used a strong initial hypothesis

that went against his company’s conventional wisdom to turn

around its core business:

We were selling products that had been around for 20 years

and faced a lot of price pressure from Wal-Mart, Kmart, and

Target—our three biggest customers. They kept threatening to go to suppliers in China or India unless we lowered our

prices. We had four alternatives: (1) reduce costs to match

China and India, (2) buy from China and India and resell to

our customers, (3) introduce new products (one of which

was close at hand), or (4) do a combination of the above. My

hypothesis was that we could best minimize the price pressure

by introducing new products. Sure enough, when we

walked into the Big 3 to introduce the new product, they

were excited; we could practically charge whatever we

wanted. After that, they were much less concerned about

beating us up on price, even on the established products, as

long as we kept generating new products. Therefore, the

hypothesis worked out.

Bob compared his hypothesis against other options available to

his company:

We could have taken one of the other approaches and tried

to cut costs to beat India and China. In fact, several of our

key managers thought cost reduction was the only answer, as

it had been in the past. Well, good luck; you can’t beat China

and India on costs with U.S.–made products. Naturally, cost

reduction was part of the answer for the long term; we

launched a cost reduction effort, but we never got down to

Chinese or Indian costs.

The other option, purchasing from China and India and

reselling to Kmart, Wal-Mart, and Target, while popular

with a small faction of management, made no sense to me.

All we would be doing was setting up a distribution system

for the Asian manufacturers and, once established, they

would go directly to the buyers and cut us out. Because of

constant price pressure, this option will continue to be on the table, but as long as we have other values to offer the Big 3,

the better off we are going to be.

The increased effectiveness of hypothesis-based decision making

stems from the lesson that “the problem is not always the problem.”

That’s what Dominic Falkowski found out when he moved

to Egon Zehnder’s Warsaw office:

My client was looking for a CFO because the current manager

was not coping well enough with reporting and investment

analysis, and he was having problems with his team.

We weren’t so sure this was the case. After an analysis of the

situation, including an assessment of the CFO, we realized

that it was the CEO who was not structured, changed opinions

and processes too often, and did not communicate

changes throughout the organization. The CFO was partly

to blame, however, as he had poor interpersonal skills and

did not cope well with any form of feedback.

We suggested some internal reengineering to be conducted

by a strategic consultancy, and we ourselves coached

the CFO and CEO. The result: solved problem, happy client

and CFO, and a prospering organization. Further, we proved

that an external search would not have brought the value the

client wanted.

IMPLEMENTATION GUIDANCE

Forming an initial hypothesis will make your problem solving

more efficient and more effective, but to reap these benefits, you

need to be able to generate and test robust hypotheses. Since you

should form your hypothesis at the start of the problem-solving

process, you have to rely less on facts (you won’t have done most of your fact gathering yet) and more on instinct or intuition. Take

what you know about the problem at hand, combine it with your

gut feelings on the issue, and think about what the most likely

answers are. This does not mean that the most likely answer is necessarily

the correct one, but it’s a good starting point.

If something leaps out at you immediately, congratulations;

you’ve just formed a hypothesis. At this point, whether you are

alone at your desk, standing under the shower (alone or otherwise),

or in a brainstorming session with your team, you should do

the Quick and Dirty Test (QDT) of your hypothesis. The QDT is

simply this: what assumptions are you making that need to be true

in order for your hypothesis to be true? If any of these assumptions

is false, then the hypothesis is false. Much of the time, you can

knock out false hypotheses in just a few minutes with the QDT.

This is especially useful when you need to choose from a few

options quickly, as Ciara Burnham, now a venture capitalist at

Evercore Partners, can attest:

So much of my job involves triaging potential investment

opportunities to figure out which ones are worth spending

time on. At the outset of any deal evaluation, I ask, “What

do I need to believe in order for this to be a good investment,

and what are the ways in which this investment could blow

up? Therefore, what analysis do I need to do to support/

reject the investment and to dimension the risks?” Sounds

like a simple approach, but frankly one that many people

trained in the deal execution side of the business don’t take.

As an example, let’s go back to Acme Widgets. Yesterday, the

board told you and your team to figure out a way to lower the

marginal cost of Acme’s venerable line of thrum-mats. Today, in

the first few minutes of your brainstorming session, you’ve come

up with a few options that might make the cut: (1) You might pressure your suppliers to lower your raw-materials costs. (2) You

could cut the workforce at your thrum-mat manufacturing facilities

while maintaining production levels. (3) You might reduce the

time that the thrum-mats spend in the curing process, thereby

increasing throughput. Now you are going to put each option to

the QDT.

Pressuring your suppliers would be great, but can it be done?

What needs to be true for that option to work? Well, you might

say, raw materials should be a significant factor in total thrum-mat

cost; otherwise, reducing the cost of raw materials wouldn’t make

much difference in the total marginal cost of a finished thrum-mat.

As it happens, one of your team knows that raw thrums make up

about 35 percent of the total cost of a thrum-mat, so there should

be some mileage there. Next, you would need to have some pricing

leverage with your suppliers. Unfortunately, on page A2 of this

morning’s Wall Street Journal, there is a story about the newly

announced takeover of General Thrums by Allied Thrums and

Bezels. Analysts expect the merger to result in a significant reduction

in total thrum production capacity, with corresponding

upward pressure on wholesale thrum prices. So much for that idea.

What about reducing manufacturing head count? Labor is a

large component of the total cost of thrum-mat production, so that

would seem a fruitful area for exploration. The key question then

is whether Acme’s production facilities are overstaffed. One way to

determine this is by learning whether Acme’s per-worker productivity

is low relative to the industry. You recall seeing the results

of a recent benchmarking study on thrum-mat production. That

study put Acme significantly ahead of its competitors in perworker

output. Another dead end.

That leaves reducing the time that thrum-mats spend in the

curing process. Traditionally, Class A thrum-mats spend at least

two weeks in the curing locker—an expensive proposition that not only uses a lot of energy, but also ties up inventory, thereby unnecessarily

swelling Acme’s balance sheet. A reduction in curing time

could thus have a double benefit. Not only would it boost Acme’s

profit line, it also would reduce work-in-progress inventory. What

needs to be true to make this feasible? As a first cut, the question

would seem to be whether it is possible to make Grade A thrummats

without a full two-week cure. Coincidentally, one of your

team has just read an article in Thrum-mat Manufacturing Weekly

on a new curing process that utilizes special temperature, humidity,

and atmospheric controls and that produces the same or better

results as traditional curing methods.

Excellent! Your team has now found an initial hypothesis that

passed the QDT.* Your next step will be to test your hypothesis

more thoroughly and, if necessary, refine it. To accomplish these

goals, you should now put together an issue tree.

An issue tree is the evolved cousin of the logic tree. Where a

logic tree is simply a hierarchical grouping of elements, an issue

tree is the series of questions or issues that must be addressed to

prove or disprove a hypothesis. Issue trees bridge the gap between

structure and hypothesis. Every issue generated by a framework

will likely be reducible to subissues, and these in turn may break

down further. By creating an issue tree, you lay out the issues and

subissues in a visual progression. This allows you to determine

what questions to ask in order to form your hypothesis and serves

as a road map for your analysis. It also allows you very rapidly to

eliminate dead ends in your analysis, since the answer to any issue

immediately eliminates all the branches falsified by that answer.

Dan Veto found issue trees especially useful when defining a set

of initiatives for the E-business arm of Conseco, one of America’s

largest diversified financial services companies:

In problem solving, a lot of people try to be uniformly complete.

The fact is, you don’t always have to be. You want to

think of everything as MECE, but you don’t need to investigate

everything to the same depth. For example, we were

thinking about our E-business strategy, as we had just

formed a new business unit, eConseco. This would be a

stand-alone business with a real P&L, so we had to ask ourselves,

“What are the key levers of profitability and growth?

Which things matter, and which things don’t?”

We were inundated with ideas. Somebody on the revenue

side would say, “Well, we could sell books.” Being able

to figure out quickly that that option is never going to make

you any money is critical. Being able to snip from the tree the

branches that don’t matter so that we’re focused on the

branches that do matter is just an unbelievable problemsolving

and problem-framing skill that is not necessarily

intuitive but which can really speed the problem-solving

process.

Going back to your team room at Acme Widgets, what would

an issue map look like for reducing the thrum-mat curing process?

As you and your team discuss it, several questions arise: Will it

actually save money? Does it require special skills? Do we have

those skills in the organization? Will it reduce the quality of our

thrum-mats? Can we implement the change in the first place?

When laying out your issue tree, you need to come up with a

MECE grouping of these issues and the others that arise. As a first step, you need to figure out which are the top-line issues, the issues

that have to be true for your hypothesis to be true. After a bit of

brainstorming, you isolate three questions that address the validity

of your hypothesis: Will shortening the curing process reduce our

costs? Can we, as an organization, implement the necessary

changes? If we implement this change, can we maintain product

quality? Put these issues one level below your hypothesis, as shown

in Figure 1-2.

Unfortunately, the answer to each of these questions lies in several

more questions. You will have to answer those in turn before

you can come up with a final yes or no. As you take each question

down one or more levels, your analysis road map will begin to take

shape. Let’s drill down on one of these issues and see where it

leads us.

The issue “Can we implement the necessary changes?” throws

off numerous subsidiary questions (see Figure 1-3). Some of them

came out in the initial brainstorming, while others will arise when

you spend more time thinking specifically about the issue. Just as

you did for the main issue, you need to figure out the logical progression

of these questions. For the sake of this exercise, let’s say

there are two top-line questions for this issue: (1) Does the new,

shorter process require special facilities that we don’t have? (2)

Does it require special skills that we don’t have? For both of these

questions, the ideal answer, “no,” shuts down any further inquiry.

If, however, the answer to either of these questions is yes, the

hypothesis is not immediately invalidated. Rather, this answer

raises additional questions that must be answered. For example,

in the case of facilities, you would ask, “Can we build or buy them?” If the answers to these questions lower down the tree turn

out to be no, then your hypothesis is indeed in jeopardy.

At this point, the process of laying out an issue tree should be

clear to you. If you’ve done it, then you have sketched out the tasks

that you will need to fulfill in terms of research and analysis—subjects

that we will address in the following chapters.

The McKinsey technique of hypothesis-driven problem solving—

solving the problem at the first meeting—has proved to be

an excellent decision-making skill beyond the confines of the Firm.

If you spend some up-front time combining your initial fact base

with your gut instinct, you will enable yourself to come to a more

robust solution sooner. A little bit of time spent weeding out

invalid hypotheses at the outset and then determining the scope of

your analysis with an issue tree will save you time and improve

your results.

EXERCISES

• Think about a nonbusiness issue about which you hold a

strong view (e.g., gun control, evolution, global warming).

List the assumptions that you are making with regard to

your position. Are they all true? What information or

analyses would you need to support your view?

• If you haven’t already, come up with a couple of likely

hypotheses for whatever issue you are currently working

on in your job. Can you come up with one or two things

that must be true for each hypothesis to be valid? Now

subject each hypothesis to the QDT.

\CONCLUSION

By using structured frameworks to create an initial hypothesis, you

will enable yourself and your team to select the analyses and areas

of research that will allow you to reach a robust conclusion in the

shortest possible time. In the next chapter, we will look at how to

plan an analysis to prove or disprove your hypothesis in the shortest

time possible.

This page intentionally left blank.

The ability to frame business problems to make them susceptible

to rigorous fact-based analysis is one of the core skills of

a McKinsey consultant. More than that, it is the hallmark of

a McKinsey-ite: if you can’t solve problems in a structured,

hypothesis-driven manner, you’re unlikely to make it through the

door of the Firm.

Data

Intuition

Managing

• Team

• Client

• Self

Presenting

• Structure

• Buy-in

Analyzing

• Framing

• Designing

• Gathering

• Interpreting

The McKinsey problem-solving process begins with the use of

structured frameworks to generate fact-based hypotheses followed

by data gathering and analysis to prove or disprove the hypothesis.

A hypothesis greatly speeds up your quest for a solution by sketching

out a road map for research and analyses that will guide your

work throughout the problem-solving process, all the way to the

presentation of your solution. Given the value of this methodology

to Firm alumni in their post-McKinsey careers, we begin with an

examination of ways to adapt that process to businesses beyond

the Firm.

In this chapter, we will show you how to apply structure to

your business problems and how to go about devising initial

hypotheses that will speed up your own decision making. Because

structure is the basis for the McKinsey problem-solving process,

let’s start there.

STRUCTURE

Although McKinsey & Company often uses the term fact-based

to describe it, the McKinsey problem-solving process begins not

with facts but with structure. Structure can refer to particular

problem-solving frameworks or more generally to defining the

boundaries of a problem and then breaking it down into its component

elements. With either approach, structure allows McKinsey

consultants to come rapidly to grips with the issues facing them

and enables them to form initial hypotheses about possible solutions.

The benefits of structure transfer readily beyond the confines

of the Firm, as our alumni have shown. The facts, as we will see,

come later.

THE McKINSEY WAY

Let’s start by summarizing the ways McKinsey consultants apply

structure to their business problems.

Feel free to be MECE. Structure is vital to McKinsey’s factbased

problem-solving process. For McKinsey-ites, structure is less

a tool and more a way of life. One Firm alumnus summed up his

McKinsey experience as “Structure, structure, structure. MECE,

MECE, MECE.” The concept of MECE (pronounced “mee-see”

and an acronym for Mutually Exclusive, Collectively Exhaustive),

is a basic tenet of the McKinsey thought process. Being MECE in

the context of problem solving means separating your problem

into distinct, nonoverlapping issues while making sure that no

issues relevant to your problem have been overlooked.

Don’t reinvent the wheel. McKinsey has leveraged its experience

with structured problem solving through numerous frameworks

that help its consultants rapidly visualize the outlines of

many common business situations. Your organization may have its

own frameworks, and you should take advantage of them if possible.

Otherwise, develop your own problem-solving tool kit based

on your experience.

Every client is unique. Frameworks are not magic bullets.

McKinsey-ites know that every client is unique. Simply trying to

squeeze every organization’s problems through the appropriate

frameworks will only get you so far. If anything, this lesson is doubly

true for McKinsey-ites once they leave the Firm.

LESSONS LEARNED AND IMPLEMENTATION

ILLUSTRATIONS

How does McKinsey’s structured problem-solving approach fare

beyond the specific conditions of the Firm? Extremely well. Our discussions with McKinsey alumni have led us to several specific

conclusions about the suitability and adaptability of structured

thinking:

• Without structure, your ideas won’t stand up.

• Use structure to strengthen your thinking.

Let’s see what these lessons look like in practice.

Without structure, your ideas won’t stand up. Think about

your company and the way you and your colleagues formulate and

present business ideas. Do you use a consistent structure or at least

emphasize the need for internal coherence and logic in your problem

solving? Or do people usually arrive at decisions ad hoc,

without a recognizable structure or factual support? When

McKinsey-ites exit the Firm, they are often shocked by the sloppy

thinking processes prevalent in many organizations.

Most of us are not blessed from birth with the ability to think

in a rigorous, structured manner; we have to learn how. Unfortunately,

that skill is not part of most university curricula, and few

companies have the resources or the inclination to teach it to their

employees. McKinsey and some other strategy-consulting firms are

exceptions to this pattern. Even some of the most highly regarded

companies in American business don’t always stress structured

problem solving, as Bill Ross learned when he joined the Transportation

Division of General Electric:

GE people move quickly when new situations arise. It’s part

of the culture. The mind-set seems to be “once we have identified

an issue, let’s wrestle it to the ground and move

quickly,” and they’re great at doing it. Rarely do people take

the time to examine the issue and develop a clear plan of

action. The structured approach really surprises a lot of peo-

ple. I think just focusing people on that has allowed me to

add value.

Many highly successful organizations don’t apply structured

thought even to their core competencies, as Paul Kenny describes

at GlaxoSmithKline:

From a scientific point of view, a lot of the research organization

is rather serendipity led: you invest in research, you

may have a direction, but often that direction will change

as a result of information you find. Some of the best drugs

on the market today were found more by luck than by

design. Then, thinking back, we realize that we could have

redesigned these clinical trials in a way to shape the product

more appropriately for the market. There are concrete examples

of ways to increase value by making more-commercial

marketing decisions earlier on in the pipeline, and designing

products from the very beginning to have the right characteristics,

rather than just letting them evolve from the R&D

pipeline however they emerge.

If structured thinking is hard to find at GE and GlaxoSmith-

Kline, two of the world’s most respected and successful companies,

one can imagine that it may be a pretty rare coin in many

organizations.

Further complicating matters, the corporate cultures of some

organizations have been imbued with the wrong types of structure.

In another example from GlaxoSmithKline, a linear, deductive

thought process got in the way of sound decision making:

We have a project leader who wants to switch his drug from

its current twice-a-day formulation to a once-a-day formulation.

The drug is at an early stage in research, and it’s a standard rule that once a day is better than twice a day. It’s

easier for people to take, so ultimately there’s a marketdriven

push to develop the once-a-day dosage. He has presented

this as a binary decision: either we invest in it, or we

don’t. But the idea of thinking through the various options

that might really be possible in a MECE way, opening out all

the possibilities and then considering or rejecting them independently,

hasn’t really occurred to him.

In fact, there are a number of options, including launching

as a twice-a-day formulation, getting through a lot of the

development risk that way, then moving to a once-a-day formulation

once the drug has proved efficacious and marketable.

Taking the all-or-nothing approach may not

necessarily be the best way to create value; the incremental

sales may not be worth the incremental costs and risks.

Between inappropriate thinking processes and the complete

absence of structured thought, there appears to be a lot of room for

someone with a McKinsey Mind to add value.

Use structure to strengthen your thinking. In all sorts of

places—whether huge corporations, new economy start-ups, or

even nonbusiness organizations such as nonprofits and government

agencies—McKinsey-ites have been able to apply structured

thinking in ways that allow them to add value to their organizations.

For example, making strategic decisions requires understanding

the capabilities of your organization and how to utilize

those capabilities to maximize performance. That’s what Jim Bennett

did during his tenure as chairman of retail banking at Key

Corp.:

I became chair of the retail bank at a time when we really

needed to grow our operation. It was a third of the company,

and we had to grow at 10 percent per year for the rest of the

company to do well. I had to determine whether that was possible or not. Of course, this depended on understanding

how good we were. The only way I could come to grips with

that was to lay out an issue tree.* By the time I was done, I

had a MECE issue tree with all the branches covered by

yes/no questions. That proved very useful to me as the line

manager and chief strategist of Key Corp.’s largest business

in making sure that we were on the right track with our performance

improvement program.

I did it myself and then exposed others to it and the general

idea behind it. The issue tree in and of itself probably

strikes people as a bit “consultanty,” but when I’ve been able

to translate it into a communicable message, it’s never failed

me in any setting, anywhere.

Another example of the successful application of McKinsey

frameworks in a large organization comes from Bill Ross, who was

then at GE:

The biggest “framing the problem” issue I found involved

the big question, “Do we know where we are going in the

long term and have we developed our growth strategy?” The

answer in many cases was no. I worked individually with

some of the other general managers and then actually used

McKinsey to put together a workshop with the senior leadership

team to talk explicitly about our growth strategy. This

allowed me to start feeding them information and expose

them to some of the previous frameworks that I learned at

McKinsey. When they saw those, it triggered light bulbs in

their heads.

Large, cash-rich corporations might seem the ideal place to

apply McKinsey techniques. After all, most of McKinsey’s clients

fit that description. What might surprise you, however, is how effective these same techniques can be in the short-of-cash, shortof-

time, short-of-people environment of a New Economy start-up,

as Omowale Crenshaw discovered at Africa.com, a Web portal for

the African continent:

We had to survey the marketplace and decide how to

develop products and services for our particular target markets:

African ex-pats and the “Africa-interested.” That

meant analyzing a number of industries such as African

wine, or African home-decorative accessories, furniture, and

art, and making a decision as to which of them would be sufficiently

attractive to our target markets. By allowing us to

come to grips quickly with the market sizes, the competitive

environment, the key players, etc., the structural frameworks

that I learned at the Firm helped us decide which of these

markets made sense for us.

Structuring your thinking can add value outside the confines of

the business world. Sylvia Mathews was deputy chief of staff to

President Clinton, so she should know:

Problem solving at the federal government level tends to be a

little more complicated than in the business world, in that it

involves things that are less tangible than valuation of companies,

profit, loss, etc. But the same techniques still apply.

When I was in charge of the State of the Union production in

1996, in August (the President delivers the State of the Union

address in January), I started by doing something that I

called the Pillars Project. It covered every area of the State

of the Union and put all our policy examples together in the

same framework and with the same approach to show what

we were going to try to achieve over the second four years.

We then assembled them into documents that the President

and Vice President could respond to over their vacations. We framed the issue very clearly: What is the problem?

What are its dimensions? What are we going to do? And it

laid out a number of things that we could try in a limited

way to increase our chances of success. We covered the various

issues stemming from each problem: you might want

to do something, but is it achievable, do we have the

resources financially, can we get the congressional support,

and what are the political ramifications?

Now that you’ve seen how useful structured thinking can be

in almost any sort of organization, let’s discuss how you can apply

it in your own business and career.

IMPLEMENTATION GUIDANCE

As we’ve seen, structured thinking is an important element in any

businessperson’s problem-solving arsenal. How should you use this

weapon? First, you must understand that structure doesn’t exist

in a vacuum; you have to wield it with a goal in mind. In the context

of framing and solving business problems, your goal is to

bring order out of chaos.

Today’s executives and entrepreneurs have access to far more

information than they can possibly use. They can manage this surfeit

of data only by filtering out all but the most relevant facts. The

appropriate structured framework will allow you to do this much

more efficiently, thereby increasing the probability that you will

arrive at a solution in a reasonable amount of time—and add value

to your business. As Omowale Crenshaw observes:

One of the things that was very clear from my McKinsey

experience—and this definitely applies in an entrepreneurial

environment—was that the skill set that I have allows me

to make some sense of ambiguity, of all the possible paths we could take. We have limited resources and limited funds, so

we can’t go everywhere; we have to start following these

paths one at a time. A framework helps you prioritize your

options. We save so much time and energy by not going

down the wrong path. That’s the key. Not necessarily knowing

what the right path is, but not going too far down the

wrong one.

The role of senior management in this is to structure “reality”

in order to make it easily graspable. Executives do this by defining

the scope of the problem at hand in order to see all its ramifications—

the links to other factors and the whole scope of

consequences. They can then disregard unimportant factors and

concentrate on prioritizing the options available to the organization.

This allows them to communicate the (potentially complex)

problem and its solution in easily understandable terms, to make it

clear to those who need to execute management’s directives.

We will examine gathering the data and communicating the

solution in later chapters, so let’s turn now to defining and simplifying

the problem. In the generic approach to framing the problem,

McKinsey-ites put this concept into practice by breaking the problem

before them into its component elements. Why? In most cases,

a complex problem can be reduced to a group of smaller, simpler

problems that can be solved individually. The problems McKinsey

handles are either extremely complex (“How can we maintain

shareholder value in the face of competitive pressure and union

demands when our core market is shrinking?”) or stated so

broadly as to be insoluble without further clarification (“How do

we make money in our industry?”). Separating out the individual

pieces of the problem will make it easier for you and your team to

identify the key drivers of the problem (see Chapter 2) and focus

your analysis accordingly.

This technique works not only for business problems, but also

for complex problems in other realms, such as politics. For

instance, Francesco Grillo, formerly with McKinsey’s Rome office,

is now a public-sector consultant and policy adviser to the Italian

government. He used these same techniques with great success on

problems such as unemployment in the European Union, reform of

the Italian electoral system, and the evaluation of the economic

impact of programs funded by the European Commission.

The most common tool McKinsey-ites use to break problems

apart is the logic tree, a hierarchical listing of all the components of

a problem, starting at the “20,000-foot view” and moving progressively

downward. As an illustration, let’s look at that fine old

blue-chip firm Acme Widgets. Let’s suppose that Acme’s board has

called your team in to help answer the basic question “How can

we increase our profits?” The first question that might pop into

your head upon hearing this is, “Where do your profits come

from?” The board answers, “From our three core business units:

widgets, grommets, and thrum-mats.”

“Aha!” you think to yourself, “that is the first level of our logic

tree for this problem.” You could then proceed down another level

by breaking apart the income streams of each business unit, most

basically into “Revenues” and “Expenses,” and then into progressively

smaller components as you move further down the tree. By

the time you’ve finished, you should have a detailed, MECE map

of Acme Widgets’ business system, along the lines of Figure 1-1

(page 12).

Remember, when you are drawing a logic tree, there may be

several ways to break apart a problem. Which one you choose will

affect the way you view the problem and can either reveal or

obscure critical issues for your team. For instance, instead of drawing

your logic tree of Acme Widgets with an organizational hierarchy

(by business unit), you might want to look at it from a

functional perspective (production, sales, marketing, research, ful-

fillment, etc.). This perspective could point your team in other,

potentially useful directions. Just make sure, whichever view you

take, that your logic tree is MECE, so that you miss nothing and

avoid confusion.

In a real-life example of a logic tree at work, Naras Eechambadi,

when he went to First Union after leaving McKinsey, had to

put together the business case for his customer information management

unit in order to get funding approved by the president of

the corporation:

The question boiled down to, “If we are going to produce a

return on investment for the company based on how we

build and leverage customer information, where are the

sources of revenue and profit? Where is the money going to

come from?” I came up with a MECE breakdown showing

how we could make money by adding or selling more products

and generating more revenue from existing customers,

cutting costs to serve the existing customers, reducing the

attrition of existing customers, or being much more effective

and efficient in bringing on new customers. And I was able to bounce around the problem and say for each of the

pieces, “How much more money can be expected? What is

the economic benefit? And at the end of the day, what is the

cost of doing all these things?” That’s how I built my business

case, by breaking down and reconstructing the problem,

figuring out where the pieces were.

The logic tree is one framework among many that McKinsey

consultants use and an especially popular one for them to take

with them when they leave the Firm. Like any framework, it helps

you clear away the clutter of a complex problem and bring order

out of chaos by building a simplified representation of the real

world. Jeff Sakaguchi, who left McKinsey’s Los Angeles office to

become a partner at Accenture, sums up the usefulness of the

frameworks he learned at the Firm:

The whole framework-driven approach is really trying to

think about, “How could you organize this?” Every framework—

all the way down to the simple two-by-two matrices

we use day in, day out—are an attempt to frame the problem

around some nifty set of three, four, or five balls or boxes

or triangles or whatever you need to create a simple representation

of a complex problem. McKinsey was masterful

at that. I’ve really tried to adapt that for my work.

When employing logic trees or any framework, bear in mind

your eventual audience. Tailor your presentation of that framework

accordingly. As Bill Ross discovered at GE:

I find that, although frameworks work great internally at

McKinsey, when you go outside McKinsey you have to be

careful about their use. Many people will see a framework

and automatically start getting defensive. We heard it a lot at

McKinsey: “Oh, you’re taking an approach that you used on somebody else’s problems and trying to apply it to me. My

problems are different.” We knew that wasn’t the case; we

were just trying to get the thoughts started, giving ourselves

a systematic checklist for what the key issues are and how

to present those key issues. You have to be careful about

introducing frameworks because they can carry a fairly negative

connotation, especially if they are overused. Instead of

reusing an old framework, use the concepts from the framework

to generate new ideas that help solve the problem at

hand.

Finally, remember that structure is only the beginning. You still

need to develop a strong hypothesis, devise and perform the right

analyses to draw your conclusions, and communicate those conclusions

effectively. We will address these issues further on in the

book, beginning in the next section of this chapter, with formulating

the initial hypothesis.

EXERCISES

• If you can, think of some frameworks that are commonly

used in your business or that you learned elsewhere. Can

you apply them to your current work? If not, how could

you apply them?

• Look at your organization. Can you lay out your sources

of profit in a MECE logic tree? How about the process by

which you generate products or deliver services?

• Think of a common, but complex, nonbusiness process,

say, a wedding or a vacation. Can you come up with a

MECE structuring of all the tasks that need to be done in

order for this process to work? What are the key elements

of the process (e.g., for a wedding, getting the guests there

on time, making sure the groom shows up)? Write them

out in the form of a logic tree. Can you come up with a different

grouping—say, by responsibility—that is still

MECE?

HYPOTHESIS

Having reduced the problem to its essential components through

the use of appropriate frameworks, you are ready to embark on the

next step in the process of framing it: forming a hypothesis as to its

likely solution. McKinsey believes, and the experiences of McKinsey

alumni demonstrate, that using an initial hypothesis to guide

your research and analysis will increase both the efficiency and

effectiveness of your decision making.

THE McKINSEY WAY

As we did with structure, let’s begin our exploration of using

hypotheses by recapping the relevant principles espoused by

McKinsey.

Solve the problem at the first meeting. McKinsey-ites learn that

it is much more efficient to analyze the facts of a problem with the

intent of proving or disproving a hypothesis than to analyze those

facts one by one to determine which answer they will eventually

provide. For a start, a hypothesis provides you and your team with

a problem-solving road map that will lead you to ask the right

questions and perform the correct analyses to get to your answer.

A good hypothesis will also save you time by pointing out potential

blind alleys much more quickly and allowing you to get back

to the main issues if you do go down the wrong path.

You generate your initial hypothesis by drawing conclusions

based on the limited facts that you know about the problem at

hand without doing a lot of additional research. For a consultant

new to the industry in question, this might mean spending a few

hours reading press articles and annual reports; someone with

plentiful industry experience might just jot down a few preliminary

thoughts. Ideally, you would then spend an hour or two meeting

with your teammates and hashing out some likely answers to the

problem.

Your next step is to figure out which analyses you have to perform

and which questions you have to ask in order to prove or disprove

your hypothesis. One way to lay out these questions is with

an issue tree. The issue tree, a species of logic tree in which each

branch of the tree is an issue or question, bridges the gap between

structure and hypothesis.* Every issue generated by a framework

will likely be reducible to subissues, and these in turn may break

down further. An issue tree is simply the laying out of issues and

subissues into a MECE visual progression. By answering the questions

in the issue tree, you can very quickly determine the validity

of your hypothesis.

Proper prior preparation. McKinsey teams rely on brainstorming

to develop and test their initial hypotheses. Brainstorming

McKinsey-style, however, requires that all the team members come

to the meeting prepared, having absorbed all the facts currently

known to the team and having spent some time thinking about

their implications. Sometimes, especially for team leaders, it helps

if individuals have their own initial hypotheses already developed,

so that the team can bat them around, but it’s not essential. Just

don’t come into the meeting thinking you know the “answer.” Be

prepared to learn.

In a white room. Brainstorming is about generating new ideas.

Check your preconceptions at the door. Everyone in the meeting

must be able to speak his mind and share his knowledge. For your

brainstorming sessions to succeed, you should follow these rules:

First, there are no bad ideas. Second, there are no dumb questions.

Third, be prepared to “kill your babies” (i.e., to see your ideas get

shot down, and to pull the trigger yourself if necessary). Fourth,

know when to say when; don’t let brainstorming drag on past the

point of diminishing returns. Last and most important, get it down

on paper.

The problem is not always the problem. Every consultant faces

the temptation of taking the client’s diagnosis of his problem at

face value. Resist this temptation. Just as a patient is not always

aware of the meaning of his symptoms, so are managers sometimes

incorrect in their diagnoses of what ails their organizations.

The only way to determine whether the problem you have been

given is the real problem is to dig deeper, ask questions, and get the

facts. A little skepticism early on in the problem-solving process

could save you a lot of frustration further down the road. What’s

more, you will be doing your client a service by getting to the real

problem, even if, sometimes, your client doesn’t like it.

LESSONS LEARNED AND IMPLEMENTATION

ILLUSTRATIONS

For McKinsey alumni, hypothesis-based decision making has

proved extremely portable. It doesn’t require a lot of resources to

implement; it can be done in teams but, if need be, also on one’s

own; and it is applicable across a wide spectrum of problems. Our

questioning of former McKinsey-ites has produced two good reasons

why you should rely on an initial hypothesis in your own

problem-solving efforts:

• An initial hypothesis will save you time.

• An initial hypothesis will make your decision making more

effective.

An initial hypothesis will save you time. Most people, when

faced with a complex problem, will start at the beginning and

wade through all the data until they come to the end—the solution.

This is sometimes referred to as the deductive approach: if A, then

B; if B, then C; . . . if Y, then Z. When you form an initial hypothesis,

you leap all the way to Z, and it’s easier to work your way

backward from Z to A. One simple example of this is a pen-andpaper

labyrinth or maze, the kind you sometimes see in the Sunday

comics or in puzzle books. Anyone who plays with these can tell

you that it is easier to solve the maze by tracing the route from the

finish to the start rather than starting at the beginning. One reason

for this is that by already knowing where your solution is, you

eliminate a lot of paths that lead to dead ends.

Forming an initial hypothesis will allow you to work through

the labyrinth of your business problem more quickly. It saves you

time partly because it allows you to start drawing conclusions

based on limited information—which, at the beginning of the

problem-solving process, is usually what you have. This holds

especially true when you are trying to break new ground where

nobody has the information you seek, as Omowale Crenshaw discovered

when figuring out how to open up Africa to E-commerce:

Sometimes at McKinsey we had the luxury of leveraging so

much data—the whole analysis paralysis—that we didn’t do

anything, nor did our clients. When we were starting our

Web portal, we had to figure out what mattered when we

really didn’t have enough data on one side or the other. We

just had to say, “OK, realistically, what do we know about

the largest three or four or five markets? What are our guesstimates about them?” We were figuring it out on the

back of an envelope, trying to be mostly right versus precisely

wrong, and making some hypotheses from that. We

would say, “OK, if we assume that the market size is X,

what do we have to believe?”

Then the process became iterative: “We think the market

size is X, and if the market size is X, then Y must be true,” so

we went and looked at Y. As we started doing that, it

became much more apparent that we were on the right

track. We’re still struggling with the actual size of the market,

but we feel much more comfortable that we’ve done the

actual due diligence as it relates to tapping into any and

every resource we could think of.

Finally, an initial hypothesis saves you time by forcing you and

your team to focus only on those issues that can prove or disprove

it. This is especially helpful for those who have trouble focusing

and prioritizing. You may even know of a few such individuals in

your own organization.

An initial hypothesis will make your decision making more

effective. Not only does the hypothesis-driven approach make your

problem solving faster and more efficient, it allows you to assess

multiple options quickly. As a result, your decision making

becomes more flexible and therefore more effective. As CEO of a

brand-name consumer goods manufacturer, McKinsey alumnus

Bob Garda, now a member of the marketing faculty at the Fuqua

School of Business at Duke University, used a strong initial hypothesis

that went against his company’s conventional wisdom to turn

around its core business:

We were selling products that had been around for 20 years

and faced a lot of price pressure from Wal-Mart, Kmart, and

Target—our three biggest customers. They kept threatening to go to suppliers in China or India unless we lowered our

prices. We had four alternatives: (1) reduce costs to match

China and India, (2) buy from China and India and resell to

our customers, (3) introduce new products (one of which

was close at hand), or (4) do a combination of the above. My

hypothesis was that we could best minimize the price pressure

by introducing new products. Sure enough, when we

walked into the Big 3 to introduce the new product, they

were excited; we could practically charge whatever we

wanted. After that, they were much less concerned about

beating us up on price, even on the established products, as

long as we kept generating new products. Therefore, the

hypothesis worked out.

Bob compared his hypothesis against other options available to

his company:

We could have taken one of the other approaches and tried

to cut costs to beat India and China. In fact, several of our

key managers thought cost reduction was the only answer, as

it had been in the past. Well, good luck; you can’t beat China

and India on costs with U.S.–made products. Naturally, cost

reduction was part of the answer for the long term; we

launched a cost reduction effort, but we never got down to

Chinese or Indian costs.

The other option, purchasing from China and India and

reselling to Kmart, Wal-Mart, and Target, while popular

with a small faction of management, made no sense to me.

All we would be doing was setting up a distribution system

for the Asian manufacturers and, once established, they

would go directly to the buyers and cut us out. Because of

constant price pressure, this option will continue to be on the table, but as long as we have other values to offer the Big 3,

the better off we are going to be.

The increased effectiveness of hypothesis-based decision making

stems from the lesson that “the problem is not always the problem.”

That’s what Dominic Falkowski found out when he moved

to Egon Zehnder’s Warsaw office:

My client was looking for a CFO because the current manager

was not coping well enough with reporting and investment

analysis, and he was having problems with his team.

We weren’t so sure this was the case. After an analysis of the

situation, including an assessment of the CFO, we realized

that it was the CEO who was not structured, changed opinions

and processes too often, and did not communicate

changes throughout the organization. The CFO was partly

to blame, however, as he had poor interpersonal skills and

did not cope well with any form of feedback.

We suggested some internal reengineering to be conducted

by a strategic consultancy, and we ourselves coached

the CFO and CEO. The result: solved problem, happy client

and CFO, and a prospering organization. Further, we proved

that an external search would not have brought the value the

client wanted.

IMPLEMENTATION GUIDANCE

Forming an initial hypothesis will make your problem solving

more efficient and more effective, but to reap these benefits, you

need to be able to generate and test robust hypotheses. Since you

should form your hypothesis at the start of the problem-solving

process, you have to rely less on facts (you won’t have done most of your fact gathering yet) and more on instinct or intuition. Take

what you know about the problem at hand, combine it with your

gut feelings on the issue, and think about what the most likely

answers are. This does not mean that the most likely answer is necessarily

the correct one, but it’s a good starting point.

If something leaps out at you immediately, congratulations;

you’ve just formed a hypothesis. At this point, whether you are

alone at your desk, standing under the shower (alone or otherwise),

or in a brainstorming session with your team, you should do

the Quick and Dirty Test (QDT) of your hypothesis. The QDT is

simply this: what assumptions are you making that need to be true

in order for your hypothesis to be true? If any of these assumptions

is false, then the hypothesis is false. Much of the time, you can

knock out false hypotheses in just a few minutes with the QDT.

This is especially useful when you need to choose from a few

options quickly, as Ciara Burnham, now a venture capitalist at

Evercore Partners, can attest:

So much of my job involves triaging potential investment

opportunities to figure out which ones are worth spending

time on. At the outset of any deal evaluation, I ask, “What

do I need to believe in order for this to be a good investment,

and what are the ways in which this investment could blow

up? Therefore, what analysis do I need to do to support/

reject the investment and to dimension the risks?” Sounds

like a simple approach, but frankly one that many people

trained in the deal execution side of the business don’t take.

As an example, let’s go back to Acme Widgets. Yesterday, the

board told you and your team to figure out a way to lower the

marginal cost of Acme’s venerable line of thrum-mats. Today, in

the first few minutes of your brainstorming session, you’ve come

up with a few options that might make the cut: (1) You might pressure your suppliers to lower your raw-materials costs. (2) You

could cut the workforce at your thrum-mat manufacturing facilities

while maintaining production levels. (3) You might reduce the

time that the thrum-mats spend in the curing process, thereby

increasing throughput. Now you are going to put each option to

the QDT.

Pressuring your suppliers would be great, but can it be done?

What needs to be true for that option to work? Well, you might

say, raw materials should be a significant factor in total thrum-mat

cost; otherwise, reducing the cost of raw materials wouldn’t make

much difference in the total marginal cost of a finished thrum-mat.

As it happens, one of your team knows that raw thrums make up

about 35 percent of the total cost of a thrum-mat, so there should

be some mileage there. Next, you would need to have some pricing

leverage with your suppliers. Unfortunately, on page A2 of this

morning’s Wall Street Journal, there is a story about the newly

announced takeover of General Thrums by Allied Thrums and

Bezels. Analysts expect the merger to result in a significant reduction

in total thrum production capacity, with corresponding

upward pressure on wholesale thrum prices. So much for that idea.

What about reducing manufacturing head count? Labor is a

large component of the total cost of thrum-mat production, so that

would seem a fruitful area for exploration. The key question then

is whether Acme’s production facilities are overstaffed. One way to

determine this is by learning whether Acme’s per-worker productivity

is low relative to the industry. You recall seeing the results

of a recent benchmarking study on thrum-mat production. That

study put Acme significantly ahead of its competitors in perworker

output. Another dead end.

That leaves reducing the time that thrum-mats spend in the

curing process. Traditionally, Class A thrum-mats spend at least

two weeks in the curing locker—an expensive proposition that not only uses a lot of energy, but also ties up inventory, thereby unnecessarily

swelling Acme’s balance sheet. A reduction in curing time

could thus have a double benefit. Not only would it boost Acme’s

profit line, it also would reduce work-in-progress inventory. What

needs to be true to make this feasible? As a first cut, the question

would seem to be whether it is possible to make Grade A thrummats

without a full two-week cure. Coincidentally, one of your

team has just read an article in Thrum-mat Manufacturing Weekly

on a new curing process that utilizes special temperature, humidity,

and atmospheric controls and that produces the same or better

results as traditional curing methods.

Excellent! Your team has now found an initial hypothesis that

passed the QDT.* Your next step will be to test your hypothesis

more thoroughly and, if necessary, refine it. To accomplish these

goals, you should now put together an issue tree.

An issue tree is the evolved cousin of the logic tree. Where a

logic tree is simply a hierarchical grouping of elements, an issue

tree is the series of questions or issues that must be addressed to

prove or disprove a hypothesis. Issue trees bridge the gap between

structure and hypothesis. Every issue generated by a framework

will likely be reducible to subissues, and these in turn may break

down further. By creating an issue tree, you lay out the issues and

subissues in a visual progression. This allows you to determine

what questions to ask in order to form your hypothesis and serves

as a road map for your analysis. It also allows you very rapidly to

eliminate dead ends in your analysis, since the answer to any issue

immediately eliminates all the branches falsified by that answer.

Dan Veto found issue trees especially useful when defining a set

of initiatives for the E-business arm of Conseco, one of America’s

largest diversified financial services companies:

In problem solving, a lot of people try to be uniformly complete.

The fact is, you don’t always have to be. You want to

think of everything as MECE, but you don’t need to investigate

everything to the same depth. For example, we were

thinking about our E-business strategy, as we had just

formed a new business unit, eConseco. This would be a

stand-alone business with a real P&L, so we had to ask ourselves,

“What are the key levers of profitability and growth?

Which things matter, and which things don’t?”

We were inundated with ideas. Somebody on the revenue

side would say, “Well, we could sell books.” Being able

to figure out quickly that that option is never going to make

you any money is critical. Being able to snip from the tree the

branches that don’t matter so that we’re focused on the

branches that do matter is just an unbelievable problemsolving

and problem-framing skill that is not necessarily

intuitive but which can really speed the problem-solving

process.

Going back to your team room at Acme Widgets, what would

an issue map look like for reducing the thrum-mat curing process?

As you and your team discuss it, several questions arise: Will it

actually save money? Does it require special skills? Do we have

those skills in the organization? Will it reduce the quality of our

thrum-mats? Can we implement the change in the first place?

When laying out your issue tree, you need to come up with a

MECE grouping of these issues and the others that arise. As a first step, you need to figure out which are the top-line issues, the issues

that have to be true for your hypothesis to be true. After a bit of

brainstorming, you isolate three questions that address the validity

of your hypothesis: Will shortening the curing process reduce our

costs? Can we, as an organization, implement the necessary

changes? If we implement this change, can we maintain product

quality? Put these issues one level below your hypothesis, as shown

in Figure 1-2.

Unfortunately, the answer to each of these questions lies in several

more questions. You will have to answer those in turn before

you can come up with a final yes or no. As you take each question

down one or more levels, your analysis road map will begin to take

shape. Let’s drill down on one of these issues and see where it

leads us.

The issue “Can we implement the necessary changes?” throws

off numerous subsidiary questions (see Figure 1-3). Some of them

came out in the initial brainstorming, while others will arise when

you spend more time thinking specifically about the issue. Just as

you did for the main issue, you need to figure out the logical progression

of these questions. For the sake of this exercise, let’s say

there are two top-line questions for this issue: (1) Does the new,

shorter process require special facilities that we don’t have? (2)

Does it require special skills that we don’t have? For both of these

questions, the ideal answer, “no,” shuts down any further inquiry.

If, however, the answer to either of these questions is yes, the

hypothesis is not immediately invalidated. Rather, this answer

raises additional questions that must be answered. For example,

in the case of facilities, you would ask, “Can we build or buy them?” If the answers to these questions lower down the tree turn

out to be no, then your hypothesis is indeed in jeopardy.

At this point, the process of laying out an issue tree should be

clear to you. If you’ve done it, then you have sketched out the tasks

that you will need to fulfill in terms of research and analysis—subjects

that we will address in the following chapters.

The McKinsey technique of hypothesis-driven problem solving—

solving the problem at the first meeting—has proved to be

an excellent decision-making skill beyond the confines of the Firm.

If you spend some up-front time combining your initial fact base

with your gut instinct, you will enable yourself to come to a more

robust solution sooner. A little bit of time spent weeding out

invalid hypotheses at the outset and then determining the scope of

your analysis with an issue tree will save you time and improve

your results.

EXERCISES

• Think about a nonbusiness issue about which you hold a

strong view (e.g., gun control, evolution, global warming).

List the assumptions that you are making with regard to

your position. Are they all true? What information or

analyses would you need to support your view?

• If you haven’t already, come up with a couple of likely

hypotheses for whatever issue you are currently working

on in your job. Can you come up with one or two things

that must be true for each hypothesis to be valid? Now

subject each hypothesis to the QDT.

\CONCLUSION

By using structured frameworks to create an initial hypothesis, you

will enable yourself and your team to select the analyses and areas

of research that will allow you to reach a robust conclusion in the

shortest possible time. In the next chapter, we will look at how to

plan an analysis to prove or disprove your hypothesis in the shortest

time possible.

This page intentionally left blank.