Define the Problem You're Actually Solving

Over and Over Again

There is a version of this story that almost every IEC knows personally.

Something in the practice keeps coming up. It's not catastrophic. It's not even that unusual. But it keeps happening, season after season, in ways that feel like they should have been resolved by now.

So something gets adjusted. A new policy gets added. A conversation gets had. Things improve for a few weeks. And then, quietly, the same situation surfaces again. Maybe in a slightly different form. Maybe in exactly the same one.

It's not that the fix didn't work. It's that the fix addressed the visible part of the problem, while the actual problem kept running underneath.

This is one of the most common patterns I see in IEC practices, and it has nothing to do with effort or experience. It has everything to do with how the problem was defined before anyone tried to solve it.

This article is part of the 12-part Business Architecture for IEC Practices series. Sections 1 through 8 examined how business decisions take shape beneath the surface of an advising practice. Starting with Section 9, the series shifts into what to do with that awareness. This section focuses on the first step: defining the problem clearly enough that the right solution becomes obvious.

Download the Section 9 PDF
This article introduces the concept. The accompanying playbook walks through the framework and reflection prompts to help you consider how this applies to your own practice. It also includes the Define framework and guided prompts to work through one specific problem in your own practice.

Download the IEC Business Tool Evaluation Guide Part 1: Define
Part 1 of 3: A standalone decision framework you can use right away to evaluate any tool, system, or operational change you’re considering in your practice.

What Most Problem Definitions Actually Are

When an IEC describes something that isn't working in their practice, it usually sounds like one of these:

"I'm spending too much time on communication." "My students don't do what I ask them to do." "My process falls apart in the middle of application season." "I feel scattered, and I can't figure out why."

Every one of those statements is real. Every one of them reflects something genuinely frustrating. And not one of them is a defined problem.

They're observations. And observations, however accurate, don't point to solutions. They point to symptoms.

The difference between an observation and a defined problem is specificity. A defined problem describes exactly what is happening, under what conditions it happens, and what it costs when it does. It's specific enough that someone outside your practice could read it and understand precisely what you're dealing with.

That level of specificity feels like extra work when something already feels urgent. But it's the only thing that prevents the same situation from coming back three months later, wearing slightly different clothes.

What Happens When the Definition Stays General

Here is what I consistently see when a problem is addressed before it is defined.

An IEC notices that parent communication is taking more time than it should. The fix is a new policy: emails will be answered within 48 hours, and communication outside of scheduled meetings will be limited.

The policy gets communicated. Things improve. And then a situation comes up that feels like an exception. A judgment call gets made. And slowly, the pattern returns.

Not because the advisor wasn't committed to the policy. Because the policy addressed the volume of communication without addressing why the communication was happening in the first place.
If the real problem was that families had no defined communication structure to operate within from the start of the engagement, adding a response-time policy doesn't solve that. It manages the output of it.

That's the difference between fixing a symptom and addressing a source. And you can't see the difference until the problem has been defined specifically enough to show you where it actually lives.

What Specific Actually Looks Like

The shift from observation to a defined problem isn't complicated. It just requires slowing down long enough to answer three questions before reaching for a solution.

1. What is actually happening, specifically and observably, not how it feels, but what is occurring?
2. When does it happen, and under what conditions does it consistently show up?
3. What does it cost when it does, in time, in energy, in consistency, or in capacity?
   
   

When those three questions have clear answers, something changes in how the problem looks. It stops feeling like a personal frustration and starts looking like a structural gap. And structural gaps, unlike personal frustrations, have structural solutions.

Why This Is the First Step in the Series

The next three sections of this series, Diagnose, Build vs. Adopt, and Decide, all depend on this one.

You cannot accurately diagnose where a problem originates until you know specifically what the problem is. You cannot evaluate whether a solution addresses it until you can describe what addressing it actually looks like. You cannot make a decision that will be consistent until the thing you're deciding about is clearly defined.

This isn't a framework step for the sake of having a framework. It's the work that makes everything after it actually useful.

The IECs I've worked with who have made lasting changes to how their practices operate didn't start with better tools or stronger policies. They started by getting honest and specific about what was actually happening. That clarity is what made everything else possible.

Where This Leads

Once a problem is defined clearly, the next instinct is usually to solve it.

But there's one more step before a solution will actually hold. Because defining what's happening and knowing where it originates are two different things. And almost every problem in an IEC practice shows up somewhere other than where it starts.

That's what Section 10 addresses.
So take the time to truly define the issue and be as specific as possible!