Build a plan for the market you dismissed.
A market can be a bad business at one cost and an interesting business at another. AI may change the cost of reviewing a small contract, evaluating a small investment, designing a product or giving every customer individual attention. Revisit a market you dismissed and investigate whether the reason for rejecting it still holds.
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
- Recover why the market was rejected and investigate the specific work AI could make cheaper, faster or newly feasible.
- Compare the old and possible new delivery economics, examine customer need and write an entry plan with a small test.
What to have ready
- A dismissed market, customer group or kind of work—or access to records that could reveal one.
- Available proposals, sales conversations, cost records or rough recollections; the AI searches accessible sources first.
Where you come in
- Confirm the original rejection and the customer problem worth revisiting.
- Correct delivery assumptions and judge the proposed offer and test.
What you'll get
A concrete plan for an AI-enabled offer, with the evidence and conditions that would make the market worth entering—or a clear account of why it still does not work.
You're done when
You have a concrete AI-enabled offer and entry plan for the dismissed market, with old-versus-new economics, supporting customer evidence and a small test of the decisive assumption. If the opportunity still fails, you understand the remaining barrier and what evidence could change that conclusion.
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 build a plan for a market or kind of work we previously dismissed because serving it was too costly, too slow or impractical. The central question is how AI has changed the picture: which work becomes affordable or possible, for which customers, and under what conditions? ### Recover the rejected opportunity Use what I have supplied to identify the company, offering, market and relevant dates. Inspect and try available access to strategy documents, rejected proposals, lost-sales records, CRM notes, delivery and pricing data, and emails, chats or meeting transcripts about why we declined the work. Include relevant WhatsApp exchanges where accessible. Search the market name, customer names, proposal titles and phrases used to describe the original objection. Use these records to distinguish a cost problem from weak demand, a poor fit or another reason AI may not change. If I have not named a market, use those records to propose a small number of concrete candidates and let me choose one. If the records cannot be read, investigate connection or export options and help me provide a useful sample. Welcome a rough account of a rejected job; label it as recollection and identify which missing numbers or decisions matter. Ask one focused question at a time. Do not make me assemble a market-research packet before you look for what is already accessible. Summarize who we would serve, what job they need done, what we would have offered, why we rejected it and when. Show the evidence and ask me to correct the premise before building a plan around it. ### Identify the change AI could make Investigate the actual tasks that made this market unattractive. These examples are possibilities to examine, not success claims: - A law firm could not afford to review smaller contracts at a price those customers could pay. - A private-equity firm or hedge fund could not justify the work of evaluating smaller investments. - A useful service required a price that a whole customer group could not afford. - Products took too long to design and prototype for a small or uncertain market. - A level of personalization was previously impractical to deliver. Map the former delivery process from the customer's request to an acceptable finished result. For each important task, establish the required inputs, people, time, bottleneck and quality judgment. Then propose the changed process: what an AI would do, what it would need, what a person still decides or checks, and where exceptions go. Preserve the customer's essential result when comparing the two processes; a cheaper but inadequate service is a different proposition. Search current official product documentation and relevant original demonstrations or evaluations for the particular capability the new process requires. Open the sources, note dates and model or tool versions, and separate documented capability from a proposed application. Do not infer reliable contract review, investment judgment or production readiness from a general statement that an AI can analyze documents. Inspect the tools actually available here. Where a bounded trial on supplied or accessible representative material is possible within our agreed scope, perform it and inspect the output against the required quality. Preserve actual inputs, results, remaining human effort and errors. If you cannot run that trial, specify exactly what needs testing and keep the capability unverified; do not invent performance. ### Rebuild the economics around the customer Find customer evidence in declined inquiries, lost-sales reasons, support exchanges, interviews, usage and relevant primary market sources. Establish who uses the result, who pays, what they do instead and why the old price or delivery method did not work. Treat an expressed need separately from willingness to buy the proposed offer. Compare the old and proposed ways of serving one representative job, order or customer. Include acquisition and onboarding, preparation, AI/tool use, human judgment and review, revisions, support, delivery time and capacity where relevant. Use actual figures when available; label estimates and show the calculation. Distinguish one-time setup from recurring delivery. Use ranges for uncertain inputs and identify which variables change the conclusion. Ask me about consequential unknowns you cannot establish. Do not turn lower token cost into a claim of lower total cost. Work out what must be true for the offer to make sense: a feasible price range, acceptable quality, enough demand, delivery capacity and the minimum repeat volume needed to cover the proposed setup. If the evidence supports only a hypothetical price or demand level, say so. Identify the assumption that most needs a real test. For a large investigation, give bounded agents separate work on the former rejection, delivery economics and customer need. Supply relevant sources, dates and a specific deliverable to each; keep track of coverage and reconcile them before deciding on an offer. Without agents, use those as manageable passes and preserve the source trail. ### Write the offer and a credible entry plan Develop a specific first offer: intended customer, problem solved, what they receive, service boundaries, delivery process, proposed price or pricing test and the reason it is newly feasible. If two materially different offers fit the evidence—for example, a standard low-price service or a more personalized premium service—show their practical differences and recommend one. Let me resolve a consequential choice before detailing the chosen plan. Write a concrete entry plan that uses the resources and capabilities we actually have. Explain how to find the first suitable buyers, prepare a representative demonstration or sample, deliver the first small set of jobs, learn what the buyers value and decide whether to continue. Name what must be built, learned or obtained before serving them. Keep proposed outreach and commercial launch as decisions for me. Specify the smallest useful test of the most important uncertain assumption. Give it a customer type, representative task, deliverable, comparison, approximate effort or cost based on stated assumptions, quality check and observable result that would support continuing, changing or stopping. A technical demonstration tests delivery; feedback tests usefulness; an actual purchase tests willingness to pay. Choose the evidence needed for this offer and do not treat one kind as the others. ### Deliver and check the plan Check the final plan against the original rejection and the customer evidence. Make the causal link explicit: AI changes this part of the work, which changes this cost or possibility, which could let us serve these customers. Identify anything in that chain that remains untested. Give me the offer, old-versus-new economics, entry sequence, small test and the few conditions that determine viability, with sources and assumptions attached. Invite my corrections and revise. If AI has not changed the decisive barrier, deliver that finding and the useful test or evidence that could change it; do not manufacture an attractive market. Finish with a usable decision document, not a claim that the business has been launched or validated. 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
Build a plan for the market you dismissed.
What the AI will do
- Recover why the market was rejected and investigate the specific work AI could make cheaper, faster or newly feasible.
- Compare the old and possible new delivery economics, examine customer need and write an entry plan with a small test.
What you can provide
- A dismissed market, customer group or kind of work—or access to records that could reveal one.
- Available proposals, sales conversations, cost records or rough recollections; the AI searches accessible sources first.
Where you'll take part
- Confirm the original rejection and the customer problem worth revisiting.
- Correct delivery assumptions and judge the proposed offer and test.
What you'll get
A concrete plan for an AI-enabled offer, with the evidence and conditions that would make the market worth entering—or a clear account of why it still does not work.
Activity context
A market can be a bad business at one cost and an interesting business at another. AI may change the cost of reviewing a small contract, evaluating a small investment, designing a product or giving every customer individual attention. Revisit a market you dismissed and investigate whether the reason for rejecting it still holds.
For the user
Start with a market or kind of work you have said no to. You can name it in a sentence; the AI will look for the old reasoning, delivery costs and customer evidence. Expect a few questions about what a buyer needs and what acceptable work requires, followed by a specific offer, a comparison of the economics and a test you could choose to run.
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 build a plan for a market or kind of work we previously dismissed because serving it was too costly, too slow or impractical. The central question is how AI has changed the picture: which work becomes affordable or possible, for which customers, and under what conditions?
Recover the rejected opportunity
Use what I have supplied to identify the company, offering, market and relevant dates. Inspect and try available access to strategy documents, rejected proposals, lost-sales records, CRM notes, delivery and pricing data, and emails, chats or meeting transcripts about why we declined the work. Include relevant WhatsApp exchanges where accessible. Search the market name, customer names, proposal titles and phrases used to describe the original objection. Use these records to distinguish a cost problem from weak demand, a poor fit or another reason AI may not change.
If I have not named a market, use those records to propose a small number of concrete candidates and let me choose one. If the records cannot be read, investigate connection or export options and help me provide a useful sample. Welcome a rough account of a rejected job; label it as recollection and identify which missing numbers or decisions matter. Ask one focused question at a time. Do not make me assemble a market-research packet before you look for what is already accessible.
Summarize who we would serve, what job they need done, what we would have offered, why we rejected it and when. Show the evidence and ask me to correct the premise before building a plan around it.
Identify the change AI could make
Investigate the actual tasks that made this market unattractive. These examples are possibilities to examine, not success claims:
- A law firm could not afford to review smaller contracts at a price those customers could pay.
- A private-equity firm or hedge fund could not justify the work of evaluating smaller investments.
- A useful service required a price that a whole customer group could not afford.
- Products took too long to design and prototype for a small or uncertain market.
- A level of personalization was previously impractical to deliver.
Map the former delivery process from the customer's request to an acceptable finished result. For each important task, establish the required inputs, people, time, bottleneck and quality judgment. Then propose the changed process: what an AI would do, what it would need, what a person still decides or checks, and where exceptions go. Preserve the customer's essential result when comparing the two processes; a cheaper but inadequate service is a different proposition.
Search current official product documentation and relevant original demonstrations or evaluations for the particular capability the new process requires. Open the sources, note dates and model or tool versions, and separate documented capability from a proposed application. Do not infer reliable contract review, investment judgment or production readiness from a general statement that an AI can analyze documents. Inspect the tools actually available here. Where a bounded trial on supplied or accessible representative material is possible within our agreed scope, perform it and inspect the output against the required quality. Preserve actual inputs, results, remaining human effort and errors. If you cannot run that trial, specify exactly what needs testing and keep the capability unverified; do not invent performance.
Rebuild the economics around the customer
Find customer evidence in declined inquiries, lost-sales reasons, support exchanges, interviews, usage and relevant primary market sources. Establish who uses the result, who pays, what they do instead and why the old price or delivery method did not work. Treat an expressed need separately from willingness to buy the proposed offer.
Compare the old and proposed ways of serving one representative job, order or customer. Include acquisition and onboarding, preparation, AI/tool use, human judgment and review, revisions, support, delivery time and capacity where relevant. Use actual figures when available; label estimates and show the calculation. Distinguish one-time setup from recurring delivery. Use ranges for uncertain inputs and identify which variables change the conclusion. Ask me about consequential unknowns you cannot establish. Do not turn lower token cost into a claim of lower total cost.
Work out what must be true for the offer to make sense: a feasible price range, acceptable quality, enough demand, delivery capacity and the minimum repeat volume needed to cover the proposed setup. If the evidence supports only a hypothetical price or demand level, say so. Identify the assumption that most needs a real test.
For a large investigation, give bounded agents separate work on the former rejection, delivery economics and customer need. Supply relevant sources, dates and a specific deliverable to each; keep track of coverage and reconcile them before deciding on an offer. Without agents, use those as manageable passes and preserve the source trail.
Write the offer and a credible entry plan
Develop a specific first offer: intended customer, problem solved, what they receive, service boundaries, delivery process, proposed price or pricing test and the reason it is newly feasible. If two materially different offers fit the evidence—for example, a standard low-price service or a more personalized premium service—show their practical differences and recommend one. Let me resolve a consequential choice before detailing the chosen plan.
Write a concrete entry plan that uses the resources and capabilities we actually have. Explain how to find the first suitable buyers, prepare a representative demonstration or sample, deliver the first small set of jobs, learn what the buyers value and decide whether to continue. Name what must be built, learned or obtained before serving them. Keep proposed outreach and commercial launch as decisions for me.
Specify the smallest useful test of the most important uncertain assumption. Give it a customer type, representative task, deliverable, comparison, approximate effort or cost based on stated assumptions, quality check and observable result that would support continuing, changing or stopping. A technical demonstration tests delivery; feedback tests usefulness; an actual purchase tests willingness to pay. Choose the evidence needed for this offer and do not treat one kind as the others.
Deliver and check the plan
Check the final plan against the original rejection and the customer evidence. Make the causal link explicit: AI changes this part of the work, which changes this cost or possibility, which could let us serve these customers. Identify anything in that chain that remains untested.
Give me the offer, old-versus-new economics, entry sequence, small test and the few conditions that determine viability, with sources and assumptions attached. Invite my corrections and revise. If AI has not changed the decisive barrier, deliver that finding and the useful test or evidence that could change it; do not manufacture an attractive market. Finish with a usable decision document, not a claim that the business has been launched or validated.
Done when
You have a concrete AI-enabled offer and entry plan for the dismissed market, with old-versus-new economics, supporting customer evidence and a small test of the decisive assumption. If the opportunity still fails, you understand the remaining barrier and what evidence could change that conclusion.
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.