Before You Build, Understand the Problem

We love solutions.

A new platform will make things easier. A new process will make things more efficient. A new dashboard will finally give us the information we need. A new workflow will eliminate the manual work that has been frustrating everyone for months.

And sometimes, those things are exactly what we need.

But I’ve found that one of the easiest ways to make a problem more complicated is to start solving it before we really understand it.

Before we build something new, we need to understand what isn’t working about what we already have.

That sounds simple. In practice, it can be surprisingly difficult.

The solution isn’t always the problem

Organizations are constantly responding to problems. Data is inconsistent, so someone suggests a new system. Communication is breaking down, so we add another meeting. Staff are spending too much time on administrative work, so we look for automation.

But the proposed solution isn’t necessarily addressing the root of the problem.

“We need a new CRM” might actually mean that different teams have different definitions of what information needs to be tracked.

“We need another project management tool” might actually mean that no one has agreed on how priorities are set or who owns the work.

“We need more reporting” might actually mean that the organization hasn’t decided which information is important enough to measure.

“We need to automate this” might actually mean that the underlying process has accumulated unnecessary steps over time.

If we skip that distinction, we can end up building a very sophisticated solution to the wrong problem.

And once we have invested time, money, and energy into that solution, it becomes much harder to step back and ask whether we were solving the right thing in the first place.

Start with questions, not answers

When I approach a complicated project, I try to resist the urge to immediately figure out what the solution should be.

Instead, I want to understand the situation.

What are we actually trying to accomplish?

Who is experiencing the problem?

What does the current process look like?

Where does it break down?

What workarounds have people created?

What information do we have, and can we trust it?

What decisions are we trying to make?

What would actually be different if we solved this successfully?

These questions don’t always produce an immediate answer. That’s the point.

They give us enough context to make a better decision about what comes next.

The current state has something to teach us

There is a tendency to treat an existing system as something that needs to be replaced as soon as it becomes frustrating.

Sometimes it does.

But before throwing something away, I want to understand why it looks the way it does.

A spreadsheet that everyone hates might still contain years of valuable information.

A complicated process might exist because someone was trying to solve a legitimate problem five years ago.

A workaround might reveal a gap that the formal process never addressed.

Even inconsistent data can tell us something about how different people understand the work.

The current state is data.

It tells us how work is actually happening, not necessarily how we think it is happening.

That distinction matters.

The process documented in an SOP may look completely different from the process employees have developed to get their jobs done. A system may have been designed around one organizational structure but still be carrying assumptions from several years ago. And a tool may technically support a process that is, in reality, too cumbersome for people to use consistently.

If we don’t understand those realities, we risk designing the next system around assumptions rather than evidence.

Listen to the people doing the work

One of the most valuable parts of any process or systems project is talking to the people who interact with it every day.

Not just leadership.

Not just the person who originally designed the process.

The people actually doing the work.

They know where information gets lost. They know which steps take twice as long as they should. They know which reports no one uses. They know which parts of a system they avoid and which spreadsheets they secretly maintain because the official process doesn’t quite work for them.

Those details matter.

They also help us distinguish between a problem with the system and a problem with the process itself.

Sometimes the answer is a new tool.

Sometimes it is a small change to an existing process.

Sometimes it is better documentation.

Sometimes it is clearer ownership.

And sometimes the answer is to stop doing something altogether.

We can’t make that distinction if we don’t take the time to understand the work.

Resist the urge to build for every possibility

Another common trap is trying to design a solution that will account for every possible future scenario.

It is understandable. We don’t want to build something today only to discover six months from now that it can’t accommodate a new program, team, reporting need, or workflow.

But trying to anticipate everything can create its own kind of complexity.

The result can be a system with dozens of fields no one understands, processes no one follows, and rules designed for hypothetical situations that may never happen.

Good systems don’t have to predict the future.

They need to be clear enough to support today’s work and flexible enough to adapt when things change.

That requires making intentional choices about what matters now, and accepting that some decisions can be revisited later.

Better questions lead to better systems

I don’t think every organizational problem requires a new system.

And I don’t think every existing system needs to be rebuilt.

What I do think is that we should be more thoughtful about the space between identifying a problem and choosing a solution.

That space is where the most important work often happens.

It is where we listen, investigate, map the current state, examine the data, challenge assumptions, and decide what actually needs to change.

Only then can we start building.

Because the goal isn’t simply to create something new.

The goal is to create something that makes the work better.

And that starts with understanding what the work actually is.

Before you build, let’s find the real problem.