The worst question a founder can ask an AI agent is also the most tempting one: "What app should I build?"
The agent will answer. It will give you a neat market, a plausible customer, a stack, a feature list, and a name that sounds like a product hunt submission from an alternate universe. You can build from that. You can even build quickly.
The problem is that you will be building from language that has never been responsible for a real task.
Customer discovery for AI-built products has to be sharper than normal customer discovery because the build cost is lower. When building was expensive, bad ideas died from friction. Now a bad idea can become a polished demo before lunch. The moat is no longer "can I make software?" The moat is "did I choose work that matters?"
So stop listening for app ideas. Listen for work.
The unit of discovery is a scene
Bad discovery collects opinions:
- "Would you use an AI assistant for invoices?"
- "Do you want a dashboard?"
- "How much would you pay?"
People are generous with hypothetical answers because hypotheticals cost them nothing. They will encourage you, praise the concept, and then disappear the second you send the link.
Useful discovery collects scenes:
- "Walk me through the last time this happened."
- "What was open on your screen?"
- "Who was waiting on you?"
- "What did you copy, paste, export, forward, or rewrite?"
- "What broke when you tried to solve it?"
- "What did you do instead?"
A scene has nouns, tools, time pressure, and consequences. It tells you what the customer actually did, not what they think they might want. For AI-built products, that matters because agents are good at automating slices of work. You need the slice.
"I need better client management" is too vague.
"Every Friday I open six unread client emails, copy the requested documents into a spreadsheet, write three reminder emails, and then forget which ones I sent" is a product brief.
Ask for the artifact
The fastest way to escape vague discovery is to ask for the artifact.
If the customer says reporting is painful, ask to see the last report. If support triage is messy, ask to see three anonymized tickets. If lead follow-up is slow, ask to see the actual spreadsheet, inbox label, CRM view, or sticky note where leads go to die.
An artifact does three things.
First, it proves the work exists. People do not maintain spreadsheets for imaginary problems. Second, it reveals hidden structure. Columns, labels, message templates, filenames, and folder names tell you how the business already thinks. Third, it gives your agent something concrete to build against.
Do not paste private customer data into an agent. Redact it. Summarize it. Replace names and amounts. The point is not to hand your tools raw customer material. The point is to learn the shape of the work.
The best discovery note looks boring:
Customer: local contractor
Scene: quote follow-up after site visit
Artifact: spreadsheet with lead, job type, quote sent date, next follow-up
Current workaround: calendar reminders plus copied email template
Failure: old quotes fall through after 7 days
Consequence: lost jobs, awkward manual chasing
First outcome: show overdue quotes and draft the next email
Do not build yet: CRM replacement, invoice system, full scheduling
That is enough to start.
Manual delivery beats fake validation
If an AI product can be manually delivered once, do that before you build the full thing.
For the contractor example, do not start with auth, roles, billing, a dashboard, and an email-sending agent. Start with the smallest service version:
- Customer sends you a redacted lead sheet.
- You classify overdue leads by hand or with a supervised agent.
- You draft follow-up emails.
- Customer approves, edits, or rejects them.
- You ask which draft would have saved them time.
That is not unscalable. That is the point. You are buying truth with manual effort instead of buying uncertainty with engineering.
AI makes manual delivery even more valuable because you can simulate the product without pretending the product exists. A founder with taste can use ChatGPT, Claude, Codex, spreadsheets, and email to deliver the outcome once. The customer does not care whether your backend exists yet. They care whether the work got easier.
Only after the manual version works do you ask the agent to build software around the repeated steps.
Translate pain into a first feature
Customer pain does not become a product by expanding. It becomes a product by narrowing.
The wrong translation:
Contractors lose leads. Build a full contractor CRM with AI follow-up, scheduling, quote generation, payment tracking, review requests, and analytics.
The better translation:
Build an overdue quote desk. Import a CSV. Show quotes older than 3, 7, and 14 days. Draft one follow-up email per row. Require human approval before sending. Save status and last contact date.
The second version is less impressive. That is why it can ship.
A good first feature has five traits:
- the input already exists
- the output is easy for the customer to judge
- the workflow happens repeatedly
- the risk can be gated by human approval
- the product can prove time saved or revenue recovered
If one of those is missing, keep discovering.
Use customer words, but not customer structure
Customer language is gold for positioning. It is not always gold for product architecture.
If three customers say "I need a dashboard," do not blindly build a dashboard. Ask what job the dashboard is supposed to do. Often the real need is "I need to know what to do next." That might be a list, an alert, a daily email, or a saved view inside Command Center. The customer's word names the frustration. Your job is to design the mechanism.
This is where AI agents can be dangerous. They are excellent at expanding nouns. "Dashboard" becomes cards, charts, filters, tables, export buttons, and empty states. The output looks product-shaped before anyone has proven the shape.
Feed the agent the scene instead:
A contractor misses follow-ups after quote emails. Current artifact is a spreadsheet. The first outcome is "know which quote to follow up today and draft the next email." Propose the smallest product surface. Do not propose a CRM replacement.
That prompt produces scope. The generic dashboard prompt produces theater.
The five-question interview
You do not need a 40-question script. You need consistency.
Use this:
- When did this last happen? Get a recent scene, not an opinion.
- What did you do first? Find the real workflow start.
- Where did the work slow down? Find the friction, not the category.
- What did you use to get around it? Find the workaround and artifact.
- What would have made that specific moment easier? Find the first outcome.
Then shut up longer than feels polite. The useful sentence usually comes after the customer has finished giving you the clean answer.
If the customer cannot remember a recent example, the pain may not be urgent. If they can show you the artifact instantly, lean in. If they already pay someone, buy a tool, or maintain a workaround, lean in harder.
Write the discovery receipt
After every interview, write a receipt while the details are fresh:
## Scene
## Artifact
## Current workaround
## Cost of failure
## Words customer used
## First manual delivery
## First buildable feature
## Kill criteria
The last line matters. Before you build, decide what would make you stop. Maybe three customers say the workaround is annoying but not worth paying for. Maybe no one will share the artifact. Maybe manual delivery does not save time. Maybe the buyer is not the user and nobody owns the budget.
Kill criteria protect you from vibe-coding momentum. The agent does not know when your pride has taken over. You need a written stop condition.
Where Boostor fits
Use Business Idea Generator after you have a scene, not before. It is much better at pressure-testing a real workflow than inventing demand from thin air.
Use Rank My Stack only after the first feature is clear. The stack should serve the workflow. It should not become a substitute for customer proof.
Use Command Center to keep the receipt visible while you build. Put the scene, artifact, first feature, and kill criteria where the next agent run can see them. Otherwise every new session will drift back toward generic product gravity.
The grounded take
AI has made building cheaper. It has not made demand cheaper. You still have to find work that someone already cares about, inside a workflow they already run, with a consequence they already feel.
So do discovery at the level of scenes. Ask for artifacts. Deliver manually once. Translate pain into the smallest feature that carries the outcome. Write kill criteria before the agent starts editing.
The best AI-built products do not start from "what app should I build?" They start from "show me the work you did yesterday."