A folder full of product ideas can feel like progress. So can a polished sales page, a cover image, and a model's enthusiastic explanation of the market. None tells you whether a customer has a problem worth paying to solve.
AI can help you investigate a problem, compare alternatives, build a small demonstration, and organize what you learn. The valuable result is a better decision about where to spend your time and money.
Your work product is an offer brief and a small validation plan. This chapter introduces Cedar Desk Studio, a fictional publisher and seller of administrative products. Its proposed Job Log Starter Kit and all research or sales figures below are teaching examples. No interviews, purchases, or market tests were performed.
Begin with the work someone struggles to finish
Cedar's proposed customer is the coordinator of a small service business. The working hypothesis is that requests get lost between messages, notes, and unfinished follow-up tasks.
That is still a hypothesis. A model can describe the problem vividly without establishing that this particular customer has it. Start by asking about recent events: a missed request, an unclear owner, or a task someone believed was finished when it was still waiting.
Look for the current workaround. Does the person use a notebook, a shared spreadsheet, a job-management system, or a colleague's memory? What works about that arrangement? What is costly or confusing? A new product competes with existing habits as well as other products.
The Small Business Administration distinguishes market research from competitive analysis and recommends investigating demand, alternatives, market conditions, and pricing. Use broad research to understand the setting, then collect relevant customer evidence for your particular decision. See the SBA's business planning and market research guidance.
Do not ask AI to estimate your market size from a few complaints. Preserve the population, date, definition, and source of any market number you use. When those are missing, call the number an assumption or leave it out.
Write an offer that is small enough to evaluate
A clear offer names the user, the job, the deliverable, and the boundary:
Proposed Job Log Starter Kit: a downloadable CSV template, a worked example, and a plain-language guide for small service coordinators who want to track the owner, next action, and review date of each request.
This proposed kit does not schedule technicians, diagnose equipment, send reminders, or replace an accounting system. Those boundaries help a buyer judge whether the kit fits the need. They also prevent a simple file from acquiring promises that would require software and ongoing support.
For an initial demonstration, choose one successful task: the user can record a request, assign an owner, and find waiting work that needs attention. You can examine that task without building a full application.
Record the important assumptions separately:
| Assumption | Evidence that would help |
|---|---|
| The problem occurs often enough to matter | Recent examples and existing work records |
| The intended buyer controls the workflow | A conversation about who chooses and pays for tools |
| A simple file fits the working environment | Observed use in the person's actual software |
| The kit is worth the proposed price | A clearly described, genuine purchase opportunity when ready |
| Cedar can support the product economically | Time, support, delivery, and cost estimates checked against a pilot |
One interview rarely settles all five. Choose the riskiest assumption you can investigate cheaply and honestly.
If considering tiers, compare concrete differences such as a blank log alone, a log with a worked guide, or a separately delivered setup session. Show what exists in each tier and test whether intended users need the added help. Include delivery and support time in each price; a more expensive label is not evidence of greater value.
Match the method to the question
Different tests answer different questions. An interview can reveal a problem and its context. A prototype exercise can show whether someone understands the workflow. A waiting list records interest in hearing more. A completed purchase at known terms is stronger evidence of willingness to pay under those conditions.
Keep that evidence ladder visible. Do not turn “sounds useful” into a sale, a signup into recurring revenue, or one paid trial into a large stable market.
For Cedar, a sensible sequence is to examine recent coordination problems, show a small sample, observe people using it, and then consider a limited real offer after delivery and support arrangements exist. A business may stop or change direction at any stage.
If you test a concept page, state what exists. “Join the interest list for a proposed kit” is different from “Download now.” Explain what the signup permits and collect only the information needed. Never use fake purchases, invented scarcity, or fabricated testimonials to make the experiment appear more successful.
Use AI to design the investigation
Help evaluate the supplied offer brief and customer evidence.
Separate source-supported findings from assumptions and new hypotheses.
Identify the three assumptions most likely to change our decision.
For each, propose the smallest honest investigation, the evidence it
could produce, its cost, and what it would not establish.
Draft neutral questions about recent behavior and current workarounds.
Do not invent demand, customers, testimonials, sales, willingness to pay,
market size, or a conversion forecast. Keep generated roleplay responses
outside the customer evidence dataset.
Review the proposed questions for leading language. “How much time would this amazing kit save you?” assumes both usefulness and a benefit. “Show me how you tracked the last request that needed a follow-up” can reveal the existing process.
Record participants' words and observed actions accurately. Preserve contradictory evidence. If one coordinator needs automatic reminders and another only needs a printable log, that may indicate different needs rather than a reason to promise every feature in one product.
Decide the rule before reading the result
For an exploratory round, Cedar might propose this decision rule: continue refining a small prototype if several relevant participants describe recent coordination problems and can use the sample to find unfinished work; do not build an application until the need for automation and the economics are better established.
That is an example of a local decision rule, not a scientifically validated threshold. A small qualitative round can guide the next design decision without estimating a population conversion rate.
If you run a quantitative comparison, use the definitions and experiment principles from Chapter 18. Specify eligibility, denominators, timing, exclusions, costs, and what would count as worthwhile improvement. Do not choose the success metric after seeing which number looks strongest.
Keep a time and spending limit. The investigation should reduce uncertainty enough to justify the next commitment. It should not become an endless exercise in generating more ideas while avoiding a decision.
Read the worked numbers honestly
The practice pack supplies this constructed concept-page funnel:
| Event | Fictional count |
|---|---|
| Eligible unique visitors shown the concept | 120 |
| People requesting a sample | 18 |
| People joining the interest list | 9 |
| Purchases | 0; no purchase was offered |
The sample-request rate is 15% of visitors. Interest-list signup is 7.5% of visitors. In this fixture, all nine signups came from the eighteen sample requesters, making that conditional rate 50%.
The product's purchase conversion rate has not been tested. Reporting “0% conversion” as evidence nobody would buy would be misleading because visitors were not offered a purchase. Reporting nine buyers would be equally wrong.
A useful decision memo would describe what people were shown, what action they could take, and the observed evidence a real experiment would need to retain. It would then state the next question: can intended users complete the target task, and will some choose a real offer at stated terms?
Check the economics of the next step
Suppose Cedar considers a future $19 kit. For planning only, it assumes $1 in transaction and delivery costs, $4 in support effort, and $2 in expected refunds and other variable allowances per sale. That leaves $12 of contribution before fixed development, marketing, and other unlisted costs.
If the proposed initial development cost is $240, twenty sales at that assumed contribution would recover that cost: $240 divided by $12. This is a break-even scenario, not a demand forecast. Changes in support time, acquisition cost, refunds, or price change the result. A twenty-person waiting list would not automatically cover development.
Give each assumption an owner and a way to check it. The unknown that matters most may be support time rather than the number of pages in the product. A cheap template that requires an hour of individual setup help can be expensive to deliver.
Treat advance orders as commitments
Do not collect payment merely to make a validation metric look stronger. Before any real advance sale, specify the deliverable, delivery timing, price, cancellation arrangements, and what happens if you cannot deliver. Check the applicable rules for the product, channel, and customer location.
For covered merchandise orders in the United States, the FTC's order rule addresses reasonable shipment promises, delays, and cancellation or refund obligations. It is not a universal rule for every digital download or service. See the FTC merchandise order guide.
An honest sample or interest list may be the better first step when the product is not ready. Keep payment, delivery, and customer communication outside an automated experiment until the business can fulfill the resulting obligations.
Finish with a decision you can explain
Choose among a few concrete actions: investigate a missing fact, revise the offer, run a usable prototype exercise, prepare a limited launch, or stop. Attach the evidence and remaining uncertainty to that decision.
A rejected idea can be a valuable result if it prevents months of unnecessary work. A promising idea becomes more valuable when you know precisely what to build first and what customers still need to verify.
Next: Apply the same evidence discipline to product records, prices, and inventory in Chapter 23.