“I want to build an AI product” describes a technology preference. It does not yet tell you whose work will improve, which difficulty you will address or whether anyone needs another tool.
Before choosing a model, investigate one task that someone already performs. Find out where it breaks down, what they do instead and what would count as an improvement. You may discover a useful software idea, a simpler process change or a problem that is not worth pursuing right now.
This guide shows how a beginner can make that decision with a small, respectful investigation. It applies to personal tools, internal business software and possible products, not only freelance services.
Choose a person and a moment
Start with someone whose workflow you can understand: a student organising revision, a shop assistant checking stock or a club organiser tracking borrowed equipment. Avoid broad groups such as “all businesses.” Their tasks and constraints differ too much for a first experiment.
Then name the moment of difficulty. “A shop needs AI” is vague. “At closing time, the assistant cannot tell which items customers requested but the shop did not have” describes an observable situation.
You are still forming a hypothesis. The person may already have a workable method, or the difficulty may happen too rarely to justify a new system. Treat that possibility as a useful finding.
The UK Government Digital Service recommends learning what users are trying to do, how they currently do it and which problems they experience. It also distinguishes evidence from assumptions. Those research principles are useful here, although the guide itself concerns government services rather than startup success. Learning about users and their needs.
Ask about a recent event instead of pitching a product
An opening such as “Would you use my AI assistant?” encourages an opinion about an imagined future. Ask someone to describe the last time the task occurred.
Useful questions include:
- What were you trying to finish?
- What information did you need, and where did you find it?
- Which step took extra effort?
- What did you do when something was missing or wrong?
- What happened after that?
- Could you show me the process using invented or non-sensitive information?
Ask permission before observing or taking notes. Do not collect customer details merely to make the exercise feel realistic. Summarise the workflow without names, private messages or account credentials. If you cannot investigate safely, choose another practice task.
Listen for differences between what someone says generally and what happened in the specific example. Neither automatically invalidates the other. The difference gives you a question to investigate next.
Worked example missing stationery requests
Imagine Sara, a fictional beginner, talking with a fictional neighbourhood stationery shop owner. Her first idea is an AI sales assistant. During a discussion of a recent afternoon, she learns that staff sometimes forget which unavailable notebook sizes customers asked for.
The shop already tracks items it sells. The missed requests are different: no sale occurred, so the request is easy to lose. The owner currently relies on memory and occasional notes.
Sara writes a narrow problem statement:
When customers ask for an unavailable stationery item, the person at the counter needs a quick way to record the item and review repeated requests before deciding what to restock.
This statement does not promise that a request will become a sale. It also does not assume that every staff member will remember to enter the information.
Her first questions are practical. Can staff record a request without delaying the next customer? Do different workers describe the same notebook consistently? Does the owner actually review the list before placing an order?
These questions matter before model selection. A clever categoriser would be irrelevant if nobody records or reviews the requests.
Figure 1. Move from a specific event to an observable trial before choosing the technology.
Separate facts assumptions and decisions
Sara’s notes need three different labels.
Observed or reported: the owner described missing requests and showed an existing blank note sheet. A reported event is still a report, not direct observation of every occurrence.
Assumed: staff will enter a short request during busy periods; the owner will use the weekly summary; similar descriptions can be grouped reliably.
Decision: try a simple request sheet with invented examples first, then ask whether a limited real workflow trial would be appropriate and authorised.
This separation prevents a common mistake: turning an enthusiastic conversation into a claim that demand is proven. One person’s interest can justify another investigation. It cannot establish a broad market or reliable revenue.
Keep negative evidence too. If the owner says the issue is annoying but never affects decisions, the opportunity may be weaker than the initial story suggested.
Try the simplest useful version
Sara sketches a sheet with three fields: item description, date and quantity requested. She tests it with invented entries. She manually groups repeated descriptions and shows a sample summary.
She asks the owner to interpret the summary without explanation. Which items would they investigate? What information is missing? Would the list change a restocking decision, or merely repeat what they already know?
This is a prototype of the workflow, not evidence of a working business. Its value is that Sara can change it cheaply before building software.
If they later agree to a limited real trial, define its boundaries in advance: who enters information, which non-sensitive fields are needed, where the records stay, who reviews them and when the trial ends. Do not quietly expand from a paper sketch into collecting real customer data or messaging customers.
Decide whether AI has a specific job
Compare three possible approaches to the same task.
A process change might be enough: a visible request sheet beside the till and a review habit before ordering stock.
A simple program could store requests, filter by date and count exact item labels. Fixed rules are useful when the required behaviour can be stated clearly.
An AI experiment might suggest that “large maths notebook” and “A4 squared exercise book” belong in a related group. That introduces uncertainty: the descriptions might refer to different products, and a mistaken grouping could hide demand for one of them.
Before trying that experiment, define what a correct suggestion means, prepare representative examples you are allowed to use and decide who reviews uncertain results. Compare the suggestion workflow with the simpler version. Include the time needed to correct mistakes, not only the time the model takes to respond.
Do not let the label “AI” make the decision for you. The job is to improve the task under its real constraints.
Figure 2. Choose an approach by the work it needs to do and the mistakes you can tolerate, not by its novelty.
Define a small test and a stop condition
Choose evidence you can actually collect. For Sara’s imagined workflow, useful observations include whether staff can complete an entry, whether descriptions are understandable later and whether the owner can use the summary to identify a question worth investigating.
Record the starting method too. Otherwise, you cannot tell whether the new process is an improvement. Avoid a made-up success percentage chosen only because it sounds professional.
Write a decision rule in ordinary language: “Continue if staff can use the record during the agreed trial and the owner finds it helpful for a real review. Revise if the fields are confusing. Stop if the record adds effort without informing decisions.”
A trial result may be mixed. Perhaps the summary is useful but entry is too slow. That points to a narrower revision, not automatic approval for a larger application.
Use this problem brief
Before installing another tool, fill in these lines:
- Person and situation: who encounters the problem, and when?
- Current task: what are they trying to finish?
- Recent evidence: what specific event or authorised observation supports the problem?
- Current workaround: how do they manage today?
- Consequence: what is delayed, missed or made harder?
- Unknowns: which important claims remain assumptions?
- Smallest trial: how can the workflow be tested without a full product?
- Simple alternative: could a checklist, sheet or fixed rule solve it?
- Possible AI role: what uncertain task would AI perform, if any?
- Limits and decision: what data is permitted, and what result means continue, revise or stop?
If the evidence line is empty, your next task is research. If the simplest alternative is already adequate, you may have found a useful solution without an AI feature.
Your next step
Pick one familiar, low-risk task. Have one permission-based conversation about a recent example and write a one-page problem brief. Do not buy tools or promise a delivery date yet.
Use the brief to decide what you need to learn next. A counting problem may lead to a small program. An ambiguous-text problem may eventually justify an AI comparison. A weak problem may lead you to stop. All three outcomes can prevent unnecessary work.
Frequently asked questions
What if I do not know any business owners?
Start with a task in your own studies, a household routine or a club you belong to. Personal experience gives you a starting hypothesis, but investigate other users separately before assuming they share your needs.
How many conversations prove an idea is good?
There is no universal conversation count that proves demand. Look for specific evidence, repeated patterns and important differences. A few conversations can expose a weak assumption, but broader product decisions usually require more evidence than initial interest.
Is a problem still valuable if a spreadsheet solves it?
It can be. The person’s outcome matters more than the complexity of your software. A working spreadsheet may be the appropriate endpoint or a way to learn the workflow before deciding whether a dedicated application adds value.
Does someone saying they would pay validate a business?
It is a signal to investigate, not proof of actual purchasing behaviour or sustainable economics. Understand who makes the purchase decision and what alternatives exist. Do not turn a casual comment into a revenue forecast.
Should my first AI idea involve health or financial decisions?
For a beginner practice project, choose a lower-risk task where mistakes are easy to inspect and reverse. High-impact decisions bring responsibilities that a small prototype and a few informal tests do not establish you can meet.
When should I stop working on an idea?
Stop or change direction when evidence shows the problem is minor, the existing method is adequate, you cannot test safely or the proposed solution adds more effort than value. Preserve what you learned so the next idea starts with better questions.