IT'S NOT A RESOURCE PROBLEM. IT'S A VISION PROBLEM.

By Dave Barcos, Founder of North Bank Innovations

I sat across the table from a founder who'd just found her problem.

She managed calendars for three partner organizations, and every week someone's meeting collided with someone else's. She lost hours untangling it by hand. So she decided to fix it. She'd build a tool that connected the calendars automatically. No more back and forth. No more double-booking.

It felt tractable. It felt useful. For the first time in months, it felt like she had an answer instead of a vague ambition.

Eight months later, she was still building. Not because the sync was hard. The sync worked in a weekend. She was still building because every person who touched the product had a different relationship to their calendar. Some blocked hours defensively. Some double-booked on purpose and let people sort it out live. Some ran their calendar through an assistant who guarded it like a vault. Some didn't use a calendar at all. They used a notebook and a memory.

None of that showed up in the pain point. It only showed up once she had users. By then she'd spent eight months and most of her runway teaching software to understand human behavior, when she'd set out to solve a syncing problem.

This isn't a story about calendars. The hard thing about hard things isn't that they're hard. It's that they don't look hard from where you're standing before you start. I've watched a dozen founders run the same play with a dozen different pain points. They feel a specific friction. They build a specific fix. They don't find the larger problem underneath it until they're too far in to turn back.

Ask a founder why the build stalled and you'll get a resourcing answer: not enough runway, not enough engineers. Ask again and you'll get a timing answer: the market wasn't ready, we moved too fast or too slow.

Both answers are honest. Neither is true.

The real problem is smaller than that, and harder to say out loud. They solved the size of problem they could see. Not the size of problem that existed.

Founders build from what they've personally felt. That's not a flaw. It's the only honest starting point anyone has. But personal pain has a radius. You feel your version of a problem with total clarity and everyone else's version not at all. So you build for the radius you can see, and you mistake the edge of your own experience for the edge of the problem.

For fourteen hundred years, the smartest astronomers alive couldn't see past their own version of this. Ptolemy built a model of the universe with the earth at the center, which matched what anyone could plainly observe: the sun crossed the sky, not the ground. The trouble was the planets. Watched over months, they didn't move in a simple arc. They slowed, reversed, and looped backward before correcting course.

So astronomers added a fix: a small circle riding on the planet's larger orbit, called an epicycle, that reproduced the backward loop. It worked. Then new observations didn't quite fit, so they added another epicycle to correct the first one. Then another. By the time Copernicus arrived, the standard model of the sky needed dozens of these corrections, stacked on top of each other. Each one was a defensible fix for a real, observed problem.

Nobody inside that tradition was wrong about their data. They were wrong about what they were looking at. Copernicus didn't out-calculate them. He stood somewhere else. From that vantage point, the entire stack of corrections collapsed into one simple fact: the earth wasn't the thing everything else moved around.

That's the useful version of AI for a founder. Not a builder. Not a task list. A vantage point outside your own orbit, one you can ask to look at your problem from a spot you can't stand in yourself, because you're inside it.

Houston has its own version of this story. In the mid-2000s, engineers widened the Katy Freeway to twenty-six lanes, the widest stretch of highway in the world, at a cost of nearly $2.8 billion. The problem was simple: too many cars, not enough road. Within a few years, the morning commute was 30 percent longer than before the widening. The evening commute was up 55 percent.

The engineers hadn't miscalculated. They'd correctly solved the problem in front of them: not enough lanes for the current traffic. What they missed was that more lanes don't hold more traffic. They generate it. Every driver who'd avoided that route, delayed that errand, or moved further out now had a reason not to. The fix didn't relieve the pressure. It rewired the whole system around a bigger version of the same jam.

That's what happened to the founder and her calendars. She solved the version of the problem she could see: sync two calendars. She didn't see the system underneath it: thousands of people, each with their own private logic for protecting their time, and no single integration that respects all of them. The complexity didn't get created by her fix. It got revealed by it.

So here's the use of AI most founders skip. Not: help me build this faster. Ask it what you're missing. Ask it what this problem looks like at the scale of a market, not the scale of your own week. Ask it who else has tried to solve this and what actually stopped them, because someone almost always has, and the reason they stopped is usually the real shape of the problem.

Don't ask it to validate what you've already decided to build. It's very good at that. That's exactly why you shouldn't use it that way. Ask it to interrogate the size of the problem before you spend two years finding out the hard way.

Most founders won't do this. Not because the tool isn't sitting open in another tab right now. They won't do it because a small problem is finish-able, and a real one might not be. It's easier to spend three years solving a calendar than three months finding out your actual problem is bigger, harder, and still yours to solve.

That's the vision problem. It was never that founders can't see far enough. It's that most of them already decided not to look.