Don’t solve problems that don’t exist.
We procrastinate.
Not because we’re lazy or undisciplined, but because the next step is unclear, and our brains avoid discomfort.
When that happens, we don’t just stall. We drift. We default to whatever is easiest to do or feel. Doomscrolling. Outrage. Obsessing over others’ milestones, followers, & salaries. Motion that looks like progress, but isn’t.
While we’re going through the motions day in and day out, only a few choices truly matter: your partner, your physical and mental health, and your closest relationships. Everything else is mostly noise, even when it feels urgent.
Products work similarly. We have some latitude in what to build and how to spend our time and energy. However, only a few levers, projects, or tasks truly matter when it comes to creating value for customers and driving business outcomes. That freedom is a gift and a trap: we can choose real problems or manufacture fake ones to solve.
As I embark on building Lazyweb as a solo human collaborating with AIs, with little guardrail or expectation on how to spend my time, I had to check myself more often than I would like that I am not solving problems that don’t exist.
Work is malleable:
“Work expands to fill the time available for its completion.” - Northcote Parkinson
Parkinson’s Law is true.
I had enough work to fill 8 hours a day, 5 days a week, 50 weeks a year, sometimes more, never less, except for the one day in my career, when I had nothing to do due to a company-wide strategic shift.
What I found fascinating in my first month building Lazyweb was that the temptation to create problems to solve that should not exist never goes away. It doesn’t matter if I have 100 other things to do, 17 fires to put out, and enough of a backlog to dry out my bank accounts on Cursor, Claude, and Codex credits.
Until recently, I thought a lack of problems to solve was the main driver for us to create new unimportant problems to go after. Now I realize this is a naive interpretation of Parkinson’s law.
Here I am creating a product from scratch, with important & well-defined problems to solve. Yet every now and then, I can’t help but wonder and take a detour attempting to solve unimportant problems. My most recent being a detour into SOC2 compliance.
Who needs compliance when you have 0 users? What is there to comply with, exactly?
Some work is necessary, some is important, some is neither
I think now is as good time as ever to distinguish between necessary but unimportant work and work that shouldn’t be done in the first place.
Not everything we do needs to be important, sometimes it is just necessary.
For instance, for an app, authentication is necessary but not important: it enables sign-up, but creating an account doesn’t deliver unique value.
On the flip side, a problem that shouldn’t exist is something that isn’t needed at all, at least now. Like setting up A/B testing and feature flags when we have 17 users.
Big company
Why do people create problems that don’t exist in big companies? I don’t know all the reasons but I know there are at least two that exist in most big companies:
1) Incentive structures
Companies have promotion ladders and comp frameworks.
Sometimes, people create problems to solve to align their work perfectly with those boxes: they inflate scope of the team to hoard “more resources” in the org, spin up cross-team initiatives that go nowhere, or pitch a low-value “platform migration” to appear strategic, none of which serve users.
We’re selfish and sometimes we push our self interest at the expense of our peers, teams, and company. This sucks and is usually obvious, but is valuable to at least one person, the person creating the problems to solve.
2) Working on a problem we can’t solve
When the important thing to solve is upstream or external, it’s safer to chase tractable but not valuable work.
If we are working on the UI on the paid marketing team but the acquisition channel is broken because of poor targeting, there isn’t much we can do to fix the important problem of a lackluster performing channel.
In that case we might be tempted to solve unnecessary manufactured problems instead that we are capable of solving like investing in a new design guideline for improving the cohesion of our marketing landing pages; it is a less discomforting use of one’s time.
Unfortunately, this is value-less work.
Early-stage startup (or solopreneur as is my case):
Solving problems that don’t exist looks different if we’re working on an early pre-PMF or even pre-launch project like Lazyweb.
We lack a clear sense of what matters; at best we haven’t pinpointed where value comes from, and at worst we’re creating none.
1) High effort, high uncertainty work
Research in psychology and behavioral economics shows people prefer known mediocre outcomes over unknown risky ones (ambiguity aversion), and will go surprisingly far to avoid uncertainty (Ellsberg, 1961; overview).
I’m not doing psych research daily anymore, but my master’s was at the HCI x information systems border, with plenty of psychology. I’m familiar with this pattern in theory and in practice. When I feel lethargic, unmotivated, or just meh, it’s usually not random. It’s my brain trying to exit a high-effort, high-uncertainty moment.
Building Lazyweb made this impossible to ignore. When I hit a real uphill battle like needing to get my first MCP server up and running, debugging a crashing backend, or watching agents spin for an hour with no obvious unblock, my backlog would suddenly “explode” with urgent-sounding tasks that conveniently avoid the actual work I am stuck on.
Here are a few items from the backlog:
Figure out pricing.
Database redundancy
SOC2 compliance
Team plans
Create the premium color brand aesthetic.
Finish Emil’s animation course.
Clawdbot, should I give it a try?
Make error states fun.
Break out my backend into smaller services.
What do they all have in common?
None of these move me closer to validating the core hypothesis of my product
They show up precisely when uncertainty spikes and I’m likely to avoid the scary, messy problem right in front of me.
2) Delusion
On the other end, the gravitational pull to create non-existent problems is strongest when things are going well...in our heads.
Delusional problem solving takes the form “If X crushes, and Y crushes, then we will have Z problem. We should solve for Z now”
“If our launch video goes viral, and everyone signs up to our service, and we have a lot of users, scammers will try to hack our system and our infrastructure is not as secure as it should be. We should invest in hardening our infrastructure today.”
We are playing three steps ahead of the game, but not in a good way.
I call these delusional because they turn hypothetical success into a present tense constraint. They seduce us into premature optimization and pull focus from the only thing that matters right now: creating something valuable and getting people to recognize its value.
None of this is new. One of YCs mantras is “Build product, talk to users,” Elon said “the most common mistake of a smart engineer is optimizing something that shouldn’t exist.”
These quotes resonate because they shed light on a human bias that we often recognize yet still fall for: resisting the temptation of spending our time solving problems that don’t matter.
When I notice myself drifting into solving problems that don’t matter, or worse, creating them, I make it a habit to treat that as a signal to take time off and reset.
A walk, cooking, journaling or a few hours of brain-rot content would just do. Sometimes I need a day or two, depending on the effort/uncertainty of the outcome of the task I am evading.
After the reset, I drop every other problem on my to do list to give myself a reasonably unlimited time to focus and break down the uncertainty of the 1 thing holding me back, one small sub-task at a time, until momentum is back on my side.
In fact, I’m taking a break right now very publicly journaling in this newsletter before doing all the work that needs to be done for the launch of Lazyweb next week.
Wish me luck,
Ali Abouelatta.