We’re wired to find solutions. I know this because I keep catching myself doing it—even after seven years of building PartRunner and learning this lesson the hard way.

Here’s what happens when you jump straight to solving:

You spend a couple weeks, maybe months, building something

• You go back to users and wonder why it’s not working

• Then you learn why it’s not working and start tweaking. And tweaking. And tweaking some more

It creates this slow, recursive, strenuous process.

You might get results eventually. But it’s not the shortest path. Think of it like a circle instead of going in a line—you end up going around and around.

The data backs this up in a painful way. 42% of startups fail because there’s no market need for their product—they build solutions nobody wants. This is the single biggest reason for startup failure, bigger than running out of money or team issues.

The Moment You Realize You’re Building the Wrong Thing

A few weeks ago, my team was debating a solution to a problem. We’d finalized our approach. We were ready to build.

Then one voice said: “Hey wait… does this solve the problem they’re facing?”

That moment stopped us cold.

The truth hit: this doesn’t solve the core problem.

Here’s what we were dealing with:

In logistics, everyone has their own lingo when requesting vehicle needs:

• “I need a 7FT Vehicle”

• “I need a Large Van”

• “I need a 1.5 Ton truck”

Our solution? Create a unified lingo that would resonate with all needs.

But our proposed solution would have created more noise.

That’s when we had to step back and ask: what is the actual problem?

The real issue wasn’t about standardizing language. It was about giving users another option where they could specify what they’re looking for—length, capacity, category—instead of forcing everyone into one lingo.

The Most Expensive Circle You’ll Ever Go Around

The most expensive circles always start with a bad starting point. And because you’re so far off from the beginning, every iteration from there takes more and more time.

Being nimble and adaptive is easier at the beginning. But it takes a toll as you do more and more iterations.

A bad starting point is always a poor understanding of the problem.

Here’s a concrete example from PartRunner’s history:

Our customers were requesting Routes, but the technology we had was built for Deliveries. A Route is generally more complex than a Delivery—but we didn’t fully understand that distinction at first.

Initially, we tried to see how Delivery could match Route. We iterated. And iterated.

It wasn’t right.

When we spent more time clearly articulating the difference between Delivery and Route—and what information we actually had available—we realized Route was not an extension of Delivery.

We needed to build a completely new module.

Research shows that finding market fit takes 2 to 3 times longer than most founders anticipate. When you start with a bad understanding of the problem, every iteration compounds the cost. What looks like optimization in isolation becomes waste when you zoom out to see the whole system.

The Framework: Finding Signal in the Noise

You can’t expect users to tell you which feedback is noise and which is signal.

That’s on us to identify.

Everyone has challenges and problems. We need to find the repetitive problem—the core one—and dig deeper.

What does “dig deeper” actually look like?

We tackle problems from different perspectives and different segments. We do testing to understand if the problem truly exists or not.

It takes about 50 conversations with customers who aren’t friends to find out if a product concept will really sell. Most teams skip this step because it’s uncomfortable.

The result? Most first products won’t meet market needs. In the worst cases, the product will be way off base, requiring a complete rethink.

This process of stopping to understand—of forcing ourselves to articulate the problem clearly—involved:

• Lots of conversations with stakeholders and users

• One-on-one conversations

• Quick demos

• Feedback loops

We built our understanding of how users operate, where they communicate, and what they want through consistent, direct engagement.

Redefining What an Idea Actually Is

Here’s what we get wrong about innovation: We think an idea is a clever solution. A new feature. A technological breakthrough.

But a real idea isn’t coming up with a solution—it’s being able to find a problem.

The companies that scale quickly, that capture enterprise clients, that grow from zero to $10MM GMV—they’re not the ones with the fanciest technology or the most features. They’re the ones who truly understand the problem.

Jeff Bezos said it best: fall in love with the problem, not the solution. Because when you’re obsessed with understanding the problem—when you can see the nuances that others miss, when you can distinguish between symptoms and root causes, when you know exactly what’s costing your clients time and money—the solutions become obvious.

PartRunner’s competitive advantage is not just better AI or more sophisticated technology. It’s that we understood what enterprise clients and fleet operators actually needed: not fancy apps, but simple tools that provide good work and visibility.

That understanding—that ability to find and articulate the real problem—is the idea. Everything else is just execution.

---

So before you build your next feature, before you iterate on that solution one more time, before you invest months going around in circles—stop.

Ask yourself: Do I actually understand the problem I’m trying to solve?

Because if you don’t, no amount of clever solutions will get you there.