Finding a Problem Worth Solving with AI

The problem of finding a problem is really a problem of knowing where to look and what signals to trust. Most developer-founders searching for startup ideas aren’t actually stuck because no good problems exist — they’re stuck because they’re scanning the wrong surfaces and filtering on the wrong signals. Fix the search method and the problems appear. This article is that method.

Why Most Developer-Founders Look in the Wrong Places

The default mode for a technical founder looking for startup ideas is to think about what they personally want to exist. This is called “scratching your own itch,” and it gets romanticized constantly because a handful of famous products were built this way. The problem is the survivorship bias is enormous. For every Dropbox (Drew Houston wanted a file sync tool), there are a thousand products built by developers for developers that had audiences in the dozens and revenue in the low thousands before quietly shutting down.

The subtler failure mode is this: developers are a small, weird, highly technical slice of the economy. Their problems are interesting but usually already served — there are 50 tools for every developer workflow that matters. Meanwhile, the rest of the economy is full of people doing things manually, expensively, and slowly, and nobody’s building for them because they’re harder to reach through a Hacker News launch.

When you build for yourself, you also skip the hardest part of startup building — genuinely understanding whether someone else will pay for this. You become both the creator and the customer, which sounds efficient but is actually a liability. You’re terrible at evaluating your own product’s value because you can’t separate the effort you put into making it from the value it actually delivers.

The second wrong place: AI demo galleries, trend reports, and “AI will disrupt X” articles. These are descriptions of what’s theoretically possible, not what’s actually painful enough to buy. Someone saying “AI could transform healthcare” tells you nothing about whether a specific person in a specific role will pay $400/month for a specific tool that solves a specific problem they deal with every Tuesday.

Look at where work is actually happening. Not where technologists imagine it happening.

The Shadow Workflow Method

A shadow workflow is something people are doing today that shouldn’t exist — it only exists because no software has been built to replace it properly yet. These are the Excel spreadsheets being used as databases. The Slack threads that have become project management systems. The email chains tracking approvals that should take two clicks. The Google Docs templates people fill out manually because no one has automated that particular form yet.

AI doesn’t just automate these workflows — it makes it viable to automate them for the first time. Many shadow workflows exist because the task requires enough judgment, pattern matching, or language understanding that rule-based automation never worked. AI changes that.

How to find shadow workflows: talk to people in jobs you don’t fully understand and ask them to walk you through a specific painful week. Not “what problems do you have” — that question gets you vague answers about communication and time management. Ask: “Walk me through last Tuesday. What did you spend time on that you wish someone else would just handle?” Then ask: “How do you actually do that right now?” The answer to that second question is almost always a shadow workflow.

The patterns you’re listening for: “I pull this into a spreadsheet and then manually…” or “We have someone junior do this because it’s tedious…” or “I basically have to read through all of these and decide…” or “I do this every week and it takes half a day.”

These are your opportunities. The manual part is the signal. The repetition is the proof there’s a market.

Problem Sources That Actually Work

Not all problem categories produce equally good opportunities. Some produce real businesses. Others produce demo purgatory.

Existing software with terrible UX in high-value workflows. Every industry has software that costs $50,000 a year per seat and was designed in 2004. Legal research tools. Medical billing systems. Compliance software. These products have captive customers who hate them but can’t leave because switching costs are enormous and the data lives inside. AI gives you an angle to build a better interface, a smarter workflow layer, or an entirely new product that doesn’t need to be a full replacement on day one. You don’t have to kill Salesforce. You just have to be better at one specific thing Salesforce does badly — and sell to people who already pay Salesforce and are already annoyed.

Regulated industries where expertise is bottlenecked. Healthcare, law, finance, insurance, construction, real estate. In all of these, you have complex professional judgments being made repeatedly by expensive, overworked people. The cost of those judgments is high. The volume is enormous. AI can either assist the human (so they can handle more cases faster) or, in limited contexts, begin to replace specific narrow decision types entirely. The regulation that makes these markets “hard” is actually a moat — it filters out competitors who don’t understand the domain. Learn the domain. That knowledge becomes your edge.

