How to find real-world problems worth solving with software

Why starting with a problem matters

Most software ideas begin as a solution: an app that does something clever, a tool that uses a new technology, a feature someone wishes existed. The trouble with starting there is that you then have to go looking for people who need it, and you are already attached to the answer before you understand the question.

Starting with a problem reverses the order. You begin with something that is already happening in people’s lives — a task that is confusing, slow, error-prone or stressful — and only then ask whether software could make it meaningfully better. That gives you three advantages:

• The people who need the product already exist, because the problem exists.
• You can check the problem is real before writing a line of code.
• You have a clear test for every later decision: does this help with the problem or not?

None of this means ideas are bad. It means an idea is most useful as a prompt to go and look at the problem behind it.

Look for repeated workarounds

The strongest signal that a problem is worth solving is that people are already solving it badly. A workaround is evidence that someone cares enough to put in effort, and that the existing options don’t fit.

Workarounds tend to look like:

• sticky notes, whiteboards and reminders written on the back of envelopes
• the same message copied and pasted to different people every week
• a tool being used for something it was never designed for
• one person in a family or team who “just keeps track of it all”

When you notice a workaround, ask what it is compensating for. The answer is often a more precise problem than the one you started with.

Look for spreadsheets, paper and manual coordination

Spreadsheets are the world’s most common prototype. When people maintain a spreadsheet for something that happens repeatedly — tracking applications, managing bookings, recording who has paid — they have already designed the data model for a product. They have also shown that the job matters enough to maintain.

Paper is a similar signal. A printed calendar on the fridge, a paper book of vouchers, a notebook by the till: each is a process that works well enough to survive but probably has gaps that software could close. Manual coordination — phone calls, group chats, reminders from one person to another — points to the same opportunity.

Look for tasks people repeatedly forget or avoid

Some problems aren’t about difficulty. They are about attention. Tasks that people forget, put off or find draining are good candidates, because software is very good at remembering, prompting and reducing the effort needed to start.

Listen for phrases like “I always mean to…”, “I never know where…” or “I have to remind them every time…”. They usually describe a recurring friction rather than a one-off inconvenience.

Look for problems that already cost time or money

A problem that already costs something is easier to reason about. If a small business loses repeat customers, if a job seeker spends hours on applications that go nowhere, or if a carer spends part of each day answering the same question, the cost is visible.

You don’t need precise numbers at this stage. You need to know whether the people involved would recognise the cost if you described it to them, and whether they already spend time or money trying to reduce it.

Separate inconvenience from genuine pain

Plenty of problems are real but not worth solving. People will agree that something is annoying and then carry on exactly as before. That is an inconvenience. A problem that causes genuine pain is one people actively try to fix, talk about without prompting, or would change their behaviour to avoid.

A few questions help tell the two apart:

• Have they tried to solve it already? What did they try?
• What happens when it goes wrong?
• How often does it happen?
• Who else is affected when it does?

If the honest answers are “no”, “not much”, “rarely” and “nobody”, it is probably an inconvenience.

Talk to the people living with the problem

It is easy to reason about a problem from a distance and get it subtly wrong. The fix is to talk to the people who live with it — and to ask about what they actually do rather than what they would like.

Ask them to walk you through the last time the problem came up. What happened, what did they do, what was frustrating? Specific recent stories are far more reliable than general opinions, and they often reveal details you would never have guessed.

Try not to pitch your idea during these conversations. As soon as you describe a solution, people start being polite about it, and you stop learning about the problem.

Write a one-sentence problem statement

Before you build anything, try to describe the problem in one sentence: who has it, what goes wrong and why existing options don’t fix it.

If you can’t fill that in clearly, you probably don’t yet understand the problem well enough. If you can, you now have a yardstick for every feature you consider later.

Test whether the problem is frequent enough to matter

Frequency matters as much as severity. A problem that happens once a year may be painful, but people rarely adopt a new tool for it. A problem that happens daily or weekly gives a product the chance to become part of someone’s routine.

Check frequency directly: ask people when the problem last happened and how often it comes up. If the answers are vague, it is probably less frequent than they think.

Examples from Incyworks experiments

Every Incyworks product starts with a problem statement rather than a feature list. A few examples:

• Daily Viewstarted from the observation that keeping track of the day can become confusing and stressful, particularly for older adults. Paper calendars are easy to miss, and phone apps are often too complex for a quick glance. The product is a calm display of today’s activities and what happens next.
• Proper Treat started with independent businesses that want the repeat visits gift vouchers bring, but find existing options clunky to sell, awkward to redeem or built for chains.
• Role CV started with job seekers applying broadly with one generic CV, spending time on poorly fitting roles without knowing which gaps were holding them back.
• Daily Product Idea is aimed at a problem this guide touches on directly: aspiring builders losing momentum while searching endlessly for the right idea.

Each of these is still being tested. Starting with a clear problem doesn’t guarantee a product will work, but it does make it much easier to tell whether it is working. The next step is to test the idea before building too much, and then to decide on the smallest useful version of the product.