English
ČeštinaABCD Decision Framework
We're building a comprehensive knowledge library about product development as part of our mission. The library is for anyone looking to make better decisions — primarily decisions about how to further develop a product. Whether you're an inventor, a product manager, or a Chief Product Officer, using a structured decision-making method increases your chances of building the right things for the right audience (build the right thing for the right audience). Today we'll introduce the ABCD decision framework.
Framework name: ABCD decision framework (also known as the McKinsey decision typology).
Inventor: Aaron De Smet, Gerald Lackey and Leigh M. Weiss (McKinsey & Company).
Year of first use: 2017.
Link to the author's original research: Article: Untangling your organization's decision making (McKinsey Quarterly, 2017)
Key figures in the framework's development:
Aaron De Smet.
Gerald Lackey.
Leigh M. Weiss.
Key milestones in the framework's development:
1967: Peter Drucker names classifying the problem as the first step of decision making in The Effective Decision.
2015: McKinsey lays the groundwork for agile decision making in Agility: It rhymes with stability.
2017: The four decision types are published in Untangling your organization's decision making.
2019: A global survey links practices per decision type to business results in Decision making in the age of urgency.
History of First Use
The framework came out of McKinsey's work with large organizations that were trying to become flatter and more agile. The authors kept running into the same problem that growing organizational complexity and cheap digital communication (email, Slack, AI) had blurred who actually decides what. More people joined every decision, meetings multiplied, and quality dropped. In a McKinsey survey, 72 percent of senior executives said bad strategic decisions were at least as common as good ones in their organization.
While working with these clients, De Smet, Lackey and Weiss noticed that decision making improved when a team first labeled the type of decision in front of it and only then chose how to make it. They observed four recurring types and named them after the first letters: Big bets, Cross-cutting, Ad hoc and Delegated decisions.
McKinsey team credits Peter Drucker, who wrote in 1967 that every decision starts with classifying the problem. Drucker, however, sorted problems by whether they were generic or exceptional. The ABCD framework sorts them by how far their consequences reach and how often they recur, which tells you who should decide and how. According to the authors, this is more suited to todays complex world where decisions needs to be untangled first.
Basic Prioritization Principles
The core idea of the framework is to prioritize decisions by risk and frequency. In product development, high risk and rare decisions such as entering a new market or rebuilding the core architecture deserve careful deliberation, while low risk and frequent ones such as copy changes or small UI tweaks should be made quickly by the team closest to the work.
The matrix has two axes and four quadrants that represent four ways to make a decision:
Frequency = the X axis shows how often the same type of decision comes up. Additionally, we can use familiarity with the decision as a proxy for frequency.
Scope and impact = the Y axis shows how broad the decision's consequences are for the organization, from narrow to broad.
Once you place a decision on both axes, you get a simple 2×2 matrix in which each quadrant calls for a different way of deciding. The framework has a set of basic rules:
How you apply the framework depends on your position in the organization. What is a delegated decision for the company as a whole can be a big bet for an individual business unit.
Senior leaders decide which decisions are big bets, who leads each cross-cutting process, and to whom other decisions are delegated.
Most decision problems come from misclassification of decisions covered below.
Parts of delegated decisions can be handed to algorithms and AI, provided there are clear thresholds for when the system escalates to a person and how it works.
Senior leaders decide which decisions are big bets, who leads each cross-cutting process, and to whom other decisions are delegated.
Quadrant I: Big Bets
The "top-left" quadrant represents Big Bets, decisions with broad scope and impact that are infrequent. They are also often not known, unfamiliar to the decision-makers. Think major acquisitions, entering a new market or rebuilding a product on a new platform. These decisions can shape the future of the company and often have no clearly right answer out-of-the-box. They deserve the most care:
Appoint an executive sponsor who frames the decision and define the problem statement.
Split the decision into stages, each with a gate that approves moving forward, and map how they depend on other decisions in the company to avoid unintended consequences.
Debate the solutions, require prework, bring in people with diverse perspectives, and embrace competing scenarios and a devil’s advocate approach.
As an executive accept imperfect data, agree on what "good enough" means, and commit to the outcome once the decisions are made.
Willingness to commit to the gamble even when decision was made when being on the opposite site of the argument is vital.
The conclusion of every meeting must make clear who owns which actions resulting from the decision.
Quadrant II: Cross-Cutting Decisions
The "top-right" quadrant represents Cross-Cutting Decisions, decisions with broad scope and impact that are frequent. Roadmap reviews and product launches belong here. They are not single decisions but a series of smaller, connected decisions made by different groups of people over time.
The challenge is not the decisions themselves but the coordination around them. So instead of asking who owns the decision, start by finding where teams need to collaborate and coordinate. In practice this means:
Map the decision process end to end in a simple, plain-English playbook (calendar, cadence, handoffs and decision points]
Test the process on real scenarios with the people who will run it to spot inefficiencies in the playbook.
Limit the number of decision-makers and define each one's mandate, members, roles and agenda.
Set shared objectives and metrics so that people own the result of the whole process, not just their part.
Quadrant III: Ad Hoc Decisions
The "bottom-left" quadrant represents Ad Hoc Decisions: decisions with low impact that are infrequent. They come up occasionally and their impact depends on how concentrated they are. The original article deliberately leaves them out.
Quadrant IV: Delegated Decisions
The "bottom-right" quadrant represents Delegated Decisions, decisions with narrow scope that are frequent. In product work, these are bug priorities, small UX changes or A/B tests within an agreed scope. The decision scope is far smaller as compare to big bets and cross-cutting decisions. A single delegated decision matters little, but their value comes from the multiplier effect of how often they occur. Let the people closest to the work make these decisions. They decide faster and better and become more engaged. Some tips for those decisions are:
As a leader list the 20 most frequent decisions you make. For each, ask: Is it reversible? Can someone on my team make it? Can I hold that person accountable? If all three answers are yes, delegate it.
Give each decision one owner. If both the product manager and the head of product can reorder the roadmap, say who has the final call and when the other only gives input.
Set clear escalation thresholds. For example, a change that affects more than 10 percent of users or exceeds an agreed budget goes to the head of product, and the team decides everything below that.
When the team escalates a decision it should own, send it back with guidance on who should make it. After a bad call, review it with the person and coach them instead of taking the decision back.
Prioritization Example
The example shows how the product organization of a B2B SaaS company could categorize its decisions.
Quadrant I: Big Bets
Rebuilding the product around MCP (AI).
Quadrant II: Cross-Cutting Decisions
Launching a new Salesforce integration. Every new integration such as Salesforce needs similar GO-TO-MARKET strategy that repeats.
Quadrant III: Ad Hoc Decisions
Sunsetting a rarely used CSV export format.
Quadrant IV: Delegated Decisions
Sorting tasks by due date. Users see the most urgent tasks first instead of the newest ones when they open their task list.