High-volume repetitive professional tasks. Contract review. Invoice processing. Insurance claims triage. Customer support escalation. Job candidate screening. Meeting summarization with action items. These tasks share a profile: they’re done by humans because they require reading and judgment, they happen at high volume, they’re not particularly enjoyable, and organizations would instantly pay to reduce the time spent on them. For each of these, the question is just: can you get accuracy high enough, and can you reach buyers?

Markets where AI changes the cost structure dramatically. Some products that were previously impossible to build economically now make sense. Translation for niche language pairs. Personalization at scale for small businesses. Custom content generation for long-tail use cases. When the cost of the thing drops by 90%, entire categories that weren’t viable become viable. Find the things that were previously cost-prohibitive and ask whether AI makes the unit economics work now.

How to Evaluate a Problem: The 5-Question Framework

Once you have a candidate problem, run it through this filter before building anything.

1. Is it painful enough? Not “is this annoying” but “would someone spend money to make this go away today?” There’s a large gap between “this is a nuisance” and “this costs us real money or time and we’ve tried to fix it and failed.” You want the latter. The test: when you describe the problem to someone who has it, do they lean in and ask when they can get access? Or do they say “yeah that would be nice”? The second response is not a customer. The first one might be.

2. Is the incumbent solution awful? This isn’t just about software being ugly. It’s about whether the current solution has real gaps that create real costs. People tolerate terrible software for years if switching is painful. You need to find the cases where the existing solution is not only bad but provably, measurably bad in a way that someone will pay to escape. Bonus points if the incumbent is expensive and the user has no contractual loyalty to it.

3. Can AI do it 10x better? Not 20% better. Not “slightly more convenient.” AI investments are expensive to build and operate. To justify the cost, and to actually hold customers, you need a step-function improvement in quality, speed, or cost. If the best you can say is “our AI does it about as well as a human but a bit faster,” that’s not 10x. “Our AI does it in 30 seconds and it used to take a human 4 hours” is 10x. Find problems where the gap is large.

4. Can you reach customers? A great problem in a segment you can’t access is not an opportunity for you — it’s an opportunity for someone with that access. How do people in this role discover new tools? Where do they congregate? Do they have budget authority? If the sales cycle requires convincing three layers of procurement and a 6-month IT security review, that’s survivable if you have the capital and patience. If you don’t, find a problem where you can sell to someone who can say yes in a conversation.

5. Is the market real? This is not “is the TAM big.” Anyone can construct a large TAM. The question is: are there identifiable, reachable buyers who are spending money on this problem category right now? If there are no competitors at all, that’s sometimes a bad sign — it may mean the problem isn’t real, or previous attempts already failed. The presence of ugly, overpriced, or mediocre competitors in a space is bullish. It means people are already paying for imperfect solutions.

The Timing Question

Some AI problems are ready to be solved right now. Others are six months early, two years early, or five years too early. Getting the timing wrong is as bad as getting the idea wrong.

Problems that are ready now tend to share a few characteristics: the AI capability to address them already exists and is reliably good enough, the workflow is already digital (not analog), and the buyers have already started forming mental models of AI tools (so you don’t have to sell them on the concept first, just on your product).

Problems that aren’t ready yet usually fail for one of these reasons: the underlying model capability isn’t quite there (hallucination rates are too high for the use case, context windows are too small, latency is too slow), the workflow lives in systems that aren’t AI-accessible yet, or the buyers are too early in their AI awareness to have budget for point solutions.

A useful diagnostic: find three people with the problem and ask them whether they’ve tried using any AI tools for this already. If they say yes and the tools mostly failed, dig into why. That’s often revealing about whether the problem is a matter of model capability (not ready) or product execution (ready, just needs building right). If they say no and have never thought about it, you may have a category creation problem — which requires a different kind of company to build.

Validating Without Building

The most expensive mistake in early-stage building is to spend three months building a product and then discover that people won’t pay for it at the price you need to charge.

You can avoid this entirely by validating the problem before writing a line of product code. The method is embarrassingly simple: describe the product to potential buyers in enough detail that they could evaluate it, and ask them to commit something — ideally money, but at minimum time and detail.

Concretely: write a two-paragraph description of what the product does. Send it to 10 people who have the problem. Ask for a 20-minute call. In that call, describe what it does and ask: “If this existed today and cost $X/month, would you buy it?” Then ask: “Would you be willing to be on our early access list and prepay for three months at a discount?” You don’t need 10 yeses. You need three or four genuine commitments with enough specificity in the conversation that you believe them.

