A founder opens a laptop and shows you the thing they’ve poured a year into. It’s polished. It’s clever. Then comes the question that’s been keeping them awake: we built it, it’s good - so why isn’t anyone coming?
I’ve lost count of how many times I’ve heard some version of it. Fifteen-plus years of building products - for governments, corporates, and startups - and working alongside their founders hasn’t given me all the answers; I’m wary of anyone who claims it has. What it gave me is a set of lessons learned the hard way, and they’re worth passing on.
None of this is new, and I won’t pretend otherwise. That founder walked into the oldest trap there is - if you build it, they will come - and people have been documenting why it fails for two decades, from Steve Blank’s customer-development work to Eric Ries’ The Lean Startup. The fix is just as well-worn: “fall in love with the problem” was a catchphrase long before Uri Levine - who co-founded Waze and Moovit - made it the title of his handbook, Fall in Love with the Problem, Not the Solution.
So no, I’m not breaking news. The line is one you’ve met a hundred times, on a hundred slides, until it curdled into a cliché. But clichés get repeated because they’re true and ignored because they’re hard. Almost everyone nods along and still goes home in love with their solution. I did, for years. All I’m adding is my own perspective - and the scar tissue that earned it.
The Cleverest Thing in the Room
When I started out, I was in love with the solution.
I was a Java developer, and maybe it comes with the territory - the language is so vast and intricate that you start to believe complexity is the craft. I made simple things complicated and felt clever for it. Guilty.
Then I discovered Ruby on Rails, and there was no going back. It was elegant, it was simple, and it got out of my way so I could solve the actual problem instead of fighting my tools. Java, I realized, had been in love with the solution. Ruby was in love with the problem.
Years later I demoed the Play Framework - back when its first version felt like magic, quietly doing the tedious work so you could focus on what mattered - to a team at a large corporation buried in IBM WebSphere and the kind of obscure Java machinery where, if you know, you know. When I finished, someone said, and I am not making this up: “It’s too simple. What’s the point of being an engineer?”
There it was, said out loud: the belief that our worth lives in the complexity, not in the problem we solve. Building hard things is a real skill, and the pride in it is earned - but I had spent years building monuments to my own cleverness, quietly hoping the user would be impressed by the same things I was. They almost never were.
One of my first ventures taught me this the hard way. More than a decade ago I built the first version of IKOUĒ - a platform to improve the relationship between students and their local embassies. It was ambitious and over-engineered, and I was proud of all the wrong things about it. It did not survive six months. I had fallen in love with the build, not with the people it was supposed to serve.
If you’re a founder, you carry a more dangerous strain of the same disease. I was in love with my code; you’re in love with your product - the thing you quit a job for, pitched your family on, rebuilt at 2am. The devotion is bigger. So is the blind spot.
The Spark Was Never the Product
Every pitch deck opens with a problem slide. Every lean canvas reserves a box for it. We all know, in theory, to start there - and then we spend the rest of the deck, and the next two years, quietly in love with the solution. Identifying a problem is the easy, ritual part. Staying faithful to it is where we get lost along the way.
And here is what the slide can never capture: the spark in a customer’s eyes - the small involuntary smile when something just works for them - has almost nothing to do with how impressive the product is.
They can’t see your elegant architecture. They don’t care about your feature list or your funding round. What they feel is whether the thing in front of them understands their problem, or whether it’s asking them to bend around someone else’s idea of how their life should go.
You can ship something genuinely impressive and watch it land cold. The product was good. The market was indifferent. That gap - between “we built something good” and “people keep coming back” - is where most startups quietly die.
And not rarely. Across hundreds of startup post-mortems, CB Insights found poor product-market fit was the second most common cause of death, named in 43% of failures - behind only running out of cash, which is usually the same failure wearing a different face.
Fall in Love with the Problem
Levine isn’t writing from theory. Google bought Waze in 2013, and Moovit, by the time Intel acquired it in 2020, had more than 800 million users across 3,100 cities in 102 countries. He has earned the right to talk about solutions. His entire argument is that the solution is the part you should hold most loosely.
His logic is plain: “the startup journey is about value creation, and the simplest way to create value is to solve a problem.” The problem is the north star. The solution is just your current best guess at hitting it.
Notice the verb, though. He doesn’t say identify the problem - every template already tells you to do that. He says fall in love with it, which is a far higher and more inconvenient bar. Love means staying faithful when the problem demands you scrap the solution you adore, sit through a hundred conversations you’d rather skip, and judge yourself on whether people come back rather than on how clever the thing is. A slide costs you nothing. Love costs you your ego.
And the warning lands like it was written for my younger self: “falling in love with the solution means losing the practice of listening to your users, which is the only way to make progress.”
Fall in love with the solution and you’ll defend it. Fall in love with the problem and you’ll keep changing the solution until it finally fits a real person.
Go Talk to a Hundred People
Here is the lesson we resist most, because it pulls us away from the thing we love doing - building.
Before you build, Levine says, go and speak with a hundred people and understand their perception of the problem - “this is the most critical validation.” Not your perception. Theirs.
He even gives you a blunt filter: ask who has this problem? If the honest answer is “only me,” he says, the next stop isn’t the market - it’s therapy.
For most of us, that hundred-conversation instinct is unnatural. Talking to strangers is slow, ambiguous, and humbling. Building is fast, clean, and flattering - every commit feels like progress. So we skip the part that tells us whether the problem is real and rush to the part that shows what we can do. The book’s quiet accusation: we validate our solution instead of the problem, then wonder why no one shows up.
The Only Metric That Matters
Levine is ruthless about what counts as success, and it isn’t the demo.
There is one metric for product-market fit, he says: retention. “If you create value, they will come back.” People returning, unprompted, is the only honest proof you solved something. He points out that Google, WhatsApp, and Waze work essentially the same way today as the day they first clicked - once you’ve actually solved the problem, you stop rebuilding and start refining.
This is where most of us quietly lie to ourselves. A standing ovation at demo day is not retention. Press coverage is not retention. Investors nodding is not retention. A signup that never returns is not value. The only honest review is the customer who comes back tomorrow because you made their day lighter - and if they aren’t, no amount of polish or pitch will save you.
Built By One Of Them
The work I’m proudest of is the work where the user felt it had been built by one of them - someone who had sat in their chair, not someone who’d read a requirements doc about their chair.
That feeling isn’t produced by UI polish or a clever growth hack. It’s produced upstream, in exactly the unglamorous work Levine prescribes: listening, sitting with people, watching them struggle before you build anything.
It’s the strangest and best part of my work as a solutions architect. You parachute into a domain you know nothing about - a bank’s risk desk, a port authority, a ministry’s back office - and if you do it right, weeks later you can hold a real conversation about it with the C-level executive and the person on the ground and the developers and designers in between. Not because you faked expertise, but because you absorbed the problem from everyone who lives it.
That absorption is the founder’s real unfair advantage - worth more than any feature. Waze’s edge was never the routing algorithm. It was understanding that a driver’s true problem is the helpless feeling of being stuck while everyone around them seems to know a way out. They fell in love with the problem, and the product followed.
I finally learned this on my own terms, and this time the problem was personal. I’m Central African, part of the diaspora IKOUĒ exists to connect - I wasn’t studying this problem from the outside, I was living it. In 2024 I came back and rebuilt it from scratch. The first version had tried to be clever and broad; this one started with a single, concrete problem in a place I come from - the gap between Central African talent, its diaspora, and the institutions that could train, employ, or fund them, the Central African Republic first, before expanding. Nothing about the new version is more technically impressive than the one that died. That was never the point - and it has grown every year since, with government ministries, institutions, and entrepreneurs joining the project. Same name, opposite object of love, opposite outcome.
And because I stayed with the problem instead of the product, it kept pointing at the next one. Helping people find work surfaced a deeper gap - they had no simple way to move money - so IKOUĒ led to Louma, a payments and financial-inclusion tool for the region and its diaspora. Solving that exposed the next layer - a local economy too fragmented to transact in - which led to Guiwara, a super app connecting the country’s businesses, services, and people. Three ventures, one unbroken thread: each was a problem the last one made visible, not a solution I went looking to build.
Learn to Put It to Sleep
The hardest discipline in the book is the one founders feel most in the gut.
If something isn’t working, Levine says, “no matter how hard we worked or how complex it was to do, it’s time to put it to sleep.” The effort you poured in is not a reason to keep it. It’s the exact reason you can’t see clearly. He frames the whole journey as a string of failures and argues the faster you fail, the faster you succeed - “if you’re afraid to fail, in reality you have already failed, because you are not going to try.”
None of this means stop caring about the craft of building. That would be the wrong lesson.
Execution matters. Keep chasing hard problems. Keep shipping things you’re proud of. The depth you build is what later lets you make something simple - and simple, for the customer, is the hardest thing to give them.
The shift is only about what comes first. The problem first, the customer first, and then all your energy and skill aimed at their smile instead of your own reflection.
When the Build Costs Almost Nothing
Levine published his handbook in 2023, when building still cost real months and real money. Since then the ground has shifted under it - in a direction that makes his argument stronger, not weaker.
I wrote about that shift in The Industrialization of Software: AI tooling has made software dramatically faster and cheaper to produce, and the bottleneck has moved from can we build this? to should we build this? Look closely at that second question. It isn’t an engineering question. It’s a problem question.
When anyone can ship a polished product in a weekend, the solution stops being a moat. Well-built things are becoming abundant. What stays scarce is everything upstream of the build: knowing whose problem is real, how they perceive it, and whether what you made actually pulls them back.
There’s a trap inside the same shift, and I feel it myself. AI makes falling in love with the solution easier than it has ever been - the seduction I knew in my Java years, one more clever layer, one more impressive feature, now runs at machine speed. You can over-build in an afternoon what used to take a quarter.
But the discipline didn’t get automated. The hundred conversations, the retention test, the courage to put a thing to sleep - all of it is still manual, still uncomfortable, and worth more than ever, precisely because it’s the only part the tools don’t do for you.
Falling in love with the problem was good advice when building was expensive. Now that building costs almost nothing, it’s close to the whole game.
Where This Gets Harder Than It Sounds
I don’t want to sell this too cleanly.
Loving the problem is necessary, but it was never sufficient. There’s brutal survivorship bias in any founder’s book - Waze won, and we don’t get the memoirs of the thousand teams who fell in love with their problem just as hard and still failed. Timing, capital, distribution, and plain luck decide more than any of us likes to admit.
Empathy doesn’t scale the way software does, either. You can talk to a hundred people; you cannot sit with the next hundred thousand, and at some point you’re making decisions about customers you’ll never meet.
And problem-love can curdle into paralysis - endlessly re-examining the question, mistaking research for progress, never shipping. Levine’s correction is uncomfortable for perfectionists: he says the best time to launch is “when you’ll be embarrassed by the quality of it,” because real use teaches faster than more thinking ever will. The hundred conversations are there to find the problem, not to postpone the launch forever.
Closing
If you’re early in your journey - or further in, quietly wondering why a product you know is good still isn’t catching - I’d gently ask where your love is sitting. On the thing you built, or on the people you built it for?
And then go read the book. I’ve only walked its spine here - the chapters on hiring and firing, fundraising, scaling, and knowing when to exit carry the same bluntness, and they land better wrapped in Levine’s own stories. It’s called a handbook for a reason: it’s meant to be kept close, not summarized.
What customers remember is not how hard it was to make. It’s whether, using it, they felt understood.
So maybe the question isn’t what should I build next. Maybe it’s: whose problem do I love enough to keep changing my answer until it finally fits them?