25/36 : 🛠️ McKinsey's Problem-solving Process
A problem well defined is a problem half-solved — Charles Kettering
Problem Solving for Product Managers
Product Managers excel in problem-solving by employing a strategic mix of analytical thinking, creative ideation, and data-driven insights. They keenly identify and comprehend customer needs, analyze market trends, and craft innovative solutions that enhance products' value and propel business growth. By addressing challenges, optimizing development processes, and aligning products with company objectives, they ensure customer demands are met efficiently and deliver successful outcomes.
Concept of problem-solving
Today's businesses want employees who can adapt to new situations rapidly and effectively.
The ideal employee is a master of basic skills such as reading, writing, and numeracy.
The ideal employee is also a master of learning, communication, critical thinking, creative thinking, and problem-solving.
The ideal employee can respond to a problem quickly, correctly, and with little or no supervision.
If you can solve problems, you can write your own ticket for whatever job you want.
Defining Problem-Solving
Problems can be classified into puzzle problems, well-structured problems, and ill-structured problems.
Simple Problems Many games contain puzzle problems and are not "serious" in nature, nor is there any real-life consequence for failing to solve them.
Well-structured Problems Some problems which are simple and well-defined are called well-structured problems and include a set number of possible solutions - solutions are either 100% right or 100% wrong. An example of a well-structured problem is a typical mathematical (2 + 2 = 4) question. This question has a definitive correct answer.
Ill-structured Problems In contrast to well-structured problems are ill-structured problems. In these cases, problems may have many possible answers because they are complex and poorly defined. The "best" solutions to ill-defined problems depend on the priorities underlying the situation. What is "best" today may not be "best" tomorrow. Ill-structured problems, because they are more difficult to "solve," require the development of higher-order thinking skills and the ability to construct a convincing argument for a particular solution as opposed to all other possible solutions.
To summarize ill-structured problems:
They are complex and poorly defined.
They have many possible answers.
They do not have one best answer.
Here is an example of an ill-structured problem:
The population of your community is growing. Your water supply will not support many new people.
What do you do?
This is a complex problem. It affects the people, the environment, and the quality of life itself. To arrive at a good solution, you need to use math, science, political science, psychology, and probably more!
This problem actually occurs frequently in areas with a growing population. In one community facing this problem, more than 20 possible solutions were presented to the public. A solution was then chosen upon which the majority of the public agreed. It wasn't the "right" solution because all of the 20 possible solutions had strengths and weaknesses.
The lesson here is that ill-structured problems usually have several workable solutions. Each solution has advantages and disadvantages that depend on who is affected by the solution. The solution chosen is often the one that has the best argument for it.
3 Prerequisites for a good solution
He realized there are three essential prerequisites for good solutions:
The product must be defined to allow for the development of useful solutions.
The potential solution must fit the defined problem space and product scope.
The product team must have understood the problem.
Understanding the problem Whether the problem comes from your users or another set of stakeholders, you need to properly understand the problem. The only way to do that is through a combination of research, and empathy. This means gathering both qualitative and quantitative data. Find out how the user/stakeholder feels about the problem, as well as how they behave in response to it.
Communicate “The Why” As a product manager, your most important why is the customer problem that your product is trying to solve. Include your team and other stakeholders in understanding the customer problem and selecting the right goal metric to grow. This way, everyone can contribute, feel ownership, and stay motivated to solve the problem even if the product changes.
First, it helps everyone internalize “the why” so they can make decisions with the same goal in mind.
Second, if people are not aligned on “the why”, they’re more likely to bring up objections if you talk about it constantly.
Keep It Simple When communicating with others, the most critical question that you need to answer is, “Do people understand?” If people don’t understand the why, they won’t be able to execute.
Keep your communication simple, short, and specific. Check to see if people understand your message by asking them to explain it back to you
Make a risk vs reward assessment Once you know what the problem is, you need to lay the groundwork for your plan on how to proceed with solving it. Analyze the potential risks and rewards of the project. So if a stakeholder is asking that a new feature be implemented, work out how much of your team’s work hours, budget, and resources will be needed to complete the project and solve the problem.
Balance this out by seeing how the best-case scenario (eg, you completely solve the problem) will benefit your product in terms of OKRs, and the bottom line.
Define Success Defining the success of a project really boils down to the final part of your risk vs reward assessment. What does the best-case scenario look like?
If the answer isn’t obvious, think about your company’s North Star metrics, or your team’s KPIs. If the project is worthwhile, its goals should align with either, if not both, or these.
I learned to approach every problem from multiple angles. It was the combination of both qualitative and quantitative insights that led us to our proposed solution. Also, a variety of perspectives are critical.
Learning to Ask the Right Questions: Define the Problem Statement
McKinsey’s Problem-solving process
McKinsey’s benchmark is the problem-solving process as practiced by McKinsey. At the most abstract level, McKinsey develops solutions to clients’ strategic problems and, possibly, aids in the implementation of those solutions
Business Need You can’t have problem-solving without a problem or, more broadly, a need on the part of the client. In business, those needs come in several forms: competitive, organizational, financial, and operational.
Analyzing Once your organization has identified the problem, it can begin to seek a solution, whether on its own or with the help of McKinsey (or any other outside agent). McKinsey’s fact-based, hypothesis-driven problem-solving process begins with framing the problem: defining the boundaries of the problem and breaking it down into its component elements to allow the problem-solving team to come up with an initial hypothesis as to the solution. The next step is designing the analysis, determining the analyses that must be done to prove the hypothesis, followed by gathering the data needed for the analyses. Finally comes interpreting the results of those analyses to see whether they prove or disprove the hypothesis and to develop a course of action for the client.
Presenting You may have found a solution, but it has no value until it has been communicated to and accepted by the client. For that to happen, you must structure your presentation so that it communicates your ideas clearly and concisely and generates buy-in for your solution for each individual audience to which you present.
Managing The success of the problem-solving process requires good management at several levels. The problem-solving team must be properly assembled, motivated, and developed. The client must be kept informed, involved, and inspired by both the problem-solving process and the solution. The individual team members (that’s you) must strike a balance between life and career that allows them to meet the expectations of the client and the team while not “burning out.”
Implementation Your organization may have accepted your solution, but it must still implement it. This requires the dedication of sufficient resources within the organization, the timely reaction of the organization to any stumbling blocks that may arise during implementation, and the focus of the organization on completion of the tasks necessary for full implementation. In addition, the organization must institute a process of iteration that leads to continual improvement. That process requires reassessing implementation and rededicating the organization to make additional changes identified during reassessment.
Leadership At the nexus of solution and implementation comes leadership. Those at the helm of your organization must conceive a strategic vision for the organization. They must also provide inspiration for those in the organization who will do the hands-on work of implementation. Finally, they must make the right judgments regarding the delegation of authority in overseeing implementation throughout the organization.
There is one other piece of the model: the tension between intuition and data. Problem-solving doesn’t take place in a vacuum. Even McKinsey has only so many resources to throw at a problem and a limited time in which to solve it. While we are advocates for McKinsey-style fact-based problem solving, we recognize that it’s practically impossible to have all the relevant facts before reaching a decision. Therefore, most executives make business decisions based partly on facts and partly on intuition—gut instinct tempered by experience. We will discuss the pros and cons of each element later in the book. For now, we will simply say that we think a sound decision requires a balance of both.
8 Steps to Problem-Solving from McKinsey
Solve at the first meeting with a hypothesis
Intuition is as important as facts
Do your research but don’t reinvent the wheel
Tell the story behind the data
Prewire
Start with the conclusion
Hit singles
Respect your time
Solve at the first meeting with a hypothesis
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 hypotheses.
Gut feeling at this stage is extremely important because we don’t have many facts yet. However, structure strengthens your thinking and ensures that your ideas will stand up. Typically, the problem-solving process would involve defining the boundaries of the problem and then breaking it down into its component elements.
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, non-overlapping issues while making sure that no issues relevant to your problem have been overlooked. This allows to simplify the problem and plan the work because in most cases, a complex problem can be reduced to a group of smaller, simpler problems that can be solved individually.
The most common tool McKinsey people use to break problems apart is the logic tree.
Having reduced the problem to its essential components, you are ready to embark on the next step which is framing it: forming a hypothesis as to its likely solution. By already knowing where your solution is, you eliminate a lot of paths that lead to dead ends.
Using an initial hypothesis to guide your research and analysis will increase both the efficiency and effectiveness of your decision-making because it provides you and your team with a problem-solving roadmap that will lead you to ask the right questions and perform the correct analysis 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.
Intuition is as important as facts
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.
Executives make major strategic decisions based as much on gut instinct as on fact-based analysis.
Intuition and data complement each other. You need at least some of each to have a solid basis for your decisions. The key to striking the balance is quality over quantity.
Do your research but don’t reinvent the wheel
When you form an initial hypothesis, you are “solving the problem at the first meeting.” Unfortunately, although you may think you have the answer, you have to prove it through fact-based analysis.
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.
When your time and resources are limited, you don’t have the luxury of being able to examine every single factor in detail. Instead, when planning your analyses, figure out which factors most affect the problem and focus on those. Drill down to the core of the problem instead of picking apart each and every piece. In most situations, achieving a scientific level of exactitude for your management decisions is counterproductive.
That’s why also as one of your first steps in designing your analysis, you should figure out what not to do.
As your next step, you should decide which analyses are quick wins — easy to complete and likely to make a major contribution to proving or refuting the initial hypothesis (80/20 rule).
When doing your research, you don’t want to get as much information as possible, you want to get the most important information as quickly as possible.
With a plan of action for what to research, make sure you don’t reinvent the wheel as you start gathering your data. Whatever problem you’re facing, chances are that someone somewhere has worked on something similar. So your next step here is to look through all possible internal documents and then look externally.
Tell the story behind the data
Once you have your analysis finished, you need to interpret it because numbers or data don’t say anything. You have to figure out the story behind it and the message that you want to communicate.
At this stage, first comes the process of understanding the data: piecing together (in your own mind or within your team) the story the data is telling you and the steps you should take based on that story. The second comes assembling your findings into an externally directed end product: a key message that includes a course of action for your organization, ream, or client.
Your interpretation of the data leads to a story, that is, what you think the data means. You select those portions of the story that you believe your audience needs to know in order to understand your conclusion, along with the supporting evidence, and you put them together into your end product as in your presentation.
To succeed here you need to see through your client’s, executive’s or audience’s lenses and speak their language.
Prewire
The key to successful presentations and getting buy-in (in order for your audience to accept your recommendations) is prewiring.
The reason behind this is because to get the buy-in you need to bridge the information and trust gaps between you and your audience. The information gap exists because you know more about your findings than your audience does. Depending on the relationship between you and your audience, the trust gap (if it exists) could take any of several forms. Your audience may think that you are too inexperienced to comment on their business, or they may mistrust you because you are an outsider, are overeducated, or not educated enough.
In its essence, prewiring means taking your audience through your findings before you give your presentation. This allows for people to trust you, ask questions you may not have thought about to avoid surprises, and then during the presentation say yes and support you among others who may be more skeptical.
Prewire everything. A good business presentation should contain no shocking revelations for the audience. Walk the relevant decision-makers in your organization through your findings before you gather them together for a dog and pony show. At a minimum, you should send out your recommendations via email to request comments from key decision-makers before the presentation if you can’t meet with those people face-to-face.
The earlier you can start the prewiring process, the better. By identifying and getting input from the relevant players early on, you allow them to put their own mark on your solution, which will make them more comfortable with it and give them a stake in the outcome.
Start with the conclusion
When you begin your presentation in front of your desired audience, make sure you start with the conclusion.
Having your conclusions or recommendations upfront is sometimes known as inductive reasoning. Simply put, inductive reasoning takes the form, “We believe X because of reasons A, B, and C.” This contrasts with deductive reasoning, which can run along the lines of, “A is true, B is true, and C is true; therefore, we believe X.” Even in this simplest and most abstract example, it is obvious that inductive reasoning gets to the point a lot more quickly, takes less time to read, and packs a lot more punch.
As an additional advantage, starting with your conclusions allows you to control how far you go into detail in your presentation.
You need to explain this clearly within just 30 seconds. Almost like an elevator pitch. If you can pass this “elevator test,” then you understand what you’re doing well enough to sell your solution.
A successful presentation bridges the gap between you — the presenter — and your audience. It lets them know what you know.
It also keeps it simple for them which is why it’s important to stick to a key rule if you are using a deck: one message per slide or chart. No more. The more complex a chart/slide becomes, the less effective it is at conveying information. The meaning should be immediately obvious to the reader, so use whatever tools you need to bring it out.
If you broke out your initial hypothesis into a MECE set of issues and sub-issues (and suitably modified them according to the results of your analysis), then you have a ready-made outline for your presentation that will support your conclusion.
Remember that you have two ears and only one mouth. It’s not just what you say, it’s how you say it. Overcommunication is better than under-communication which is why prewiring as mentioned above is so important.
Finally, if you are proposing a certain solution in which you will be involved in the execution, make sure you don’t overpromise because you’re bound to under-deliver. Instead, balance the demands for the solution with your capabilities and those of your team. If more work is necessary, you can always start a second project once the first is done.
Hit singles
When you begin executing on the solution, aim to hit singles.
This is a metaphor from baseball. You can’t do everything, so don’t try. Just do what you’re supposed to do, and get it right. It’s impossible to do everything yourself all the time. If you do manage that feat once, you raise unrealistic expectations from those around you. Then, when you fail to meet those expectations, you’ll have difficulty regaining your credibility.
Getting on base consistently is much better than trying to hit a home run and striking out nine times out of ten.
Do few things well rather than a ton with mediocre execution or results. Stick to targeted focus rather than perfection and drilling into every little piece.
Quality over quantity. And when there’s a lot of work to be done, delegate around your limitations. Know them for what they are and respect them.
Respect your time
Don’t forget that work is like a gas: it expands to fill the time available.
As in the previous point, share the load by delegating and also perform sanity checks on the way to allow you to take a step back and look at the big picture.
You will also have to get others to respect your time. The better you are at your job or the higher up you go in your organization, the more everyone wants a piece of you. There’s an old saying, “Stress is the feeling you get when your gut says, ‘No,’ and your mouth says, ‘Yes, I’d be glad to.’” You have to train your mouth to say, “No.”
Once you make a commitment — “I won’t work on weekends” or “I’ll cook dinner three nights a week” — stick to it, barring life-and-death emergencies. If you seem to be having life-and-death emergencies every week (and you’re not dealing with matters of real life and death, as in a trauma ward), take a hard look at your priorities.