Fall in Love with the Problem

The daily brief email came out looking like crap.

I’m not exaggerating. The formatting was off in a way that wasn’t a tweak — it was the kind of broken that means something earlier in the pipeline is producing the wrong shape of data. I have to go back, find the seam, and fix it. Could be an hour. Could be three sessions across a weekend. Either way, what isn’t happening is the deliverable I promised.

So instead of pretending the demo works, here’s the piece I’m writing instead: the one about what to do when it doesn’t.

The principle has a name

Uri Levine, who cofounded Waze and Moovit, wrote a book called Fall in Love with the Problem, Not the Solution. The title is the thesis. Levine’s argument, distilled, is that entrepreneurs who fall in love with their solution are emotionally hostage to that solution — they can’t pivot when the data tells them to, they can’t ship the v2 that contradicts the v1, they can’t see the customer in front of them because they’re looking past her at the thing they built.

Entrepreneurs who fall in love with the problem don’t have that drag. The solution is just a draft. If it doesn’t fit the problem, you change the solution. The problem is the anchor.

Some of you run companies. Some lead teams. Some consult. Some build personal workflows for an audience of one. What we share isn't a job title — it's the experience of pushing something toward production and watching it fail in non-obvious ways. The scale of the work changes the stakes. It doesn't change the trap.

When your daily brief breaks on a Wednesday morning, the question is: are you in love with the daily brief you built, or are you in love with the problem of starting your day without losing the first hour to context-switching?

If it’s the first, you’re stuck. Every breakage is a verdict on your judgment. You’ll either grind on the wrong solution because you’re emotionally invested, or you’ll bail on the project entirely because you can’t separate the broken implementation from the underlying need.

If it’s the second, every breakage is a clue. The solution is just a draft. The next one is on its way.

What loving the solution costs you

The piece I was going to publish was real work. The system mostly works. I have tests from days when the brief landed clean and useful. There’s a version of this week where I push through, ship something that’s 70% there, and add a footnote saying “still iterating on the formatting.” That’s the version where I’m in love with the solution.

The cost of that version isn’t the slightly-broken email. It’s that I’d spend the next two weeks defending the choice instead of fixing the problem. People would reply with the formatting issue, and I’d have to either argue it’s not a big deal or admit I shipped before it was ready. Either way I’m not working on the actual issue — I’m working on the optics of having already committed.

Falling out of love with the solution is the move that lets me keep working on the problem. The piece can wait. The problem — I want a daily brief that actually arrives in a usable shape — is still there, exactly as it was, ready for the next attempt.

If you’ve ever sunk weeks into a Notion build, a custom CRM, a Zapier chain, an agent setup, and watched it work in demo and break in production, you know this shape. The temptation to grind on the broken solution is strongest right at the moment the data is telling you to pivot.

Iteration only counts if you’re tracking what changed

Here’s the part that makes “fall in love with the problem” workable instead of just inspirational: you need a way of dialoguing with yourself across time.

I track everything I’m working on through git. That’s a developer’s tool, but the practice it enables isn’t a developer’s practice — it’s a thinker’s practice. Every change gets a record. I can roll back, compare versions, see what worked last Tuesday that I broke on Thursday, and follow the through-line.

The medium matters less than the practice. A dated notebook entry with “tried X, didn’t work, here’s why” — that’s the practice. A sketchbook page with a small drawing of the failed prototype and three lines about what you’d change next time — that’s the practice. A Notion log with three fields (what I tried, what happened, what I’d change) — same thing. The technical sophistication is incidental. The discipline of looking at what you tried yesterday before deciding what to try today is what matters.

Without that, you don’t iterate. You just repeat. You feel like you’re working on the problem because you’re putting time in, but each session is starting from scratch because your past attempts are gone or unsearchable. That’s the quiet way most personal projects die — not from a dramatic failure but from a slow drift back to zero.

Falling in love with the problem requires receipts. The receipts are what let you trust the next attempt instead of doubting whether you’ve actually made progress.

The despair phase is where the work happens

