AI Bits #6: Test the customer problem before scaling outreach

Before scaling outreach for an AI product, establish whose problem you are testing and what would change your mind. This issue offers a conversation guide and a decision log you can use before investing in another feature. Neither compliments nor a clever demo establish demand.

10 September update: a completed fictional discovery record, a separate unrun next-test plan and a downloadable worksheet now accompany the questions. No interviews, outreach or customer results were added.

This is for Australian AI/startup-curious founders deciding whether an idea addresses a worthwhile problem. The immediate outcome is a reasoned decision to investigate, change scope or stop—not a sales funnel or a contractor application.

What the paper actually examines

Viktor Jarotschkin, Mostofa Wahid Soykoth and Nawar N. Chaker's 2025 paper, Artificial intelligence in sales research: Identifying emergent themes and looking forward, appears in the Journal of Business Research. The source check below uses the publisher-indexed abstract, checked on 10 September 2026; full text was not independently reviewed.

On small screens, scroll the tables sideways. Keyboard users can focus each labelled table region and use the arrow keys.

Neither a universal build-versus-sell time allocation nor a guaranteed acquisition rate is established here. The literature review does not validate the exercise.

1. Write a problem hypothesis, not a product pitch

Choose one role, one situation and one suspected difficulty. “Businesses need AI” is too broad to test. State what someone does today and why changing that work might matter. Write down a competing explanation before speaking to anyone.

Illustrative example, not customer research: “An owner of a small service business spends time checking whether enquiries received a reply.” A competing explanation is that the existing inbox already handles this adequately; the real issue might be unclear responsibility rather than missing software. Do not assume an AI agent is the answer.

Keep the initial question separate from your preferred implementation. If participants describe a simple process change, that is useful evidence even when it removes the reason to build your product.

2. Ask about a recent event

Explain who you are, that you are exploring a possible product and how you intend to use the conversation. Do not disguise selling as neutral research. Ask permission before recording or retaining notes; avoid collecting customer records or confidential material. A participant can decline or stop.

1. “Tell me about the last time this happened.” Follow the trigger, people, tools, exceptions and result.
2. “What did you do instead?” Ask what is satisfactory about the current workaround, including doing nothing.
3. “How often does that happen, and how do you know?” Label recollections as estimates; do not turn an anecdote into a market statistic.
4. “What makes changing this difficult?” Explore responsibilities, permissions, training, switching effort and competing priorities.
5. “Who uses it, and who decides whether to change it?” A user's enthusiasm is not purchasing approval.
6. “What have I misunderstood?” Invite correction rather than endorsement of a proposed feature.

Record what was said separately from what you think it means. Quotes require permission for publication and enough context to remain accurate. AI can help organise de-identified notes when appropriate, but invented interviews, inferred motives and synthetic quotes must never become customer evidence.

3. Choose the next test before counting success

A conversation can identify a question worth testing; it does not prove willingness to pay. Agree a bounded next step with a willing participant, such as reviewing a mock workflow using fictional inputs. State what you will observe, the effort you can afford and what would make you stop or change direction.

Define the segment, recruitment route and time window when reporting results. Track invitations and refusals as well as completed conversations. A convenience sample of friends or event attendees does not represent the whole Australian market. Do not select only encouraging responses or describe a small trial as product-market fit.

4. A worked decision that changes the proposed product

Entirely fictional example: all people, dates, counts and notes below are invented. No interviews or outreach occurred. No market demand, permission or customer result is established. This is an illustration of how to reason, not customer research.

A Melbourne idea-stage founder suspects that small service-business owners miss replies because drafting is difficult. The fit rule is an owner who personally handles or supervises enquiries and can describe a recent instance. The competing explanations are an adequate existing inbox, unclear responsibility or an unimportant problem.

The fictional recruitment window is 1–7 September 2026, using permission-first introductions through an existing professional network. The ledger retains 8 invitations: 3 completed conversations, 2 declines and 3 without a response by the cutoff. All eight invented records are in the download. This convenience sample cannot represent the Australian market, and no actual contact permission exists.

Missing measurement: Frequency unknown; active effort unknown; error cost unknown. Do not replace missing values with zero or claim recovered hours, sales or margin.

