Test a new offering with simulated customers.
An imagined customer can expose a confusing offer or a missing feature before a real customer sees it. The useful simulation starts with customers who resemble the people you want to serve: their work, constraints, alternatives and reasons to say no. You get to correct that cast before anyone reacts.
Try it now
Copy the prompt into your AI tool of choice, then answer its questions as they come.
Paste it into any AI chat to start. For most people, this is all you need.
Everything on this page in one paste: the prompt plus the full plan, every step and what to check. Use it for longer moves, to plan ahead, to share with a colleague, or if your AI can't open links.
How it goes
What the AI will do
- Find existing customer personas and the evidence behind them, or propose plausible customers from research and company records.
- Run separate reactions to the same offering, reconcile the findings and revise the offering into a stronger version for real-customer testing.
What to have ready
- The new offering in whatever form it exists: a rough description, proposal, prototype or product page.
- Accessible customer research and company records; the AI looks for existing personas before asking you to create them.
Where you come in
- Clarify the offering and edit, add or remove the proposed simulated customers.
- Accept the cast before the simulation, then judge which proposed changes belong in the revised offer.
What you'll get
A revised offering, a comparison of simulated reactions and specific hypotheses and questions to take to real customers.
You're done when
You have accepted the customer profiles, seen their simulated reactions, reviewed a concrete revision of the offering and received a short brief for testing the important hypotheses with real customers.
These are general instructions, not a description of this user's particular AI system, tools, access, or circumstances. Adapt the method to the user's goal and the capabilities you can actually use, while preserving the activity's essential sequence, review points, and intended result. ### Start with the activity and the user's context Read the complete activity and guide the user through it. Use the activity prompt yourself; the user does not need to paste it again. Keep the responsibilities of the user, the AI, and any colleague clear. Begin with what the user has already supplied. Establish the intended result and resolve missing context through focused questions when needed. Work within the activity's stated scope, permissions, required confirmations, and stopping points, including any deliberate order for introducing information. Make progress with the available information and reasonable, clearly identified assumptions where the activity allows them. ### Check the capabilities needed for this work Inspect relevant available tools, connectors, and data. Use small, relevant, non-destructive checks to establish whether necessary access or a capability actually works. Naming a product does not establish access to it. Let this activity determine what needs checking; do not impose a universal preliminary questionnaire or a full system audit. When useful access is missing: - Explain what you cannot reach and how that material would help. - Investigate practical setup, connection, export, or other access alternatives before asking the user to gather material or troubleshoot. - If progress depends on access, request only the specific user action or permission needed to enable it or provide the material another way. Continue useful independent work while awaiting the response. - Offer to walk the user through an export or upload. Welcome files, links, copied text, rough notes, or an interview as supported by your system and the activity, and use the best available route. If the missing access is optional, continue with what is available. ### Ask focused questions and respect the answers Ask questions only when necessary to complete the work well or satisfy the activity's required review points. Build on answers already supplied. Ask one question at a time, or a small group of closely related questions. Wait on work that depends on the answer, and continue useful work that does not. Explain unfamiliar language with examples where helpful. Confirm answers or decisions you supply on the user's behalf before treating them as the user's final answers or decisions. This does not require separate approval of every sourced finding; follow the activity's specific review requirements. ### Keep evidence and independent contributions distinct Distinguish evidence, inference, and missing information. Check your work against the source material. Use independent agents when your system actually supports delegation and independent investigation or review would improve the work: - Give each agent a bounded brief and the context appropriate to its role. - Keep discovery independent until synthesis where the activity requires it. Preserve any requirement for the user or colleagues to contribute before seeing other explanations. - Follow the activity's stated fallback and any required confirmation when independent agents or fresh contexts are unavailable. Preserve reviewer isolation where required; describe shared-context or sequential passes accurately. ### Produce, check, and revise the result Do the substantive investigation and production. Carry the activity through to the most complete, usable result within its scope, rather than ending with a plan or handing the main work back to the user. When missing information does not prevent useful work, proceed with clearly identified assumptions where the activity permits them. Check the result against the activity's completion criteria. At each substantive delivery, state what is complete and any material unfinished work, assumptions, helpful missing information, and remaining uncertainty. Explain how these affect what the user can use, and help the user revise the result. Preserve the activity's stopping point. Do not turn a rehearsal, investigation, or test-design activity into execution that the user has not authorized. Help me test a new offering with simulated customers and use what we learn to improve it. First establish who those customers should be and let me correct and accept them. Do not run customer simulations before that agreement. ### Understand the offering and find existing customer knowledge Read the offering I supplied, whether a rough idea, document, product page or prototype. Establish what it does, who might use or buy it, the proposed price or commitment if known, and what I want to learn. Inspect and try access to relevant company email, message boards and chats, research documents, product plans, sales and support records, customer interview transcripts and meeting notes. Search the offering name and related products for existing personas, segments, customer problems, objections and prior tests. Use calendar or interview participant records and account roles where they help distinguish buyer, user and decision maker. Read the dates and evidence behind any personas. An old marketing persona may be useful context without describing this offer's intended audience. Separate observed behavior, customers' reported preferences, our team's assumptions and missing information. If company records are unavailable, investigate connection or export options and help me provide existing research or a few useful examples. If no personas exist, use customer interviews, transactions, observed use, lost sales and relevant primary public research to develop a proposed cast. If the available basis is only my experience or a rough hypothesis, say that plainly. Do not present invented customer research as something you found. Ask focused questions one at a time about gaps that matter to the proposed test. ### Agree the cast and what they will see Propose a small, manageable set of simulated customers that covers materially different needs or buying conditions. Use the evidence to choose differences, rather than filling a demographic template. For each, describe: - Their role and situation, including whether they use the offer, pay for it or influence the purchase. - The job they are trying to do, how they do it now and what a useful result would mean. - Relevant constraints, vocabulary, concerns and reasons they might decline. - The records supporting those traits, any important counterexamples and which traits are inferred. Show me the proposed cast. Invite me to alter descriptions, add people or remove people who do not belong. Ask the clarifying question that would most improve their realism. Wait for my acceptance of the resulting cast before running any simulated reactions. Incorporate corrections and keep my proposed traits distinguishable from recorded customer evidence. Prepare one common test stimulus: the actual offer description, page or prototype that every simulated customer will receive. Separate confirmed features and terms from proposed or unknown ones. Do not quietly supply missing benefits or explain away confusing wording. Establish the questions we want the test to answer, such as whether users understand it, where it fits their work, which missing element prevents use or what comparison drives a refusal. If an unresolved feature or price is central, let me resolve it or explicitly agree how the hypothetical term will be tested. ### Run independent customer encounters Use separate agents or fresh sessions for the accepted customers when supported. Give each a self-contained brief with its accepted profile, the relevant evidence and uncertainties, the identical stimulus and the test task. Do not give them other customers' reactions, your preferred verdict or an argument for why the offering should succeed. A large cast can run in waves; track which accepted profiles completed the same test. Have each simulated customer encounter the offering in its own working situation. Ask it to explain what it understands the offer to do; describe a concrete occasion when it might use it; walk through how it would start and fit the offer into its current work; identify confusing or missing information; and explain what would make it choose its present alternative instead. Where a usable prototype exists, have the agent attempt a representative task with the available tools and record what it actually did. Distinguish that interaction from an imagined walkthrough. Request a short reaction in the customer's voice followed by the evidence or accepted assumption behind each substantive concern. Do not demand that every customer produce a complaint or like the idea. Have agents identify gaps they cannot answer from the supplied profile. Avoid invented statistics, precise willingness-to-pay estimates and claims that a real person has spoken. If isolated sessions are unavailable, explain that sequential role passes share context and offer a precise handoff for fresh chats if that matters to me. Agree that fallback before proceeding. Either way, keep the profiles and stimulus fixed and describe the method honestly; several reactions from one shared conversation are not independent customer evidence. ### Reconcile reactions and improve the offer Wait until the independent encounters finish before comparing them. Organize findings around concrete moments in use or purchase: what was understood, what failed to fit, what information was missing, what value was recognized and why someone might decline. Link each finding to the responsible profile, the exact part of the offer and its source basis. Distinguish repeated reactions from one persona's specific needs. Similar model-generated comments do not establish prevalence among real customers. Examine conflicting reactions instead of averaging them into an artificial consensus. Decide whether they point to different segments, a choice about whom to serve or missing context. Present the few changes likely to matter most and explain the tradeoff. If two materially different revisions serve different accepted customers, show how each would work and let me choose. Do not change the intended audience or a substantive product promise on my behalf. Produce the actual revised offer in the form we are testing: rewritten proposal or page copy, a corrected specification or a feasible prototype amendment. Mark assumptions and new proposed commitments for my judgment. Recheck the affected parts with the relevant accepted profiles, using fresh encounters where possible and labeling this as a revision check. Retain the original so I can see what changed. ### Prepare the real-customer test Deliver the accepted customer profiles with their evidence, the original and revised offering, and a compact comparison of the simulated encounters. State which questions the simulation surfaced and which remain unanswered. Turn the most important findings into a short real-customer test brief. Identify whom to involve, what to show them, a representative task or behavior to observe, and neutral questions to ask about current work and the proposed change. For each hypothesis, name what evidence would support or contradict it. Keep predicted enthusiasm, purchasing and demand as things to investigate, not simulation results we have established. Invite my corrections and revise the deliverables. Finish with a stronger offering and a practical way to learn from real people. Do not contact customers or claim market validation from this exercise. These instructions were written in September 2026 using the frontier models available at the time. You may now have better tools or models, or restrictions that make some tasks harder. Your AI should adapt to the tools and access you actually have and find the best available way to help. Everything here is a starting suggestion for you and your AI, not a proven best practice for every setup. Feel free to rewrite any of it to better meet your needs.
View full AI instructions
Test a new offering with simulated customers.
What the AI will do
- Find existing customer personas and the evidence behind them, or propose plausible customers from research and company records.
- Run separate reactions to the same offering, reconcile the findings and revise the offering into a stronger version for real-customer testing.
What you can provide
- The new offering in whatever form it exists: a rough description, proposal, prototype or product page.
- Accessible customer research and company records; the AI looks for existing personas before asking you to create them.
Where you'll take part
- Clarify the offering and edit, add or remove the proposed simulated customers.
- Accept the cast before the simulation, then judge which proposed changes belong in the revised offer.
What you'll get
A revised offering, a comparison of simulated reactions and specific hypotheses and questions to take to real customers.
Activity context
An imagined customer can expose a confusing offer or a missing feature before a real customer sees it. The useful simulation starts with customers who resemble the people you want to serve: their work, constraints, alternatives and reasons to say no. You get to correct that cast before anyone reacts.
For the user
Bring the offering you want to test. The AI will look for existing personas and customer evidence, then show you whom it proposes to simulate. You will correct and accept those customer descriptions before the test runs, and help choose revisions afterward. A simulation gives you useful hypotheses; actual customer testing establishes whether they hold.
Guidance for the AI
These are general instructions, not a description of this user's particular AI system, tools, access, or circumstances. Adapt the method to the user's goal and the capabilities you can actually use, while preserving the activity's essential sequence, review points, and intended result.
Start with the activity and the user's context
Read the complete activity and guide the user through it. Use the activity prompt yourself; the user does not need to paste it again. Keep the responsibilities of the user, the AI, and any colleague clear.
Begin with what the user has already supplied. Establish the intended result and resolve missing context through focused questions when needed. Work within the activity's stated scope, permissions, required confirmations, and stopping points, including any deliberate order for introducing information. Make progress with the available information and reasonable, clearly identified assumptions where the activity allows them.
Check the capabilities needed for this work
Inspect relevant available tools, connectors, and data. Use small, relevant, non-destructive checks to establish whether necessary access or a capability actually works. Naming a product does not establish access to it. Let this activity determine what needs checking; do not impose a universal preliminary questionnaire or a full system audit.
When useful access is missing:
- Explain what you cannot reach and how that material would help.
- Investigate practical setup, connection, export, or other access alternatives before asking the user to gather material or troubleshoot.
- If progress depends on access, request only the specific user action or permission needed to enable it or provide the material another way. Continue useful independent work while awaiting the response.
- Offer to walk the user through an export or upload. Welcome files, links, copied text, rough notes, or an interview as supported by your system and the activity, and use the best available route. If the missing access is optional, continue with what is available.
Ask focused questions and respect the answers
Ask questions only when necessary to complete the work well or satisfy the activity's required review points. Build on answers already supplied. Ask one question at a time, or a small group of closely related questions. Wait on work that depends on the answer, and continue useful work that does not. Explain unfamiliar language with examples where helpful.
Confirm answers or decisions you supply on the user's behalf before treating them as the user's final answers or decisions. This does not require separate approval of every sourced finding; follow the activity's specific review requirements.
Keep evidence and independent contributions distinct
Distinguish evidence, inference, and missing information. Check your work against the source material.
Use independent agents when your system actually supports delegation and independent investigation or review would improve the work:
- Give each agent a bounded brief and the context appropriate to its role.
- Keep discovery independent until synthesis where the activity requires it. Preserve any requirement for the user or colleagues to contribute before seeing other explanations.
- Follow the activity's stated fallback and any required confirmation when independent agents or fresh contexts are unavailable. Preserve reviewer isolation where required; describe shared-context or sequential passes accurately.
Produce, check, and revise the result
Do the substantive investigation and production. Carry the activity through to the most complete, usable result within its scope, rather than ending with a plan or handing the main work back to the user. When missing information does not prevent useful work, proceed with clearly identified assumptions where the activity permits them.
Check the result against the activity's completion criteria. At each substantive delivery, state what is complete and any material unfinished work, assumptions, helpful missing information, and remaining uncertainty. Explain how these affect what the user can use, and help the user revise the result.
Preserve the activity's stopping point. Do not turn a rehearsal, investigation, or test-design activity into execution that the user has not authorized.
Your AI prompt
Help me test a new offering with simulated customers and use what we learn to improve it. First establish who those customers should be and let me correct and accept them. Do not run customer simulations before that agreement.
Understand the offering and find existing customer knowledge
Read the offering I supplied, whether a rough idea, document, product page or prototype. Establish what it does, who might use or buy it, the proposed price or commitment if known, and what I want to learn. Inspect and try access to relevant company email, message boards and chats, research documents, product plans, sales and support records, customer interview transcripts and meeting notes. Search the offering name and related products for existing personas, segments, customer problems, objections and prior tests. Use calendar or interview participant records and account roles where they help distinguish buyer, user and decision maker.
Read the dates and evidence behind any personas. An old marketing persona may be useful context without describing this offer's intended audience. Separate observed behavior, customers' reported preferences, our team's assumptions and missing information.
If company records are unavailable, investigate connection or export options and help me provide existing research or a few useful examples. If no personas exist, use customer interviews, transactions, observed use, lost sales and relevant primary public research to develop a proposed cast. If the available basis is only my experience or a rough hypothesis, say that plainly. Do not present invented customer research as something you found. Ask focused questions one at a time about gaps that matter to the proposed test.
Agree the cast and what they will see
Propose a small, manageable set of simulated customers that covers materially different needs or buying conditions. Use the evidence to choose differences, rather than filling a demographic template. For each, describe:
- Their role and situation, including whether they use the offer, pay for it or influence the purchase.
- The job they are trying to do, how they do it now and what a useful result would mean.
- Relevant constraints, vocabulary, concerns and reasons they might decline.
- The records supporting those traits, any important counterexamples and which traits are inferred.
Show me the proposed cast. Invite me to alter descriptions, add people or remove people who do not belong. Ask the clarifying question that would most improve their realism. Wait for my acceptance of the resulting cast before running any simulated reactions. Incorporate corrections and keep my proposed traits distinguishable from recorded customer evidence.
Prepare one common test stimulus: the actual offer description, page or prototype that every simulated customer will receive. Separate confirmed features and terms from proposed or unknown ones. Do not quietly supply missing benefits or explain away confusing wording. Establish the questions we want the test to answer, such as whether users understand it, where it fits their work, which missing element prevents use or what comparison drives a refusal. If an unresolved feature or price is central, let me resolve it or explicitly agree how the hypothetical term will be tested.
Run independent customer encounters
Use separate agents or fresh sessions for the accepted customers when supported. Give each a self-contained brief with its accepted profile, the relevant evidence and uncertainties, the identical stimulus and the test task. Do not give them other customers' reactions, your preferred verdict or an argument for why the offering should succeed. A large cast can run in waves; track which accepted profiles completed the same test.
Have each simulated customer encounter the offering in its own working situation. Ask it to explain what it understands the offer to do; describe a concrete occasion when it might use it; walk through how it would start and fit the offer into its current work; identify confusing or missing information; and explain what would make it choose its present alternative instead. Where a usable prototype exists, have the agent attempt a representative task with the available tools and record what it actually did. Distinguish that interaction from an imagined walkthrough.
Request a short reaction in the customer's voice followed by the evidence or accepted assumption behind each substantive concern. Do not demand that every customer produce a complaint or like the idea. Have agents identify gaps they cannot answer from the supplied profile. Avoid invented statistics, precise willingness-to-pay estimates and claims that a real person has spoken.
If isolated sessions are unavailable, explain that sequential role passes share context and offer a precise handoff for fresh chats if that matters to me. Agree that fallback before proceeding. Either way, keep the profiles and stimulus fixed and describe the method honestly; several reactions from one shared conversation are not independent customer evidence.
Reconcile reactions and improve the offer
Wait until the independent encounters finish before comparing them. Organize findings around concrete moments in use or purchase: what was understood, what failed to fit, what information was missing, what value was recognized and why someone might decline. Link each finding to the responsible profile, the exact part of the offer and its source basis. Distinguish repeated reactions from one persona's specific needs. Similar model-generated comments do not establish prevalence among real customers.
Examine conflicting reactions instead of averaging them into an artificial consensus. Decide whether they point to different segments, a choice about whom to serve or missing context. Present the few changes likely to matter most and explain the tradeoff. If two materially different revisions serve different accepted customers, show how each would work and let me choose. Do not change the intended audience or a substantive product promise on my behalf.
Produce the actual revised offer in the form we are testing: rewritten proposal or page copy, a corrected specification or a feasible prototype amendment. Mark assumptions and new proposed commitments for my judgment. Recheck the affected parts with the relevant accepted profiles, using fresh encounters where possible and labeling this as a revision check. Retain the original so I can see what changed.
Prepare the real-customer test
Deliver the accepted customer profiles with their evidence, the original and revised offering, and a compact comparison of the simulated encounters. State which questions the simulation surfaced and which remain unanswered.
Turn the most important findings into a short real-customer test brief. Identify whom to involve, what to show them, a representative task or behavior to observe, and neutral questions to ask about current work and the proposed change. For each hypothesis, name what evidence would support or contradict it. Keep predicted enthusiasm, purchasing and demand as things to investigate, not simulation results we have established.
Invite my corrections and revise the deliverables. Finish with a stronger offering and a practical way to learn from real people. Do not contact customers or claim market validation from this exercise.
Done when
You have accepted the customer profiles, seen their simulated reactions, reviewed a concrete revision of the offering and received a short brief for testing the important hypotheses with real customers.
These instructions were written in September 2026 using the frontier models available at the time. You may now have better tools or models, or restrictions that make some tasks harder. Your AI should adapt to the tools and access you actually have and find the best available way to help. Everything here is a starting suggestion for you and your AI, not a proven best practice for every setup. Feel free to rewrite any of it to better meet your needs.
These instructions were written in September 2026 using the frontier models available at the time. You may now have better tools or models, or restrictions that make some tasks harder. Your AI should adapt to the tools and access you actually have and find the best available way to help. Everything here is a starting suggestion for you and your AI, not a proven best practice for every setup. Feel free to rewrite any of it to better meet your needs.