If you’ve followed Forge for a while, you’ve seen me write about the despair cycle: Excitement → Despair → Hope → Joy → Repeat. I learned the shape of it carving spoons — initial enthusiasm, brutal frustration when the wood splits or the curve goes wrong, the first piece that actually works, the eventual joy of doing it well. Then a new project starts the cycle over.

The despair phase is where the growth happens. You don’t learn anything in the excitement phase — you’re high on possibility. You don’t learn much in the joy phase either — you’re collecting the dividends. The despair phase is where you find out what you didn’t know, and where you decide whether you’re going to learn it or quit.

Falling in love with the problem is the orientation that lets you stay in the despair phase long enough for it to do its work. If you’re in love with the solution, despair is unbearable — every minute in it is a referendum on your competence. If you’re in love with the problem, despair is just data collection. Uncomfortable, sure. But not personal.

Angela Duckworth’s grit research — the peer-reviewed kind — found that long-term goal persistence predicted success across West Point cadets, spelling bee competitors, and Ivy League GPAs, independent of IQ. The effect was small but real (around 4% of the variance in outcomes), and the trait Duckworth and her colleagues measured was passion and perseverance for long-term goals. The passion part matters. Perseverance without an anchor is just stubbornness. The anchor — the thing you’re persevering toward — is the problem you fell in love with.

You’re directing a river, not building a wall

The mental model I keep coming back to is a river.

When you’re in love with the solution, you’re trying to build a wall — a fixed object, finished, immovable. Every leak is a defect. Every redesign is a setback. Every change in the environment is a threat.

When you’re in love with the problem, you’re directing a river. The water keeps moving regardless of what you do. Your job is to shape the channel — to nudge the flow toward the outcome you want. A washed-out bank isn’t a defeat; it’s a new piece of information about where the river wants to go.

This isn’t a license to drift. Directing a river takes more skill than building a wall, not less. You have to read what’s in front of you. You have to know which channels to deepen and which to fill in. You have to accept that the river will route around you sometimes, and that routing around isn’t the river breaking — it’s the river doing what rivers do.

The builders I respect most operate this way. They have strong opinions about the problem and loose grips on any particular solution. They ship things that don’t work yet. They talk about what failed. They version everything. They come back next week with a different cut at the same underlying issue, and the work compounds because the problem stayed in the center the whole time.

What I actually did about Open Brain Part Two

I’m not going to give you a date.

I made that mistake weeks ago — promised the drop, anchored to a calendar, painted myself into a corner where the only way to keep the commitment was to either ship something broken or write the piece you’re reading now.

What I did instead:

I went back into the daily brief pipeline and found the seam where the formatting broke. I committed each attempt to git so I could see what changed when something started working. I tested against real inputs. And yesterday it worked — the email arrived in a shape I actually wanted to read on any given morning. The piece and the scripts were ready to go together; only the writeup was left to polish.

The problem was the same problem it had been last week: I wanted a daily brief that landed in my inbox in a usable shape and actually saved me the first hour of context-switching. The first attempt didn’t solve it. The next attempt did. Every version was a draft. The drafts compounded until one of them held.

If you’re in the middle of one of these

If you’re three attempts into something that isn’t working — a workflow, a system, a piece of writing, a side project — the question worth sitting with isn’t “should I keep going?” It’s “what am I in love with?”

If the answer is the solution, you’re in trouble. Every minute you spend defending the solution is a minute you’re not spending on the problem.

If the answer is the problem, you’re fine. The current solution is a draft. You learned something from it not working. Write down what you learned. Commit the version. Make a different decision tomorrow.

If you’re in a team, the question gets harder — multiple people have to fall in love with the same problem, and you have to agree on which solution you’re letting go of — but the principle holds. The problem is the anchor; the solution is always negotiable.

The thing that makes this practice sustainable isn’t willpower. It’s setup. It’s having somewhere to track what changed, so the next attempt is informed instead of random. It’s having a few examples of past despair phases you got through, so the current one feels like a phase instead of a permanent condition. It’s having permission — from yourself, from your readers, from the people you work with — to publish the pivot when the original plan breaks.

You’re directing a river. The river is going to keep moving. Your job is to keep paying attention to it, keep nudging the channel, and keep loving the problem long enough to find the solution that finally fits.