Worked decision: CHANGE SCOPE: stop building the automatic-reply feature for now. Investigate ownership with a manual mockup before considering any AI implementation. Revisit only if suitable participants demonstrate a consequential drafting problem that their existing process cannot address.

P1 stays in the example because a satisfactory existing solution challenges the original idea. P3 and P5 suggest a different question; they do not establish paid demand. Declines and non-response may concern access or timing, not the absence of a problem. None of these invented notes should be used in a pitch deck as traction.

5. Specify a small next test without inventing its outcome

The founder's proposed follow-up is a manual responsibility exercise, not an AI build. It is UNRUN; the example includes no participant behaviour or measured improvement. Replace the invented dates and limits with your own before proposing a real test.

Question

Would making responsibility visible address the described handoff confusion without new AI software?

Status and participants

UNRUN. Seek agreement from up to two relevant participants and confirm an appropriate staff role. None has consented or been recruited for this test.

Materials

Prepare eight invented enquiry cards: four with a stated responsible role, two with conflicting ownership and two outside the proposed workflow. No real messages, contact details, model or integration.

Procedure

First ask how each participant would handle the cards today. Then show a paper owner/status column. Ask them to assign or escalate each card and explain the choice; do not coach them toward the preferred result.

Limits

Proposed window: 8–11 September 2026, entirely fictional. At most two hours of total founder effort, including preparation and review, with at most 30 minutes per session. A$0 external spend; the time is not free.

Record

For each of the eight cards: current approach, proposed approach, assigned/escalated/unclear result, participant explanation and observed time. Keep missing observations unknown. Include refusals and interrupted sessions.

Decision rule

If both completed sessions prefer the existing approach and reveal no useful change, stop this mockup. If ownership stays unclear, revise the responsibility rule before testing again. No completed sessions means an access problem to investigate, not proof of no demand. These are editorial choices, not statistically validated thresholds.

Stop and follow-up

Stop immediately if a participant wishes to stop or private information is introduced. Do not connect a live inbox or send messages. Discuss any future invitation separately; this plan grants no contact permission.

Actual result

UNRUN — no participant behaviour, timing, improvement, customer or willingness-to-pay result is available.

Keep the task and evidence separate from the technology you hoped to sell. If a clearer owner/status column is sufficient, that is a reason not to commission an autonomous reply agent. If the test cannot be completed, preserve the missing result and decide how to investigate it.

6. Save the prompts, example and decision log

Download the discovery worksheet as an editable plain-text file. It includes the six prompts, blank log, all eleven completed example fields, eight-record recruitment ledger, three fictional conversation notes and unrun test plan. No account or email is required.

Use one record per test in your own notes. This is a working aid, not a validated research instrument. Keep the supplied fictional example separate from any actual notes, and leave uncertain fields unknown. You can also select and copy the blank log below if downloading is unavailable.

Customer problem test — keep identifying and confidential details out
Date / segment / participant role:
Hypothesis and what would contradict it:
Recruitment method / invitations / refusals / completed conversations:
Recent workflow described / current workaround:
Observed evidence versus my interpretation:
Frequency / effort / cost: measured, estimated or unknown?
User / decision maker / approval constraints:
Small next test / time and spending limit:
Expected observable action / stop condition:
Result, including non-response and contrary evidence:
Decision: investigate, change scope, test or stop — and why:

End with a decision and its reason. “Stop: the current process is adequate” is a legitimate outcome. “Investigate: the user has the problem but the budget owner is unknown” is more informative than counting another positive conversation.

Continue the discussion without turning it into a pitch

If you want peers to challenge your assumptions, bring the non-confidential problem statement and one unresolved question to a suitable community event. Ask whether someone wants to discuss it; attending is not consent to a sales sequence. Peers can help improve the test, but their feedback does not replace evidence from your intended customers.

Only once a problem warrants an offer, continue with the first-customer conversation and scoped-offer guide. That is a later decision, not a reason to ignore contrary evidence here. No worksheet is automatically shared with event organisers or attendees.

Original publication: 25 February 2026. Substantive correction: 9 September; worked-example update: 10 September 2026. Original contributor credits remain in the publication record. Codex assisted the fictional teaching material and local checks; no actual customer research or new independent expert review is claimed.