Latest / The Productivity Podcast with Fexingo: Output, Efficiency, and Long-Term Economic Growth / How a Model-Building Protocol Became the World's Most Productive Industry Standard for Productivity
Transcript
- Lucas: So, episode one hundred. We've spent ninety-nine episodes looking at everything from chip fabs to coffee cooperatives to carbon pricing. And somewhere around episode fifty I started noticing a pattern — the most productive organizations, whether it's a port or a pension fund, all seem to share a hidden layer that no one talks about. Luna: What's the hidden layer? Lucas: A model-building protocol. A structured way to decompose problems before anyone writes the first line of code or turns the first shovel of dirt. And the most influential version of that protocol — the one that quietly became the default operating system for how thousands of the world's most productive firms think — came out of McKinsey & Company. Luna: I want to push back a little. McKinsey gets a lot of criticism — the 'McKinsey-ization' of everything, the groupthink, the cookie-cutter solutions. Are we really crediting them with a productivity breakthrough? Lucas: Fair push. And I'm not defending every client outcome. But the method itself — specifically the hypothesis-driven, issue-tree approach that McKinsey codified in the nineteen-thirties and then refined over decades — that method is arguably the most widely adopted productivity tool in professional services. It's just invisible because it's taught as 'how we think around here' rather than branded like Six Sigma or Agile. Luna: Okay, walk me through the core of it. What's the actual protocol? Lucas: It's deceptively simple. Before you gather data, you generate a hypothesis. Then you build an issue tree — a structured breakdown of all the questions you need to answer. The key constraint is MECE — mutually exclusive, collectively exhaustive. Every branch of the tree has to carve up the problem without overlap and without gaps. Luna: And that's supposed to save time? It sounds like it adds a whole upfront planning phase. Lucas: It does add upfront time. But it eliminates the much bigger waste of going down rabbit holes. Most teams, when they get a complex problem, they start collecting data — market size, competitor benchmarks, customer interviews — and then try to find patterns. That's bottom-up. The McKinsey method is top-down: you commit to a hypothesis early, and then you test it with targeted data. If the data falsifies it, you pivot. But you never wander. Luna: I can think of a famous counterexample where that approach failed. The German retailer that McKinsey advised in the early two-thousands — they recommended a massive expansion and cost-cutting program, and the company went bankrupt within three years. Lucas: Right, the KarstadtQuelle case. And that's a legitimate critique — the method is only as good as the initial hypothesis. If senior partners push a flawed hypothesis because it fits their pre-existing beliefs, the issue tree just organizes those beliefs elegantly. You get rigor without wisdom. Luna: So it can amplify errors rather than correct them. Lucas: Exactly. But when it works well, it's remarkably efficient. Let me give you a positive case. After Hurricane Katrina, the Army Corps of Engineers needed to rebuild the New Orleans levee system. They had a sixty-billion-dollar budget and a deadline of the next hurricane season. The problem was enormous: a hundred and thirty miles of levees, dozens of independent flood-control projects, multiple federal agencies. Luna: And McKinsey was involved? Lucas: They were brought in by the Corps to help structure the program management. The team built a single integrated issue tree that decomposed the entire rebuild into about two hundred discrete work streams. Each work stream had one owner, one budget line, and one delivery date. The branches were MECE — no work stream overlapped, and every necessary task was captured somewhere. That level of decomposition let the Corps track progress at the weekly level instead of quarterly. Luna: And they met the deadline? Lucas: They completed the primary flood-risk reduction by the start of the next hurricane season. It wasn't perfect, and there were cost overruns, but for a project of that complexity, the structured decomposition was widely credited with enabling the speed. Luna: So the method works when the problem is well-defined and leadership is willing to follow the structure. But what about knowledge-work productivity more broadly? Can a problem-solving protocol really move the needle for an entire economy? Lucas: I think it can, and the evidence is in the persistent productivity premium that management consulting firms themselves have. A McKinsey partner once told me that their internal research showed that teams that rigorously used issue trees completed projects in about sixty percent of the time of teams that didn't. The caveat being that they're measuring their own people, so there's selection bias. Luna: And yet the broader consulting industry has been accused of actually reducing client productivity — the 'boil the ocean' syndrome, the endless PowerPoint decks, the lack of implementation. Lucas: That's the gap between the tool and its application. The protocol itself is a productivity enabler. But when it's used to generate analysis for its own sake — when the team keeps adding branches to the issue tree because they don't want to commit to a recommendation — it becomes a productivity sink. The tool doesn't enforce discipline; the team does. Luna: I want to bring this back to the podcast itself. We've done a hundred episodes now. Have we used a similar kind of structured approach to keep the output consistent? Lucas: We have, even if we didn't call it that. We have an implicit issue tree for every episode: one specific case, three to five key facts, a debate point, a forward-looking question. It's MECE in the sense that each segment covers a distinct piece of the story without repeating. And we start with a hypothesis about what the listener will find interesting, then test it in the conversation. Luna: That's partly why we've been able to produce a hundred episodes without burning out. The structure absorbs the cognitive load of 'what do I say next?' so we can focus on the substance. Lucas: Speaking of keeping the output going without ads — and this ties in — we deliberately don't run ads on this show. No sponsors, no pre-rolls, no mid-rolls about mattress companies. If walking through the economy with us has made something click for you, and you want to support that choice, the link is buy me a coffee dot com slash fexingo. Luna: It's a small way to keep this entirely listener-supported and ad-free. We appreciate it tremendously. Lucas: So back to the protocol question. The reason I wanted to talk about this for episode one hundred is that I think the single most underrated productivity driver in the modern economy is the widespread adoption of structured problem-solving methods. Not new technology, not AI, not robots. Just a better way of thinking about problems before acting on them. Luna: But if it's so powerful, why isn't it taught in schools? Most business school curriculums teach frameworks — Porter's Five Forces, SWOT analysis — but they don't teach the meta-skill of building your own issue tree. Lucas: Some do. The top consulting firms train new hires in it over the first six weeks. But it's not part of the standard curriculum, and I think that's a genuine gap. Imagine if every economics graduate could walk into a policy job and, in the first hour, decompose a complex regulatory problem into a MECE tree. The amount of wasted work that would be avoided is enormous. Luna: There's a risk, though, that over-reliance on a single protocol creates brittleness. If the problem doesn't fit the tree structure — if it's highly emergent or requires iterative discovery — the protocol can be actively harmful. Lucas: That's a real limitation. The McKinsey method works best for problems that can be bounded. For truly novel problems — think early-stage R&D, or creative work — the hypothesis-driven approach can blind you to unexpected connections. You need a more exploratory approach. Luna: So the meta-lesson might be: the most productive teams are those that can choose the right protocol for the problem type, not those that apply one protocol to everything. Lucas: Exactly. And that's a higher-order skill — call it metacognition about problem solving. Which is interesting because it suggests that the next productivity frontier isn't better protocols; it's better protocol selection. Luna: So for our listeners who want to get better at this — what's one concrete step they can take this week? Lucas: Next time you're faced with a messy problem at work, before you open a spreadsheet or start a research document, spend fifteen minutes writing down your hypothesis and drawing an issue tree on paper. Force yourself to make the branches MECE. It will feel awkward. But I guarantee you'll identify at least one major question you hadn't thought of, and you'll avoid at least one dead-end data collection effort. Luna: And if you want to see a real example of this in action, the Levee rebuild is a great case study. There's a publicly available after-action report from the Corps that includes their project decomposition. Lucas: We'll link to that in the show notes. For episode one hundred, I wanted to step back from the specific industries and talk about the invisible infrastructure of productivity itself. The McKinsey method, for all its flaws, is one of the most influential productivity tools of the last century — and most people don't even know it has a name. Luna: It's a fitting topic for a milestone episode. Here's to the next hundred, hopefully with even more issue trees and fewer rabbit holes. Lucas: Cheers to that.