Why Problem Solving Doesn't Need to Start From Scratch

Complex problems are hard to tackle because they hold many factors at once, and those factors interact with each other in ways that are difficult to see clearly. The interrelationship between them is often what makes the problem hard — not any single factor on its own.

But here is the useful part: most problems a business faces today have already been faced, in some form, by a company that came before it. Over time, frameworks get built around these recurring problems — structured ways of breaking a big, tangled problem into smaller pieces that can actually be worked on.

A simple example

One of the most common frameworks in business is the profitability framework. Every business wants to make more money and keep more of what it makes. The framework breaks that single, vague goal into two clear levers — revenue and expenses — and then breaks each of those into smaller, more specific moves.

Take a coffee shop looking to bring in more revenue and keep a higher share of it:

None of these ideas are exotic. What the framework does is give you a structure to generate them systematically, rather than relying on whatever comes to mind first.

What a good framework actually gives you

It turns a vague goal into specific, workable pieces. "Make more money" is not a plan. "Increase basket size per customer" is something you can actually act on, measure, and improve. The framework's real value is in the decomposition — taking something broad and making it concrete enough to solve.

It makes ideas easier to remember and explain. Humans are unusually good at holding onto things that are logically connected, and unusually bad at holding onto disconnected facts. Consider two versions of the same story:

• The king died. The queen died.
• The king died. The queen died of grief.

The second version sticks with you. Not because it has more information — it has almost the same information — but because the events are connected by logic. A framework does the same thing for a business problem: it doesn't just list the pieces, it shows you how they relate, which makes the whole thing easier to hold in your head.

This matters more than it might seem. Research on business problem-solving (Cracked It!, by Bernard Garrette, Corey Phelps, and Olivier Sibony) suggests that raw intelligence accounts for only about 20% of someone's ability to solve a business problem well. The rest comes down to experience, exposure to similar problems, and — critically — the ability to apply the right frameworks to structure the thinking. This is part of why consulting firms invest so heavily in training their people on frameworks, not just hiring for raw horsepower.

It makes your solution easier to communicate to others. Most real business problems involve more than one stakeholder, and because of that, effective communication is critical to getting their buy-in — a good solution explained badly is nearly as useless as a bad solution. If a solution is structured clearly in your own mind, you can walk someone else through it far more effectively than if it lives in your head as a collection of loosely connected ideas. The framework is not just a thinking tool — it is also the vehicle you use to bring other people along with your reasoning.

It exposes your thinking to scrutiny. A structured framework forces your reasoning into the open — every branch, every assumption — so other people can follow it, and so you can catch your own blind spots before someone else does. By laying out your solution this way, you give a second pair of eyes the chance to challenge your logic, push back on a weak assumption, or catch something you missed — which helps you avoid confirmation bias and makes it far more likely your solution actually holds up.

This is also where the idea of being MECE comes in — a term consultants use constantly, short for Mutually Exclusive, Collectively Exhaustive. It means your categories don't overlap (mutually exclusive) and together they cover the whole problem with nothing left out (collectively exhaustive). A framework structured this way makes it much harder to fool yourself — or your audience — into thinking a solution is complete when it isn't.

The caveat

Frameworks are powerful, but they are not free of risk. Two things are worth holding onto.

First: not every problem has an off-the-shelf framework, and that's fine. The deeper skill is not memorizing frameworks — it's the underlying habit of breaking any problem into its component parts. That habit is the real entry point to building a framework around a problem that doesn't have one yet.

Second: borrowed frameworks come with borrowed assumptions, and those assumptions are not always visible. Imagine hiring a firm to help you reduce employee turnover. Their solution: have your longest-tenured employees fill out a personality questionnaire, give the same questionnaire to job candidates, and prioritize the candidates whose answers most closely match.

It sounds reasonable. But look at what it quietly assumes:

• That personality traits are actually what drives tenure — when the real driver might be something else entirely. Maybe the reason employees don't stay is a weak compensation package, and they leave for the first better offer that comes along. If that's true, the employees who do stick around for years aren't necessarily a good personality match — they may simply be the ones your competitors weren't interested in hiring away in the first place
• That a questionnaire can accurately capture how someone actually behaves — when what people report about themselves is consistently different from what they do in practice

Neither assumption is stated out loud. Both could be quietly wrong. A framework is only as good as the assumptions baked into it, and those assumptions deserve to be questioned every time — especially when the framework wasn't built for your specific situation in the first place.

Why this shapes how we work

This is exactly why, at Black Feather Consulting, we build a framework around each specific problem we are solving for a client — rather than reaching for a generic, off-the-shelf template and hoping the assumptions happen to fit their business.

The framework itself is not the point. It is the vehicle. It lets us show you, step by step, exactly how we got to a recommendation — which branches we considered, which assumptions we made, and why. That structure is what makes it possible for you to actually evaluate our thinking, push back where something doesn't sit right, and approve the logic before we move forward together. A recommendation you can't see the reasoning behind is not one you can really trust.