The Most Expensive Assumption in Government

One of the first questions I ask when I begin working with a team is surprisingly simple. “What problem are you trying to solve?”

You’d think that question would have an immediate answer. It usually doesn’t. Because most organizations spend far more time discussing solutions than defining the problem those solutions are intended to address.

That’s an expensive habit.

At CAIP, ideas came from everywhere. Some originated with leadership. Others came from policy changes, operational pain points, or feedback from applicants and staff. Every idea was well intentioned. Every request represented someone trying to make the program better.

But not every request addressed the underlying problem. Sometimes it addressed a symptom. Sometimes it addressed yesterday’s problem. Sometimes it addressed an assumption that had never been tested.

Before deciding what to build, the team had to understand what it was actually trying to improve.

I’ve seen organizations spend months debating the best solution while spending only minutes discussing the problem itself. Soon everyone is discussing implementation details. Meanwhile, the original problem quietly fades into the background.

This happens because solutions feel tangible. Problems are often messy. Solutions can be estimated. Problems require exploration. Solutions can be scheduled. Problems require curiosity. It’s much easier to start building than it is to stop and ask whether we’re building the right thing.

One question has changed more conversations than any framework I’ve ever introduced. How do you know that’s the problem?

Not: “Why do you think that?” Not: “Can you prove it?” Simply: “How do you know?”

That question changes everything. It invites evidence instead of opinion. It encourages observation instead of assumption. It shifts the conversation from defending ideas to understanding reality.

Sometimes the answer is backed by data. Sometimes it’s supported by user research. Sometimes it’s based on years of operational experience. And sometimes the answer is refreshingly honest: “We don’t know. It just seems like the right thing to do.” There’s nothing wrong with that answer. As long as we recognize it for what it is. An assumption.

Assumptions aren’t the enemy. Untested assumptions are.

Every meaningful improvement begins with assumptions about what users need, what is causing friction, and what might create a better outcome. The goal isn’t to eliminate assumptions. The goal is to identify them early enough that we can learn whether they’re true. That’s very different from treating them as requirements that must simply be implemented.

The earlier we identify our assumptions, the cheaper they are to test.

A conversation is cheaper than a prototype. A prototype is cheaper than development. Development is cheaper than deploying the wrong solution.

The longer an assumption survives without being challenged, the more expensive it becomes.

At CAIP, some of the most valuable discussions happened before development began because it was reducing the risk of solving the wrong problem. Sometimes those conversations confirmed the original idea. Other times they uncovered a better one. Both outcomes moved the program forward.

Organizations don’t improve by having better answers. They improve by asking better questions.

And perhaps the most important question of all is still the simplest: What problem are we actually trying to solve? Because every solution depends on getting that answer right.

When was the last time your team challenged the problem instead of the proposed solution?

Reply or comment—I read every one.

CAIP is a program we follow throughout my book,