The thing nobody tells you about problem-first thinking
I spent three years building features for a SaaS product that my users were actively uninstalling because the core workflow was broken. We had metrics showing 84% of new accounts never completed the onboarding flow. Instead of asking why people were dropping off, my team and I spent two sprints building a "gamified progress tracker" to make onboarding feel more rewarding. It increased completion rates by 1.3 percent. We had solved a symptom instead of the disease. The real problem turned out to be that our signup form required an email verification before users could see anything inside the product. That single step was creating friction nobody had talked about because everyone assumed verification was table stakes. Once we moved verification to after the first meaningful action, completion rates jumped to 67 percent. No gamification needed. This is what people mean when they say Fall In Love With The Problem Not The Solution, though the phrase itself has been stripped of almost all of its original meaning through constant repetition.
Fall In Love With The Problem Not The Solution
Here is how the practice actually works in a way that is not covered in the blog posts. You sit with the problem long enough that you can describe it to someone who has never heard of your product and they immediately understand the frustration. Most teams skip this step because it feels unproductive. It is not unproductive. It is the entire point. I have a framework I use that takes about twenty minutes and completely changes how I approach a product decision. First, I write down the problem in one sentence without mentioning any solution language. If I catch myself using words like "click," "button," "dashboard," or "feature," I rewrite it. Then I ask three times why that is a problem, each time going deeper into the user's actual pain rather than my assumptions about it. After that, I find five people who have experienced the problem and ask them to describe their worst moment, not their ideal solution. Their answers will almost never match what your team pitched last quarter. The uncomfortable part is that sometimes the problem is so deeply embedded in your business model that the right answer is to stop building entirely. I learned this the hard way with a reporting module my engineering team had optimized over six months. We reduced load times from eleven seconds to two point four seconds. User engagement with that report stayed flat at three percent of the cohort. The problem was not performance. The problem was that nobody needed that report. Nobody asked for it. Nobody would miss it if we killed it. We decommissioned it and redirected those engineers to a segmentation feature that shipped in three weeks and moved the revenue needle.
Where this approach breaks down
Problem-first thinking does not work when the problem is obvious and already well understood by everyone. If you are building a payment integration or a database connector, spending three weeks "falling in love with the problem" is a waste of resources. In these cases, good execution of the solution matters far more than problem discovery. The framework works best when you are dealing with ambiguous user behavior, low engagement metrics that lack clear causes, or new market exploration where assumptions are cheap and likely wrong. There is also a timing constraint. This approach adds roughly two to four weeks to the front end of a project cycle. For startups burning through runway or teams with hard quarterly commitments, that is not always feasible. In those situations, you compress the process. Instead of five user interviews, do three. Instead of two weeks of observation, do one. You still get most of the value, just not all of it. A week of real problem immersion beats a month of solution refinement on a misdiagnosed problem, but a day of it beats nothing. The biggest trap I see teams fall into is confusing problem empathy with problem paralysis. You can study a problem for months and still never ship anything. The threshold is simple: once you can articulate the problem clearly enough that you could write the product requirements document without seeing the user, you are ready to move to solution mode. Any more time spent purely observing is procrastination dressed up as diligence. Most people in my experience cross that threshold much sooner than they expect, then slow down and over-research because they are afraid of building the wrong thing. Ironically, they end up building nothing while the problem still exists.
Get the Full Details
I keep a note in my calendar every ninety days where I review active projects and ask a single question: if I had to restart this from zero today based purely on what I know now, would I still be building this. The answer comes back no more often than I would like it to. That is usually the most useful signal I get.
