Build with AI · Chapter 8 of 13
Find a problem someone already spends time solving
Start an AI business investigation with the last time a problem happened, not a promise of future customers.
About 5 minutes · school-level background
Edition 2026-10-28.1 · Checked 2026-10-28
What you will understand
Separate an interesting AI idea from evidence of a recurring need and design a small voluntary pilot.
In this lesson
Build the idea
A product idea meets an ordinary Tuesday
You tell a friend that AI could organise all their club information. They say it sounds amazing. That is encouraging, but you still do not know what happened last Tuesday when they tried to update an event. Perhaps the problem was conflicting documents. Perhaps nobody knew who was allowed to approve the change. Perhaps the existing spreadsheet was already good enough. Each explanation points to a different product, and one points to no product at all.
Start with a recent, specific occurrence. Ask what they were trying to finish, what material they used, where they got stuck and what they did next. A real sequence of actions reveals more than an abstract opinion about AI. You are looking for work that consumes time, causes mistakes or prevents an important outcome. The person may describe it without using technical language, so listen for the task rather than your preferred solution.
Ask about a recent task
Follow the existing steps
Find the costly or confusing part
Agree on a small voluntary test
A simplified reading aid. Follow the article for sources, conditions and limits.
What the source reports
An older idea that still helps
Paul Graham’s July 2013 essay argues for doing early work manually and recruiting initial users directly. It is founder advice, not proof that a particular business will succeed. We borrow the practical starting point: learn from a small number of actual tasks before investing in broad automation.
Original report: Paul Graham: Do Things that Don’t Scale
Use the idea
Ask questions that allow an inconvenient answer
Useful questions include: when did this last happen; what did you do; which part took longest; how often does it occur; what counts as an acceptable result? Ask to see a public or anonymised example if they are comfortable sharing one. Avoid turning every question into a sales pitch. Would you love an AI that fixes this invites agreement. What did you use last time may reveal a free tool that already solves most of the problem.
The existing workaround is your real comparison. It may be a spreadsheet, a group chat, a volunteer’s memory or doing nothing. Your product must improve something that matters enough to justify changing that routine. Saving ten minutes may be valuable for a weekly task and irrelevant for a task done once a year. A person may dislike a process but still prefer it to teaching a new service their rules.
Worked teaching example
Turn an interview into a testable need
Imagine a fictional organiser who manages six public events each month. They say the difficult part is checking whether changed details reached every listing. A vague need would be automate events with AI. A testable need is compare an approved update with three public listings and return the discrepancies before Friday. The second version names the input, output, deadline and person who can judge the result. It is small enough to attempt and specific enough to fail honestly.
Suppose you perform one comparison manually with an assistant and find two mismatched rooms. The organiser confirms that one is a real error and the other is a different event with a similar name. You have learned both something useful and a failure boundary. Record how you matched event identity. Counting two discoveries would exaggerate the result. Keeping the rejected match helps the next attempt avoid repeating the mistake.
Now imagine that the organiser says the list is accurate but arrives after their publication deadline. The technical result is correct and the service is still not useful in that situation. Delivery time belongs in the acceptance criteria. So do the format, source links and handling of unresolved cases. A product earns trust by fitting the whole task, including the ordinary details that a demonstration tends to leave out.
Build the idea
Explore ways the work could become a business
The same underlying task can support different arrangements. You might offer a manual checking service, a reusable template or software that the organiser runs. Each puts different work on you and the customer. A service lets you learn from exceptions but may require your time on every job. A template is simpler to distribute but may need the customer to do more checking. Software can repeat steps, yet still needs maintenance and support.
Do not choose a subscription merely because software businesses often use one. Ask whether the need repeats and whether ongoing delivery adds value. A one-off project may suit a one-off payment later; a repeated monitoring task may justify recurring work. At the WRS pilot stage, participation remains free. Investigating these options does not activate payments or imply that anyone has agreed to buy. The immediate evidence is whether the result is wanted and used.
Use the idea
Make the first pilot small and voluntary
Write a pilot offer in plain language: I can compare these three public listings against your approved update and return a discrepancy table by Friday; you decide whether to use it; I will not publish changes or contact attendees. Agree how the recipient will tell you whether the output helped. Avoid collecting private attendee details when the task concerns public event information. A narrow scope makes a useful trial easier for both sides.
After delivery, ask what they actually did with the result. Did they correct a listing, forward it to a colleague, or leave it untouched? Their reasons matter. If they did not use it because the format was awkward, that suggests a change. If the problem rarely occurs, you may choose another task. A negative outcome is useful when it changes your decision before you spend weeks building.
Use the idea
Leave evidence instead of a success story
Keep an honest record of the proposed need, the deliverable, the recipient’s response and the change you would make. Separate a compliment from adoption and adoption from payment. Do not turn a friend’s enthusiasm into a customer count. When you share a result on WRS, make the contribution understandable and reusable without exposing someone’s private information. The strongest early business lesson may be a clear reason to stop, narrow the promise or serve a different user.
Words you can now use
- Workaround
- What someone currently does to get past a problem.
- Adoption
- Actual use of a result or product in the intended task.
- Pilot
- A limited trial with agreed scope and a way to assess the outcome.
Check your understanding
Five friends say your idea sounds useful, but nobody has tried its output. What do you know?
Show the explanation
You have encouraging reactions, not evidence of use, recurring demand or willingness to pay. The next useful check is a small real task with a recipient who can explain whether and how they used the result.
Read the original sources
- Paul Graham: Do Things that Don’t ScaleFounder essay · Published 2013-07 · Checked 2026-10-28
Try it with your own assistant
Select and copy this bounded exercise. A normal chat assistant is enough to start.
Choose one accessible group and one repeated information task. Draft five questions about the last real occurrence, existing workaround, frequency, cost and acceptance. Collect no personal information you do not need. Do not invent interview findings or contact people without your own permission.
Keep the task brief, supplied inputs, checked output and unresolved questions together. Using this exercise does not submit anything to WRS.