Most organizations are not short on ideas. Ideas tend to show up everywhere: in meetings, in Slack/Teams threads, in sales conversations, in customer calls, and increasingly in AI demos that make everything look both possible and urgent at the same time. Someone asks if we can "just build this". Someone else says the customer really needs it. A deal is almost signed. A capability feels strategically important. An opportunity looks too good to miss.

None of this is wrong, but very little of it is a problem — at least not yet. The uncomfortable truth is that almost everything can be framed as a problem. That doesn't mean everything matters and it certainly doesn't mean everything deserves time, focus, and engineering capacity. This perspective is an invitation to slow down just enough to notice the difference.

There's a sentence I often come back to, because it sounds backwards at first — and because it keeps proving itself true:

Solutions are easy. Problems are hard.

It is relatively easy to build technology, and today it's easier than ever to ship features, spin up proofs of concept, create roadmaps that look impressive, and say yes to good ideas. It's easy to get excited about a solution — especially when it's concrete, demoable, and makes us feel like we're moving.

What's genuinely difficult is something else entirely: identifying the right problem. The problem that actually creates value when it's solved. The problem that's real, meaningful, and worth the cost of solving. Too often, we rush past that part. We move straight into scoping, estimating, designing, and implementing. We discuss timelines before we're clear on impact. We talk about architecture before we're aligned on what should change in the real world, and once we've started building, it becomes surprisingly easy to forget the original question altogether.

A problem without a clear definition of success is just an interesting discussion. A solution without a clearly articulated problem is often just an expensive activity.

I Learned This the Hard Way

I was working in an organization where sales had significant influence over direction and priorities. Product and engineering were often reactive, pulled toward the loudest opportunity rather than the clearest strategy. It created fragmentation, constant context-switching, and an environment where focus was fragile. Then came what looked like a big opportunity.

A well-known international brand with significant long-term potential. Sales believed the deal was close, and in an effort to be proactive, we started preparing. We moved capacity. We began building parts of what we expected the customer would need. We wanted to be ready the moment the contract was signed. Four weeks later, the contract wasn't signed. Four weeks of engineering time had gone into something that never materialized. Not because anyone acted in bad faith. Not because the opportunity wasn't real. But because hope quietly turned into an engineering problem.

The cost wasn't just time. It was focus, momentum, and trust. And it was everything we didn't do during those four weeks — including critical work with real deadlines and real consequences. Looking back, there's one sentence I wish I had been able to say clearly, calmly, and with confidence:

"This is not an engineering problem yet. This is a sales hope."

Not because sales isn't important or commercial opportunities don't matter. It is because hope is not a prioritization model.

Engineering time is one of the most expensive and consequential resources we have. Once we start building, we don't just create code. We lock in direction, expectations, complexity, and long-term maintenance for ourselves and potentially our customers. Engineering should not be where we discover whether a problem is real. Engineering should be where we solve problems that have already earned the right to be built.

That raises an important question: what does it actually mean for a problem to earn that right? It doesn't mean we need perfect certainty. But it does mean that some basic thresholds should be met before we commit heavy capacity. Things like whether a contract is signed, whether a start date is agreed, whether the customer has allocated their own resources, whether success is defined in something other than vague ambition.

If those things aren't in place, the idea might still be interesting. It might be a hypothesis worth exploring, or a conversation worth continuing. But it may not yet be an engineering problem — and treating it as one too early can be surprisingly costly.

Goals Are Not Motivational Posters

The same pattern shows up when we talk about goals. We all like ambitious goals. We like saying we want to be market-leading, best-in-class, or at the forefront of AI adoption. These statements sound good. They look good in strategy decks. They give a sense of direction.

But on their own, they don't actually help us make decisions. Because they avoid the hard parts: what we're leading on, who we're doing it for, what we're willing to prioritize — and just as importantly, what we're willing to deprioritize.

This is why I keep coming back to a simple reminder personally and with clients: Goals are not motivational posters. Goals are choices, and choices imply trade-offs. You can't optimize for speed, quality, customization, innovation, stability, and growth all at once. If everything is important, nothing is guiding. And if no one ever says no, you don't really have a strategy — you just have a growing queue of wishes.

Customer Wishes Are Not Problems

Customers, by the way, are not immune to this either. Customers are very good at telling us what they want. They ask for dashboards, integrations, automations, AI features, buttons, and workflows. Often, those requests make sense, but customer wishes are usually framed as solutions. The underlying problem is something else entirely.

The most useful question I know in these situations is simple, but powerful:

If we deliver exactly what you're asking for — what will actually be different afterward?

That question changes the conversation. It moves us away from features and toward outcomes. It forces both us and the customer to think about change: who works differently, which decisions become easier, what takes less time, what becomes safer or cheaper or faster.

If no one can clearly articulate what changes after delivery, we probably don't have a problem yet. We have a request, and those are not the same thing.

When Building Gets Easier, Choosing Gets Harder

All of this becomes even more important now, as AI lowers the cost of building. We can create solutions faster than ever. Which is exciting — and dangerous. Because when the barrier to building goes down, the risk of building the wrong thing goes up with it. Speed amplifies both good and bad decisions.

In that world, the real competitive advantage isn't the ability to build quickly. It's the ability to choose wisely. When solution thresholds drop, problem quality has to rise.

What This Means

This isn't just a product, sales or engineering concern. It's something we all influence.

As individuals, we can get better at pausing when a solution feels obvious, and asking what problem it's actually trying to solve. We can challenge ideas with curiosity rather than resistance, and become comfortable separating interest from importance.

As teams, we can protect focus by defining success early, treating hypotheses as hypotheses, and testing cheaply before committing heavily. We can make it normal to ask what will be different afterward — and how we'll know.

As an organization, we can treat engineering time as the strategic asset it is. We can use goals and OKRs to keep problems visible, rather than to dress up wish lists. And we can create shared language that makes it easier to say "not yet" without shutting down momentum.

The point isn't to slow down. It's to move with intention.