AIAI for Business

The one AI skill that outlasts every tool upgrade

Most AI tools you're using today will look different or obsolete within two years. The professionals who stay effective aren't the ones who memorize features, they're the ones who've learned to think in terms of problems, constraints, and outputs.

🎙️

Listen to the podcast

4 min

The concept at the center of this article isproblem decomposition for AI: the ability to break a complex, ambiguous business problem into discrete sub-tasks that a language model can actually handle well. It sounds simple. It isn't practiced nearly enough, and it's the single skill that transfers cleanly from GPT-4 to Claude to whatever ships next year.

The confusion around it is real. Most professionals who use AI tools regularly think they're already doing this. They're not. They're doing something closer to wish-casting: typing a big, vague request and hoping the model figures it out. Sometimes it does. More often, the output is plausible-sounding but structurally wrong, and the user doesn't have the framework to know why.

Why this skill matters for anyone using AI at work

Tool interfaces change constantly. OpenAI redesigns ChatGPT's feature set several times a year. Anthropic ships Claude updates that change how the model reasons through multi-step problems. Microsoft embeds Copilot deeper into Office in ways that shift what you need to type versus what the system infers automatically. Keeping up with all of that at the feature level is a full-time job nobody has.

Problem decomposition is different because it operates one layer above the interface. When you understand how to break a problem into well-scoped pieces, you can adapt that thinking to any tool, any context window size, any new model release. A McKinsey analyst who learned to decompose strategy questions for GPT-3.5 in 2023 can apply the same logic to Gemini Ultra or a specialized legal AI today. The underlying discipline is the same.

There's also a career signal dimension. As of 2026, most hiring managers in consulting, finance, and product management report that they can no longer distinguish candidates who "use AI" from those who don't, because everyone claims to. What they can distinguish is whether a candidate understands why a particular AI output is wrong and can fix it systematically. That requires decomposition skills, not tool familiarity.

How it actually works

The core mechanic is this: before you type anything into an AI tool, you identify the output you actually need, then trace backward to list the distinct cognitive steps required to produce it.

Take a concrete example. A senior product manager at a mid-sized SaaS company needs to prepare a competitive positioning memo for a board meeting. The instinctive move is to open ChatGPT and type: "Write a competitive positioning memo comparing us to Salesforce and HubSpot for our board meeting." The output will be generic, probably structured around whatever the model has absorbed about competitive memos in general.

The decomposed version looks different. First, the PM defines what "competitive positioning" means in this specific context: market segments, pricing tiers, and two or three functional differentiators that actually matter to this board. Second, they ask the model to summarize known public information about Salesforce's mid-market strategy, separately from HubSpot's. Third, they feed in internal data (win/loss rates, sales call notes, customer survey excerpts) and ask the model to extract the patterns that appear. Fourth, only after those building blocks exist, they ask the model to draft the memo structure.

Each sub-task is narrow enough that the model can do it well. The integration of those outputs into a coherent argument stays with the human, because that's where judgment and context live. The PM hasn't memorized a prompt library. They've applied a thinking process that works regardless of which model sits underneath.

This is also why the obsession with "prompt engineering" as a standalone skill has a limited shelf life. Specific prompt syntax changes with every model update. The reasoning process that generates good prompts does not.

When to use this approach and when not to

Decomposition is worth the investment when the task is consequential, complex, or will be repeated. Board memos, due diligence summaries, policy drafts, strategic recommendations: these justify the upfront effort of mapping the sub-tasks before touching the tool.

It's overkill for routine, low-stakes requests. If you need to reformat a table or generate a first draft of a routine client email, just ask directly. Applying a rigorous decomposition process to every AI interaction is a form of over-engineering that wastes the time decomposition is supposed to save.

The honest tradeoff is cognitive effort. Decomposing a problem properly takes five to fifteen minutes of structured thinking before you open any AI tool. Many professionals skip this because it feels slower. It is slower, at the start. But it consistently produces better first drafts, reduces revision cycles, and builds a repeatable approach the person can refine over time. Teams at firms like BCG and Bain have started formalizing this in their internal AI training, precisely because ad hoc prompting produces inconsistent quality at scale.

One more genuine limitation: decomposition requires enough domain knowledge to know what the sub-tasks actually are. A junior analyst who doesn't understand what makes a competitive positioning memo useful to a board will struggle to decompose the problem correctly, regardless of how well they've internalized the methodology. The skill amplifies existing expertise. It doesn't replace the need for it.

The professionals who will still be effective when today's specific tools are gone are the ones who treat AI as something to direct, not something to defer to. Decomposition is the operational version of that principle: concrete, teachable, and independent of any particular platform's feature set.

Finished reading?

Validate your read to earn XP and feed your radar.