Problem vs solution

Engineers are trained to solve problems. The career-limiting failure mode is solving the wrong ones with great skill. A polished feature for a mild inconvenience burns the same sprint as a rough fix for a hair-on-fire pain — and only one of those moves retention, revenue or reputation.

A solution is a thing you might build: a dashboard, an AI summarizer, a mobile app, a new API. A problem is a struggle in someone's life or workflow: "I cannot tell which invoices are overdue before the customer calls," "I spend Sunday night copying grades into three systems." Teams that start with solutions argue about implementation. Teams that start with problems argue about whether the pain is real.

Falling in love with the right thing

Falling in love with the solution looks like: defending the architecture when users shrug; adding features to "complete" a vision nobody asked for; interpreting polite interest as demand.

Falling in love with the problem looks like: celebrating when a cheaper workaround kills your idea (you learned fast); being willing to change the solution as long as the pain shrinks; measuring success by the user's struggle disappearing, not by your feature existing.

Paul Graham's advice on startup ideas rhymes with this: the best ideas often come from noticing your own acute problems, not from brainstorming "markets." Live with a painful workflow long enough and the problem is undeniable. See startup ideas for the company-building angle; here the same filter applies inside a product org deciding what to put on the roadmap.

Keep solutions out of the problem statement. "Users need a better dashboard" is a solution in disguise. "Finance leads cannot see which invoices will age past 30 days until the weekly export, so they miss collection calls" is a problem.

Jobs to be done later reframes what the problem is in the customer's language. User research is how you gather evidence without lying to yourself.

Walking through invoices

Bad: "Build AI invoice categorization."

Problem: For AP clerks at 50–200 person companies who code 200+ invoices/week, the problem is manual GL coding that takes ~45 seconds per invoice and errs ~5%, causing month-end rework. Today they use rules in the ERP plus Slack questions to accounting.

The AI categorizer is one hypothesis. A cheaper rules engine, or a better ERP field, might shrink the same pain. You do not know yet. That is the point.

Common mistakes

• Solution-first brainstorms labeled as "problem discovery."
• Trusting compliments ("I'd definitely buy that") over past behavior.
• Confusing company goals with user problems. "We need more upsell" is not a user problem; "admins cannot see seat usage so they fear buying more" might be.

Check yourself

"Users need a better dashboard." Problem or solution? Solution in disguise. Rewrite with who, the job, the obstacle and what it costs today.

A cheaper workaround kills your idea. Did you fail? No. You learned fast. That is falling in love with the problem.

Key takeaways

• Fall in love with the problem; treat solutions as disposable hypotheses.
• A problem statement has no UI. A hypothesis adds an intervention and kill criteria.
• "I'd use that if it existed" is almost worthless. Past behavior is evidence.

Further learning

How to Get Startup Ideas (Paul Graham)How to Get Startup Ideaspaulgraham.com

Next: scoring problems on intensity, frequency and willingness to pay.