Find a Problem Worth Building For

Every Friday a volunteer at a community club spends an hour sorting messages into a newsletter. That sounds like an opportunity for AI, but it isn't yet a reason to build an app. First find out whether the volunteer actually wants a different way to do the job.

Many software ideas begin with an exciting feature: an AI button, a clever dashboard or something that looks impressive in a demonstration. The difficulty is that nobody wakes up wanting another dashboard. People want a problem to go away. In the club example, perhaps the volunteer's real frustration is chasing late submissions, not writing the newsletter. A tool that drafts beautiful paragraphs would solve the wrong problem.

Begin by observing the existing process. Ask the person to describe the last time they did the task, from receiving the first message to sending the final result. Listen for moments when information was missing, work was repeated or mistakes had to be corrected. Their actual behaviour is usually more informative than asking whether they would use a hypothetical app. Most people will politely say that an idea sounds useful, especially when you appear enthusiastic about it.

Next, distinguish inconvenience from an expensive problem. An occasional five-minute annoyance may not justify another account or a new workflow. A small repeated frustration affecting several people might. Frequency, effort and consequences matter. A task can be worth solving because it takes time, creates errors, causes anxiety or delays another person's work. Put an approximate number on it where you can: how often, how long, and what happens when it goes badly?

Return to the newsletter. You discover that the secretary receives updates through email, text messages and handwritten notes. Some have dates, some do not. The secretary copies everything into a document, checks for duplicate events and asks two people for clarification. The bottleneck is organising incomplete information into an approved draft. That gives you a much more useful problem statement than 'make an AI newsletter app'.

Write that statement in plain English: 'A club secretary spends about an hour each week reconciling updates from several sources; they need one easy way to produce a draft with missing details clearly marked for review.' Notice the limits. It says who benefits, what happens now and what improvement would count. It does not assume that an AI model, website or database is necessary. Keeping the solution open protects you from becoming attached to the first technology you imagined.

Now check whether a simpler intervention might work. A standard submission form could reduce missing information. A shared document might eliminate copying. AI could then be useful for grouping updates, removing duplicates and preparing a readable draft, but it should not invent dates or publish unapproved news. Sometimes the first successful solution is a checklist rather than software. That is still a useful discovery, not a failed product idea.

Choose a problem you can access and observe. Building for a fictional stranger is harder because you cannot find out whether the tool helps. A club organiser, a family member or your own repeated task is a better first user. Avoid starting with sensitive records or decisions where a mistake could harm someone. A low-stakes project allows you to learn the building process without confusing technical success with safety or professional authorisation.

Before building, ask your intended user to show you an example of the current input and a satisfactory finished result, with private details removed or replaced. These two artifacts reveal requirements that conversation often misses. You might discover that the newsletter has to fit on one printed page or that a particular person must approve it. Such constraints shape the useful product far more than its visual design.

Finally, agree on a small evidence test. If the new approach lets the secretary produce an accurate draft in twenty minutes rather than an hour, with less chasing and no extra mistakes, you've identified a worthwhile improvement. If they cannot explain when they would use it, or they keep returning to the old method, revisit the problem. The first builder skill is not creating software. It's recognising work that someone would genuinely welcome help with.

Consider what would make you abandon this particular idea. If the volunteer only prepares a newsletter twice a year, cannot provide sample material and already has an effortless method, there may be little to improve. Conversely, if several people regularly struggle with the same incomplete submissions, the opportunity may be stronger than you first thought. Write down both the evidence for the problem and evidence against it. That small act of intellectual honesty will save more building effort than any cleverly worded prompt.