If you can’t describe the product in two paragraphs, you haven’t thought about it enough yet. If you can’t name 10 people who have the problem, your distribution strategy is already broken. If no one will give you a prepayment, slow down — that’s important signal.

A landing page with a waitlist signup is a weak validation. Many people will give you their email out of mild curiosity. What you want is something that costs them something — money, calendar time, or a detailed conversation — because cost filters for genuine intent.

Red Flags: Problems That Seem Good But Aren’t

Too broad. “AI for sales teams” is not a problem. “AI that generates first drafts of outbound sequences based on a rep’s notes from an inbound call” is a problem. Broadness feels like optionality but it’s actually just vagueness. You can’t build for “sales teams.” You have to build for a specific person doing a specific thing. If your problem statement doesn’t include a verb, it’s probably too broad.

Too commoditized. Some problems have been attacked by 50 well-funded companies. AI meeting summaries. AI writing assistants. AI customer support chatbots. In these categories, the incumbents have distribution, brand, and integrations you don’t have. Unless you have a genuine structural edge — a proprietary dataset, a specific buyer segment with unique requirements, a distribution channel no one else has — you’re fighting uphill for no reason. The market being large doesn’t help you if you can’t carve out a defensible slice.

Model-dependent moat. If your competitive advantage is that you prompt GPT-5.5 better than competitors, you don’t have a competitive advantage. Model capabilities evolve fast and prompting techniques spread instantly. Your moat has to be something that doesn’t evaporate when the model gets better or a competitor reads your documentation. Proprietary training data, customer data lock-in, deep workflow integration, network effects — these persist. “Our prompts are clever” does not.

The user isn’t the buyer. In B2B, the person who experiences the pain is often not the person who approves the budget. If you build something that helps individual contributors save two hours a week, you still have to sell it to someone who controls budget — often a manager who doesn’t experience the pain directly and cares more about compliance risk, integration with existing systems, and not being fired for a bad vendor decision. This isn’t a dealbreaker, but it means your sales motion is more complex than you think. Know exactly who you’re selling to and why they’ll say yes.

Where to Find Problems: Specific Places

Stop waiting for inspiration. Go to where complaints live.

Reddit subreddits for specific professions. r/legaladvice, r/medicine, r/financialplanning, r/realestate, r/smallbusiness. Not to mine for product ideas directly — people rarely describe their problems in product terms. But to understand what’s painful, what’s confusing, what people ask the same questions about repeatedly. Recurring questions are a signal. “How do I X” asked 40 times a week means X is hard and the existing solutions are inadequate.

Job listings for roles you’d want to automate. Search for job postings for “data entry specialist,” “document reviewer,” “contract analyst,” “insurance adjuster,” “claims processor.” Read what the job requires in detail. Every bullet point describing manual, repetitive, judgment-requiring tasks is a description of a workflow that AI might address. Job listings also tell you the salary — which gives you a rough ceiling on what automation is worth. A $70K/year role that AI can partially automate justifies significant spend.

Support ticket archives for existing software. If you can access support forums or community boards for incumbent tools in a category, you’ll find the most authentic version of what users hate. Zendesk communities, Salesforce Trailblazer forums, SAP user groups — these are full of people describing specific frustrations with current tools. The highest-frequency complaints with the most emotional intensity are your roadmap.

LinkedIn job changes. When someone hires five people into the same role rapidly, that’s a scaling problem. When companies keep having turnover in a specific function, that’s often a pain signal. A company that has had four “compliance managers” in three years either has a bad culture or a terrible compliance workflow. Both are exploitable.

Niche professional communities. Slack groups, Discord servers, and forums for specific professional roles — paralegals, construction project managers, independent insurance agents, healthcare coders. These communities are full of questions about workflows, tool recommendations, and frustrations. Spend a week lurking before you say anything. You’ll find a year’s worth of product ideas.

The search for a problem worth solving with AI is not a creative exercise. It’s a research exercise. You’re looking for evidence of pain — paid, repeated, documented pain — in segments where AI capability creates a step-function improvement and existing solutions are inadequate. That evidence exists in many places. Most founders just don’t look in the right ones.

Stop ideating. Start observing.