HOST_A: So I want to start with a story that I think about a lot, and it's Kodak. Because Kodak is the canonical example of a company that — and this is the wild part — actually invented the thing that killed them.
HOST_B: Right, the digital camera. Steven Sasson, 1975. He builds this prototype, shows it to management, and they basically say "cool toy, put it in the drawer."
HOST_A: They put it in the drawer! And here's the thing — it's not that those executives were stupid. Kodak had brilliant engineers, brilliant strategists. They dominated the market. So why did they fail so completely?
HOST_B: Because they defined the problem wrong. They thought their business was film. Film was where the margins were, film was what they understood, film was the product. So when someone showed them digital, they asked, "does this threaten our film business?" And the answer in 1975 was, "not yet, not really." So they filed it away.
HOST_A: But the actual problem — the right problem — was something like, "how do we help people capture and share memories?" Right? That's the job the customer was hiring them to do. And film was just the current best technology for that job.
HOST_B: Exactly. And if they'd framed the problem that way — framed it at the right level of abstraction — they might have seen that digital was a better answer to that same job, and they needed to be in that business.
HOST_A: So they solved the wrong problem brilliantly. They got incredibly good at optimizing film when the whole problem space had shifted.
HOST_B: And they're not alone. Nokia is another one. Nokia in 2007 had arguably better hardware than Apple. Their phones were more durable, the batteries lasted longer, they had better cellular radios.
HOST_A: But they thought they were in the hardware business.
HOST_B: They thought they were in the hardware business! And when the iPhone came out, their engineers apparently were like, "our hardware is actually superior." And they were right. They were just asking the wrong question. The real problem wasn't "how do we make better hardware" — it was "how do we create an ecosystem that developers want to build on?"
HOST_A: Which is a completely different problem decomposition. It's not a manufacturing problem or even a product design problem. It's a platform problem. It's a developer relations problem.
HOST_B: So why does this keep happening? Smart people, good companies, access to resources — why do they consistently decompose problems the wrong way?
HOST_A: I think there are a few answers. One is what I'd call the familiarity trap — you decompose problems using the frameworks you already know, which means you find the pieces you already know how to work on.
HOST_B: Which leads to what the statisticians call the streetlight effect, right? The old joke about the drunk man looking for his keys under the streetlight, not because he dropped them there, but because that's where the light is.
HOST_A: Exactly. We decompose problems toward what's measurable and familiar, not toward what actually matters.
HOST_B: And the second reason is organizational. Kodak had entire divisions built around film. Entire careers, entire incentive structures. When you decompose a problem, you're also — implicitly — deciding which parts of the organization are relevant to solving it. And that is extremely politically charged.
HOST_A: So decomposing a problem isn't just a cognitive exercise. It's also a power exercise.
HOST_B: It's enormously political. The way you frame a problem determines who owns it, who gets resources, who gets blamed if it goes wrong.
HOST_A: Okay so this is why I think problem decomposition is one of the most underrated skills in business. Everyone talks about being a good problem solver. Almost no one talks about being a good problem definer.
HOST_B: And they're completely different skills! Which brings us to — I think we should actually get into what decomposition means, structurally, mechanically. Because I think it's one of those terms people use without really understanding what they mean by it.
HOST_A: Yeah, let's do the foundations. What does it actually mean to decompose a problem?
HOST_B: So the core idea is this: you take a big, complex, hard-to-act-on problem and you break it into smaller sub-problems that are each independently workable. You can assign different people to them, you can make progress on each one without necessarily solving all the others, and when you reassemble the pieces, you've made progress on the whole.
HOST_A: That sounds almost obvious when you put it that way.
HOST_B: It does! And that's actually — I mean, there's a real argument that decomposition is just common sense with expensive jargon. But I think the jargon matters because it gives you precision. It lets you notice when you're doing it wrong.
HOST_A: Okay so what's the most famous framework for doing this rigorously?
HOST_B: MECE. Mutually Exclusive, Collectively Exhaustive. It comes from McKinsey, specifically from Barbara Minto, who developed it in the late 1960s and early 70s when she was working there. She later wrote a book called The Pyramid Principle which is still probably the most influential book on structured thinking in the consulting world.
HOST_A: So break down what MECE means. Mutually Exclusive means...
HOST_B: Means the pieces don't overlap. If you split a problem into parts, each piece of the problem belongs to exactly one bucket. There's no double-counting, no ambiguity about which part of your breakdown a given issue belongs to.
HOST_A: And Collectively Exhaustive means...
HOST_B: Together, all the pieces cover the whole problem. Nothing falls through the cracks. If you decompose a problem into parts A, B, and C, and you solve A, B, and C, you've solved the whole problem. There's no mysterious fourth thing lurking outside your framework.
HOST_A: And you turn this into what's called an issue tree, right? Or a logic tree?
HOST_B: Right. So an issue tree is just a visual representation of your MECE decomposition. You start with the main problem at the top, then you branch it into the main sub-questions, then each of those branches further into more specific questions, and so on, until you get to questions that are small and concrete enough to actually research and answer.
HOST_A: Like a classic McKinsey engagement. "Why is our client's profit declining?" And then you branch that into revenue and cost. Revenue branches into volume and price. Volume branches into market size and market share. And so on until you get to something like "our conversion rate in the western region has dropped three points since Q2."
HOST_B: Exactly. And each node in that tree should be MECE with respect to its siblings. Revenue and cost are MECE — they don't overlap and they fully explain profit. Volume and price are MECE because revenue is literally price times volume.
HOST_A: Okay but here's my first question. Is profit really just revenue minus cost? I mean, structurally yes, but does splitting it that way actually give you useful insight?
HOST_B: That's a great challenge and we'll come back to it. But let's first finish the foundations. Because MECE is one tool. There's another set of tools for a different kind of problem — specifically, when you're not trying to understand the full landscape of a problem, but you're trying to find the root cause of something that went wrong.
HOST_A: Right. The Five Whys.
HOST_B: The Five Whys, which comes from Toyota — specifically from Taiichi Ohno, who developed it as part of the Toyota Production System in the 1950s and 60s. The idea is bracingly simple: when something goes wrong, you ask "why" five times in succession, and each answer becomes the basis for the next question. You're drilling down through layers of symptoms to find the real cause.
HOST_A: And it really is five? Not four, not six?
HOST_B: It's roughly five — the number is illustrative, not prescriptive. Ohno's point was that the first answer to "why did this happen" is almost always a symptom, not a root cause. And if you fix a symptom, the problem comes back. You need to go deeper.
HOST_A: Can you walk through an example?
HOST_B: Sure. Classic one from Toyota: a machine stops working. Why? Because it overloaded and the fuse blew. Why did it overload? Because the bearing wasn't lubricated properly. Why wasn't the bearing lubricated? Because the lubrication pump wasn't working correctly. Why wasn't the pump working? Because the pump intake was clogged with debris. Why was the intake clogged? Because there was no filter on the intake.
HOST_A: So if you just replace the fuse, the machine breaks again in a week.
HOST_B: Exactly. The root cause is the missing filter. Fix that, and you've actually fixed the problem. This is the fundamental insight of the Five Whys — you need to distinguish between symptoms and causes.
HOST_A: Which is also what I think is really missing from the MECE issue tree approach sometimes. The issue tree tells you where the problem is, but not why it's there.
HOST_B: That's a fair distinction. MECE is good for problem location — narrowing down where in the system the issue lives. The Five Whys is good for causal depth — understanding why the issue exists at that location. They're complementary.
HOST_A: And there's a third distinction I want to make, which is the problem space versus the solution space. This trips people up so much.
HOST_B: Oh, this is huge. The problem space is a description of what's wrong or what you want to achieve, without any reference to how you'd fix it. The solution space is where you think about interventions, technologies, approaches.
HOST_A: And the failure mode is jumping straight to the solution space before you've properly understood the problem space. Which is incredibly common.
HOST_B: Incredibly common. In software engineering, this shows up constantly. Someone files a bug report that says "we should add a manual refresh button." That's a solution, not a problem. The actual problem might be "users don't know when data is stale." And if you understand it that way, maybe the right answer is a refresh button — or maybe it's showing a timestamp, or pushing real-time updates, or redesigning the workflow so staleness doesn't matter.
HOST_A: Right, by jumping to the solution you've pre-constrained your options. You've made the problem smaller than it needs to be.
HOST_B: And inversely, you can also make the problem bigger than it needs to be, which leads to scope creep and paralysis. Which is why the discipline of problem decomposition isn't just about expanding the problem — it's about finding the right level of abstraction.
HOST_A: Okay so let's talk about why this stuff is taught everywhere now. Because it's not just McKinsey anymore. Product managers learn MECE. Engineers learn root cause analysis. Designers learn how to reframe problems. Why has structured decomposition become such a core skill?
HOST_B: I think there are a few forces. One is the complexity of modern work. When you're building a large software system, or managing a multi-market company, or designing a public health intervention, the problems are genuinely too complex for a single mind to hold all at once. You need a systematic way to carve them up so different people can work on different pieces without stepping on each other.
HOST_A: So decomposition is partly an organizational technology, not just a cognitive one.
HOST_B: Exactly. It's how you coordinate distributed work. If your team all shares the same issue tree, everyone knows where their piece fits and what depends on what.
HOST_A: And in consulting it's almost a client communication tool, right? You're showing the client, "look, we have a rigorous, systematic way of approaching your problem. We're not just guessing."
HOST_B: Right, and there's a whole hypothesis-driven decomposition approach that McKinsey uses — sometimes called the pyramid principle in action. Instead of just building an issue tree and then going off to fill in all the leaves, you start with a hypothesis about what the answer is, then you build an issue tree specifically designed to test that hypothesis. So instead of exploring everything, you're quickly trying to prove or disprove your initial guess.
HOST_A: Which is faster, but riskier. You might chase the wrong hypothesis.
HOST_B: Exactly the tension. Speed versus completeness. But in practice, experienced consultants will tell you that having a working hypothesis — even a wrong one — actually accelerates your thinking because it forces you to be explicit about your assumptions. You can challenge a wrong hypothesis. You can't challenge a blank page.
HOST_A: Now I want to talk about Clayton Christensen and Jobs-to-be-Done, because I think this is a really interesting flavor of problem decomposition that comes from a completely different direction.
HOST_B: Yes! So Christensen developed this framework, and the core insight is: customers don't buy products, they hire them to do a job. A "job" in this sense is the progress a person is trying to make in a particular circumstance. So the job isn't "buy a milkshake." The job might be "survive a boring morning commute and arrive at work not hungry."
HOST_A: And that reframing completely changes how you think about competition. The milkshake isn't competing against other milkshakes. It's competing against a banana, a granola bar, a podcast.
HOST_B: Right. So Jobs-to-be-Done is a decomposition of customer motivation. Instead of segmenting customers by demographic — age, income, location — you segment by the job they're trying to get done. And different people hiring your product for different jobs might be completely different demographic profiles, but they share a job.
HOST_A: This is what Apple did with the iPhone, arguably. The job wasn't "make calls" — the job was "manage my entire life from a single device I carry everywhere." And once you define the job that way, you suddenly understand why email, maps, apps, and the App Store were all core to the product, not features bolted on later.
HOST_B: And what's interesting is that Jobs-to-be-Done is very different from MECE structurally. MECE gives you a top-down decomposition of a known problem space. JTBD gives you a bottom-up understanding of what the problem space actually is, from the customer's perspective. They're solving different things.
HOST_A: Okay and you mentioned OKRs. That's another decomposition framework that's everywhere now.
HOST_B: OKRs — Objectives and Key Results — is fundamentally a decomposition of organizational intent. You take a big ambiguous goal — "be the best search engine in the world" — and you decompose it into a set of measurable outcomes that you think, if you achieve them, will constitute having achieved that goal. The objective is the qualitative aspiration; the key results are the MECE decomposition of what success looks like.
HOST_A: Hmm. But are OKRs actually MECE? In practice, I feel like key results often overlap, or don't fully cover the objective.
HOST_B: In practice, they often aren't. Which is why OKRs, done badly, are just a box-checking exercise. The discipline is in the decomposition — making sure your key results actually fully cover the objective, without redundancy.
HOST_A: And then there's design thinking, which has its own decomposition approach. The "How Might We" question.
HOST_B: "How Might We" is a reframing technique — it takes a problem or observation and converts it into an opportunity question. "Users are frustrated when the app is slow" becomes "How might we reduce the experience of waiting?" Which is subtly different from "how might we make the app faster," because the first opens up solutions like better loading states, background pre-fetching, or just redesigning so the slow thing is less central. It decomposes the experience, not the code.
HOST_A: I love that. Because it keeps you in the problem space longer before jumping to solutions.
HOST_B: Exactly. And there's a whole process in design thinking called the Double Diamond — you have a first diamond where you diverge to explore the full problem space, then converge on the right problem definition; then a second diamond where you diverge on possible solutions and converge on the best one. The decomposition happens in that first diamond. Most people skip it.
HOST_A: Okay. I want to push back on some of this now. Because I think there are real failure modes to structured decomposition that don't get talked about enough. Can I play devil's advocate?
HOST_B: Please. This is why we're here.
HOST_A: My first issue with MECE specifically is that it creates false precision. It assumes that real problems have clean, non-overlapping structure. But most interesting problems are what the systems thinkers call "messes" — everything is entangled with everything else. Revenue affects cost. Employee morale affects customer experience affects revenue. You can't draw clean boxes around them.
HOST_B: That's a fair critique. MECE works best on well-structured problems — financial analysis, process debugging. It works much less well on organizational or social problems where everything is interconnected.
HOST_A: And actually, there's a really important academic framework for this that I don't think gets cited enough in business conversations, which is Rittel and Webber's work on wicked problems from 1973.
HOST_B: Yes! Horst Rittel and Melvin Webber — urban planners, actually. And their insight was that certain kinds of problems — particularly social and policy problems — have properties that make them fundamentally resistant to the kind of decomposition we've been talking about.
HOST_A: Can you go through some of those properties? Because I think they're genuinely important.
HOST_B: Sure. One key property is that wicked problems have no definitive formulation — you can't write down a complete description of the problem without already embedding assumptions about what solutions are possible. The way you define the problem already constrains your solution space.
HOST_A: Which is the meta-problem. The problem definition is itself part of the problem.
HOST_B: Exactly. Another property: wicked problems have no stopping rule. For a MECE issue tree, you can say "I've checked all the branches and the answer is X." For a wicked problem, you can always dig deeper, there's always more context, the problem is never fully solved — only more or less managed.
HOST_A: And the third one I keep coming back to: every solution to a wicked problem changes the problem. When you intervene in a complex social system, you change the system. The problem you were trying to solve is no longer the same problem. Which means your carefully constructed decomposition might be obsolete the moment you start solving.
HOST_B: Right. And Rittel and Webber's point wasn't that you shouldn't try to address wicked problems. It was that you need a fundamentally different approach — one that acknowledges the problem is contested, involves stakeholders in the framing, and treats every intervention as an experiment rather than a solution.
HOST_A: So MECE is great for tame problems and dangerous for wicked ones. Because it gives you the false confidence that you've correctly decomposed something that is, in fact, not decomposable.
HOST_B: I think that's right. And I'll extend the critique to over-decomposition paralysis — which I've seen a lot in consulting contexts. You get a team that is brilliant at building issue trees, and they spend three weeks building the most beautiful, comprehensive issue tree you've ever seen, and they've done zero actual work on the problem.
HOST_A: Analysis paralysis in fancy clothing.
HOST_B: Exactly. The decomposition becomes the work instead of a tool for doing the work. And I think this is a genuine risk of teaching frameworks too dogmatically — people learn the framework, and then the framework becomes the goal instead of the means.
HOST_A: There's also what I call the measurement trap, which connects to the streetlight effect we mentioned earlier. When you're building an issue tree, you naturally tend to break problems into things you can measure. Because if you can't measure a branch, how do you know when you've solved it?
HOST_B: Right, but the most important parts of a problem are often the hardest to measure. Culture, trust, meaning, creativity — these are real levers in organizations, but they're extremely hard to quantify. So your issue tree tends to over-emphasize financial metrics, headcount, process efficiency, because those have numbers attached to them.
HOST_A: And then you optimize the measurable things at the expense of the unmeasurable things, and you're surprised when your highly optimized, fully MECE'd company can't innovate or retain talent.
HOST_B: Which brings us to first principles thinking, which I think is genuinely a different mode of problem decomposition that sidesteps some of these issues.
HOST_A: Elon Musk talks about this a lot. Can you explain what first principles actually means?
HOST_B: So the idea comes from Aristotle originally — a first principle is a basic proposition that cannot be deduced from any other proposition. In Musk's usage, it means: don't reason by analogy from what already exists. Instead, break the problem down to its fundamental physical or logical constraints, and then reason back up from there.
HOST_A: And the canonical example is the battery.
HOST_B: The battery! Musk wanted to build electric cars, but batteries were impossibly expensive. The conventional wisdom was "batteries cost around $600 per kilowatt-hour, they've always been that expensive, they'll always be expensive." Which was reasoning by analogy from existing supply chains.
HOST_A: Musk asked: what are batteries actually made of? Lithium, cobalt, nickel, aluminum, a polymer separator, a can. What do those materials cost on commodity markets?
HOST_B: And the answer was something like $80 per kilowatt-hour. So the difference between $600 and $80 is just manufacturing inefficiency and supply chain markup — and if you build a gigafactory at scale and vertically integrate, you can actually get there. Which is what Tesla did.
HOST_A: So first principles decomposition breaks a problem not into logical buckets, like MECE, but into physical or causal primitives. What is this thing actually made of? What are the real constraints, not the assumed ones?
HOST_B: Right. And it's powerful precisely in situations where the conventional decomposition has baked in assumptions that are false. If everyone in an industry decomposes the cost problem the same way — "component cost, assembly cost, distribution cost" — they're all finding the same solution space. First principles asks whether the entire decomposition is wrong.
HOST_A: Hold on though — is this really different from just being creative? Or is it a systematic method?
HOST_B: Good challenge. I think it's more systematic than raw creativity, but less systematic than MECE. It requires deep domain knowledge — you need to know what the actual physical or mathematical constraints of a problem are, which is why Musk uses it for physics-adjacent problems like rockets and batteries. It's harder to apply to organizational problems where there are no fundamental laws of nature to appeal to.
HOST_A: Right. You can't reason from first principles about why your sales team has low morale.
HOST_B: Not really. Or you can try, but "first principles of human motivation" gets you into philosophy, not engineering.
HOST_A: Okay so let's go deeper on the landscape of frameworks, because I think the sophisticated view isn't "MECE is good" or "MECE is bad" — it's that different frameworks are designed for different problem types, and knowing which to use is the actual skill.
HOST_B: Yes! This is what I think is most underappreciated. People learn one framework and try to apply it to everything. But the real skill is recognizing what kind of problem you're looking at and selecting the appropriate decomposition approach.
HOST_A: So let's go through the main problem types. Starting with causal problems — something went wrong and you need to find out why.
HOST_B: Causal problems are where Five Whys and the Ishikawa fishbone diagram shine. Five Whys is what we talked about — drill down from symptom to root cause. The fishbone diagram, developed by Kaoru Ishikawa in Japan, is essentially a visual Five Whys expanded to consider multiple causal pathways simultaneously. You draw the problem as the fish's head, and you identify the main categories of potential causes — the "bones" — like people, process, materials, machines, environment, measurement. Then for each category you drill down into specific causes.
HOST_A: The fishbone is nice because it's MECE at the category level — those six M's or whatever framework you use cover most causal domains — but it doesn't require causal paths to be mutually exclusive. Multiple things can contribute simultaneously.
HOST_B: Exactly. Which is more realistic than the Five Whys, which can oversimplify to a single causal chain when the reality is multiple interacting causes.
HOST_A: Okay, strategic problems — how does a company decide where to compete, what to build, how to grow?
HOST_B: Here MECE issue trees come into their own, as do frameworks like Porter's Five Forces. Porter's Five Forces is actually a decomposition of competitive dynamics — it says the profitability of an industry is determined by five forces: competitive rivalry, supplier power, buyer power, threat of substitutes, and threat of new entrants. Each of those is a distinct dimension of competitive pressure, and together they collectively exhaustively explain why some industries are more profitable than others.
HOST_A: That's a MECE decomposition of the concept "competitive attractiveness."
HOST_B: Exactly! Porter may never have used the word MECE, but that's structurally what he did. He broke down a complex, hard-to-measure thing — "is this market worth entering?" — into five separable, analyzable dimensions.
HOST_A: And the BCG growth-share matrix is another one — decomposing a portfolio of businesses into four quadrants based on market growth and relative market share. Stars, cash cows, question marks, dogs.
HOST_B: Right. Which has its critics, but structurally it's a decomposition of "how should we allocate capital across our business units."
HOST_A: Okay, innovation problems. You want to create something new that people will actually want. How do you decompose that?
HOST_B: Jobs-to-be-Done is the primary tool here, as we discussed. But I want to add inversion — specifically, "what would make this fail?" Thinking about failure modes is a powerful decomposition technique for innovation because it forces you to identify the critical assumptions in your design.
HOST_A: Which is the pre-mortem! Jeff Bezos talks about this, Gary Klein developed it — the idea is that before you launch something, you imagine it's already failed, spectacularly, and you ask: what went wrong? You're not predicting failure, you're decomposing the risk surface.
HOST_B: And the pre-mortem surfaces assumptions that normal forward planning hides. When you're building a business case, everyone's incentivized to be optimistic. When you're doing a pre-mortem, you're explicitly invited to identify what could go wrong, which reveals the hidden assumptions about market adoption, technical feasibility, competitive response, whatever.
HOST_A: It's decomposition of uncertainty rather than decomposition of structure.
HOST_B: I love that framing. Yes. And Amazon takes this even further with their "working backwards" approach, specifically the PRFAQ — the Press Release and FAQ. The idea is: before building anything, write the press release you'd issue when it launches. That press release has to answer the question "what problem does this solve for customers?" and you have to answer it clearly enough that a journalist could write about it.
HOST_A: Which is a decomposition of the product into customer value. You can't write the press release until you understand, clearly, what job the product does for whom and why it's better than existing solutions.
HOST_B: And the FAQ part — the frequently asked questions — is explicitly a decomposition of objections and edge cases. You're pre-answering "but what about X" before anyone asks. Which forces you to think through the full problem space, not just the happy path.
HOST_A: That's a really clever structural trick. Because the instinct is to build first and figure out the value prop later. Working backwards forces you to figure out the value prop first.
HOST_B: And it's also a forcing function for clarity. It's very easy to have a vague idea in your head that sounds good but can't survive being written as a press release. The act of writing forces decomposition.
HOST_A: Now I want to talk about systems problems, because I think this is where a lot of standard decomposition frameworks really break down.
HOST_B: Donella Meadows. "Thinking in Systems."
HOST_A: Yes! Meadows was a systems scientist, and her book is a masterclass in a completely different way of thinking about problems. Her critique of standard decomposition is roughly this: most frameworks treat systems as if they're made of independent components that you can analyze separately and then reassemble. But real systems have feedback loops — the output of component A becomes the input to component B, which feeds back to component A.
HOST_B: And when you have feedback loops, the MECE approach fails because the components aren't actually independent. They're coupled. You can't understand component A without understanding its relationship to component B.
HOST_A: Meadows talks about stocks and flows — stocks are things that accumulate or deplete over time, like water in a tank or trust in a relationship or inventory in a warehouse. Flows are rates of change — things flowing in or out of a stock. And the key insight is that behavior emerges from the interaction of stocks and flows, not from any individual component.
HOST_B: So a business that's losing market share might look like a revenue problem if you use a MECE decomposition. But if you use a systems lens, you might see that market share is a stock, and it's declining because customer defection rate (outflow) exceeds new customer acquisition rate (inflow). And customer defection is high because of a feedback loop between product quality and engineering talent — as quality drops, engineers get demoralized and leave, which reduces quality further.
HOST_A: That's the doom loop. And a MECE issue tree might correctly identify "we need to improve product quality," but it won't reveal that product quality and talent retention are a coupled system where you have to address both simultaneously or neither works.
HOST_B: Systems thinking gives you causal loop diagrams as a decomposition tool. You draw the key variables and the causal links between them, distinguishing reinforcing loops (where A increases B which increases A — virtuous or vicious cycles) from balancing loops (where A increases B which decreases A — like a thermostat). And the decomposition of a systems problem is not "what are the independent components" but "what are the key feedback loops and where are the leverage points."
HOST_A: Meadows actually has a list of leverage points in systems — places where a small change produces a large effect. And they're counterintuitive. Changing numbers in a system — prices, tax rates, subsidies — is actually the least powerful leverage point. Changing the rules of the system is more powerful. Changing the goals of the system is even more powerful. Changing the mindset from which the system arises is the most powerful.
HOST_B: Which is profoundly different from what most management consulting is trying to do. Most consulting says, "here are the levers you should pull." Meadows says the real leverage is often in the structure and goals of the system, not the parameters.
HOST_A: Wait, I hadn't thought of it that way before, but that's basically what Kodak and Nokia failed to do. Their leverage point was in the goal of the system — are we a film company or a memory-capture company? And they couldn't change that, so all the other levers they pulled were operating within a system structure that was already doomed.
HOST_B: That's exactly it. The problem decomposition that would have saved them wasn't "how do we improve our film business" — it was "what is the actual goal of this system, and does our current goal still serve that?"
HOST_A: Okay let's shift to decision problems — when you need to choose between options and you want to be rigorous about it.
HOST_B: Decision trees are the classic tool here. You start with the decision node — the choice you're making — and you branch into each possible action. Then for each action, you add chance nodes — the uncertain outcomes that could follow — with probabilities. And then you calculate expected values backward through the tree.
HOST_A: Which is actually a decomposition of uncertainty. You're making the implicit assumption "I don't know what will happen" explicit and structured.
HOST_B: Right. And the related tool is influence diagrams, which are more compact — they show the relationships between decisions, uncertainties, and outcomes without spelling out every possible path. They're good for visualizing the structure of a decision problem before getting into the numbers.
HOST_A: I feel like there's a meta-level here that we haven't addressed explicitly. How do you know which of all these frameworks to use for a given problem?
HOST_B: Yeah, the meta-framework question. I think the starting point is asking: what type of problem is this? And I'd roughly categorize:
HOST_A: Okay hit me.
HOST_B: If something went wrong and you need to know why — it's a causal problem. Use Five Whys or fishbone. If you need to understand the full landscape before choosing a direction — it's a structural problem. Use MECE issue trees, Porter's, whatever fits the domain. If you're trying to create something new that customers will want — it's an innovation problem. Use JTBD, pre-mortem, working backwards. If you're dealing with an interconnected system with feedback loops — it's a systems problem. Use causal loop diagrams, Meadows's leverage points. If you need to make a specific choice under uncertainty — it's a decision problem. Use decision trees, influence diagrams.
HOST_A: And wicked problems?
HOST_B: Wicked problems don't fit neatly into any of these. The honest answer is: use participatory processes, involve the stakeholders who are affected, treat every intervention as an experiment, and expect the problem to change as you engage with it.
HOST_A: Which sounds like "admit you don't have a framework and muddle through carefully."
HOST_B: Which is essentially correct, but I'd say it more kindly: wicked problems require epistemic humility, not abandonment of rigor. You can still be systematic and evidence-based; you just have to hold your decompositions lightly and update them as you learn.
HOST_A: Okay, practical time. Because this can all sound very theoretical and I know our listeners are coming from engineering backgrounds, product management, business — how do you actually use any of this day-to-day without going full MBA on every problem?
HOST_B: Let's start with the two-minute problem statement check. Before you start any project or any analysis, take two minutes and write down the answer to these three questions: What's the actual problem we're trying to solve? How will we know when we've solved it? What are we not trying to solve?
HOST_A: That third one is so important. Scope definition as a form of decomposition.
HOST_B: Because scope creep is almost always a symptom of fuzzy problem definition. When the team isn't sure exactly what problem they're solving, they naturally start solving adjacent problems they encounter along the way. Two minutes of clarity up front saves weeks of drift.
HOST_A: And the "how will we know when we've solved it" question forces you to engage with measurability, but in the right direction — you're asking what success looks like, not "what can we measure," which avoids the streetlight trap.
HOST_B: Exactly. You're defining success criteria in terms of the problem, and then figuring out how to measure those, rather than defining success as whatever you happen to be able to measure.
HOST_A: What about for engineers specifically? I feel like there are some engineering-specific patterns here.
HOST_B: Debugging is essentially applied Five Whys. When something breaks, the natural instinct is to patch the immediate error. The discipline is to ask: why did this error occur? And why was that possible? And why wasn't there a guard against it? Until you get to the structural reason the bug existed — missing test coverage, unclear ownership, an architectural decision that allowed an invalid state.
HOST_A: And post-mortems are a formalized version of this for incidents. A good post-mortem isn't about blame — it's about decomposing the event into the chain of causes, and then identifying which causes are fixable versus inherent to the system.
HOST_B: Right. The best post-mortems I've seen ask "five why" style questions but also explicitly ask about the system structure — what conditions made this kind of failure possible? Because if you only fix the immediate cause, the same class of failure will recur in a slightly different form.
HOST_A: And for architecture decisions, decomposition shows up in the way you structure the decision document. Amazon has a template called a design doc or ADR — Architecture Decision Record — where you explicitly state the problem you're solving, the options you considered, the criteria you used to evaluate them, and which option you chose and why.
HOST_B: Which is a structured decomposition of the decision. You're making explicit: here are the dimensions of the problem, here are the candidate solutions, here's how each solution scores on each dimension.
HOST_A: And the rubber duck approach to debugging is secretly also a decomposition technique — you explain your code to a rubber duck, and the act of explaining it forces you to decompose it into logical steps, at which point you often discover the bug yourself before the duck says anything.
HOST_B: Which is a principle more broadly applicable: explaining a problem to someone who doesn't understand it — a junior colleague, a friend from outside your domain — forces you to decompose it in a way that reveals assumptions and gaps you didn't know you were making.
HOST_A: I've been in so many conversations where I've started explaining a problem, and by the time I finished the explanation I had the answer. The act of making the implicit explicit is itself a decomposition.
HOST_B: There's a technique called "technical pre-mortem" that I find really valuable for engineering. Before you launch a new system or make a major architectural change, you gather the team and say: it's six months from now and this has completely failed. What happened? What broke? What did we miss?
HOST_A: And you're not predicting failure — you're decomposing the risk space. You're asking: what are all the ways this could go wrong?
HOST_B: And the output isn't "we shouldn't do this." It's "here are the top five failure modes we need to mitigate before we ship." You're using the decomposition to prioritize your risk mitigation work.
HOST_A: Okay I want to do synthesis now because I feel like we've covered a lot of ground and I want to see where we both actually land on this.
HOST_B: Yeah. So let me be honest about where I started and where I am now. I came into this episode as someone who loves frameworks. I think MECE is genuinely powerful, I think structured decomposition is one of the most valuable skills you can develop, and I think the reason most projects fail is that people don't spend enough time defining and decomposing the problem.
HOST_A: And I've been pushing back, saying frameworks can create false precision, they can become the goal instead of the means, they fail on wicked and systems problems, and they can bake in assumptions that lead you to the wrong problem.
HOST_B: Right. And where I've genuinely updated is this: I think the framing "should I use a decomposition framework" is the wrong question. The right question is "which mode of decomposition does this problem require?" And there are problems — wicked problems, systems problems, innovation problems — where MECE and issue trees are actively harmful if you apply them naively.
HOST_A: And where I've updated is: the alternative to structured decomposition is not better intuition — it's usually just unexamined assumptions. The problems I described with over-decomposition are real, but they're problems of bad application, not problems with the underlying practice. The Kodak and Nokia failures were failures of decomposition — they decomposed their problems in the wrong way. The solution isn't less decomposition, it's better decomposition.
HOST_B: So what's the minimum viable decomposition practice? If someone listening to this has five minutes before their next project kick-off, what should they do?
HOST_A: Three questions: what problem are we actually solving, how will we know we've solved it, and what are we not solving? Two minutes of honest answers to those will prevent more suffering than any amount of elaborate issue trees.
HOST_B: And I'd add one more: what type of problem is this? Is this causal, structural, innovative, systems, decision? Because that tells you which toolkit to reach for. Not always perfectly, but directionally.
HOST_A: And if you're not sure which type of problem it is — that's actually a signal that you need to spend more time in problem definition before jumping into frameworks at all.
HOST_B: Which is maybe the deepest lesson of all of this. The frameworks are tools. Before you pick a tool, you need to understand the material you're working with.
HOST_A: And the most important skill — the one that Kodak and Nokia and thousands of companies since have failed at — is the willingness to hold your problem definition lightly. To say, "we think this is the problem, but let's stay curious about whether it actually is."
HOST_B: Because the worst thing you can do is solve the wrong problem brilliantly.
HOST_A: Especially when you invented the solution to the right problem and put it in a drawer.
HOST_B: Kodak coming back to haunt us at the end.
HOST_A: Always. Thanks everyone for listening to Clawd Talks. We went pretty deep today on problem decomposition — MECE, Five Whys, Jobs-to-be-Done, first principles, wicked problems, systems thinking, the whole toolkit. If there's one thing to take away, it's: before you solve, define. Before you define, ask whether you're defining the right thing.
HOST_B: And the links and references — Barbara Minto's Pyramid Principle, Rittel and Webber's 1973 paper on wicked problems, Clayton Christensen's work on Jobs-to-be-Done, Donella Meadows's Thinking in Systems, Taiichi Ohno and the Toyota Production System — we'll have all of those in the show notes.
HOST_A: See you next time.
HOST_B: Cheers.
HOST_A: Okay wait, actually — before we close — I want to go back to something you said about MECE and I think we undersold one critique. You mentioned the streetlight effect, but I don't think we fully worked through why it's so pernicious.
HOST_B: Go on.
HOST_A: The streetlight effect is specifically dangerous in the context of MECE because MECE gives you a false sense of completeness. You've checked all the branches, the tree is exhaustive, you've been rigorous. But if your issue tree was built around measurable things — revenue per segment, conversion rates, NPS scores — you've been exhaustive within the measurable space. You haven't necessarily covered the actual problem space.
HOST_B: And the failure mode is subtle because you can genuinely say "I've checked everything." You have checked everything in your framework. But the framework was built on a biased sample of what's checkable.
HOST_A: Right. And this is where I think the best decomposers I've met are distinguished. They're not just rigorous within their framework. They explicitly ask: what might I be missing because I can't measure it? What's outside the scope of my current decomposition because it doesn't fit the categories I've chosen?
HOST_B: That's almost a metacognitive practice. You're decomposing your own decomposition.
HOST_A: Which sounds recursive and weird, but I think it's actually the difference between analysts who are impressive and analysts who are actually useful.
HOST_B: Fair enough. And it connects to something in Minto's Pyramid Principle that often gets glossed over — she actually talks about the importance of not just having a MECE structure, but making sure you've chosen the right governing principle for your decomposition. Because there are multiple valid MECE decompositions of any problem, and they lead you to very different places.
HOST_A: Can you give an example?
HOST_B: Sure. Take the question "why are our revenues declining?" You could decompose it by product line — revenue from product A, product B, product C. That's MECE. Or you could decompose it by customer segment — revenue from enterprise, mid-market, small business. Also MECE. Or by geography — EMEA, APAC, Americas. Also MECE. Or by sales channel — direct, partner, online. Also MECE.
HOST_A: And depending on which decomposition you choose, you'll focus your attention on different things. If the problem is in the enterprise segment specifically, the product-line decomposition might not reveal it. If the problem is in APAC specifically, the customer-segment decomposition might not reveal it.
HOST_B: So the art is choosing the decomposition axis that's most likely to reveal the actual structure of the problem. And that requires domain knowledge, hypothesis generation, and yes — sometimes gut instinct about where to look first.
HOST_A: Which is why experienced consultants are valuable even if a junior analyst can build a technically better issue tree. The experience is in knowing which axis to cut along.
HOST_B: And this is also why the hypothesis-driven approach is powerful. If you go in with a hypothesis — "we think the problem is in enterprise sales, not product quality" — you immediately know which decomposition axis to use. And if your hypothesis is wrong, you learn something fast.
HOST_A: Okay now I'm satisfied. That was the thing I wanted to add.
HOST_B: Good instinct. That's actually one of the most practically useful things we've said today — choosing the decomposition axis is a skill in itself, not just a matter of applying the MECE rule.
HOST_A: And it's something that's very hard to teach from a textbook. You learn it by building a lot of issue trees and noticing which ones were useful and which ones led you astray.
HOST_B: Which is perhaps the most honest thing we can say about all of these frameworks. They're not recipes. They're practices. You develop them through repeated application, failure, and reflection.
HOST_A: Which is a bit ironic, because the whole point of frameworks is to codify expertise so you don't need years of experience to apply it.
HOST_B: Right, and they do do that — they give you a good starting point that's much better than blank-page intuition. But the really sophisticated application of any framework requires understanding its limitations, which you can only really learn by experiencing those limitations.
HOST_A: So: use the frameworks. Learn their limits. Hold them lightly. And never forget to ask whether you're working on the right problem in the first place.
HOST_B: Perfectly put. Now we're actually done.
HOST_A: Now we're done.
HOST_B: Brilliant episode. Thanks for pushing back on me throughout.
HOST_A: That's what I'm here for.