The Startup Paradox

You know how everybody in the startup world talks about "fall in love with the problem"? The phrase has become so universal it's hard to trace where it started. Intuit leaders used it as a catchphrase to keep teams focused on customer challenges rather than pet ideas. Ash Maurya made it a core mantra of Lean Startup practice. Uri Levine, the Waze co-founder, built a whole book around it in 2023.

“Love the Problem, Not the Solution.”
― Ash Maurya, Scaling Lean: Mastering the Key Metrics for Startup Growth

Try finding a startup accelerator that doesn't repeat some version of this advice. "Be passionate about the problem" is as close to consensus as the startup world gets.

On the surface, it makes perfect sense.

Startup founders tend to be passionate about the product they're building while failing to develop a deeper understanding of customer reality. The assumption is that conversations with customers—customer discovery—will help founders understand the pain points customers face and offer a solution that addresses the underlying problem, rather than having a solution in search of a problem.

Mentors and investors giving this advice want to ensure that founders have their hand on the pulse of the market. Start customer conversations early. Build empathy for the customer and customer context.

The underlying failure pattern is common—operating in a vacuum without feedback loops, moving toward perfection on a path that leads nowhere.

There's real truth behind this advice. Empathy for the customer. Understanding customer reality. Relationships built early. Avoiding premature overinvestment in a solution. Forcing the founder to make smaller bets. These are all great ideas.

I believed all of this when I started building Traction5.

Traction5 is a SaaS platform for team mentorship. As I was starting to work on it, I talked to the MIT VMS Outreach team about the challenges in managing team mentorship programs. I talked to other programs. I was running Innovate Charlotte VMS myself. People shared their pain points and what they wanted to see. That was my customer discovery.

Completing MIT VMS training — the customer discovery that led to Traction5

I was surprised to find that when the product was ready and solved those specific issues, only a few programs were willing to actually adopt it. For some, it was switching costs. For some, lack of trust in a new startup. For others, the inefficient solution was free to them organizationally.

There were reasons I didn't anticipate—reasons beyond the problem itself.

Here's what I didn't see at first: the tool I built adds transparency. You can see immediately how a program is being managed. If a program is poorly managed, it becomes visible. Not everyone wants that visibility. The manual process, with all its inefficiency, was also protecting some programs from accountability.

The "problem" of manual scheduling wasn't universally experienced as a problem. For some, it was a feature.

This is what happens when you zoom in on the problem. The founder becomes dependent on customer input. The power shifts to the customer, who supposedly knows their pain points and is willing to share them fully. The founder's energy goes into reconciling competing and contradictory customer inputs. There's confusion. A loss of center of gravity.

When you operate from a problem mindset, you're always reacting. Reacting to customer problems. A new problem emerges, a situation changes, the problem shifts—you have to react again.

Here's the structural trap: the best case in this orientation is that there are no problems. But then there's nothing to react to. You're irrelevant.

The underlying system, the underlying reality, is unchanged. Nothing transformed. The problems just went away. An ideal world where you have no purpose.

Other challenges emerge when the problem changes, as often happens. Do you start from step one or pivot? All your work becomes dependent on this problem not changing. The same is true if the problem gets partially solved or shrinks. External reality controls the founder's fate.

And there's something even more fundamental.

Can we really be passionate about abstract concepts?

Usually we're passionate about our life's work or about helping other people—not about their problems. "Fall in love with the problem" asks us to do something unnatural, as if falling in love is something you can decide to do.

We are humans. We are builders. The best founders don't build companies to solve customer problems — they build because something should exist that doesn't exist yet. The customer benefit is real, but it's secondary to the generative impulse.

This is where true passion lives. This is self-actualization. We have skills, experiences, learning. The more we develop capability, the more we need to apply it—to make something, to leave a mark, to see our potential become actual.

Founders don't build companies to solve customer problems. They build because something in them needs to be expressed and actualized. The customer benefit is real, but it's secondary to the generative impulse.

So what's the alternative?

Not "be passionate about the problem." Be passionate about what you want to create. Have a vision. Have empathy for those whom this vision serves.

And here's a better frame than "problem": think about opportunity.

Problem-framing doesn't account for opportunity. What's the opportunity you see in this particular market, for these particular customers? Why does this opportunity exist? How is it being pursued by competitors? How should you pursue it?

Problems are narrow and static. Opportunities are contextual and dynamic. The same customer situation can be framed as "they have problem X" or "there's an opportunity to create Y." The framing changes how we see reality.

Being aware of customer problems is part of understanding underlying reality. But the vision is creating a world that makes these problems irrelevant—and more. It's not the current system with the problems removed. It's a new, better reality.

You're not solving their problem. You're creating a reality they want to be part of.

This extends beyond startups.

"Be passionate about the problem" is a startup-specific version of something more general. We live in a problem-focused society. School teaches us to solve problems. We are expected to react and respond to external stimuli in our personal and work lives. Finding a job so we don't starve. Consumer culture to keep up or to enjoy life. Everything designed to increase comfort by removing problems. We are taught that this is the path to happiness. I wrote about how it works in technical teams here: What Does Your Team Create?

Yet problems never end. And people feel empty, because relationships stop working as every situation becomes a problem to solve. The goal of a life without problems leads to a loss of meaning, burnout, and depression.

None of this means problem-solving is useless, and it does have its place. A surgeon removes a tumor to help someone survive. That's necessary. But the goal isn't surgery; it's health. The larger vision might be preventing the condition that required a surgery in the first place.

With Traction5, this meant moving from "how do we reduce administrative workload for program directors?" to "how do we enable team mentorship at scale?" The first question solves a problem. The second creates something — a way to activate the social capital already present in communities and institutions. This shift in orientation led to launching a Dean's Innovation Ecosystem at Barton College and a Team Mentorship Pilot at Northeastern University.

The problem with being passionate about the problem is that it points you in the wrong direction, away from your source of creative energy; away from opportunity; toward reaction instead of creation.

The startup paradox: advice meant to connect founders to customers actually disconnects them from themselves.

If this resonates, I'm working on something to help teams move from problem-solving to building. Stay tuned.