This guide covers how to use AI research tools the way founders actually need it: with the framework, the common mistakes, and the evidence to back the work.
The most common complaint we hear from founders who have tried AI research tools before Verdikt is some variation of: "it gave me something generic." The report described a market they already knew, identified competitors they had already found, and produced a risk section that could apply to almost anything. It was not wrong. It was useless.
This is almost always a brief quality problem, not a model quality problem. The tool was given a sentence or two and asked to produce a memo. Without specifics, it retrieved and synthesized the most generally available information about the general category. That is what a sentence-level brief produces.
Here is what changes when you give the model more.
The buyer.
Name the specific type of person who will pay for this. Not "enterprise customers." Not "SMBs." The VP of Compliance at a Series B fintech. The Director of Operations at a 200-person logistics company. The Head of HR at a professional services firm that does not have a full-time HRIS administrator. A named buyer type lets the research focus on what that person actually controls, worries about, and currently uses.
The geography.
If you are building for the US market first, say that. If you are building internationally, say which countries. Market size data, regulatory context, and competitive landscape differ significantly by geography. A brief that does not specify geography gets a blended picture that is accurate for nowhere in particular.
The price you intend to charge.
This is one of the most skipped inputs. The research questions change completely depending on whether you are selling at $50 per month, $500 per month, or $50,000 per year. Who controls the budget? How long does procurement take? What is the competitive pressure at that price point? None of these questions can be answered without a target price.
The two assumptions you are least sure about.
Most founders know which two things in their model they have not validated. Naming them in the brief gets the research focused on the highest-uncertainty elements rather than the things you already know.
The current solution.
How does the buyer solve this problem today? Spreadsheet? Legacy tool? Consultant? Manual process? Knowing the current solution tells the research what switching costs look like and what the status quo defense will be.
The funding stage.
A pre-seed founder needs different information than a Series A founder. Pre-seed needs market evidence that the problem is real. Series A needs competitive differentiation evidence and growth model assumptions. The brief should indicate where you are and what decision you are trying to make.
What you have already done.
If you have had five customer conversations, say so. If you have a prototype with three design partners, say so. This prevents the research from covering territory you have already covered and focuses it on what you do not yet know.
What outcome you need.
"Validate this idea" and "tell me if I should keep building" and "help me prepare for a Series A pitch" are three different requests. Name the one you actually need.
The time horizon.
If you are making a decision in two weeks, the relevant research is different from if you are planning a pivot in six months. The urgency and decision scope should be in the brief.
None of this is complicated. It is the same information you would give a good research analyst before a call. The difference is that most founders treat an AI research tool like a search engine: type a few words and expect a good result. It is not a search engine. It is a research collaborator. Brief it like one.
The nine-minute intake process at Verdikt exists precisely because we have learned which questions produce useful answers and which inputs change the quality of the output most. The report is only as good as the brief. We have built an interview process that makes sure the brief is good.
What a clean brief contains, line by line
A brief is not a paragraph; it is a structured set of fields the AI can act on. The minimum set that survives contact with a serious research tool is seven items. First, the one-sentence pitch in subject-verb-object form: "We sell scheduling software to mental health practices in two beachhead states." Second, the ICP definition with a job title, a tool they use today, and a count: "Practice managers at outpatient mental health groups with two to ten clinicians who currently use SimplePractice and bill insurance, roughly 35,000 in the US per BLS data." Third, the price hypothesis with comparable wedges: "$2,400 ACV, midpoint of the $1,500 to $3,500 band where SimplePractice and TherapyNotes sit today." Fourth, the 10× claim and its falsifier: "Onboarding in 30 minutes vs the category norm of two weeks, falsifier: if median first-value time exceeds 4 hours in our first 25 demos, the claim does not survive." Fifth, the do-nothing baseline: what does the customer do today if they do not buy? Sixth, three named competitors with the angle of attack for each. Seventh, the kill criterion: the threshold at which the pursuit ends.
A brief that contains all seven produces a research output you can act on. A brief that contains three produces an output that is interesting and unusable. The discipline of writing the brief is the work, not the prompt engineering.
Common failure patterns
The first failure mode is the omitted ICP. The brief says "B2B SaaS founders" or "AI-native teams" and the research output is necessarily generic. The fix is to write the ICP at the granularity of "person you could send a cold email to today." If you cannot picture the person, the brief is not specific enough.
The second failure mode is the unfalsifiable 10× claim. "Our product is better" cannot be tested. "Our p95 latency on the same prompt set is 1.6× faster than Cursor at equivalent context length" can be tested. The 10× claim should always be paired with the test that would falsify it. A briefing pattern that bakes this in: state the claim, then state "this is wrong if [specific measurable condition]."
The third failure mode is the missing baseline. Founders often forget that the do-nothing alternative is a competitor. Sometimes the strongest competitor. If a customer is solving 80 percent of the problem with a spreadsheet today, "our product replaces the spreadsheet" is a 20 percent improvement story, not a 10× story. The brief should name the baseline so the research can size the actual delta.
How to test your brief before you run it
The cheapest test is to hand the brief to a friend who has never heard the pitch, ask them to describe what you would build, who you would sell to, and how it would fail. If their answer matches your model, the brief is specific enough. If they cannot describe the customer in a sentence with a job title, rewrite the ICP. If they cannot name how it would fail, rewrite the kill criterion. This is the same discipline The Mom Test advocates for customer interviews: do not ask people to validate your pitch, ask them to describe what they think you mean. The gaps in their description are the gaps in your brief.
The five-minute brief test catches most failures before you spend any AI runtime. The hour you spend rewriting the brief is the hour that saves you a day of unusable research output. The interview process Verdikt’s intake runs is, in effect, a brief-testing session: the questions are designed to surface the gaps before the research stage starts. The answers a founder gives are the inputs to the research. If the answers are weak, the research is weak. The work happens at the brief.