fall in love with problems, not solutions

There is a specific kind of founder failure that doesn't look like failure for a long time. The product ships. The demo is impressive. The pitch lands. And then the market doesn't respond the way the model predicted, and instead of asking why, the founder adds features. Refines the onboarding. Improves the UI. Runs more outreach. Pivots the messaging. Runs another cohort.

The product gets better, and better. The problem stays unsolved from the perspective of the buyer. The customer doesn’t adopt.

This is what solution attachment looks like in practice. It's not laziness. It's the opposite. It's a founder working hard on the wrong thing, sustained by emotional investment in what they built rather than what the customer needs. You can’t sell a Ferrari to someone who needs a pickup truck.

The solution is seductive in ways the problem never is. Problems are messy, poorly defined, and belong to other people. Solutions are yours. You designed them. You can describe them, demonstrate them, be proud of them. They have logos and landing pages and repos. When someone asks what you do, you say the name of the product, not the name of the problem.

But the problem framing is the one that keeps you honest.

When you're attached to the problem, a feature that doesn't solve it is obviously wrong, no matter how clean the code is. When you're attached to the solution, every piece of evidence that the solution isn't working becomes an argument for more iteration rather than a signal to question the premise.

Solution attachment shows up in decisions that seem reasonable individually. You push back on customer feedback because the product "isn't finished yet." You build the feature roadmap based on internal logic rather than watching where users stall. You price based on what the product cost to build rather than what the problem costs the customer. You keep the original vision intact while making incremental adjustments that never get close enough to what the market is actually asking for.

The practical discipline of problem-love is harder than it sounds, because the problem doesn't belong to you. You have to earn your understanding of it, continuously, from the people who live with it. That means watching how customers actually use what you've built, not how you designed it to be used. It means starting pricing conversations with "how much is this problem costing you" rather than "here's what we charge." It means treating a customer who stopped using the product as the most important feedback in your pipeline.

It also means being willing to throw away work you're proud of.

That's the real test. If a significant piece of the product has to go because the problem demands a different solution, and you can do it without grief because the problem is what matters, you've built the right relationship with the work. If you find yourself arguing that the solution is right and the customer is reading it wrong, you've already lost the thread.

The reason this connects directly to speed is that building fast only makes sense as a moral position if it's the problem you're racing toward. The moral urgency is in getting the right thing to the people who need it. That urgency evaporates the moment the product becomes the goal rather than the vehicle.

Staying problem-attached also requires the same discipline described in asking why enough times. Features and processes accumulate. They each have a reasonable origin story. Periodically stripping them back to ask whether each one still serves the underlying problem is the maintenance required to keep the product honest. If the answer is "that's how we built it," you haven't hit bottom yet.

Build quickly. Ship often. Know what problem you're in a hurry to solve. The product is the vehicle. The problem is the destination. The gap between those two things is where solutions go to become monuments to founders who fell in love with the wrong thing.