How to find a problem worth solving in public data

A problem worth solving is a problem someone is already spending time or money trying to fix. You do not find these in a shower epiphany. You find them in public text where frustrated users are actively begging for a solution. The internet is an open ledger of demand signals. You just need to know which databases to query and how to filter the noise.

Feature request boards are abandoned product blueprints

Software companies routinely publish their roadmaps on tools like UserVoice or Canny. They let users submit ideas and upvote their favorites. For a founder looking for a problem, this is a goldmine. You are looking for tickets that are at least two years old, have hundreds of votes, and have been explicitly ignored by the company. The incumbent company's strategic gap is your immediate wedge.

Go to the Webflow Wishlist or the Shopify community forums. Sort the feature requests by the highest number of votes. Filter out anything marked as planned or in progress. Look closely at the top ten ignored requests. These are features the company has decided are too niche, too complex, or outside their core vision.

You can calculate the exact value of these ignored requests. If a specific request for tiered pricing on a platform has 500 votes, and the base software costs $50 a month, those users are highly invested. If you build a third-party plugin that bridges this exact gap, you already have a target list of 500 qualified leads. You know exactly what they want because they wrote the product specification for you. A conservative estimate assumes that for every user who logs in to vote, another hundred experience the problem but remain silent. That means a 500-vote ticket represents 50,000 potential users. If your plugin costs $10 a month, you are looking at a $500,000 monthly recurring revenue ceiling. The math is right there on the screen.

Extracting standalone products from one-star reviews

The App Store, the Shopify App Store, and the Salesforce AppExchange are massive repositories of demand signals. A one-star review is rarely just a user venting. It is a highly specific articulation of a failed expectation. The user downloaded a product expecting it to do one thing, and it failed. That gap is a standalone product waiting to be built.

Read the reviews for the top grossing apps in your target category. Ignore reviews about bugs, crashes, or poor customer service. You are looking strictly for feature deficits. When a reviewer writes that a tool forces them to use a specific payment gateway, or lacks a basic CSV export function, they are telling you exactly what a competing product needs to lead with.

You can size the market directly from these reviews. If a popular inventory management app has 2,000 reviews, it likely has around 100,000 active installs. If five percent of those reviews are one-star ratings specifically citing a missing wholesale portal feature, that is 5,000 highly motivated merchants. At $30 a month, that is a $150,000 monthly recurring revenue business sitting inside the negative reviews of a single competitor. The users have already identified the problem, defined the missing feature, and proven they are willing to install software to solve it.

Support threads reveal expensive workarounds

People do not post on technical support forums for fun. They post when they are blocked and desperate. The most valuable demand signals on the internet start with the exact phrase "is there a way to". You can find these on Stack Overflow, GitHub issues, and specialized Reddit communities like r/salesforce or r/excel.

When you find a user asking how to automate a repetitive task, look at the accepted answer. If the solution is a twelve-step manual workaround involving Zapier, a Google Sheet, and a custom Python script, you have found a problem worth solving. The user is currently paying for the solution with their time and technical overhead. Your software will let them pay with their money instead.

Focus on business environments where time is strictly tied to revenue. A sales operations manager asking how to route leads based on a complex custom object is not asking for a tutorial. They are asking to buy a routing engine. When you see a GitHub issue titled "Support for custom webhooks" that has been open since 2020, read the comments. Users will post their elaborate workarounds. They will describe setting up AWS Lambda functions to poll the API every five minutes. They are paying for compute power, spending engineering hours, and maintaining fragile scripts. If you package that exact workflow into a reliable, one-click integration, you will convert those users instantly. You are selling a cheaper, more reliable version of the duct tape they are already using.

The graveyard of brainstorming

Founders fail when they sit in a room and try to invent problems. Brainstorming produces solutions for idealized users who do not exist. This leads to the classic trap of building a vitamin instead of a painkiller. Vitamins are nice to have, but users cancel them during the first budget cut. Painkillers are mandatory.

Founders love brainstorming because it is safe. Writing code in a vacuum protects you from rejection. Searching for real demand signals forces you to confront reality before you build. It forces you to realize that your favorite idea has zero market demand. This is a painful realization, but it is much cheaper to experience it before you spend six months writing a web application.

Demand signals are the only reliable evidence of pain. If you cannot find a public record of someone actively seeking a solution, the problem does not exist in a commercially viable way. Do not trust your intuition. Trust the text. If a problem is truly worth solving, the people experiencing it will not suffer in silence. They will leave a trail of digital evidence.

Filtering for commercial viability

Not all demand signals justify a business. You must filter them through strict commercial criteria. First, the user must have a budget. A student posting about the price of a textbook is a demand signal with zero purchasing power. A logistics manager trying to integrate two legacy freight APIs has a corporate card and a mandate to spend it.

Second, the problem must occur frequently. A painful administrative task that happens once a year is not a subscription business. It is a minor annoyance. A task that breaks a workflow every Tuesday is a core operational dependency. Build for the Tuesday problems.

Third, the solution must be measurable. You need to be able to tell the user exactly what they get in return for their money. You must be able to say your tool saves them ten hours a week, or recovers five percent of their abandoned carts. If the primary benefit of your solution is an abstract concept like "peace of mind", walk away. You cannot price peace of mind.

Fourth, the problem must be technically feasible for a small team to solve. If the demand signal asks for a complete overhaul of a core operating system, you cannot build that as a solo developer. You are looking for the missing connective tissue between existing platforms. An integration, a specialized reporting dashboard, or a bulk editing tool. These are scoped tightly enough that one person can build them in a month, but valuable enough to charge a monthly fee.

Always calculate the cost of the problem before you calculate the price of your solution. If a user spends three hours a week manually copying data from Stripe to a Google Sheet, that is twelve hours a month. If their time is worth $50 an hour, the problem costs them $600 a month. If you charge $49 a month for an automated sync, the purchasing decision is frictionless. You are giving them back $551 of value.

Distribution is built into the problem

The greatest advantage of sourcing problems from public forums is that your go-to-market strategy is already written. When you finally build the solution, you do not need to buy expensive social media ads or write endless search engine optimized blog posts. You go directly back to the source.

You find the two-year-old feature request thread. You reply and state that you built exactly what the original poster asked for. You provide a link. You have just reached a captive audience of people who opted in to notifications for that specific problem. When you post your solution, every single person who upvoted or replied gets an email notification. You are leveraging the platform's own infrastructure to deliver your product launch directly to your most qualified leads.

Automating the discovery process

Manually scraping forums, app stores, and review sites takes hundreds of hours. You can build your own data pipeline to speed this up. Write Python scripts to pull App Store reviews via their public APIs. Run those reviews through a basic sentiment analysis tool to flag feature requests and filter out generic noise.

The method you choose does not matter as much as the discipline of using it. The goal is to stop guessing what the market wants.

Stop asking people what they might buy in the future. Look at what they are already demanding in public today. Read the support forums. Tally the votes on ignored feature requests. Do the math on the one-star reviews. The problems are already written down, quantified, and waiting. Your only job is to read them and write the code.